Audit IA en entreprise : quelle mission choisir et quels livrables exiger ?

01Diagnostic, contrôle ou cadrage : trois missions différentes

Un audit IA n’a de valeur que s’il prépare une décision définie. Pour une entreprise qui cherche son premier cas d’usage, cette décision consiste à retenir ou écarter une option, puis à fixer les conditions de son exploration. L’investigation établit des constats, éprouve les hypothèses et indique ce que l’entreprise peut raisonnablement faire ensuite.

Le sujet est loin d’être marginal : beaucoup d’organisations se lancent, mais peu savent ce qu’elles ont réellement mis en service.

Ces chiffres décrivent l’adoption déclarée ou les résultats d’audits publics, jamais les résultats métier obtenus : c’est précisément ce qu’un audit doit établir.

Trois missions différentes portent aujourd’hui le même nom. Les confondre revient à payer pour une réponse à une question que l’entreprise ne se pose pas.

Le diagnostic d’opportunité intervient lorsque l’entreprise envisage l’IA sans avoir encore délimité le problème à traiter. Il répond à une question de pertinence : un travail métier justifie-t-il d’explorer une solution d’IA ? L’enquête porte alors sur les objectifs, les difficultés rencontrées, les décisions concernées, les conditions d’adoption et les obstacles susceptibles de rendre cette exploration inutile.

Cette logique rejoint la fonction MAP du cadre du NIST : au terme de cette étape, l’organisation doit connaître suffisamment le contexte pour décider une première fois d’engager ou non la conception, le développement ou le déploiement d’un système d’IA.^[1] Le cadre confirme l’utilité d’une analyse préalable à cette décision, sans prescrire pour autant la forme de la mission.

Le contrôle d’un usage déjà installé ne porte plus sur le choix d’un premier cas. Les symptômes déclencheurs sont concrets : la finalité réelle n’est plus claire, des personnes utilisent l’outil sans règle commune, les données mobilisées restent inconnues, la validation humaine ne fonctionne pas comme prévu, ou un incident révèle un écart entre la pratique et le cadre annoncé.

Ce manque de visibilité sur les accès n’a rien d’une hypothèse d’école. Lorsque la Cour des comptes néerlandaise a audité neuf algorithmes employés par l’administration, six des neuf organisations concernées ne savaient pas quels agents disposaient d’un accès aux données.^[3] La question « qui peut lire quoi » peut donc rester longtemps sans réponse.

L’examen commence par délimiter l’usage, les personnes concernées et la décision à préparer. Il confronte ensuite les règles déclarées aux entrées, sorties, validations et incidents effectivement observables. Le livrable attendu est un dossier de contrôle qui sépare les faits constatés, les déclarations recueillies, les accès refusés et les conditions de décision. Il permet au responsable désigné de maintenir l’usage, de modifier ses conditions ou de le suspendre. Ce contrôle ne constitue ni un audit juridique ni un audit de cybersécurité.

Le cadrage de projet suppose enfin qu’un problème précis ait été retenu. Il faut définir ce qui sera éprouvé, dans quel processus, auprès de quels utilisateurs, avec quelles données, quelles limites et quelle règle de décision. Le cadrage n’aboutit pas à une liste générale d’idées : il produit un cadre qui permet d’autoriser ou de refuser l’étape suivante.

Ces périmètres peuvent se succéder, mais ils ne sont pas interchangeables. Chacun part d’une incertitude différente et prépare sa propre décision.

02Choisir le périmètre à partir de la décision attendue

Une demande d’« audit IA » sans décision attendue reste insuffisamment qualifiée. Le prestataire et la direction doivent alors préciser ensemble la question avant de fixer le contenu du rapport. Les principes de gouvernance publiés par le service numérique britannique formulent la même exigence : une décision se prend sur des faits, par une personne disposant de l’autorité nécessaire, selon une procédure d’arbitrage définie à l’avance.^[14]

Un diagnostic d’opportunité devient hors sujet si des usages sensibles existent déjà et réclament un examen immédiat. Un examen des pratiques actuelles n’aide pas une direction à cadrer un projet précis. Un cadrage détaillé arrive trop tôt lorsque personne ne peut encore expliquer quel problème mérite une expérimentation.

