Audit IA en entreprise : la méthode complète pour évaluer la maturité IA

La demande arrive presque toujours sous la même forme : « il nous faut un audit IA ». Sous-entendu : un état des lieux qui dira si l'organisation est en avance, en retard, ou dans la moyenne. Le mot trompe — il évoque l'audit de comptes ou l'audit IT, exercices stabilisés avec des référentiels clairs (ISO 27001, COBIT, normes comptables). L'audit IA ne ressemble pas à ça. Il évalue une capacité émergente, sur un objet qui change tous les six mois, dans une organisation qui n'a souvent pas de cas d'usage en production. Le risque est de produire un livrable scolaire qui mesure ce qui se mesure facilement, plutôt que ce qui détermine la trajectoire réelle.

Sur les missions que nous menons, l'audit IA utile suit une logique inverse à celle de l'audit IT classique. Il ne part pas du référentiel pour mesurer l'écart — il part des cas d'usage métier réellement en jeu, qualifie la matière première (données, compétences, infrastructure), et n'évalue la gouvernance qu'à la fin, comme un chapeau qui rationalise l'existant. C'est ce qui transforme un diagnostic en feuille de route, plutôt qu'en photographie figée d'un instant T.

Pourquoi un audit IA n'est pas un audit IT

Un audit IT mesure la conformité d'un système stable à un référentiel stable. L'auditeur connaît la cible (ITIL, ISO, COBIT), il connaît l'objet audité (un SI cartographié), et l'écart qu'il documente est exploitable directement par les équipes. L'audit IA ne dispose ni de référentiel stable, ni d'objet stable. La Hype Cycle for AI de Gartner publie chaque année une cartographie des technologies — et chaque année, une moitié du paysage a changé. Auditer une organisation contre un référentiel daté de huit mois revient à mesurer un coureur avec un mètre qui rétrécit.

Deuxième différence : l'audit IT s'intéresse à des actifs (logiciels, infrastructures, contrats). L'audit IA s'intéresse à des capacités, qui sont par construction transversales. La capacité à industrialiser un modèle dépend autant du data engineering que du sponsorship métier, autant des pratiques MLOps que de l'appétence du COMEX au risque. Un auditeur qui décompose en silos passe à côté du sujet — la maturité IA est précisément ce qui se joue à l'intersection.

Troisième différence : un audit IT débouche sur des correctifs (patch, montée de version, recadrage de procédure). Un audit IA débouche, si on l'a bien fait, sur des arbitrages stratégiques — quels cas d'usage prioriser, quelles compétences internaliser, quelle architecture cible. Un livrable qui ne pose pas ces choix-là n'est pas un audit, c'est un inventaire.

Les 5 piliers à auditer

Sur les diagnostics que nous conduisons en grande entreprise, cinq piliers couvrent l'essentiel du périmètre. L'ordre n'est pas neutre : commencer par les cas d'usage permet de calibrer la profondeur d'audit nécessaire sur les quatre autres.

Sur ces cinq piliers, c'est rarement le même qui est le plus mature. Une banque que nous avons auditée affichait un niveau 3 sur les données (lac data structuré depuis 2019, gouvernance solide) mais un niveau 1 sur les compétences GenAI (zéro profil senior, dépendance totale aux intégrateurs). Le diagnostic ne se résume jamais à un score global — il décrit un profil, et c'est ce profil qui conditionne la roadmap.

La grille de maturité IA en 4 niveaux

Quatre niveaux suffisent à classer un cas d'usage ou un pilier. Les frontières ne sont pas absolues — elles décrivent un moment dans une trajectoire. Une organisation peut très bien être au niveau 3 sur un cas et au niveau 1 sur tous les autres.

Grille de maturité IA — synthèse des modèles BCG, Gartner et CIGREF, adaptée au contexte ETI/CAC40 français

Le passage du niveau 2 au niveau 3 est statistiquement le plus difficile. Le BCG documente que la majorité des entreprises restent bloquées au stade pilote — non par manque de cas, mais par manque de capacité à industrialiser. Un audit qui ne diagnostique pas spécifiquement ce passage rate l'enjeu central.

Le livrable type d'un audit IA

Un livrable d'audit IA exploitable tient en quatre parties. Tout le reste — annexes techniques, benchmarks détaillés, glossaires — relève du complément.

La quatrième section est celle qui distingue un audit utile d'un audit cosmétique. Sans arbitrages explicitement formulés, le livrable est un constat — pas une décision. Et un constat sans décision, en grande entreprise, finit dans un drive partagé que personne n'ouvre douze mois plus tard.

Le piège du benchmark

La demande arrive presque toujours : « comment on se situe par rapport à nos concurrents ? ». La tentation est de répondre par un benchmark abstrait — courbes Gartner, classements McKinsey, rapports sectoriels du CIGREF. Le problème : ces benchmarks comparent à un best-in-class flou, sans tenir compte du contexte métier, de la régulation sectorielle, de la trajectoire historique de l'organisation.

