Pourquoi les entreprises doivent désormais gouverner l’autorité de leurs agents, et pas seulement leur autonomie

Imaginez une entreprise qui autorise un agent commercial à consulter le CRM, identifier les clients à risque, proposer une remise et envoyer des emails. Chaque permission paraît raisonnable.

Puis l’agent obtient la possibilité de modifier certaines conditions commerciales dans l’ERP. À quel moment l’entreprise a-t-elle décidé que cet agent pouvait modifier les conditions économiques d’une relation client ?

Peut-être jamais.

Pourtant, techniquement, elle vient de lui en donner la possibilité. C’est précisément le problème. Une organisation peut déléguer à un agent un pouvoir d’action sans avoir explicitement décidé de lui confier l’autorité correspondante. Celle-ci peut émerger progressivement de l’accumulation des accès, des outils et des permissions techniques.

L’autorité d’un agent devrait être une décision explicite de l’organisation, et non la conséquence implicite de son architecture technique.

Après avoir appris à gouverner les modèles, les données et les usages, les entreprises doivent désormais gouverner quelque chose de plus sensible : le pouvoir d’agir en leur nom.

Capacité, permission, autonomie et autorité ne sont pas synonymes Quatre notions doivent être distinguées.

  • La capacité décrit ce qu’un agent sait techniquement accomplir.
  • La permission correspond à ce que les systèmes informatiques lui permettent concrètement de faire.
  • L’autonomie mesure dans quelle mesure il peut accomplir ces actions sans solliciter une intervention humaine.
  • L’autorité, enfin, désigne le pouvoir que l’organisation décide de lui reconnaître pour prendre une décision ou agir en son nom.

Ces dimensions sont liées, mais elles ne sont pas équivalentes.

Un agent peut être techniquement capable d’effectuer un paiement. Une API peut lui permettre de le déclencher. Il peut même être suffisamment autonome pour exécuter l’opération sans assistance humaine. Cela ne signifie pas que l’organisation a décidé de lui déléguer le droit d’engager cette dépense.

Cette distinction commence à apparaître dans les travaux scientifiques récents. En juillet 2026, Haining Zheng et ses coauteurs ont proposé de différencier les Autonomous Capability Levels, qui décrivent les capacités techniques d’un agent, et les Allowed Autonomy Levels, qui déterminent le niveau d’autonomie effectivement autorisé compte tenu du risque, de la supervision et de la capacité à rendre compte. Un système peut donc être très capable tout en restant volontairement limité dans ce qu’il est autorisé à accomplir.

Cette recherche ne définit pas exactement l’autorité organisationnelle telle que je l’entends ici. Elle permet néanmoins de poser un principe essentiel :

Capacité ≠ permission ≠ autonomie ≠ autorité.

Ce qu’un système peut faire ne détermine pas ce qu’il doit être autorisé à faire.

Cette distinction est évidente lorsqu’il s’agit des humains. Un directeur financier peut avoir les compétences nécessaires pour effectuer une opération de plusieurs millions d’euros sans disposer du pouvoir de l’autoriser seul. Un responsable commercial peut savoir négocier un contrat sans bénéficier de la délégation de signature correspondante. Un collaborateur peut accéder à une information sans avoir le droit de la modifier. Les organisations séparent constamment compétence, accès et pouvoir de décision. L’arrivée des agents IA impose désormais d’étendre cette logique aux systèmes artificiels.

Quand l’automatisation devient-elle une délégation de pouvoir ?

Prenons un agent chargé du processus achats. Il peut identifier des fournisseurs, demander des devis, comparer les propositions, recommander une offre, négocier certaines conditions, créer une commande, engager une dépense puis éventuellement déclencher un paiement. Sous l’angle informatique, cette succession ressemble à un processus automatisé. Sous l’angle de la gouvernance, elle raconte autre chose : à chaque étape, la nature du pouvoir confié à l’agent évolue. Analyser une offre n’équivaut pas à choisir un fournisseur. Choisir un fournisseur n’équivaut pas à engager une dépense. Préparer un paiement n’équivaut pas à l’exécuter. C’est ce que mettent également en lumière Nenad Tomašev, Matija Franklin et Simon Osindero dans leur travail publié en février 2026 sur l’Intelligent AI Delegation. Leur cadre envisage la délégation non seulement comme un transfert de tâches, mais aussi comme un transfert d’autorité, de responsabilité et de capacité à rendre compte, à l’intérieur de frontières définies.

La question managériale change alors de nature. Elle n’est plus seulement :

Quelle tâche pouvons-nous automatiser ?

Elle devient :

Quelle part du pouvoir nécessaire à son exécution sommes-nous prêts à déléguer ?

