Dix-huit mois après la décision, le courrier arrive. Le régulateur veut savoir pourquoi la ligne de crédit a été coupée, sur quels chiffres, et qui l’a validé. L’analyste est parti. L’éditeur a retiré le modèle. Le log contient la réponse que le système a donnée ce matin-là, et rien d’autre. La banque sait ce qui a été décidé. Elle ne peut pas montrer comment.
Ce que demande un régulateur
Un régulateur ne demande pas si la réponse avait des chances d’être juste. Il demande qui a agi, sur quelle base, et si on peut le démontrer. La probabilité qualifie des énoncés ; la responsabilité qualifie des actes.[1] Les déploiements qui traitent la journalisation comme une fonction de conformité confondent les deux, et s’en aperçoivent au moment d’être interrogés.
Les questions arrivent tard. Une institution prend des décisions dont les conséquences courent sur des décennies, mais en répond sur quelques années.[2] Ceux qui ont pris la décision sont partis avant que les conséquences n’arrivent, et celui qui hérite de la question n’hérite d’aucun contexte. La traçabilité fait le lien entre les deux. Une institution qui ne sait pas reconstituer pourquoi elle a agi ne peut pas en répondre.
On a beaucoup écrit sur les raisons de tracer une décision d’IA.[3] Nous nous en tenons à ce qu’une trace doit permettre à un régulateur de faire.
Pour les entités financières, c’est la loi. DORA leur impose de détecter, gérer, enregistrer et notifier les incidents liés aux TIC, et de gérer le risque lié aux prestataires TIC dont elles dépendent.[4] Un système qui propose ou prend des décisions touchant le grand livre est un système TIC, et l’entreprise qui l’exploite pour vous est un prestataire tiers. La trace d’audit est le point où les deux obligations se rejoignent.
Ce qu’une trace doit permettre
Quatre choses. Une trace qui en manque une n’est qu’un journal intime.
Nommer. Qui a validé l’action, et quand. Une décision sans nom n’est la décision de personne.[5]
Situer. Quelles données, telles qu’elles étaient à cet instant, et quelle règle. Pas la valeur actuelle du champ : la valeur qui a été lue.
Rejouer. Poser aujourd’hui la même question avec les mêmes entrées, et obtenir la même réponse. Une décision qu’on ne peut pas rejouer est une coïncidence horodatée.
Ordonner. La séquence des événements, figée sous une forme que personne ne peut réécrire : ni l’éditeur, ni l’administrateur, ni la personne dont le nom y figure.
Notre page entreprise le dit en une ligne : qui a validé quoi, sur quelles données, dans un ordre qui ne peut pas être réécrit.[6] C’est un engagement envers nos clients, et c’est aussi la norme qu’appliquera un régulateur.
Trois types de logs que nous refusons
Un log conservé par l’éditeur. Quand le contrat s’arrête, la trace s’arrête avec lui. Quand le régulateur demande, vous devez demander à l’éditeur, qui répond à son rythme. Une trace qu’il faut demander est une dépendance envers un tiers, et DORA la traite comme telle.[4:1] Monarch tourne dans votre infrastructure et Galahad n’héberge aucune de vos données : la trace est à vous dès le départ.[6:1]
Un log qui enregistre la réponse, pas le chemin. La plupart des logs listent des sorties. Ils disent ce que le système a répondu, mais pas quelles données, quelle règle et quel raisonnement ont produit la réponse.[5:1] Personne qui devra plus tard justifier une action ne peut s’appuyer sur une réponse sans son origine.
Un log qu’on ne peut pas rejouer. Si la même question peut rendre une réponse différente, le log enregistre ce qui s’est passé une fois, pas le comportement du système. Nous tenons que la même question, posée deux fois, doit rendre la même réponse, mot pour mot, et qu’une trace ne vaut que ce que vaut son rejeu.[5:2]
La traçabilité est une défense
Une organisation qui ne sait pas lire ses propres opérations ne peut pas les défendre.[7] Un fournisseur qui vous tient captif, une fraude qui dure depuis des années, un risque logé entre deux systèmes jamais reliés : chacun se cache là où aucune trace n’arrive. Une bonne trace n’est pas de la paperasse ajoutée au métier. Elle rend le métier lisible, d’abord pour lui-même, puis pour quiconque a le droit de demander.
L’Europe a écrit les règles en premier. Ce que le reste du monde exigera d’ici cinq ans, un éditeur européen peut le proposer dès aujourd’hui. L’auditabilité est un avantage concurrentiel, et elle se perd quand on la traite comme une corvée de conformité.[8]
Les questions à poser à un éditeur
Posez-les par écrit, avant la démonstration.
- Où vit la trace, et qui la détient le lendemain de la fin du contrat ?
- Pour toute décision passée, puis-je voir les données telles qu’elles étaient et la règle appliquée ?
- Puis-je rejouer cette décision aujourd’hui, avec les mêmes entrées, et obtenir la même réponse ?
- Quel nom figure sur la validation, et à quelle heure ?
- Quelqu’un, vous compris, peut-il modifier ou supprimer une entrée après coup ?
- Que voit le régulateur, et ai-je besoin de vous pour le lui montrer ?
Un éditeur qui répond aux six questions depuis votre réseau a construit une vraie trace d’audit.
Monarch tourne dans votre infrastructure et laisse une trace qui tient : qui a validé quoi, sur quelles données, dans un ordre qui ne peut pas être réécrit. Voyez-le sur vos données.
Algos AI, « Comprendre la traçabilité des décisions d’une IA : pourquoi et comment ? » : la traçabilité comme condition de la conformité, du contrôle humain et de l’explicabilité. Source ↩︎
Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA), applicable depuis le 17 janvier 2025 : gestion, classification et notification des incidents liés aux TIC ; gestion du risque lié aux prestataires tiers de services TIC. Source ↩︎ ↩︎
Machines de conséquence, thèse 11 : provenance, déterminisme, réversibilité, imputation. Le lire ↩︎ ↩︎ ↩︎