Shadow AI (IA fantôme) : détecter, gouverner et réduire l'usage non maîtrisé de l'IA en entreprise

Sommaire

• Le Shadow AI, c'est quoi ?
• Les trois couches de Shadow AI que personne ne voit
• Shadow IT et Shadow AI : ce qui change vraiment
• Pourquoi les ETI sont les plus exposées
• Les cinq risques réels, classés par probabilité
• Comment détecter le Shadow AI avec ce que vous avez déjà
• Valider, encadrer, remplacer ou bloquer : la grille d'arbitrage
• Gouverner l'usage de l'IA en continu
• Shadow AI et conformité : RGPD, AI Act, NIS2
• Vos 30 premiers jours
• Comment Corma vous aide à détecter et gouverner le Shadow AI
• Questions fréquentes

Introduction

En douze mois, la question que se posent les DSI a changé de nature. On ne demande plus « faut-il adopter l'IA ? », on demande « combien d'outils d'IA tournent déjà chez nous sans que nous le sachions ? »

Les données de recherche racontent la même histoire. En France, le volume Google Ads sur la requête shadow ai est passé de 590 recherches mensuelles en juillet 2025 à 1 900 en juin 2026. Personne ne cherche la définition d'un problème qu'il n'a pas déjà.

Le contenu qui répond à ces recherches, en revanche, a été écrit pour un autre lecteur. Il présuppose un SOC, un CASB, une passerelle web sécurisée et une solution DLP déjà en place. Une entreprise de 200 personnes avec trois personnes à la DSI ne dispose de rien de tout cela, et le problème existe quand même.

Ce guide prend un autre chemin. Il traite le Shadow AI pour ce qu'il est réellement dans une organisation de taille intermédiaire : non pas un problème de filtrage réseau, mais un problème de SaaS et d'identités. Ce recadrage a une conséquence pratique immédiate, à savoir que vous pouvez commencer la détection cette semaine avec des systèmes que vous payez déjà. Pour un panorama plus large des menaces, notre article sur les risques introduits par le Shadow AI couvre le sujet en complément.

Le Shadow AI, c'est quoi ?

Le Shadow AI (ou IA fantôme) est l'utilisation d'outils, de modèles ou de fonctionnalités d'intelligence artificielle au sein d'une organisation sans que la DSI, l'équipe sécurité ou le DPO en aient connaissance, les aient évalués ou validés. Il couvre trois réalités : les applications autonomes comme un compte ChatGPT personnel utilisé au travail, les fonctions IA activées silencieusement dans un logiciel déjà sous licence, et les agents ou intégrations IA à qui l'on a accordé un accès aux données de l'entreprise via OAuth.

Le terme emprunte sa structure au Shadow IT, et le parallèle est utile, mais les deux notions ne sont pas interchangeables. Le Shadow IT est un problème de visibilité sur les applications qui existent. Le Shadow AI est un problème de visibilité sur la destination de vos données. Un outil de gestion de projet non validé conserve les données que votre équipe y saisit. Un assistant IA non validé peut transmettre ces données à un modèle tiers, les conserver, et dans certaines configurations les utiliser pour son entraînement.

Cette différence explique pourquoi le Shadow AI progresse plus vite que le Shadow IT ne l'a jamais fait. L'adoption ne demande ni achat, ni installation, ni budget. Un onglet de navigateur et une adresse professionnelle suffisent.

Ce que le Shadow AI n'est pas

Trois précisions utiles d'emblée, parce qu'elles déterminent la réponse à y apporter :

• Ce n'est pas malveillant. Dans l'immense majorité des cas, les collaborateurs qui adoptent une IA non validée cherchent à travailler plus vite, pas à exfiltrer quoi que ce soit. Traiter le Shadow AI comme une menace interne produit la mauvaise politique.
• L'interdiction ne le règle pas. Bloquer les domaines d'IA connus déplace l'usage vers les appareils et comptes personnels, où vous perdez la dernière visibilité qui vous restait.
• Ce ne sont pas seulement des chatbots. Le chatbot est la partie visible. Les deux couches situées en dessous portent les problèmes les plus difficiles, ce qui fait l'objet de la section suivante.

Les trois couches de Shadow AI que personne ne voit

La quasi-totalité du contenu publié sur le Shadow AI décrit une seule catégorie : des collaborateurs qui utilisent des applications d'IA non validées. Cette description couvre environ un tiers de l'exposition réelle. En pratique, le Shadow AI opère sur trois couches distinctes, chacune exigeant une méthode de détection différente.

Couche 1 : les applications d'IA autonomes

