Gouvernance des agents IA : cadre, risques et contrôles 2026

La gouvernance des agents IA est l'ensemble des contrôles qui déterminent à quels systèmes un agent IA autonome peut accéder, quelles actions il peut exécuter, qui en est responsable, et quand ses accès prennent fin. Elle se distingue de la gouvernance de l'IA sur un point décisif : la gouvernance de l'IA examine ce qu'un modèle dit, la gouvernance des agents contrôle ce qu'un agent fait. Un agent détient des identifiants, appelle des outils, écrit dans des systèmes de production et continue de travailler quand personne ne regarde. C'est donc un sujet d'identité, pas un sujet de contenu.

La plupart des équipes IT des PME et ETI disposent déjà des contrôles nécessaires. Elles ne les ont simplement pas encore appliqués aux identités non humaines.

Sommaire

• Qu'est-ce que la gouvernance des agents IA ?
• Les quatre risques agentiques que personne n'a inventoriés
• Le cadre de gouvernance des agents IA : cinq contrôles
• Correspondance avec les obligations réglementaires européennes
• Comment étendre votre IAM existant aux agents IA
• Un plan de 30 jours pour une équipe IT
• Pourquoi Corma pour la gouvernance des agents IA
• Questions fréquentes

Quelque chose a basculé discrètement entre 2025 et 2026. Le volume de recherche sur shadow AI est passé de 1 600 requêtes mensuelles en juillet 2025 à 4 400 en juin 2026 sur le marché américain, selon les données Google Ads Keyword Planner relevées en juillet 2026. Cette courbe n'est pas une curiosité marketing. Elle traduit un moment de découverte, incident après incident : des collaborateurs ont connecté des logiciels autonomes aux systèmes de l'entreprise sans en informer personne.

L'ampleur du mouvement est documentée. Gartner prévoit que les agents IA seront responsables de 15 % des décisions de travail quotidiennes d'ici 2028, contre 0 % en 2024. McKinsey estime que les cas d'usage agentiques et génératifs pourraient représenter 2 600 à 4 400 milliards de dollars par an, tout en relevant dans le même corpus de recherche que seulement 1 % des organisations considèrent leur adoption de l'IA comme mature. La capacité progresse plus vite que le contrôle.

La réponse du marché consiste à vendre une couche supplémentaire : plateformes de gouvernance d'agents, moteurs de garde-fous, intercepteurs de politiques à l'exécution. Pour une entreprise de 50 à 500 collaborateurs avec une équipe IT de quatre personnes, acheter une pile de gouvernance parallèle n'est pas réaliste. Ce guide prend le chemin inverse. Il montre comment les cinq contrôles qui gouvernent réellement les agents se superposent aux capacités de gestion des identités et des accès que vous exploitez déjà, comment elles se positionnent face aux obligations de l'AI Act, de NIS2, d'ISO 27001 et du RGPD, et quoi faire dans les 30 prochains jours.

Qu'est-ce que la gouvernance des agents IA ?

La gouvernance des agents IA est une discipline de contrôle d'accès appliquée à des logiciels autonomes. Elle définit les ressources qu'un agent IA peut atteindre, les actions qu'il peut réaliser, l'humain qui en répond, et la façon dont ses permissions sont revues puis révoquées dans le temps.

Un agent IA est un système d'IA qui planifie une séquence d'étapes, sélectionne des outils et exécute des actions vers un objectif, sans attendre une instruction à chaque étape. Si un grand modèle de langage constitue la couche de raisonnement, un agent est cette couche à laquelle s'ajoutent des identifiants, un accès à des outils et une fiche de poste. La distinction compte, car la gouvernance porte sur les identifiants et l'accès aux outils, pas sur le raisonnement.

En quoi la gouvernance des agents diffère-t-elle de la gouvernance de l'IA ?

La gouvernance classique de l'IA a été conçue pour des systèmes qui produisent une sortie : test de biais, revue des hallucinations, filtrage de contenu, documentation des modèles. Ces contrôles supposent qu'un humain lit la sortie et décide de la suite. Les agents suppriment cette étape. Un agent peut créer un ticket Jira, mettre à jour une fiche CRM, provisionner un utilisateur ou envoyer un e-mail externe avant qu'aucun humain n'ait vu le raisonnement sous-jacent.

