Risque des agents IA : pourquoi les agents ont besoin d’un nouveau modèle de gouvernance

12 avril 2026 · 8 min de lecture

Les agents IA sont en train de devenir le nouveau grand sujet de l’IA en entreprise. Les éditeurs ajoutent des agents dans les suites de productivité, les plateformes de service client, les outils pour développeurs, les systèmes de workflow et les environnements low-code. Microsoft Copilot Studio, par exemple, se présente désormais comme une plateforme permettant de créer, personnaliser, déployer et gérer des agents IA capables de se connecter aux données métier, d’utiliser des outils et d’être publiés dans des canaux comme Microsoft 365 Copilot, Teams, SharePoint et les sites web.

Ce mouvement est important. Mais il crée aussi un problème de langage.

Tous les produits appelés "agents" ne portent pas le même niveau de risque.

Un simple assistant prompt-réponse appuyé sur quelques documents n’est pas la même chose qu’un agent de workflow autonome qui surveille des événements, décide quoi faire, appelle des outils, met à jour des enregistrements, envoie des messages, escalade des cas ou déclenche des processus métier en arrière-plan. Les deux peuvent être commercialisés comme des agents. Ils n’ont pourtant pas besoin du même modèle de gouvernance.

Idée clé : un agent est une catégorie de produit, mais le comportement agentique est une propriété de risque.

De l’IA qui répond à l’IA qui agit

La gouvernance IA traditionnelle commence souvent par des questions comme :

• Le modèle est-il précis ?
• La sortie est-elle biaisée ?
• Le système explique-t-il son résultat ?
• Les données personnelles sont-elles traitées légalement ?
• Les utilisateurs peuvent-ils se fier à la réponse ?

Ces questions restent importantes. Mais les systèmes agentiques ajoutent une nouvelle couche : l’action.

Avec les agents, la question de gouvernance passe de :

Qu’est-ce que le modèle a dit ?

À :

Que l’agent avait-il le droit de faire, qu’a-t-il réellement fait, pourquoi l’a-t-il fait, qui l’a approuvé, et pouvons-nous le prouver ?

C’est un problème de contrôle très différent.

Un chatbot peut donner une mauvaise réponse. Un agent peut donner une mauvaise réponse puis agir sur cette base. Il peut appeler une API, mettre à jour un ticket, envoyer un e-mail à un client, modifier un enregistrement, récupérer des données sensibles, lancer un remboursement, créer une tâche ou transmettre le travail à un autre agent.

Dès qu’un système d’IA peut affecter un autre système, la gouvernance de l’IA devient une gouvernance opérationnelle.

Le label "agent" est trop large

La propre documentation de Microsoft rend ce spectre visible. Microsoft 365 Copilot décrit des agents allant de simples agents prompt-réponse jusqu’à des agents pleinement autonomes. Copilot Studio ajoute ensuite des capacités autonomes où les agents peuvent agir à partir de déclencheurs, d’instructions et de garde-fous, en arrière-plan plutôt qu’en répondant seulement dans une conversation.

Ce spectre est utile. Mais il crée aussi de la confusion.

Beaucoup d’organisations entendent le mot "agent" et pensent avoir affaire à une seule catégorie. En pratique, il existe plusieurs niveaux de comportement agentique.

Niveau 1 : assistant de connaissance

Il s’agit d’un outil faiblement agentique. Il répond à des questions à l’aide d’instructions et de sources de connaissance sélectionnées.

Exemple :

• Un assistant RH interne qui répond aux questions sur les politiques à partir de documents approuvés.
• Un agent Copilot Studio qui répond dans Teams à partir de sujets configurés et de connaissances sélectionnées.

Risques principaux :

• Réponses incorrectes
• Connaissances obsolètes
• Divulgation inappropriée
• Surconfiance des utilisateurs

Focus de gouvernance :

• Qualité du contenu
• Accès aux sources de connaissance
• Avertissements et escalade
• Journalisation de base

Niveau 2 : assistant de workflow guidé

Cet outil aide un utilisateur à accomplir une tâche, mais l’humain reste aux commandes.

Exemple :

• Un assistant support qui rédige une réponse et suggère l’étape suivante.
• Un assistant commercial qui résume les informations d’un compte et propose un e-mail de suivi.

Risques principaux :

• Mauvaises recommandations
• Contexte incomplet
• Résumés trompeurs
• Validation automatique par l’utilisateur

Focus de gouvernance :

• Revue humaine
• Transparence des sources
• Limites du workflow
• Formation des utilisateurs

Niveau 3 : agent utilisant des outils