Le cas connu. Un collaborateur s'inscrit à un service d'IA avec son adresse professionnelle ou personnelle, y colle des documents internes, et aucune revue sécurité n'a lieu. Cette couche est détectable via la télémétrie navigateur, les journaux de l'annuaire d'identités et les données de dépense.

Couche 2 : les fonctions IA dans les logiciels déjà validés

L'angle mort que presque personne ne traite. Votre CRM livre une fonction de synthèse par IA. Votre helpdesk ajoute un générateur de réponses. Votre outil de prise de notes active un assistant par défaut dans une mise à jour mineure. Rien de tout cela n'apparaît dans un inventaire applicatif, puisque l'application était déjà validée. L'éditeur est dans votre liste, le contrat est signé, et la revue sécurité a été menée il y a dix-huit mois sur un produit qui ne se comporte plus de la même façon.

Cette couche est invisible pour la supervision réseau, puisque le trafic va vers un domaine déjà autorisé. Elle n'est détectable que par le suivi des évolutions éditeurs et la relecture des contrats, ce qui explique précisément qu'elle reste non gouvernée.

Couche 3 : les agents IA et les intégrations OAuth

La couche qui progresse le plus vite. Un collaborateur connecte un assistant IA à Google Workspace ou Microsoft 365 via un écran de consentement, lui accordant un accès en lecture aux mails, aux fichiers ou à l'agenda. Aucun logiciel installé, aucun mot de passe partagé, mais un jeton permet désormais à un modèle tiers de lire en continu des données de l'entreprise.

C'est la couche la plus proche d'une véritable urgence, et c'est celle que votre annuaire d'identités peut vous montrer dès aujourd'hui. Elle rejoint directement la question plus large de la gouvernance des agents IA, qui devient incontournable à mesure que les outils agentiques se diffusent.

Shadow IT et Shadow AI : ce qui change vraiment

Le Shadow AI est un sous-ensemble du Shadow IT, mais le considérer comme une simple variante du même problème conduit à réutiliser des contrôles qui ne se transposent pas. Le tableau ci-dessous précise les divergences.

La conséquence pratique : un inventaire applicatif reste nécessaire, mais il n'est plus suffisant. Il vous faut un inventaire des flux de données et des permissions accordées, pas seulement des logiciels installés. C'est le même glissement structurel qui a fait du SaaS sprawl un sujet de gouvernance et non plus de licences.

Pourquoi les ETI sont les plus exposées

Les entreprises de 50 à 500 collaborateurs occupent la pire position possible sur le Shadow AI, pour quatre raisons structurelles.

• Assez d'autonomie pour adopter, pas assez de process pour gouverner. Les équipes ont un budget et une liberté d'outillage. L'achat au niveau du département est la norme. Personne ne relit un abonnement à 20 euros par mois.
• Aucune fonction sécurité dédiée. La DSI compte typiquement deux à cinq personnes qui couvrent le support, l'infrastructure, le réseau et la conformité. Aucun analyste n'a pour mission de surveiller l'adoption de l'IA.
• Aucun des outils que la littérature présuppose. Pas de CASB, pas de SWG, pas de SOC, pas de DLP dédiée. Les contrôles recommandés par la plupart des guides publiés ne sont tout simplement pas disponibles.
• Une exposition réglementaire pleine malgré tout. Une entreprise française de 200 personnes qui traite des données clients relève intégralement du RGPD. Si elle opère dans un secteur couvert, NIS2 s'applique aussi. La taille ne réduit ni l'une ni l'autre de ces obligations.

Le résultat est un écart de gouvernance qui se creuse tout seul : l'adoption accélère, la capacité de contrôle reste plate.

Les cinq risques réels du Shadow AI, classés par probabilité

La plupart des listes de risques sur ce sujet classent par gravité, ce qui produit un catalogue de scénarios extrêmes que peu d'équipes reconnaissent. Le classement ci-dessous est établi par probabilité, plus utile pour décider quoi traiter en premier.

1. L'exposition de données via les prompts (quasi certain)

L'hypothèse de départ doit être que cela se produit déjà. Les collaborateurs collent des dossiers clients, des clauses contractuelles, du code et des chiffres financiers dans des interfaces d'IA parce que c'est le chemin le plus court vers une réponse. Une enquête relayée par Infosecurity Magazine en septembre 2024 indiquait que 38 % des salariés reconnaissaient avoir partagé des informations professionnelles sensibles avec des outils d'IA sans autorisation de leur employeur. Ce chiffre est antérieur à la vague d'adoption actuelle : à considérer comme un plancher, pas comme une estimation à jour.

