Une politique, des milliers d’agents : pourquoi la gouvernance de l’IA en entreprise échoue à grande échelle

Une grande partie des discussions sur l’adoption des agents d’IA autonomes porte, à juste titre, sur la gouvernance, considérée comme un enjeu majeur. Gartner a récemment prédit que 40 % des entreprises rétrograderont ou mettront hors service leurs agents d’IA autonomes d’ici 2027 — non pas parce que la technologie aura échoué, mais parce que leur gouvernance aura échoué. Selon Shiva Varma, analyste et directeur principal chez Gartner, le problème tient à une « gouvernance binaire » : les agents sont soit complètement bridés, soit entièrement dignes de confiance, sans juste milieu.

À l’heure actuelle, de nombreuses organisations tendent soit à interdire totalement les outils d’IA, soit à déployer des agents sans garde-fous suffisants. Aucune de ces approches ne peut être généralisée efficacement. Même lorsque les équipes informatiques interdisent les outils d’IA externes, l’IA fantôme continue d’exister. Les développeurs veulent naturellement créer et résoudre des problèmes ; si la gouvernance leur paraît excessivement bureaucratique, ils contourneront les contrôles et utiliseront des outils non testés pour faire avancer les choses. À l’inverse, des garde-fous insuffisants exposent les organisations à des risques de sécurité, de conformité et d’exploitation qui s’amplifient avec le temps. 

Le défi, c’est que les agents d’IA ne peuvent pas être gouvernés uniformément au moyen d’une approche statique et universelle.  L’ère de la gouvernance universelle touche à sa fin, car ces systèmes n’ont pas le même profil de risque : ils diffèrent par les logiciels sur lesquels ils reposent, leurs capacités, leurs niveaux d’accès et leur degré d’autonomie. Appliquer à des logiciels fonctionnant à la vitesse des machines des contrôles statiques hérités de l’ère industrielle ne peut pas fonctionner.  Une gouvernance efficace dépendra de la capacité des organisations à comprendre la chaîne d’approvisionnement logicielle de chaque agent et à adapter les contrôles aux risques qu’il introduit.  

Gouverner les environnements de développement logiciel agentique

Un véritable contrôle consiste à gérer efficacement tous les éléments logiciels qui composent l’agent. De nombreuses équipes considèrent à tort ces agents comme « fiables et dignes de confiance », négligeant les éléments habituels qui influent sur leur fonctionnement et leur sécurité. 

Chaque agent d’IA autonome repose sur une pile logicielle bien identifiable : un modèle de fondation, des serveurs MCP (Model Context Protocol) qui le relient aux données de l’entreprise et aux systèmes externes, des plug-ins qui étendent ses capacités et des fichiers de compétences qui indiquent comment il doit se comporter. Les responsables informatiques doivent garder à l’esprit que :

• Les agents d’IA sont des écosystèmes logiciels : ils reposent sur une configuration standard comprenant des modèles, des serveurs MCP, des outils, des plug-ins, des compétences et des logiciels open source.
• Les serveurs MCP peuvent présenter des risques : ils relient les agents aux données de l’entreprise et peuvent être téléchargés comme n’importe quel autre logiciel. S’ils ne sont pas vérifiés, ils pourraient permettre à des pirates informatiques de pénétrer dans votre système. Par exemple, une récente étude de sécurité de JFrog met en évidence ces risques précis liés à la chaîne d’approvisionnement logicielle dans mcp-run-python, notamment une falsification de requêtes côté serveur (SSRF) (CVE-2026-25904) et une vulnérabilité due à l’absence d’isolation (CVE-2026-25905), qui peuvent conduire à une prise de contrôle complète de MCP.
• Les plug-ins peuvent accroître les risques : différents agents ont besoin de plug-ins différents (par exemple, un plug-in OpenAI ne fonctionnera pas dans Microsoft Copilot), ce qui oblige souvent les entreprises à gérer plusieurs variantes ; un seul plug-in malveillant pourrait dérober des informations sensibles.
• Les compétences définissent le comportement des agents : ces fichiers d’instructions indiquent à l’agent comment travailler. Comme les développeurs les récupèrent auprès de sources communautaires, une compétence compromise peut modifier discrètement le fonctionnement d’un agent.
• Les risques liés aux logiciels open source : les fonctionnalités des solutions développées à l’aide du codage agentique reposent notamment sur l’exploitation de binaires open source pour les fournir. Les agents de programmation peuvent tout aussi facilement utiliser des paquets malveillants plutôt que des paquets sûrs, sans se rendre compte du risque.
• La visibilité est essentielle : de nombreuses équipes ignorent l’existence de ces problèmes, ce qui rend leurs agents très vulnérables. Les organisations gèrent encore les dépendances logicielles en se fiant à la confiance plutôt qu’en procédant à des vérifications approfondies.

