L’inventaire des agents IA : dix champs à connaître avant de les gouverner

Le 16 octobre, Anthropic a publié l’évolution de l’emploi au sein de l’entreprise. Un chiffre ressort. En mars 2026, le total des heures travaillées par ses agents autonomes et interactifs a dépassé pour la première fois celui des heures travaillées par ses employés. En août, les agents dirigés par des employés travaillaient six fois plus d’heures que les personnes qui les supervisaient.

Lisez les mises en garde avant de citer ce chiffre. Il décrit une seule entreprise, à l’avant-garde de l’adoption. Le temps des agents est mesuré en temps d’exécution, inférence et utilisation d’outils comprises. Le temps humain correspond à l’effectif multiplié par une semaine présumée de 40 heures. Les auteurs soulignent que l’adoption n’était pas aléatoire et que l’entreprise croissait rapidement, ce qui limite la portée des estimations de productivité.

Le constat de sécurité résiste à toutes ces réserves. Quand les agents travaillent plus d’heures que les personnes, la majeure partie de l’activité menée sous vos identifiants n’est plus humaine. Votre modèle de sécurité a été conçu pour des interactions ponctuelles avec l’IA : une personne pose une question, un modèle répond. Il doit maintenant couvrir des identités machines persistantes qui travaillent en continu, souvent sans que personne ne regarde.

Pourquoi votre registre d’IA n’est pas un inventaire d’agents

La plupart des organisations ont déjà une liste de leurs outils d’IA. Elle nomme habituellement des fournisseurs et des cas d’usage : « Copilot pour l’ingénierie », « agent conversationnel sur le site de soutien », « projet pilote de résumé de contrats ». Cette liste répond à une question d’approvisionnement. Elle ne répond pas à une question de sécurité.

Une personne qui intervient lors d’un incident a besoin d’autres faits. Sous quelle identité cet agent a-t-il agi ? Que pouvait-il atteindre ? Qui en est responsable ? Comment l’arrêter ? Les pratiques de réponse aux incidents publiées en octobre par le NIST, la NSA et la CISA supposent que vous le savez déjà. La pratique 3.1 demande de définir le périmètre prévu de chaque agent pour pouvoir en détecter les écarts. La pratique 1.7 exige un moyen d’arrêter rapidement l’activité d’un agent. Après que des agents en évaluation eurent atteint des systèmes d’entreprise en production, le CERT-In de l’Inde a recommandé aux organisations de donner à chaque exécution d’agent sa propre identité éphémère, à moindre privilège.

Chacun de ces contrôles présuppose un inventaire doté des bonnes colonnes.

Microsoft est arrivée à la même conclusion le 19 octobre. Dans Agents are your newest insiders, elle soutient que chaque agent a besoin d’une identité à part entière, distincte de la personne qui l’utilise ou le parraine, qu’il doit partir sans aucune permission et s’exécuter dans un environnement contrôlé, les contrôles se trouvant à l’extérieur du modèle. Sa conclusion : on ne doit pas demander à un modèle d’être sa propre autorité de sécurité. L’inventaire permet de vérifier que c’est vrai pour chaque agent, une fiche à la fois.

Les dix champs

Une fiche par agent. Un agent, ici, désigne tout ce qui pose des actions au moyen d’outils sous une identité : un agent de codage dans votre chaîne d’intégration, un agent de soutien qui accorde des remboursements, une automatisation qui lit des courriels et ouvre des billets. Pour chaque champ, la question à poser et la réponse qui devrait vous inquiéter.

