Comment définir les pouvoirs accordés à vos agents IA

Un agent peut avoir raison et malgré tout dépasser son autorité

Un agent en production peut calculer le bon remboursement et malgré tout prendre une mauvaise décision métier en accordant plus de crédit qu’il n’était autorisé à approuver. À mesure que les agents dépassent le stade des copilots orientés recommandation et commencent à appeler des outils et à activer des workflows, l’exactitude n’est plus un test suffisant pour la production, car la sortie du modèle peut devenir une action métier. L’entreprise doit aussi décider si une action sûre et techniquement valide est autorisée en son nom. La capacité technique et l’autorité métier sont deux propriétés distinctes.

Le commerce rend cette distinction concrète. Un agent de commande peut effectuer exactement la modification demandée par un client tout en invalidant une condition de financement. Une promesse de livraison peut correspondre au stock disponible tout en ignorant une restriction de transporteur appliquée une heure plus tôt. Dans chaque cas, l’agent peut raisonner correctement et suivre ses instructions comme prévu, et pourtant l’entreprise peut quand même se retrouver avec une action qu’elle n’a pas validée.

Ces exemples révèlent un mode de défaillance que les contrôles de contenu ne peuvent pas résoudre, car la question porte sur l’autorité organisationnelle. Les filtres peuvent restreindre les sorties dangereuses, mais ce sont les règles de l’organisation qui déterminent si l’agent peut émettre un remboursement, modifier une commande ou prendre un engagement externe. Comme l’action peut sembler techniquement réussie, l’agent peut continuer à fonctionner jusqu’à ce qu’un processus en aval révèle le problème. Un raisonnement correct n’établit pas qu’une action est autorisée.

En production, la question est de savoir comment empêcher un agent qui se comporte correctement d’exercer une autorité que l’entreprise ne lui a jamais déléguée. Cette question devient plus importante à mesure que l’accès aux outils transforme la sortie du modèle en action métier. Faire fonctionner la démo de l’agent est de plus en plus distinct de la tâche plus difficile qui consiste à définir quelles décisions l’agent est légitimement autorisé à prendre.

Les garde-fous, les contrôles d’accès et l’autorité déléguée résolvent des problèmes différents

Cette distinction ajoute une couche de contrôle à celles que les entreprises utilisent déjà. Les premiers contrôles de l’IA générative filtrent les contenus nuisibles, protègent les informations sensibles, valident les réponses et encadrent le comportement des outils. La sécurité des modèles, les contrôles de sortie et l’usage sécurisé des outils restent importants, car les agents doivent être protégés contre les comportements dangereux et l’utilisation inappropriée des outils. L’autorité déléguée traite la question opérationnelle distincte de savoir quelles décisions métier un agent peut prendre.

Le contrôle d’accès couvre une partie de cette décision, car il détermine si un agent peut atteindre un système ou une ressource. Une fois cette connexion autorisée, l’entreprise doit encore décider si une action particulière est légitime dans les circonstances où elle est demandée. L’accessibilité et l’autorité peuvent produire des réponses différentes pour le même outil. Une opération techniquement disponible peut malgré tout sortir du mandat délégué à l’agent.

Cette différence signifie qu’un agent en production a besoin de droits de décision explicites couvrant quatre questions de base : ce qu’il peut exécuter, ce qui nécessite une approbation, ce qu’il peut seulement recommander et ce à quoi il ne doit jamais toucher. Ces droits doivent préciser qui a délégué l’autorité, jusqu’où elle s’étend, quand elle s’applique et à qui revient la responsabilité du résultat en cas de problème. Les garde-fous classiques maintiennent le comportement dans des contraintes de sécurité, tandis que ces décisions métier établissent le mandat de l’agent.

Le mandat a aussi besoin d’une frontière d’application en dehors du system prompt. Dire à un agent en langage naturel qu’il ne doit jamais effectuer une opération particulière exprime une politique au modèle, mais l’outil concerné peut rester techniquement appelable. Une décision de refus doit être appliquée là où l’agent ne peut pas transformer sa confiance ou un raisonnement apparemment conforme en permission.

