Imaginez la scène. Un lundi matin, une collègue du service comptabilité quitte l’entreprise après six ans de bons et loyaux services. Son badge est désactivé, sa boîte mail fermée, son ordinateur restitué. Tout est carré, tout est propre. Sauf que, quelque part dans un coin de votre système, un petit programme qu’elle avait bricolé un soir de trop-plein de travail continue de lire des fichiers, d’interroger une base de données et d’envoyer des synthèses… à personne. Ou pire : à quelqu’un qui ne devrait pas les recevoir.
Ce programme, c’est ce que les spécialistes de la sécurité appellent désormais un agent IA orphelin. Le phénomène est encore discret, mais il progresse au rythme de la démocratisation des outils d’automatisation. Et il pose une question aussi simple que redoutable : qui est responsable d’une machine qui travaille toute seule quand son créateur a disparu ?
| 📘 Définition pour les débutants Agent IA : un petit programme autonome, souvent construit avec un outil « sans code », qui accomplit une tâche à votre place (trier des e-mails, interroger une base de données, résumer des documents) et qui peut agir sans qu’un humain valide chaque geste. Agent IA orphelin : un agent dont le propriétaire a quitté l’entreprise (ou n’est plus identifiable), mais dont les identifiants et les accès restent actifs. |
Comment un agent devient-il orphelin ?
Personne ne décide un beau matin de fabriquer un orphelin. Le processus est banal, presque poli. Il tient en quatre étapes :
- La bonne idée. Un employé, lassé de trier cinquante e-mails par jour ou de recopier des chiffres d’un tableau à l’autre, monte un agent avec un outil grand public.
- Les clés remises. Pour fonctionner, l’agent a besoin d’accès : une boîte mail, un dossier partagé, une base clients. L’employé lui prête ses propres droits, ou crée une clé d’accès (un « jeton », ou token) qui fait l’affaire.
- Le départ. L’employé change de poste ou quitte la société. Le service informatique coupe son compte, comme le veut la procédure.
- L’oubli. L’agent, lui, n’a jamais figuré dans aucun inventaire. Sa clé d’accès vit sa vie, indépendante du compte de son créateur. Il continue donc à tourner.
Voilà le nœud du problème : un agent s’authentifie de façon autonome. Fermer la session de l’humain ne révoque pas nécessairement les autorisations que l’agent a reçues par ailleurs, ce que soulignent plusieurs acteurs du secteur qui citent parmi les cas typiques les agents créés dans Copilot Studio, les automatisations de type Zapier, les clés d’API intégrées, les agents bâtis dans des plateformes comme Salesforce et les connexions à des serveurs MCP.
L’image du robot aspirateur qui poursuit son ménage
Pour saisir l’enjeu, pensez à un robot aspirateur intelligent laissé dans des bureaux fermés à clé après le départ du prestataire de nettoyage. Personne ne l’a éteint, personne ne sait qui l’avait programmé, et il conserve pourtant l’accès à des pièces où plus aucun humain ne met les pieds. Tant qu’il aspire de la poussière, l’affaire est anodine. Mais si l’on remplace la poussière par des dossiers clients, du code source ou des données de paie, le tableau change du tout au tout.
Ajoutons une nuance importante : un aspirateur ne « décide » rien. Un agent IA, si. Il interprète, enchaîne des actions, s’adapte. Il est donc à la fois plus utile et plus imprévisible qu’un simple script.
Pourquoi ces orphelins sont dangereux
1. Des privilèges permanents que plus personne ne réexamine
Un agent reçoit souvent plus de droits que nécessaire, parce qu’il est plus rapide de tout autoriser que de peser chaque permission. Les spécialistes parlent de privilèges permanents : des accès accordés une fois, à vie. Un agent orphelin, lui, échappe au contrôle périodique des droits, faute de propriétaire pour dire « oui, on garde » ou « non, on coupe ».
2. Une surface d’attaque que personne ne surveille
Un pirate n’a pas toujours besoin de forcer une porte blindée : une porte oubliée lui suffit. Un agent orphelin, avec ses identifiants encore valides, est exactement cela. Atticus Tysen, directeur des systèmes d’information et de la sécurité chez Intuit, le résume ainsi dans InformationWeek : le risque, c’est que les agents prolifèrent, deviennent orphelins, puis « un vecteur d’attaque ».
3. Un comportement « normal » aux yeux des outils classiques
Les filtres de sécurité traditionnels voient un agent aspirer tout un dépôt de fichiers et concluent que l’application fait simplement son travail. Or, un agent ne reste pas statique : il puise, déplace et croise des données de sa propre initiative. Ce que l’on jugerait suspect chez un humain passe inaperçu chez lui.
4. Un trou dans la conformité
Un accès qui persiste sous une identité sans responsable actif pose un problème d’audit : à qui demander des comptes ? En Europe, où la gouvernance des accès et la supervision humaine des systèmes d’IA sont des sujets réglementaires, cette absence de propriétaire devient un vrai casse-tête.
| ⚠️ Attention Le danger n’est pas que l’agent devienne « méchant ». Il est qu’il reste crédule et bien équipé : s’il est manipulé (par exemple par une instruction malveillante glissée dans un document qu’il lit), il exécutera avec les droits qu’on lui a laissés. Et aucun humain ne verra rien passer. |
Quelques chiffres pour prendre la mesure
Les données précises sur les agents orphelins restent rares : la plupart des chiffres portent sur les identités non humaines (comptes de service, clés d’API, jetons, agents) dans leur ensemble. Ils donnent toutefois un bon ordre de grandeur du terrain sur lequel ces orphelins prospèrent.
| Constat | Chiffre rapporté | Source |
| Ratio identités non humaines / humaines | En moyenne 45 pour 1, jusqu’à 144 pour 1 en environnement cloud | Cloud Security Alliance (synthèse 2026) |
| Shadow AI et violations de données | 20 % des brèches, environ 670 000 $ de surcoût moyen | IBM, rapport 2025 (cité par la CSA) |
| Organisations très confiantes face aux attaques sur ces identités | Seulement 15 % | Cloud Security Alliance, analyse 2026 |
| Entreprises pouvant inventorier leurs identités non humaines | Moins d’un tiers | Delinea, cité par IT Social |
| 💡 Ces chiffres proviennent d’études, de synthèses et parfois d’éditeurs qui vendent des solutions de sécurité. Ils sont utiles pour l’ordre de grandeur, mais mieux vaut les lire avec du recul plutôt que comme des vérités absolues. |
Que faire concrètement ? Le guide de survie
Bonne nouvelle : on n’a pas besoin d’une armée d’experts pour réduire nettement le risque. Voici les réflexes que recommandent les spécialistes.
Recenser : on ne protège pas ce qu’on ne voit pas
Créez un registre des agents : qui l’a créé, à quoi il sert, à quels systèmes il accède, quelles clés il utilise. Certaines équipes y ajoutent une date de revue et un niveau de risque. Sans cet inventaire, tout le reste est de la poudre de perlimpinpin.
Nommer : un propriétaire, et un suppléant
Chaque agent doit avoir un responsable identifié et un remplaçant. Lorsqu’un collaborateur part, un mécanisme lié aux ressources humaines doit automatiquement réaffecter ses agents à un manager, ou les suspendre. C’est le principe de la « succession » : personne ne quitte l’entreprise sans passer le relais.
Restreindre : le moins de droits possible
Donnez à l’agent uniquement ce dont il a besoin (principe du moindre privilège). Un agent qui trie des e-mails n’a aucune raison de lire la base de paie. Préférez aussi des clés d’accès à durée de vie courte, renouvelées régulièrement : certains guides suggèrent, par exemple, une expiration maximale de 90 jours.
Surveiller : l’agent laisse des traces, lisez-les
Consignez ce que font les agents dans vos journaux de sécurité et prévoyez un interrupteur d’arrêt d’urgence (kill switch), ainsi qu’une validation humaine pour les opérations à haut risque.
Offrir une alternative légitime
Si l’entreprise ne propose aucun outil autorisé, les employés se débrouilleront avec ce qu’ils trouvent : c’est ainsi que naît le shadow AI, l’IA utilisée en dehors de tout cadre validé. Proposer une plateforme d’agents approuvée réduit la tentation de bricoler dans son coin.
| 📘 Exemple concret Une PME de logistique autorise ses équipes à créer des agents, mais impose trois règles : chaque agent est déclaré dans un tableau partagé, chaque départ déclenche une revue des agents du partant, et toute clé d’accès expire au bout de trois mois. Résultat : quand un responsable des achats s’en va, son agent de relance fournisseurs est repris par son successeur… ou arrêté en dix minutes. (Exemple illustratif fictif, construit pour l’explication.) |
Les cadres de référence à connaître
- OWASP publie un « Top 10 » consacré aux identités non humaines et un autre dédié aux applications agentiques, deux références utiles pour structurer une politique interne.
- NIST (États-Unis) a lancé en février 2026 une initiative de standards pour les agents IA et un projet sur leur identité et leur autorisation. Son cadre de gestion des risques évoque la mise hors service des systèmes, mais sans obligation contraignante.
- Union européenne : le règlement sur l’IA (AI Act) impose notamment une supervision humaine pour les systèmes à haut risque. Son calendrier d’application vient d’être ajusté par le paquet « Digital Omnibus » : vérifiez la date qui concerne réellement votre cas.
Notre lecture est simple : l’agent orphelin n’est pas un problème d’intelligence artificielle, c’est un problème d’organisation déguisé en problème technologique. Les entreprises ont mis des décennies à comprendre qu’un compte utilisateur doit être fermé quand quelqu’un s’en va. Il leur faut maintenant apprendre que la même règle vaut pour les créations de cet utilisateur. Le risque est d’autant plus sournois que l’agent est utile : on ne veut pas l’éteindre, alors on l’oublie.
Et vous, qu’en pensez-vous ? Quelques questions pour lancer la discussion :
- Dans votre entreprise, savez-vous combien d’agents ou d’automatisations tournent, et qui en est responsable ?
- Faut-il interdire aux employés de créer leurs propres agents, ou leur donner un cadre pour le faire en sécurité ?
- Un agent devrait-il s’éteindre automatiquement lorsque son créateur part, quitte à casser un processus utile ?
- Qui doit porter la responsabilité en cas d’incident : le créateur parti, son manager, ou le service informatique ?
Racontez-nous votre expérience en commentaire.