Une évaluation IA ne vaut que si elle est auditable

Beaucoup de programmes IA disposent désormais de dashboards, de scores et de rapports de red team. C'est utile, mais ce n'est pas encore de l'auditabilité. Une évaluation IA auditable permet à quelqu'un qui n'a pas lancé le test de reconstruire la conclusion : quel système a été évalué, ce qui avait changé, quelles preuves ont été utilisées, ce qui a échoué, qui a accepté le risque restant et si la conclusion tient encore en production.

L'auditabilité commence là où le score s'arrête

Une scorecard peut dire qu'un système a passé 42 contrôles sur 50. Elle ne prouve pas, à elle seule, que le bon système a été testé, que la preuve vient du bon environnement, que les scénarios échoués ont été conservés, ni que la méthode de scoring était assez fiable pour la décision à prendre.

Cette distinction compte parce que les systèmes IA changent vite. Une modification de prompt, une réindexation RAG, un changement de fournisseur de modèle, une nouvelle permission d'outil, un connecteur d'observabilité ou une exception de politique peuvent modifier la surface de risque sans changer le nom du système. Si la preuve ne capture pas ces changements, la trace d'audit décrit un ancien système, pas celui qui tourne aujourd'hui.

La question d'audit n'est pas seulement de savoir si l'IA a réussi. Elle est de savoir si l'organisation peut prouver ce qui a réussi, quand, pourquoi et dans quelles conditions.

L'objet de l'audit, c'est le système, pas le modèle

Un système IA en production ne se résume pas à un endpoint de modèle. Il comprend des instructions, des datasets, des sources de retrieval, des contrôles d'accès, des outils, des connecteurs, des règles de revue humaine, du monitoring, des plans de repli, des responsables et des fournisseurs. Une évaluation qui ignore ce contexte peut rester intéressante techniquement, mais elle produit une preuve faible pour la gouvernance.

Pour un assistant de support client, l'objet d'audit n'est pas seulement le LLM. C'est aussi le corpus de politiques, le modèle de permissions, les templates de réponse, la configuration de logs, la règle d'escalade, le connecteur CRM et le processus de correction des mauvaises réponses. Pour un agent, il faut ajouter le catalogue d'outils et la règle d'approbation de chaque action. Pour un modèle de scoring, il faut la lignée des données, le pipeline de features, la politique de seuils et le processus d'override humain.

Un enregistrement défendable a cinq couches

L'unité minimale utile n'est pas un PDF. C'est une chaîne qui relie système, obligation, contrôle, run, résultat et preuve. Sans cette chaîne, les équipes finissent avec des captures d'écran et des narratifs reconstruits après coup.

• Contexte système : responsable, finalité, utilisateurs, données, modèle, fournisseur, outils, environnement et version au moment du run.
• Contrôles applicables : obligations, politiques internes, dimensions de risque, critères, seuils et raison pour laquelle chaque contrôle s'applique.
• Méthode d'évaluation : source des tests, règle d'échantillonnage, scorer, modèle juge, version du prompt ou de la grille, outils déterministes et règles de revue humaine.
• Preuves : scénarios, traces de production, sources récupérées, appels d'outils, findings, logs, captures seulement si nécessaire, et observations brutes derrière chaque verdict.
• Trace de décision : contrôles échoués, preuves insuffisantes, remédiation, risque accepté, personne accountable, date d'expiration et prochain déclencheur de revue.

C'est pour cela que l'auditabilité doit vivre dans le workflow d'évaluation, pas après. Si le run ne conserve pas le contexte, la méthode et les preuves pendant son exécution, l'équipe doit reconstituer le dossier plus tard à partir de logs partiels et de mémoire.

Tests synthétiques et traces de production ne répondent pas à la même question

Les évaluations offline sont contrôlées. Elles permettent de tester l'injection de prompt, les contenus dangereux, les fuites de données, l'ancrage, les variantes de fairness et les cas limites connus avant une mise en ligne. Elles répondent bien à la question : ce système peut-il échouer si on le pousse d'une manière précise ?

Les traces de production répondent à une autre question. Elles montrent ce que de vrais utilisateurs, de vrais documents, de vrais outils et une vraie latence font au système. Elles permettent de demander : le système s'est-il comporté correctement en usage réel, et les contrôles tenaient-ils encore après déploiement ?

Un programme auditable a besoin des deux. Le run offline doit conserver les scénarios générés et leurs métadonnées. Le run online doit conserver les sessions échantillonnées, horodatages, identifiants de traces source, appels d'outils, documents récupérés et règle d'échantillonnage. Sinon l'organisation ne peut pas expliquer pourquoi un bon score de pré-production a, ou n'a pas, prédit le comportement en production.

Un log ne devient une preuve que s'il est relié à un contrôle

L'AI Act rend les logs et le suivi du cycle de vie très concrets pour les systèmes à haut risque. L'article 12 impose des capacités d'enregistrement automatique. L'article 19 impose aux fournisseurs de conserver les logs générés qui sont sous leur contrôle pendant une durée appropriée. L'article 72 impose un monitoring post-commercialisation, et l'article 73 crée des obligations de déclaration des incidents graves.

Mais les logs seuls ne suffisent pas. Un million de lignes de traces ne disent pas à un auditeur quelle obligation a été testée, quel contrôle a échoué, si la preuve vient de staging ou de production, ni si le problème a été corrigé. L'auditabilité commence quand les logs sont attachés au contrôle qu'ils soutiennent.

