Pistes d'audit : pas un data lake

Dans la partie 1, nous avons vu ce qui transforme un enregistrement en preuve : l’exhaustivité, l’altération détectable, et un temps attesté par quelqu’un d’autre que vous. J’ai conclu cet article par une mise en garde, et j’aimerais reprendre le fil précisément là.

Suivez ces conseils à la lettre et vous risquez de construire quelque chose de discrètement dangereux : un stockage qui couvre chaque client et chaque modification, conservé pendant des années, et conçu pour que rien ne puisse jamais y être modifié ou supprimé. Dans de nombreuses organisations, il devient la plus grande concentration de données personnelles qu’elles détiennent. Un passif en matière de protection des données d’un côté, et une cible très attractive pour les attaquants de l’autre.

Ce qui est rassurant, c’est que rien de tout cela n’est inévitable. Une piste d’audit existe pour prouver ce qui s’est passé, pas pour conserver une seconde copie de tout ce qui a été touché en chemin. La discipline qui sépare ces deux objectifs est la divulgation minimale, et elle s’applique à trois moments de la vie d’un enregistrement : quand il est écrit, au fil du temps, et quand quelqu’un le lit.

Deux questions se trouvent juste à côté de celle-ci, et chacune mérite plus qu’un paragraphe : qui a le droit d’écrire dans la piste, et qui a le droit de l’ouvrir. Elles ont leurs propres articles plus loin dans la série. Ici, nous nous concentrons sur ce que contient la piste et sur ce qu’elle révèle.

Un artefact, deux devoirs

Le droit de la protection des données place la piste d’audit dans une position assez inhabituelle. Le principe de responsabilité du RGPD demande à une organisation d’être en mesure de démontrer qu’elle traite correctement les données personnelles, et la piste d’audit est très souvent sa principale pièce justificative. Pourtant, la piste est elle-même un traitement de données personnelles, soumis aux principes mêmes qu’elle aide à démontrer.

Pour le dire simplement, elle doit prouver la conformité tout en étant conforme.

L’Europe est loin d’être seule dans ce cas. Le UK GDPR, la loi fédérale suisse révisée sur la protection des données, la LGPD brésilienne, le CCPA californien tel que modifié par le CPRA, la PIPEDA canadienne, l’APPI japonaise, la PDPA singapourienne et le Digital Personal Data Protection Act indien ont chacun leur vocabulaire et leurs nuances, mais ils reposent sur une famille d’idées similaire. Une piste qui respecte ces idées voyage bien d’une juridiction à l’autre.

La bonne nouvelle, c’est que chaque principe se traduit par un contrôle de conception concret.

Le RGPD exige aussi la protection des données dès la conception et par défaut. Ces contrôles ont leur place dans la première version de l’architecture, pas dans le plan de remédiation qui suit le premier constat d’audit. Trois d’entre eux sont ceux sur lesquels les équipes d’ingénierie trébuchent le plus souvent, et ce sont ceux que j’aimerais parcourir avec vous : la minimisation, la limitation de la conservation, et la confidentialité à la lecture.

Écrire moins : des références, pas des payloads

La minimisation à l’écriture commence par une question simple : quel est le strict minimum que cet enregistrement doit contenir pour prouver l’événement plus tard ? La réponse honnête est généralement bien inférieure au payload que le service a en main à ce moment-là.

Pour rendre cela concret, voici à quoi pourrait ressembler un événement minimal pour un changement de bénéficiaire de paiement :

{
  "seq": 1048213,
  "prev": "sha256:9f1c…",
  "at": "2026-07-14T14:02:11.482Z",
  "actor": { "type": "human", "id": "emp-7Q2K", "auth": "fido2" },
  "action": "beneficiary.update",
  "subject": "cust-p:8d41a7",
  "object": "acct-p:1f0c93",
  "fields": ["iban", "holder_name"],
  "before": "hmac:3a7e…",
  "after": "hmac:c019…",
  "purpose": "customer-request",
  "sig": "ed25519:…"
}

Il nous dit qui a modifié quel bénéficiaire, quand, comment l’acteur s’est authentifié, et dans quel but. Il ne contient ni IBAN ni nom. Si la modification venait à être contestée, les valeurs d’origine pourraient être vérifiées à l’aide des hachages à clé, sans que la piste les ait stockées.

