Liste de contrôle d’audit IA  : comment auditer un système d’IA étape par étape

Soixante-dix-huit pour cent des dirigeants d’entreprise n’ont pas une confiance solide dans leur capacité à réussir un audit indépendant de gouvernance de l’IA dans un délai de 90 jours. Ce chiffre provient de l’enquête 2026 AI Impact Survey de Grant Thornton, menée auprès de 950 dirigeants d’entreprise, et c’est une façon diplomatique de dire que la plupart des entreprises ont déployé une IA qu’elles ne peuvent pas expliquer entièrement.

Un audit d’IA est un examen structuré des données, du modèle, de la sécurité, de la supervision et de la documentation d’un système d’IA au regard d’une norme définie. Pour auditer un système d’IA, suivez huit étapes dans l’ordre  : définir le périmètre du système, retracer les données, valider les performances, tester les biais, examiner la sécurité, vérifier la supervision humaine, contrôler le monitoring et constituer le dossier de preuves.

Chacune des huit étapes ci-dessous s’accompagne des vérifications précises à effectuer, des actions que vous pouvez confier à une équipe, et du signal d’alerte qui indique que l’étape a échoué. Si vous souhaitez un contexte plus large sur les types d’audit et sur qui en a besoin, notre guide sur ce qu’est un audit d’IA couvre ce terrain, et la page de notre service d’audit de développement logiciel explique comment une équipe externe en mène un.

Ce que couvre la liste de contrôle d'audit IA

Les huit étapes ci-dessous passent délibérément de la documentation à la production. Chaque étape ultérieure dépend du travail de délimitation du périmètre effectué dans la première étape, si bien que les exécuter dans le désordre revient à auditer un système que vous n’avez pas encore défini. La colonne relative à l’effort suppose un système de production unique de taille moyenne, comportant un ou deux modèles, avec une équipe capable de répondre aux questions en une journée.

Prévoyez trois à quatre semaines pour une première itération, et moins pour les cycles suivants une fois le pipeline de preuves en place. Le risque d’ignorer complètement cet exercice est mesurable  : une étude IBM de 2026 menée auprès de 2 000 dirigeants technologiques a révélé que les organisations disposant de contrôles intégrés connaissent 25 % d’incidents en moins que celles qui s’appuient sur une gouvernance manuelle.

Étape 1  : définir le périmètre du système et rédiger une fiche modèle

Vous ne pouvez pas auditer «  notre IA  ». Vous auditez un système précis, avec un numéro de version, un propriétaire nommé et une finalité écrite. Commencez par une fiche modèle, une fiche d’une page qui décrit ce que fait le système, ce pour quoi il ne doit jamais être utilisé, qui en est propriétaire, et à quel point ses décisions sont risquées. La liste de contrôle d’audit IA du Comité européen de la protection des données s’ouvre exactement sur cet artefact, puis ajoute une carte du système montrant où se situe le modèle dans le flux de décision et quelles personnes touchent à sa sortie.

Attendez-vous à ce que cette étape révèle des systèmes dont personne ne vous avait parlé. Une étude de l’IBM Institute for Business Value menée auprès de 2 000 dirigeants technologiques a révélé que 70 % d’entre eux affirment que les équipes, dans toute l’entreprise, déploient des technologies plus vite que l’IT ne peut en assurer le suivi.

Inventaire du système  :

• Recensez chaque système d’IA utilisé, y compris les outils achetés avec la carte de crédit d’une équipe
• Enregistrez le numéro de version et la date de la dernière modification
• Nommez un propriétaire responsable par système, une personne plutôt qu’un service

La fiche modèle  :

• Rédigez la finalité prévue du système en une phrase simple
• Documentez ce pour quoi il ne doit pas être utilisé, et pourquoi
• Notez quel modèle ou fournisseur se trouve derrière, et quelle version

Carte du système  :

• Schématisez où la sortie de l’IA entre dans une décision réelle et qui agit en fonction de celle-ci
• Repérez chaque point où une personne peut réviser, modifier ou annuler le résultat

Signal d’alerte  : la finalité du système change selon la personne à qui vous le demandez.

Étape 2  : retracer l'origine des données et déterminer si vous pouvez les utiliser