2. L'exposition réglementaire RGPD et AI Act (élevé)

Dès lors que des données personnelles entrent dans un outil d'IA sans contrat de sous-traitance, sans mécanisme de transfert documenté et sans inscription au registre des traitements, vous avez une non-conformité qui préexiste à tout incident. L'article 83(5) du RGPD plafonne la tranche haute des amendes administratives à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. La CNIL a par ailleurs publié des recommandations spécifiques sur l'usage de l'IA, ce qui rend l'argument « nous ne savions pas » difficile à tenir.

3. Les comptes IA orphelins après un départ (élevé, et jamais vérifié)

Ce risque n'apparaît dans presque aucun contenu publié sur le Shadow AI, ce qui est remarquable vu son caractère mécanique. Un collaborateur crée un compte IA rattaché à son adresse professionnelle. Il quitte l'entreprise. Sa boîte mail est désactivée, ses accès SSO révoqués, et le compte IA reste actif, contenant tout ce qu'il y a versé, parfois toujours facturé sur une carte de l'entreprise. Comme l'outil n'a jamais été inventorié, il n'entre jamais dans la checklist d'offboarding et n'apparaît dans aucune revue d'accès.

Toute organisation qui pilote un provisionnement et un onboarding automatisés ferme cette faille par construction. Celles qui s'appuient sur une checklist manuelle ne la ferment pas, puisque la checklist ne couvre que les applications connues.

4. Les dépenses IA non maîtrisées et dupliquées (élevé)

Le Shadow AI est traité presque partout comme un sujet de sécurité, ce qui masque sa dimension financière. Une même organisation paie fréquemment trois abonnements IA redondants dans trois équipes, au tarif par utilisateur, sur des cartes personnelles remboursées en note de frais. Rien n'apparaît au budget logiciel puisque rien n'a été acheté. Remettre cela à plat est l'objet de la gestion des abonnements SaaS destinée à réduire les dépenses logicielles.

5. La qualité des sorties et le risque de décision (modéré)

Des productions de modèle non relues qui entrent dans des livrables clients ou du code portent un risque d'erreur et de biais que personne n'a évalué. Réel, mais plus lent que les quatre précédents, et mieux traité par la formation que par l'outillage.

Comment détecter le Shadow AI avec ce que vous avez déjà

C'est ici que la plupart des guides s'arrêtent à « surveillez l'activité réseau » et passent à la suite. Voici la version opérationnelle, construite autour de cinq sources de données qu'une ETI possède déjà. Aucun nouvel outil de sécurité n'est nécessaire pour le premier passage.

Deux principes gouvernent la combinaison de ces sources.

Commencez par les accès OAuth, pas par les journaux réseau. Passer en revue les accès applicatifs tiers dans la console d'administration Google Workspace ou le panneau des applications d'entreprise de Microsoft Entra ID prend moins d'une heure et fait remonter la couche la plus grave du Shadow AI : les outils déjà autorisés à lire les données de l'entreprise. La plupart des équipes n'ont jamais ouvert cet écran. C'est l'heure la plus rentable disponible sur ce sujet.

Réconciliez les identités avec les dépenses, puis avec l'usage. Chaque source prise seule donne une image incomplète : l'annuaire d'identités rate ce qui passe par des identifiants personnels, les données de dépense ratent les offres gratuites où vit l'essentiel du Shadow AI, et la télémétrie navigateur rate les appareils personnels. Croiser trois sources transforme une liste partielle en inventaire défendable, et c'est exactement cette logique qu'automatise une plateforme de SaaS Management.

Un passage de découverte structuré fait généralement remonter deux à trois fois plus d'outils d'IA que la DSI ne l'anticipait. C'est cet écart, et non un outil en particulier, qui change la conversation avec la direction.

Valider, encadrer, remplacer ou bloquer : la grille d'arbitrage

La découverte produit une liste. Une liste sans règle de décision produit de la paralysie, ce qui explique que tant de démarches Shadow AI s'arrêtent après l'audit. Toutes les sources crédibles s'accordent sur le fait que l'interdiction pure se retourne contre vous, mais presque aucune ne fournit les critères de remplacement.

Quatre issues couvrent tous les outils découverts. Les variables déterminantes sont la sensibilité des données concernées et l'existence d'un équivalent validé.

Deux règles font fonctionner cette grille en pratique.