C’est là que le risque commence à changer de manière significative. L’agent peut appeler des outils, des API, des flows ou des connecteurs.

Exemple :

• Un agent de support IT qui crée des tickets et vérifie l’état d’un appareil.
• Un agent de service client qui consulte des commandes et lance des actions autorisées.
• Un agent Copilot Studio connecté à des flows Power Automate ou à des API de systèmes métier.

Risques principaux :

• Usage non autorisé des outils
• Permissions trop larges
• Prompt injection conduisant à un mauvais usage des outils
• Fuite de données via les entrées ou sorties d’outils
• Traçabilité incomplète

Focus de gouvernance :

• Matrice de permissions des outils
• Accès en moindre privilège
• Règles d’approbation
• Journaux d’audit
• Application de politiques à l’exécution

Niveau 4 : agent de workflow autonome

L’agent peut surveiller des événements, prendre des décisions et exécuter des tâches sans attendre un prompt utilisateur.

Exemple :

• Un agent qui surveille les e-mails fournisseurs, extrait les changements contractuels, classe le risque et route les validations.
• Un agent finance qui surveille les exceptions de rapprochement et initie des workflows de correction.
• Un agent sécurité qui observe des alertes, enrichit des cas et prend des mesures de confinement.

Risques principaux :

• Action non approuvée
• Mauvaise décision à grande échelle
• Échec silencieux
• Échec d’escalade
• Perturbation du processus métier
• Lacunes de preuve de conformité

Focus de gouvernance :

• Validation des déclencheurs
• Limites de décision
• Approbation humaine pour les actions critiques
• Monitoring et alerting
• Réponse à incident
• Kill switches

Niveau 5 : orchestration multi-agents

Plusieurs agents se coordonnent, délèguent ou se transmettent du travail.

Exemple :

• Un processus d’onboarding client où un agent collecte les documents, un autre vérifie la conformité, un autre met à jour les systèmes et un autre communique avec le client.

Risques principaux :

• Manque de responsabilité claire
• Instructions contradictoires
• Propagation d’erreurs
• Délégation cachée
• Analyse des causes difficile

Focus de gouvernance :

• Identité des agents
• Règles de délégation
• Traçabilité de bout en bout
• Tests au niveau système
• Modèle d’ownership

Règle pratique : ne gouvernez pas le label, gouvernez le comportement.

Exemples de cas d’usage par niveau d’agent

Ces niveaux ne sont pas des boîtes parfaites. C’est une manière pratique de demander : quel degré réel d’agency ce système possède-t-il ?

Les outils faiblement agentiques ont quand même besoin de gouvernance

Ce serait une erreur de considérer les plateformes faiblement agentiques comme inoffensives. Un simple agent Copilot Studio peut quand même exposer des informations sensibles, donner des réponses trompeuses, s’appuyer sur des connaissances obsolètes ou créer un faux sentiment d’autorité.

Mais les outils faiblement agentiques relèvent généralement d’un modèle de gouvernance plus léger, car le système répond surtout, sans agir de manière autonome.

Pour ces outils, les questions les plus importantes sont :

• À quelles sources de connaissance l’agent a-t-il accès ?
• Les permissions sont-elles correctement héritées depuis Microsoft 365, SharePoint ou d’autres systèmes ?
• Les réponses sont-elles ancrées dans un contenu approuvé ?
• L’utilisateur sait-il quand vérifier ou escalader ?
• Les conversations sont-elles journalisées de manière appropriée ?
• Qui est propriétaire de l’agent après sa mise en production ?

Il s’agit bien de gouvernance, mais surtout de gouvernance du contenu, de l’accès, de la qualité et de l’ownership.

Le risque plus lourd commence lorsque l’agent obtient des outils, de l’autonomie, de la mémoire, des déclencheurs ou la capacité d’affecter des systèmes métier.

À ce stade, le modèle de gouvernance doit inclure une conception de contrôle, pas seulement une revue de contenu.

Pourquoi la gouvernance IA existante ne suffit pas

De nombreux programmes de gouvernance IA ont été conçus autour des modèles et des cas d’usage. Ils demandent aux équipes de documenter le modèle, classifier le cas d’usage, évaluer l’impact vie privée, tester les biais et approuver le déploiement.

C’est un bon début. Mais les agents introduisent des risques qui ne sont pas totalement couverts par une gouvernance centrée sur le modèle.

1. Les agents ont des permissions

Les modèles produisent des sorties. Les agents, eux, ont souvent des permissions.

Ils peuvent accéder à des fichiers, interroger des bases de données, appeler des API, envoyer des e-mails, créer des enregistrements ou invoquer des workflows. Cela signifie que la gouvernance des agents doit emprunter des éléments à l’identity and access management.

