Shadow AI : pourquoi l’IA fantôme est d’abord un problème de gouvernance

L’essentiel

• Le shadow AI désigne tout usage d’un outil, d’une fonctionnalité ou d’un agent d’IA dans l’entreprise sans contrôle de gouvernance, et il est aujourd’hui impliqué dans environ une violation de données sur cinq.
• La presse spécialisée en cybersécurité en fait un sujet de fuites de données. C’est tout autant un problème de découverte gouvernance : on ne peut ni enregistrer, ni évaluer, ni auditer ce que l’on ne voit pas.
• Shadow AI, prolifération de l’IA (AI sprawl) et nomenclature IA (AI bill of materials) sont trois notions distinctes que beaucoup confondent. Les traiter séparément est une condition de passage à l’échelle.
• Le règlement IA européen, la norme ISO/IEC 42001 et le NIST AI Risk Management Framework partagent une hypothèse implicite : l’organisation tient un inventaire complet de ses systèmes d’IA. Le shadow AI invalide silencieusement cette hypothèse.
• La réponse n’est pas l’interdiction (contre-productive) mais un programme de découverte crédible alimentant un registre d’IA unique, qui sert à la fois à l’enregistrement Annexe VIII et au registre des risques ISO 42001.

Définir le shadow AI sans le réduire

Le shadow AI, ou IA fantôme, désigne l’usage d’un outil, d’une capacité ou d’un agent d’intelligence artificielle au sein d’une organisation, sans connaissance ni approbation des fonctions responsables de la gouvernance de l’IA : RSSI, délégué à la protection des données, responsable IA, conformité, ou toute personne portant ce mandat dans l’organigramme.

L’image commune est celle du salarié qui colle un document confidentiel dans ChatGPT. C’est un cas, ce n’est pas la catégorie entière. Le shadow AI prend au moins trois formes, et les traiter comme un problème unique conduit à des contrôles incomplets.

Les outils GenAI grand public autonomes. Chatbots gratuits, générateurs d’images, assistants de code, transcripteurs de réunions accessibles via un navigateur ou un compte personnel. La surface classique, la plus simple à détecter par la télémétrie réseau.

Les fonctionnalités d’IA intégrées dans des SaaS approuvés. L’éditeur a activé une nouvelle fonction d’IA en cours de contrat. Soudain, le CRM résume les comptes rendus clients avec un modèle de fondation, la suite collaborative rédige des courriels automatiquement, l’outil de gestion de projet propose des risques. Le dossier achats n’a rien approuvé. La réalité dit autre chose. IBM observe une bascule de 74 à 96 pour cent d’adoption GenAI chez les salariés d’entreprise entre 2023 et 2024, en grande partie par cette voie d’intégration (IBM Think).

Les modèles, scripts et agents internes. Un analyste affine un modèle open source sur son poste. Un ingénieur plateforme connecte un agent à un serveur Model Context Protocol avec des droits étendus. Une équipe marketing entraîne un GPT personnalisé sur un corpus sensible. Aucun de ces flux ne passe par un chatbot tiers public, donc la détection shadow-IT traditionnelle les rate, mais la même faille de gouvernance s’installe.

La distinction utile avec le shadow IT relève de la portée. Le shadow IT couvre tout actif technologique non approuvé. Le shadow AI est son sous-ensemble en forme d’IA, et il porte des risques spécifiques : sortie probabiliste, hallucination, données d’entraînement opaques, dérive de modèle, contamination de la chaîne de valeur, et un régime réglementaire dédié (le règlement IA) qui attribue explicitement la responsabilité de ces caractéristiques.

C’est ce dernier point qui bascule le shadow AI du registre cybersécurité au registre gouvernance. La sécurité a deux décennies de pratique sur les SaaS non approuvés. Le travail neuf des deux prochaines décennies, c’est gouverner l’IA dont on ignorait l’existence.

Shadow AI, AI sprawl, AI bill of materials : trois concepts distincts

Trois notions voisines sont utilisées comme synonymes dans les blogs et les notes d’analystes. Ce ne sont pas la même chose, et les confondre produit un programme de gouvernance flou.

Le shadow AI est une question d’autorisation. Un système est dans l’ombre dès lors qu’aucune fonction responsable n’a tracé son existence. Un outil parfaitement approuvé mais utilisé par une équipe non habilitée reste du shadow AI, parce que la piste d’audit manque.

L’AI sprawl est une question de multiplication, que les systèmes soient autorisés ou non. Une organisation qui possède 80 outils d’IA approuvés, dispersés dans 40 équipes, sans catalogue central, fait face à de la prolifération, pas à du shadow AI au sens strict. La prolifération est ce qui survient quand la découverte réussit mais que la consolidation échoue.