• Tout blocage exige une alternative nommée le même jour. Un blocage sans remplacement est une demande de travailler moins vite, et il sera contourné. C'est le mode d'échec le plus fréquent des politiques d'usage de l'IA.
• La consolidation est le lieu de l'argument budgétaire. Trois équipes qui paient trois outils d'IA similaires deviennent un contrat unique avec un tarif volume, une administration centralisée et un contrat de sous-traitance. L'économie dégagée finance le travail de gouvernance, ce qui permet à la démarche de survivre à son premier arbitrage budgétaire.

Gouverner l'usage de l'IA en continu

Un audit ponctuel a une durée de vie d'environ un trimestre sur cette catégorie. Gouverner signifie que l'inventaire se maintient tout seul. Quatre mécanismes portent la charge.

Un inventaire vivant des applications d'IA. Pas un tableur mis à jour quand quelqu'un y pense. Une découverte continue, pour qu'un nouvel outil d'IA apparaisse dans l'inventaire quelques jours après son premier usage, et non au prochain audit.

Les outils d'IA dans les revues d'accès. Si vos revues d'accès automatisées et conformes ne couvrent que vos systèmes cœur, chaque outil d'IA est hors périmètre par défaut. Les y intégrer transforme un exercice de conformité périodique en mécanisme qui attrape les comptes orphelins et les intégrations surprivilégiées.

Les outils d'IA dans le cycle arrivée, mobilité, départ. Tout compte IA découvert doit entrer immédiatement dans la séquence d'offboarding. Quand le provisionnement et le déprovisionnement tournent en automatisation plutôt que sur une liste manuelle, la couverture s'étend aux outils nouvellement découverts sans que personne réécrive une procédure.

Une politique qui autorise plutôt qu'elle interdit. Les politiques d'usage de l'IA qui tiennent en pratique nomment ce qui est validé pour quelle classification de données, expliquent le raisonnement, ouvrent une voie rapide pour demander un nouvel outil, et sont revues chaque trimestre. Les politiques construites comme des listes d'interdictions vieillissent mal et sont contournées.

Shadow AI et conformité : RGPD, AI Act, NIS2

Pour une entreprise européenne, le Shadow AI se situe à l'intersection de trois cadres réglementaires arrivés à dix-huit mois d'intervalle. Chacun impose une obligation que l'usage non gouverné de l'IA vient directement contrarier.

Le fil conducteur des trois est le même : vous ne pouvez pas documenter, évaluer ou déclarer un usage d'IA que vous n'avez pas inventorié. Chacune de ces obligations a l'inventaire pour condition préalable, et c'est pourquoi la découverte est une activité de conformité, pas seulement de sécurité.

La localisation des données mérite une note à part. Quand un collaborateur utilise un service d'IA grand public, le lieu de traitement est celui que l'éditeur applique par défaut, généralement hors Union européenne, sans mécanisme de transfert documenté de votre côté. Pour une organisation qui s'est engagée contractuellement sur un hébergement européen, ou qui l'a inscrit dans un périmètre de certification, le Shadow AI peut invalider cet engagement sans bruit. Corma traite ce point au niveau de la plateforme : les données sont hébergées dans l'Union européenne et la plateforme est certifiée ISO/IEC 27001:2022, dont la mesure A.5.23 de l'Annexe A porte sur la sécurité de l'information dans l'usage des services cloud, catégorie exacte dont relèvent les outils d'IA non validés. Les équipes qui travaillent sur les exigences NIS2 y retrouveront la même dépendance à l'inventaire. Les recommandations de l'ANSSI sur la sécurisation des systèmes d'IA vont dans le même sens.

Vos 30 premiers jours

Une séquence qui produit un inventaire défendable et un premier jeu de décisions en un mois, sans aucun nouvel outil en semaines 1 et 2.

Comment Corma vous aide à détecter et gouverner le Shadow AI

Le Shadow AI est un problème de découverte suivi d'un problème d'identités. Corma est une plateforme européenne qui couvre les deux au même endroit, ce qui est la raison de sa présence sur ce sujet : la plupart des éditeurs traitent soit la visibilité SaaS, soit la gouvernance des accès, rarement les deux ensemble.