La question clé devient :

Que cet agent a-t-il le droit de faire, dans quelles conditions, et qui a approuvé ces permissions ?

2. Les agents ont des outils

Les outils créent une nouvelle surface d’attaque. Une instruction malveillante cachée dans un document, un e-mail, une page web, un ticket ou une source de connaissance récupérée peut tenter de manipuler l’agent pour qu’il utilise mal ses outils.

Avec les agents, le prompt injection ne consiste pas seulement à influencer le texte. Il peut s’agir d’influencer une action.

3. Les agents ont un comportement à l’exécution

Une évaluation du modèle avant le lancement ne suffit pas. Les agents peuvent se comporter différemment selon les déclencheurs, le contexte, les réponses d’outils, les données récupérées, les instructions utilisateur et l’état du workflow.

La gouvernance doit donc continuer à l’exécution via la journalisation, le monitoring, les alertes et la réponse à incident.

4. Les agents ont besoin de limites d’action

Une réponse acceptable n’est pas la même chose qu’une action acceptable.

Par exemple, un agent peut être autorisé à rédiger une recommandation de remboursement sans être autorisé à exécuter le remboursement. Il peut être autorisé à créer un ticket sans être autorisé à le fermer. Il peut être autorisé à résumer un risque contractuel sans pouvoir envoyer le contrat révisé à la contrepartie.

Ces limites doivent être explicites.

5. Les agents créent des exigences de preuve

Quand quelque chose se passe mal, l’organisation doit pouvoir reconstruire la séquence :

• Qu’est-ce qui a déclenché l’agent ?
• Quelles données a-t-il vues ?
• Quelle instruction a-t-il suivie ?
• Quels outils a-t-il appelés ?
• Quelle décision de politique a été prise ?
• Une approbation humaine était-elle requise ?
• Qui a approuvé ou rejeté l’action ?
• Qu’est-ce qui a changé dans le système métier ?

Si vous ne pouvez pas répondre à ces questions, vous n’avez pas de gouvernance des agents. Vous avez de l’espoir agentique.

Un modèle de gouvernance pratique pour les agents IA

Un modèle de gouvernance utile pour les agents devrait inclure au moins huit couches de contrôle.

1. Inventaire des agents

On ne peut pas gouverner des agents que l’on ne voit pas.

Suivez chaque agent avec :

• Propriétaire
• Objectif
• Groupe d’utilisateurs
• Modèle ou plateforme
• Sources de données
• Outils et connecteurs
• Niveau d’autonomie
• Niveau de risque
• Statut d’approbation
• Date de revue
• Responsable du monitoring

2. Tiering du risque agentique

Classifiez les agents selon leur comportement, pas selon le label du fournisseur.

Dimensions utiles :

• Peut-il accéder à des données sensibles ?
• Peut-il appeler des outils ?
• Peut-il écrire dans des systèmes ?
• Peut-il agir sans prompt utilisateur ?
• Peut-il déclencher une communication externe ?
• Peut-il prendre ou influencer des décisions à fort impact ?
• Peut-il déléguer à d’autres agents ?

3. Matrice de permissions des outils

Chaque outil devrait avoir une politique explicite.

Pour chaque outil, définissez :

• Autorisé ou bloqué
• Lecture seule ou capacité d’écriture
• Approbation requise ou non
• Seuils maximums
• Classes de données autorisées
• Groupes d’utilisateurs autorisés
• Exigences de journalisation

Un outil de remboursement, par exemple, pourrait autoriser les recommandations en brouillon sans validation, exiger une validation sous un certain seuil et bloquer les remboursements autonomes au-dessus d’un certain seuil.

4. Points d’approbation humaine

Le human-in-the-loop ne doit pas être un slogan. Il doit être conçu dans le workflow.

Une approbation devrait être requise pour :

• Les engagements juridiques
• Les transactions financières
• Les décisions RH
• Les actions qui impactent le client
• Les changements sensibles en sécurité
• Les actions irréversibles
• Les décisions automatisées à grand volume

L’approbation doit devenir une partie de la piste d’audit.

5. Tests de prompt injection et de mauvais usage des outils

Les agents doivent être testés contre des scénarios adversariaux avant la production.

Tester :

• Les documents récupérés malveillants
• Les instructions contradictoires
• Les tentatives d’exfiltration de données
• Les tentatives de contournement de validation
• Les tentatives d’usage d’outils non autorisés
• Les tentatives d’écrasement des instructions système
• Les tentatives de déclencher des actions à partir d’entrées non fiables

6. Audit logging à l’exécution