Remarquez aussi que purpose est un code issu d’une liste contrôlée, pas une phrase. Les champs en texte libre sont la porte par laquelle les données personnelles reviennent. Un conseiller bien intentionné qui tape « Mme Martin a appelé, elle déménage à Lyon le mois prochain » peut défaire, en une seule ligne, tout le soin apporté au reste du schéma.

Un hachage n’est pas un déguisement

Un simple SHA-256 d’un IBAN ou d’une date de naissance protège bien moins qu’il n’y paraît. Ces valeurs ont une faible entropie, donc un attaquant peut simplement hacher tous les candidats plausibles et chercher une correspondance. Un hachage à clé (HMAC), dont la clé vit dans un système de gestion des clés séparé, ferme cette porte : le stockage d’audit seul ne peut plus être inversé.

Il faut être clair sur ce que cela apporte juridiquement. Les identifiants pseudonymes et les hachages à clé relèvent de la pseudonymisation, pas de l’anonymisation. Les données restent des données personnelles, parce qu’elles peuvent être reliées à nouveau par quiconque détient la clé. Cela vaut tout de même largement la peine, puisque le RGPD cite explicitement la pseudonymisation et le chiffrement parmi les mesures de sécurité qu’il attend. Cela ne fait simplement pas sortir la piste du périmètre.

Laisser le temps faire son œuvre : immuabilité contre effacement

Un log append-only à altération détectable et le droit à l’effacement semblent inconciliables à première vue. En pratique, trois mécanismes résolvent l’essentiel de la tension.

1. La conservation légale passe en premier. Lorsque des enregistrements doivent être conservés pour satisfaire une obligation légale, la conservation des documents en matière de lutte contre le blanchiment étant l’exemple classique, le droit à l’effacement s’efface tant que cette obligation court. L’immuabilité pendant la période de rétention est donc licite. L’obligation doit cependant être nommée, flux par flux, avec sa propre durée et son propre point de départ (fin de la relation client, date de la transaction, clôture d’un dossier). « Nous gardons tout pendant dix ans, au cas où » n’est pas une politique de conservation ; c’est son absence.

2. La limitation de la conservation s’applique avec des clés, pas des suppressions. Les données personnelles de la piste sont chiffrées avec des clés par personne détenues dans un KMS ou un HSM, en dehors du stockage d’audit. Quand la rétention prend fin, la clé est détruite. Le texte chiffré reste exactement où il est, et la chaîne de hachage reste valide parce qu’elle a été calculée sur le texte chiffré, mais le contenu est désormais définitivement illisible. C’est le crypto-shredding.

3. Les pseudonymes sont déliés de la même façon. La table qui associe les identifiants pseudonymes aux vrais clients vit en dehors de la piste. Supprimez l’entrée d’une personne dans cette table, détruisez la clé HMAC utilisée pour ses valeurs, et ses événements deviennent de fait anonymes tout en restant vérifiables en tant que séquence. Les valeurs contestées ne peuvent plus être vérifiées non plus, et c’est précisément le but : toute fenêtre de contestation devrait se situer confortablement à l’intérieur de la période de rétention.

Le crypto-shredding a un effet secondaire appréciable souvent négligé : il atteint aussi les sauvegardes et les réplicas. Chaque copie de la piste, où qu’elle se trouve, devient illisible pour cette personne dès que la clé disparaît. Supprimer les enregistrements un par un à travers le stockage WORM, les réplicas et les archives aurait de toute façon été impossible.

Il y a bien sûr un prix, et c’est la gestion des clés. Des clés par personne signifient des millions de clés, une hiérarchie dans laquelle elles sont enveloppées par une poignée de clés maîtresses dans le HSM, et un processus de destruction des clés gouverné aussi rigoureusement que n’importe quel accès privilégié. Une perte de clé accidentelle est tout aussi irréversible qu’une destruction délibérée. Il est également sage de convenir avec votre DPO et votre service juridique de la façon dont le crypto-shredding est décrit dans votre registre des traitements : le mécanisme est solide, et c’est la formulation que liront les auditeurs.

Montrer moins : la divulgation minimale à la lecture

Minimiser ce qui est écrit, c’est la moitié du travail. L’autre moitié consiste à minimiser ce que voit chaque lecteur. Être autorisé à ouvrir la piste ne signifie pas avoir droit à tout son contenu.

