La gouvernance des agents IA est l'ensemble des règles qui encadrent ce qu'un agent a le droit de faire, avec quels accès, sous quel contrôle humain, et avec quelles traces. La différence avec la gouvernance d'un assistant tient en un mot : un assistant répond, un agent agit. Il appelle des outils, écrit dans des systèmes, enchaîne des décisions. Chaque permission accordée devient une action possible — y compris une action que personne n'a voulue.
C'est pour cela que les règles pensées pour les assistants conversationnels ne suffisent plus.
En quoi un agent change-t-il la gouvernance ?
| Assistant | Agent | |
|---|---|---|
| Ce qu'il produit | Une réponse, lue par un humain | Une action dans un système |
| Qui décide de l'effet | L'humain qui lit | L'agent, puis éventuellement un humain |
| Risque principal | Une réponse fausse | Une action non voulue, à grande échelle |
| Contrôle naturel | La relecture | Aucun, sauf s'il est construit |
Le dernier point est le cœur du sujet. Avec un assistant, la relecture humaine existe par construction. Avec un agent, elle n'existe que si on l'a placée dans le circuit.
Les sept bonnes pratiques de gouvernance des agents IA
1. Tenir un registre des agents, chacun avec un propriétaire nommé. Pour chaque agent : sa finalité, les outils qu'il appelle, les données qu'il lit et écrit, son responsable métier, sa date de mise en service. Un agent sans propriétaire est un agent que personne n'arrêtera le jour où il dérive.
2. Accorder le strict nécessaire — et rien d'autre. Le référentiel de l'OWASP pour les applications à base de modèles de langage classe parmi ses dix risques majeurs l'« agentivité excessive » (Excessive Agency, LLM06 dans l'édition 2025) : un agent doté de plus d'outils, de plus de fonctions ou de plus de droits que sa tâche ne l'exige. La parade est connue : un compte de service propre à chaque agent, des connexions en lecture seule quand la lecture suffit, des périmètres d'API restreints.
3. Placer une validation humaine devant les actions sensibles. Écriture de données, suppression, paiement, envoi à l'extérieur, modification d'infrastructure : ces actions passent par une approbation humaine explicite. Tout le reste peut être automatisé. Le tri se fait par conséquence de l'action, pas par fréquence.
4. Ne jamais coder de secrets en dur dans un agent. Une clé d'API écrite dans une consigne, un fichier de configuration ou le code d'un outil finit toujours par fuiter — dans un journal, une réponse, un dépôt. Les secrets vivent dans un coffre, sont injectés à l'exécution, rattachés à l'identité de l'agent et renouvelés régulièrement. Une consigne système n'est pas un lieu sûr : elle peut être extraite.
5. Journaliser chaque action, pas seulement chaque réponse. Pour un agent, la trace utile n'est pas la conversation : c'est la suite des outils appelés, avec leurs paramètres et leurs résultats. Sans elle, impossible de reconstituer pourquoi une commande a été passée ou un fichier supprimé. Pour les systèmes à haut risque, l'article 12 de l'AI Act impose d'ailleurs l'enregistrement automatique des événements.
6. Tester l'agent contre l'injection de consignes avant de l'ouvrir. Un agent qui lit des contenus externes — mails, pages web, documents — peut y trouver des instructions déguisées. C'est le premier risque du même référentiel OWASP (Prompt Injection, LLM01). Un jeu d'évaluation qui inclut des tentatives d'injection, rejoué à chaque modification, est la seule protection qui se vérifie.
7. Prévoir l'arrêt — et l'avoir testé. Chaque agent doit pouvoir être suspendu en une action, sans dépendre de son développeur. Le retrait se teste avant la mise en service, pas le jour de l'incident.
Que doit offrir une plateforme de gouvernance d'agents IA ?
Les fonctions à exiger d'un outil, ou à construire si l'on n'en achète pas :
| Fonction | Ce qu'elle permet | Question à poser au fournisseur |
|---|---|---|
| Inventaire | Voir tous les agents actifs et leurs propriétaires | Détecte-t-elle les agents créés hors du circuit officiel ? |
| Identités et permissions | Un compte et des droits par agent | Peut-on restreindre un agent outil par outil ? |
| Gestion des secrets | Injecter les clés sans les exposer | Où sont stockés les secrets, qui y accède ? |
| Journal des actions | Reconstituer chaque décision | Les paramètres des appels d'outils sont-ils conservés ? |
| Évaluation | Rejouer des cas de test à chaque changement | Les tests d'injection sont-ils inclus ? |
| Coûts | Suivre la consommation par agent | Peut-on fixer un plafond par agent ? |
| Arrêt | Suspendre un agent immédiatement | L'arrêt fonctionne-t-il sans le fournisseur ? |
Une plateforme qui couvre l'inventaire et les coûts mais pas les journaux d'actions ni l'arrêt donne une impression de maîtrise sans la substance.
Ce qu'il faut journaliser pour un agent
| Élément | Pourquoi |
|---|---|
| Demande initiale et son auteur | Rattacher l'action à une intention humaine |
| Version datée du modèle et de la consigne | Un changement de version change le comportement |
| Chaque outil appelé, avec ses paramètres | C'est là que se trouve l'action réelle |
| Résultat de chaque appel | Comprendre l'enchaînement des décisions |
| Validations humaines : qui, quand, quoi | Prouver que la supervision a eu lieu |
| Erreurs et interruptions | Détecter les dérives avant les utilisateurs |
Les erreurs les plus fréquentes
Donner à l'agent les droits de son créateur. Le développeur teste avec ses propres accès, l'agent part en production avec. Il hérite alors de permissions que personne n'a décidé de lui accorder.
Confondre journal de conversation et journal d'actions. Le premier montre ce que l'agent a dit, le second ce qu'il a fait. En cas d'incident, seul le second sert.
Ouvrir à tous avant d'avoir testé l'arrêt. Un agent qui ne s'arrête pas proprement se découvre toujours au pire moment.
Gouverner l'agent sans gouverner ses outils. Un agent bien encadré qui appelle un connecteur aux droits trop larges reste un agent dangereux.
Ces règles prolongent le cadre général de la gouvernance de l'IA et le registre de preuves des agents en production. Les décisions d'ouverture et d'arrêt relèvent du comité de gouvernance IA ; la sécurisation des données est détaillée dans notre article sur les fuites de données par les agents.
Questions fréquentes
Qu'est-ce que la gouvernance des agents IA ? C'est l'ensemble des règles qui encadrent ce qu'un agent a le droit de faire, avec quels accès, sous quel contrôle humain et avec quelles traces. Elle se distingue de la gouvernance des assistants parce qu'un agent agit dans des systèmes au lieu de produire une réponse lue par un humain.
Quelles sont les bonnes pratiques de gouvernance des agents IA ? Sept règles couvrent l'essentiel : un registre avec un propriétaire par agent, le moindre privilège, une validation humaine devant les actions sensibles, aucun secret codé en dur, une journalisation de chaque action, des tests d'injection avant ouverture, et un arrêt testé avant la mise en service.
Comment éviter les secrets codés en dur dans un agent IA ? En stockant les clés dans un coffre de secrets, en les injectant à l'exécution plutôt qu'en les écrivant dans la consigne ou le code, en les rattachant à une identité propre à chaque agent et en les renouvelant régulièrement. Une consigne système peut être extraite : elle ne doit jamais contenir de secret.
Que faut-il journaliser pour un agent IA ? La demande et son auteur, la version du modèle et de la consigne, chaque outil appelé avec ses paramètres et son résultat, les validations humaines et les erreurs. Le journal de conversation seul ne suffit pas : il montre ce que l'agent a dit, pas ce qu'il a fait.
L'AI Act s'applique-t-il aux agents IA ? Oui, selon l'usage. Un agent n'est pas une catégorie à part : c'est son domaine d'application qui détermine son niveau de risque. Un agent utilisé dans un domaine à haut risque hérite des obligations correspondantes, dont l'enregistrement automatique des événements prévu à l'article 12.