La conséquence pratique : un échec de gouvernance d'agent produit une action à annuler, pas une réponse à corriger.

Qu'est-ce qui a changé en 2026 ?

Trois basculements ont fait passer la gouvernance des agents du sujet de recherche au sujet opérationnel.

• Les agents sont désormais créés par des non-développeurs. Microsoft Copilot Studio, Salesforce Agentforce, n8n, Zapier Agents et Retool permettent à un utilisateur métier de créer un agent fonctionnel en une après-midi. Les achats, la revue sécurité et la DSI ne sont pas dans cette boucle.
• Le Model Context Protocol (MCP) a multiplié les points de connexion. Chaque serveur MCP auquel un agent se connecte constitue un nouveau chemin d'identifiants vers un système. Les recherches de Nudge Security documentent la prolifération des serveurs MCP comme une extension rapide de la surface d'attaque SaaS que les outils de découverte classiques ne détectent pas.
• Le calendrier réglementaire est devenu concret. Les obligations de transparence de l'article 50 de l'AI Act s'appliquent à partir du 2 août 2026, tandis que les obligations relatives aux systèmes à haut risque ont été repoussées au 2 décembre 2027 par le Digital Omnibus sur l'IA, adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026. Les échéances existent, et elles sont désormais datées.

Les quatre risques agentiques que personne n'a inventoriés

La plupart des articles sur le risque agentique listent l'injection de prompt, l'hallucination et la dérive de modèle. Ces risques sont réels, et ce sont aussi ceux contre lesquels un éditeur de sécurité peut vendre un produit à l'exécution. Les quatre risques ci-dessous sont ceux qui remontent dans un audit réel de PME ou d'ETI, et ce sont tous des problèmes d'identité et de gestion d'actifs.

Des accès non suivis : autorisations OAuth, clés d'API et connexions MCP

Un agent a besoin d'identifiants pour être utile. En pratique, ces identifiants arrivent par le chemin le plus rapide : un collaborateur approuve une autorisation OAuth avec des portées trop larges, colle une clé d'API à durée illimitée dans une automatisation, ou pointe un agent vers un serveur MCP en utilisant un compte de service que personne n'a documenté.

Le mode de défaillance n'a rien d'exotique. C'est un jeton avec droits d'écriture sur un système de production, détenu par un logiciel, sans date d'expiration et sans propriétaire nommé. C'est le même angle mort de visibilité qui a produit le shadow IT, à une différence près : le logiciel peut maintenant agir de lui-même.

La prolifération d'agents : du shadow IT doté d'un moteur de décision

La prolifération d'agents est l'accumulation incontrôlée d'agents IA créés hors du processus d'achat IT, chacun détenant ses propres permissions et connexions. Les données de Nudge Security situent l'organisation moyenne à 26 applications d'IA distinctes déjà en usage, la plupart adoptées sans supervision de la DSI. Chaque plateforme agentique de cet ensemble peut générer des agents.

La prolifération se mesure et se cumule. Deux collaborateurs construisant des agents similaires sur des plateformes différentes produisent deux jeux d'identifiants, deux trous d'audit et deux lignes de renouvellement. Le schéma est familier à qui a lu notre analyse sur la montée du shadow AI et la façon de la contenir.

Les comptes d'agents orphelins : personne ne désactive un agent

C'est l'angle mort du marché tout entier. Parcourez les dix premiers résultats sur la gouvernance des agents IA : vous trouverez une couverture abondante du déploiement, des garde-fous et de la supervision humaine, et presque rien sur la fin de vie.

Quand un collaborateur part, une équipe IT mature révoque ses comptes. Quand le collaborateur qui avait construit trois agents part, ces agents continuent de tourner, conservent leurs jetons et conservent leurs accès. Ils deviennent des identités non humaines orphelines : des identifiants actifs sans humain responsable. Un auditeur traite un compte de service orphelin comme un écart. Un agent orphelin est le même écart avec un rayon d'impact plus large, parce qu'il agit au lieu d'attendre.