Ensemble, ces contrôles répondent à des questions voisines. Les contrôles d’accès régissent ce qui est accessible ; les garde-fous de sécurité encadrent le comportement ; l’autorisation détermine si l’entreprise a délégué la décision précise que l’on tente de prendre. Une approbation humaine peut fournir un contrôle supplémentaire, mais l’appliquer à chaque action crée un problème de passage à l’échelle. Un modèle d’autorité pour la production doit préserver ces contrôles tout en ajoutant une réponse applicable à la question de la délégation.

L’adoption des agents dépasse déjà la visibilité et la responsabilité

Le besoin de cette réponse apparaît alors même que les organisations découvrent encore où les agents opèrent. Une enquête de l’April 2026 Cloud Security Alliance menée auprès de 418 professionnels de l’IT et de la sécurité a révélé que 65 % des répondants avaient connu un incident lié à un agent d’IA au cours de l’année précédente. Elle a également montré que 82 % avaient découvert dans leurs environnements des agents dont ils n’avaient pas connaissance auparavant. Token Security a sponsorisé l’enquête, ce qui donne à une entreprise ayant un intérêt commercial dans la sécurité autour des déploiements d’agents une partie prenante sur le sujet.

Ces chiffres établissent le problème immédiat de visibilité et de responsabilité : les organisations rencontrent déjà des agents inconnus et des incidents liés aux agents tout en essayant d’établir qui connaît, possède et contrôle ces systèmes. Dans cet environnement, la délégation explicite compte davantage, car le déploiement technique peut précéder une responsabilité organisationnelle claire. L’autorité doit être définie sous une forme que l’infrastructure peut appliquer.

Définir l’autorité avant que l’agent n’obtienne l’accès aux outils de l’entreprise

Une fois qu’un agent peut transformer une décision en action d’entreprise, son mandat doit prendre une forme que l’infrastructure peut faire respecter. Un Agent Authority Contract fournit cette forme : un enregistrement exécutoire par machine de l’autorité que l’entreprise délègue délibérément à un agent en production. Il doit exister avant que l’accès aux outils de l’entreprise ne soit accordé, car accorder d’abord l’accessibilité laisse l’organisation tenter ensuite de déduire l’action légitime à partir des permissions techniques. Le contrat doit répondre à sept questions :

1. Qui est responsable du résultat ? Le responsable doit être une personne nommée ou un rôle métier, plutôt qu’un autre système.
2. Que l’agent peut-il faire ? Son mandat doit distinguer la lecture, la recommandation, l’écriture et l’engagement.
3. À quels systèmes et données peut-il accéder ? Le contrat doit établir les ressources pertinentes pour la tâche déléguée.
4. Quelles limites de matérialité s’appliquent ? La matérialité désigne le niveau de conséquence d’une action, et ses limites peuvent inclure des seuils monétaires, des volumes d’enregistrements, le périmètre client et l’impact opérationnel.
5. Qu’est-ce qui déclenche une escalade ? Les conditions pertinentes incluent l’incertitude, les anomalies, les données sensibles et l’impact potentiel.
6. L’action peut-elle être annulée, et qui a l’autorité pour l’annuler ? La réversibilité change les conséquences d’une exécution autonome.
7. Quand l’autorité expire-t-elle, et comment est-elle retirée ? La délégation a besoin d’une fin explicite et d’un mécanisme de révocation.

Ces questions transforment des affirmations générales telles que « l’agent gère le service client » en droits de décision pouvant être évalués. Prenons un workflow de service qui calcule le bon remboursement. Son raisonnement peut être entièrement solide, tandis que le contrat l’empêche malgré tout d’émettre un crédit au-delà de la limite autonome approuvée par l’entreprise. La limite de matérialité fournit la règle métier que la seule exactitude du modèle ne peut pas fournir.