Chaque jeu de données ayant servi à entraîner, ajuster ou alimenter le modèle a besoin d’une origine traçable, d’une base légale documentée et d’un contrôle qualité. Demandez d’où proviennent les données, qui les a collectées, sous quel consentement ou quelle licence, et quand elles ont été actualisées pour la dernière fois. Vérifiez ensuite un échantillon vous-même plutôt que d’accepter le résumé, car c’est souvent là que les audits trouvent leur premier vrai problème.

Le marché le sait déjà. Dans le rapport State of AI in the Enterprise de Deloitte, la confidentialité et la sécurité des données arrivent en tête des préoccupations liées aux risques de l’IA avec 73 %, devant les aspects juridiques, la propriété intellectuelle et la conformité réglementaire à 50 %.

Origine des données  :

• Retracez chaque jeu de données jusqu’à l’organisation qui l’a initialement collecté
• Vérifiez la licence ou le consentement autorisant votre usage spécifique
• Signalez toute donnée collectée par scraping ou achetée dont les droits ne sont pas clairs

Données personnelles  :

• Identifiez toute information personnelle présente dans les jeux d’entraînement, les prompts ou les index de recherche
• Confirmez que vous disposez d’une base légale pour conserver chaque catégorie de ces données
• Vérifiez si les demandes de suppression atteignent réellement le système d’IA

Qualité des données  :

• Examinez comment les données ont été nettoyées et qui a décidé de ce qui devait être retiré
• Vérifiez la date d’actualisation, et si des données obsolètes sont encore utilisées discrètement

Signal d’alerte  : la réponse à «  d’où viennent ces données  » est un emplacement de stockage plutôt qu’une source.

Étape 3  : tester le modèle sur vos propres données, pas sur la démo du fournisseur

Les benchmarks des fournisseurs mesurent les conditions du fournisseur. Votre audit mesure les vôtres. Constituez un jeu de test à partir d’exemples réels que le modèle n’a jamais vus, exécutez le modèle sur ce jeu, puis enregistrez la fréquence à laquelle il a raison et la façon dont il échoue lorsqu’il se trompe.

Pour les systèmes de chat et de contenu, un score de précision unique ne vous apprend presque rien. Notez plutôt les résultats à l’aide d’une grille couvrant l’exactitude des faits, le respect des instructions, le refus des demandes qu’il devait refuser, et le maintien du format. Les équipes qui développent des systèmes d’IA et de machine learning personnalisés devraient déjà disposer de ce banc de test, et son absence constitue en soi un constat.

Jeu de test  :

• Réunissez des exemples réels que le modèle n’a jamais vus, issus du trafic réel
• Incluez les cas difficiles, pas seulement ceux qui se présentent bien en démonstration
• Conservez ce jeu à part afin qu’il ne se retrouve jamais dans l’entraînement

Mesure des performances  :

• Enregistrez la fréquence à laquelle le système a raison, et celle à laquelle il se trompe avec assurance
• Exécutez chaque test plus d’une fois, car les réponses varient d’une exécution à l’autre
• Ventilez les résultats par segment de clientèle, pas seulement par moyenne globale

Analyse des échecs  :

• Lisez un échantillon de réponses erronées et regroupez-les par cause
• Vérifiez si les pires échecs se concentrent sur votre cas d’usage à plus forte valeur

Signal d’alerte  : la seule preuve de performance est une diapositive issue du processus d’achat.

Étape 4  : tester les biais dans les groupes affectés par votre système

Les tests de biais forment un ensemble de mesures, pas un débat philosophique. Déterminez quels groupes sont affectés par les décisions de votre système, définissez à quoi ressemble un résultat préjudiciable pour chacun, puis comparez la fréquence de ce résultat entre ces groupes à l’aide du jeu de test de l’étape précédente. Si l’écart est significatif, consignez son ampleur plutôt qu’une impression générale.

La méthodologie d’audit du Comité européen de la protection des données ajoute ici une discipline utile. Repérez d’abord les moments de biais, c’est-à-dire les points précis où un déséquilibre peut s’introduire, comme qui s’est retrouvé dans les données, comment les étiquettes ont été rédigées, quelles caractéristiques le modèle utilise, et où le seuil de coupure a été fixé. Testez ensuite chacun de ces points séparément.

Définition des groupes  :

• Recensez les groupes réellement affectés par les décisions de votre système
• Définissez en termes simples à quoi ressemble un mauvais résultat pour chaque groupe

Comparaison des résultats  :

• Mesurez la fréquence à laquelle chaque groupe reçoit le résultat défavorable
• Comparez la précision par groupe, pas seulement le chiffre combiné
• Consignez l’ampleur de tout écart et qui a validé son acceptation

