Agent IA connecté au SI : quels connecteurs, quelle sécurité ?
Un agent connecté au SI n’a accès qu’à des outils déclarés, par les API de vos applications ou par MCP, avec un compte à lui, des droits minimaux et des journaux. Il lit et prépare seul ; toute écriture qui engage quelque chose passe par une validation humaine. Le risque principal n’est pas le modèle, c’est l’autonomie qu’on lui laisse.
Qu’est-ce qu’un agent, et en quoi diffère-t-il d’un assistant documentaire ?
Un assistant documentaire répond : il cherche dans vos documents et rédige une réponse sourcée. Un agent agit : il dispose d’outils, décide lesquels appeler, dans quel ordre, avec quels paramètres, et enchaîne jusqu’à ce que la tâche soit faite. Lire un ticket, chercher la procédure dans la GED, préparer une réponse dans le CRM, proposer une écriture dans l’ERP : c’est un agent, parce qu’à chaque étape il fait quelque chose dans un système.
Le passage de « lire » à « faire » change tout ce qui compte pour une DSI. Une réponse fausse se relit ; une action fausse se répare, parfois pas. Un assistant qui invente est un problème de qualité. Un agent qui invente une action est un incident. Tout le reste de cet article découle de là.
Par quoi un agent se connecte-t-il au SI ?
Par trois voies, souvent combinées.
Les API de vos applications. Un outil de tickets, une GED, un CRM ou un ERP moderne exposent des API. L’agent les appelle comme le ferait n’importe quel programme, avec un compte et des droits. C’est la voie la plus directe et la plus ancienne, et elle suffit souvent.
MCP. Le Model Context Protocol est un standard ouvert qui décrit à un modèle les outils qu’il peut appeler : leur nom, ce qu’ils font, les paramètres qu’ils attendent. Un serveur MCP expose des outils ; un client MCP, intégré à l’agent, les découvre et les appelle. L’intérêt est de ne pas réécrire une intégration par modèle et par application, et de disposer de serveurs déjà écrits pour les outils courants. J’écris des clients MCP en Python et je m’en sers tous les jours : mon moteur de recherche sur mes notes est exposé de cette façon, et l’un de mes agents l’interroge par là.
Les connecteurs maison. Quand une application n’a pas d’API, ou pas celle qu’il faut, on écrit une couche entre l’agent et le système. C’est la voie la plus coûteuse et la plus fragile, celle où l’on passe le plus de temps sur un projet d’agent, et celle qui n’a rien d’intelligent.
Dans les trois cas, une chose ne change pas : l’agent n’a accès qu’aux outils qu’on a déclarés. Un agent qui « peut tout faire » est un agent dont personne n’a listé les outils.
Quels sont les risques, nommés par ceux qui les recensent ?
Deux références publiques, lues le 8 septembre 2026.
Le Top 10 OWASP pour les applications à LLM, version 2025, place en première position l’injection de prompt : un texte lu par le modèle, un document, un ticket, une page web, contient des instructions qu’il suit. Viennent ensuite, parmi d’autres, la divulgation d’informations sensibles, la chaîne d’approvisionnement, et l’agentivité excessive, qui décrit exactement le sujet de cet article : un système à qui l’on a donné trop d’outils, trop de droits ou trop d’autonomie.
La spécification MCP elle-même consacre une page aux bonnes pratiques de sécurité, dans sa version du 25 novembre 2025. Elle nomme des attaques précises : le mandataire confus, où un serveur intermédiaire accorde un accès sans le consentement de l’utilisateur ; le passage de jeton, explicitement interdit, où un serveur transmet un jeton qui ne lui était pas destiné ; la falsification de requêtes côté serveur ; le détournement de session ; la compromission d’un serveur MCP local, qui s’exécute avec les droits de l’utilisateur ; et la minimisation des portées, contre les jetons qui donnent accès à tout.
| Risque nommé | Ce qu’il signifie pour un DSI | Parade concrète |
|---|---|---|
| Injection de prompt (OWASP) | Un document lu par l’agent peut lui donner des ordres | Outils limités, validation humaine sur les actions, journal |
| Agentivité excessive (OWASP) | L’agent peut faire plus que sa tâche ne l’exige | Un outil par besoin, droits d’un compte dédié à portée minimale |
| Divulgation d’informations sensibles (OWASP) | L’agent ramène dans une réponse ce qu’il ne devrait pas | Droits de lecture alignés sur ceux de l’utilisateur, filtrage des sorties |
| Mandataire confus et passage de jeton (MCP) | Un intermédiaire accorde ou transmet un accès sans contrôle | Consentement par client, jetons émis pour le serveur qui les utilise |
| Serveur MCP local compromis (MCP) | Un composant installé sur un poste agit avec les droits de l’utilisateur | Provenance vérifiée, isolation, commande affichée avant exécution |
| Portées trop larges (MCP) | Un jeton volé ouvre tout | Portées minimales au départ, élévation au cas par cas, journalisée |
Aucune de ces parades n’est propre à l’IA. Ce sont des règles d’exploitation ordinaires, appliquées à un composant qui a la particularité de pouvoir être manipulé par le texte qu’il lit.
Comment j’ai construit le mien, et ce que ça impose ?
Je fais tourner depuis juin 2026 un assistant multi-agents local, Jarvis Local, dont le code est public. Un coordinateur reçoit la demande et la route vers un agent spécialisé : mes notes, mon code, mes projets, mon serveur, le web. Tout tourne sur mes machines, avec des modèles locaux.
Les règles ont été écrites avant le code, et elles sont dans la documentation du dépôt. Lecture et analyse libres. Création, modification et déplacement soumis à validation, avec un aperçu de la différence avant d’appliquer. Suppression interdite par construction : ce qui doit disparaître est archivé, jamais effacé. Confinement à des zones autorisées, hors desquelles toute action est refusée. Pour les commandes sur le serveur, la même mécanique : les commandes de lecture s’exécutent, les commandes qui modifient attendent une validation, une liste de commandes destructrices est refusée d’office, et les hôtes joignables sont énumérés. L’interface distante ne permet que la lecture ; les écritures ne s’exécutent qu’en local, sous validation.
Ce que ce projet m’a appris tient en une phrase : une liste d’interdits ne protège pas, elle rassure. Un filtre sur les commandes se contourne par une formulation que le filtre ne connaît pas. La protection réelle vient d’ailleurs : de la validation humaine sur tout ce qui modifie, qui voit l’action exacte et non un résumé, et d’un périmètre réseau qui limite ce que l’agent peut atteindre. Le filtre reste utile, comme un garde-fou contre les erreurs banales, pas comme une frontière de sécurité.
En entreprise, la transposition est directe : un agent est un composant du SI comme un autre. Il a un compte, des droits, des journaux et une procédure de reprise, et il les a avant d’avoir un modèle.
Que se passe-t-il quand ça marche ?
Le premier incident réel traité par mon agent d’infrastructure, en juin 2026, donne l’échelle. En surveillant le serveur, l’agent a signalé un conteneur en état de défaut. Le diagnostic s’est fait en lecture seule, par les commandes de lecture autorisées : journaux, configuration, état des services. L’agent a proposé une correction. Je l’ai lue, validée, et elle a été appliquée. Le conteneur est repassé en état sain.
Rien de spectaculaire, et c’est le point. La boucle est celle qu’une équipe d’exploitation connaît : observer, diagnostiquer, proposer, faire valider, appliquer, tracer. L’agent tient les quatre premières étapes plus vite qu’un humain ; il ne tient pas la cinquième seul, et ne doit pas. En production, c’est cette boucle qu’on industrialise, pas l’autonomie.
Quelles règles d’exploitation exiger d’un agent en entreprise ?
Sept, à écrire dans le cadrage et à vérifier avant la mise en service.
- Un compte dédié à l’agent, jamais le compte d’une personne, pour que les journaux disent qui a fait quoi.
- Des droits minimaux et des portées limitées : les outils nécessaires à la tâche, rien de plus, avec élévation au cas par cas si le besoin apparaît.
- Un journal de chaque appel d’outil, avec l’entrée, la sortie, et ce qui a déclenché l’appel, conservé selon une durée fixée.
- Une validation humaine sur toute action qui engage, avec l’action complète affichée, pas un résumé.
- Une file de vérification quand la confiance est basse ou le volume élevé : l’agent prépare, une personne traite la file.
- Une procédure de reprise et de retour arrière, testée, pour les actions qui ont été validées à tort.
- Un jeu d’évaluation sur les actions, comme sur les réponses d’un RAG : des cas réels, l’action attendue, et la mesure de ce que l’agent propose, rejouée à chaque changement.
Si l’une manque, l’agent n’est pas prêt pour la production, quel que soit le modèle. Si toutes sont là, le choix du modèle devient une question de coût et de mesure, pas de confiance.
Par quel processus commencer ?
Par un processus qui traverse plusieurs applications, parce que c’est là que le lien manuel coûte ; à faible enjeu par action, parce que les premières erreurs doivent être réparables ; et à volume suffisant pour mesurer, parce qu’un agent qui agit dix fois par mois ne s’évalue pas. Préparer une réponse à un ticket à partir de la procédure et du dossier client, sans l’envoyer, est un bon premier cas. Passer une écriture comptable ne l’est pas.
C’est ce qu’un cadrage établit : le processus, les outils à déclarer, les droits, les actions qui exigent validation, et le jeu de cas pour mesurer. Le livrable reste utile même si vous ne poursuivez pas avec moi. Si vous avez un processus en tête, décrivez votre cas d’usage : la première question portera sur ce que l’agent aura le droit de faire.