L’AI bill of materials (nomenclature IA) est l’artefact documentaire, calqué sur le software BOM. Pour un système donné, la nomenclature liste les composants : modèle de fondation et version, sources de données d’entraînement et d’affinage, bases vectorielles, API tierces appelées à l’inférence, points de contrôle humain. La nomenclature n’est pas un problème : c’est un livrable, et c’est ce qui rend la remédiation du shadow AI auditable.

Un programme mature traite les trois : faire émerger le shadow AI par la découverte, réduire la prolifération par la consolidation, et produire une nomenclature IA par système pour que le registre ait du contenu, pas seulement un nom et un propriétaire.

Les quatre forces qui font exploser le phénomène

Dans un preprint de 2026, Silic et ses coauteurs proposent de penser le shadow AI comme un échec sociotechnique de gouvernance plutôt que comme un incident de sécurité, en arguant que le caractère génératif, opaque et autonome de l’IA crée des défis que la gouvernance IT existante n’absorbe pas (Silic et al., Preprints.org). Leur cadre rejoint l’expérience du terrain. Quatre forces se renforcent.

La consumérisation de la GenAI. Un compte OpenAI gratuit ou un abonnement à quinze euros par mois donne accès à une capacité qui exigeait, il y a deux ans, un cycle achats et une facture cloud. Le frottement qui freinait l’outillage non approuvé a disparu.

L’IA intégrée dans les SaaS approuvés. Quand un éditeur sous contrat active une fonction d’IA par défaut, le contrat n’a pas changé, mais les flux de données, si. Peu de RSSI disposent de l’instrumentation contractuelle nécessaire pour savoir quand leur cinquième fournisseur SaaS le plus important a discrètement activé la génération augmentée par récupération sur les données tenant.

Les agents et la couche MCP. Les serveurs Model Context Protocol et les agents autonomes constituent une surface neuve que les passerelles web sécurisées n’ont pas été conçues pour inspecter. Un agent qui invoque un serveur MCP hérite des permissions de ce serveur, qui peuvent dépasser celles de l’utilisateur appelant. Sans visibilité dédiée, le rayon d’explosion d’un déploiement d’agent est inconnu.

L’écart de vitesse entre IT et métiers. Les salariés font appel au shadow AI pour la même raison qu’ils faisaient appel au shadow SaaS : ça va plus vite que le chemin officiel. Comme le note un explicatif de Splunk, interdire les outils GenAI grand public sans proposer d’alternative interne ne fait qu’enfoncer l’usage plus profondément dans l’ombre (Splunk).

Les chiffres sont sans ambiguïté. Gartner prévoit que plus de 40 pour cent des entreprises auront connu un incident de sécurité ou de conformité lié au shadow AI d’ici 2030 (communiqué Gartner, novembre 2025). Le rapport IBM 2025 sur le coût des violations de données chiffre la prime des violations liées au shadow AI à environ 4,63 millions de dollars contre 3,96 millions pour les violations standard, et constate que seules 37 pour cent des organisations disposent d’une politique de gestion ou de détection du shadow AI (IBM Cost of a Data Breach 2025). Une violation sur cinq implique aujourd’hui le shadow AI comme facteur contributif.

La direction est claire. La question stratégique est de savoir si l’organisation traite la faille comme un problème de sécurité à colmater, ou comme une discipline de gouvernance à bâtir.

Le risque de gouvernance : ce que le shadow AI casse réellement

Le récit cybersécurité est intuitif : des données sensibles sortent du périmètre, le régulateur sanctionne, les clients partent. Il est vrai, et d’autres articles le racontent bien. Le récit gouvernance est moins raconté et plus consequent. Trois régimes réglementaires et normatifs convergent, et tous trois reposent sur une hypothèse unique que le shadow AI invalide.

Le mandat d’enregistrement du règlement IA

L’article 49 du règlement IA exige que les fournisseurs de systèmes d’IA à haut risque listés à l’annexe III s’enregistrent et enregistrent le système dans la base de données publique de l’UE avant la mise sur le marché ou la mise en service. Les déployeurs autorités publiques doivent enregistrer leur usage. Le contenu attendu, défini à l’annexe VIII, comprend l’identité du fournisseur, le nom et la finalité du système, les instructions d’usage, le certificat d’évaluation de conformité, le statut (sur le marché, retiré, rappelé) et les synthèses d’évaluation d’impact (Article 49, Annexe VIII).