Le rôle d’un référentiel de référence dans une gouvernance efficace de l’IA

La course au déploiement des agents d’IA en entreprise ne peut être remportée avec une mentalité d’hier. Imposer à tous les flux de travail des chaînes d’approbation manuelles, lourdes et monolithiques étouffe l’innovation, tandis que laisser les agents sans surveillance crée des risques inutiles.

Pour déployer l’IA à grande échelle en toute sécurité, les organisations doivent adopter une approche à plusieurs niveaux pour gouverner et sécuriser les composants logiciels, notamment les paquets, les binaires, les serveurs MCP, les compétences et les dépendances. En mettant en place un référentiel central, les entreprises peuvent sélectionner tous les composants utilisés, tout analyser avant leur utilisation, appliquer des politiques au moment opportun du cycle de développement, et conserver la capacité de revenir instantanément à une version antérieure. Ainsi, lorsqu’une nouvelle vulnérabilité est divulguée, la réponse à la question « sommes-nous exposés ? » est obtenue en quelques minutes, et non en quelques jours.

Cependant, les agents d’IA élargissent considérablement la surface d’attaque, qui évolue aussi beaucoup plus rapidement. En effet, les agents très autonomes peuvent prendre des centaines de décisions par minute, enchaîner les appels d’outils, accéder aux données et exécuter du code plus vite que les contrôles d’admission traditionnels ne peuvent suivre. Même si les examens préalables et les procédures d’approbation jouent toujours un rôle important, ils ne suffisent pas à sécuriser des systèmes qui fonctionnent à la vitesse des machines.

Ces agents nécessitent une application dynamique des contrôles à l’exécution, qui permette de détecter tout comportement anormal dès qu’il se produit et d’intervenir avant que les dommages ne s’étendent. Il faut y voir une sorte de disjoncteur : révoquer l’accès à une compétence compromise, déconnecter un contexte de données non fiable ou bloquer un appel d’outil précis dès qu’un problème survient.

Dépasser le modèle uniforme

Une gouvernance rigide et uniforme est vouée à l’échec. La fenêtre pour prendre les devants se referme, et la dette de gouvernance s’accumule à mesure que le déploiement des agents s’accélère. Voici donc quatre mesures que les responsables de la sécurité et de l’ingénierie peuvent prendre dès maintenant pour renforcer leurs systèmes d’entreprise :

1. Faites l’inventaire de ce qui fonctionne déjà. La plupart des entreprises ne sont pas en mesure de recenser tous les agents d’IA présents dans leur organisation, sans même parler des serveurs MCP, des plug-ins et des fichiers de compétences qui les alimentent. Avant de pouvoir évaluer les risques ou encadrer quoi que ce soit, il faut savoir ce qui existe.
2. Traitez les composants d’IA comme des artefacts logiciels. Les serveurs MCP, les fichiers de compétences et les plug-ins ne sont pas de simples éléments de configuration : ce sont du code, exposé aux mêmes risques liés à la chaîne d’approvisionnement que toute dépendance à un composant open source. Appliquez-leur les mêmes procédures d’évaluation, d’analyse et de suivi de la provenance que pour toute bibliothèque tierce.
3. Classez les agents selon leur degré d’autonomie et adaptez les contrôles en conséquence. Définissez ce que signifie « hautement autonome » pour votre organisation et élaborez un cadre de politiques à plusieurs niveaux. Les agents hautement autonomes nécessitent des contrôles appliqués à l’exécution, et pas seulement des vérifications à l’admission. Commencez par vos systèmes les plus sensibles, puis étendez progressivement votre périmètre.
4. Faites en sorte que la gouvernance soit assez rapide pour que les développeurs — humains ou agents — ne cherchent pas à la contourner. L’IA fantôme est un problème de friction. Si l’approbation d’un nouveau serveur MCP prend deux semaines, les développeurs trouveront un autre moyen. L’analyse automatisée, assortie de règles claires, est le seul modèle qui puisse suivre le rythme réel du développement de l’IA.

La gouvernance gagne considérablement en efficacité lorsqu’elle tient compte des risques réels associés à chaque agent, au lieu de les traiter tous de la même façon. Les entreprises qui prendront l’avantage seront celles qui adapteront leur gouvernance aux réalités propres à chaque agent, en s’appuyant sur un système de référence qui applique les politiques à chaque frontière, donne une visibilité sur chaque composant et permet aux équipes d’intervenir dès qu’un problème survient.