Auditabilité d'un système d'IA : ce que vous devez pouvoir prouver, et comment

Le mot circule dans les appels d'offres et les questionnaires de conformité sans définition partagée. Les éditeurs y mettent leurs journaux d'administration, les juristes la documentation technique, les data scientists la reproductibilité d'un modèle. Les trois ont raison, et aucun ne suffit seul.

Si vous cherchez la mission qui vérifie votre situation au regard des textes, notre page audit de conformité IA décrit le périmètre et le livrable. Cet article traite du fond : ce qu'est l'auditabilité, ce qui est exigé, et comment la construire.

Auditabilité : une définition opérationnelle

Un système d'IA est auditable quand quatre questions trouvent une réponse documentée, pour n'importe quelle sortie produite au cours des six derniers mois : quel système et quelle version ont produit cette sortie ; à partir de quelles données d'entrée et de quels réglages, prompt système compris ; quelle personne a vu la sortie, l'a validée, modifiée ou écartée ; sur quelle base ce système a été autorisé dans l'organisation, par qui, et avec quelles limites.

Le test le plus simple tient en une phrase : prenez un courrier, un score ou un résumé produit avec l'IA il y a un mois, et reconstituez-le. Si vous ne retrouvez ni la version du modèle, ni le prompt, ni la personne qui a validé, le système n'est pas auditable, quelle que soit la qualité de sa documentation générale.

L'auditabilité se distingue de l'explicabilité, qui porte sur la capacité à expliquer pourquoi un modèle a produit tel résultat. Un système peut être auditable sans être explicable : on sait qui a fait quoi et avec quoi, sans pouvoir ouvrir la boîte noire. Pour la plupart des usages d'entreprise, c'est l'auditabilité qui est exigée, l'explicabilité restant une propriété recherchée pour les décisions individuelles à fort enjeu.

Ce que le règlement européen demande, et à quelle date

Le règlement (UE) 2024/1689 ne parle pas d'« auditabilité » comme telle. Il la construit par un ensemble d'obligations qui pèsent sur les systèmes à haut risque, réparties entre le fournisseur, qui conçoit le système, et le déployeur, qui l'utilise. La plupart des entreprises sont déployeurs.

• Documentation technique (article 11 et annexe IV) : le fournisseur tient une documentation qui décrit le système, ses données d'entraînement, ses performances, ses limites et son système de gestion des risques. Le déployeur doit pouvoir l'obtenir.
• Enregistrement automatique des événements (article 12) : le système à haut risque journalise automatiquement les événements pertinents pendant toute sa durée de vie, de façon à permettre la traçabilité de son fonctionnement.
• Transparence envers le déployeur (article 13) : une notice d'utilisation qui précise les capacités, les limites, le niveau d'exactitude et les mesures de supervision humaine prévues.
• Supervision humaine (article 14) : le système est conçu pour être supervisé par des personnes capables de comprendre ses sorties, de les interpréter, de les écarter ou d'interrompre le système.
• Conservation des journaux : le fournisseur les conserve au moins six mois (article 19) ; le déployeur conserve ceux qui sont sous son contrôle pendant au moins six mois (article 26, paragraphe 6).
• Obligations du déployeur (article 26) : utiliser le système conformément à la notice, confier la supervision à des personnes formées, informer les représentants du personnel et les salariés concernés avant la mise en service d'un système à haut risque au travail.
• Analyse d'impact sur les droits fondamentaux (article 27) : pour les organismes publics, les entités privées chargées d'une mission de service public, et les déployeurs de systèmes d'évaluation de crédit ou de tarification en assurance vie et santé.

Le RGPD ajoute ses propres exigences, applicables dès aujourd'hui et quel que soit le niveau de risque : le registre des traitements (article 30), l'analyse d'impact quand elle est requise (article 35), et le droit d'obtenir une intervention humaine et des explications face à une décision entièrement automatisée (article 22). En pratique, c'est le RGPD qui rend l'auditabilité exigible en 2026, pas le règlement IA.

Les quatre couches de l'auditabilité

Un système auditable se documente à quatre niveaux. Les organisations qui échouent traitent en général un seul niveau, souvent le modèle, et découvrent le jour du contrôle que les trois autres manquent.

1. Les données

D'où viennent les données d'entrée et, pour un système entraîné en interne, les données d'entraînement : source, date d'extraction, base légale, droits d'usage, transformations appliquées. Pour un assistant génératif du marché, la couche données se réduit à ce que vos équipes y saisissent : c'est là que se logent la plupart des écarts, quand un document confidentiel ou une donnée personnelle part dans un outil non contractualisé.

2. Le modèle et sa configuration

Le fournisseur, le nom du modèle, sa version, la date de mise en service, les paramètres, le prompt système, les outils connectés, les sources documentaires branchées. Les éditeurs changent de modèle sans préavis, parfois plusieurs fois par an : sans date de version, deux sorties produites à trois mois d'écart ne sont pas comparables. Un simple journal des changements, tenu par la DSI, règle la question.

3. Les décisions et les journaux

Qui a demandé quoi, quelle sortie a été produite, qui l'a validée, ce qui a été modifié avant usage, et ce qui a été fait de la sortie. Pour un système à haut risque, cette couche est celle de l'article 12. Pour un assistant bureautique, elle se résume à deux règles : la sortie de l'IA ne part jamais telle quelle vers un tiers, et la personne qui la signe est identifiable.

4. L'organisation