Un benchmark utile repose sur trois principes :

• Comparer à des pairs réellement comparables. Un assureur ne se mesure pas à Microsoft, ni même à BNP Paribas. Il se mesure à trois ou quatre acteurs de son sous-segment, avec une stack et une régulation similaires.
• Comparer sur des dimensions sur lesquelles on a des données fiables. Le nombre de cas en prod est documentable. La « culture data » ne l'est pas — elle est invisible de l'extérieur, et tous les rapports qui prétendent la mesurer extrapolent à partir de signaux faibles.
• Comparer pour décider, pas pour rassurer. Le bon benchmark fait remonter une question stratégique précise (« nos pairs ont tous internalisé leurs équipes data, pourquoi pas nous ? »), pas un graphique radar.

L'enquête McKinsey State of AI montre que les écarts intra-sectoriels sont systématiquement plus grands que les écarts inter-sectoriels. Autrement dit : votre principal concurrent en maturité IA n'est pas dans une autre industrie — il est dans la vôtre, parfois sur le même périmètre, et c'est ce différentiel qui compte.

5 signaux que votre maturité IA est sur-évaluée

L'auto-évaluation par les directions métier surestime presque toujours la maturité réelle. Cinq signaux faibles, croisés avec ce que nous voyons en mission, permettent de recalibrer.

Comment passer de l'audit à la roadmap actionnable

Un audit qui s'arrête à la photographie produit un rapport. Un audit qui débouche sur une roadmap produit une décision. La transition entre les deux repose sur trois mécaniques peu discutées en amont, et qui font la différence à la livraison.

Trancher l'ambition avant la technique. Avant de discuter architecture, modèles ou plateformes, le COMEX doit arbitrer un niveau d'ambition explicite à 18 mois : rester en exploration ciblée, monter au niveau industrialisation sur deux ou trois cas, ou viser le scale sur l'ensemble d'un domaine métier. Sans cet arbitrage, la roadmap empile des chantiers sans logique d'ensemble — et chaque ligne hiérarchique pousse ses propres priorités.

Séquencer les chantiers transverses en fonction des cas. Les chantiers data, MLOps ou gouvernance ne sont pas des prérequis abstraits — ils sont déclenchés par des cas d'usage précis. Reconstruire un data lake « pour préparer l'IA » sans cas d'usage attaché est l'erreur classique : douze mois de travaux, zéro impact métier, et une fenêtre concurrentielle perdue. Un audit utile rattache chaque chantier transverse aux deux ou trois cas qui le justifient économiquement.

Identifier les arbitrages COMEX dès le début. Les vraies décisions ne sont pas techniques : recrutement vs. partenariat, cloud public vs. souverain, build de plateforme interne vs. solution éditeur. Ces arbitrages ne se prennent pas en réunion technique, ils se préparent. Le livrable d'audit doit les formuler explicitement, avec deux ou trois options chiffrées et leurs implications — pas une recommandation fermée qu'on présente comme évidente.

Sur les missions où nous accompagnons un audit, la phase « livrable + roadmap » prend systématiquement plus de temps que la phase « collecte + diagnostic ». C'est un signal de qualité : un diagnostic bien fait pose des questions qui méritent qu'on s'y arrête, pas des réponses qu'on déroule.

Comment nous intervenons sur ce sujet

Nous conduisons des audits IA pour des banques, assureurs, industriels et acteurs du retail depuis plusieurs années — toujours avec la même logique : partir des cas d'usage métier, pas du référentiel. Le format type articule entretiens dirigeants, atelier data, revue technique des cas existants, et synthèse avec arbitrages COMEX. Le livrable couvre les cinq piliers, propose une grille de maturité argumentée, et débouche sur une roadmap 12-18 mois avec jalons trimestriels.

L'audit recoupe nos expertises GenAI et data engineering — c'est ce qui permet de rendre des constats opérationnels et non purement stratégiques. Pour des exemples de missions menées, voir nos références. Pour la phase suivante — celle de l'industrialisation après l'audit — nous avons documenté la méthode dans un article dédié à l'intégration IA en entreprise.

Ce qui change vraiment la donne

L'audit IA n'est pas un exercice intellectuel — c'est l'investissement qui détermine la trajectoire des dix-huit mois suivants. Mal mené, il produit un rapport qui rassure le COMEX et ne déplace rien. Bien mené, il pose deux ou trois arbitrages stratégiques qui débloquent l'industrialisation et alignent l'organisation sur une cible commune. La différence ne tient pas à la longueur du livrable ni au nombre d'entretiens : elle tient à la capacité de l'audit à formuler des questions assez précises pour que le COMEX ne puisse plus les reporter.