Un agent qui tourne en démonstration et un agent qui tourne en production sont deux objets différents. Entre les deux se trouve la gouvernance des agents IA : un périmètre d’accès validé, un journal d’actions, un seuil d’escalade, un plafond de coût. Chez les grands comptes, 40 % des répondants déclarent passer leurs agents IA à l’échelle, contre 27 % un an plus tôt. Six sur dix restent donc bloqués au pilote. Cet article décrit ce qui doit exister avant la mise en production, et pourquoi le blocage est rarement technique.

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

La gouvernance des agents IA définit ce qu’un agent a le droit de faire, jusqu’où il va sans validation humaine, et ce qui se passe quand il se trompe. Elle se décide avant la mise en production, pas après le premier incident.

La distinction avec la gouvernance de l’IA en général tient en un mot : l’action. Un modèle génératif produit un texte que quelqu’un relit avant de s’en servir. Un agent, lui, exécute. La CNIL et le Conseil de l’IA et du Numérique décrivent, dans leur note exploratoire du 20 juillet 2026, une technologie « désormais capable d’agir sur son environnement à la place de son utilisateur ». C’est cette délégation qui change la nature du contrôle à mettre en place.

Gouverner un modèle, c’est encadrer une production. Gouverner un agent IA, c’est encadrer une capacité d’agir dans vos systèmes.

Pourquoi un agent qui marche en pilote ne passe-t-il pas en production ?

Parce que le pilote ne pose aucune des questions qui bloquent la production : qui valide l’accès aux données, que fait l’agent quand une étape échoue, combien coûte une exécution. Le pilote démontre la faisabilité, pas l’exploitabilité.

Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, et attribue ces abandons à trois causes : des coûts qui dérapent, une valeur métier mal établie, des contrôles de risque insuffisants. Aucune des trois n’est un problème de modèle.

Le schéma est régulier. Une équipe construit un agent qui fonctionne, le présente, obtient un accord de principe. Puis la direction des risques découvre l’étendue des accès demandés, personne ne sait dire ce que l’agent a fait la semaine précédente, et le coût par exécution n’a jamais été calculé. Le projet ne s’arrête pas parce qu’il a échoué. Il s’arrête parce que personne ne peut signer.

Que faut-il avoir en place avant la mise en production ?

Cinq garde-fous, tous décidés avant le go-live : le périmètre d’accès, le journal d’actions, le seuil d’escalade, le plafond de coût et la condition de sortie. Chacun répond à une question que quelqu’un posera de toute façon, et la seule variable est de savoir si vous y répondez tôt ou sous pression.

Le périmètre d’accès énumère les données et les systèmes que l’agent peut lire, et ceux dans lesquels il peut écrire. Sans lui, la revue de sécurité découvre l’étendue réelle des accès demandés trois semaines avant le lancement, à un moment où la seule décision rapide possible est de reporter.

Le journal d’actions enregistre ce que l’agent a fait, quand, et avec quelles données. Sans lui, aucun incident n’est reconstituable après coup : vous savez qu’un enregistrement est faux, vous ne savez pas quelle exécution l’a produit ni combien d’autres ont suivi le même chemin.

Le seuil d’escalade fixe le nombre d’échecs, ou le type d’action, qui rend la main à un humain. Sans lui, l’agent réessaie au lieu de s’arrêter, et le comportement par défaut d’une boucle qui échoue est de consommer du budget en répétant la même erreur.

Le plafond de coût fixe la dépense maximale par exécution et par mois. Sans lui, la consommation se découvre sur la facture, avec un mois de retard sur le moment où elle aurait pu être corrigée.

La condition de sortie définit ce qui met fin à une exécution : un résultat obtenu, une erreur, un nombre maximal d’étapes. Sans elle, il n’existe aucune garantie qu’une exécution se termine, et c’est le seul des cinq garde-fous dont l’absence est un défaut de conception plutôt qu’un défaut de gouvernance.

Quel garde-fou retarde réellement le go-live ?

Le périmètre d’accès et le seuil d’escalade. Ce sont les deux seuls des cinq dont la décision se situe hors de l’équipe projet, et ce sont ceux sur lesquels les mises en production s’arrêtent.

Les trois autres se paramètrent par l’équipe qui a construit l’agent : le journal d’actions, le plafond de coût et la condition de sortie sont des décisions d’ingénierie, prises par des gens déjà dans la pièce. Le périmètre d’accès, non : il relève d’une DSI ou d’un responsable de la sécurité qui n’a jamais vu le pilote. Le seuil d’escalade non plus : il relève d’un métier qui devra assumer les reprises en main. Le calendrier réaliste d’un go-live n’est donc pas celui du développement, c’est celui de ces deux validations.

Et le premier des deux n’est pas un problème technique, c’est un tri. Chez Club Med, le programme a fait émerger 102 agents identifiés avec 50 ambassadeurs formés en deux jours. Dix-huit ont été retenus comme quick wins prêts à déployer, 57 documentés comme projets structurels. Le travail qui compte n’est pas d’avoir trouvé 102 idées, c’est d’en avoir écarté 84 pour l’instant. Un portefeuille de 102 agents ne se gouverne pas, parce qu’aucune direction de la sécurité ne validera 102 périmètres d’accès ; un portefeuille de 18 se gouverne.

Comment garder le contrôle sans supprimer l’autonomie de l’agent ?

En superposant plusieurs contrôles spécialisés plutôt qu’un seul général, et en définissant à l’avance ce qui déclenche une reprise en main humaine. Un agent sans seuil d’escalade n’est pas autonome, il est simplement non surveillé.

OpenAI décrit ces protections comme un empilement : « un seul garde-fou a peu de chances d’offrir une protection suffisante ; en combiner plusieurs, spécialisés, rend les agents plus résistants ». Le guide liste des filtres de pertinence, de sécurité, de données personnelles, une modération, des protections par règles, des garde-fous sur les outils et une validation des sorties.

Sur l’intervention humaine, deux déclencheurs sont nommés explicitement. Le premier est le dépassement d’un seuil d’échecs : « fixez des limites au nombre de tentatives ou d’actions de l’agent ». Le second concerne les actions à fort enjeu, « sensibles, irréversibles ou à forte portée », qui doivent rester sous contrôle humain tant que la fiabilité n’est pas établie. Ces deux règles se paramètrent en une réunion. Elles sont pourtant absentes de la plupart des pilotes.

Comment savoir si la gouvernance fonctionne ?

En la mesurant comme le reste : taux d’escalade, coût moyen par exécution, délai de validation des accès, part des actions journalisées. Une gouvernance qui ne produit aucun chiffre ne se distingue pas d’une gouvernance absente.

Les organisations les plus avancées se distinguent précisément là. McKinsey observe qu’elles sont nettement plus susceptibles que les autres de travailler à limiter les actions non autorisées ou non intentionnelles de leurs systèmes. La même enquête, menée auprès de 1 719 répondants dans 97 pays et publiée le 25 août 2026, montre que près des trois quarts des plus performants ont fondamentalement repensé leurs processus, contre 55 % l’an dernier, et que 37 % des répondants attribuent un impact sur l’EBIT à leur usage de l’IA.

Un seuil d’escalade sans mesure du taux d’escalade est une intention. Avec la mesure, c’est un réglage.

Par où commencer ?

Par l’inventaire et le tri, pas par l’outillage. Recensez les agents existants et les projets en cours, classez-les selon la sensibilité des accès qu’ils demandent, et n’écrivez de règles détaillées que pour ceux qui iront en production.

C’est ce que nous cadrons pendant l’audit et la feuille de route, sur quatre à six semaines, avant le premier agent. Les garde-fous sont ensuite intégrés au moment de la construction plutôt qu’ajoutés après, ce qui est la seule façon tenable de mettre des agents en production. Et parce qu’un seuil d’escalade mal compris par les équipes métier ne sera jamais respecté, la montée en compétences fait partie du dispositif, pas de l’habillage : c’est l’objet de nos programmes de formation.

Questions fréquentes sur la gouvernance des agents IA

La gouvernance ralentit-elle la mise en production ?
Elle déplace le délai plutôt qu’elle ne l’allonge. Le temps passé à faire valider un périmètre d’accès en amont est celui que vous ne passerez pas à arbitrer en urgence trois semaines avant le lancement.

Faut-il créer un comité IA dédié ?
Pas au départ. Un porteur nommé par agent, un périmètre d’accès écrit et un point de revue mensuel suffisent tant que le portefeuille reste sous une vingtaine d’agents.

La gouvernance des agents IA diffère-t-elle de la gouvernance de l’IA en général ?
Oui, sur un point décisif : l’agent agit dans vos systèmes au lieu de produire un contenu que vous relisez. Les questions d’accès, de journalisation et d’escalade n’ont pas d’équivalent dans la gouvernance d’un modèle génératif.

Un agent IA d’entreprise relève-t-il du haut risque au sens de l’AI Act ?
Rarement, mais cela dépend de l’usage, pas de la technologie. Un agent qui intervient dans le recrutement, le crédit ou l’accès à un service essentiel a beaucoup plus de chances d’être concerné qu’un agent de rapprochement de données.

Vous voulez savoir lesquels de vos agents peuvent partir en production, et ce qui manque aux autres ? Prenez 30 minutes avec nous : nous passons en revue votre portefeuille et ses garde-fous, sans préparation de votre côté.