Publié le 15 septembre 2026 à 13:00 · Publication originale
Six mois plus tard, une décision est contestée.
L'équipe retrouve le résultat.
Mais peut-elle reconstruire ce qui l'a produit?
Le modèle a peut-être changé. Les données ont été actualisées. Une instruction interne modifiée. Un seuil de décision n'est plus le même.
Le résultat existe encore.
Son contexte a disparu.
C'est l'un des problèmes les moins visibles des systèmes automatisés: la traçabilité.
Dans un processus traditionnel, une décision importante laisse des traces. Version d'un contrat, signature, date, dossier présenté au comité, personne ayant approuvé.
Un système numérique complexe doit produire l'équivalent.
Pour chaque opération sensible, il peut être nécessaire de connaître la version du modèle, les données utilisées, l'instruction reçue, les outils consultés, les règles appliquées, l'heure d'exécution et l'intervention d'un humain.
Cette mémoire technique change la manière d'enquêter sur une erreur.
Supposons que le taux de refus d'un service augmente soudainement.
Sans historique détaillé, plusieurs explications restent possibles: nouveau modèle, données différentes, modification d'une règle, panne d'une source, changement du comportement des utilisateurs.
Avec des versions et des journaux d'exécution, l'équipe peut comparer l'avant et l'après.
Cette capacité devient importante lorsque les systèmes évoluent rapidement.
Un logiciel classique peut rester identique plusieurs mois.
Un service fondé sur des modèles peut changer parce que le fournisseur actualise un modèle, qu'une base documentaire évolue ou qu'une instruction est modifiée.
Deux réponses produites à trois semaines d'intervalle ne proviennent donc pas nécessairement du même système.
La gouvernance commence par quelque chose de très matériel: conserver assez de traces pour reconstituer une décision après qu'elle a été prise.
Sans cette mémoire, l'organisation connaît le résultat sans pouvoir expliquer son histoire.
ULTRA®
Une piste d'audit IA réellement forensique doit permettre de reconstruire une exécution bit par bit lorsque l'infrastructure le permet.
Chaque événement reçoit un identifiant de trace et transporte version du modèle, empreinte SHA-256 de l'instruction système, paramètres d'échantillonnage, références documentaires, appels d'outils et décision humaine.
Dans une architecture distribuée, OpenTelemetry permet de corréler traces, métriques et journaux entre orchestrateur, modèle, RAG et API.
L'intégrité peut être renforcée par stockage WORM, journaux en ajout uniquement et chaînage cryptographique: l'empreinte d'un événement dépend de celle du précédent. Une modification historique brise alors la chaîne.
Le niveau supérieur consiste à conserver provenance et artefacts versionnés afin de réaliser un "replay" de l'incident.
Attention cependant: température nulle ne garantit pas toujours une reproductibilité exacte sur une infrastructure d'inférence non déterministe.