Le Shadow IT changeait de main, le Shadow AI change de nature
Un outil IA non référencé ne se contente plus de stocker un document. Il peut recevoir des données internes, se connecter à des applications et, s’il s’agit d’un agent, exécuter des actions.
Le phénomène n’est pas nouveau dans son principe. Depuis des années, des collaborateurs adoptent des applications, des espaces de stockage ou des extensions sans passer par les circuits officiels de leur entreprise. Ce que l’intelligence artificielle modifie, c’est ce qu’un outil non référencé est capable de faire une fois installé.
La première vague se comprenait assez simplement. Un collaborateur ouvrait un assistant grand public et y copiait un document interne pour en obtenir une synthèse. Le risque portait alors sur les données transmises, et il se traitait comme une fuite d’information ordinaire. Cette question demeure, mais les outils ont changé d’échelle : certains agents interagissent désormais avec des fichiers locaux, des environnements de développement, un navigateur ou plusieurs applications, et une partie d’entre eux s’exécute directement sur le poste de travail.
La frontière qui compte n’est donc plus entre outil autorisé et outil interdit, mais entre utiliser une IA et donner à une IA la capacité d’agir. Les éditeurs suivent ce déplacement. Microsoft a présenté Agent 365 à Ignite en novembre 2025 comme une couche de gestion des agents, puis, en annonçant sa disponibilité générale le 1er mai 2026, a mis en avant la découverte et la gestion des agents IA exécutés localement sur des postes Windows. Que le sujet soit traité par une console d’administration en dit long : il quitte le registre de l’usage pour celui de la gouvernance.
Le Shadow AI est un signal avant d’être une infraction
La réaction naturelle consiste à y voir un problème de discipline. C’est passer à côté de l’essentiel. Quand un collaborateur adopte spontanément un outil, c’est le plus souvent qu’il répond à un besoin que son environnement officiel couvre mal : analyser un document plus vite, automatiser une tâche répétitive, produire du code, retrouver une information dispersée.
Il en découle une règle simple : plus l’écart se creuse entre les outils fournis et ceux accessibles sur le marché, plus les usages parallèles apparaissent. Interdire sans comprendre fait disparaître l’usage visible, rarement le besoin qui l’a fait naître. C’est le même mécanisme que celui décrit dans notre décryptage sur l’adoption de l’IA en entreprise : l’écart entre ce qui est distribué et ce qui est réellement utile.
Ce qui se perd vraiment, c’est la visibilité
Une organisation ne gouverne que ce qu’elle connaît. Un agent déployé officiellement peut être documenté : son propriétaire, sa finalité, les modèles qu’il utilise, les données auxquelles il accède, les actions qu’il a le droit d’effectuer. Avec le Shadow AI, cette chaîne disparaît d’un coup.
L’effet est cumulatif, et c’est ce qui le rend coûteux. Auditer les permissions d’un agent suppose de savoir qu’il existe. Vérifier les données qu’il manipule suppose de connaître ses connexions. Analyser un incident suppose que son activité soit visible dans les traces. Chacun des mécanismes de gouvernance que nous décrivons dans notre décryptage sur la gouvernance agentique présuppose la découverte. Sans elle, ils ne s’appliquent à rien.
Une politique d’interdiction seule ne tiendra pas le rythme
L’écosystème évolue plus vite que les cycles de référencement des outils d’entreprise. De nouvelles applications apparaissent en continu, les éditeurs ajoutent des fonctions agentiques à des logiciels déjà déployés, et un développeur peut installer localement un assistant spécialisé sans rien demander à personne. Une liste tenue à jour trimestriellement décrit un paysage qui a déjà changé.
L’état de l’outillage confirme que la découverte n’est pas un acquis. Chez Microsoft, les pages consacrées au Shadow AI et aux agents locaux dans le centre d’administration Microsoft 365 sont documentées en préversion publique, au sein du programme Frontier. Elles reposent sur une liste d’agents connus, désignés nommément, parmi lesquels OpenClaw, Claude Desktop, ChatGPT Desktop, Ollama Desktop, Claude Code, Gemini CLI, GitHub Copilot CLI et plusieurs extensions VS Code. Le blocage n’est pour l’instant proposé que pour OpenClaw, via une stratégie Intune, et détection comme blocage ne s’appliquent qu’aux postes Windows gérés et inscrits dans Microsoft Intune.
Ce constat ne disqualifie pas l’outillage, il en situe la maturité. Une découverte fondée sur un catalogue d’agents reconnus hérite en partie de la limite qu’elle doit corriger : ce qui n’y figure pas reste invisible, au même titre que les postes non gérés et les environnements hors Windows. La documentation de Microsoft introduit d’ailleurs une distinction utile entre les agents locaux, outils de développement délibérément installés et configurés, et le Shadow AI proprement dit, applications et agents autonomes déployés sans visibilité de la DSI. Les deux catégories relèvent de décisions différentes, et les confondre conduit à traiter un poste de développeur équipé comme un incident de conformité.
Une approche opérationnelle tient en quatre temps : découvrir, qualifier, décider, proposer une alternative. La découverte identifie les usages. La qualification cherche à comprendre leur finalité, les données manipulées et les accès requis. L’organisation autorise alors, restreint ou bloque. Mais lorsqu’un outil est bloqué parce qu’il répond mal à un besoin réel, le travail n’est pas terminé : reste à savoir comment couvrir ce besoin autrement.
Le Shadow AI comme source de découverte des cas d’usage
Ce dernier point change la façon de regarder le phénomène. Supposons que plusieurs équipes commerciales utilisent spontanément un assistant externe pour analyser leurs comptes rendus de rendez-vous. L’organisation peut bloquer l’outil et clore le dossier. Elle peut aussi lire ce comportement comme une information : il existe probablement un besoin transverse d’analyse automatisée de ces documents, qu’aucune solution interne ne couvre.
Les usages observés alimentent alors la cartographie des cas d’usage et aident à prioriser ce qu’il faut construire. Il ne s’agit évidemment pas de légitimer tout outil adopté sans autorisation, mais de séparer deux questions que l’on traite trop souvent ensemble : le problème de conformité, et le besoin métier qui l’a provoqué. Le premier se règle par une décision, le second par une feuille de route.
Autoriser un outil ne suffit pas, il faut autoriser un usage et des permissions
À mesure que les usages se multiplient, une simple liste d’outils autorisés montre ses limites, parce qu’un même outil peut être acceptable pour une tâche et inadapté pour une autre. Un assistant peut convenir pour produire des contenus génériques et pas pour manipuler des données sensibles. Un agent peut être approuvé sur un périmètre de permissions restreint et devenir problématique dès que ce périmètre s’élargit, sans que son nom ni sa fiche de référencement ne changent.
La gouvernance doit donc porter sur le triptyque outil, usage, permissions plutôt que sur le seul nom de l’outil. C’est plus exigeant qu’une politique binaire, mais c’est la granularité qui correspond à la réalité des agents. Et cela suppose que chaque agent puisse être identifié individuellement. C’est précisément l’objet de Microsoft Entra Agent ID, que son éditeur décrit comme un cadre d’identité et de sécurité étendant Entra aux agents IA pour les authentifier, les autoriser, les gouverner et les protéger. Nous développons ce point dans notre décryptage sur la question de l’identité agentique.
À retenir
Le Shadow AI n’est pas une nouvelle version du Shadow IT. Avec les agents, un outil non maîtrisé dispose de capacités d’action sur l’environnement de l’entreprise, ce qui déplace le sujet de la fuite de données vers l’exécution non contrôlée.
Le meilleur indicateur d’une gouvernance IA saine n’est probablement pas l’absence de Shadow AI, mais la capacité à le détecter assez tôt pour comprendre pourquoi il existe et décider quoi en faire.
