Éviter la prolifération d'agents internes pour préserver confiance et conformité
La prolifération d’agents internes peut rapidement faire basculer une expérimentation IA utile vers un parc opaque, difficile à sécuriser et encore plus difficile à auditer. Pour préserver la confiance des métiers, des utilisateurs et des responsables conformité, les agents doivent être traités comme des identités actives, avec des accès, des responsabilités et un cycle de vie à gouverner.
Le sujet ne consiste donc pas à freiner l’innovation ou à interdire toute initiative locale. Il consiste à offrir un chemin de déploiement suffisamment simple, rapide et sûr pour que les équipes n’aient pas intérêt à créer, connecter ou exploiter des agents en dehors des règles communes.
Pourquoi la prolifération d’agents internes menace la confiance et la conformité
Un agent IA interne ne se limite pas à une interface conversationnelle. Dès qu’il consulte une base documentaire, interroge une application métier, appelle un outil ou déclenche une action, il devient un participant opérationnel du système d’information. Microsoft qualifie les agents d’« ultimate insiders » : ils ont besoin d’accès pour produire de la valeur, sans que ces accès compromettent la sécurité, la conformité ou la gouvernance.
Cette position particulière modifie le niveau d’exigence. Une application classique suit généralement un parcours de conception, de validation et d’exploitation relativement établi. Un agent, lui, peut combiner un modèle, des instructions, des sources de connaissances, une mémoire, des connecteurs et des outils d’action. Chacun de ces éléments peut évoluer et influer sur son comportement réel.
Réponse directe : éviter la prolifération d’agents internes consiste à recenser chaque agent, lui attribuer un propriétaire, limiter ses identités et ses droits, imposer des contrôles d’exécution, puis surveiller ses actions et son cycle de vie depuis une gouvernance commune.
Le danger apparaît lorsque plusieurs directions, produits ou équipes créent des agents de manière autonome, avec leurs propres connecteurs, fournisseurs, règles d’accès et méthodes de suivi. AWS décrit ce phénomène comme une « shadow agent sprawl » : une multiplication d’agents développés en silos par les business units. Ce mode de croissance peut entraîner une corruption silencieuse des données, une agrégation peu visible des coûts et des violations de conformité entre frontières réglementaires.
Le problème est également organisationnel. Dans son étude publiée le 8 juin 2026, IBM indique que deux tiers des CIO et CTO interrogés sont tenus responsables de systèmes qu’ils ne contrôlent pas totalement. Ce décalage entre responsabilité et maîtrise constitue un control gap : l’organisation doit répondre des conséquences de composants dont elle ne possède ni l’inventaire fiable, ni les paramètres d’accès, ni les preuves d’audit nécessaires.
Un agent peut accéder à une information que son créateur est autorisé à consulter, mais que les futurs utilisateurs ne devraient pas recevoir.
Un connecteur peut faire transiter des données vers un espace, un outil ou une région qui ne correspond pas aux exigences applicables.
Deux agents distincts peuvent produire des réponses contradictoires à partir de référentiels différents ou obsolètes.
Un agent apparemment limité peut obtenir un effet important en enchaînant plusieurs outils dont les permissions, prises séparément, semblent acceptables.
La confiance se joue précisément dans ces zones grises. Un collaborateur adoptera plus facilement un agent si son périmètre est clair, si les données utilisées sont compréhensibles et si une personne est responsable en cas d’erreur. À l’inverse, un agent impossible à expliquer, à suspendre ou à auditer encourage la défiance, même lorsqu’il rend ponctuellement service.
Identifier les signaux d’une shadow agent sprawl avant qu’elle ne s’installe
La prolifération ne commence pas nécessairement par des projets ambitieux. Elle peut naître d’un assistant créé pour accélérer une tâche locale, d’un prototype conservé après une démonstration, d’un bot configuré par un prestataire ou d’une automatisation reliée à un outil SaaS. Le problème devient sérieux quand l’organisation ne sait plus répondre simplement à la question : « Quels agents agissent, sur quelles données, pour qui et avec quels droits ? »
Les symptômes opérationnels à examiner
Les signaux suivants ne prouvent pas, à eux seuls, une non-conformité. En revanche, leur accumulation indique qu’un inventaire et une remise sous contrôle deviennent prioritaires.
Des agents sans propriétaire métier et technique identifié.
Le métier peut connaître le besoin, tandis que l’IT connaît l’environnement, mais personne n’assume l’exploitation de bout en bout.
Des accès accordés par commodité.
Des permissions larges, partagées ou permanentes remplacent des droits limités au besoin réel de l’agent.
Des sources de connaissances dupliquées.
Chaque équipe charge ses propres fichiers, sans politique claire de fraîcheur, de qualité ou de retrait des contenus.
Des pilotes qui deviennent des services de fait.
Un test est utilisé quotidiennement sans critères d’industrialisation, journalisation structurée ni procédure de retrait.
Une surveillance centrée sur les seuls incidents applicatifs.
Les logs techniques existent parfois, mais les interactions, les données sensibles consultées et les actions déclenchées ne sont pas suivies comme des événements de conformité.
IBM relève que 70 % des répondants estiment que les équipes déploient la technologie plus vite que l’IT ne peut la suivre. Cette observation éclaire un risque fréquent : attendre d’avoir une cartographie parfaite avant de proposer un cadre. En pratique, l’absence de parcours approuvé peut inciter les équipes à chercher des solutions indépendantes pour répondre à une pression métier réelle.
Ne pas confondre décentralisation et absence de cadre
Une organisation peut laisser les métiers contribuer à la conception d’agents sans accepter une multiplication incontrôlée des environnements et des règles. La décentralisation porte utilement sur l’expression du besoin, les cas d’usage, les jeux de tests et la validation métier. La gouvernance, elle, doit conserver des fondations partagées : identité, autorisations, traçabilité, règles de données, revue des risques et processus de fin de vie.
Cette distinction évite deux excès. Le premier est le verrouillage central, qui ralentit tous les usages et pousse certains projets hors du cadre. Le second est l’autonomie sans garde-fous, qui transforme chaque gain local en dette de sécurité, de conformité et d’exploitation.
Mettre en place un inventaire des agents IA réellement exploitable
Un registre d’agents ne doit pas être un simple catalogue de projets. Il doit servir à décider : autoriser une évolution, vérifier un périmètre d’accès, enquêter sur un comportement, démontrer une maîtrise auprès d’une fonction conformité ou retirer proprement un agent. Pour cela, chaque entrée doit décrire l’agent tel qu’il fonctionne en production ou en pilote, et non tel qu’il avait été imaginé au lancement.
Le Cloud Adoption Framework de Microsoft recommande de définir des politiques de base valables pour chaque agent afin de maîtriser le risque au fur et à mesure que l’adoption progresse. Le registre est l’endroit où ces politiques deviennent applicables à des objets concrets.
Les informations minimales à maintenir pour chaque agent
Identité et finalité :
nom de l’agent, objectif métier, équipe utilisatrice et environnement concerné.
Responsabilités :
propriétaire métier, propriétaire technique et contact de sécurité ou de conformité selon le niveau de risque.
Statut de cycle de vie :
idée, expérimentation, pilote, production, suspension ou retrait.
Données et connaissances :
catégories de données consultées, sources connectées, règles de mise à jour et conditions de suppression.
Capacités d’action :
outils appelés, actions autorisées, validations humaines requises et possibilités de révocation.
Identités et droits :
comptes de service, rôles, périmètres d’accès et justification du moindre privilège.
Traçabilité :
journaux disponibles, durée de conservation applicable, événements critiques suivis et procédure d’escalade.
Cette granularité est importante parce qu’un agent peut évoluer sans changer de nom. L’ajout d’un connecteur, l’ouverture d’un outil d’écriture, l’extension à un nouveau groupe d’utilisateurs ou l’activation d’une mémoire modifient son profil de risque. Un registre utile impose donc une revue lors de changements significatifs, pas uniquement lors de la première mise en service.
Le maintien de cet inventaire peut sembler administratif, mais son alternative est plus coûteuse : reconstruire dans l’urgence qui a accès à quoi après une fuite de données, une réponse erronée à fort impact ou un incident de conformité. IBM rapporte une moyenne de 54 incidents d’agents IA l’année précédente parmi les organisations interrogées, dont 17 % de sévérité élevée. Les incidents cités incluent des fuites de données, des pannes en cascade et des problèmes de conformité.
Réduire les accès des agents : identité, moindre privilège et séparation des rôles
La sécurité d’un agent commence par ses permissions, pas par la qualité apparente de son interface. Un agent qui répond à des questions internes peut n’avoir besoin que de lire un corpus précis. Un agent qui prépare une action peut nécessiter un droit de proposition, tandis que l’exécution finale reste réservée à un humain ou à un workflow contrôlé. Ces différences doivent être traduites dans l’identité technique et les rôles attribués.
Microsoft Purview met notamment en avant la pseudonymisation par défaut, les contrôles d’accès par rôle et les journaux d’audit pour protéger la confidentialité tout en détectant les risques d’insider, y compris ceux liés aux agents. Il s’agit d’un repère concret : les agents doivent être gouvernés comme des acteurs internes, et non comme des fonctionnalités neutres.
Appliquer le moindre privilège aux actions, pas seulement aux données
Le moindre privilège est souvent réduit à la lecture de données sensibles. Or le risque agentique concerne également les outils que l’agent peut invoquer. Une capacité d’envoyer un message, de créer un ticket, de modifier un enregistrement ou de déclencher un processus peut avoir des effets opérationnels importants, même si l’agent ne consulte qu’un nombre limité de documents.
Accorder des droits spécifiques à l’agent plutôt que réutiliser l’identité d’un administrateur ou d’un utilisateur générique.
Séparer la capacité à lire, proposer, valider et exécuter une action lorsque le processus le permet.
Limiter les connexions à des outils explicitement nécessaires au cas d’usage déclaré.
Prévoir une révocation rapide des accès lors d’une suspension, d’un incident ou d’un changement de propriétaire.
Éviter que des secrets, tokens ou clés soient dispersés dans des configurations locales difficiles à inventorier.
Cette discipline aide aussi à contenir les risques formalisés par l’OWASP Top 10 for Agentic Applications 2026, cité par Microsoft : goal hijacking, tool misuse, identity abuse, memory poisoning et rogue agents. Ces catégories rappellent qu’un agent ne doit pas seulement être protégé contre une erreur de modèle ; il doit aussi être empêché d’utiliser abusivement une identité, une mémoire ou un outil.
Il existe un compromis réel. Des droits trop restreints peuvent dégrader l’utilité de l’agent et générer des contournements manuels. Des droits trop larges augmentent l’exposition et rendent les incidents plus graves. La bonne réponse n’est pas un niveau de permission universel : c’est une conception explicite par cas d’usage, avec des permissions réexaminées à chaque évolution des capacités.
Intégrer la gouvernance des agents IA dès la conception et à l’exécution
Une politique écrite est nécessaire, mais insuffisante si elle n’est pas traduite dans les outils et les parcours de livraison. IBM indique que les organisations intégrant directement le contrôle dans leurs systèmes d’IA enregistrent 25 % moins d’incidents que celles qui s’appuient sur une gouvernance manuelle. Le résultat soutient une approche « governance by design » : les contrôles doivent accompagner l’agent dans son environnement d’exécution.
Microsoft a présenté en avril 2026 son Agent Governance Toolkit, centré sur la sécurité d’exécution, la confiance et la conformité des agents autonomes. Plus largement, la multiplication des outils de gouvernance runtime montre que la vérification avant mise en production ne suffit plus. Un agent peut se comporter différemment selon les requêtes, les contenus consultés, les outils disponibles et les changements autour de lui.
Construire des garde-fous dans la chaîne de livraison
La gouvernance devient plus fluide lorsqu’elle est conçue comme une série de contrôles proportionnés, plutôt qu’un comité exceptionnel convoqué à la fin du projet. Un parcours de déploiement gouverné peut inclure les étapes suivantes :
Qualifier le cas d’usage.
Définir la valeur attendue, les utilisateurs, les données et le niveau d’autonomie recherché.
Évaluer les risques.
Examiner notamment l’exposition aux données sensibles, les actions possibles, les connecteurs, les obligations de conformité et le besoin de validation humaine.
Configurer les contrôles.
Appliquer identités dédiées, permissions limitées, règles de données, journalisation et alertes adaptées.
Tester les scénarios attendus et indésirables.
Vérifier le comportement face à des demandes ambiguës, à des contenus non fiables et à des tentatives de sortie de périmètre.
Autoriser avec des conditions explicites.
Fixer le périmètre d’usage, les responsabilités, les seuils d’escalade et la date de revue.
Surveiller puis améliorer.
Utiliser les événements observés pour ajuster les règles, les permissions et la documentation.
Anthropic souligne en avril 2026 que l’autonomie qui rend les agents utiles introduit aussi de nouveaux risques, notamment les erreurs d’interprétation des intentions et les attaques par prompt injection. Le test et le suivi doivent donc porter autant sur l’environnement de l’agent que sur la qualité de ses réponses. Un agent peut être pertinent dans une démonstration et devenir risqué lorsqu’il reçoit des instructions adverses dans un document, une page web ou une donnée connectée.
Passer du journal d’audit à une supervision active des agents
Les journaux sont indispensables pour enquêter et démontrer une traçabilité. Toutefois, une organisation qui se contente de stocker des logs découvre souvent les problèmes après leur impact. Google Cloud et Mandiant avertissent en 2026 que les abus adversariaux d’agents peuvent s’opérer à vitesse machine : le modèle de contrôle doit donc évoluer du simple logging de conformité vers une surveillance active en temps réel.
Cette surveillance ne signifie pas inspecter indistinctement toutes les conversations. Elle doit être proportionnée, respectueuse de la confidentialité et concentrée sur des signaux de risque identifiés. Microsoft Purview Insider Risk Management permet désormais de surveiller l’activité des agents et de détecter des comportements susceptibles de conduire à des fuites de données, à des violations de conformité ou à des problèmes de sécurité.
Définir des événements qui exigent une attention
Microsoft documente des détections « Risky Agents » portant notamment sur des prompts risqués, des réponses sensibles, l’accès à des données sensibles et la consultation de sites risqués. Ces catégories fournissent une base pour définir des scénarios de surveillance pertinents dans son propre contexte.
Un agent tente d’accéder à une source en dehors de son périmètre habituel.
Un agent produit ou transmet une réponse contenant des éléments considérés comme sensibles par les règles internes.
Un agent appelle un outil d’action de manière inhabituelle, répétée ou incompatible avec sa finalité déclarée.
Une instruction reçue cherche manifestement à détourner l’objectif initial ou à contourner des règles.
Un changement de configuration étend les capacités de l’agent sans validation correspondant à son niveau de risque.
La supervision doit être liée à une capacité de réponse. Il faut savoir qui analyse l’alerte, comment isoler ou suspendre l’agent, qui informe les parties concernées et comment restaurer un fonctionnement maîtrisé. Sans procédure de réponse, une détection enrichit les tableaux de bord mais ne réduit pas suffisamment le risque.
Les équipes doivent aussi distinguer les incidents de sécurité, les écarts de conformité, les défauts de qualité et les comportements inattendus sans impact immédiat. Tous méritent une trace, mais ils ne requièrent pas la même urgence ni les mêmes interlocuteurs. Cette catégorisation évite de noyer les équipes sous des alertes tout en conservant les éléments nécessaires à l’amélioration continue.
Organiser un cycle de vie qui évite les agents orphelins et les règles obsolètes
La conformité ne s’arrête pas au feu vert initial. Un agent peut perdre son propriétaire, conserver un connecteur devenu inutile, s’appuyer sur des connaissances vieillissantes ou rester actif après la fin du produit qu’il servait. Le rapport Mandiant 2026 souligne les governance and lifecycle gaps, notamment les politiques obsolètes et l’absence de SBOM internes pour les outils propriétaires.
Dans le contexte des agents, un inventaire de composants et de dépendances apporte une visibilité essentielle. Il permet de savoir quels modèles, outils, connecteurs, sources de connaissances et mécanismes d’identité participent à un service. L’objectif n’est pas de produire une documentation théorique exhaustive ; il est de pouvoir évaluer les conséquences d’un changement, d’une vulnérabilité, d’une nouvelle règle ou d’un retrait de service.
Prévoir les revues et le retrait dès le lancement
Chaque agent en production devrait avoir une fréquence de revue adaptée à son niveau d’autonomie, aux données traitées et aux actions possibles. Une revue peut confirmer que le besoin existe toujours, que les sources restent autorisées, que les permissions sont justifiées et que les journaux ou alertes fonctionnent comme prévu.
La sortie de service mérite la même rigueur. Retirer un agent implique de désactiver ses identités, de supprimer ou d’archiver ses secrets selon les règles applicables, de déconnecter ses outils, de traiter ses données et ses mémoires conformément aux politiques en vigueur, puis de mettre à jour le registre. Laisser un agent inactif mais techniquement accessible revient à conserver une surface d’exposition sans valeur métier claire.
Cette logique de cycle de vie aide à préserver la confiance interne. Les utilisateurs voient que les agents ne sont pas lancés puis oubliés ; les équipes techniques disposent d’un mécanisme de maintenance ; les responsables conformité peuvent vérifier que les règles évoluent avec les usages réels.
Créer un modèle opérationnel qui accélère les usages autorisés
La centralisation du pilotage ne doit pas se traduire par une centralisation de tous les développements. L’orientation défendue par AWS est plutôt de proposer des chemins de déploiement gouvernés et plus rapides afin de réduire la shadow agent proliferation, au lieu de laisser les équipes créer séparément des agents non sanctionnés. Autrement dit, la gouvernance devient un levier d’adoption si elle simplifie l’accès à des composants sûrs.
Google Cloud rapporte en août 2026 que 79 % des leaders technologiques considèrent la sécurité, la gouvernance ou les opérations comme leur principal défi pour passer l’inférence à l’échelle. Dans le même rapport, 80 % indiquent que la conformité des données constitue le facteur principal dans le choix d’une plateforme. Ces résultats confirment que l’industrialisation ne dépend pas seulement de la performance des modèles : elle dépend de la capacité à déployer de façon répétable et contrôlée.
Répartir clairement les responsabilités
Un modèle opérationnel robuste peut associer plusieurs rôles, sans dupliquer les décisions. Les métiers formulent la valeur attendue et valident l’utilité. Les équipes produit et techniques construisent, testent et exploitent. Les fonctions sécurité, données, juridique et conformité définissent les exigences et participent à l’évaluation des usages à risque. Une gouvernance centrale maintient les standards, les composants communs et la vision du parc.
Cette organisation fonctionne mieux lorsqu’elle publie des règles compréhensibles : quels cas d’usage peuvent suivre un parcours allégé, lesquels nécessitent une revue renforcée, quels connecteurs sont approuvés, quelles données sont exclues par défaut et quels contrôles sont obligatoires. L’objectif est de réduire l’incertitude, pas d’ajouter une couche de validation indistincte.
La préparation doit rester progressive. IBM indique que seuls 11 % des répondants se disent totalement prêts pour l’échelle de déploiement des agents IA attendue dans l’année suivante. Commencer par des cas d’usage circonscrits, avec un périmètre de données maîtrisé et une autonomie limitée, offre un moyen pragmatique d’améliorer les pratiques avant d’élargir les capacités.
Mesurer la maîtrise du parc d’agents plutôt que compter les prototypes
Le nombre d’agents créés n’est pas un indicateur suffisant de maturité. Il peut même encourager la dispersion si les équipes sont valorisées pour lancer des prototypes plutôt que pour exploiter durablement des services fiables. Une gouvernance des agents utile suit des indicateurs de couverture, de contrôle et de qualité opérationnelle.
Part des agents connus dans le registre par rapport aux agents détectés dans les environnements concernés.
Part des agents disposant d’un propriétaire métier et d’un propriétaire technique désignés.
Part des agents avec des identités dédiées, des permissions revues et une journalisation active.
Nombre d’agents en pilote dont le statut est revu avant une éventuelle mise en production.
Délai nécessaire pour suspendre un agent, révoquer ses accès et identifier ses dépendances.
Répartition des alertes, incidents et actions correctives par type de risque.
Ces mesures doivent soutenir des décisions, non alimenter une bureaucratie. Si un indicateur révèle que de nombreux agents ne possèdent pas de propriétaire, l’organisation doit simplifier l’affectation et le suivi. Si les équipes évitent le parcours officiel parce qu’il est trop lent, il faut améliorer les modèles, les composants réutilisables et les critères de qualification.
Microsoft relie la réussite des agents à une infrastructure où la confiance est intégrée au système lui-même. C’est une perspective utile pour les responsables de projet, les leads techniques et les équipes produit : la confiance ne se gagne pas par une promesse générale de contrôle, mais par des mécanismes visibles, testables et applicables à chaque nouvel agent.
Préserver confiance et conformité face à la prolifération d’agents internes exige donc une décision structurante : considérer les agents comme un parc à gouverner, et non comme une succession d’expérimentations isolées. Inventaire vivant, propriétaires identifiés, droits minimaux, contrôles intégrés, supervision active et retrait maîtrisé forment un socle cohérent pour faire évoluer les usages sans perdre la maîtrise.
La priorité pratique est de cartographier les agents déjà présents, puis de mettre en place un chemin de déploiement approuvé plus simple que les contournements. En donnant aux équipes des fondations communes et une gouvernance proportionnée au risque, l’organisation peut développer des agents réellement utiles tout en protégeant ses données, ses obligations de conformité et la confiance de ses utilisateurs.
