Partage de journaux conforme au RGPD...

Les données personnelles se cachent dans les journaux

Les journaux d'application sont l'une des surfaces RGPD les plus négligées en ingénierie. Non pas parce que les ingénieurs ignorent la loi. Mais parce que les données utilisateur entrent dans les fichiers de journal par accident.

Un seul journal de requête JSON peut contenir quatre champs PII :

{
  "timestamp": "2025-11-14T09:22:13Z",
  "level": "ERROR",
  "endpoint": "/api/users/profile",
  "user_email": "sarah.johnson@company.com",
  "client_ip": "82.123.45.67",
  "user_agent": "Mozilla/5.0",
  "error": "ValidationError: phone format",
  "input_value": "+49 176 1234 5678"
}

Cette seule entrée contient un e-mail, une IP et un numéro de téléphone. Multipliez cela par des millions d'appels API quotidiens. Le résultat est une activité PII majeure. Elle nécessite une base légale, des limites et des contrôles.

Le partage avec des tiers augmente le risque RGPD

Les équipes partagent des fichiers journaux avec des parties externes en permanence :

• Entreprises de test d'intrusion qui reçoivent des enregistrements pour cartographier le comportement de l'application
• Consultants externes qui utilisent des échantillons de journaux pour diagnostiquer les problèmes de performance
• Plateformes de journalisation (Elastic, Datadog, Splunk) qui reçoivent des flux de sortie complets
• Sous-traitants SRE qui accèdent aux enregistrements lors d'incidents
• Équipes de développement dans d'autres entités juridiques qui reçoivent des fichiers pour le débogage

Chaque partage soulève des questions liées à l'article 28 du RGPD. Le destinataire est-il un sous-traitant ? Existe-t-il un contrat de traitement des données ? Dispose-t-il d'une base légale pour consulter les données utilisateur dans ces fichiers ?

Les plateformes de journalisation sont un angle mort courant. Envoyer des sorties avec de vraies adresses e-mail et IP à Elastic Cloud ou Datadog crée un lien de traitement. Ce lien nécessite un DPA, des clauses types et un mécanisme de transfert si la plateforme est hors UE. Tout cela prend du temps et une révision juridique.

La voie la plus simple : supprimer les données utilisateur avant que les fichiers quittent votre système. Consultez notre aperçu de conformité pour le cadre complet de l'article 28.

Pourquoi la structure JSON complique la détection

Les fichiers journaux JSON varient en structure. Le scan de texte générique ne suffit pas.

Profondeur d'imbrication : Les données utilisateur apparaissent à n'importe quelle profondeur. Le champ request.headers.x-forwarded-for contient des adresses IP. Le champ response.body.errors[0].field_value peut contenir des entrées utilisateur issues d'erreurs. Un scan texte plat rate les champs enfouis dans des chemins imbriqués.

Schémas incohérents : Chaque point de terminaison API produit une forme de sortie différente. Les fichiers d'authentification diffèrent des fichiers de paiement. Les fichiers de mise à jour de profil diffèrent des deux. Une approche à chemin fixe rate les données utilisateur qui apparaissent dans des contextes d'erreur inattendus.

Valeurs techniques mélangées à des PII : Les traces de pile, les codes d'erreur et les horodatages doivent rester intacts. La suppression globale efface les champs nécessaires et rend le fichier inutilisable.

La bonne approche est la détection basée sur le contenu. Trouvez les données utilisateur par ce qu'elles sont — motif d'e-mail, format IP, entité nommée — et non par leur position. Cela gère des schémas variables sans configuration par point de terminaison.

Un remplacement cohérent maintient l'utilité des journaux

L'exigence clé est l'intégrité référentielle. Si sarah.johnson@company.com apparaît dans 47 entrées d'une chaîne de requête, les 47 doivent correspondre à la même valeur.

Règles de correspondance :

• sarah.johnson@company.com → user1@example.com (même valeur dans tout le fichier)
• 82.123.45.67 → 192.0.2.1 (IP de documentation RFC 5737 — clairement pas réelle)
• +49 176 1234 5678 → +49 XXX XXX XXXX (masqué)