• Découverte continue des SaaS et des IA. Corma maintient l'inventaire sur les trois couches, applications connectées en OAuth et intégrations dans votre tenant Google Workspace ou Microsoft 365 incluses. C'est la visibilité complète qui permet d'identifier le Shadow IT, appliquée à l'IA.
• Connecteurs IDP natifs. Google Workspace, Microsoft Entra ID, Okta et JumpCloud se connectent directement : la réconciliation identités, applications et permissions se fait sans export manuel.
• SaaS Management et IAM convergés. La gouvernance des identités et le SaaS Management partagent le même inventaire, ce qui fait entrer automatiquement un outil d'IA découvert dans les revues d'accès et l'offboarding.
• Coûts et risque au même endroit. Les abonnements IA dupliqués ou orphelins remontent à côté des constats de sécurité, ce qui finance le travail de gouvernance au lieu de le concurrencer.
• Européen par construction. Hébergement UE, alignement RGPD, certification ISO/IEC 27001:2022, reporting compatible NIS2, sans les questions de transfert qu'une plateforme américaine soulève. Corma est reconnu dans le Gartner® Magic Quadrant™ 2025 des plateformes de SaaS Management.
• Déploiement en semaines. L'onboarding complet d'une ETI se termine typiquement en moins d'un mois, ce qui compte quand l'inventaire bloque tout le reste.

Pour un exemple concret en environnement régulé, le déploiement d'IGA chez Satelia montre comment découverte et gouvernance des accès fonctionnent ensemble dans la santé.

Visualisez votre propre inventaire IA et SaaS avant de décider quoi que ce soit : demandez une démo Corma.

Questions fréquentes

Le Shadow AI, c'est quoi exactement ?

Le Shadow AI, ou IA fantôme, désigne l'usage d'outils, de modèles ou de fonctionnalités d'intelligence artificielle dans une entreprise sans validation ni supervision de la DSI, de la sécurité ou du DPO. Il inclut les comptes d'IA grand public utilisés au travail, les fonctions IA activées dans des logiciels déjà sous contrat, et les assistants IA connectés à vos données via OAuth.

Quel est un exemple de Shadow AI ?

L'exemple le plus courant est un collaborateur qui utilise un compte ChatGPT ou Claude personnel pour résumer des documents internes ou rédiger un livrable client, sans validation DSI ni contrat de sous-traitance. Deux exemples moins évidents comptent davantage : une fonction IA activée par défaut dans un logiciel que votre entreprise licencie déjà, et un assistant IA autorisé via un écran de consentement OAuth à lire vos données Google Workspace ou Microsoft 365.

Quels sont les principaux risques du Shadow AI ?

Cinq, classés par fréquence réelle : l'exposition de données sensibles via les prompts, l'exposition réglementaire au titre du RGPD et de l'AI Act, les comptes IA orphelins qui survivent au départ d'un collaborateur, les dépenses IA dupliquées et non maîtrisées, et les productions de modèle non relues qui entrent dans des décisions métier. Les troisième et quatrième sont ceux que la plupart des organisations n'ont jamais vérifiés.

Comment détecter le Shadow AI dans son entreprise ?

Commencez par examiner les accès applicatifs tiers accordés en OAuth dans la console d'administration de votre annuaire d'identités : cela prend moins d'une heure et fait remonter la catégorie la plus à risque. Croisez ensuite trois sources : les journaux de connexion de l'annuaire, les données de dépense et de cartes bancaires, et la télémétrie navigateur ou poste de travail. Aucune source n'est complète seule, donc c'est le recoupement qui produit un inventaire fiable.

Quelle différence entre Shadow IT et Shadow AI ?

Le Shadow IT est l'usage de tout logiciel ou matériel non validé. Le Shadow AI est le cas plus étroit des outils et fonctions d'IA non validés, et il porte deux risques que le Shadow IT n'a pas : les données saisies dans un prompt peuvent être conservées ou servir à entraîner un modèle tiers, et les capacités d'IA peuvent apparaître dans un logiciel que vous avez déjà validé, ce qui les rend invisibles à un inventaire applicatif.

Faut-il interdire les outils d'IA au travail ?

Non, et les retours d'expérience convergent sur ce point. Bloquer les domaines d'IA connus pousse l'usage vers les appareils et comptes personnels, où la visibilité disparaît totalement. L'approche qui fonctionne consiste à inventorier ce qui est utilisé, valider un petit nombre d'outils avec des conditions contractuelles adaptées à chaque niveau de sensibilité, et publier une voie rapide de validation pour toute nouvelle demande.

Le Shadow AI a-t-il un impact sur la conformité RGPD ?

Oui. Des données personnelles qui entrent dans un outil d'IA sans contrat de sous-traitance, sans mécanisme de transfert documenté et sans inscription au registre des traitements constituent une non-conformité qui existe avant tout incident, avec des amendes pouvant atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial au titre de l'article 83(5). Du côté de l'AI Act, l'obligation de littératie en IA de l'article 4 suppose que vous sachiez quels systèmes d'IA vos équipes utilisent, ce qui est impossible sans inventaire.