La question a été posée en comité de direction et il a fallu quarante minutes pour ne pas y répondre : combien d’agents IA tournent chez nous en ce moment. L’informatique dit quatre, ceux qui sont passés par l’architecture. Les opérations disent sept, parce qu’elles comptent ceux que leur équipe a montés dans l’outil d’automatisation. Le marketing ne sait pas, mais l’assistant qui résume les réunions et les envoie par mail est là depuis mars. Personne ne ment et personne n’a raison, parce que personne n’a la liste.
La thèse en une ligne : le recensement passe avant la gouvernance. On n’applique pas une politique à une flotte qu’on n’a pas comptée, et presque toutes les initiatives de gouvernance de l’IA commencent par la politique — le document, le comité, le cadre — sur un ensemble que personne ne sait énumérer. L’inventaire des agents IA n’est pas la partie ennuyeuse du projet de gouvernance : c’en est la condition préalable.
Inventaire des agents IA en entreprise : pourquoi le recensement passe avant la gouvernance
Une politique d’agents dit ce que chacun a le droit de faire, qui l’approuve et qui répond en cas d’erreur. Tout cela s’applique à une liste. Si la liste n’existe pas, la politique gouverne les agents passés par le processus — c’est-à-dire précisément les moins risqués, puisque quelqu’un les a relus — et laisse le reste dehors. Résultat : un cadre de gouvernance respecté à cent pour cent sur la moitié de la flotte, et un comité serein pour de mauvaises raisons.
L’écart est mesuré. La Cloud Security Alliance a publié le 21 avril 2026 l’enquête Autonomous but Not Controlled, avec un résultat inconfortable : 82% des organisations ont trouvé dans leur infrastructure des agents IA dont elles ignoraient l’existence, et 65% ont connu au moins un incident lié à des agents sur les douze derniers mois. Parmi ces incidents, 61% se sont soldés par une exposition de données, 43% par une interruption opérationnelle et 35% par un coût financier direct.
Le détail qui transforme le chiffre en thèse arrive ensuite : 68% des répondants déclarent avoir une bonne visibilité sur leurs agents. Les deux chiffres viennent du même échantillon. La confiance dans la visibilité n’est pas de la visibilité ; c’est ce qu’on ressent quand il n’y a aucune liste contre laquelle vérifier. Et ce n’était pas une frayeur isolée : 41% avaient découvert des agents inconnus plus d’une fois dans la même année.
Périmètre de ces chiffres, dit clairement : enquête en ligne auprès de 418 professionnels IT et sécurité d’organisations de tailles et de pays variés, menée en janvier 2026, commandée et financée par un éditeur de sécurité des identités d’agents — Token Security — avec un questionnaire co-construit avec les analystes de la CSA. Elle dimensionne un problème que le sponsor vend résoudre, et il faut la lire avec ça sous les yeux. Utile pour l’ordre de grandeur, pas comme mesure de notre part ni comme promesse de résultat.
La pente pointe dans la même direction sous un autre angle. Gartner, dans sa note du 28 avril 2026 sur la gestion de la prolifération des agents, prévoit qu’en 2028 une entreprise moyenne du Fortune 500 mondial aura plus de 150 000 agents en service, contre moins de 15 en 2025, et ajoute que seules 13% des organisations estiment avoir la bonne gouvernance d’agents. La deuxième des six étapes recommandées consiste, littéralement, à construire un inventaire centralisé. Périmètre : une prévision d’analyste sur de grandes entreprises mondiales, pas un chiffre du marché français ni la mesure de quoi que ce soit. Ce qui compte ici n’est pas le nombre, c’est la pente. Une flotte qui grossit comme ça ne se compte pas après coup.
D’où sortent les agents que tu n’as jamais enregistrés
La mauvaise image mentale, c’est l’employé rebelle qui monte un agent en cachette. Ça arrive, mais ce n’est pas le volume. Le volume vient de ce que chaque outil que tu paies déjà a activé le sien, et que personne n’a vu là une décision à autoriser.
| D’où ça sort | Comment ça apparaît | Pourquoi personne ne l’a enregistré |
|---|---|---|
| Automatisation interne et scripts | Un flux monté par quelqu’un pour ne plus faire une tâche hebdomadaire à la main, et qui appelle maintenant un modèle au passage | Né comme script, pas comme agent, et aucune politique IA ne s’appliquait aux scripts |
| Plateformes de LLM : assistants et outils maison | Un assistant configuré avec des documents internes et un accès à un ou deux outils | Ça se crée en quelques minutes depuis une interface, sans aucune création de fiche ni aucun achat |
| SaaS avec automatisation incluse | Le CRM, l’ERP ou l’outil de tickets qui sort sa fonction agentique dans une mise à jour | Tu ne l’as pas acheté : on te l’a activé. La décision a été prise par l’éditeur dans sa feuille de route |
| Flux de développement | Un agent qui relit du code, ouvre des tickets ou déploie, monté par l’équipe elle-même | Il vit dans la chaîne d’outils d’ingénierie, qui n’entre presque jamais dans le périmètre de l’inventaire IA |
Ces quatre voies sont, dans cet ordre, celles qui reviennent le plus dans l’enquête de la CSA : automatisation interne ou scripting (51%), plateformes de LLM y compris assistants et outils maison (47%), SaaS avec automatisation intégrée (40%) et flux créés par les développeurs (40%). Aucune des quatre n’exige que quelqu’un décide de mettre un agent. C’est pour ça que le recensement ne se fait pas en demandant qui a déployé un agent : il faut demander quels outils vous avez et ce que chacun fait déjà tout seul.
Et il y a une seconde moitié du problème, qui se découvre plus tard : les agents qu’on a cessé d’utiliser et que personne n’a éteints. Dans la même enquête, seules 21% des organisations ont un processus formel de retrait. Un agent abandonné ne disparaît pas : il garde son identifiant, ses droits et son accès, et reste une identité valide sur tes systèmes longtemps après la mort de son cas d’usage. La CSA parle de dette de retrait, et c’est la raison pour laquelle la fiche a besoin d’une date d’entrée et d’une procédure d’extinction dès le premier jour. Quels identifiants et quel périmètre accorder à chacun, on le détaille dans quels droits donner à un agent IA ; l’inventaire, c’est ce qui garde cette décision consultable deux ans plus tard.
Les cinq champs que doit contenir la fiche de chaque agent
Un inventaire sert ou ne sert à rien selon ce qu’on peut décider avec. Cinq champs par agent suffisent à arbitrer ; à vingt, personne ne le remplit. Voilà les cinq, avec la question opérationnelle à laquelle chacun répond :
| Champ | La question à laquelle il répond | Ce qui arrive s’il manque |
|---|---|---|
| Propriétaire | Qui j’appelle quand cet agent fait quelque chose de bizarre | L’incident fait le tour de trois équipes avant de trouver quelqu’un capable de l’arrêter |
| Ce qu’il touche | Quels systèmes il lit et dans lesquels il écrit | Impossible d’estimer les dégâts d’une panne, donc toute panne est traitée comme grave ou comme bénigne, et les deux coûtent cher |
| Avec quel identifiant | Sous quelle identité il agit et jusqu’où va cette identité | En révoquant un accès, on casse des choses dont personne ne savait qu’elles en dépendaient |
| Depuis quand | Depuis combien de temps il tourne et qui l’a autorisé à l’époque | On ne distingue plus ce que quelqu’un a approuvé de ce qui est simplement là depuis longtemps |
| Comment on l’éteint | La procédure exacte pour l’arrêter sans casser le processus qu’il porte | Le frein à main s’improvise le jour de l’incident, le pire jour pour le concevoir |
Les cinq sont volontairement peu nombreux. La tentation est d’ajouter le modèle utilisé, le coût mensuel, la version du prompt, le responsable technique et le responsable métier. Tout cela est utile et tout cela transforme l’inventaire en formulaire que personne ne remplit. Cinq champs, le propriétaire en a pour trois minutes. Vingt champs, un cabinet les remplit une fois et ils sont périmés en six semaines.
L’inventaire est une liste ennuyeuse, pas un produit
Le mode d’échec le plus courant n’est pas de ne jamais commencer : c’est de commencer trop bien. La demande de visibilité sur nos agents se transforme en projet avec outil de découverte, tableau de bord, intégrations et comité de suivi. Six mois plus tard il y a une démo et toujours pas de liste.
Un tableur à jour vaut mieux qu’un tableau de bord périmé. Pas parce que le tableur est meilleur — il ne l’est pas — mais parce que toute la valeur de l’inventaire tient à ce qu’il reflète aujourd’hui, et ça dépend d’une habitude, pas d’un outil. Les outils de découverte aident vraiment quand tu as déjà la liste et que tu veux trouver ce qui t’a échappé : ils ne remplacent pas le recensement, ils l’auditent.
Ce qui devient possible quand ils sont comptés, et pas avant
Avec la liste sur la table, ce qui était des conversations devient des tâches. On peut classer par risque et exiger une validation humaine seulement là où ça compte, au lieu de tout freiner pareil. On peut revoir quels agents justifient encore leur accès et retirer les autres. On peut savoir, quand un modèle change ou qu’une intégration tombe, ce qui va casser et qui il faut prévenir. Cette fonction continue — politiques, trace de chaque action, gestion des incidents et conformité — c’est ce qu’on monte et qu’on opère dans gouverner les agents IA de ton entreprise, et l’inventaire en est le premier livrable, pas une étape préalable qu’on saute.
L’ordre compte peu quand le risque est déjà là. Si la question du jour n’est pas combien en avons-nous mais lequel va nous créer un problème cette semaine, la priorité c’est le confinement : droits minimaux, validation humaine sur ce qui coûte de l’argent ou touche à des personnes, et un frein à main qui marche vraiment. C’est éviter que tes agents IA partent en vrille. Le recensement se fera quand même, mais après avoir baissé la température.
Et il y a une décision que l’inventaire met à nu dès qu’il existe : jusqu’où chaque agent décide tout seul. L’échelle de droits et de preuves qui la tranche est dans les niveaux d’autonomie d’un agent, et le cadre plus large de contrôle sur ce que tu as déjà automatisé, dans gouvernance et contrôle de l’automatisation IA. Les deux questions se répondent sur la liste. Sans elle, ce sont des opinions bien argumentées.
Comment faire le recensement en une semaine
Pas besoin d’un projet. Il faut une semaine et quelqu’un qui a l’autorité de poser la question.
- Commence par la liste des outils, pas par celle des agents. Prends l’inventaire SaaS que les achats ou l’IT tiennent déjà et marque ceux qui ont sorti des fonctions agentiques ou d’assistant. C’est là qu’est l’essentiel de ce que tu ne savais pas avoir.
- Demande par processus, pas par technologie. « Quelle partie de ton travail hebdomadaire est déjà faite par quelque chose d’automatique » remonte des agents que « avez-vous déployé des agents IA » ne remonte jamais.
- Passe en revue les identifiants et clés d’API actifs et cherche ceux qui n’ont personne derrière. Une identité non humaine sans propriétaire, c’est un agent sans fiche, ou un agent mort qui a encore les clés.
- Remplis les cinq champs et arrête-toi là. Pas de classification fine au premier passage : propriétaire, périmètre, identifiant, ancienneté et extinction suffisent déjà à arbitrer.
- Fais de l’inscription une exigence. Dès la semaine suivante, aucun nouvel agent ne reçoit d’identifiant sans être sur la liste. C’est la seule règle du processus, et c’est celle qui le garde vivant.
Rien de tout cela n’est sophistiqué, et c’est exactement pour ça qu’on le saute : ça ne brille pas en comité et ça ne ressemble pas à une stratégie IA. Mais le premier contrôle sur une flotte, c’est de savoir combien ils sont. Tout le reste — politiques, validations, audit, retrait — s’applique à une liste que quelqu’un a dû écrire à la main.