Masqué par défaut, révélé à la demande

Chaque vue commence masquée : pseudonymes, hachages à clé, noms de champs, aucune valeur en clair. Quand un dossier l’exige réellement, le lecteur révèle un champ d’un enregistrement, en indiquant le dossier et la raison. La valeur est déchiffrée juste à temps, et la révélation elle-même est écrite dans la piste.

La divulgation devient progressive, délibérée et traçable, tout le contraire d’un dump complet à la première requête. Elle donne aussi aux relecteurs un signal précis : quelqu’un qui révèle quatre cents champs sur un dossier concernant un seul client se remarque immédiatement.

Des requêtes liées à une finalité

L’interface de requête refuse tout simplement toute demande qui ne porte pas de finalité. Chaque finalité correspond à un périmètre : une enquête ouvre les événements d’une personne sur une période définie ; un échantillon d’audit interne ouvre un ensemble aléatoire d’événements avec les acteurs visibles et les personnes masquées. Il n’existe pas d’endpoint « tout sélectionner », et les exports sont filigranés, limités dans le temps et enregistrés.

Qui peut ouvrir la piste en premier lieu, comment cet accès est demandé, approuvé et limité dans le temps, et ce qui se passe en cas d’urgence, est une question de gouvernance à part entière.

Quand la personne concernée demande

Dans l’arrêt Pankki S (C-579/21), rendu en juin 2023, la Cour de justice de l’UE a examiné exactement cette situation. Un employé de banque, également client de cette banque, a demandé qui avait consulté ses données client, quand et pourquoi. La Cour a jugé que son droit d’accès couvrait les dates et finalités de ces consultations. L’identité des employés concernés n’est, en principe, pas due, sauf si elle est indispensable pour lui permettre d’exercer effectivement ses droits, et seulement après mise en balance avec les droits des employés eux-mêmes.

La conséquence pour l’ingénierie est directe. Si votre piste n’enregistre pas la finalité de chaque lecture, vous ne pouvez pas répondre à une demande d’accès légitime. Si elle ne peut pas séparer les acteurs des métadonnées d’accès, vous ne pouvez pas répondre sans divulguer excessivement vos propres collègues. La divulgation minimale n’est donc pas seulement une restriction imposée aux lecteurs ; c’est une capacité que vous devez construire pour remplir vos obligations.

Une nuance mérite attention. Le droit national peut restreindre les droits d’accès dans des situations spécifiques, par exemple pendant une enquête anti-blanchiment, où alerter la personne concernée est une infraction en soi. La piste devrait permettre au délégué à la protection des données d’appliquer ces restrictions au cas par cas, plutôt que d’imposer un choix entre tout et rien.

Ce qui change

Une piste d’audit bien conçue prouve qui a fait quoi, quand et pourquoi, sans devenir une seconde copie des données qu’elle protège. Minimisez à l’écriture avec des références et des hachages à clé. Appliquez la limitation de la conservation avec des clés plutôt que des suppressions. Divulguez à la lecture un champ, une finalité et un dossier à la fois.

Si vous voulez un point de départ pour votre prochaine revue de conception, ces questions font généralement apparaître les lacunes rapidement :

• Un champ de nos événements pourrait-il identifier un client sans une clé détenue ailleurs ?
• Existe-t-il un champ en texte libre quelque part dans le schéma ?
• Pour chaque flux, pouvons-nous nommer l’obligation qui justifie sa conservation, et pour combien de temps ?
• Si la clé d’une personne était détruite aujourd’hui, chaque réplica et chaque sauvegarde suivraient-ils ?
• Pouvons-nous répondre à une demande d’accès avec les dates et les finalités, sans exposer notre propre personnel ?
• Existe-t-il un chemin de requête qui n’exige pas de finalité ?

Ainsi conçue, la piste d’audit cesse d’être le data lake auquel personne n’ose toucher. Elle devient exactement ce que demande le principe de responsabilité : une preuve sereine et vérifiable que l’organisation traite les données personnelles comme elle dit le faire.

Nous disposons maintenant de deux des ingrédients : les propriétés probantes de la partie 1 et la discipline de divulgation de cet article. Avant de les assembler, une question demeure : qui écrit réellement les enregistrements ? La partie 3 applique la séparation des tâches à la preuve elle-même.