L’intégration de l’intelligence artificielle dans les systèmes d’information s’est longtemps faite sous une forme relativement maîtrisée. Les premiers usages consistaient à assister, suggérer, accélérer certaines tâches sans jamais retirer à l’humain la responsabilité finale de l’action. Génération de code, aide à la rédaction, analyse de logs ou priorisation d’incidents entraient dans cette catégorie. L’IA proposait, l’humain disposait. Ce modèle, bien qu’imparfait, conservait une frontière claire entre la décision et l’exécution.
Cette frontière est en train de s’estomper.
Les agents dits « agentiques » ne se contentent plus de produire des recommandations. Ils développent, testent, déploient, modifient des configurations, appellent des API, orchestrent des pipelines et interagissent directement avec des infrastructures de production. Dans de nombreux environnements, ces capacités sont perçues comme une évolution naturelle de l’automatisation, un prolongement logique des chaînes CI/CD et des outils d’infrastructure as code. Pourtant, ce glissement introduit une rupture plus profonde qu’il n’y paraît.
« Quand l’IA ne suggère plus, mais agit, la question n’est plus technique, elle devient organisationnelle. »
Ce qui est délégué ici n’est pas seulement une tâche, mais une capacité d’exécution. Or, dans un système d’information, l’exécution n’est jamais neutre. Elle implique des droits, des périmètres, des dépendances et des effets de bord. Autoriser un agent à exécuter du code, à manipuler des ressources ou à déclencher des processus revient à lui confier une part de l’autorité opérationnelle du SI. Cette autorité peut être encadrée, mais elle existe bel et bien.
Le cœur de cette délégation repose sur des mécanismes souvent peu visibles pour les décideurs : les plans de contrôle machine, ou MCP. Ces dispositifs définissent ce qu’un agent peut faire, avec quels outils, sur quels environnements et via quelles interfaces. Ils déterminent les API accessibles, les actions autorisées, les contextes d’exécution possibles. En pratique, ils jouent un rôle comparable à celui des politiques d’habilitation dans les systèmes classiques, à ceci près qu’ils s’appliquent à des entités non humaines, capables d’agir de manière autonome et à grande échelle.
Lorsque ces plans de contrôle sont correctement conçus, ils limitent les risques. Mais lorsqu’ils sont incomplets, permissifs ou mal compris, ils deviennent un facteur d’exposition majeur. L’agent ne commet pas d’erreur au sens humain du terme : il exécute ce qui lui est permis, exactement comme prévu. Le problème n’est pas l’IA, mais l’étendue de l’autorité qui lui a été confiée.
« Ce qui est autorisé à grande échelle devient critique par nature. »
Un incident récent, associé à une vulnérabilité identifiée dans un proxy OAuth largement utilisé, illustre cette réalité. Sans recourir à une chaîne d’exploitation complexe, des acteurs ont pu transformer un mécanisme de confiance en vecteur d’exécution de code à distance. L’attaque n’a pas reposé sur une faille spectaculaire, mais sur l’automatisation de ce qui était déjà autorisé. Ce type d’événement agit comme un révélateur : dès lors qu’un agent peut exécuter des commandes, il peut aussi exécuter des actions malveillantes si son périmètre n’est pas strictement maîtrisé.
Ce constat met en lumière un angle mort fréquent des démarches de sécurité. Les organisations ont l’habitude de raisonner en termes de vulnérabilités logicielles, de correctifs ou de détection d’anomalies. Or, dans le cas des IA agentiques, le risque ne provient pas nécessairement d’un défaut du code généré, mais de la capacité d’action accordée à l’agent. Une action légitime répétée à l’échelle, déclenchée dans un contexte inapproprié ou combinée à d’autres automatisations, peut produire des effets systémiques.
À cela s’ajoute un phénomène plus discret, mais tout aussi préoccupant : la prolifération des identités et des secrets techniques. Les agents s’appuient sur des clés API, des jetons d’accès et des permissions parfois temporaires, parfois persistantes. Ces éléments, souvent créés pour répondre à un besoin ponctuel, s’accumulent au fil des itérations. Ils deviennent difficiles à inventorier, à auditer et à révoquer. Ces « identités fantômes » échappent progressivement aux modèles classiques de gestion des accès et brouillent la notion de responsabilité.
Dans un système traditionnel, chaque action peut être rattachée à un utilisateur, un rôle, une fonction. Avec des agents autonomes, cette traçabilité devient plus complexe. Qui est responsable d’une action exécutée par un agent ? Le développeur qui l’a configuré ? L’équipe qui a validé le pipeline ? L’organisation qui a accepté le principe de l’automatisation ? Cette dilution de la responsabilité complique non seulement la gestion des incidents, mais aussi l’analyse de risques en amont.
« La délégation d’exécution n’efface pas la responsabilité, elle la rend plus diffuse. »
Face à ces enjeux, les réponses purement techniques montrent rapidement leurs limites. Auditer le code généré, renforcer la détection ou multiplier les contrôles a posteriori ne suffit pas. Le problème se situe en amont, dans la manière dont l’autorité est définie, attribuée et contrôlée. Il s’agit d’un sujet de gouvernance avant d’être un sujet d’outillage.
Sécuriser des IA agentiques suppose d’abord de clarifier ce qui peut être délégué et ce qui ne peut pas l’être. Toutes les actions ne se valent pas. Certaines relèvent de l’assistance, d’autres de la décision, d’autres encore de l’exécution critique. Les confondre revient à créer un continuum de risques difficilement maîtrisable. La capacité à interrompre, limiter ou révoquer une action automatisée doit être pensée dès la conception, et non ajoutée comme un correctif ultérieur.
Cela implique également de revoir les pratiques d’audit. Il ne s’agit plus seulement d’auditer des configurations ou des journaux, mais de comprendre les chaînes d’exécution dans leur ensemble : quelles décisions déclenchent quelles actions, avec quels droits, dans quels contextes. Cette lecture systémique est souvent absente des projets d’automatisation, focalisés sur la performance et la rapidité de mise en œuvre.
Enfin, l’IA agentique interroge la capacité des organisations à accepter l’incertitude. Un agent autonome ne se comporte pas toujours de manière strictement prévisible, surtout lorsqu’il interagit avec des environnements dynamiques. La sécurité ne peut donc pas reposer uniquement sur des règles figées. Elle nécessite une surveillance continue des usages réels et une aptitude à reprendre la main lorsque l’automatisation dévie de son cadre initial.
Déléguer l’exécution à une IA ne revient pas à abandonner le contrôle, mais à le transformer. Ce contrôle n’est plus exercé action par action, mais par la définition de périmètres, de limites et de mécanismes de réversibilité. Les organisations qui réussiront cette transition seront celles qui auront compris que l’IA agentique n’est pas seulement un outil d’efficacité, mais un nouvel acteur du système d’information, avec lequel il faut composer.
À mesure que ces agents s’intègrent dans la gestion quotidienne des infrastructures, la question n’est donc pas de savoir s’ils sont fiables ou intelligents, mais s’ils agissent dans un cadre de gouvernance suffisamment explicite. Tant que cette question restera secondaire, les gains de productivité promis par l’automatisation risqueront de se payer au prix d’une perte de maîtrise silencieuse du système d’information.