Un périmètre mal choisi produit un rapport qui ne prépare pas la décision attendue.

Regrouper tous les constats sous un même intitulé masque leurs différences. Une absence de responsable, une donnée indisponible et un objectif flou deviennent des « points de vigilance » équivalents dans un score ou une liste de recommandations. Or leurs conséquences divergent : attribuer une responsabilité, vérifier un accès ou reformuler le problème n’engagent ni les mêmes personnes ni la même suite.

Une conclusion sans critère précis renvoie enfin le travail au commanditaire. Le rapport recommande de « poursuivre », de « structurer » ou de « prioriser » sans préciser ce qui autorise l’action, ce qui la bloque et qui tranche. La direction reçoit une orientation, puis doit reconstruire seule la décision.

Ce tableau relie ce que l’entreprise observe au périmètre d’audit qui lui correspond.

La présence de plusieurs symptômes n’autorise pas un périmètre illimité. Elle impose de décider quelle incertitude doit être traitée en premier, puis de documenter les questions laissées hors champ.

03Six questions avant de lancer la mission

Le test de qualification tient sur une page. Il vérifie que la décision à préparer est assez claire pour que la mission puisse être engagée, suivie et acceptée.

Ces six questions font apparaître les points qui restent à préciser avant le lancement de la mission.

Avant d’engager l’audit, complétez cette phrase : « À l’issue de la mission, la personne responsable décidera de…, à partir de…, à condition que… » Si un blanc subsiste, il devient une question de qualification, une limite acceptée ou un motif de report.

Le test ne conduit pas nécessairement au lancement de l’audit. Il peut conduire à un entretien de qualification, à la collecte préalable d’un document, à la séparation de deux missions ou à l’arrêt d’une demande qui ne prépare aucune décision réelle. Les guides publics de conception de services assument explicitement cette issue : la phase de découverte sert à comprendre le problème, les personnes concernées et les contraintes, et peut se conclure par la décision de ne pas poursuivre.^[12]

Deux questions méritent d’être tranchées à ce stade plutôt qu’au milieu de la mission. La première est juridique : lorsque des données personnelles sont mobilisées, la finalité du système doit être établie dès la définition du projet.^[7] L’entreprise doit aussi déterminer sa qualification au sens du RGPD : responsable de traitement, responsable conjoint ou sous-traitant.^[7] La seconde concerne l’analyse d’impact, exigible lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes.^[10] Découvrir l’une ou l’autre après le lancement transforme un audit d’opportunité en chantier de conformité et allonge d’autant le calendrier.

Un diagnostic d’opportunité peut établir que plusieurs cas d’usage méritent d’être comparés. Leur sélection demande cependant une méthode distincte. À ce stade, l’audit précise les critères de choix, les informations nécessaires et la personne chargée de trancher.

04Chercher aussi les preuves qui contredisent l’hypothèse

Un audit ne transforme pas une information inaccessible en constat fiable. Ses conclusions doivent donc rester proportionnées aux personnes entendues et aux documents examinés.

La décision à préparer détermine les personnes à entendre. Le décideur et le responsable du processus doivent être entendus. Pour documenter le travail réel, l’audit demande aux personnes qui l’exécutent de décrire les exceptions, les reprises et les effets qu’elles observent. D’autres interlocuteurs ne sont sollicités que si la question dépend de leurs ressources ou si la décision les concerne directement.

Le NIST cite notamment des experts métier, des responsables des données, des financeurs du système et des responsables produit parmi les acteurs de conception de l’IA.^[1] Cette liste ne prescrit pas la composition d’un comité d’audit. Elle aide seulement à identifier les responsabilités à associer à la question étudiée.

Cette matrice relie chaque contribution à l’information attendue et à la décision qu’elle peut éclairer.

Les documents demandés doivent être annoncés avant les entretiens. Selon le périmètre, ils peuvent comprendre une description du processus, les décisions existantes, les outils employés, les instructions internes, les sources de données déclarées, les résultats disponibles, les contrôles effectués, les incidents consignés, les essais antérieurs et les contraintes connues.

