Comment prouver qu'une décision prise avec l'IA était justifiée ?

Ce que demande un auditeur

Lorsqu’un commissaire aux comptes, un régulateur ou un comité des risques ouvre le dossier d’une décision assistée par un système d’IA, il ne part pas d’une curiosité technique. Il part d’une obligation : pouvoir dire, mois plus tard, pourquoi ce résultat a été retenu, sur quelles données, selon quelle méthode, et sous quelle responsabilité humaine.

Les questions sont stables. Elles varient peu d’un secteur à l’autre, parce qu’elles découlent du droit de la preuve et des normes d’audit, pas d’un guide d’implémentation. L’auditeur veut d’abord les entrées : quels fichiers, quelles tables, quelles versions de référentiels ont alimenté le run. Il veut ensuite le traitement : modèle, paramètres, règles métier, seuils, éventuelles reprises manuelles. Il veut le validateur : nom, rôle, horodatage, et ce que cette personne a réellement vu avant de signer. Il veut enfin la reproductibilité : si l’on relance le même run, obtient-on le même livrable, ou un livrable dont l’écart est expliqué.

Ces quatre demandes ne sont pas un questionnaire optionnel. Elles sont le minimum pour qu’une décision soit opposable. Une sortie plausible, même correcte, ne suffit pas. Une capture d’écran de chat non plus. Un e-mail de validation sans le dossier joint non plus. L’auditeur n’évalue pas l’élégance du prompt. Il évalue si l’organisation peut défendre le résultat comme elle défendrait un calcul actuariel ou un arrêté comptable.

Dans les revues que nous observons, le point de friction n’est presque jamais « le modèle s’est trompé ». C’est « personne ne peut reconstituer le chemin ». Le modèle a tourné. Le livrable a circulé. Le comité a tranché. Six mois plus tard, les logs d’inférence ont tourné, le prompt a changé, le fichier source a été écrasé, et le validateur se souvient d’avoir « regardé ». Ce souvenir n’est pas une preuve.

La distinction utile est donc celle-ci : une justification narrative (on raconte ce qui a dû se passer) n’est pas un dossier de preuve (on montre ce qui s’est passé). L’audit accepte la seconde. Il tolère mal la première, surtout lorsque la décision a un effet financier, prudentiel ou contractuel.

Les quatre éléments du dossier

Le dossier minimal tient en quatre pièces. Chacune est nécessaire. Aucune ne se substitue aux autres.

Les sources. Chaque assertion du livrable doit pointer vers une entrée identifiable : document, ligne, agrégat, hypothèse. Le pointeur n’est pas un libellé du type « base commerciale ». C’est une référence versionnée : identifiant, date d’extraction, périmètre. Sans cela, on ne sait pas si le run a utilisé le référentiel de mars ou celui de juin, ni si une ligne exclue l’a été par règle ou par oubli. Le lineage, au sens opérationnel, est cette chaîne d’identifiants. Il n’est pas un schéma d’architecture. Il est le chemin consultable du livrable vers les données.

La logique appliquée. L’auditeur doit pouvoir lire le traitement sans interroger l’équipe qui l’a conçu. Modèle et version, paramètres, règles déterministes, seuils de confiance, éventuelles branches (« si le score est inférieur à x, renvoyer en revue »). Un résumé marketing du type « matching sémantique » ne qualifie pas. Ce qui qualifie, c’est la possibilité de dire : voici l’algorithme qui a produit ce score, voici la règle qui a écarté cette alternative, voici le seuil qui a classé le dossier en haute confiance. La logique n’a pas à être simple. Elle a à être déclarée et stable pour un run donné.

Le validateur. Le droit actuel ne reconnaît pas un système comme responsable. La personne qui a approuvé le résultat reste le signataire. Encore faut-il que cette approbation soit une action tracée, pas une absence d’objection. Le dossier enregistre l’identité, le rôle, l’horodatage, et l’état du dossier au moment de la signature. Si le validateur a signé sans accès aux sources, la chaîne est formellement complète et matériellement vide. La preuve de validation n’est pas la case cochée. C’est la démonstration que la personne pouvait juger.

Le rejeu. Reproduire l’exécution à l’identique, c’est relancer le run avec les mêmes entrées, les mêmes paramètres, le même modèle versionné, et comparer. Un écart n’est pas nécessairement une fraude. C’est un fait à documenter : donnée mise à jour, seed non fixé, dépendance externe. Sans rejeu, la conversation d’audit devient une reconstitution orale. Avec rejeu, elle devient une comparaison. C’est ce que l’auditeur sait faire.