L’implication pour le shadow AI est directe. Si un outil utilisé dans l’organisation, approuvé ou non, relève des catégories à haut risque de l’annexe III (sélection à l’embauche, notation de crédit, identification biométrique, infrastructures critiques, éducation, application des lois, migration, justice), l’enregistrement est une obligation légale, pas une bonne pratique. Un système fantôme qui s’avère relever de l’annexe III est un défaut d’enregistrement, précisément le type de non-conformité factuelle que les autorités nationales de surveillance du marché poursuivront.

Les obligations des déployeurs aux articles 26 et 27 aggravent l’exposition. Le déployeur doit suivre les instructions d’usage du fournisseur, tenir des journaux, garantir la supervision humaine et, pour les déployeurs publics ou sectoriels visés, conduire une analyse d’impact sur les droits fondamentaux (FRIA). Le déploiement fantôme casse silencieusement les quatre, parce que le système n’a jamais figuré dans l’inventaire qui les aurait déclenchées.

Cette section est purement descriptive du texte juridique. Le but n’est pas de dire ce que le lecteur devrait en faire. Le but est de montrer que le shadow AI convertit une obligation documentaire en défaillance documentaire, sans que personne ne s’en aperçoive avant l’audit.

La déclaration d’applicabilité ISO/IEC 42001

La clause 6 d’ISO/IEC 42001 exige que l’organisation identifie les risques et opportunités liés à l’IA, les traite et documente le traitement dans un registre des risques IA. L’annexe A fournit un catalogue de contrôles recommandés, et la déclaration d’applicabilité (Statement of Applicability) précise les contrôles inclus ou exclus, avec justification.

Le shadow AI brise cette structure de deux façons. D’une part, le registre des risques est incomplet par construction : un système inconnu n’a pas de traitement documenté. D’autre part, la déclaration d’applicabilité affirme que certains contrôles s’appliquent à certains systèmes. Dès qu’un système fantôme entre dans le périmètre, ces affirmations deviennent inexactes, et les organisations certifiées s’exposent à une non-conformité au ré-audit.

L’implication pratique est qu’une certification 42001 ne vaut que ce que vaut le programme de découverte qui la sous-tend. Les organisations qui préparent leur certification découvrent souvent, douloureusement, que l’écart entre la liste des IA officielles et l’empreinte IA réelle dépasse ce que le calendrier d’audit peut absorber.

La fonction MAP du NIST AI RMF

Le NIST AI Risk Management Framework 1.0 structure les activités d’IA de confiance en quatre fonctions : GOVERN, MAP, MEASURE, MANAGE. GOVERN pose la politique et la responsabilité. MAP, deuxième fonction, exige ce que le NIST appelle l’analyse contextuelle : connaître pour chaque système d’IA sa finalité, ses propriétaires, ses données d’entraînement, son statut de déploiement, ses points d’intégration (NIST AI RMF).

Le shadow AI met MAP en échec à la racine. On ne peut pas caractériser le contexte d’un système qu’on n’a pas identifié. Le NIST AI 600-1 (profil GenAI) ajoute une couche en listant douze risques propres à la GenAI (vie privée des données, sécurité de l’information, chaîne de valeur, configuration humain-IA, confabulation, biais nuisible, etc.) qui exigent tous une visibilité au niveau système pour être gérés (NIST AI 600-1).

L’OWASP AI Exchange, projet phare d’OWASP depuis mars 2025, formule le même constat côté catalogue de contrôles : toute menace et tout contrôle suppose un actif connu. Là où l’actif est dans l’ombre, le modèle de menace se tait par défaut (OWASP AI Exchange). Les projets de normes harmonisées du CEN-CENELEC en cours d’élaboration (prEN 18228 et prEN 18282) suivent la même logique au niveau européen.

Trois référentiels, une dépendance non énoncée : il faut savoir quelle IA on a.

Découvrir le shadow AI : cinq couches indispensables

La découverte doit être stratifiée parce qu’aucun signal unique ne couvre toutes les formes de shadow AI. Les cinq couches ci-dessous, exécutées en combinaison, offrent une couverture défendable.

Couche 1 : télémétrie réseau et SaaS. Journaux DNS, passerelle web sécurisée, CASB, extensions navigateur révèlent le trafic vers les points de terminaison IA grand public connus. Capte le cas classique ChatGPT-dans-un-navigateur. Rate tout ce qui tourne à l’intérieur d’un SaaS approuvé ou derrière une IP d’entreprise.

Couche 2 : audit identité. Historique des autorisations OAuth, journaux SSO, écrans de consentement révèlent quels services d’IA tiers ont reçu un accès à l’identité corporative. Capte les services qui s’appuient sur l’identité Google Workspace ou Microsoft 365. Rate les usages totalement isolés.

