L'ombre de l'IA occupe les équipes sécurité depuis des années. Des employés utilisent ChatGPT pour leurs emails professionnels. Un commercial passe des données clients dans un outil gratuit de résumé. Un développeur colle du code propriétaire dans un assistant IA. Ce sont ces risques qui ont poussé les RSSI à élaborer des politiques d'usage de l'IA en 2024 et 2025.
Mais voici ce qui a changé : les employés ne se contentent plus d’utiliser l’IA fantôme. Ils la construisent.
Point de vue RSSI : pourquoi les agents construits par les employés changent le modèle de risque
La vraie question pour un RSSI n'est pas de savoir si les employés vont expérimenter avec des agents. Ils le font déjà. La question est de savoir si la sécurité peut voir quels agents existent, quels systèmes ils touchent, quelles identifiants ils héritent et quand ils manipulent des données réglementées. C'est pourquoi la gouvernance des agents doit s'ajouter à la découverte SaaS, DLP et contrôles d'identité, plutôt que d'être un projet d'innovation annexe.
Le passage de l'IA fantôme aux agents fantômes
Il y a une différence significative entre un employé qui utilise discrètement un outil SaaS non approuvé et un employé qui déploie discrètement un agent IA autonome exécutant des workflows en son nom, récupérant des données des systèmes de l'entreprise, prenant des décisions, envoyant des e-mails et agissant sans revue humaine.
Le premier problème est grave. Le second est fondamentalement différent par nature.
Les plateformes d'IA agentique sont devenues remarquablement accessibles. Des outils comme n8n, Make et Zapier offrent désormais des capacités natives d'agents IA. L'API Assistants d'OpenAI propose un niveau gratuit. Cursor et GitHub Copilot peuvent générer et déployer du code en quelques minutes. Ce qui nécessitait auparavant une équipe d'ingénieurs dédiée peut maintenant être construit par un analyste motivé en un week-end.
Et les analystes motivés font exactement cela.
Les chercheurs en sécurité et les observateurs du secteur ont identifié un nouveau phénomène en 2026 : des employés, souvent des contributeurs individuels techniquement compétents en finance, opérations ou marketing, créent des workflows autonomes connectés aux sources de données de l'entreprise comme les CRM, SharePoint, les API internes et les systèmes de messagerie. Ce ne sont pas des acteurs malveillants. Ce sont souvent des performants frustrés d'attendre que l'informatique livre quelque chose, alors ils l'ont fait eux-mêmes.
Le problème n'est pas l'intention. C'est la visibilité.
Pourquoi l'IA agentique fantôme est un problème plus complexe
Avec l'IA fantôme traditionnelle, la portée des dégâts est à peu près limitée à ce qu'un humain peut copier-coller dans une session. Un employé colle une proposition client dans ChatGPT. C'est un incident d'exposition de données, sérieux, mais limité.
Un agent autonome est une autre histoire. Un agent fantôme avec accès en lecture/écriture à un CRM peut extraire chaque affaire, chaque note de contact, chaque prévision, et les fournir à un LLM externe comme contexte à chaque exécution. S'il est connecté à la messagerie, il peut envoyer des centaines de messages avant que quelqu'un ne s'en aperçoive. S'il puise dans des API internes, il peut fuir des données structurées d'une manière presque impossible à détecter via les journaux DLP standards.
La dimension multi-agent aggrave la situation. Les architectures agentiques modernes ne lancent pas un seul workflow autonome, elles les enchaînent. Un employé peut déployer un « agent de recherche » qui déclenche un « agent de rédaction » qui déclenche un « agent d'envoi ». Chaque étape a son propre périmètre de permissions. Chaque transfert est une exposition potentielle de données. Et comme ces agents sont souvent construits sur des clés API personnelles et des comptes SaaS personnels, ils sont totalement hors inventaire des actifs informatiques.
48 % des professionnels de la sécurité classent désormais l’IA agentique comme leur principale préoccupation en matière de vecteur d’attaque pour 2026, selon une étude publiée plus tôt cette année. Ce n’est pas une exagération, cela reflète une réelle inquiétude face à la rapidité avec laquelle la surface d’attaque est passée de « quels outils SaaS les employés utilisent » à « ce que les employés construisent avec l’IA, et où cela s’exécute ».
Le fossé de gouvernance
La plupart des programmes de gouvernance IA en entreprise sont encore optimisés pour le problème précédent. Ils suivent l'utilisation des outils SaaS via la surveillance du navigateur ou des proxys réseau. Ils établissent des listes d'outils IA approuvés et non approuvés. Ils organisent des formations sur ce qu'il ne faut pas coller dans ChatGPT.
Rien de tout cela ne détecte un agent fantôme.
Un agent fantôme peut s'exécuter sur l'ordinateur portable d'un employé, un niveau gratuit cloud ou un runner GitHub Actions personnel. Il s'authentifie avec les identifiants de l'employé. Il accède aux données via les mêmes API que l'employé est légitimement autorisé à utiliser. Du point de vue réseau ou identité, il ressemble exactement à l'employé qui fait son travail, ce qui explique précisément pourquoi il est invisible.
Le déficit de gouvernance ici ne concerne pas la politique. La plupart des organisations ont déjà des politiques qui interdisent techniquement ce genre de pratiques. Le problème est la détection. On ne peut pas gouverner ce qu’on ne voit pas.
C’est pourquoi la conversation en sécurité IA d’entreprise évolue de « quelles sont vos politiques IA » vers « quelle est votre pile d’observabilité IA ». Il ne suffit pas de dire aux employés qu’ils doivent obtenir une approbation pour utiliser des outils IA si vous n’avez aucun moyen de détecter les déploiements IA non approuvés.
À quoi ressemble une gouvernance IA efficace aujourd'hui
Les organisations qui réussissent traitent la gouvernance IA comme la sécurité des endpoints : surveillance continue, détection d'anomalies et réponse rapide, pas seulement des documents de politique et des sessions de formation.
Concrètement, cela signifie plusieurs choses.
Premièrement, inventorier au-delà du navigateur. Les agents fantômes n’apparaissent pas toujours dans les journaux de trafic web. Une visibilité efficace nécessite de surveiller l’utilisation des identifiants API, les flux d’autorisation OAuth et les schémas de sortie de données, pas seulement les sites web visités par les employés.
Deuxièmement, comprendre ce qu’est un comportement « normal » pour les charges de travail IA. Les identifiants d’un seul employé extrayant 10 000 enregistrements CRM dans un lot automatisé à 2h du matin n’est pas un comportement humain normal. Mais cela peut sembler tout à fait normal si vous vérifiez uniquement si l’accès était techniquement autorisé.
Troisièmement, étendre la politique aux déploiements, pas seulement aux outils. La question ne devrait pas être seulement « cet outil est-il approuvé ? » mais « ce déploiement d’agent est-il approuvé, quelles données accède-t-il, et qui est responsable de ses actions ? »
Enfin, rendre le chemin autorisé plus simple que le non autorisé. L’IA fantôme et les agents fantômes prolifèrent lorsque les employés estiment que les outils approuvés ne sont pas suffisants, ou lorsque le processus d’approbation prend six semaines. Le moyen le plus rapide de réduire votre surface d’IA fantôme est de développer des capacités IA internes qui répondent réellement aux besoins des employés.
En résumé
L'IA fantôme était une donnée connue. Les agents fantômes sont l'évolution pour laquelle la plupart des programmes de sécurité d'entreprise n'étaient pas prêts. La combinaison de plateformes agentiques accessibles, d'employés motivés et de cadres de gouvernance conçus pour le problème précédent crée un angle mort significatif.
La bonne nouvelle, c’est que ce n’est pas ingouvernable. Il suffit d’élargir la définition de ce que signifie « visibilité IA », passer du suivi des outils utilisés par les employés à la compréhension de ce que ces outils font, à un niveau opérationnel, dans votre environnement.
C'est un problème plus complexe. Mais c'est celui qu'il faut résoudre en 2026.