La même structure résout des ambiguïtés moins évidentes. Un agent de commande peut effectuer correctement une modification demandée, et pourtant l’action devrait s’arrêter ou être escaladée lorsqu’une condition de financement ou d’exécution change ce que l’entreprise est prête à autoriser. Un agent d’approvisionnement peut identifier le fournisseur le moins cher, tandis que son contrat le limite à une recommandation parce que l’entreprise ne lui a jamais délégué l’autorité d’accepter des conditions contractuelles. Dans chaque cas, c’est le mandat attaché à l’action qui détermine jusqu’où l’agent peut aller.

Ce mandat établit aussi la responsabilité, car l’exécution autonome laisse à l’entreprise la responsabilité des résultats. Nommer une personne ou un rôle métier oblige l’entreprise à décider où cette responsabilité se situe avant qu’une défaillance ne survienne. L’expiration et le retrait suivent la même logique : l’autorité est déléguée pour des conditions définies et peut cesser lorsque ces conditions ne sont plus réunies.

Une fois ces éléments définis, l’Agent Authority Contract peut fonctionner aux côtés du contrôle d’accès. L’accès peut établir qu’un agent d’approvisionnement est techniquement capable d’atteindre un workflow fournisseur ; le contrat peut établir s’il peut consulter des informations, recommander un fournisseur, rédiger un projet de modification ou engager l’entreprise dans la situation actuelle. Cette précision transforme la délégation métier en règle que l’infrastructure environnante peut faire respecter.

L’autorisation a quatre issues

Un contrat devient opérationnel lorsque chaque action conséquente peut se résoudre en l’une de quatre issues d’autorisation : Allow, Approve, Recommend ou Deny. Un modèle binaire autorisé-ou-bloqué ne peut pas exprimer les cas où un agent peut apporter un travail utile tandis qu’une personne ou un service de politique déterministe conserve l’engagement final. Les quatre issues séparent la participation autorisée de l’agent de son autorité à finaliser la transaction.

« Allow » couvre les actions bornées, à faible risque et réversibles, qui peuvent s’exécuter de manière autonome. Un agent peut récupérer des informations approuvées, classer une demande entrante ou mettre à jour un champ sans conséquence matérielle. Comme le périmètre et l’impact potentiel sont limités et que l’annulation reste praticable, une revue humaine préalable apporte peu de valeur de contrôle.

« Approve » permet à l’agent de préparer ou d’initier une action tandis que l’exécution attend une autorisation d’une personne ou d’un service de politique déterministe. Les paiements et les changements de production relèvent de cette catégorie lorsque leurs conséquences exigent une étape d’autorisation indépendante. Le même traitement s’applique aux actions qui affectent matériellement un client, un employé ou un tiers, car préparer l’opération et recevoir l’autorité de l’exécuter sont deux décisions distinctes.

« Recommend » maintient une personne nommée comme décideur final. L’agent peut analyser des informations, classer des options, rédiger des éléments ou proposer une action, ce qui permet à l’automatisation de réduire le travail nécessaire pour parvenir à une décision. Cette issue convient aux cas où le jugement contextuel reste important ou lorsque les conséquences juridiques, financières ou individuelles rendent l’exécution automatique inacceptable.

« Deny » place une action hors de l’autorité déléguée, indépendamment du niveau de confiance du modèle. Supprimer des données critiques de production, prendre une décision finale en matière d’emploi et contourner un contrôle obligatoire de conformité sont des exemples d’opérations qui peuvent rester interdites même lorsqu’un agent a produit un raisonnement apparemment correct. L’application technique de cette limite doit se situer en dehors du system prompt afin que l’exécution ne dépende pas du respect par le modèle d’une interdiction formulée en langage naturel.

Le playbook de mai 2026 du World Economic Forum décrit une séparation connexe à travers son Agent Capability and Authorization Profile, conçu pour que les actions déléguées soient auditables, applicables et assorties d’une responsabilité claire. Dans ce profil, la capacité technique est une entrée de la gouvernance, tandis que l’autorisation précise quelle capacité a été déléguée et sous quelle supervision. Cette distinction devient particulièrement importante lorsque l’issue d’autorisation appropriée change selon le contexte métier.