Couche 3 : audit des fonctionnalités d’IA intégrées dans les SaaS approuvés. Conversation directe avec chacun des vingt principaux éditeurs : quelles fonctions sont activées par défaut, lesquelles sont opt-in, où vont les données. Travail ingrat de pilotage achats, mais c’est ce qui fait remonter la forme intégrée que la télémétrie ne voit pas.

Couche 4 : programmes d’amnistie et enquêtes. Une fenêtre d’amnistie clairement communiquée pendant laquelle les salariés déclarent leurs usages d’IA sans sanction. Avec une enquête courte et honnête, on obtient une découverte qualitative qu’aucune télémétrie n’égale. La condition de réussite est la sécurité psychologique, pas l’outil.

Couche 5 : DLP sensible à l’IA. Inspection au niveau des prompts dans les canaux approuvés, à la recherche de motifs d’exfiltration de données sensibles. C’est l’axe d’investissement actuel des éditeurs de cybersécurité et la couche mise en avant par la plupart des blogs. Nécessaire, mais pas suffisante isolément.

Aucune organisation n’atteint cent pour cent de couverture. L’objectif réaliste est un balayage suffisamment fin pour que l’inconnu résiduel soit petit, documenté et décroissant. L’erreur consiste à surinvestir une seule couche et à appeler cela découverte.

De la découverte au registre d’IA

La découverte sans destination, c’est un tableur à usage unique qui se périme en un trimestre. La destination est un registre d’IA central qui héberge chaque système connu, dans une structure qui satisfait simultanément le régulateur, les organismes de normalisation et la fonction risque interne.

Ce que le registre doit capter par système :

• Identité : nom, propriétaire, sponsor métier, sponsor technique
• Finalité : usage prévu, usages interdits, populations d’utilisateurs en périmètre
• Données : classifications des entrées et sorties, sources d’entraînement et d’affinage, bases de récupération
• Chaîne fournisseurs : modèle de fondation et version, prestataire d’affinage, environnement d’hébergement, API tierces appelées à l’inférence
• Statut cycle de vie : pilote, production, retiré ; date de mise en service
• Niveau réglementaire : classification de risque règlement IA, applicabilité annexe A ISO 42001, profil NIST AI RMF
• Risque résiduel : après contrôles, avec l’accepteur nommé
• Preuves : liens vers les FRIA, évaluations de conformité, fiches de modèle, fiches de données

La section nomenclature IA de chaque entrée du registre est ce qui rend le système auditable. Lignée de modèle, composition des données d’entraînement, index de récupération, dépendances API en aval forment un graphe qu’un auditeur externe peut vérifier face aux déploiements réels.

Bien fait, le registre est la source unique qui alimente trois livrables aval : le dossier d’enregistrement annexe VIII lorsque un système relève du règlement IA, le registre des risques et les annexes de la déclaration d’applicabilité ISO 42001, et les sorties MAP du NIST AI RMF. Construits en trois tableurs séparés, ils dérivent les uns par rapport aux autres en quelques semaines. Construits une fois, avec le bon schéma, ils donnent un effet de levier de gouvernance.

Sortir le shadow AI de l’ombre : un plan en 60 jours

La séquence compte, parce que la découverte sans accompagnement génère du ressentiment et enfonce le shadow AI plus profondément.

Semaines 1 à 2. Annonce de la fenêtre d’amnistie. Communication centrée sur l’objectif : habiliter l’IA, pas l’interdire. Mise en place du squelette du registre avec un schéma minimal. Capture de la télémétrie de référence sur les cinq couches.

Semaines 3 à 4. Balayage de découverte. Combinaison télémétrie, audit identité, conversation avec les éditeurs SaaS, enquête d’amnistie. Surprise prévisible dans la catégorie IA intégrée.

Semaines 5 à 6. Triage. Niveau réglementaire d’abord, criticité métier ensuite. Identifier les systèmes qui correspondent à l’annexe III du règlement IA, qui portent une obligation d’enregistrement indépendamment de la maturité du reste du programme.

Semaines 7 à 8. Migration du triage dans le registre. Pour chaque système de niveau un, joindre la nomenclature IA, la FRIA quand elle s’applique, la fiche de modèle, la classification des données. Pour les niveaux inférieurs, capter identité et finalité, et reporter la documentation profonde au sprint suivant.

Au-delà du jour 60, le programme devient opérationnel : l’admission de nouveaux systèmes remplace la découverte, le registre alimente les pipelines réglementaire et d’audit, et le sprint suivant attaque la prolifération (consolidation, déclassement, retrait).