Six niveaux pour penser la délégation

L’autonomie ne devrait donc pas être pensée comme un simple interrupteur entre intervention humaine et automatisation.

Je propose ici, à titre de grille managériale, six niveaux de délégation de l’autorité. Ils ne constituent ni un standard technique ni une classification réglementaire.

Niveau 0 : observer

L’agent accède aux informations et les analyse sans recommander ni agir.

Exemple : détecter des variations anormales dans les dépenses fournisseurs.

Niveau 1 : recommander

L’agent formule une proposition sans préparer ou déclencher d’action opérationnelle.

Exemple : recommander le fournisseur présentant le meilleur compromis entre prix, qualité et délai.

Niveau 2 : préparer

L’agent prépare une action qui reste soumise à l’approbation d’une personne autorisée.

Exemple : générer un bon de commande ou préparer un projet de contrat.

Niveau 3 : exécuter sous conditions

L’agent peut agir sans approbation ponctuelle lorsqu’un ensemble de règles prédéfinies est respecté.

Exemple : passer automatiquement une commande inférieure à un seuil défini auprès d’un fournisseur référencé.

Niveau 4 : décider et exécuter

L’agent sélectionne une option et réalise l’action correspondante dans le périmètre qui lui a été confié, sans approbation humaine préalable.

Niveau 5 : déléguer et orchestrer

L’agent peut répartir certains sous-objectifs entre d’autres agents ou orchestrer plusieurs systèmes, mais uniquement dans les limites de l’autorité qui lui a été accordée. Cette dernière condition est essentielle. Un agent ne devrait pas pouvoir créer, par sous-délégation, une autorité supérieure à celle que l’organisation lui a reconnue. L’objectif n’est donc pas d’atteindre le niveau le plus élevé. Il est de déterminer le niveau d’autorité pertinent pour chaque processus, chaque risque et chaque objectif de création de valeur.

L’autorité n’est pas un niveau, c’est une enveloppe

Une échelle ne suffit cependant pas. L’autorité d’un agent est multidimensionnelle. Un agent peut être très autonome tout en restant fortement limité dans son périmètre. Un agent achats pourrait, par exemple, être autorisé à passer certaines commandes sans validation humaine, mais uniquement jusqu’à 500 euros, auprès de fournisseurs référencés, dans un périmètre géographique donné, sans modification contractuelle, sans accès à certaines catégories de données, sans sous-délégation et avec obligation d’escalade dès qu’une anomalie est détectée. Dire simplement qu’il est « niveau 4 » serait donc insuffisant. C’est pourquoi je propose une notion complémentaire : l’enveloppe d’autorité. Elle définit le périmètre à l’intérieur duquel un agent peut exercer l’autonomie qui lui a été accordée.

Cette enveloppe devrait préciser notamment les décisions autorisées, les données accessibles, les outils utilisables, les montants financiers, les périmètres géographiques, les opérations irréversibles, les conditions de validation humaine, les possibilités de sous-délégation, les règles d’escalade et les mécanismes de suspension.

L’échelle répond ainsi à une première question :

Quel degré d’autonomie accordons-nous ?

L’enveloppe répond à une seconde :

Dans quel périmètre cette autonomie peut-elle réellement s’exercer ?

C’est probablement cette seconde question qui deviendra la plus importante.

Cette tension apparaît déjà sur le terrain

Lors de mon entretien avec Anthony Levy, fondateur de Damn, cette tension apparaissait très concrètement. Il insistait sur la nécessité de définir ce qu’un agent peut faire, ce qu’il ne peut pas faire et le périmètre dans lequel il peut agir. Son approche met notamment l’accent sur l’identité de l’agent, ses permissions, ses accès et la traçabilité de ses actions.

Ce retour de terrain fait apparaître une question qui dépasse la seule cybersécurité : lorsque plusieurs permissions permettent ensemble à un agent d’agir, l’entreprise a-t-elle réellement décidé de lui confier le pouvoir correspondant ?

Quand les permissions créent une autorité que personne n’a décidée

Les architectures agentiques ajoutent une difficulté particulière : l’autorité réelle peut émerger de la combinaison des permissions.

Microsoft insiste depuis 2026 sur l’application du principe du moindre privilège (least privilege) aux agents. Chacun devrait disposer d’une identité propre, de permissions limitées et d’une activité traçable.

Mais plusieurs permissions individuellement raisonnables peuvent, lorsqu’elles sont combinées, produire un pouvoir d’action beaucoup plus important.

