Auditer une réponse générée par une IA : les trois niveaux de contrôle
Vérifier d'où vient une réponse, si elle est exacte, et si on pourra le prouver dans six mois. Le troisième niveau est celui qui manque presque toujours.
Auditer une réponse générée par une IA consiste à vérifier trois choses : d'où elle vient, si elle est exacte, et si l'on peut le prouver plus tard. Les trois sont distinctes, et c'est la troisième qui manque presque toujours — celle qui transforme un contrôle ponctuel en preuve opposable.
La question se pose dès qu'une réponse produite par un modèle sort de l'écran de celui qui l'a demandée : quand elle part chez un client, alimente une décision, ou justifie un refus.
Les trois niveaux de contrôle
Niveau 1 — La traçabilité de la source. Sur quels documents la réponse s'appuie-t-elle ? Un assistant branché sur vos données doit pouvoir citer ses sources et permettre d'y remonter. Une réponse sans source vérifiable n'est pas auditable, quelle que soit sa qualité apparente.
Niveau 2 — L'exactitude du contenu. La réponse dit-elle vrai au regard de ces sources ? C'est le contrôle qu'on fait spontanément — et le seul, dans la plupart des organisations.
Niveau 3 — La reconstituabilité. Dans six mois, saura-t-on refaire le chemin ? Quel modèle, quelle version, quelle configuration, quels documents à cette date ? C'est ce niveau qui distingue une vérification d'un audit, et c'est celui qu'aucune relecture humaine ne produit après coup.
Pourquoi le troisième niveau change tout
Une relecture attentive attrape les erreurs du moment. Elle ne laisse aucune trace.
Six mois plus tard, quand la décision est contestée, la question n'est plus « la réponse était-elle juste » mais « qu'est-ce qui a été produit, à partir de quoi, et qui l'a validé ». Sans journal, la seule réponse disponible est un souvenir.
C'est exactement la logique de l'auditabilité au sens du règlement européen : un système peut fonctionner parfaitement et rester non conforme si la preuve du contrôle fait défaut. Le contrôle sans trace ne compte pas.
Ce qu'il faut journaliser
| Élément | Pourquoi | Fréquent ? |
|---|---|---|
| Horodatage et identité du demandeur | Rattacher la réponse à une décision | Souvent présent |
| Question exacte posée | Une reformulation change la réponse | Souvent absent |
| Version datée du modèle | Un alias flottant change de modèle sans prévenir | Presque toujours absent |
| Documents effectivement consultés | Reconstituer sans dépendre de l'état actuel de la base | Rare |
| Réponse brute, avant reprise humaine | Distinguer ce que le modèle a dit de ce qui a été envoyé | Rare |
| Décision de l'humain : validé, corrigé, rejeté | Mesurer la supervision, pas la supposer | Presque toujours absent |
Les trois lignes marquées sont celles qui font échouer les audits. La version du modèle en particulier : une intégration qui référence un alias générique change de modèle sans que personne ne le décide, et rend toute reconstitution impossible.
Les erreurs qu'un contrôle rate
La réponse plausible et fausse. C'est le mode d'échec principal : le texte a la même apparence qu'il soit juste ou faux. Aucune relecture rapide ne le détecte, parce qu'il n'y a rien à détecter dans la forme.
L'omission. Un modèle qui ne trouve pas une information ne dit pas toujours qu'elle manque — il répond avec ce qu'il a. C'est le mode d'erreur le plus dangereux dans un contexte réglementé, parce qu'il produit une réponse complète en apparence.
La dérive silencieuse. Le même prompt, quatre mois plus tard, sur une version différente du modèle, ne donne pas la même réponse. Sans jeu de cas rejoué régulièrement, personne ne s'en aperçoit avant qu'un utilisateur ne le signale.
La méthode qui tient
Un jeu d'évaluation. Une trentaine de questions réelles, avec les réponses attendues, rejouées à chaque changement de modèle, de configuration ou de source. C'est le seul dispositif qui détecte une dégradation avant les utilisateurs.
Une supervision proportionnée à l'enjeu. Tout relire n'est pas tenable ; ne rien relire n'est pas défendable. Le critère utile est la conséquence : ce qui sort de l'organisation ou fonde une décision se relit intégralement, le reste s'échantillonne.
Une trace de la décision humaine. Enregistrer que quelqu'un a validé — et non déduire d'un envoi qu'il y a eu validation. C'est la différence entre une supervision réelle et une supervision nominale, et c'est précisément ce qu'un auditeur regardera.
Questions fréquentes
Comment vérifier qu'une réponse d'IA est fiable ? En remontant aux sources qu'elle cite et en les lisant. Si l'assistant ne cite pas ses sources ou si les liens ne mènent nulle part, la réponse n'est pas vérifiable — et une réponse non vérifiable ne devrait pas sortir de l'écran de celui qui l'a obtenue.
Faut-il relire toutes les réponses générées ? Non, et vouloir le faire garantit qu'on ne le fera pas. Le critère est la conséquence : relecture intégrale pour ce qui engage l'organisation ou fonde une décision, échantillonnage pour le reste, avec une trace de ce qui a été échantillonné.
Que faut-il conserver pour prouver un contrôle ? Au minimum : la question posée, la version datée du modèle, les documents consultés, la réponse brute et la décision humaine. Sans la version du modèle et la décision humaine, la reconstitution est impossible — ce sont les deux éléments les plus souvent manquants.
Combien de temps conserver ces journaux ? Le règlement européen sur l'IA fixe un plancher de six mois pour les journaux générés automatiquement par les systèmes à haut risque. La durée utile est celle du cycle de contestation de la décision concernée : un système dont les décisions peuvent être attaquées deux ans plus tard a besoin de journaux sur deux ans.