Aucun de ces documents n’a automatiquement valeur de preuve. Une procédure décrit ce qui devrait se produire ; elle n’établit pas seule ce qui se produit. Une démonstration montre un fonctionnement possible ; elle ne suffit pas à caractériser tous les cas d’usage. Un entretien révèle une expérience ou une interprétation qui doit être attribuée à son interlocuteur.

Cette confrontation distingue nettement l’audit d’une étude de faisabilité. La psychologie de la décision décrit depuis longtemps la tendance à rassembler sélectivement les preuves favorables et à écarter celles qui contredisent la position défendue, souvent sans intention consciente de le faire.^[6] Un audit sérieux recherche donc ce qui pourrait invalider l’option envisagée, et pas seulement ce qui la soutient.

Un dossier conçu pour justifier une conclusion déjà arrêtée ne constitue pas un audit : il documente une décision prise d’avance.

Le rapport doit nommer tout accès manquant, sa conséquence et la personne qui peut l’autoriser. Si cette limite compromet un constat déterminant, la conclusion reste conditionnelle ou la décision est reportée. Promettre davantage masquerait simplement ce que l’audit n’a pas pu établir.

05Traiter les désaccords entre les sources

L’accord sur la décision à préparer doit précéder la planification des entretiens. Il fixe la question à résoudre, le périmètre, le hors-champ, le responsable, les documents attendus et les critères d’acceptation.

La méthode change avec la décision. Le diagnostic d’opportunité précise le besoin et les options à comparer. Le cadrage examine ensuite les conditions de départ du cas retenu et prépare sa feuille de route. Aucun de ces livrables ne tient lieu d’audit juridique, d’audit de cybersécurité, d’intégration ou de déploiement.

Chaque étape doit produire un résultat contrôlable. Si elle ne modifie ni la compréhension du problème ni la capacité à décider, elle décrit probablement une activité de mission plutôt qu’un résultat utile.

1. 01

   Qualifier la demande

   Décrire le déclencheur, l’objet concerné, la décision aujourd’hui impossible et l’autorité qui devra la prendre.

2. 02

   Fixer les règles de la mission

   Écrire le périmètre, les questions, les issues favorables ou défavorables, les limites connues et les critères d’acceptation.

3. 03

   Négocier les accès

   Associer chaque question aux personnes, documents, observations ou traces susceptibles de l’éclairer, et obtenir l’autorisation correspondante.

4. 04

   Recueillir et confronter

   Distinguer les déclarations, les documents, les observations, les inconnues et les désaccords sans les fusionner.

5. 05

   Formuler les options

   Présenter les actions possibles, leurs conditions, leurs responsables et les conséquences des informations manquantes.

6. 06

   Tester l’acceptation

   Vérifier que chaque livrable permet au décideur désigné de trancher, d’attribuer la suite ou de demander une preuve précise.

Exemple hypothétique : une demande qui change après l’analyse

L’exemple qui suit est hypothétique. Il ne rapporte aucune mission réelle et ne cite aucun client.

Une PME envisage d’équiper son service client d’un assistant capable de préparer des réponses. La demande initiale porte déjà le nom d’un outil et suppose que le gain viendra de la rédaction automatique. Le test de qualification ramène pourtant la discussion au problème observé : les conseillers perdent surtout du temps à retrouver la bonne information dans plusieurs documents, puis à vérifier si elle est encore valable.

L’analyse compare alors trois options : faciliter la recherche documentaire, préparer un brouillon de réponse ou mieux orienter les demandes entrantes. Elle consigne pour chacune les données nécessaires, la personne chargée de valider le résultat, les erreurs qui imposeraient un arrêt et l’information encore indisponible. Dans ce scénario, le brouillon automatique reste ajourné parce que les règles de réponse ne sont pas suffisamment stabilisées. La recherche documentaire peut en revanche être explorée sur un périmètre borné, avec une source identifiée et une validation humaine maintenue.

Le dossier ne prétend pas avoir trouvé « le meilleur projet IA ». Il explique pourquoi une option précise mérite un test, pourquoi les deux autres sont ajournées et quelles observations pourraient rouvrir le choix. La feuille de route part de cette décision : situation de départ, responsable, corpus autorisé, vérifications attendues et conditions distinctes de poursuite, de révision ou d’arrêt.

Une nouvelle question peut apparaître pendant les travaux. L’accord de départ permet alors de la classer comme nécessaire à la décision convenue, utile à une mission ultérieure ou extérieure au mandat.

