IA ACT

Checklist d'auditabilité d'un système d'IA

L'auditabilité est la capacité d'un système d'IA à être contrôlé par un tiers. Elle ne se décrète pas : elle se construit, et se vérifie point par point.

Research Lab NoolyaPublié le 24 août 2026Mis à jour le 27 août 20269 min

L'auditabilité d'un système d'IA est sa capacité à être contrôlé par un tiers : reconstituer une décision, savoir sur quelles données le modèle a été entraîné, retrouver qui l'a validé et quand, et démontrer qu'un humain peut intervenir.

C'est la notion la plus contre-intuitive du sujet, parce qu'elle dissocie deux choses que l'on confond : un système peut fonctionner parfaitement et rester non conforme, si la preuve du contrôle fait défaut. Inversement, un système imparfait mais documenté, journalisé et supervisé se trouve en bien meilleure posture.

Cette checklist en vingt-quatre points couvre les six dimensions qu'un auditeur examinera. Elle sert autant à préparer un audit qu'à cadrer un projet avant sa mise en production.

1. Identification : sait-on de quoi on parle ?

Un système qu'on ne sait pas nommer précisément ne peut pas être audité.

Le système est inscrit au registre des cas d'usage, avec un identifiant stable.
Sa finalité est décrite en une phrase, en langage métier.
Le modèle sous-jacent est identifié par sa version exacte et datée, pas par un alias flottant.
Le fournisseur est nommé, avec le contrat de référence.
Un responsable métier est désigné nommément.

Le troisième point est celui qui manque le plus souvent. Une intégration qui référence un alias générique change de modèle sans que personne ne le décide, ce qui rend toute reconstitution impossible a posteriori.

2. Données : sait-on ce qui entre ?

Les sources de données mobilisées sont listées, avec leur propriétaire.
La présence de données personnelles est qualifiée, et la base légale identifiée.
La durée de conservation des entrées est définie et appliquée automatiquement.
Le traitement des données par le fournisseur est encadré contractuellement : conservation, entraînement, localisation.

Sur le dernier point, une clause générale ne suffit pas. Ce qui se vérifie est précis : les requêtes sont-elles conservées, combien de temps, servent-elles à l'entraînement, et existe-t-il une option contractuelle de retrait.

3. Décision : peut-on rejouer ce qui s'est passé ?

C'est le cœur de l'auditabilité, et l'endroit où la plupart des organisations découvrent leur retard.

Le prompt système est versionné hors du code applicatif, avec historique.
Les paramètres non par défaut sont documentés et versionnés.
Pour une décision donnée, on peut retrouver la version du modèle, le prompt et les documents mobilisés à cet instant.
Les sorties sont conservées, associées à leur entrée.

Le test qui tranche : prenez une décision produite il y a trois mois et essayez de la reconstituer. Si vous ne pouvez pas dire quelle version du prompt tournait ce jour-là, le système n'est pas auditable, quelle que soit la qualité de sa documentation.

4. Supervision humaine : est-elle réelle ou nominale ?

Les personnes chargées de la supervision sont identifiées.
Elles disposent de la compétence pour évaluer une sortie du système.
Elles disposent du temps — le volume de décisions à contrôler est compatible avec un examen réel.
Elles disposent de l'autorité de passer outre, et cette possibilité est documentée.
Les cas où un humain a contredit le système sont tracés.

Les trois conditions — compétence, temps, autorité — sont cumulatives. Un opérateur qui valide trois cents décisions par jour ne supervise pas, il tamponne, et un auditeur le verra dans les statistiques : un taux de contradiction proche de zéro est un signal, pas une performance.

Le dernier point est celui qu'on oublie et qui vaut le plus : tracer les désaccords humain-machine donne à la fois la preuve de la supervision et la matière pour améliorer le système.

5. Surveillance : voit-on les dérives ?

Un jeu d'évaluation permanent existe et tourne à intervalle régulier.
Les indicateurs suivis incluent le taux d'erreur, le taux de reprise et la latence.
Un seuil d'alerte est défini, avec un destinataire nommé.
Les incidents sont enregistrés dans un registre, avec leur résolution.
Les changements de version du modèle déclenchent une réévaluation avant bascule.

Sans jeu d'évaluation permanent, une dégradation silencieuse — un fournisseur qui modifie son modèle, un corpus documentaire qui vieillit — passe inaperçue jusqu'à ce qu'un utilisateur se plaigne. Ce qui arrive toujours trop tard.

6. Journaux : la preuve existe-t-elle, et tient-elle ?

Le système génère des journaux automatiques.
Ces journaux sont conservés au moins six mois, sauf disposition contraire.
Ils sont horodatés, intègres, et accessibles à qui doit les consulter.
Leur contenu en données personnelles est maîtrisé et sa durée de conservation décidée.
Un test de restitution a été effectué : on a réellement extrait un journal et vérifié qu'il était exploitable.

Le dernier point est le plus négligé. Beaucoup d'organisations journalisent sans jamais avoir tenté d'exploiter un journal. Le jour où il faut le faire sous pression, on découvre que le format est illisible, que la rétention était plus courte que prévu, ou que l'export est impossible.

Auditabilité, traçabilité, explicabilité : trois notions que l'on confond

Ces trois mots reviennent ensemble dans les comités et désignent des choses différentes. La confusion coûte cher : on répond à la mauvaise exigence.