L’autorité doit être décidée dans le contexte, au moment de l’exécution

Les quatre issues peuvent changer même lorsque l’action demandée reste la même, car le risque change avec le contexte. Un petit avoir de service peut normalement recevoir Allow, puis nécessiter Approve lorsque son montant dépasse un seuil. Une enquête sur un compte ou un statut de client réglementé peut produire le même changement même si l’opération demandée reste identique. L’autorisation au moment de l’exécution traite ces cas en évaluant l’autorité lorsque l’agent propose l’action. La séquence est la suivante :

1. L’agent propose une action.
2. Une couche de politique évalue l’identité de l’agent, le principal délégué, l’outil demandé, les données concernées, le contexte de la transaction et l’impact potentiel.
3. La politique renvoie Allow, Approve, Recommend ou Deny.
4. Le système enregistre la décision d’autorité, l’action qui en résulte et le résultat.
5. La télémétrie opérationnelle est ensuite utilisée au fil du temps pour élargir, restreindre ou révoquer l’autorité de l’agent.

Dans cette évaluation, le principal délégué identifie la personne ou la fonction métier dont l’agent exerce l’autorité. Combiné à l’identité de l’agent et à l’outil demandé, il indique à la couche de politique qui agit, de quel mandat l’agent se sert et quelle opération technique il veut invoquer. Les données et le contexte de transaction ajoutent les faits susceptibles de changer si cette opération est légitime à cet instant.

Ces faits changeants rendent l’autorisation contextuelle. Le montant, le statut du client, l’état de l’enquête, la réversibilité et l’impact potentiel peuvent chacun faire passer une demande par ailleurs identique d’une issue à une autre parmi les quatre. Un agent peut conserver un accès continu à un système tout en recevant des décisions d’autorisation différentes à mesure que les circonstances métier évoluent.

Les défaillances commerciales évoquées plus haut montrent pourquoi cette évaluation doit avoir lieu au plus près de l’exécution : un remboursement exact, une modification de commande demandée ou une promesse de livraison fondée sur le stock peut dépasser une limite d’approbation, invalider une condition de financement ou rencontrer une contrainte de transporteur introduite une heure plus tôt. C’est le contexte opérationnel le plus récent qui détermine si un raisonnement techniquement correct peut légitimement devenir une action. La politique d’exécution est le point où ces faits actuels peuvent influer sur l’exécution.

Comme la politique d’exécution prend une décision pour chaque action conséquente, le système peut enregistrer à la fois la décision d’autorité et ce qui s’est passé ensuite. L’entreprise peut alors voir quel contexte a produit une issue d’autorisation, ce que l’agent a fait ensuite et quel résultat métier a suivi. Ces enregistrements fournissent la télémétrie nécessaire pour faire évoluer l’autorité à mesure que les preuves opérationnelles s’accumulent, plutôt que de traiter la première configuration de politique comme permanente.

L’approbation humaine doit être proportionnelle au risque

Le risque contextuel peut inciter une entreprise à placer une personne devant chaque action d’agent, mais le volume de revue peut affaiblir le contrôle qu’il est censé fournir. Lorsque des évaluateurs approuvent des milliers d’opérations de routine, l’attention baisse et les véritables exceptions deviennent plus difficiles à distinguer. À cette échelle, l’autorisation humaine peut se dégrader en simple validation automatique.

La version mise à jour du Model AI Governance Framework for Agentic AI de Singapour traite les contrôles d’accès, les garde-fous comportementaux et les approbations humaines comme des contrôles distincts. Elle relie la supervision à la portée d’une action, au fait que l’action puisse être annulée ou non, et à son impact potentiel. Le framework reconnaît également qu’une supervision humaine continue de chaque workflow d’agent devient impraticable à grande échelle et appelle à des points de contrôle significatifs autour des actions à risque élevé ou irréversibles.