Moments de biais  :

• Vérifiez qui est sur- ou sous-représenté dans les données d’entraînement
• Examinez comment les étiquettes ont été créées et par qui
• Étudiez où les seuils ont été fixés et s’ils ont été ajustés pour un groupe donné

Signal d’alerte  : l’équipe soutient que le système ne peut pas être biaisé car il ne voit jamais l’origine ethnique, le genre ou l’âge. Des champs ordinaires se substituent à ces informations, si bien qu’un code postal, le nom d’un établissement scolaire ou un historique professionnel peuvent porter le même signal et produire le même résultat biaisé.

Étape 5  : examiner la sécurité, en commençant par l'injection de prompt

Les systèmes d’IA héritent de toutes les vulnérabilités classiques des applications et en ajoutent quelques-unes qui leur sont propres. L’injection de prompt occupe la première place de l’OWASP Top 10 pour les applications LLM sous le nom LLM01, et elle fonctionne de deux manières. L’injection directe consiste pour un utilisateur à saisir des instructions qui détournent le système. L’injection indirecte correspond à des instructions cachées arrivant dans un document, une page web ou un e-mail que le modèle lit et exécute.

Ce qui transforme une mauvaise réponse en véritable incident, c’est ce à quoi le modèle peut accéder. Notre équipe QA chez QAwerk maintient une liste de contrôle de tests d’injection de prompt avant lancement avec les cas de test précis à exécuter avant la mise en production, et toute équipe qui déploie un produit basé sur un LLM devrait pouvoir vous montrer des résultats issus de cette liste, et non de simples intentions.

Tests d’injection  :

• Tentez de contourner directement le prompt système, comme le ferait un utilisateur malveillant
• Dissimulez des instructions cachées dans un document ou une page web lu par le système
• Vérifiez si le système révèle ses propres instructions lorsqu’on l’interroge habilement

Accès et autorisations  :

• Recensez chaque outil, base de données et API que le modèle peut appeler
• Confirmez que les autorisations du modèle ne sont pas plus larges que celles de l’utilisateur qui lui parle
• Exigez une validation humaine avant toute action qui dépense de l’argent ou envoie des messages

Fuite de données  :

• Vérifiez si le système peut révéler les données d’un autre client
• Vérifiez que le filtrage s’applique aux sorties, pas seulement aux entrées

Signal d’alerte  : le modèle dispose d’identifiants API avec des autorisations plus larges que celles de l’utilisateur qui lui parle.

Étape 6  : vérifier qui surveille et qui peut l'arrêter

La supervision échoue d’une manière prévisible. Une personne est nominalement impliquée mais n’a ni le temps ni l’autorité pour être en désaccord avec le modèle, si bien que la révision devient une formalité. Votre audit doit vérifier si le réviseur peut réellement évaluer la sortie, à quelle fréquence il l’annule effectivement, et ce qui se passe quand il le fait.

L’article 26 du règlement européen sur l’IA exige que les déployeurs de systèmes à haut risque confient la supervision à des personnes disposant «  des compétences, de la formation et de l’autorité nécessaires  ». Ce sont précisément la compétence et l’autorité qui sont souvent négligées. Grant Thornton a constaté que seulement 20 % des organisations disposent d’un plan de réponse aux incidents d’IA testé, demandez donc à quand remonte la dernière répétition de la procédure d’arrêt.

Capacité du réviseur  :

• Confirmez que le réviseur dispose du temps et du contexte nécessaires pour juger chaque sortie
• Vérifiez qu’il a l’autorité pour infirmer le système sans devoir remonter la hiérarchie
• Mesurez le taux d’annulation sur le dernier trimestre

Autorité d’arrêt  :

• Identifiez qui peut désactiver le système, par nom et par rôle
• Vérifiez qu’un chemin de retour arrière existe et ne nécessite pas le développeur d’origine
• Confirmez que la procédure d’arrêt a été répétée, et pas seulement rédigée

Escalade  :

• Examinez comment une mauvaise sortie est signalée et qui reçoit ce signalement
• Vérifiez que les incidents sont consignés quelque part que la direction consulte réellement

Notre guide sur la gouvernance des agents d’IA en entreprise détaille cette architecture de supervision, notamment pourquoi un plan de retour arrière doit exister dès la validation du lancement plutôt qu’au moment de l’incident.

Signal d’alerte  : le taux d’annulation est nul, ce qui signifie généralement que la révision n’est qu’un tampon formel.

