Agents d'IA : les repérer, leur donner un responsable, pouvoir les arrêter

Un salarié qui pose une question à un assistant reste devant son écran : il lit la réponse, il décide. Un agent, non. C’est un programme qui se sert d’un modèle d’IA pour agir seul : il lit une boîte mail, résume, classe, écrit dans le CRM, appelle un autre outil, parfois un autre agent. Il tourne la nuit, le week-end, pendant les congés de la personne qui l’a créé.

Les agents prennent des formes très ordinaires. Un assistant RH créé dans Copilot Studio et partagé à toute l’entreprise. Une automatisation Zapier branchée sur la messagerie commerciale. Un script, sur un serveur, qui appelle l’API d’OpenAI chaque nuit. Un dépôt de code qui embarque LangChain. Aucun ne passe forcément par un achat, ni par la DSI.

Où naissent les agents

Les agents apparaissent à quatre endroits, qui ne se voient pas depuis le même poste.

Les plateformes sans code. Copilot Studio et Power Automate permettent à un salarié, si l’administration de Microsoft 365 le laisse faire, de créer un agent, de lui donner des connecteurs (SharePoint, Outlook, une base de données) et de le partager. Trois questions à poser : avec qui est-il partagé, demande-t-il une authentification, agit-il avec les droits de son créateur ?

Les automatisations branchées sur les comptes. Zapier, Make, n8n ou Dust se connectent à Google Workspace ou à Microsoft 365 par une autorisation OAuth, avec des droits qui peuvent aller loin : lire et envoyer des e-mails, ouvrir des fichiers, consulter l’agenda. Ces autorisations sont inscrites dans la console d’administration, avec leur portée.

Le code. Un dépôt qui dépend d’une bibliothèque d’IA, le kit d’OpenAI ou d’Anthropic, LangChain, un serveur MCP, annonce un agent ou en deviendra un. Les clés d’API qui l’accompagnent ont parfois fini dans le dépôt lui-même.

Les serveurs et le cloud. Une machine qui appelle l’API d’un modèle et ne fait rien d’autre est un programme, pas une personne. Elle se repère dans les journaux DNS ou du pare-feu. Les clouds ont aussi leurs agents : AWS Bedrock, Azure AI Foundry, Salesforce Agentforce.

Les inventorier sans lire ce qu’ils traitent

Pour chacun de ces endroits, une source dit qu’un agent existe sans exposer son contenu :

• la liste des applications autorisées et de leurs droits, dans la console Google ou Microsoft ;
• l’inventaire de Power Platform, pour Copilot Studio ;
• les fichiers de dépendances des dépôts (la liste des bibliothèques, pas le code) et les alertes de clés exposées ;
• les clés d’API d’OpenAI ou d’Anthropic, avec leur dernier usage ;
• les journaux DNS.

Ajoutez ce qu’aucune source ne voit, un agent qu’un prestataire fait tourner pour vous par exemple : une déclaration d’une ligne suffit. C’est le principe de l’inventaire des agents d’IA de Lanterne, qui s’appuie sur des connexions en lecture seule à vos outils.

Un responsable, une revue

Un agent sans responsable, c’est un compte de service dont plus personne ne se souvient. Pour chacun, notez :

• à quoi il sert, en une phrase ;
• qui en répond : une personne, pas une équipe ;
• ce qu’il peut faire : ses droits, ses connecteurs, avec qui il est partagé ;
• sa classe de risque au sens de l’AI Act : un agent qui trie des candidatures relève du haut risque à partir du 2 décembre 2027 (voir l’AI Act pour l’entreprise qui utilise l’IA).

Revoyez ensuite chaque agent à intervalle fixe, tous les six mois par exemple, avec une question simple à son responsable : sert-il encore, et ses droits sont-ils toujours justifiés ? L’ANSSI va dans le même sens pour les outils d’IA générative branchés sur les applications métier : revoir leurs droits dès l’activation, puis régulièrement (recommandation R35 de ses recommandations de sécurité pour un système d’IA générative).

Méfiez-vous des agents qui dorment. Un agent qui n’a rien fait depuis trois mois garde tous ses accès, et plus personne ne regarde ce qu’il pourrait en faire.

Pouvoir l’arrêter, et le prouver

Le jour où un agent envoie des e-mails qu’il ne devrait pas, il faut savoir comment l’arrêter, et cela dépend de sa sorte :

• un agent Copilot Studio se met en quarantaine par l’API d’administration de Power Platform ;
• une automatisation autorisée par OAuth perd ses droits quand on retire l’autorisation dans la console Google ou Microsoft ;
• un programme qui utilise une clé d’API s’arrête quand on révoque la clé chez le fournisseur ;
• une machine qui appelle un modèle peut être coupée en bloquant le domaine de l’API dans le DNS.

Écrivez ces procédures avant d’en avoir besoin, et essayez-les au moins une fois.

Pour les agents qui utilisent des outils par le protocole MCP, une passerelle placée entre l’agent et ses outils va plus loin : n’autoriser que certains outils, refuser ceux qui écrivent ou suppriment, journaliser chaque appel. C’est le rôle de la passerelle MCP de Lanterne.

Enfin, gardez la trace. Pour un système à haut risque, l’article 26 de l’AI Act demande au déployeur de conserver au moins six mois les journaux générés automatiquement, dans la mesure où il en a le contrôle, et de prévenir le fournisseur en cas d’incident grave. Pour les autres agents, c’est une bonne pratique qui coûte peu.

Par où commencer cette semaine

• Ouvrez la console d’administration de Google ou de Microsoft, cherchez Zapier, Make, n8n et Dust parmi les applications autorisées, et regardez leurs droits.
• Demandez l’inventaire de Copilot Studio à l’administrateur de Power Platform.
• Cherchez les bibliothèques d’IA dans les dépôts de code de l’entreprise.
• Donnez un responsable et une date de revue à chaque agent trouvé.

Ce travail va de pair avec celui sur le Shadow IA des salariés, et la charte d’usage de l’IA peut demander à chacun de déclarer les automatisations qu’il crée. La page pour les RSSI et les DSI montre comment Lanterne réunit outils et agents dans un même inventaire.