Reprenons l’exemple commercial. Un agent peut avoir accès au CRM, à la messagerie, aux documents commerciaux et à certaines fonctions de l’ERP. Pris séparément, chacun de ces accès paraît légitime. Ensemble, ils peuvent permettre au système d’identifier un client fragilisé, d’analyser son historique, de déterminer une nouvelle proposition tarifaire, de modifier certaines conditions commerciales puis de communiquer directement avec lui. Le problème ne réside plus dans une permission isolée. Il réside dans ce que leur combinaison rend possible.

L’autorité effective d’un agent peut devenir supérieure à ce que suggère chacune de ses permissions prise séparément.

Je propose de qualifier ce phénomène d’autorité accidentelle : un pouvoir d’action qui n’a pas été explicitement délégué par l’organisation, mais qui émerge de la combinaison des permissions techniques accordées à l’agent. L’entreprise peut ainsi donner de facto un pouvoir à la machine sans avoir jamais pris explicitement la décision managériale correspondante.

La question de gouvernance n’est donc plus seulement :

À quoi cet agent a-t-il accès ?

Elle devient :

Que peut-il réellement accomplir grâce à la combinaison de tous ses accès ?

Gouverner la trajectoire, pas seulement l’action

Cette question devient encore plus importante lorsque les agents accomplissent des tâches longues.

Les mécanismes classiques de contrôle raisonnent souvent action par action : une opération est autorisée ou interdite, une transaction dépassant un seuil exige une validation, une modification sensible déclenche une alerte.

Mais une succession d’actions individuellement acceptables peut produire collectivement un résultat qui ne l’est pas.

OpenAI en a fourni un exemple en juillet 2026 avec des modèles capables d’exécuter des tâches sur des horizons plus longs. Certaines défaillances n’avaient pas été identifiées par les évaluations préalables. L’entreprise a notamment ajouté une surveillance de la trajectoire (trajectory-level monitoring), afin d’examiner le comportement global du système plutôt qu’une succession d’actions isolées.

Le principe dépasse ce cas particulier : contrôler les actions n’équivaut pas nécessairement à gouverner la trajectoire.

L’organisation doit donc s’intéresser à ce que l’agent peut faire à chaque étape, mais aussi à ce qu’il devient capable d’accomplir lorsque ces actions s’enchaînent autour d’un même objectif.

Le sujet devient celui des droits de décision

La gouvernance de l’IA s’est largement construite autour des données, des risques, des biais, de la conformité, de la transparence, de la cybersécurité ou de la propriété intellectuelle.

Ces dimensions restent indispensables.

Mais les agents introduisent une question différente : qui peut agir au nom de l’entreprise ?

Une organisation repose précisément sur une architecture de droits de décision. Elle définit qui peut recruter, engager une dépense, modifier un prix, accorder une remise, signer un contrat ou accéder à certaines informations. Ces règles empêchent que compétence et pouvoir institutionnel soient confondus.

Les agents IA entrent désormais dans cette architecture. Dans son State of AI in the Enterprise 2026, Deloitte, à partir d’une enquête menée auprès de 3 235 dirigeants dans 24 pays, met en évidence une forte progression attendue de l’IA agentique alors que 21% des organisations déclarent disposer de dispositifs matures pour gouverner les agents autonomes.

Nous pouvons donc nous retrouver dans une situation paradoxale : des agents deviennent opérationnellement plus puissants alors que les droits de décision qui leur correspondent restent mal définis.

Faut-il formaliser une délégation d’autorité pour les agents IA ?

La comparaison avec la délégation de pouvoir doit être maniée avec prudence. Il ne s’agit pas de considérer un agent comme une personne juridique ni d’assimiler juridiquement une délégation accordée à un système artificiel à celle confiée à une personne physique. En revanche, la logique organisationnelle de la délégation est particulièrement utile.

Les entreprises utilisent déjà des périmètres d’autorité, des seuils financiers, des matrices RACI, des doubles validations, des séparations de fonctions et des délégations de signature.

Une discipline comparable peut être appliquée aux agents. Cette logique peut être traduite en un outil de gouvernance : une AI Delegation of Authority Matrix.

Son objectif n’est pas simplement de documenter les permissions techniques d’un agent. Il est de rendre explicite le pouvoir que l’organisation accepte de lui déléguer.

Dimension Question de gouvernance
Agent et mission Quel système agit et pour atteindre quel objectif ?
Données Quelles informations peut-il consulter, croiser ou modifier ?
Outils Quels systèmes, applications et API peut-il utiliser ?
Niveau de délégation Observe-t-il, recommande-t-il, prépare-t-il, exécute-t-il, décide-t-il ou orchestre-t-il ?
Décisions autorisées Que peut-il décider sans intervention humaine ?
Seuils Quelles limites financières, contractuelles, réglementaires ou opérationnelles s’appliquent ?
Irréversibilité Quelles actions exigent obligatoirement une confirmation ?
Escalade Dans quelles circonstances doit-il interrompre son action ?
Sous-délégation Peut-il confier certaines opérations à d’autres agents ?
Suspension Qui peut reprendre immédiatement le contrôle ?
Responsabilité Quelle fonction porte la responsabilité de la délégation et de ses conséquences ?

