Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Vendredi 16 octobre 2026
RGPD

Journaux d'erreurs : éviter de collecter tout le dossier

Configurer les journaux d’erreurs pour diagnostiquer un problème sans enregistrer mots de passe, contenus complets ou données excessives.

Une erreur d’import déclenche l’enregistrement de la ligne rejetée. Le journal reçoit alors le nom, l’adresse, un commentaire et parfois une pièce jointe, alors que le diagnostic exige seulement de savoir quelle règle a échoué. Ces informations sont ensuite copiées vers un collecteur, un tableau de bord et une alerte électronique.

La minimisation des journaux consiste à définir les faits utiles au diagnostic et à la sécurité, puis à vérifier ce que les différents composants enregistrent réellement. Masquer une colonne dans l’interface de consultation ne réduit pas la collecte si le contenu complet reste dans le stockage et les exports.

Séparer les finalités avant de fixer les champs

Un journal de sécurité permet notamment de comprendre un accès ou une opération anormale. Un journal de diagnostic aide à expliquer un dysfonctionnement logiciel. Ils peuvent partager certains événements, mais leurs lecteurs, leur détail et leur conservation ne sont pas forcément identiques. Ne réunissez pas toutes les traces dans une conservation unique justifiée par le seul mot « sécurité ».

L’Art. 5(1)(b), 5(1)(c) et 5(1)(e) du RGPD encadre respectivement la finalité, la minimisation et la durée. L’Art. 32(1) exige des mesures adaptées aux risques ; il ne donne pas une permission générale de recopier toutes les données métier dans les traces. RGPD, principes et sécurité du traitement.

La CNIL recommande notamment de tracer les opérations avec des références aux données concernées pour éviter leur duplication. Elle déconseille l’enregistrement excessif des données, dont les mots de passe ou leurs empreintes. Elle demande aussi de protéger les journaux et d’en vérifier l’exploitation. CNIL, tracer les opérations.

Formulez donc deux besoins différents si nécessaire : « retrouver les versions et règles associées à un import rejeté » et « identifier les accès non autorisés à l’application ». Un événement suffisamment précis peut remplir le premier besoin sans contenir l’identité complète de chaque personne importée.

Un dictionnaire de journalisation rempli

Le tableau suivant concerne un import fictif de réservations. L’équipe veut expliquer pourquoi certaines lignes échouent après une mise à jour. Le problème à diagnostiquer est une date de fin antérieure à la date de début. La proposition limite les traces ordinaires à des faits techniques ; elle doit être adaptée à l’application réelle.

Champ proposé Valeur fictive Décision et utilité
Horodatage 2026-10-06T08:14:32Z Conserver pour situer l’événement, avec fuseau explicite
Version applicative 4.2-exemple Conserver pour rapprocher le défaut d’une évolution
Opération import_reservation Conserver : décrit la fonction sans copier le dossier
Code d’erreur DATE_FIN_AVANT_DEBUT Conserver : identifie la règle violée
Référence d’exécution IMP-72 Conserver si nécessaire au rapprochement contrôlé
Rang de la ligne 18 Conserver pour retrouver la ligne dans le circuit métier habilité
Nom, adresse et commentaire Contenu du client Exclure des traces ordinaires de ce diagnostic
Mot de passe ou jeton de session Secret d’authentification Exclure ; ne pas remplacer par une empreinte conservée par réflexe
Pièce jointe complète Document du dossier Exclure : inutile à la règle de dates examinée

Le résultat attendu pourrait se lire ainsi : « 08:14:32Z ; version 4.2-exemple ; import_reservation ; IMP-72 ; ligne 18 ; DATE_FIN_AVANT_DEBUT ». Ce message permet de rechercher les événements du même import et de comparer les versions sans recopier la ligne rejetée.

La référence IMP-72 n’est pas présentée comme anonyme. Si elle permet de retrouver un dossier personnel, directement ou avec d’autres informations accessibles, elle reste à protéger. La table ou l’outil qui réalise ce rapprochement doit avoir ses propres habilitations, distinctes si nécessaire de celles des personnes chargées du diagnostic.