Avec cette correspondance, un développeur peut tracer user1@example.com dans 47 entrées, reconstruire la chaîne de requête et corriger le bug — sans voir de vraies données utilisateur.

Ces champs de métadonnées restent inchangés :

• Horodatages (pas de données utilisateur)
• Codes et types d'erreur (pas de données utilisateur)
• Traces de pile (peuvent contenir des ID techniques, pas de données utilisateur)
• Méthodes HTTP, chemins, codes de statut (pas de données utilisateur)
• Valeurs de métriques et de latence (pas de données utilisateur)

Le résultat est un fichier qui fonctionne pour le débogage. Il ne contient pas de vraies données utilisateur. Consultez notre glossaire pour la différence entre anonymisation et pseudonymisation selon le RGPD.

Cas d'usage : Partage de journaux pour test d'intrusion

Une entreprise SaaS a mené une revue de sécurité trimestrielle avec une équipe externe de test d'intrusion. Le périmètre exigeait 90 jours de sortie API de production pour cartographier les flux d'authentification et analyser les modèles d'erreur.

Volume brut : 180 Mo de fichiers JSON. Comptage PII : 4 200 e-mails utilisateur uniques, 1 800 IP uniques, 340 numéros de compte partiels dans des contextes d'erreur.

Sans suppression préalable des données utilisateur, le partage de ces fichiers nécessiterait :

• Un DPA avec l'entreprise de test d'intrusion
• Un mécanisme de transfert RGPD article 46 (l'entreprise était hors UE)
• Une analyse de notification des personnes concernées

Chaque point implique du travail juridique et du temps.

Avec suppression des PII appliquée :

• Temps de traitement : 25 minutes pour 180 Mo
• Résultat : 180 Mo de fichiers structurellement identiques, tous les e-mails et IP remplacés par des valeurs sûres
• Résultat : l'équipe de test d'intrusion a reçu le contexte complet ; aucune donnée utilisateur réelle ne leur a été transmise
• Issue RGPD : aucun DPA requis — la sortie épurée n'est pas des données utilisateur selon le RGPD

Consultez notre FAQ pour les questions fréquentes sur ce qui est considéré comme anonyme selon le RGPD.

Intégrer la suppression des PII dans CI/CD

Pour les équipes qui partagent régulièrement des sorties, cette étape peut s'exécuter dans les pipelines existants.

Rotation des journaux :

1. Le script de rotation s'exécute chaque nuit
2. L'étape de suppression s'exécute avant l'archivage ou l'envoi à une plateforme de journalisation
3. Les fichiers épurés vont aux systèmes externes
4. Les fichiers originaux restent en interne avec toute la période de conservation

Script de pré-partage :

1. L'ingénieur doit partager un échantillon avec un sous-traitant
2. Exécute le script : input=raw-logs/ output=clean-logs/
3. Partage le dossier clean-logs/
4. Pas de vérification manuelle des PII nécessaire

Approche sidecar :

1. Le sidecar épure le flux de sortie avant la transmission
2. La suppression en temps réel maintient l'utilité pour l'analyse des journaux
3. La plateforme ne reçoit aucune donnée utilisateur réelle

Intégration dans la politique de conservation

L'article 5(1)(e) du RGPD exige la limitation du stockage. La suppression des PII s'intègre dans toute politique de conservation.

• Sortie brute conservée 7 jours (pour le débogage quotidien)
• Versions épurées conservées 90 jours (pour l'analyse des tendances et la revue des incidents)
• L'étape de suppression s'exécute le jour 7

Cela satisfait la limitation du stockage. Cela élimine le risque de conserver des sorties brutes sur le long terme.

Sources

• RGPD Article 5 : Principes relatifs au traitement
• RGPD Article 28 : Obligations du sous-traitant
• EDPB : Lignes directrices sur les relations responsable-sous-traitant
• Elastic : Détection des PII dans les fichiers journaux