Le coût invisible : sièges, crédits et jetons

Les agents consomment des ressources payantes. Ils occupent des sièges de licence dans les outils qu'ils opèrent, brûlent des crédits d'API et consomment des jetons de modèle. Comme la dépense atterrit souvent sur une carte de service ou à l'intérieur d'un abonnement existant, elle apparaît dans le reporting financier bien avant d'apparaître dans une revue de sécurité.

Le coût devient donc le signal d'alerte précoce le plus fiable disponible. Une hausse inexpliquée des dépenses liées aux abonnements SaaS et aux coûts logiciels est fréquemment le premier symptôme détectable d'un agent non gouverné, et elle atteint le DAF avant d'atteindre le RSSI.

Le cadre de gouvernance des agents IA : cinq contrôles

Le cadre ci-dessous suit la séquence qui fonctionne opérationnellement : on ne peut pas appliquer une politique à un agent qu'on n'a pas trouvé, et on ne peut pas révoquer un accès qu'on ne sait pas attribuer.

1. Découvrir et inventorier chaque agent

La gouvernance ne peut pas précéder la découverte. Avant le moindre privilège, les revues ou la politique d'exécution, il faut un inventaire qui répond à trois questions par agent : que peut-il atteindre, que peut-il faire, et qui l'a créé.

Un inventaire d'agents n'est pas un inventaire d'outils d'IA. Un inventaire d'outils demande quelles applications les collaborateurs utilisent. Un inventaire d'agents demande quels systèmes autonomes détiennent des accès à votre environnement. Les sources de découverte qui fonctionnent réellement : les journaux du fournisseur d'identité, les enregistrements d'autorisations OAuth, les signaux de découverte SaaS, les données de dépense et de carte bancaire, et les signaux navigateur pour les plateformes sans API.

2. Attribuer à chaque agent une identité unique et un propriétaire humain

Chaque agent reçoit sa propre identité et un responsable humain nommé. Pas de clé d'API partagée entre agents, pas de compte de service générique, pas d'identifiants héritages d'un collaborateur sortant.

Ce seul contrôle produit l'essentiel de la valeur d'audit, car il rend chaque action d'agent traçable jusqu'à une personne à qui on peut demander de la justifier. C'est la même discipline que le provisionnement des utilisateurs, appliquée à un logiciel plutôt qu'à un collaborateur.

3. Appliquer le moindre privilège par les rôles, pas par des clés partagées

Cadrez les permissions sur la tâche. Un agent qui lit des données d'agenda pour rédiger des synthèses n'a pas besoin d'un accès en écriture au CRM. En pratique, cela signifie un contrôle d'accès basé sur les rôles pour les identités non humaines, avec des identifiants à durée limitée là où la plateforme le permet.

Si votre équipe doit choisir un modèle de permissions, notre comparatif des modèles de contrôle d'accès RBAC et ABAC s'applique directement : les rôles passent mieux à l'échelle pour un catalogue d'agents figé, les attributs gèrent mieux le contexte dynamique.

4. Définir des seuils de validation humaine selon la criticité de l'action

Toutes les actions d'agent ne méritent pas un point de validation, et un système qui demande une approbation pour tout finit contourné. Calibrez sur la conséquence : les actions réversibles et à faible impact s'exécutent en autonomie, les actions irréversibles ou visibles à l'extérieur exigent une approbation humaine explicite.

Le mécanisme existe déjà dans la plupart des piles IAM sous forme de workflow d'approbation. Faire passer les élévations de privilèges des agents par le même canal que celui utilisé par vos équipes sécurité pour rester conformes évite de construire un second système d'approbation.

5. Certifier, puis révoquer : revues d'accès et sortie des agents

Les permissions des agents dérivent dans la même direction que celles des humains : elles ne font que croître. Le contrôle est la certification périodique, et il doit inclure un chemin de suppression.