Pour une erreur différente, le dictionnaire doit évoluer selon le besoin. Une anomalie d’encodage peut nécessiter de connaître un type de caractère ou une taille ; cela n’implique pas forcément de conserver toute la valeur saisie. Préférez une information dérivée suffisante, en vérifiant qu’elle ne révèle pas elle-même une donnée inutile.

Contrôler les messages produits automatiquement

Le message explicite du développeur n’est qu’une source de traces. Une bibliothèque peut ajouter la requête, les paramètres, le corps d’une réponse ou le détail d’une exception. Un composant de surveillance peut aussi collecter ce que l’application avait choisi de ne pas enregistrer dans son journal principal.

Dressez la liste des points de capture : navigateur, serveur applicatif, passerelle, tâche d’import, collecteur et service externe. Pour chacun, demandez le contenu transmis et les transformations appliquées. Une règle configurée dans le serveur ne démontre pas que la trace produite côté navigateur suit la même règle.

Lorsque c’est possible, partez d’une liste de champs admis plutôt que d’un enregistrement complet suivi de quelques suppressions. Un filtre portant seulement sur les noms « password » ou « email » peut ignorer un secret dans un champ libre, un objet imbriqué ou un message d’exception. La règle doit viser les contenus effectivement produits par vos composants.

La revue d’une nouvelle catégorie de données inclut son apparition éventuelle dans les traces. L’ajout d’une pièce jointe ou d’un commentaire à un formulaire peut changer le contenu des erreurs sans modification visible du tableau de bord technique.

Vérifier la chaîne avec des valeurs fictives reconnaissables

Préparez plusieurs entrées fictives : import conforme, date incohérente, format refusé et accès non autorisé. Placez des valeurs témoins distinctes dans les champs qui doivent être exclus. Utilisez de faux secrets sans aucune capacité d’accès ; l’objectif est de repérer une copie, pas d’exposer un identifiant réel.

Pour l’import de l’exemple, la fiche de vérification prévoit : retrouver IMP-72 et le code d’erreur dans les traces autorisées ; ne retrouver ni le nom témoin ni le commentaire témoin dans le journal applicatif, le collecteur, l’alerte et l’export. Le parcours conforme sert également de contrôle : il ne doit pas devenir une collecte intégrale simplement parce qu’aucune erreur n’est survenue.

La CNIL recommande de vérifier les développements avant leur mise à disposition et de privilégier des données fictives ou anonymisées dans les environnements de développement et de test. CNIL, encadrer les développements. La préparation des données de test permet d’organiser ces vérifications sans reprendre inutilement des dossiers réels.

Ce protocole décrit des contrôles à effectuer ; aucun essai d’application n’est rapporté ici. Consignez les résultats réels par destination, pas seulement « filtre activé ». Si un commentaire témoin apparaît encore dans une alerte, la chaîne n’est pas maîtrisée. Corrigez ce point de collecte ou son transfert, puis vérifiez à nouveau les destinations concernées avant d’accepter la configuration.

Fixer les durées par catégorie de trace

La fiche CNIL sur la journalisation recommande une période glissante de six mois à un an pour les événements qu’elle vise, avec des exceptions notamment liées aux obligations légales, contentieux ou analyses d’incident. Ce repère ne rend pas nécessaire la conservation d’une requête complète pendant un an. Le détail à collecter reste soumis à minimisation. CNIL, conservation des événements journalisés.

Dans un dossier de configuration, séparez donc la durée des événements de sécurité de celle d’informations de diagnostic supplémentaires. Par exemple, une équipe peut proposer trente jours pour un diagnostic ordinaire si ce besoin est établi ; c’est alors une décision interne motivée, pas une durée légale générale. L’analyse doit aussi préciser ce qui est retiré ou conservé au terme de l’investigation.

