La gouvernance des agents IA se cadre comme une architecture de contrôle, pas comme une note interne. Le vrai sujet, c’est l’identité, les accès, les garde-fous runtime, les logs et les limites humaines. Sinon, un agent utile devient vite un risque business invisible.
Besoin d'aide ? Découvrez les solutions de notre agence d'agents IA.
Pourquoi agir avant la production ?
Il faut agir avant la production parce qu’un agent IA gagne vite des accès, des outils et de l’autonomie, parfois bien au-delà de son besoin initial. Au départ, il résume des emails ou classe des demandes. Puis quelqu’un se dit que ce serait pratique de le connecter au CRM, à la messagerie, à une base interne, à l’outil de ticketing, puis à un scénario d’automatisation Low Code. Et là, sans bruit, on n’a plus un assistant. On a un acteur logiciel capable d’agir.
Le passage du prototype à la production va souvent trop vite. Je le vois régulièrement. Le prototype marche, il fait gagner du temps, l’équipe métier pousse pour l’utiliser, et la sécurité arrive après. Le problème, c’est que chaque connecteur ajoute une surface de risque. Une surface de risque, c’est simplement une nouvelle porte possible pour lire, modifier, envoyer, supprimer ou déclencher quelque chose.
Trois forces rendent la gouvernance urgente dès le départ :
- Un agent compromis peut agir sur plusieurs systèmes à la fois. Si quelqu’un manipule l’agent, il peut créer un ticket, envoyer un email, lire une fiche client et déclencher un workflow dans la même chaîne.
- Un agent hérite souvent de permissions trop larges. On lui donne un compte qui “marche partout” pour aller plus vite, au lieu de limiter précisément ce qu’il peut faire.
- Le nombre d’agents peut dépasser la capacité réelle de supervision. Un agent, ça se surveille. Dix agents aussi. Cinquante agents bricolés dans plusieurs équipes, c’est autre chose.
J’ai vu des automatisations Low Code partir en production avec un compte service partagé parce que c’était plus rapide. Trois mois plus tard, personne ne savait vraiment quelles actions étaient possibles avec ce compte. Ni qui l’utilisait. Ni dans quels scénarios il était appelé. C’est exactement comme ça qu’on perd le contrôle, pas par mauvaise intention, juste par empilement.
Les référentiels de sécurité IA comme l’OWASP Top 10 for LLM Applications parlent très clairement de ces sujets, notamment l’excès d’autonomie et les injections de prompt. Une injection de prompt, c’est quand une instruction cachée ou malveillante pousse le modèle à ignorer les règles prévues. Si l’agent a trop de droits derrière, l’impact n’est plus théorique.
Plus l’agent est autonome, plus les contrôles doivent être pensés au moment du déploiement. Pas après un incident. Après, on ne gouverne plus vraiment, on répare.
Que faut-il gouverner ?
Il faut gouverner l’identité de l’agent, ses accès, ses décisions, ses garde-fous, ses logs, son propriétaire et son cycle de vie. Pour moi, c’est le minimum vital. Pas un joli document de politique IA rangé dans un Drive que personne n’ouvre jamais.
La gouvernance des agents IA doit être pensée comme une architecture opérationnelle. Elle doit dire clairement qui peut faire quoi, avec quels outils, sur quelles données, dans quel environnement, avec quelles validations. Sinon, on laisse un agent agir avec des droits flous, des données sensibles, et parfois aucune trace exploitable. J’ai déjà vu ça chez un client : l’agent marchait très bien, trop bien même, mais personne ne savait vraiment quel compte API il utilisait ni qui devait répondre en cas d’incident.
Avant la mise en production, je cadre toujours quelques piliers très concrets :
- Identité et contrôle d’accès : L’agent doit avoir sa propre identité, pas celle d’un humain. Ses permissions doivent être minimales et traçables.
- Garde-fous runtime : Le runtime, c’est le moment où l’agent agit vraiment. Il faut limiter les outils appelables, filtrer certaines actions, bloquer les sorties à risque.
- Observabilité et évaluation : Il faut des logs, des métriques, des traces, et des tests réguliers pour vérifier que l’agent reste fiable.
- Limites décisionnelles et conformité : L’agent peut proposer, exécuter ou escalader. Cette frontière doit être explicite.
- Inventaire et ownership : Chaque agent doit avoir un propriétaire clair. Sans owner, pas de production.
L’inventaire doit être vivant. Pour chaque agent, je documente l’objectif, l’environnement, le propriétaire, le contact on-call, le modèle d’identité, le stockage des credentials, la surface d’intégration, les permissions, la sensibilité des données traitées et les points d’audit. C’est moins sexy qu’une démo IA, mais c’est ce qui évite les mauvaises surprises.
Cette logique colle assez bien aux pratiques sérieuses du marché. Le NIST AI Risk Management Framework insiste sur la gouvernance, la cartographie, la mesure et la gestion des risques. L’ISO/IEC 42001 va dans le même sens avec l’idée d’un système de management de l’IA. Pas besoin d’en faire un cours juridique. Je les utilise surtout comme repères de maturité.
| Composant à gouverner | Question à poser | Risque si on ne le fait pas |
| Identité de l’agent | Quel compte ou service account l’agent utilise-t-il ? | Actions impossibles à attribuer clairement. |
| Accès et permissions | De quels droits l’agent a-t-il vraiment besoin ? | Surpermission, fuite de données, action non autorisée. |
| Garde-fous runtime | Qu’est-ce que l’agent peut faire ou ne jamais faire ? | Exécution d’actions dangereuses sans validation. |
| Logs et observabilité | Peut-on reconstruire une décision ou une action ? | Incident impossible à analyser. |
| Ownership | Qui répond quand l’agent dysfonctionne ? | Responsabilité diluée, correction lente. |
Comment limiter les accès ?
On limite les accès en liant chaque action de l’agent à une identité connue, avec le moindre privilège, et jamais à un compte partagé trop puissant.
Pour moi, l’identité est le cœur de la gouvernance des agents IA. Si je ne sais pas qui agit, dans quel contexte, avec quelle permission, et avec quelle trace derrière, je n’ai pas une gouvernance. J’ai une boîte noire qui clique partout avec un badge admin.
Un agent ne doit pas agir avec un super compte service qui peut tout faire “parce que c’est plus simple”. C’est souvent comme ça que les problèmes arrivent. Une action doit pouvoir être reliée à un utilisateur, à un agent précis, à une permission donnée, et à un journal exploitable. Un journal, c’est simplement une trace horodatée qui dit : qui a fait quoi, où, quand, et pourquoi si possible.
Le principe clé, c’est le moindre privilège. L’agent accède uniquement aux outils, aux données et aux actions nécessaires à sa mission. Pas plus. Un agent qui doit résumer des tickets n’a pas besoin de supprimer des clients dans le CRM. Un agent qui prépare une réponse commerciale n’a pas besoin de modifier les conditions de remise.
L’excès de permissions est une cause très concrète d’actions excessives. Suppression non prévue. Envoi externe non contrôlé. Extraction de données sensibles. Modification dans un système métier. J’ai déjà vu des automatisations “temporaires” garder des droits larges pendant des mois. Le temporaire, en entreprise, ça devient vite permanent.
Les secrets doivent aussi être traités sérieusement. Les clés API, tokens, credentials OAuth et mots de passe ne doivent jamais être écrits en dur dans un scénario d’automatisation, un prompt, une variable visible ou un fichier partagé. Ils vont dans un coffre sécurisé, comme un secret manager. Ce coffre contrôle l’accès, journalise l’usage, permet la rotation et évite qu’un copier-coller finisse dans Slack ou dans Notion.
| Identité utilisateur | L’agent agit au nom d’une personne identifiable, avec ses droits et ses limites. |
| Identité agent | L’agent a sa propre identité technique, traçable, avec des droits définis pour sa mission. |
| Compte service | Un compte technique utilisé par un système. Acceptable s’il est limité et tracé. Dangereux s’il est partagé et trop puissant. |
Un exemple simple. Un agent support client peut lire les tickets et proposer une réponse. Très bien. Mais il ne doit pas modifier les conditions commerciales ou déclencher un remboursement sans validation humaine. Là, on passe d’une aide à la décision à une action métier sensible.
- Identité nominative ou traçable pour chaque action.
- Permissions minimales, uniquement liées à la mission de l’agent.
- Secrets stockés dans un coffre sécurisé.
- Rotation régulière des credentials.
- Révocation des accès à la retraite de l’agent.
Quels garde-fous en runtime ?
Les bons garde-fous runtime sont ceux qui bloquent vraiment l’action quand une règle échoue. Runtime, ça veut dire au moment où l’agent tourne, décide, appelle un outil, lit une donnée, envoie un message. Pas seulement pendant la conception.
Un agent peut recevoir un prompt malveillant, tomber sur une donnée sensible, appeler un outil non prévu, ou tenter une action hors politique. Si le contrôle ne peut pas interrompre l’action, ce n’est pas un garde-fou. C’est une alerte décorative. J’ai vu ça chez un client : tout était “surveillé”, mais rien ne bloquait. L’agent pouvait quand même envoyer le mauvais fichier au mauvais destinataire. Les logs étaient propres, le risque était réel.
Les contrôles runtime utiles sont très concrets. Ils doivent agir avant que le dommage soit fait :
- Blocage des injections de prompt, quand une instruction tente de contourner les règles du système ou de voler du contexte.
- Filtrage des appels d’outils hors politique, par exemple empêcher un agent support de lancer une suppression en base.
- Masquage ou caviardage des données sensibles avant sortie, comme un IBAN, un token API, une donnée RH ou médicale.
- Validation du périmètre utilisateur, pour vérifier que l’agent agit bien avec les droits de la personne concernée.
- Contrôle du destinataire avant tout envoi externe, surtout email, Slack, CRM ou outil ticketing.
- Seuils sur les actions répétées ou coûteuses, pour éviter les boucles, les abus API, ou les dépenses cloud absurdes.
L’observabilité est indispensable. Il faut journaliser les appels d’outils, les décisions, les prompts critiques, les réponses, les usages de credentials et les refus de politique. Ces logs doivent être rejouables. Sinon, après incident, on devine au lieu de comprendre.
Il faut aussi tester en continu. Red teaming, tests adversariaux, scénarios de prompt injection, détection d’anomalies, comparaison entre comportement attendu et comportement réel. Ces tests ne s’arrêtent pas au déploiement, parce que les modèles changent, les outils changent, et les usages changent encore plus vite.
| Menace | Contrôle runtime | Trace à conserver |
| Injection de prompt | Détection et blocage avant exécution | Prompt reçu, règle déclenchée, décision |
| Appel d’outil non autorisé | Filtrage par politique et rôle utilisateur | Outil demandé, paramètres, refus |
| Donnée sensible en sortie | Masquage ou caviardage automatique | Donnée détectée, transformation appliquée |
| Envoi externe risqué | Validation du destinataire et du contenu | Destinataire, contenu résumé, validation |
| Actions répétées ou coûteuses | Seuils, quotas, arrêt automatique | Volume, coût estimé, action bloquée |
Quand garder un humain dans la boucle ?
Il faut garder un humain dans la boucle dès que l’action est irréversible, externe, réglementée ou à fort impact business. C’est la borne simple que j’utilise avec mes clients, parce qu’elle évite les débats interminables sur “est-ce qu’on fait confiance à l’agent ou pas”. La vraie question, c’est plutôt : qu’est-ce qui se passe si l’agent se trompe ?
Un agent IA peut très bien classer, résumer, préparer, suggérer, préremplir. Là, on reste dans l’aide à la décision ou dans la préparation du travail. Le risque existe, mais il est rattrapable. Par contre, certaines actions doivent passer par une validation humaine.
- Supprimer des données.
- Envoyer un email externe sensible.
- Valider un paiement.
- Modifier un contrat.
- Traiter une donnée réglementée, comme une donnée de santé, RH ou financière.
- Déclencher une action qui impacte directement un client ou un salarié.
Ces limites sont aussi liées à la conformité. L’AI Act européen insiste sur la traçabilité, la gestion des risques, la supervision humaine et des obligations renforcées pour certains systèmes à haut risque. Je ne donne pas ici un conseil juridique, mais côté gouvernance, les entreprises ont vraiment intérêt à cartographier ce que l’agent peut faire seul, ce qu’il peut préparer, et ce qu’il ne doit jamais exécuter sans validation.
Cette cartographie doit suivre tout le cycle de vie de l’agent. À la création, on définit son rôle, ses accès, ses données et ses limites. Au passage en production, on valide les permissions réelles. Lors d’un changement de modèle, d’outil, de connecteur ou de périmètre, on revoit l’inventaire et les droits. Pendant les revues périodiques, on vérifie que l’agent sert encore à quelque chose et qu’il n’a pas dérivé. En cas d’incident, on coupe, on analyse, on corrige. À la retraite, on révoque les accès et on décommissionne son identité.
Le sujet n’est pas de ralentir les équipes, c’est d’éviter qu’un agent devenu critique tourne sans propriétaire clair.
| Action autonome | Action avec validation | Action interdite |
| Résumer un document interne. | Envoyer un email externe sensible. | Supprimer des données critiques sans approbation. |
| Classer des tickets support. | Valider un paiement ou une remise commerciale. | Modifier un contrat signé seul. |
| Préremplir un formulaire. | Traiter une donnée réglementée. | Contourner une règle métier ou conformité. |
Alors, on laisse vraiment les agents IA décider seuls ?
Je ne vois pas la gouvernance des agents IA comme une couche administrative. Je la vois comme le système nerveux de vos agents en production. Identité claire, accès minimum, secrets protégés, garde-fous runtime, logs rejouables, évaluations continues, propriétaire identifié, limites humaines nettes. C’est ça qui permet de passer du prototype sympa à un agent réellement exploitable dans le business. Le point clé, c’est d’agir avant que les agents se multiplient partout. Vous gagnez en sécurité, en traçabilité et en confiance, sans bloquer l’innovation.
FAQ
- Qu’est-ce que la gouvernance des agents IA ?
La gouvernance des agents IA, c’est l’ensemble des contrôles qui encadrent ce qu’un agent peut faire en production. Ça couvre son identité, ses accès, ses outils, ses données, ses décisions, ses logs, ses validations humaines et son propriétaire. - Pourquoi les agents IA sont-ils plus risqués qu’un chatbot classique ?
Un chatbot répond. Un agent agit. Il peut appeler des outils, lire des données, envoyer des messages, modifier des systèmes ou déclencher des workflows. Dès qu’il a des intégrations et des permissions, le risque devient opérationnel. - Quel est le premier contrôle à mettre en place ?
Le premier contrôle, c’est l’identité et le moindre privilège. Chaque action doit être traçable et limitée au périmètre nécessaire. Les comptes partagés très permissifs sont pratiques au début, mais dangereux en production. - À quoi servent les garde-fous runtime ?
Ils servent à bloquer une action au moment où elle se produit. Par exemple une injection de prompt, une sortie contenant des données sensibles, un appel d’outil non autorisé ou un envoi externe hors politique. - Quand faut-il demander une validation humaine ?
Il faut une validation humaine pour les actions irréversibles, les décisions à fort impact, les envois externes sensibles, les données réglementées et les opérations qui peuvent toucher un client, un salarié, un paiement ou un contrat.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé avec des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Si vous voulez cadrer vos agents IA, vos automatisations ou votre gouvernance data sans usine à gaz, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.