Étape 7  : vérifier le monitoring, les alertes de dérive et la conservation des journaux

Un modèle qui a réussi tous les tests en mars peut se dégrader discrètement d’ici septembre, à mesure que le monde réel évolue sous lui. Vérifiez que quelqu’un surveille la production, que les alertes disposent de seuils plutôt que de tableaux de bord que personne n’ouvre, et qu’une personne nommée les reçoit. Vérifiez ensuite les journaux, car la journalisation déterminera si votre prochain audit est même possible.

L’article 12 du règlement européen sur l’IA exige que les systèmes à haut risque enregistrent automatiquement les événements sur toute la durée de vie du système, et l’article 26 exige que les déployeurs conservent ces journaux pendant au moins six mois. Des chercheurs de l’université Brown formulent le constat plus crûment dans leurs travaux sur les pistes d’audit des LLM  : sans enregistrements infalsifiables, les organisations ne peuvent pas reconstituer quelle version du modèle était en cours d’exécution, quelles données l’ont influencée, ni qui a approuvé le changement.

Monitoring en production  :

• Confirmez que quelqu’un vérifie si les requêtes entrantes ressemblent encore à ce pour quoi le modèle a été conçu
• Surveillez la qualité des réponses, les taux d’erreur et la vitesse, pas seulement la disponibilité
• Suivez un indicateur de résultat métier en plus des indicateurs techniques

Alertes  :

• Vérifiez que les alertes disposent de seuils définis et d’un destinataire nommé
• Examinez les trois dernières alertes et l’action qui a suivi chacune d’elles

Conservation des journaux  :

• Consignez ce qui est journalisé  : entrées, sorties, version du modèle, version du prompt, et qui a changé quoi
• Confirmez que la conservation respecte votre exigence applicable la plus stricte, pas le paramètre par défaut de la plateforme
• Vérifiez que les journaux ne peuvent pas être modifiés discrètement après coup

Vous ne pouvez pas reconstituer rétroactivement un journal qui n’a jamais été capturé, traitez donc les lacunes ici comme urgentes plutôt qu’administratives. Notre article sur l’audit de la collaboration entre l’IA et l’humain approfondit la façon de capturer le volet humain de cet enregistrement.

Signal d’alerte  : la conservation des journaux est réglée sur le paramètre par défaut de la plateforme et personne n’a vérifié quel est ce paramètre.

Étape 8  : constituer le dossier de preuves

La dernière étape transforme sept étapes de travail en quelque chose qu’une partie externe peut vérifier. Rassemblez chaque artefact produit dans un package indexé, puis associez chacun aux référentiels dont vous êtes responsable, qu’il s’agisse du règlement européen sur l’IA, de l’ISO/IEC 42001, de SOC 2 ou du NIST AI Risk Management Framework et de ses fonctions Govern, Map, Measure et Manage. Un auditeur devrait pouvoir ouvrir le dossier et retracer toute affirmation jusqu’au document qui l’étaye.

Limitez cette étape à la documentation et à la traçabilité. Déterminer quels référentiels s’appliquent à votre activité est un exercice distinct, qu’il vaut mieux terminer avant le début de l’audit.

Collecte des preuves  :

• Réunissez au même endroit la fiche modèle, la carte du système, les dossiers de données et tous les résultats de tests
• Incluez des échantillons de journaux montrant que le système enregistre ce que vous affirmez qu’il enregistre
• Datez et versionnez chaque artefact afin qu’un réviseur puisse savoir ce qui était en vigueur

Correspondance avec les référentiels  :

• Associez chaque artefact à l’exigence précise qu’il satisfait
• Signalez comme lacunes ouvertes les exigences sans preuve à l’appui

Rapport de constats  :

• Rédigez les constats avec un niveau de gravité et un propriétaire nommé pour chacun
• Utilisez le même format de défaut que celui déjà utilisé par votre équipe d’ingénierie
• Fixez une date de nouvelle vérification pour chaque constat que vous avez accepté

Notre liste de contrôle d’audit du SDLC applique la même rigueur à l’ensemble du processus de développement.

Signal d’alerte  : le livrable est une présentation plutôt qu’un ensemble de dossiers documentés.

Quand cette liste de contrôle est excessive