Les logs doivent capturer plus que la réponse finale.

Au minimum :

• Déclencheur utilisateur ou événementiel
• ID de l’agent
• Version du prompt ou des instructions
• Version du modèle
• Contexte récupéré
• Appels d’outils
• Entrées et sorties d’outils
• Décisions de politique
• Approbations humaines
• Action finale
• ID de trace

7. Monitoring et kill switches

Les agents ont besoin de contrôles opérationnels.

À surveiller :

• Usage inattendu des outils
• Accès inhabituel aux données
• Échecs répétés
• Pics d’escalade
• Anomalies de coût
• Comportement en boucle
• Actions en dehors des schémas normaux

Un agent à haut risque devrait avoir une procédure claire de pause, révocation ou kill switch.

8. Revues de cycle de vie

Les agents évoluent. Leurs outils, prompts, sources de données, modèles, utilisateurs et contextes métier changent.

Revoyez les agents lorsque :

• Un nouvel outil est ajouté
• Une nouvelle source de données est connectée
• L’autonomie augmente
• Le modèle change
• L’agent est publié dans un nouveau canal
• Le processus métier change
• Un incident survient

La leçon de Microsoft Copilot Studio

L’approche de Microsoft est utile car elle montre le schéma qui émerge dans l’entreprise. Copilot Studio réunit création d’agents low-code, grounding sur données métier, outils, flows, API, canaux de publication, capacités de gestion, analytique et fonctions de gouvernance.

Mais elle montre aussi pourquoi les entreprises ont besoin de leur propre langage de risque des agents.

Un agent déclaratif simple ou prompt-réponse peut être une extension gérable de la gestion des connaissances. Un agent Copilot Studio autonome connecté à des workflows métier est plus proche d’un acteur de processus numérique. Un système multi-agents coordonnant plusieurs outils et départements est plus proche d’un système opérationnel distribué.

Ces systèmes ne devraient pas passer par la même checklist d’approbation.

La question de risque n’est pas :

Est-ce que cela a été construit avec Copilot Studio, Azure AI Foundry, LangGraph, OpenAI, CrewAI ou un autre framework ?

La meilleure question est :

Quel est le degré d’agency de ce système, et quels contrôles correspondent à ce degré d’agency ?

Ce cadrage aide aussi à éviter les angles morts liés aux fournisseurs. Une plateforme low-code peut offrir des garde-fous utiles, des contrôles d’administration et une intégration avec les outils de gouvernance d’entreprise. C’est précieux. Mais l’organisation doit quand même décider quelles actions sont acceptables, quelles approbations sont requises, quelles preuves doivent être conservées et qui est propriétaire de l’agent après le déploiement.

Une règle simple

Plus un système d’IA peut agir, plus la gouvernance doit passer de la documentation au contrôle.

Utilisez cette règle :

• S’il ne fait que répondre, gouvernez le contenu, l’accès et l’exactitude.
• S’il recommande, gouvernez l’aide à la décision et la revue humaine.
• S’il utilise des outils, gouvernez les permissions et les politiques d’appels d’outils.
• S’il agit de façon autonome, gouvernez les déclencheurs, les validations, le monitoring et la réponse à incident.
• S’il se coordonne avec d’autres agents, gouvernez l’identité, la délégation et la traçabilité de bout en bout.

C’est la base de AI Agent Risk.

Que faire ensuite

Pour les organisations qui démarrent maintenant, les premières étapes sont pratiques :

1. Créer un inventaire de tous les agents et systèmes de type agent.
2. Les classifier selon leur niveau d’agency, et non selon le nom du produit.
3. Identifier quels agents peuvent accéder à des données, appeler des outils ou déclencher des actions.
4. Définir une matrice de permissions pour chaque agent utilisant des outils.
5. Exiger une validation humaine pour les actions sensibles ou irréversibles.
6. Journaliser les actions des agents de manière à soutenir l’audit et la réponse à incident.
7. Tester les agents contre le prompt injection, la fuite de données et le contournement de validation.
8. Revoir les agents chaque fois que leur autonomie, leurs outils ou leur accès aux données augmentent.

L’avenir de la gouvernance de l’IA ne portera pas seulement sur les modèles. Il portera sur des systèmes qui perçoivent, décident et agissent à l’intérieur de processus métier.

C’est pourquoi les agents ont besoin d’un nouveau modèle de gouvernance.

Sources

• Microsoft Copilot Studio : créer, personnaliser et lancer des agents IA
• Microsoft Learn : utiliser des agents dans Microsoft 365 Copilot Chat
• Microsoft Learn : concevoir des capacités d’agents autonomes dans Copilot Studio