Notion	Question à laquelle elle répond	Ce qu'elle exige concrètement
Traçabilité	Que s'est-il passé ?	Des journaux horodatés, conservés, non modifiables
Explicabilité	Pourquoi ce résultat-là ?	Une méthode qui rend la décision compréhensible pour son destinataire
Auditabilité	Un tiers peut-il le vérifier sans nous croire sur parole ?	Traçabilité et explicabilité et documentation et gouvernance nommée

L'auditabilité englobe les deux autres et y ajoute ce qu'elles ignorent : la capacité d'un examinateur externe à refaire le chemin sans dépendre de la bonne volonté de l'équipe. Un système parfaitement tracé mais dont les journaux ne sont lisibles que par son développeur n'est pas auditable.

C'est la raison pour laquelle un projet peut cocher « logs activés » et échouer à un audit : la trace existe, la preuve non.

Ce que l'AI Act exige, dimension par dimension

Les six dimensions de la checklist ne sortent pas de nulle part : elles suivent les obligations du règlement (UE) 2024/1689 pour les systèmes à haut risque. Le tableau ci-dessous fait le lien.

Dimension de la checklist	Base dans l'AI Act	Ce que le texte demande
Identification	Art. 11 et Annexe IV	Une documentation technique établie avant la mise sur le marché et tenue à jour
Données	Art. 10	Gouvernance des jeux de données : provenance, pertinence, biais examinés
Décision	Art. 12	Un enregistrement automatique des événements sur toute la durée de vie du système
Supervision humaine	Art. 14	Une supervision effective : la personne doit pouvoir comprendre, contredire et interrompre
Surveillance	Art. 72	Un plan de surveillance après commercialisation, actif et documenté
Journaux	Art. 19 et Art. 26	Conservation des journaux générés automatiquement, au moins six mois

Deux points méritent d'être soulignés, parce qu'ils sont systématiquement sous-estimés.

La supervision humaine de l'article 14 n'est pas une case à cocher. Le texte exige que la personne désignée puisse effectivement comprendre le fonctionnement du système, interpréter sa sortie, décider de ne pas l'utiliser et interrompre son fonctionnement. Un opérateur qui valide trois cents recommandations par jour sans capacité réelle d'arbitrage ne remplit pas cette condition, quel que soit l'organigramme.

La durée de conservation des journaux est un minimum, pas une cible. Six mois est le plancher réglementaire ; la durée utile est celle du cycle de contestation de la décision concernée. Un système de scoring dont les décisions peuvent être attaquées deux ans plus tard a besoin de journaux sur deux ans.

Référence : règlement (UE) 2024/1689, dit AI Act, entré en vigueur le 1er août 2024. Les obligations relatives aux systèmes à haut risque s'appliquent par paliers — vérifier le calendrier applicable à votre cas avant de vous engager sur une date.

Comment se servir de cette checklist ?

Elle n'est pas conçue pour être cochée à cent pour cent sur tous les systèmes. Le bon usage est proportionné :

Niveau du système	Points à couvrir	Fréquence de revue
Risque minimal	Sections 1 et 2	Annuelle
Risque limité	Sections 1, 2 et 6	Annuelle
Haut risque	Les six sections	Trimestrielle
En cours de qualification	Les six, en mode diagnostic	Avant décision

Un système à risque minimal qui coche les vingt-quatre points représente un effort mal placé. Un système à haut risque qui n'en coche que la moitié représente un risque réel.

Questions fréquentes

Combien de temps faut-il pour rendre un système auditable ? Pour un système existant et bien construit, quelques semaines : l'essentiel du travail consiste à documenter ce qui existe déjà et à mettre en place la journalisation manquante. Pour un système dont les prompts vivent dans le code et dont personne ne connaît la version du modèle, comptez plusieurs mois — et la difficulté est organisationnelle, pas technique.

L'auditabilité s'applique-t-elle aussi aux modèles open weight hébergés en interne ? Elle s'applique davantage. Héberger le modèle vous donne la maîtrise et vous transfère la charge de preuve : vous devenez responsable de la provenance des poids, de la configuration, de la journalisation et du versionnement. Un modèle open weight n'est pas plus auditable par nature ; il l'est si vous le rendez tel.

Un fournisseur peut-il garantir l'auditabilité à ma place ? Il en fournit une partie — documentation technique, journaux générés, notice d'utilisation — mais pas la vôtre. La supervision humaine, la qualité des données que vous injectez, le versionnement de vos prompts et la traçabilité de vos décisions vous appartiennent. Aucun contrat ne les délègue.

Faut-il un outil dédié pour tenir tout cela ? Non pour commencer. Un registre en tableur, des prompts dans un dépôt versionné et des journaux applicatifs correctement conservés couvrent l'essentiel pour une organisation de taille moyenne. L'outil devient utile quand le nombre de systèmes dépasse ce qu'une revue trimestrielle peut absorber manuellement.

Conclusion

L'auditabilité ne se décrète pas dans une politique : elle se construit dans les systèmes, point par point, et se vérifie par un test — reconstituer une décision passée.

C'est le seul contrôle qui ne trompe pas. Une organisation capable de rejouer une décision de l'an dernier est prête ; les autres ont un dossier documentaire, ce qui n'est pas la même chose.

Pour situer ce sujet dans une démarche complète, Noolya détaille l'audit de conformité IA et l'AI Act.

Pour aller plus loin

Sources principales