Deux règles rendent cela opérant. D'abord, inclure les identités non humaines dans le périmètre de vos revues d'accès automatisées et conformes plutôt que de les traiter à part. Ensuite, ajouter les agents à l'étape de sortie de votre processus arrivée-mobilité-départ, afin que le provisionnement et l'onboarding automatisés couvrent les agents créés par un collaborateur, et pas seulement les comptes qu'il détenait.

Correspondance avec les obligations réglementaires européennes

Les organisations européennes ne peuvent pas traiter la gouvernance des agents comme une bonne pratique émergente. Plusieurs obligations existantes la couvrent déjà, et un cadre a une échéance active en 2026.

Le calendrier de l'AI Act tel qu'il se présente en juillet 2026. Le Digital Omnibus sur l'IA a été adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026, avec une entrée en vigueur en juillet 2026. Il repousse les obligations relatives aux systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027, et celles relatives à l'IA intégrée dans les produits réglementés de l'annexe I au 2 août 2028. Les obligations de transparence de l'article 50 s'appliquent bien à partir du 2 août 2026. Les nouvelles interdictions et les exigences de marquage de l'article 50(2) pour les systèmes déjà sur le marché s'appliquent à partir du 2 décembre 2026.

La lecture pratique pour un DSI : le travail de conformité sur le haut risque dispose de davantage de marge, mais le travail de journalisation et de conception de la supervision humaine ne devient pas optionnel. L'article 12 exige l'enregistrement automatique des événements sur la durée de vie du système. L'article 14 exige que les systèmes à haut risque soient conçus pour permettre une supervision humaine effective. Ces deux exigences sont des sujets d'ingénierie et de contrôle d'accès, et elles sont bien plus simples à satisfaire si l'identité des agents et la journalisation existent avant l'échéance plutôt qu'après.

NIS2 constitue la contrainte la plus immédiate pour la plupart des entreprises concernées. L'article 21(2) énumère les mesures de gestion des risques cyber exigées, parmi lesquelles les politiques de contrôle d'accès et la gestion des actifs. Un agent non documenté détenant des identifiants de production est une défaillance de gestion d'actifs au sens de cet article, quoi qu'il soit par ailleurs. En France, l'ANSSI pilote la transposition et publie les référentiels applicables aux entités essentielles et importantes. Notre guide sur ce que la directive NIS2 implique pour votre entreprise détaille la question du périmètre.

Côté données personnelles, la CNIL a précisé sa doctrine sur les systèmes d'IA et rappelle que la base légale et la minimisation s'apprécient aussi au niveau des accès techniques. Un agent qui accède à des données personnelles au-delà de sa finalité déclarée est un sujet RGPD avant d'être un sujet d'IA.

Comment étendre votre IAM existant aux agents IA

Voici l'argument en une ligne : les quatre piliers que le marché vend comme nouveaux (découverte, moindre privilège, garde-fous, supervision humaine) sont respectivement de la découverte SaaS, du RBAC, du provisionnement conditionnel et de la revue d'accès. Il ne vous manque pas une catégorie d'outillage. Il vous manque la couverture des identités non humaines dans l'outillage que vous avez.

Ce que votre pile actuelle couvre déjà, si elle est configurée pour cela :

• Le SSO et votre fournisseur d'identité vous donnent un point unique pour voir et couper l'authentification. Un agent qui s'authentifie via l'IdP est un agent que vous pouvez désactiver en une action.
• Le provisionnement SCIM vous donne la création programmatique de comptes et, plus important encore, la suppression programmatique. Là où une plateforme agentique supporte SCIM, le déprovisionnement devient un appel d'API plutôt qu'un ticket manuel.
• Le RBAC vous donne le modèle de permissions. Les agents deviennent des porteurs de rôles.
• Les revues d'accès vous donnent le cycle de certification récurrent. Ajoutez une vue identités non humaines.
• Les workflows arrivée-mobilité-départ vous donnent le cycle de vie. Ajoutez une étape agents à la checklist de départ.

Ce qu'il faut réellement ajouter :