Ces quatre éléments forment un tout. Des sources sans logique laissent un résultat orphelin. Une logique sans validateur laisse un calcul sans responsable. Un validateur sans rejeu laisse une signature sur un objet introuvable. Le dossier n’est pas une archive de fichiers. C’est la cohérence de ces quatre pièces pour une exécution donnée.

Pourquoi la reconstitution a posteriori échoue

Les organisations qui tentent de « mettre en conformité » un usage déjà en production découvrent le même plafond. On peut extraire des logs. On ne reconstitue pas un dossier de preuve.

Les raisons sont prosaïques. Les prompts évoluent sans versionnage. Les fichiers sources sont remplacés. Les identifiants de run n’existent pas, ou existent dans un outil que personne n’interroge. Les validations circulent dans des fils de messagerie, détachées du livrable. Les modèles sont mis à jour côté fournisseur sans que l’organisation ne fige la version utilisée. Le coût de reconstitution n’est pas un coût d’ingénierie ponctuel. C’est un coût d’enquête : retrouver les personnes, croiser les souvenirs, accepter les trous.

Même lorsque les logs d’API sont conservés, ils documentent l’appel, pas la décision. Un appel contient un prompt et une completion. Une décision contient un périmètre métier, des règles, des alternatives écartées, une revue humaine. Coller le JSON d’inférence dans un dossier d’audit ne répond pas à « pourquoi ce résultat a été retenu plutôt que l’autre ». Il répond à « quelle chaîne de tokens a été produite ». Ce n’est pas la même question.

Il y a ensuite le biais de reconstruction. Plus le délai s’allonge, plus l’équipe raconte le run tel qu’il aurait dû se dérouler, non tel qu’il s’est déroulé. Les exceptions oubliées disparaissent. Les fichiers intermédiaires aussi. Un auditeur expérimenté le sait. Il ne prend pas le récit pour une pièce. Il demande des artefacts horodatés, non révisables après coup.

C’est pourquoi la reconstitution a posteriori échoue même quand l’intention est bonne et le budget disponible. Ce qui n’a pas été saisi à l’exécution n’existe plus comme fait. Il existe comme hypothèse. L’audit traite les faits. Les hypothèses, il les note comme limites.

Le corollaire est opérationnel : chaque run sans dossier natif crée une dette de preuve. Cette dette n’apparaît pas dans le compte d’exploitation du projet. Elle apparaît le jour où quelqu’un demande le dossier. À cette date, le coût n’est plus un coût de plateforme. C’est un coût de crise, ou un coût de non-réponse.

Ce que change la preuve native

La preuve native consiste à produire les quatre éléments pendant l’exécution, comme un reçu, pas comme un chantier ultérieur. Le livrable et le dossier naissent ensemble. Rien de métier ne circule sans les sources, la logique, le statut de validation et l’identifiant de run qui permettra le rejeu.

Concrètement, cela change trois choses dans le rituel.

D’abord, le validateur n’approuve plus un texte isolé. Il approuve un objet qui porte déjà son Evidence Panel : extraits sourcés, scores, alternatives, statut. S’il refuse, le refus est un acte du dossier, pas un commentaire perdu. S’il accepte, la signature ferme une chaîne, elle n’ouvre pas une discussion sur ce qui a dû se passer.

Ensuite, le run devient une unité de mémoire. On ne parle plus « du modèle de classification » en général. On parle du run du 12 mars, 14 h 22, modèle v3.2, référentiel nomenclatures 2025-03, seuil de haute confiance 0,82, validé par telle personne. Cette unité est ce que l’on rejoue. Elle est ce que l’on exporte. Elle est ce que l’on oppose.

Enfin, le coût de l’audit change de nature. Préparer un dossier n’est plus une collecte. C’est un export. Le temps se mesure en minutes, pas en semaines de reconstitution. Ce n’est pas un argument d’efficacité interne seulement. C’est la condition pour que la décision reste utilisable en comité lorsque la question arrive, plutôt que d’être retirée « le temps de vérifier ».

La preuve native n’empêche pas l’erreur. Elle empêche l’indéfendable. Un run faux, documenté, peut être corrigé, capitalisé, rejoué. Un run plausible, sans dossier, ne peut qu’être raconté. Dans un environnement régulé, la différence n’est pas cosmétique. Elle décide si le résultat entre dans le rituel de décision, ou s’il reste un brouillon que personne ne voudra signer.