Traçabilité de bout en bout

COADF P-4 est publié en entier. Un identifiant est créé à la réception d'un document et voyage avec chaque étape de traitement, chaque évaluation de confiance, chaque décision humaine et la sortie publiée. La piste est en ajout seul, une seule requête reconstruit la chaîne, et la chaîne s'exporte en JSON pour quelqu'un qui n'a pas construit le système. Le schéma publié de la piste d'audit nomme les champs : trace_id, timestamp, event_type, actor, input, output, decision, source_hash et immutable.

Deux propriétés la portent. La continuité : chaque étape porte la même identité, à travers chaque frontière qu'elle franchit. La persistance : l'enregistrement de chaque étape subsiste, et personne ne peut le modifier pour que la réponse paraisse meilleure plus tard.

La question à laquelle P-4 répond arrive tard et de l'extérieur. Des mois après la publication, quelqu'un demande d'où vient une valeur, ce qui l'a lue et qui l'a examinée. La réponse doit pouvoir être reconstruite par une personne qui n'a pas construit le système, à partir d'enregistrements que personne n'a pu réécrire entre-temps.

Une trace distribuée n'est pas une piste d'audit métier

C'est la distinction que la plupart des mises en œuvre brouillent, parce que les outils se ressemblent : tous deux ont un identifiant, tous deux traversent des services, tous deux montrent des étapes dans l'ordre. Ils répondent à des questions différentes et font des promesses différentes.

La spécification W3C Trace Context définit l'en-tête traceparent, et les SDK OpenTelemetry propagent tracecontext et baggage par défaut. Cette identité vaut pour une exécution. Dans OpenTelemetry, une trace qui n'est pas échantillonnée n'est pas exportée, et le processeur de filtrage du Collector supprime la télémétrie qui satisfait une condition. Ces deux comportements sont corrects pour le diagnostic et disqualifiants pour la preuve.

Les deux se corrèlent : enregistrer le trace_id d'audit comme attribut sur chaque span, et l'identifiant de la trace distribuée dans les journaux. Aucun des deux ne doit devenir l'autre. Une seule transaction métier s'étend couramment sur plusieurs traces distribuées : une requête de réception, un job de traitement asynchrone, une décision prise des jours plus tard, la sortie.

La corrélation copie l'identifiant d'audit dans la télémétrie, et la télémétrie franchit d'autres frontières : des exportateurs, des fournisseurs, des règles d'accès et une rétention généralement plus lâches que celles du stockage d'audit. Il faut qualifier l'identifiant avant qu'il ne sorte : une référence opaque, jamais une donnée personnelle ni un secret. Là où l'identifiant d'audit porte un sens propre, la corrélation passe par une référence distincte et non sensible.

Créer une seule fois, à la réception

L'identifiant est créé là où la transaction entre, et nulle part ailleurs. Chaque composant ultérieur l'exige et aucun n'en génère. Un identifiant manquant est une erreur, jamais une raison d'en créer un nouveau, et une valeur par défaut dans un modèle de message est la façon la plus courante d'enfreindre cette règle sans que personne ne le remarque.

Le porter explicitement à travers chaque frontière

• Dans le processus : un argument de fonction ou le contexte de la requête.
• Entre services : un champ du contrat de requête ou de message, là où un schéma peut l'exiger.
• Dans le travail planifié : un argument du job.
• Au repos : une colonne sur chaque ligne stockée.

Les bibliothèques de propagation portent d'elles-mêmes le contexte d'exécution. L'identité d'audit fait partie du contrat de l'application et a sa place dans la charge utile.

Persister, en ajout seul

Plusieurs réalisations sont valables, et elles se combinent :

• Une persistance en insertion seule. Le dépôt offre l'ajout et la lecture, et rien d'autre.
• Les privilèges de base de données. Le rôle de l'application a INSERT et SELECT sur la piste, et ni UPDATE, ni DELETE, ni TRUNCATE.
• Des triggers qui refusent les réécritures, en défense en profondeur pour les sessions qui détiennent des droits plus larges, avec un trigger de niveau instruction pour TRUNCATE, parce que dans PostgreSQL TRUNCATE ne déclenche pas les triggers ON DELETE.
• Un modèle d'événements immuable, dans lequel une correction est un nouvel événement qui en remplace un antérieur.
• Une convention de remplacement. La valeur courante d'un attribut est sa dernière entrée ; l'historique, c'est l'ensemble de ses entrées.

L'event sourcing est une façon d'obtenir un historique en ajout seul, et pas la seule ; voir la note technique.

Écrire l'entrée avec le changement

Enregistrer l'entrée d'audit dans la même transaction de base de données que le changement d'état qu'elle décrit, ou via un outbox transactionnel, afin que l'un ne puisse pas exister sans l'autre.

Rendre les relances idempotentes

Horodater l'étape au moment où elle s'exécute, et renvoyer la même entrée lors d'une relance. Donner aux entrées une clé unique naturelle, pour qu'une écriture répétée soit absorbée plutôt que dupliquée. Dans PostgreSQL, ON CONFLICT DO NOTHING ignore une ligne en conflit avec une contrainte ou un index unique au lieu de lever une erreur, et c'est précisément pourquoi cela ne peut pas être toute la réponse : un conflit n'est pas toujours une relance. La même clé avec un contenu différent, c'est un second processus qui écrit, ou un bug. Comparer l'entrée stockée avant de qualifier l'écriture de relance, et échouer bruyamment quand elle diffère.

Reconstruire en une requête, exporter en JSON

Si la reconstruction a besoin de quelqu'un qui connaît le système, P-4 ne tient pas. Ordonner par horodatage, et dire ce que cet ordre ne tranche pas : les entrées de même horodatage ne sont ordonnées par aucun des champs publiés.

Ce qu'un trigger n'apporte pas

Les privilèges et les triggers sont des contrôles situés à l'intérieur de la frontière de confiance de la base de données elle-même. Dans PostgreSQL, un superutilisateur contourne toutes les vérifications de permissions, et le propriétaire de la table peut désactiver ses triggers. Une table en ajout seul est donc un contrôle fort face à l'application et un contrôle faible face à ses administrateurs. La détectabilité des altérations face à des initiés privilégiés exige un contrôle extérieur à la base de données, et c'est une propriété distincte de la persistance en ajout seul. Aucune des deux n'est, en soi, une affirmation juridique sur la preuve.

• Event sourcing. Le stockage d'événements est l'historique, et l'état en est dérivé. De fortes propriétés d'audit, et un engagement architectural important.
• Change data capture. Les changements de lignes lus dans le journal de la base de données. Utile pour la réplication ; cela enregistre ce qui a changé, pas qui a décidé ni pourquoi, et ne remplace donc pas les entrées d'audit métier.
• Un stockage objet à écriture unique pour les chaînes exportées, là où la rétention doit survivre à la base de données.
• Des registres ou des stockages à détection d'altération, là où l'altération par des initiés fait partie du modèle de menace.

• Le pattern ne décide pas quelles étapes sont pertinentes pour une réglementation particulière ou un produit particulier.
• La persistance en ajout seul n'est pas une détectabilité des altérations, et aucune des deux n'est une conclusion juridique sur la preuve.
• Il ne définit pas de durées de rétention.
• Il repose sur le respect du contrat par chaque composant. Un composant qui ne le respecte pas est découvert par le test de reconstruction, pas empêché par lui.