• Un registre des agents avec propriétaire, finalité, systèmes connectés, type d'identifiant et date de revue.
• Une hygiène des identifiants machine : pas de clé partagée, dates d'expiration sur les jetons, calendrier de rotation.
• Des seuils d'approbation par type d'action, documentés plutôt qu'implicites.
• Un chemin de fin de vie déclenché à la fois par la mise hors service de l'agent et par le départ de son propriétaire.

Pour les équipes qui veulent la vue opérationnelle plutôt que la vue cadre, notre article sur la gouvernance des agents IA et le pilotage de l'IT de demain traite le volet organisationnel du même problème, y compris la question de savoir qui doit porter le registre.

Un plan de 30 jours pour une équipe IT

Ce plan est écrit pour une équipe IT de deux à six personnes qui accompagne 50 à 500 collaborateurs, sans fonction dédiée de supervision sécurité.

Semaine 1 : les trouver. Exportez les autorisations OAuth depuis Google Workspace ou Microsoft Entra ID. Récupérez les dépenses SaaS et IA auprès de la finance. Listez chaque plateforme agentique en usage. N'attaquez pas encore la politique.

Semaine 2 : leur donner un propriétaire. Une ligne par agent : propriétaire, finalité, systèmes atteints, type d'identifiant. Tout ce qui n'a pas de propriétaire identifiable va sur une liste de révocation, pas sur une liste de revue.

Semaine 3 : couper l'évident. Révoquez les jetons orphelins, remplacez les clés d'API partagées par des identifiants par agent, retirez les droits d'écriture qu'aucun cas d'usage documenté ne justifie.

Semaine 4 : rendre le contrôle récurrent. Intégrez les identités non humaines au cycle de revue d'accès, ajoutez une ligne agents à la checklist d'offboarding, et fixez des seuils d'approbation pour les trois ou quatre types d'actions les plus lourdes de conséquences dans votre environnement.

Pourquoi Corma pour la gouvernance des agents IA

Corma est une plateforme européenne qui combine SaaS Management et gestion des identités et des accès dans un seul système, ce qui correspond exactement à la combinaison exigée par la gouvernance des agents. La découverte vit du côté SaaS Management. L'identité, le moindre privilège, les approbations et la révocation vivent du côté IAM. Répartir ces deux moitiés sur deux éditeurs, c'est précisément par là que les agents passent entre les mailles.

Quatre points comptent pour ce cas d'usage :

• Découverte et contrôle convergents. Corma découvre les applications, les licences et les accès dans la même plateforme que celle qui provisionne et révoque, donc un agent trouvé lundi peut être cadré ou coupé lundi. La plupart des concurrents ne couvrent qu'un côté.
• Hébergement européen et conformité RGPD native. Les données sont hébergées dans l'Union européenne, et Corma détient la certification ISO/IEC 27001:2022. Pour une entreprise qui met ses contrôles en correspondance avec NIS2 et l'AI Act, cela retire du dossier la question des transferts de données à laquelle les éditeurs de SaaS Management basés aux États-Unis doivent répondre.
• Coût et accès dans une seule vue. Parce que Corma suit les licences et les dépenses en même temps que les identités, le signal budgétaire décrit plus haut devient une alerte opérationnelle plutôt qu'une surprise trimestrielle.
• Une réalité d'implémentation adaptée aux PME et ETI. L'onboarding complet prend généralement moins d'un mois pour une entreprise de 50 à 500 collaborateurs, ce qui fait la différence entre un contrôle qui existe sur le papier et un contrôle qui tourne.

Le schéma est déjà documenté dans des environnements réglementés. Notre cas client sur la gouvernance des identités dans la santé chez Satelia montre le même jeu de contrôles appliqué là où les exigences d'audit sont les plus strictes.

Questions fréquentes

Qu'est-ce que la gouvernance des agents dans l'IA ?

La gouvernance des agents dans l'IA est la pratique qui consiste à contrôler ce à quoi un agent IA autonome peut accéder et ce qu'il peut exécuter, qui en est responsable, et comment ses permissions sont revues puis révoquées. Elle couvre l'identité, les permissions, les seuils d'approbation, la journalisation et la fin de vie, et elle porte sur les actions de l'agent plutôt que sur la sortie du modèle.

