Le risque RGPD silencieux dans votre stack de logs
Mis à jour pour 2026
La plupart des équipes vérifient leur base de données pour les données personnelles. Peu appliquent la même rigueur à leur système de logs.
L'article 5, paragraphe 1, point e) du RGPD limite la durée de conservation des données personnelles. Pour les bases de données, les équipes définissent des politiques de rétention et des tâches de suppression. Pour les fichiers de logs, la règle est plus simple : tout conserver 90 jours pour le débogage.
Le problème ? Ces entrées contiennent des données personnelles. Les entrées de requêtes contiennent des e-mails d'utilisateurs. Les captures d'erreurs contiennent des valeurs d'entrée brutes. Les entrées d'accès contiennent des adresses IP. Chacune de ces informations est une donnée personnelle au sens du RGPD. Votre équipe a besoin d'une base juridique et d'un plan de conservation pour chaque cas.
Ce qui finit dans vos fichiers de logs
La journalisation standard des applications web collecte un large éventail de données personnelles (PII).
Entrées d'accès (nginx/Apache) :
- Adresses IP — données personnelles selon les lignes directrices du CEPD
- Chaînes user-agent — peuvent permettre l'empreinte digitale d'appareil
- Jetons de session — s'ils figurent dans la sortie
Entrées applicatives (JSON structuré) :
- Identifiants utilisateurs et adresses e-mail
- Erreurs de validation — contiennent souvent la valeur invalide brute, qui peut être une vraie donnée personnelle
- Événements métier — IDs de commandes liés aux comptes clients
- Requêtes de recherche — peuvent contenir des noms ou des adresses
Entrées de passerelle API :
- En-têtes d'autorisation — partiellement capturés dans certaines configurations
- Paramètres de requête — peuvent transporter des IDs utilisateurs, noms ou e-mails
- Corps des requêtes et réponses — présents dans les configurations de niveau débogage
Entrées d'audit de base de données :
- Requêtes SQL avec clauses WHERE comme
email = 'user@example.com' - Valeurs personnelles littérales dans les paramètres de requête
Cette accumulation n'est pas intentionnelle. C'est un effet secondaire de pratiques de journalisation conçues pour le débogage, pas pour la conformité RGPD.
Position du CEPD sur les adresses IP
Le Comité européen de la protection des données (CEPD) considère les adresses IP comme des données personnelles. Les fournisseurs d'accès peuvent les relier à des abonnés. Au sein d'une organisation, elles peuvent identifier des utilisateurs spécifiques.
L'implication est directe. Les entrées d'accès avec adresses IP sont des enregistrements personnels. Conserver la sortie nginx 12 mois signifie conserver des données personnelles 12 mois. Cela exige une base juridique selon l'article 6. Cela exige aussi que la durée de conservation corresponde à la finalité déclarée.
La plupart des équipes sautent cette étape. « Nous conservons les entrées 90 jours parce que la sécurité le dit » est une règle opérationnelle. Ce n'est pas une analyse au titre de l'article 5, paragraphe 1, point e). Consultez notre aperçu conformité légale pour le contexte global.
Le chemin vers la conformité
La voie pratique pour la plupart des équipes n'est pas de réduire les fenêtres de rétention. Les justifications opérationnelles et sécuritaires pour des durées plus longues sont réelles. La meilleure approche est de masquer les entrées avant le stockage à long terme.
Un modèle par niveaux fonctionne bien.
0–7 jours : Entrées brutes complètes pour le débogage actif. Sept jours sont suffisamment courts pour la plupart des équipes.
7–90 jours : Entrées masquées pour l'analyse des tendances et la surveillance de sécurité. Les adresses IP sont remplacées. Les e-mails des utilisateurs deviennent des jetons stables. Les numéros de compte sont masqués. Les champs techniques — horodatages, codes d'erreur, latence, points de terminaison — sont conservés.
90+ jours (si nécessaire) : Sortie agrégée uniquement. Comptages d'événements, taux d'erreurs, plages de latence. Aucun enregistrement individuel ne subsiste.
La conservation des données personnelles s'arrête à sept jours. La sortie agrégée peut être conservée sans exposer d'individus. Voir Sécurité & Conformité pour plus de détails.
Préserver la structure JSON pour la surveillance
Un bon masquage maintient la structure JSON intacte. Il ne remplace que le contenu. Cela garde la sortie utile pour le débogage et les alertes.
Conservé :
- Structure JSON et noms de clés
- Horodatages et séquences temporelles
- Types d'erreurs et codes de statut HTTP
- Méthodes HTTP, chemins et valeurs de latence
- Types d'événements métier
Remplacé :
- Adresses e-mail → jeton stable par original (ex.
user1@example.com) - Adresses IP → plages RFC 5737 (
192.0.2.x) - Numéros de compte →
ACCT_XXXXX - Numéros de téléphone →
+XX XXX XXX XXXX - Noms dans le texte d'erreur →
[PERSON]
Les jetons stables gardent les traces utiles. Une trace pour user1@example.com sur 40 entrées fonctionne comme l'original. Les métriques agrégées — taux d'erreurs, latence, débit — n'ont besoin d'aucune donnée personnelle. Consultez le Glossaire pour les définitions de pseudonymisation et anonymisation.
Trois options d'intégration
Trois modèles couvrent la plupart des équipes engineering.
Option 1 — Masquage dans le pipeline : Fluentd ou Logstash intercepte chaque ligne avant de la transmettre. Une étape de masquage s'exécute en ligne. Elastic ou Datadog ne reçoit que des entrées nettoyées. Aucun changement de code applicatif n'est nécessaire.
Option 2 — Traitement par lots nocturne : Les entrées brutes atterrissent dans le stockage local. Un job nocturne masque la sortie de la veille et supprime la version brute. Les entrées masquées vont dans le stockage long terme. La sortie brute n'est conservée que sept jours.
Option 3 — Masquage avant partage : Les entrées brutes restent internes avec des contrôles d'accès stricts. Avant de partager avec des testeurs de pénétration ou des prestataires externes, effectuez un passage de masquage. Les parties externes reçoivent toujours des versions nettoyées.
Pour la documentation RGPD, le masquage est une « mesure technique » au titre de l'article 32. Documentez l'outil, sa configuration et votre politique de rétention dans votre Registre des Activités de Traitement (RAT) selon l'article 30. Consultez notre FAQ pour les questions fréquentes sur le RAT.
Vous voulez un exemple concret ? Consultez les études de cas. Voir aussi les tarifs pour savoir quel plan inclut des pipelines de masquage intégrés.
Sources
- RGPD Article 5 : Principes relatifs au traitement — VERIFIED-EXTERNAL
- Avis CEPD 5/2019 sur la directive ePrivacy et le RGPD — VERIFIED-EXTERNAL
- Sonra.io : Masquage PII dans les données JSON et XML — VERIFIED-EXTERNAL