Cette approche conduit à une autorisation proportionnée. Les actions étroitement bornées et à faible risque peuvent s’exécuter de manière autonome, tandis que les actions à haut risque ou irréversibles exigent une approbation. Un comportement inattendu déclenche une escalade, et une action conséquente sans politique d’autorisation définie est refusée par défaut. L’attention humaine peut alors se concentrer là où le jugement modifie l’issue du risque.

La proportionnalité change aussi la cible de l’autonomie des agents. L’objectif utile est le niveau d’autonomie le plus élevé qu’une entreprise peut observer, gouverner et inverser de manière responsable. La réversibilité compte, car une opération récupérable crée une exposition différente d’une opération irréversible, tandis que l’impact potentiel détermine le niveau de revue indépendante que l’entreprise doit exiger avant l’exécution. Ces facteurs fournissent aussi des signaux concrets pour décider si l’autorité d’un agent doit ensuite être élargie ou réduite.

Traitez l’autorité déléguée comme une variable que vous pouvez étendre ou révoquer

Une fois l’agent en fonctionnement, l’exactitude des réponses est trop limitée pour montrer si son autorité est correctement calibrée. Un système peut produire des réponses exactes tout en escaladant trop souvent, en franchissant les limites déléguées ou en causant des dommages par des actions qu’il était techniquement autorisé à effectuer. La mesure en production doit saisir la manière dont la délégation elle-même fonctionne. Cinq mesures fournissent des signaux directs :

• Le taux d’annulation mesure la fréquence à laquelle des humains rejettent ou modifient matériellement les décisions de l’agent.
• La précision des escalades mesure si l’escalade identifie de véritables cas à risque au lieu de renvoyer systématiquement un travail ordinaire aux humains.
• Les tentatives d’action non autorisée mesurent la fréquence à laquelle un agent essaie d’aller au-delà des limites autorisées de système, de données ou d’action.
• Le taux d’erreurs ayant un impact métier mesure la fréquence à laquelle des actions autorisées causent un préjudice financier, de conformité, opérationnel ou client.
• La latence de décision mesure si les exigences d’approbation réduisent le risque ou retardent simplement une automatisation qui était déjà sûre.

Ensemble, ces mesures transforment l’autorité en variable opérationnelle gouvernable. Une performance constamment fiable peut justifier une extension contrôlée d’une autorité bornée, car l’entreprise dispose de preuves sur les résultats dans le cadre du mandat existant. Des annulations fréquentes, des escalades défaillantes ou des violations de politique pointent dans la direction opposée et devraient restreindre ou révoquer l’autorité déléguée.

Cette boucle de rétroaction change ce que signifie le « déploiement » pour un agent. Le contrat initial Agent Authority Contract définit le mandat autorisé, la politique d’exécution applique ce mandat aux conditions du moment, et les preuves d’exploitation déterminent si le mandat doit évoluer. L’autorité reste révocable, car les conditions de production, le comportement de l’agent et la tolérance de l’entreprise aux conséquences peuvent tous changer après le lancement.

Réflexions finales

À mesure que les agents d’IA accèdent aux systèmes de l’entreprise, la question de gouvernance passe de ce qu’ils peuvent faire à ce que l’entreprise les a autorisés à faire. Cette distinction relève du niveau exécutif, car l’autorité déléguée détermine qui peut engager les ressources de l’entreprise, affecter les clients, modifier les opérations et accepter le risque au nom de l’organisation.

L’objectif pratique n’est pas l’autonomie maximale. C’est une autonomie contrôlée avec une responsabilité explicite, des limites applicables, une approbation proportionnée et une voie claire de révocation. Les dirigeants devraient exiger ces conditions avant d’accorder un accès conséquent aux outils, puis utiliser les preuves de production pour décider si l’autorité d’un agent doit être élargie ou réduite.

Les organisations qui établissent tôt ces limites peuvent accroître l’autonomie sans traiter la confiance comme une décision ponctuelle. L’autorité de l’agent devient quelque chose que l’entreprise accorde délibérément, observe et ajuste à mesure que les conditions métier et les preuves opérationnelles évoluent.