Le rapport doit indiquer la nature de chaque élément recueilli. Un avis de direction, une description donnée par un opérateur et un document technique ne répondent pas à la même question. Leur désaccord constitue parfois le constat principal. Le gommer au profit d’une synthèse consensuelle ferait perdre une information utile à la décision.

La restitution doit enfin permettre au responsable désigné de décider. Elle distingue le constat, les éléments qui l’étayent, les conséquences du constat et l’action proposée. Le débat peut ainsi porter sur les preuves et les arbitrages, au lieu de se limiter à la formulation de la recommandation.

06Neuf livrables pour rendre le rapport exploitable

Le fait qu’un livrable figure dans la proposition initiale ne suffit pas à justifier son acceptation. Il doit remplir la fonction annoncée et permettre au destinataire de prendre une décision, de refuser une option ou de préparer l’étape suivante.

Les référentiels d’audit publics fournissent un cadre utile. Le cadre de redevabilité du GAO répartit ses pratiques entre quatre principes : gouvernance, données, performance et suivi. Il associe à chaque pratique des questions destinées aux entités, aux auditeurs et aux évaluateurs externes, ainsi que des procédures d’audit.^[2] Le guide commun de six institutions supérieures de contrôle relie, pour sa part, des sujets d’audit fondés sur les risques aux contrôles attendus.^[5] Aucun des deux ne s’adresse à une PME française, mais tous deux montrent la même exigence : à chaque question posée doit correspondre une procédure de vérification.

L’accord de départ fixe la question, le responsable, le périmètre, les exclusions et la forme de la conclusion. La carte de situation décrit concrètement l’objet examiné, les personnes concernées, les ressources engagées, les contrôles déclarés et les inconnues susceptibles de modifier l’analyse.

Deux pièces permettent alors d’examiner les résultats sans effacer leurs différences. Le registre des constats conserve, pour chaque point, la nature des éléments qui l’étayent, son périmètre et ses limites, tandis que la carte des conditions montre ce que ce point change pour une option ou un responsable. Une alerte qui ne modifie ni une décision ni une action reste un thème général, pas un résultat exploitable.

Au terme de l’analyse, chaque option est présentée avec son responsable, la condition qui autorise la suite et l’information encore manquante. La feuille de décision enregistre le choix, les réserves et le prochain contrôle. Même lorsqu’une seule recommandation subsiste, le dossier précise ce qui conduirait à la refuser ou à la reporter.

Lorsque l’audit porte sur un premier cas d’usage, le dossier de priorisation nomme les idées examinées, le cas retenu, les options ajournées et la référence de la grille de comparaison utilisée. Il est acceptable si la conclusion peut être reliée aux informations examinées et aux motifs consignés dans cette analyse séparée.

La feuille de route part ensuite du cas retenu. Elle réunit l’hypothèse testée, la situation de départ, les dépendances, les responsables, les indicateurs, les seuils, les preuves à conserver et les jalons de décision. Elle est acceptable si chaque résultat prévu conduit à l’une des trois issues écrites avant le test : poursuivre une étape délimitée, revoir une hypothèse précise ou arrêter. Une liste de tâches et de réunions ne satisfait pas ce critère.

Cette grille relie chaque livrable à un responsable, à une preuve vérifiable, à son critère d’acceptation et à la décision qu’il prépare.

Le responsable participe à la définition du livrable qu’il devra accepter. Le dossier précise son autorité, les moyens disponibles et les éventuelles limites d’exécution, afin que ces conditions restent visibles au moment de décider.

Lorsque le périmètre touche un système soumis au règlement européen sur l’IA, plusieurs exigences s’ajoutent, notamment la documentation technique, la tenue de registres et l’organisation du contrôle humain ; les obligations diffèrent selon que l’entreprise est fournisseur ou déployeur.^[9] Ces obligations visent des systèmes précis, principalement à haut risque : elles ne créent aucun devoir général d’auditer un projet d’IA. Il serait donc inexact de présenter le contraire à un dirigeant.

Les documents exigés doivent enfin rester proportionnés à la question. Le rapport indique ce qui a été examiné et ce qui ne l’a pas été. Il évite d’étendre une conclusion au-delà du processus, de l’usage, des personnes ou des données effectivement couverts.