Exécuter les huit étapes sur un système en production depuis deux semaines et qui ne sert qu’au personnel interne constitue généralement une mauvaise utilisation d’un mois de travail. Adaptez la profondeur à l’exposition. Un outil de synthèse pour l’équipe marketing a réellement besoin de trois choses  : une fiche modèle nommant son propriétaire et sa finalité, une vérification des données qu’il touche et de la possibilité de les utiliser, et une analyse de sécurité couvrant l’injection de prompt et ce à quoi l’outil peut accéder. Un modèle de décision de crédit a besoin des huit étapes, deux fois par an, revues par une personne indépendante de l’équipe qui l’a construit.

La liste de contrôle suppose également que vous puissiez voir l’intérieur du système. Lorsque vous auditez un modèle fermé fourni par un tiers, trois étapes changent de forme. Les tests de performance, les tests de biais et l’analyse de sécurité passent tous de l’inspection du modèle à l’évaluation de son comportement depuis l’extérieur et à la lecture des engagements contractuels du fournisseur. Cela reste un audit légitime, il faut simplement l’indiquer honnêtement dans le rapport afin que personne ne confonde une attestation avec une mesure.

Enfin, un audit n’est qu’un instantané pris à une date donnée. C’est pourquoi l’étape de monitoring et de journalisation pèse plus qu’il n’y paraît au premier abord, car un monitoring continu est ce qui maintient les constats valables entre les révisions formelles.

Pourquoi Redwerk est un partenaire pertinent pour cela

Nous concevons des logiciels sur mesure depuis 2005, ce qui signifie que nous auditons comme le font les ingénieurs, en vérifiant les endroits où ces systèmes tombent réellement en panne plutôt qu’en suivant une liste générique. Parce que nous accompagnons nos clients à chaque étape du SDLC, nous pouvons aussi examiner chacune de ces étapes, identifier les lacunes et recommander des correctifs adaptés à l’équipe qui doit les mettre en œuvre.

Les environnements réglementés nous sont familiers. Nous avons construit l’application citoyenne YouTown, distinguée par la Maison Blanche, mis à niveau la plateforme de vote électronique EUGI pour le Parlement européen, et déployé un SaaS de gestion des prestations sociales aujourd’hui adopté par plus de dix comtés et États américains. Côté IA, nous avons contribué à construire, faire évoluer et maintenir des systèmes en production, notamment Recruit Media et Evolv.

Si vous préférez confier cette liste de contrôle à une équipe qui l’a déjà mise en œuvre, contactez-nous et nous définirons le périmètre d’un audit pour les systèmes que vous avez réellement en production.

FAQ

Comment auditer un système d'IA  ?

Auditez un système d’IA en huit étapes  : définissez le périmètre du système et rédigez une fiche modèle, retracez l’origine des données et déterminez si vous pouvez les utiliser, testez le modèle sur vos propres données, testez les biais entre les groupes affectés, examinez la sécurité, notamment l’injection de prompt, vérifiez la supervision humaine et l’autorité d’arrêt, contrôlez le monitoring et la conservation des journaux, puis constituez un dossier de preuves associé aux référentiels qui vous sont applicables.

Que doit contenir une liste de contrôle d'audit IA  ?

Au minimum  : inventaire du système et responsabilité, origine des données et base légale, tests de performance sur des exemples réels que le modèle n’a jamais vus, tests de biais avec comparaisons documentées entre groupes, tests de sécurité au regard de l’OWASP Top 10 pour les applications LLM, supervision humaine avec une procédure d’arrêt répétée, monitoring de la dérive, conservation des journaux respectant votre minimum réglementaire, et documentation associée à un référentiel nommé.

Que devez-vous réunir avant de démarrer un audit d'IA  ?

Réunissez cinq éléments avant le premier jour  : une liste de tous les systèmes d’IA utilisés avec un propriétaire nommé, les sources de données derrière chacun, toute documentation et tout contrat fournisseur, les résultats de tests ou benchmarks existants, et l’accès aux journaux de production. Les éléments manquants ne sont pas des blocages, ce sont vos premiers constats.

Peut-on auditer un système d'IA que l'on n'a pas construit soi-même  ?

Oui, et c’est le cas de la plupart des audits. Pour les modèles fermés fournis par un tiers, vous testez le comportement depuis l’extérieur, vous examinez la documentation et les engagements contractuels du fournisseur, et vous auditez intégralement votre propre intégration, le traitement de vos données et votre supervision. Le rapport doit indiquer clairement quels constats vous avez observés vous-même et lesquels ont été affirmés par le fournisseur.