• Preuve faible : un dashboard qui montre tokens, latence et taux d'erreur.
• Meilleure preuve : une session rejouable qui montre prompt, source récupérée, appel d'outil, réponse et horodatage.
• Preuve audit-ready : la même session reliée à un contrôle, un critère, un verdict, une version système, une décision de remédiation et un responsable.

Le juge fait partie de la méthode

Beaucoup d'évaluations IA utilisent des LLM comme juges. C'est pratique, notamment pour les réponses ancrées, le raisonnement réglementaire et les comportements conversationnels. Mais c'est aussi une dépendance méthodologique. Le juge peut être sensible au wording du prompt, à l'ordre des réponses, à la verbosité, à la politique du fournisseur et à ses propres préférences.

Un rapport sérieux doit donc dire quelles parties du verdict sont déterministes, statistiques, issues de machine learning, médiées par LLM ou revues par un humain. Il doit conserver la configuration du juge et expliquer si un finding déterministe peut prendre le dessus sur un jugement LLM. Sinon, un contrôle échoué et une préférence du juge peuvent se ressembler dans le score final.

Un score ponctuel doit montrer son incertitude

Un score d'évaluation est une estimation, pas une propriété stable du système. Dix scénarios synthétiques peuvent révéler une défaillance grave, mais ils ne prouvent pas que le système est sûr avec un niveau d'assurance d'audit. Un taux de réussite de 100 % sur trois tests ne doit pas être lu comme une certification.

Pour être auditable, le rapport doit exposer la taille d'échantillon, la stratégie d'échantillonnage, le taux de réussite, l'intervalle de confiance quand il s'applique, les critères sous-dimensionnés et le niveau d'assurance. Certains contrôles peuvent être exhaustifs, par exemple scanner toutes les tables connectées pour une classe de données. D'autres sont échantillonnés, comme les conversations de production ou les prompts adversariaux. Le rapport doit dire clairement de quel cas il s'agit.

La readiness n'est pas une approbation

Une plateforme de gouvernance IA utile peut synthétiser la readiness de production, mais elle ne doit pas prétendre approuver la mise en production à la place de l'organisation. La décision dépend du contexte système, des obligations applicables, de la politique de risque du client, des contrôles échoués, des preuves manquantes, de la couverture de monitoring et du risque résiduel accepté.

Le bon objet de décision est un dossier, pas une note unique. Il doit montrer les blockers, les contrôles critiques échoués, les preuves insuffisantes, les risques acceptés, la dernière date d'évaluation, la couverture de monitoring, le responsable et les preuves exportables. Le comité de risque peut alors décider si le risque restant est acceptable, si une remédiation est nécessaire ou si le système doit rester hors production.

Par où commencer

Les équipes n'ont pas besoin d'une archive d'audit parfaite dès le premier jour. Elles doivent d'abord arrêter de perdre les preuves qui rendent leurs conclusions défendables. Commencez par les systèmes dont l'impact métier est le plus élevé : assistants exposés aux clients, agents connectés à des outils, systèmes qui touchent des données régulées, modèles qui soutiennent l'éligibilité, la fraude, la conformité ou des décisions financières.

• Inventorier le système : finalité, responsable, données, modèle, outils, fournisseurs, environnements et plan de repli.
• Relier contrôles et preuves : obligation vers contrôle, contrôle vers critère, critère vers run, run vers trace ou artefact.
• Versionner la méthode : critères, prompts, rubriques, seuils, modèle juge, outils déterministes et paramètres d'échantillonnage.
• Séparer les statuts : passed, failed, insufficient evidence, not evaluated et accepted risk ne doivent jamais disparaître dans un score unique.
• Garder des enregistrements rejouables : scénarios, traces de production, appels d'outils, documents récupérés et findings doivent rester inspectables après le run.
• Exporter pour humains et systèmes : PDF pour les comités, CSV pour les matrices de contrôles, JSON ou API pour GRC, SIEM et outils de workflow.

Les organisations qui réussiront ne seront pas celles qui ont la politique IA la plus longue. Ce seront celles qui peuvent répondre vite à une question étroite : pour ce système, dans cette version, quelles preuves montrent que les contrôles ont fonctionné, et qu'avons-nous fait quand ce n'était pas le cas ?

Références

• Règlement (UE) 2024/1689 (AI Act), articles 11, 12, 19, 72 et 73, annexe IV, eur-lex.europa.eu et ai-act-service-desk.ec.europa.eu.
• NIST, Artificial Intelligence Risk Management Framework 1.0, Govern, Map, Measure and Manage, nist.gov/itl/ai-risk-management-framework.
• NIST AI 800-3, Expanding the AI Evaluation Toolbox with Statistical Models, février 2026.
• NIST AI 800-4, Challenges to the Monitoring of Deployed AI Systems, mars 2026.
• ISO/IEC 42001:2023, système de management de l'intelligence artificielle, iso.org/standard/42001.
• OpenTelemetry, conventions sémantiques Generative AI et ressources sur l'observabilité des agents IA, opentelemetry.io.
• Anthropic, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, 2024.
• RAND, Judge Reliability Harness: Stress Testing the Reliability of LLM Judges, 2026.
• W3C, PROV-DM: The PROV Data Model, w3.org/TR/prov-dm.
• IETF Internet-Draft, Verifiable AI Provenance Framework, draft-kamimura-vap-framework-00, 2026.