07Définir les motifs de refus avant le début de la mission

Des recommandations générales ne précisent ni l’action, ni son responsable, ni la condition qui l’autorise. Les critères d’acceptation sont donc définis avant la mission afin que chaque livrable indique ces trois éléments.

Un critère utile peut être vérifié par une question fermée ou par une observation précise. Le périmètre est-il nommé ? La décision est-elle attribuée à un responsable ? Les constats sont-ils séparés des hypothèses ? Chaque réserve modifie-t-elle une option ? La responsabilité de fournir les accès manquants est-elle attribuée ? La conclusion contient-elle une issue d’arrêt ou de report ?

Ce contrôle permet de refuser un livrable qui ne prépare aucune décision identifiable.

Les six autres algorithmes exposaient l’administration à des risques divers.^[3] Une norme volontaire comme ISO/IEC 42001 décrit un système de management destiné à établir des politiques, des objectifs et des processus pour le développement, la fourniture ou l’utilisation responsables de systèmes d’IA.^[11] Mais aucun référentiel ne dispense de vérifier ce qui a réellement été fait.

Les formules « renforcer la gouvernance », « améliorer la qualité des données » ou « accompagner le changement » restent insuffisantes lorsqu’elles ne désignent ni objet, ni action, ni responsable, ni condition permettant d’agir. Elles nomment tout au plus un thème ; elles ne permettent pas encore d’agir.

Une demande de mission qui cumule une vision stratégique, un inventaire des usages, une évaluation des outils et une feuille de route reste trop large tant que la décision prioritaire n’est pas précisée. Le critère d’acceptation porte alors sur l’ordre des décisions et sur les exclusions assumées.

Refusez un livrable lorsque le décideur ne peut pas compléter cette phrase : « À partir de ce constat, je peux autoriser, refuser, attribuer ou reporter telle action, pour telle raison vérifiable. »

Un livrable est acceptable si son raisonnement peut être vérifié : question claire, sources identifiées, limites visibles et conséquence cohérente. Une conclusion défavorable peut satisfaire le contrat. Une conclusion séduisante, mais dépourvue de preuves suffisantes ou sans responsable désigné pour agir, doit être refusée.

Le contrôle final porte aussi sur le hors-champ. Le rapport précise les questions qu’il n’a pas résolues. Cette mention du hors-champ rappelle qu’un diagnostic d’opportunité ne vaut pas validation implicite d’un outil et qu’un cadrage de projet ne vaut pas autorisation générale de déploiement.

08Décider d’arrêter reste une conclusion recevable

Une décision sérieuse ne se réduit pas à un feu vert. Trois issues restent possibles, et chacune exige ses propres preuves.

Les annonces rendent moins visibles les décisions d’arrêt que les lancements. Le National Audit Office britannique relevait en 2024 que 70 % des organismes interrogés expérimentaient ou planifiaient des cas d’usage de l’IA^[4] : ce chiffre porte sur des intentions et ne dit rien du nombre de projets effectivement conduits jusqu’au bout. Un audit qui exclut la possibilité d’arrêter conduit à recommander des projets dont personne n’a réellement décidé la poursuite.

Pour qualifier votre demande, identifiez d’abord si la décision concerne une opportunité à explorer, un usage déjà installé à contrôler ou un projet retenu à cadrer. Si l’objectif est de choisir un premier cas d’usage, écrivez ensuite la décision exacte attendue de chaque livrable. Ajoutez le nom ou la fonction de la personne qui devra l’assumer et la preuve qui lui permettra de l’accepter. Les éléments laissés en blanc constituent déjà un premier résultat : ils montrent ce que la demande d’audit doit encore clarifier.

Si l’entreprise souhaite faire examiner ce périmètre par un intervenant extérieur, l’audit IA présenté sur farweb.fr porte sur la cartographie des usages, la priorisation et les arbitrages de direction ; il n’inclut ni audit juridique, ni audit de cybersécurité, ni intégration.

Après l’audit, vous devez pouvoir choisir une action délimitée, la refuser ou demander une preuve précise, avec un responsable identifiable et sans prêter au rapport une portée qu’il ne possède pas.