Cette matrice ne serait pas simplement un outil supplémentaire de conformité.

Elle obligerait l’organisation à rendre visible une décision qui risque autrement de rester enfouie dans l’architecture informatique :

quel pouvoir sommes-nous réellement prêts à déléguer à cette machine ?

Elle implique également que chaque agent soit identifiable et que ses actions puissent être attribuées. Le National Cybersecurity Center of Excellence du NIST explore précisément en 2026 ces questions d’identité, d’autorisation des agents logiciels et IA et de traçabilité des actions.

Sans identité claire, sans traçabilité et sans périmètre d’autorité explicite, la chaîne de responsabilité devient difficile à reconstruire.

Être « dans la boucle » ne suffit pas

Le même niveau de précision doit s’appliquer au contrôle humain. Un humain peut intervenir avant chaque action, uniquement au-delà d’un certain seuil, lorsqu’une décision devient irréversible, lorsque l’agent sort de son enveloppe d’autorité ou après l’exécution. Ces situations ne correspondent pas au même niveau de délégation. Les travaux publiés par Anthropic en février 2026 montrent que l’autonomie observée dépend non seulement des capacités du modèle, mais également de la latitude que les utilisateurs lui accordent et de la manière dont ils organisent leur supervision. L’autonomie n’est donc pas seulement une propriété technique. Elle résulte aussi d’un choix organisationnel.

La question importante n’est plus uniquement de savoir si un humain reste dans la boucle, mais à quel moment son autorité doit redevenir supérieure à celle de l’agent.

Cinq questions que les COMEX devraient poser

La gouvernance de l’autorité peut finalement être ramenée à cinq décisions.

  1. Quelle capacité voulons-nous réellement utiliser ?
    Toutes les capacités disponibles ne créent pas nécessairement de valeur.
  2. Quelle autorité voulons-nous déléguer ?
    Quelles décisions ou actions peuvent être exécutées sans approbation préalable ?
  3. Quelle enveloppe d’autorité définissons-nous ?
    Quels systèmes, données, montants, décisions, territoires et actions entrent dans le périmètre ?
  4. Comment reprenons-nous le contrôle ?
    Qui peut suspendre l’agent, interrompre une trajectoire ou réattribuer immédiatement la décision ?
  5. Qui répond de cette délégation ?
    Quelle fonction porte la responsabilité du périmètre accordé à l’agent et de ses conséquences ?

Un système autonome ne devrait jamais créer un vide organisationnel de responsabilité.

Entre capacité et valeur, l’organisation doit décider de l’autorité

Cette réflexion prolonge une conviction qui structure ma lecture de l’intelligence artificielle en entreprise :

L’intelligence artificielle crée une capacité. Les organisations créent la valeur.

L’essor des agents permet aujourd’hui de préciser ce qui se joue entre ces deux termes :

CAPACITÉ → ENVELOPPE D’AUTORITÉ → ACTION AUTONOME → RESPONSABILITÉ → VALEUR

La capacité définit ce que l’IA peut faire. L’enveloppe d’autorité détermine ce que l’organisation lui permet de faire en son nom. L’action autonome matérialise cette délégation. La responsabilité permet d’en attribuer les conséquences. La valeur justifie finalement pourquoi cette autonomie a été accordée. Une gouvernance pertinente ne consiste donc ni à réduire systématiquement l’autonomie ni à la maximiser parce que la technologie le permet. Elle consiste à déterminer le bon niveau d’autorité, dans le bon périmètre, pour le bon usage.

Gouverner l’accès au pouvoir d’agir

Pendant longtemps, gouverner un système d’information consistait notamment à décider qui pouvait accéder à quoi. Avec les agents IA, cette question ne suffit plus. Il faut désormais déterminer qui peut agir sur quoi, jusqu’où, sous quelles conditions et au nom de qui. C’est un changement plus profond qu’une nouvelle génération d’automatisation. Lorsqu’une organisation donne à une intelligence artificielle la capacité d’observer, de décider puis d’agir, elle ne lui confie plus seulement une tâche. Elle lui délègue une partie de son pouvoir d’action.

Cette délégation ne devrait jamais être accidentelle. Elle doit devenir un acte explicite de gouvernance.