Le mode d’échec à surveiller est le sur-engineering. Un registre parfait que personne ne met à jour vaut moins qu’un registre approximatif qui couvre quatre-vingts pour cent des systèmes et que l’on rafraîchit trimestriellement. Démarrer léger, faire couler les entrées, et laisser la pression réglementaire affiner la précision avec le temps.

Questions fréquentes

Qu’est-ce que le shadow AI, expliqué simplement ? Le shadow AI désigne l’usage d’un outil, d’une fonction ou d’un agent d’IA dans une organisation, dont les responsables de la gouvernance IA n’ont pas connaissance. Cela peut être un salarié qui utilise un chatbot gratuit, une fonction d’IA activée dans un SaaS approuvé, ou un modèle interne tournant sur un poste de travail. Le dénominateur commun est l’absence d’inventaire et donc de gestion.

Shadow AI et shadow IT, est-ce la même chose ? Non. Le shadow IT couvre l’ensemble des actifs technologiques non approuvés. Le shadow AI en est le sous-ensemble en forme d’IA, et il porte des risques spécifiques : sorties probabilistes, hallucination, données d’entraînement opaques, dérive de modèle, et un régime réglementaire dédié dans l’UE. Les contrôles shadow IT attrapent une partie du shadow AI, mais ratent les formes intégrées et internes.

Quelle est l’ampleur du phénomène en 2026 ? Gartner estime que plus de 40 pour cent des entreprises subiront un incident de sécurité ou de conformité lié au shadow AI d’ici 2030. Le rapport IBM 2025 indique qu’environ une violation sur cinq implique aujourd’hui le shadow AI, et que ces violations coûtent en moyenne 0,67 million de dollars de plus que les violations standard. Seules 37 pour cent des organisations déclarent disposer d’une politique de gestion ou de détection.

Le règlement IA m’oblige-t-il à inventorier le shadow AI ? Le règlement IA n’utilise pas le mot « inventaire » mais l’effet est identique. L’article 49 exige l’enregistrement des systèmes à haut risque de l’annexe III avant mise sur le marché. Les articles 26 et 27 imposent au déployeur des obligations (tenue de journaux, supervision, instructions d’usage, FRIA pour les déployeurs visés) qui ne peuvent être satisfaites sans savoir quels systèmes sont en périmètre. Un système fantôme qui s’avère à haut risque est, en pratique, une faille de conformité qui n’attend que l’enforcement.

Comment ISO 42001 traite-t-elle le shadow AI ? La clause 6 d’ISO/IEC 42001 exige un registre des risques IA. L’annexe A fournit un catalogue de contrôles, et la déclaration d’applicabilité indique lesquels s’appliquent à quels systèmes. Le shadow AI casse les deux : le registre des risques est incomplet par construction, et la déclaration d’applicabilité devient inexacte dès qu’un système fantôme entre en périmètre. C’est pour cette raison que les audits de certification commencent souvent par un exercice de découverte plutôt que par une revue de contrôles.

Quelle différence entre shadow AI et AI sprawl ? Le shadow AI relève de l’autorisation : un système est dans l’ombre quand la gouvernance ne le voit pas. L’AI sprawl relève de la multiplication : beaucoup de systèmes d’IA, approuvés ou non, qui se répandent sans catalogue central. On peut avoir de la prolifération sans ombre (tout est tracé, mais il y en a quatre-vingts) et de l’ombre sans prolifération (deux outils non approuvés, largement utilisés). Un programme mature traite les deux, et la nomenclature IA par système est le livrable qui relie les deux.

Que doit contenir un registre d’IA, au minimum ? Au minimum : identité du système et propriétaire, finalité et utilisateurs en périmètre, classifications des données, modèle de fondation et version, API tierces à l’inférence, statut de cycle de vie, niveau réglementaire, risque résiduel après contrôles, et liens vers les preuves (fiche de modèle, fiche de données, évaluation de conformité, FRIA). Chaque entrée alimente l’annexe VIII règlement IA, le registre ISO 42001 et la sortie MAP du NIST AI RMF.

Conclusion

Le shadow AI ne cèdera ni aux interdictions, ni à l’outillage de cybersécurité seul. C’est un problème de découverte gouvernance déguisé en problème de sécurité, et les organisations qui le traitent comme tel passeront les deux prochaines années à bâtir des registres, des nomenclatures IA et des traitements de risque qui survivent à un audit. Celles qui le traitent comme un problème de périmètre passeront ces deux mêmes années à courir après les incidents. Le livrable est identique dans les deux cas : un inventaire unique, à jour, crédible, de chaque système d’IA que l’organisation fait tourner. La question est de savoir si on le construit à son rythme ou sous pression du régulateur.