Quelle différence entre gouvernance de l'IA et gouvernance des agents IA ?

La gouvernance de l'IA évalue les sorties du modèle sur l'exactitude, le biais et la conformité. La gouvernance des agents IA contrôle les actions de l'agent : quels systèmes il atteint, quelles opérations il peut réaliser et dans quelles conditions un humain doit valider. La première est un problème de revue de contenu, la seconde un problème de contrôle d'accès.

Faut-il une plateforme dédiée à la gouvernance des agents IA ?

Pour la plupart des PME et ETI, non. Les cinq contrôles qui comptent (découverte, identité unique, moindre privilège, seuils d'approbation, certification et révocation) sont des capacités IAM et SaaS Management. Une plateforme dédiée de gouvernance à l'exécution se justifie quand vous construisez des agents en interne à grande échelle avec des chaînes d'outils sur mesure. Si vous consommez surtout des agents bâtis sur Copilot Studio, Agentforce, n8n ou équivalent, étendre votre pile d'identité existante est plus rapide et moins coûteux.

Qui doit porter la gouvernance des agents IA : la DSI, la sécurité ou la conformité ?

La DSI doit porter le registre et le cycle de vie, parce qu'elle opère déjà le provisionnement et le déprovisionnement. La sécurité doit fixer les seuils d'approbation et les standards de permissions. La conformité doit porter la correspondance avec NIS2, ISO 27001 et l'AI Act. Répartir la responsabilité sur trois fonctions sans propriétaire du registre est le schéma d'échec à éviter.

Comment l'AI Act s'applique-t-il aux agents IA ?

Cela dépend du cas d'usage, pas de la technologie. Les obligations de transparence de l'article 50 s'appliquent à partir du 2 août 2026. Les obligations relatives aux systèmes autonomes à haut risque de l'annexe III, qui couvrent notamment l'emploi, l'éducation, l'évaluation de solvabilité et l'accès aux services essentiels, s'appliquent à partir du 2 décembre 2027 après le Digital Omnibus sur l'IA adopté en juin 2026. Les exigences de journalisation de l'article 12 et de supervision humaine de l'article 14 sont les dispositions les plus directement pertinentes pour la conception des agents.

Qu'est-ce qu'un agent IA orphelin et pourquoi est-ce un problème ?

Un agent IA orphelin est un agent dont le propriétaire humain responsable a quitté l'organisation ou n'est plus identifiable, alors que ses identifiants restent actifs. C'est un problème parce que l'agent continue d'exécuter des actions avec des permissions valides sans personne pour les justifier, ce qui constitue à la fois une exposition de sécurité et un écart d'audit au regard des exigences de contrôle d'accès telles que la mesure A.5.18 d'ISO 27001.

Comment découvrir les agents IA créés par des collaborateurs sans en informer la DSI ?

Combinez quatre signaux : les enregistrements d'autorisations OAuth dans votre fournisseur d'identité, les dépenses SaaS et IA dans les données financières, les journaux d'administration des plateformes agentiques sous licence de l'entreprise, et les signaux navigateur pour les plateformes sans API d'administration. Chaque source prise isolément manque une catégorie, ce qui explique pourquoi une plateforme convergente SaaS Management et identité remonte davantage qu'un simple audit d'IdP.

Conclusion

La gouvernance des agents ressemble à un problème nouveau parce que les éditeurs qui la vendent ont besoin qu'elle en soit un. Retirez le cadrage et l'exigence redevient familière : savoir ce qui a accès à vos systèmes, donner à chaque accès un propriétaire nommé, le cadrer sur la tâche, mettre un point de contrôle sur les actions dangereuses, et le retirer quand il n'est plus nécessaire. Votre pile IAM a été construite exactement pour cela. Elle n'a simplement pas encore été pointée vers les identités non humaines.

Les équipes qui passeront leur premier audit lié aux agents en 2027 sont celles qui construisent le registre en 2026.

Découvrez comment Corma détecte, cadre et révoque les accès sur l'ensemble de votre parc SaaS et IA depuis une seule plateforme. Demandez une démo.