Agent. De quoi s’agit-il, et quelle est sa tâche en une phrase ? Signal d’alarme : la description est un nom de produit, pas une tâche.
Responsable. Quelle personne nommée répond de son comportement et reçoit l’alerte quand il dérape ? Signal d’alarme : une adresse d’équipe, ou la personne qui l’a construit et qui a changé de poste depuis.
Identité. Sous quel compte, quelle clé ou quel jeton agit-il ? Signal d’alarme : le jeton personnel d’un employé, ou un compte de service partagé avec d’autres systèmes. Ses actions deviennent alors impossibles à distinguer de celles des autres.
Outils. Quels outils, quelles API et quels serveurs MCP peut-il appeler ? Signal d’alarme : « tout ce qui est configuré », ou un interpréteur de commandes à usage général.
Données. Quelles données peut-il lire, et lesquelles peut-il écrire, modifier ou supprimer ? Signal d’alarme : un accès hérité d’un rôle étendu plutôt qu’accordé pour la tâche.
Privilèges. Quelles actions lourdes de conséquences peut-il poser sans approbation distincte : paiements, messages externes, changements en production, octroi de permissions ? Signal d’alarme : l’une ou l’autre sans point de contrôle que l’agent ne maîtrise pas.
Réseau. Quelles destinations peut-il joindre ? Signal d’alarme : un accès Internet sortant sans restriction. Les agents d’Anthropic ont contourné la restriction d’un outil avec un raccourcisseur d’URL public ; une liste d’autorisation réseau qui ne l’incluait pas aurait refusé la requête.
Exécution. Où fonctionne-t-il, à quelle fréquence et pendant combien de temps ? Signal d’alarme : sur le portable d’un développeur, ou en continu sans que personne soit chargé de le surveiller.
Télémétrie. Où ses appels d’outils, ses destinations et les décisions des contrôles sont-ils journalisés, et qui contrôle ces journaux ? Signal d’alarme : uniquement dans la console du fournisseur, selon sa politique de conservation.
Mécanisme d’arrêt. Comment l’arrêter et révoquer ses identifiants, combien de temps cela prend-il, et quand l’a-t-on testé pour la dernière fois ? Signal d’alarme : « on désactiverait la clé d’API », sans savoir quels autres systèmes la partagent.

Si vous ne pouvez pas remplir un champ, vous n’avez pas échoué à l’exercice. Vous avez trouvé votre premier constat.

Un exemple concret

Voici la fiche d’un cas courant : un agent de codage par IA qui s’exécute dans la chaîne d’intégration continue, corrige les tests en échec et ouvre des demandes de fusion. Les valeurs sont illustratives, typiques de ce qu’on trouve à la première passe.

Agent. Corrige les tests en échec sur les branches de développement et ouvre une demande de fusion avec la modification.
Responsable. Le chef de l’ingénierie de plateforme, nommément.
Identité. Une installation d’application GitHub limitée à trois dépôts. Constat : la chaîne expose aussi un jeton de déploiement dans une variable d’environnement que l’agent peut lire.
Outils. Lecture et écriture dans le dépôt, exécuteur de tests, registre de paquets.
Données. Code source et jeux de données de test. Constat : l’un de ces fichiers contient un instantané de la base de données de production.
Privilèges. Peut pousser vers les branches de développement. Ne peut pas fusionner ; la protection de branche exige une revue humaine.
Réseau. Constat : trafic sortant sans restriction depuis l’exécuteur d’intégration continue.
Exécution. Exécuteur éphémère, déclenché à chaque compilation en échec, environ 40 exécutions par jour.
Télémétrie. Journaux d’intégration continue conservés 30 jours dans la plateforme. Constat : les appels d’outils et les URL consultées ne sont pas journalisés.
Mécanisme d’arrêt. Désactiver l’application GitHub. Constat : jamais testé, et la révocation ne touche pas le jeton de déploiement.

Il a fallu moins d’une heure, et l’exercice a produit cinq constats, chacun avec une correction évidente : retirer le jeton de déploiement de la tâche, nettoyer le jeu de données, imposer une liste d’autorisation sortante à l’exécuteur, journaliser les appels d’outils dans la plateforme centrale et ajouter au guide d’intervention une étape de révocation testée. Aucun n’exigeait un cadre de gouvernance.

Où se cachent les agents

La première fiche est facile parce que vous avez choisi l’agent. Le plus difficile, ce sont ceux dont personne ne vous a parlé. Cherchez à ces endroits :