Qui a autorisé le système, sur quelle base, avec quelles limites ; qui le supervise et avec quelle formation ; à quelle fréquence il est revu ; comment un incident remonte. C'est la couche que couvre une gouvernance de l'IA, et celle qu'une certification ISO/IEC 42001 examine en premier.

Ce que vous devez pouvoir produire, selon l'usage

Le niveau d'auditabilité attendu dépend de l'usage, pas de l'outil. Le tableau donne, pour les usages les plus fréquents en entreprise, le niveau de risque au sens du règlement, les pièces qu'on vous demandera et un délai réaliste pour les constituer.

Les délais supposent une organisation qui part de rien et un système déjà en service. Ils s'allongent quand le fournisseur ne livre pas sa documentation, ce qui arrive avec les éditeurs de logiciels métier qui ont activé une fonction d'IA sans le dire.

Auditabilité des IA génératives que vous achetez

Pour un assistant du marché, vous ne contrôlez ni le modèle ni son entraînement. L'auditabilité se joue alors dans le contrat et le plan souscrit. Cinq points à vérifier avant de signer, ou à vérifier maintenant si vous avez déjà signé.

1. 1Des journaux d'administration existent-ils, et sont-ils exportables ? Les plans destinés aux entreprises en proposent en général ; les comptes gratuits et grand public, jamais. Sans export, vos journaux vivent chez l'éditeur et disparaissent avec le compte.
2. 2Vos données sont-elles réutilisées pour l'entraînement ? La réponse doit être écrite dans le contrat, pas dans une page d'aide. Elle conditionne la couche données.
3. 3Où sont hébergées et traitées les données ? Région, sous-traitants, transferts hors Union européenne : le registre des traitements en a besoin.
4. 4Comment êtes-vous informé d'un changement de modèle ? À défaut de préavis de l'éditeur, tenez votre propre journal des versions, avec une date et un test de référence.
5. 5Pouvez-vous fixer un prompt système et des sources documentaires versionnés ? C'est ce qui rend deux sorties comparables et ce qui permet de reconstituer une réponse.

Sur un exemple précis, notre page sur la sécurité de Claude en entreprise décrit ce qu'un plan Entreprise apporte en matière de journaux et de conservation. Le principe vaut pour tous les éditeurs : l'auditabilité s'achète avec le plan, elle ne vient pas avec l'outil.

Auditabilité et ISO/IEC 42001

La norme ISO/IEC 42001, publiée le 18 décembre 2023, décrit un système de management de l'intelligence artificielle. Elle demande des enregistrements : inventaire des systèmes, évaluation des impacts, décisions documentées, revues périodiques. Une organisation certifiée a, par construction, traité la couche organisation de l'auditabilité, et souvent les trois autres. La certification est délivrée par un organisme accrédité sur un périmètre déclaré ; elle ne vaut pas conformité au règlement européen, pour lequel aucune norme harmonisée n'a été citée au Journal officiel de l'Union européenne à ce jour. Elle reste le cadre le plus utile pour structurer le travail, certification visée ou non.

Par où commencer : un plan en trois semaines

Pour une organisation qui utilise des outils du marché et n'a pas de système à haut risque en service, trois semaines suffisent à passer d'un usage non tracé à un usage auditable. Le plan ci-dessous se mène avec la DSI, le DPO et un responsable métier.

1. 1Semaine 1, inventaire et registre. Lister chaque système d'IA en service, y compris les fonctions activées dans vos logiciels et les comptes personnels connus. Pour chacun : usage, données, fournisseur, plan, version, personne responsable. Ce registre est la pièce que tout le reste suppose.
2. 2Semaine 2, journaux et versions pour les trois usages les plus sensibles. Activer ou exporter les journaux d'administration, dater la version du modèle, versionner le prompt système et les sources documentaires, écrire la règle « aucune sortie ne part telle quelle vers un tiers ».
3. 3Semaine 3, procédure et test. Rédiger la procédure d'autorisation d'un nouvel usage (qui décide, sur quels critères), la fiche de supervision (qui valide, comment on écarte une sortie), puis faire le test de reconstitution sur une sortie vieille d'un mois. Si le test échoue, la semaine 2 n'est pas finie.

Les erreurs qui rendent un système inauditable

• Des comptes personnels ou gratuits utilisés pour un usage professionnel : aucun journal, aucune version, aucun contrat.
• Un prompt système modifié à la main, sans historique : deux sorties ne sont plus comparables.
• Des sorties copiées-collées dans un document final sans trace de ce qui vient de l'IA et de ce qui a été corrigé.
• Un changement de modèle par l'éditeur, non daté côté entreprise : les performances mesurées avant ne veulent plus rien dire.
• Des journaux qui n'existent que chez l'éditeur, sans export : ils disparaissent avec le compte ou avec le prestataire.
• Une validation humaine réelle mais jamais tracée : au moment du litige, personne ne peut prouver qu'elle a eu lieu.

Chacune de ces erreurs se corrige en quelques jours. Aucune ne se corrige rétroactivement : les sorties produites avant restent inauditables. C'est la raison de commencer avant que le règlement ne l'exige, et avant qu'une question extérieure ne l'impose.

1. 01Auditabilité : une définition opérationnelle
2. 02Ce que le règlement européen demande, et à quelle date
3. 03Les quatre couches de l'auditabilité
4. 04Ce que vous devez pouvoir produire, selon l'usage
5. 05Auditabilité des IA génératives que vous achetez
6. 06Auditabilité et ISO/IEC 42001
7. 07Par où commencer : un plan en trois semaines
8. 08Les erreurs qui rendent un système inauditable

Questions fréquentes