Une conservation liée à un incident identifié porte sur les éléments nécessaires à ce dossier. Elle ne justifie pas de suspendre indéfiniment la suppression de tous les journaux. Documentez le périmètre extrait, le motif, les lecteurs autorisés et le réexamen de cette conservation.

Vérifiez les réglages du collecteur, les exports et les sauvegardes selon leur fonction. Une règle appliquée au tableau de bord principal ne dit rien, à elle seule, d’une pièce jointe conservée dans une boîte de messagerie.

Encadrer le diagnostic exceptionnel

Certaines anomalies exigent temporairement plus de détail. L’autorisation doit expliquer ce qui manque, pourquoi une information moins précise ne suffit pas et sur quel périmètre l’observation sera activée. L’urgence ne rend pas nécessaires les secrets ou le dossier complet.

Une fiche originale pourrait prévoir : « Observation renforcée de l’import des dates ; collecte du format et de la longueur des valeurs, sans valeurs complètes ; accès aux deux personnes chargées du diagnostic ; arrêt après résolution ou à l’échéance décidée ; vérification du retour au niveau normal. » Les personnes, dates et paramètres exacts sont à renseigner pour chaque intervention réelle.

Prévoyez techniquement et organisationnellement ce retour. Une consigne « penser à désactiver le mode détaillé » est fragile si personne n’en porte l’exécution. Vérifiez également les copies produites pendant cette période : diminuer le niveau de collecte ne supprime pas le passé.

Si un prestataire reçoit les traces, qualifiez son rôle pour ces opérations, examinez les engagements applicables et les éventuels transferts. La télémétrie malgré un hébergement européen rappelle pourquoi la localisation de la base principale ne décrit pas toute la circulation des journaux.

Corriger des traces déjà excessives

Traitez deux chantiers séparément : arrêter la collecte excessive et décider du sort des données déjà enregistrées. L’équipe peut limiter les lecteurs, suspendre un transfert ou réduire un point de capture, tout en maintenant les traces nécessaires à la sécurité. L’objectif n’est pas d’aveugler l’organisation en supprimant toute journalisation.

Établissez les emplacements concernés : journal local, plateforme, export, alerte et copie de support. Pour chacun, définissez retrait, conservation justifiée ou autre action, puis obtenez une preuve adaptée. Évitez de reproduire le contenu sensible dans le ticket créé pour demander sa suppression.

Lorsqu’un secret a été enregistré, l’équipe sécurité évalue aussi sa révocation ou son remplacement. Lorsqu’une divulgation ou un accès non autorisé à des données personnelles est établi, l’organisme examine les obligations des Art. 33–34, indépendamment du fait que l’erreur vient d’un outil de diagnostic. Une collecte excessive et une violation de sécurité ne sont pas des notions interchangeables. RGPD, Art. 4(12).

Ce qu’il faut retenir

  • Justifiez les champs à partir du besoin, avant de fixer leur durée.
  • Une référence peut éviter la copie du dossier sans devenir anonyme.
  • Vérifiez toutes les destinations, y compris les exceptions et alertes.
  • Le retour au niveau normal et le traitement des anciennes copies sont deux actions distinctes.

FAQ

Peut-on seulement masquer les colonnes dans le tableau de bord ?

Cela protège éventuellement l’affichage, mais ne réduit pas la collecte sous-jacente. Vérifiez stockage, exports, accès directs et autres destinataires avant de conclure que la donnée a disparu.

Faut-il effacer tous les journaux après un incident ?

Non. Préservez les éléments nécessaires à l’analyse dans un périmètre protégé et justifié. Cela ne dispense pas de supprimer les copies excessives qui n’ont pas de finalité établie.

Qui valide le dictionnaire des champs ?

L’équipe technique décrit leur utilité et leur circulation ; le responsable du traitement organise la décision avec les fonctions compétentes, dont le DPO lorsqu’il est désigné. La validation doit rester applicable lors des évolutions du logiciel.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →