Gouvernance des agents IA : qui est responsable quand l’IA peut agir ?

Les capacités progressent plus vite que les garde-fous

Dans une enquête Deloitte publiée le 24 avril 2026 auprès de 3 235 responsables IT et métier de 24 pays, 21 % seulement déclarent que leur organisation dispose d’un modèle de gouvernance mature pour l’IA agentique.

Le même échantillon anticipe pourtant une généralisation rapide : d’ici 2027, 74 % des répondants s’attendent à ce que leur entreprise utilise des agents IA au moins de façon modérée. L’écart entre ces deux chiffres résume la situation. Le déploiement est engagé, la gouvernance suit avec plusieurs trimestres de retard.

Deloitte précise ce que recouvre cette immaturité. Près de 80 % des organisations interrogées ne disposent pas encore de capacités de gouvernance matures pour l’IA agentique, à commencer par trois d’entre elles : des frontières explicites entre les décisions qu’un agent peut prendre seul et celles qui exigent une approbation humaine, une supervision en temps réel capable de signaler un comportement anormal, et une piste d’audit reconstituant la chaîne complète de ses actions. Ce sont trois questions de gouvernance avant d’être trois sujets techniques.

Cette exigence tient à une différence simple. Un assistant conversationnel qui se trompe produit une mauvaise réponse, qu’un humain lit avant d’en faire quelque chose. Un agent connecté à des outils qui se trompe exécute une action sur un système réel : il modifie un enregistrement, envoie un message, déclenche un remboursement. La sortie du modèle cesse d’être une proposition pour devenir un effet.

Gouverner le modèle ne suffit plus

Tant que l’IA se limitait à produire du texte, la gouvernance pouvait se concentrer sur le modèle : lequel, entraîné comment, pour quels usages, avec quelles données. Un système agentique déplace la question, parce qu’une action y résulte d’une chaîne et non d’un composant isolé.

Cette chaîne se lit dans l’ordre où elle s’exécute. Un modèle interprète une demande, il consulte des données auxquelles on lui a ouvert l’accès, il choisit un outil parmi ceux qu’on lui a exposés, puis il déclenche l’action avec une identité technique qui porte des droits. Chaque maillon est un point de décision distinct, et gouverner l’un ne gouverne pas les autres : restreindre le modèle ne restreint pas ses outils, et restreindre ses outils ne restreint pas les droits de l’identité sous laquelle il agit.

Trois maillons s’ajoutent en aval, qui ne relèvent plus de la conception mais de l’exploitation : le seuil à partir duquel une opération exige une validation humaine, la supervision qui permet de repérer un comportement anormal, et la responsabilité, c’est-à-dire le nom de la personne qui répond des actions du système. Les quatre premiers définissent ce que l’agent peut faire, les trois derniers déterminent ce qui se passe lorsqu’il le fait mal.

Le NIST structure sa démarche de gestion du risque IA selon une logique voisine, autour de quatre fonctions. Map situe le système et ses risques dans son contexte d’usage, Measure les évalue et les instrumente, Manage les traite et les priorise. Govern n’est pas une quatrième étape mais la fonction transverse : les rôles, les politiques et les pratiques qui font tenir les trois autres dans la durée. C’est elle qui manque le plus souvent, y compris dans les organisations qui ont produit une charte IA : un document décrit des principes, il ne désigne pas qui tranche.

1. Décider du périmètre d’action avant de décider de l’architecture

Le principe du moindre privilège est un principe de sécurité connu : n’accorder que les droits nécessaires à la tâche, pour la durée nécessaire. Ce qui relève de la gouvernance, c’est de savoir qui l’applique et à quel moment. Dans la plupart des projets, le périmètre d’accès d’un agent est fixé pendant le développement, par la personne qui a besoin que le prototype fonctionne. Un accès large fait gagner quelques jours, et il est rarement repris ensuite.

L’inversion consiste à faire du périmètre une décision métier prise avant l’implémentation, puis écrite. Un agent chargé de renseigner un client sur l’état de sa commande a besoin de la lire. Il n’a probablement pas besoin de la modifier, encore moins de la supprimer. Formuler cette limite en amont oblige à distinguer ce que l’agent doit faire de ce qu’il pourrait faire, et rend l’écart visible au moment de la revue.

La traduction technique de ce principe, identités dédiées, portées d’API restreintes, audit des permissions réellement effectives, constitue un sujet à part entière que nous détaillons dans notre décryptage sur la sécurité des agents IA. Retenons ici la règle de gouvernance : une permission que personne n’a explicitement accordée a été accordée par défaut.

2. Calibrer l’autonomie par action, pas par agent

Classer un agent comme autonome ou supervisé est une simplification coûteuse, parce que le risque ne se situe pas au niveau de l’agent mais de chacune de ses actions. Le même agent de support peut consulter un historique de commandes des centaines de fois par jour sans qu’aucune supervision se justifie, et déclencher un remboursement de 2 000 € qui, lui, mérite une validation. Fixer un niveau d’autonomie une fois pour toutes conduit soit à brider l’usage courant, soit à laisser passer l’exception.

La règle utile porte donc sur les opérations. Pour chaque action qu’un outil expose, l’organisation décide si elle s’exécute automatiquement, si elle s’exécute en laissant une trace effectivement supervisée, ou si elle exige une validation préalable. Ce découpage a un effet secondaire précieux : il oblige à inventorier ce que les outils permettent réellement, ce qui dépasse souvent ce que l’équipe croit avoir exposé.

Reste à calibrer le seuil, et l’erreur symétrique existe. Une validation demandée trop souvent finit par être accordée sans examen. Le législateur européen a nommé ce phénomène le biais d’automatisation, en imposant que les personnes chargées du contrôle humain d’un système à haut risque restent conscientes de leur tendance à se fier automatiquement aux sorties de ce système. Une chaîne de validation qui produit un accord réflexe ne protège de rien : elle déplace seulement la responsabilité vers un humain qui n’a pas réellement décidé.

3. Rendre chaque action attribuable

Une action déclenchée par un agent n’est gouvernable qu’à condition de pouvoir la rattacher, après coup, à tout ce qui l’a produite : l’identité qui l’a exécutée, la demande initiale qui l’a déclenchée, l’exécution dans laquelle elle s’inscrit, l’outil appelé et ses paramètres, le résultat renvoyé et, le cas échéant, la validation humaine qui l’a autorisée.

Ces éléments n’ont d’intérêt que reliés entre eux. Un journal d’appels d’API sans identifiant d’exécution ne permet pas de reconstituer un enchaînement. Une trace d’exécution sans identité d’agent ne permet pas de distinguer l’action réalisée pour le compte d’un utilisateur de l’initiative propre de l’agent. C’est cette continuité qui transforme des journaux en piste d’audit, et c’est elle que Deloitte trouve manquante dans la grande majorité des organisations.

Sans elle, la responsabilité se dilue mécaniquement, puisque personne ne peut démontrer ce qui s’est passé et que personne ne peut donc en répondre. La façon d’instrumenter cette continuité relève de l’observabilité agentique.

4. Construire l’échelle d’arrêt avant l’incident

« Comment arrête-t-on ce système ? » est la question qu’une équipe ne devrait jamais découvrir pendant un incident. Il n’existe pas un bouton d’arrêt unique, mais une échelle de mesures dont chacune coupe une portée différente. Le choix se fait dans l’urgence, ce qui suppose que l’échelle, elle, ait été construite à froid.

Le premier degré consiste à désactiver un outil. L’agent continue de fonctionner, mais l’action problématique disparaît de ce qu’il peut appeler : c’est la mesure la plus fine, et la seule qui n’interrompe pas le service. Le deuxième consiste à révoquer un jeton ou une clé. On ne retire plus une capacité, on retire un accès, ce qui coupe d’un seul geste toutes les actions qui passaient par lui, y compris celles qu’on n’avait pas identifiées comme risquées. Le troisième suspend l’agent lui-même, lorsque le problème vient de son comportement plutôt que d’un outil particulier.

Deux mesures complètent l’échelle par le haut. La bascule vers une validation humaine systématique ne coupe rien : elle retransforme chaque exécution en proposition, ce qui permet de continuer à rendre le service pendant l’investigation, au prix d’une charge humaine qui n’est tenable que temporairement. L’arrêt complet du workflow s’impose quand le doute porte sur la chaîne entière et non sur l’un de ses maillons. Ces cinq degrés ne sont pas interchangeables : plus on monte, plus on est certain de couper le problème, et plus on coupe aussi ce qui fonctionnait.

Le règlement européen sur l’IA formule une exigence voisine pour les systèmes à haut risque. Les personnes chargées du contrôle humain doivent pouvoir intervenir sur le fonctionnement du système ou l’interrompre au moyen d’un bouton d’arrêt ou d’une procédure équivalente, permettant au système de s’arrêter dans un état sûr. La précision compte : interrompre un agent au milieu d’une séquence peut laisser un état incohérent, un débit sans le crédit correspondant, un dossier à moitié traité. Un mécanisme d’arrêt se conçoit donc avec la question de ce qu’il laisse derrière lui.

Deux nuances évitent le contresens. Cette obligation ne vise que les systèmes qualifiés à haut risque au sens du règlement, ce que la plupart des agents déployés en entreprise ne sont pas. Et son calendrier a bougé : le règlement (UE) 2026/1744, dit Digital Omnibus on AI, entré en vigueur le 27 juillet 2026, a reporté au 2 décembre 2027 l’application des obligations relatives aux systèmes à haut risque de l’annexe III, initialement prévue au 2 août 2026. Le report porte sur l’échéance, pas sur le raisonnement : un mécanisme d’arrêt qui n’a jamais été déclenché en conditions réelles reste une hypothèse, que la réglementation l’exige ou non.

5. Interdire techniquement l’accès aux systèmes réels pendant les tests

Un agent est évalué avant d’être déployé, puis réévalué à chaque modification de ses prompts, de ses outils ou de son modèle. Ces exécutions de test appellent de vrais outils. Si l’environnement n’est pas séparé, elles appellent aussi de vrais systèmes, et un jeu d’évaluations qui envoie réellement les courriels qu’il était censé simuler devient un incident de production causé par une démarche qualité.

La séparation doit être une frontière technique, pas une consigne. Un prompt qui demande à l’agent de ne rien écrire en production n’est pas un contrôle d’accès : c’est une instruction, qu’une ambiguïté ou une injection dissimulée dans une source externe peut faire dévier. La règle de gouvernance est donc formulée comme une preuve à produire : on doit pouvoir démontrer, en inspectant les identifiants et les points de terminaison configurés dans l’environnement de test, qu’aucun chemin ne mène au système réel.

Cette exigence conditionne la valeur des évaluations elles-mêmes. Une équipe qui redoute les effets de bord finit par tester moins souvent, ou par ne tester que des cas assez inoffensifs pour ne rien démontrer.

6. Réviser l’autonomie, pas seulement les permissions

Un agent en production ne reste pas celui qui a été approuvé. On lui ajoute un outil, on branche une nouvelle source de données, on met à jour son modèle, on élargit le périmètre de ses utilisateurs. Chacun de ces gestes est mineur pris isolément, mais leur accumulation redéfinit ce que le système peut faire sans qu’aucune décision explicite n’ait été prise sur ce point.

Une revue fixée au calendrier attrape mal ce phénomène, parce que le risque n’augmente pas avec le temps mais avec les changements. Le déclencheur le plus fiable est donc le changement lui-même : tout ajout d’outil, toute nouvelle source de données et tout changement de modèle rouvrent la question du périmètre. La revue calendaire garde son utilité pour ce que les changements ne signalent jamais, c’est-à-dire les permissions accordées pour une tâche qui n’existe plus.

Cette révision fonctionne dans les deux sens, et c’est ce qui la rend acceptable par les équipes. Un agent dont on a mesuré pendant six mois qu’il ne se trompe pas sur une catégorie d’opérations peut légitimement voir sa validation humaine levée sur cette catégorie précise. Une gouvernance qui ne sait que restreindre finit contournée. Une gouvernance qui définit aussi comment l’autonomie s’acquiert est appliquée.

7. Nommer les personnes qui répondent du système

La responsabilité ne se transfère pas à l’agent. Elle reste à l’organisation qui l’a déployé et se répartit entre des personnes nommées : celle qui décide du niveau d’autonomie, celle qui répond de son implémentation, celle qui autorise l’accès aux données, et celle qu’on appelle lorsqu’il faut arrêter le système.

« L’IA a décidé » n’est pas une chaîne de responsabilité. Trois rôles suffisent le plus souvent à la reconstituer, à condition qu’ils portent des noms de personnes et pas des noms de directions. Le responsable métier possède le cas d’usage et arbitre le niveau d’autonomie : c’est celui qui bénéficie de l’automatisation, donc celui qui doit en assumer le risque. Le responsable technique répond de l’implémentation, des permissions effectives et de la capacité réelle à arrêter le système. Le propriétaire des données autorise le périmètre d’accès, un rôle souvent escamoté alors qu’un agent hérite fréquemment de données dont le propriétaire n’a jamais été consulté. Une fonction risque ou conformité s’ajoute aux trois lorsque le domaine est réglementé.

Un dernier élément n’est pas un rôle mais un chemin : la procédure d’escalade. Elle ne vaut que si elle désigne des personnes joignables et précise les plages horaires couvertes. Une adresse générique surveillée en heures ouvrées ne constitue pas une procédure d’escalade pour un système qui agit la nuit.

Le règlement européen sur l’IA raisonne de la même manière lorsqu’il distingue le fournisseur du système et son déployeur, et qu’il impose à ce dernier de confier le contrôle humain à des personnes physiques disposant de la compétence, de la formation, de l’autorité et du soutien nécessaires. L’autorité est le terme décisif : une personne qui ne peut pas arrêter le système ne le supervise pas, elle l’observe. Le NIST pousse le raisonnement dans la durée en plaçant la gestion du risque sur l’ensemble du cycle de vie du système plutôt que sur une vérification ponctuelle avant déploiement.

Une matrice d’autonomie pour arbitrer

Ces règles laissent une décision ouverte : à partir de quel niveau d’impact une action cesse-t-elle d’être automatique ? Aucun barème universel ne répond à cette question. Une matrice simple, adossée à l’impact potentiel d’une action plutôt qu’à sa fréquence ou à sa difficulté technique, suffit en revanche à rendre l’arbitrage explicite et discutable.

Sa valeur ne tient pas au classement qu’elle produit, mais à la discussion qu’elle impose. Positionner une action dans ce tableau oblige à formuler à voix haute pourquoi l’organisation accepte de laisser cet agent agir seul, et ce qu’elle est prête à assumer s’il se trompe. Lorsque la réponse est « parce que c’était plus simple à implémenter », le niveau d’autonomie n’a pas été gouverné.

À retenir

Gouverner des agents IA ne consiste pas à empêcher l’autonomie, mais à la rendre décidée : savoir où elle commence, où elle s’arrête, qui l’a accordée et comment on la reprend. Deloitte observe d’ailleurs que les organisations qui réussissent avec l’IA agentique procèdent par étapes : elles commencent par des cas d’usage à faible risque, construisent leurs capacités de gouvernance, puis passent à l’échelle délibérément, en s’appuyant sur des instances qui réunissent l’IT, le juridique, la conformité et les métiers.

À mesure que les agents obtiennent davantage d’accès aux systèmes d’entreprise, cette question pèse autant que le choix du modèle, et souvent davantage : on change de modèle en quelques semaines, on ne reconstruit pas une chaîne de responsabilité aussi vite.