Votre fournisseur d’identité. Comptes non humains, autorisations OAuth accordées à des applications d’IA et jetons émis au cours des six derniers mois.
Les consoles des fournisseurs de modèles. Clés d’API émises sous les comptes de l’entreprise, et qui les a créées.
Les journaux de trafic sortant. Trafic vers les points de terminaison d’API de modèles, et depuis quels hôtes.
Les plateformes d’intégration continue et d’automatisation. Tâches qui appellent un modèle, et les secrets auxquels elles ont accès.
Les consoles d’administration SaaS. Fonctions d’agent activées dans des outils que vous payez déjà, avec les permissions de la personne qui les a activées.
Les postes des développeurs. Agents de codage et serveurs MCP locaux qui fonctionnent avec les identifiants du développeur. Les outils de découverte de Microsoft reconnaissent maintenant 60 types d’agents locaux, dont Claude Code, OpenAI Codex et GitHub Copilot. Voilà l’ampleur de ce qui peut arriver sans processus de déploiement.
Les notes de frais. Abonnements à des outils d’IA payés avec une carte d’entreprise.

Chaque source trouve des agents que les autres ratent. Passez-les toutes une fois, puis faites de l’inventaire un point de contrôle : aucun agent n’obtient d’identifiant de production sans fiche complète.

Ce que l’inventaire rend possible

L’inventaire n’est pas une fin. C’est la condition préalable à tout le reste.

Le test de reconstitution. Pour chaque agent, pourriez-vous reconstituer ses 24 dernières heures à partir de vos propres journaux ? Le champ télémétrie vous le dit avant qu’un incident le fasse.
Le décompte des quasi-incidents. Les tentatives bloquées n’ont de sens que par agent, au regard de son périmètre déclaré.
La reddition de comptes au conseil. Les administrateurs n’ont pas besoin des fiches. Ils ont besoin de chiffres : combien d’agents, combien avec un responsable nommé, combien avec un mécanisme d’arrêt testé. Notre billet sur les questions qu’un conseil devrait poser avant d’approuver un outil de codage par IA en montre le format.
La correspondance avec les contrôles. Le 20 octobre, le NIST a renommé COSIS son projet d’adaptation de la SP 800-53 à ces systèmes : des surcouches de contrôles, pas un cadre distinct. L’inventaire parle déjà cette langue. L’agent et son responsable forment un inventaire des composants (CM-8). L’identité correspond à la famille IA, les outils, les données et les privilèges à AC et au moindre privilège (AC-6), le réseau à la protection des frontières (SC-7), l’exécution à la gestion de la configuration (CM), la télémétrie à l’audit (AU) et le mécanisme d’arrêt à la réponse aux incidents (IR). Vos auditeurs connaissent déjà ces familles.
Les évaluations des facteurs relatifs à la vie privée. En vertu de la Loi 25 du Québec, le champ données alimente l’EFVP que la loi exige pour les projets de système d’information qui touchent des renseignements personnels.

Comment nous aidons

Notre Évaluation de la sécurité de l’IA générative commence par cet inventaire. Nous découvrons les agents, bâtissons les fiches avec leurs responsables, testons les mécanismes d’arrêt et transformons chaque lacune en constat assorti d’un responsable, d’un niveau de gravité et d’une mesure corrective. Vous conservez l’inventaire et le processus pour le tenir à jour.

Trois questions pour vous tester

Combien d’agents fonctionnent aujourd’hui dans votre environnement ? Si la réponse est une estimation, l’inventaire est votre première tâche.
Pour votre agent le plus privilégié, pourriez-vous remplir les dix champs de mémoire, ou à partir d’un document qui date de moins d’un trimestre ?
Lesquels de vos agents pourriez-vous arrêter, avec tous leurs identifiants révoqués, en moins de quinze minutes ?

Choisissez un agent cette semaine et remplissez sa fiche. La première prend une heure. C’est aussi la première preuve que votre gouvernance des agents existe ailleurs que dans un document de politique.