Introduction

L’essor des systèmes agentiques a profondément modifié la manière dont les entreprises envisagent l’intelligence artificielle. Pourtant, une confusion persiste : le terme « agent IA » est aujourd’hui utilisé pour désigner des architectures très différentes, allant d’un simple modèle de langage générant une réponse textuelle à un système capable de planifier des actions, d’utiliser plusieurs outils, de déléguer des tâches et d’interagir durablement avec un système d’information.

👉 Cette généralisation masque une réalité essentielle : tous les agents IA ne disposent pas du même pouvoir d’action. Or, c’est précisément ce pouvoir d’action qui détermine leur niveau de risque, les mécanismes de contrôle qu’ils nécessitent et les décisions d’architecture qu’ils imposent.

⚠️ Pourquoi tous les « agents IA » ne présentent pas le même niveau de risque

Un modèle de langage utilisé pour résumer un rapport interne ne présente pas les mêmes enjeux qu’un agent capable de modifier des données métier, de déclencher un paiement ou d’orchestrer plusieurs services applicatifs. Pourtant, ces deux systèmes sont fréquemment regroupés sous la même appellation.

Cette simplification peut sembler anodine, mais elle conduit souvent à des erreurs de conception. Elle pousse à appliquer les mêmes principes de sécurité, de gouvernance ou de supervision à des architectures dont les capacités opérationnelles sont pourtant radicalement différentes.

En pratique, le risque ne dépend pas uniquement de la qualité du raisonnement d’un modèle ou de la sophistication de son architecture. Il dépend avant tout de ce que le système est réellement capable de décider, d’exécuter, de consulter, de modifier ou de déléguer.

Autrement dit, deux systèmes reposant sur le même modèle de langage peuvent présenter des profils de risque totalement différents si leurs permissions, leurs outils ou leur niveau d’autonomie ne sont pas identiques.

📊 L’agenticité : un continuum de capacités plutôt qu’une caractéristique binaire

👉 Cette réalité conduit à abandonner une vision binaire selon laquelle un système serait simplement « agentique » ou « non agentique ».

L’agenticité doit être comprise comme un continuum de capacités. Chaque architecture se situe à un niveau différent selon les possibilités qui lui sont offertes : produire une réponse, accéder à des informations externes, sélectionner une action, utiliser un outil, enchaîner plusieurs opérations, poursuivre une tâche dans le temps ou encore déléguer certaines responsabilités à d’autres composants.

Cette progression est déterminante, car chaque capacité supplémentaire élargit potentiellement le pouvoir d’action du système et, par conséquent, les exigences en matière de contrôle.

Ainsi, un assistant documentaire basé sur une architecture de génération augmentée par récupération (RAG) n’implique pas les mêmes mécanismes de sécurité qu’un agent autonome disposant d’un accès à plusieurs applications métier. De même, une architecture multi-agents ne devient pas automatiquement plus performante ou plus sûre qu’un agent unique : tout dépend de la manière dont les responsabilités, les permissions et les interactions sont réparties.

👉 L’agenticité ne décrit donc pas une technologie particulière. Elle décrit le profil de capacités qu’une architecture confère à un système.

🏛️ Pourquoi la classification d’un système est la première étape avant toute décision d’architecture

👉 Cette distinction conduit à une conclusion fondamentale : avant de sécuriser un système agentique, il faut d’abord être capable de le classifier.

Trop souvent, les discussions portent immédiatement sur le choix du modèle de langage, des outils ou de l’orchestrateur. Pourtant, ces décisions n’ont de sens que si l’on connaît au préalable le niveau d’agenticité réellement nécessaire au cas d’usage.

Un système chargé de proposer une recommandation ne nécessite pas les mêmes permissions qu’un système capable d’exécuter automatiquement cette recommandation. De la même manière, un agent limité à la consultation d’informations ne doit pas être gouverné comme un système pouvant modifier des données critiques ou déclencher des opérations irréversibles.

La classification constitue donc le point de départ de toutes les décisions structurantes :

• quel niveau d’autonomie accorder au système ;
• quelles permissions lui attribuer ;
• quels outils lui rendre accessibles ;
• quelles actions exigeront une validation humaine ;
• quels mécanismes de supervision devront être mis en œuvre.

En l’absence d’une telle classification, il devient difficile d’adapter les contrôles au pouvoir d’action réel du système. Le risque est alors double : surprotéger des architectures simples ou, à l’inverse, sous-estimer les exigences de systèmes beaucoup plus autonomes.

🎯 Notre position : mesurer le pouvoir d’action avant de concevoir le système

La plupart des contenus consacrés aux agents IA présentent une succession de catégories techniques : modèles de langage, assistants, workflows, agents autonomes ou architectures multi-agents. Cette approche permet de comprendre les différentes familles de systèmes, mais elle ne répond pas à la question essentielle que se posent les architectes, les DSI ou les RSSI : comment déterminer le niveau de contrôle réellement nécessaire ?

La position défendue dans cet article est différente.

👉 Un système agentique ne devrait pas être évalué selon sa sophistication technologique, mais selon le pouvoir d’action que son architecture lui confère.

Cette approche conduit à déplacer le débat. La question n’est plus de savoir si une solution mérite ou non l’étiquette d’« agent IA », mais d’évaluer précisément ce qu’elle est capable de faire, dans quelles conditions et avec quel niveau d’autonomie.

Pour structurer cette analyse, nous utiliserons tout au long de cet article une matrice d’agenticité. Plus qu’un simple tableau de classification, cette matrice constitue un véritable cadre méthodologique permettant de caractériser le niveau d’agenticité d’un système à partir de ses capacités réelles. Elle offre une grille de lecture commune pour comparer différentes architectures, mesurer leur pouvoir d’action et en déduire les exigences d’architecture, de sécurité et de gouvernance.

En d’autres termes, l’objectif n’est pas de répondre à la question : « Avons-nous un agent IA ? », mais à une interrogation beaucoup plus utile pour l’entreprise :

👉 « Quel est exactement le pouvoir d’action de ce système, et comment ce pouvoir doit-il être maîtrisé ? »

C’est cette démarche qui servira de fil conducteur dans la suite de cet article, en commençant par l’analyse des différents niveaux d’agenticité et de leur impact sur la conception des systèmes IA en entreprise.

Chapitre 1 — Pourquoi classer un système agentique avant de parler d’autonomie ?

L’expression « agent IA » est désormais utilisée pour désigner une grande variété de systèmes : assistants conversationnels, applications intégrant un modèle de langage, workflows pilotés par un LLM, agents capables d’utiliser des outils, architectures multi-agents ou encore systèmes distribués. Cette généralisation simplifie le discours, mais elle masque des différences fondamentales du point de vue de l’architecture et de la gestion des risques.

En entreprise, cette confusion n’est pas uniquement terminologique. Elle influence directement les décisions de conception, les choix de sécurité et le niveau de gouvernance appliqué aux systèmes. Deux solutions présentées comme des « agents IA » peuvent partager le même modèle de langage tout en offrant des capacités opérationnelles radicalement différentes.

Avant de déterminer le niveau d’autonomie acceptable, les permissions à accorder ou les mécanismes de supervision à mettre en œuvre, une question doit donc être posée :

Quel est le véritable pouvoir d’action de ce système ?

C’est précisément l’objectif de la classification de l’agenticité. Elle ne cherche pas à attribuer une étiquette technologique, mais à mesurer les capacités réelles d’un système afin d’adapter les décisions d’architecture à son niveau d’action effectif.

1.1. Une confusion fréquente : tous les agents IA sont-ils vraiment des agents ?

L’essor de l’IA générative a largement contribué à populariser le terme « agent IA ». Dans de nombreux discours marketing, il suffit désormais qu’une application utilise un modèle de langage pour être qualifiée d’agent. Cette simplification favorise l’adoption de nouveaux usages, mais elle entretient également une confusion entre des architectures dont les responsabilités et les capacités n’ont parfois rien de comparable.

Un modèle de langage qui rédige une synthèse documentaire, un assistant enrichi par une base de connaissances, un workflow métier piloté par un LLM et un système capable de planifier des actions sur plusieurs applications sont pourtant regroupés sous une même appellation. Cette approche gomme une différence essentielle : certains systèmes produisent uniquement une information, tandis que d’autres sont capables d’agir sur leur environnement.

Cette distinction est loin d’être anodine. Un système qui génère une recommandation reste dépendant d’une décision humaine ou d’un processus externe pour produire un effet concret. À l’inverse, un agent capable d’utiliser des outils, de modifier des données ou de déclencher une opération devient un acteur du système d’information. Son comportement ne relève plus uniquement de la qualité de ses réponses, mais également de sa capacité à transformer son environnement.

Regrouper ces architectures sous une même catégorie conduit alors à deux erreurs fréquentes.

La première consiste à surestimer le risque de systèmes dont les capacités d’action restent très limitées. Un assistant documentaire en lecture seule ne nécessite pas le même niveau de contrôle qu’un agent capable de modifier des données métier.

La seconde, plus préoccupante, consiste à sous-estimer les exigences d’architectures disposant d’une autonomie opérationnelle importante. Plus un système peut agir, plus les questions liées aux permissions, aux identités, à la supervision ou à la révocation deviennent structurantes.

Le véritable critère de différenciation n’est donc pas l’utilisation d’un modèle de langage, mais le pouvoir d’action que l’architecture accorde au système.

1.2. L’agenticité : une progression du pouvoir d’action

L’agenticité ne doit pas être considérée comme une propriété binaire. Un système n’est pas simplement « agentique » ou « non agentique ». Il se situe sur un continuum de capacités, où chaque niveau correspond à un accroissement de son pouvoir d’action.

Cette progression débute avec un modèle de langage qui produit uniquement une réponse textuelle. Le système peut ensuite accéder à des informations externes, utiliser un ou plusieurs outils, sélectionner des actions, enchaîner différentes opérations, poursuivre une tâche dans le temps, collaborer avec d’autres agents ou encore déléguer certaines responsabilités.

Chaque étape franchie modifie profondément le rôle du système. Tant qu’il se limite à générer une information, son influence demeure essentiellement indirecte. Dès qu’il interagit avec des outils ou des applications métier, il devient capable d’agir sur son environnement. Plus ses capacités s’élargissent, plus il peut combiner des ressources, prendre des initiatives dans le cadre qui lui est défini et produire des effets qui dépassent la simple génération de contenu.

Cette évolution ne traduit pas uniquement une sophistication technique. Elle correspond avant tout à une augmentation progressive du pouvoir d’action du système.

C’est pourquoi deux architectures reposant sur le même modèle de langage peuvent présenter des niveaux d’agenticité très différents. Le modèle constitue le moteur de raisonnement, mais c’est l’architecture qui détermine ce que ce raisonnement peut effectivement produire dans le système d’information.

Chaque capacité supplémentaire élargit ainsi le périmètre des décisions, des actions possibles et des interactions avec l’environnement. Cette montée en puissance modifie naturellement le profil de risque et impose des exigences de contrôle plus élevées.

1.3. Pourquoi le niveau d’agenticité détermine les contrôles à mettre en place

La classification d’un système agentique n’a pas pour objectif de lui attribuer une catégorie théorique. Elle constitue un outil d’aide à la décision permettant d’adapter les mécanismes de contrôle à ses capacités réelles.

Un système capable uniquement de consulter une documentation interne ne nécessite pas les mêmes permissions qu’un agent autorisé à créer des tickets, modifier des données métier ou déclencher une transaction. De la même manière, une architecture dont toutes les actions sont validées par un opérateur humain ne présente pas le même profil qu’un système capable d’exécuter directement ces actions.

Le niveau d’agenticité devient ainsi le point de départ de nombreuses décisions d’architecture :

• quelles permissions peuvent être accordées au système ;
• quels outils peuvent lui être exposés ;
• quelles données sont accessibles ;
• quelles actions peuvent être exécutées automatiquement ;
• quelles opérations nécessitent une validation humaine ;
• quel niveau de supervision est requis ;
• quels mécanismes de journalisation, de limitation ou de suspension doivent être prévus.

👉 Autrement dit, les contrôles ne doivent pas être définis en fonction du nom donné au système, mais en fonction de son pouvoir d’action effectif.

C’est précisément la raison d’être de la classification proposée dans cet article. Elle permet de déplacer le débat d’une question essentiellement descriptive — « Avons-nous un agent IA ? » — vers une question beaucoup plus opérationnelle :

👉 Quel est exactement le pouvoir d’action de ce système, et quelles exigences d’architecture découlent de ce niveau d’agenticité ?

Cette approche constitue le fondement de la matrice d’agenticité qui sera développée dans la suite de cet article. Plus qu’un simple outil de classification, cette matrice fournit un cadre méthodologique permettant d’évaluer objectivement les capacités d’un système avant de déterminer son niveau d’autonomie, ses permissions et les mécanismes de contrôle qui devront l’encadrer.

Chapitre 2 — Du LLM au système agentique distribué : les différents niveaux d’agenticité

Le terme « agent IA » donne souvent l’impression qu’il existerait une frontière nette entre un système agentique et une application d’intelligence artificielle plus classique. En réalité, cette frontière est beaucoup plus progressive.

Chaque architecture ajoute de nouvelles capacités : accès à des données, utilisation d’outils, prise de décision, exécution d’actions, persistance dans le temps ou collaboration avec d’autres agents. À mesure que ces capacités s’accumulent, le système acquiert un pouvoir d’action de plus en plus important sur son environnement.

👉 C’est précisément cette progression qu’il convient d’analyser.

L’objectif de cette classification n’est pas d’établir une hiérarchie technologique où chaque niveau serait systématiquement supérieur au précédent. Une architecture plus autonome n’est pas nécessairement meilleure. Dans de nombreux projets d’entreprise, une solution plus simple offre un meilleur compromis entre efficacité, maîtrise des risques et facilité d’exploitation.

La question pertinente n’est donc pas :

👉 « Quel est le niveau d’agenticité le plus avancé ? »

Mais plutôt :

👉 « Quel est le niveau minimal d’agenticité nécessaire pour répondre au besoin métier tout en conservant le meilleur niveau de maîtrise ? »

Cette approche inverse le raisonnement habituellement adopté. L’objectif n’est plus de maximiser l’autonomie, mais de n’accorder au système que le pouvoir d’action strictement nécessaire à sa mission.

2.1. Le LLM sans capacité d’action : le niveau zéro de l’agenticité

Le premier niveau correspond au modèle de langage utilisé seul.

Dans cette configuration, le système reçoit une instruction, produit une réponse, puis s’arrête. Il peut résumer un document, rédiger un texte, extraire des informations, analyser un contenu ou générer du code, mais il ne dispose d’aucune capacité native pour agir sur son environnement.

Sa fonction consiste exclusivement à transformer une entrée en une sortie.

Même lorsqu’il produit une analyse particulièrement élaborée, il ne modifie ni une base de données, ni une application métier, ni un système externe. Toute action éventuelle dépend d’un utilisateur ou d’une autre application qui interprétera sa réponse.

👉 Il est donc important de distinguer raisonnement et action.

Un modèle peut démontrer des capacités de raisonnement impressionnantes sans posséder le moindre pouvoir opérationnel.

Cela ne signifie évidemment pas que les risques sont inexistants. Les problématiques de confidentialité, d’hallucinations, de qualité des réponses ou de fuite d’informations demeurent pleinement d’actualité. Toutefois, ces risques restent essentiellement indirects : le modèle influence une décision sans agir lui-même sur le système d’information.

Dans notre matrice d’agenticité, ce niveau constitue le point de départ. Il représente un système capable de produire de la connaissance, mais dépourvu d’autonomie d’exécution.

2.2. L’assistant enrichi par des données (RAG)

Le deuxième niveau apparaît lorsque le modèle de langage est connecté à une source d’information externe.

Grâce à une architecture de génération augmentée par récupération (RAG), le système peut rechercher des documents, consulter une base documentaire, accéder à des procédures internes ou récupérer un contexte métier avant de produire sa réponse.

Cette évolution améliore considérablement la pertinence des réponses tout en limitant certains problèmes liés aux connaissances internes de l’entreprise.

Pour autant, cette capacité supplémentaire ne transforme pas automatiquement le système en agent autonome.

Dans une architecture RAG classique, le déroulement reste largement déterministe :

👉 Question → Recherche → Récupération des informations → Génération de la réponse.

Le système enrichit son contexte, mais il ne décide ni de son objectif ni des actions à entreprendre. Il consulte des informations sans modifier l’environnement dans lequel il évolue.

Le périmètre d’exposition augmente, puisque le modèle accède désormais à des ressources externes. En revanche, son pouvoir d’action demeure limité.

👉 Cette distinction est essentielle : accéder à davantage d’informations ne signifie pas disposer de davantage d’autonomie.

2.3. Le workflow piloté par un LLM

Le niveau d’agenticité progresse lorsque le modèle de langage intervient dans un processus métier déjà défini.

Le LLM ne se contente plus de répondre : il participe à la prise de décision en choisissant, par exemple, la branche suivante d’un workflow, la catégorie d’une demande ou la fonction à exécuter parmi plusieurs possibilités prévues.

L’architecture conserve néanmoins une caractéristique essentielle : le cadre d’exécution reste conçu à l’avance.

Les étapes possibles sont connues.

Les outils accessibles sont définis.

Les transitions sont encadrées.

Les conditions d’arrêt sont prévues.

Le modèle apporte donc une capacité d’adaptation locale sans disposer d’une liberté complète pour construire sa propre stratégie.

Cette architecture représente souvent un excellent compromis pour les entreprises.

Elle permet de bénéficier de la flexibilité d’un modèle de langage tout en conservant la prévisibilité et la gouvernance d’un workflow classique.

Dans de nombreux cas, remplacer un workflow maîtrisé par un agent autonome n’apporte aucune valeur supplémentaire. Au contraire, cette évolution augmente la complexité des tests, rend les comportements plus difficiles à expliquer et élargit inutilement la surface de contrôle.

👉 La première règle d’une architecture robuste consiste donc à ne pas introduire davantage d’agenticité que le cas d’usage ne l’exige réellement.

2.4. L’agent mono-outil

Avec l’agent mono-outil, un changement de nature s’opère.

Le système ne produit plus seulement une recommandation : il devient capable d’interagir avec son environnement en utilisant un outil déterminé.

Cette capacité peut sembler limitée, mais elle modifie profondément le modèle de risque.

👉 Le véritable changement ne réside pas dans le nombre d’outils disponibles, mais dans le passage de la réponse à l’action.

Selon la nature de cet outil, l’agent pourra simplement consulter une information ou, au contraire, modifier une donnée, créer une ressource ou déclencher une opération métier.

C’est pourquoi il serait trompeur d’évaluer un agent uniquement en comptant le nombre de fonctions auxquelles il accède.

Un agent disposant d’un seul outil de paiement présente potentiellement davantage de risques qu’un agent ayant accès à plusieurs outils limités à la consultation d’informations.

Dans la matrice d’agenticité, la question essentielle devient alors :

👉 Que permet réellement cet outil ?

2.5. L’agent multi-outils

Lorsque plusieurs outils deviennent disponibles, le pouvoir d’action du système ne progresse plus de manière linéaire.

👉 Il augmente par composition.

L’agent peut désormais enchaîner différentes opérations, utiliser le résultat d’une première action pour alimenter la suivante, puis poursuivre son objectif sans intervention humaine.

C’est cette capacité de combinaison qui modifie profondément le profil de risque.

Pris isolément, chacun des outils peut paraître peu sensible.

En revanche, leur utilisation successive peut produire un effet qui n’avait jamais été envisagé lors de leur conception individuelle.

Cette évolution introduit une notion essentielle : le blast radius, c’est-à-dire le périmètre potentiel des conséquences qu’un système peut produire lorsqu’il agit.

Le blast radius ne dépend pas uniquement de la permission la plus élevée dont dispose un agent. Il dépend également de sa capacité à combiner plusieurs permissions, plusieurs données et plusieurs outils.

👉 L’analyse ne doit donc plus porter sur chaque outil pris séparément, mais sur les scénarios qu’ils rendent possibles lorsqu’ils sont utilisés ensemble.

2.6. L’agent autonome

L’agent autonome franchit une nouvelle étape.

Au lieu d’exécuter un scénario prédéfini, il reçoit un objectif et construit lui-même une partie de sa stratégie pour l’atteindre.

Il peut sélectionner les outils les plus appropriés, analyser les résultats obtenus, ajuster son comportement et poursuivre son exécution jusqu’à satisfaire une condition d’arrêt.

Le contrôle ne porte alors plus principalement sur les étapes du processus.

Il porte sur le cadre dans lequel cette autonomie peut s’exercer.

• Objectifs.
• Contraintes.
• Budget d’actions.
• Durée maximale.
• Conditions d’arrêt.
• Validation humaine pour certaines opérations.
• Journalisation.
• Capacité de suspension.

👉 Autrement dit, plus l’autonomie décisionnelle progresse, plus les mécanismes de gouvernance doivent se déplacer vers le contrôle des limites plutôt que vers le contrôle de chaque action individuelle.

2.7. Le système multi-agents

Une architecture multi-agents répartit les responsabilités entre plusieurs agents spécialisés.

• L’un peut planifier.
• Un autre rechercher des informations.
• Un troisième analyser les résultats.
• Un quatrième exécuter certaines opérations.

Cette décomposition peut améliorer la modularité, faciliter l’évolution du système ou limiter certaines permissions lorsqu’elle est correctement conçue.

Mais elle ne constitue pas, à elle seule, une amélioration.

Multiplier les agents revient également à multiplier les échanges, les identités, les dépendances et les chaînes de décision.

La question pertinente n’est donc jamais :

👉 « Combien d’agents pouvons-nous créer ? »

Mais :

👉 « Cette séparation des responsabilités améliore-t-elle réellement la maîtrise du système ? »

Une architecture multi-agents n’est justifiée que lorsqu’elle réduit effectivement la complexité globale ou améliore l’isolation des responsabilités.

2.8. Le système agentique distribué

Le niveau le plus élevé d’agenticité apparaît lorsque plusieurs composants autonomes interagissent au sein d’un même écosystème.

• Agents spécialisés.
• Plusieurs modèles.
• API internes.
• Services SaaS.
• Bases de données.
• Outils distants.
• Mécanismes de mémoire.
• Orchestrateurs.
• Utilisateurs humains.

À ce stade, l’agenticité ne peut plus être attribuée à un composant unique.

👉 Elle devient une propriété émergente de l’ensemble de l’architecture.

Une décision peut résulter d’une succession d’interactions entre plusieurs agents, plusieurs services et plusieurs environnements, chacun contribuant à une partie du processus.

Les frontières de confiance deviennent alors plus difficiles à identifier.

Les responsabilités sont distribuées.

Les permissions se combinent.

Les décisions circulent.

Les actions se propagent.

L’enjeu ne consiste plus seulement à sécuriser chaque composant, mais à comprendre le pouvoir d’action produit par leurs interactions.

C’est précisément à ce stade que la simple description des architectures ne suffit plus. Il devient nécessaire de disposer d’une méthode capable d’évaluer objectivement le niveau d’autonomie réel d’un système.

C’est l’objet du chapitre suivant, qui introduit les cinq dimensions de l’autonomie et la matrice d’agenticité, véritable grille d’analyse permettant de mesurer le pouvoir d’action d’un système avant toute décision d’architecture.

Chapitre 3 — Les cinq dimensions qui révèlent le véritable niveau d’autonomie d’un agent

Le chapitre précédent a montré que l’agenticité ne constitue pas une caractéristique binaire. Entre un modèle de langage qui génère une réponse et un système capable d’orchestrer plusieurs agents, il existe une progression continue du pouvoir d’action.

Cependant, cette première classification reste insuffisante pour évaluer précisément un système. Deux agents appartenant à une même catégorie peuvent présenter des profils de risque très différents. L’un peut disposer d’une grande liberté de décision tout en restant incapable d’agir sans validation humaine. Un autre peut suivre un scénario très simple mais être autorisé à exécuter directement des opérations critiques.

Autrement dit, le niveau d’agenticité ne peut être déterminé uniquement par le type d’architecture adopté. Il doit également être évalué selon les capacités réelles dont dispose le système.

👉 C’est pourquoi nous proposons d’analyser tout système agentique selon cinq dimensions complémentaires de l’autonomie. Ensemble, elles permettent de mesurer son pouvoir d’action effectif et constituent le socle de la matrice d’agenticité présentée dans le chapitre suivant.

3.1. L’autonomie décisionnelle

La première dimension concerne la capacité du système à construire lui-même sa stratégie d’exécution.

Dans les architectures les plus simples, cette stratégie est entièrement définie par les concepteurs. Le système se contente d’exécuter un enchaînement d’étapes prédéterminé ou de choisir entre quelques options prévues à l’avance.

À mesure que l’agenticité augmente, cette contrainte s’allège. Le système peut adapter son plan en fonction du contexte, modifier l’ordre des opérations, sélectionner les outils qu’il juge les plus appropriés ou réorienter son approche selon les résultats obtenus.

La question fondamentale devient alors :

👉 Qui décide réellement de la stratégie d’exécution ?

La réponse peut être multiple :

• un opérateur humain ;
• un workflow prédéfini ;
• un modèle de langage ;
• un orchestrateur ;
• un autre agent.

Plus la stratégie est construite dynamiquement au moment de l’exécution, plus les mécanismes de contrôle doivent porter sur les objectifs assignés, les contraintes imposées et les conditions d’arrêt, plutôt que sur la séquence exacte des opérations.

👉 L’autonomie décisionnelle mesure donc la liberté laissée au système pour déterminer comment atteindre un objectif.

3.2. L’autonomie d’exécution

👉 Décider ne signifie pas nécessairement agir.

Cette distinction est fondamentale dans l’analyse d’un système agentique.

Deux architectures peuvent parvenir exactement à la même conclusion tout en présentant des niveaux de risque radicalement différents.

Dans le premier cas, le système recommande une action et attend qu’un utilisateur la valide avant toute exécution.

Dans le second, cette même décision déclenche immédiatement une modification de données, l’envoi d’une commande ou l’exécution d’une opération métier.

Le raisonnement est identique.

Le pouvoir d’action ne l’est pas.

L’autonomie d’exécution mesure précisément cette capacité à transformer une décision en action sans intervention humaine immédiate.

Cette dimension influence directement le niveau de contrôle nécessaire.

Plus un système peut agir seul, plus il devient indispensable de définir :

• les actions autorisées ;
• les opérations interdites ;
• les validations obligatoires ;
• les conditions d’interruption ;
• les mécanismes de supervision.

En pratique, ce n’est pas uniquement la qualité des décisions qui détermine le risque, mais la possibilité de les exécuter automatiquement.

3.3. L’autonomie temporelle

L’autonomie ne dépend pas uniquement de ce qu’un système peut faire. Elle dépend également de la durée pendant laquelle il peut continuer à agir.

Un agent qui répond à une requête avant de s’arrêter immédiatement présente un profil très différent d’un système capable de conserver un état, de reprendre une tâche plusieurs heures plus tard ou d’exécuter des opérations de manière planifiée.

Cette persistance constitue une dimension souvent sous-estimée.

Lorsqu’un système reste actif dans le temps, plusieurs enjeux apparaissent progressivement :

• accumulation d’erreurs ;
• dérive comportementale ;
• utilisation prolongée de permissions ;
• maintien d’identités ou de secrets devenus obsolètes ;
• difficulté à interrompre rapidement une tâche en cours.

Plus la durée de fonctionnement augmente, plus la maîtrise opérationnelle devient complexe.

L’autonomie temporelle conduit donc à s’interroger non seulement sur ce que l’agent peut faire, mais aussi sur combien de temps il est autorisé à le faire.

Cette question influence directement la conception des mécanismes de limitation, de supervision et de révocation.

3.4. L’autonomie d’accès

L’un des principaux facteurs de risque d’un système agentique réside dans les ressources auxquelles il peut accéder.

Ces ressources peuvent être de nature très différente :

• données internes ;
• API ;
• applications métier ;
• services cloud ;
• outils SaaS ;
• bases documentaires ;
• environnements d’exécution ;
• secrets techniques.

L’autonomie d’accès mesure la capacité du système à consulter ou à utiliser ces ressources sans médiation humaine.

Toutefois, disposer d’un accès ne signifie pas qu’il doive être illimité.

Au contraire, cette dimension doit être analysée à la lumière du principe du moindre privilège.

👉 Un agent ne devrait jamais disposer d’autorisations plus larges que celles strictement nécessaires à la mission qui lui est confiée.

Cette approche impose que chaque accès soit :

• explicitement autorisé ;
• limité au périmètre utile ;
• contextualisé selon la tâche ;
• traçable ;
• facilement révocable.

L’autonomie d’accès ne se limite donc pas à une question de connectivité. Elle renvoie directement à l’identité du système et aux permissions qui lui sont effectivement accordées.

Le véritable pouvoir d’action d’un agent dépend moins du nombre d’outils disponibles que de l’étendue des privilèges associés à chacun d’entre eux.

3.5. L’autonomie de délégation

La dernière dimension est également l’une des moins visibles.

Un système agentique peut-il demander à un autre agent, à un service ou à un composant d’agir en son nom ?

Cette capacité de délégation apporte une grande souplesse dans les architectures complexes, mais elle crée également une chaîne de confiance dont les conséquences sont parfois difficiles à anticiper.

Chaque délégation soulève plusieurs questions.

L’autorité transmise est-elle limitée ?

Les permissions du système délégataire sont-elles supérieures à celles du système délégant ?

Une délégation permet-elle de contourner des restrictions qui auraient dû s’appliquer directement ?

Ces interrogations deviennent particulièrement importantes dans les architectures multi-agents.

Un agent faiblement privilégié pourrait, en théorie, obtenir indirectement davantage de capacités en sollicitant un composant disposant de permissions plus élevées.

Sans mécanisme de contrôle, la délégation risque alors d’élargir progressivement le pouvoir d’action global du système sans qu’aucune permission supplémentaire n’ait été explicitement accordée.

Une architecture robuste impose donc que toute délégation soit :

• authentifiée ;
• explicitement autorisée ;
• limitée à un périmètre défini ;
• intégralement traçable.

👉 L’autonomie de délégation ne mesure pas seulement la capacité à distribuer des tâches. Elle évalue également la manière dont une architecture contrôle la circulation des responsabilités et des privilèges entre ses différents composants.

Un agent n’est jamais autonome de manière absolue

L’une des erreurs les plus fréquentes consiste à qualifier un système d’« agent autonome » sans préciser de quelle autonomie il est réellement question.

En pratique, l’autonomie n’est jamais un attribut unique. Elle résulte de la combinaison de plusieurs dimensions indépendantes.

Un agent peut disposer d’une grande liberté de décision tout en restant incapable d’agir sans validation humaine. À l’inverse, un système dont la logique est entièrement prédéfinie peut exécuter automatiquement des opérations critiques si les permissions qui lui sont accordées sont suffisamment étendues.

👉 L’autonomie d’un système n’est donc pas absolue : elle constitue un profil composé de cinq dimensions complémentaires — décision, exécution, temps, accès et délégation.

Cette grille de lecture représente le cœur de la matrice d’agenticité. En évaluant séparément chacune de ces dimensions, il devient possible de mesurer objectivement le pouvoir d’action réel d’un système et d’adapter, de manière proportionnée, les exigences d’architecture, de sécurité et de gouvernance.

Chapitre 4 — Comment évaluer le niveau d’agenticité d’un système avant son déploiement

Les chapitres précédents ont établi deux constats essentiels. D’une part, l’agenticité n’est pas une caractéristique binaire mais un continuum de capacités. D’autre part, le véritable niveau d’autonomie d’un système ne peut être apprécié qu’en analysant plusieurs dimensions complémentaires : la décision, l’exécution, le temps, l’accès et la délégation.

Ces éléments constituent une base d’analyse, mais ils ne suffisent pas encore à guider les choix d’architecture. Une entreprise ne déploie pas un agent parce qu’il appartient à une catégorie donnée ; elle le déploie pour répondre à un besoin métier, dans un environnement soumis à des contraintes de sécurité, de conformité, de disponibilité et de gouvernance.

La question devient alors beaucoup plus opérationnelle :

👉 Comment déterminer, avant tout déploiement, si le niveau d’agenticité d’un système est adapté au cas d’usage et compatible avec les exigences de l’organisation ?

Pour répondre à cette question, il est nécessaire de disposer d’une méthode d’évaluation reproductible. La matrice d’agenticité proposée dans ce chapitre répond précisément à cet objectif. Elle ne cherche pas à attribuer une étiquette à un système, mais à établir un diagnostic structuré de son pouvoir d’action afin d’en déduire les exigences d’architecture qui lui sont associées.

4.1. Les cinq questions indispensables

Toute évaluation commence par une série de questions simples, mais déterminantes. Elles permettent d’identifier rapidement le niveau d’agenticité d’un système avant même d’examiner son implémentation technique.

Le système décide-t-il lui-même ?

La première question consiste à déterminer l’origine des décisions.

Le système applique-t-il un scénario entièrement défini par les concepteurs ou construit-il lui-même sa stratégie d’exécution en fonction du contexte ?

Plus cette capacité de décision est importante, plus il devient nécessaire de contrôler les objectifs assignés, les contraintes imposées et les critères d’arrêt plutôt que les étapes individuelles du processus.

Peut-il agir sans validation humaine ?

Une recommandation n’a pas les mêmes conséquences qu’une action exécutée automatiquement.

Il convient donc d’identifier précisément les opérations que le système peut réaliser sans intervention humaine : modifier des données, envoyer une commande, déclencher un processus métier ou interagir avec un service externe.

👉 Cette question permet de distinguer un système d’assistance d’un système disposant d’une véritable autonomie opérationnelle.

Peut-il poursuivre une tâche dans le temps ?

Un système dont l’exécution s’arrête immédiatement après chaque requête présente un profil de risque très différent d’un agent capable de conserver un état, de reprendre une tâche plusieurs heures plus tard ou d’exécuter des traitements planifiés.

L’autonomie temporelle influence directement les mécanismes de supervision, de limitation de durée et de révocation.

À quelles ressources peut-il accéder ?

Le pouvoir d’action dépend autant des permissions que des capacités de raisonnement.

Il est donc indispensable d’identifier :

• les données accessibles ;
• les applications métier concernées ;
• les API disponibles ;
• les outils utilisables ;
• les privilèges effectivement accordés.

👉 Cette analyse permet de mesurer la surface d’action réelle du système.

Peut-il déléguer une action ou une autorité ?

Enfin, il convient d’évaluer si le système peut solliciter d’autres agents, transmettre une tâche ou s’appuyer sur des composants disposant de privilèges différents.

Cette capacité élargit potentiellement le pouvoir d’action global du système et modifie les chaînes de confiance qui devront être contrôlées.

👉 Ces cinq questions ne remplacent pas une analyse détaillée. Elles constituent cependant un premier filtre permettant de positionner rapidement un système dans le continuum d’agenticité.

4.2. Les critères qui influencent réellement le niveau de risque

Deux systèmes présentant un niveau d’agenticité comparable peuvent néanmoins exposer l’organisation à des niveaux de risque très différents. L’évaluation doit donc être complétée par une analyse qualitative des actions que le système est autorisé à réaliser.

La criticité des actions

Toutes les opérations n’ont pas le même impact.

Consulter une base documentaire, créer un brouillon de réponse, modifier un enregistrement client, déclencher un paiement ou arrêter un service de production ne présentent évidemment pas les mêmes conséquences.

👉 L’évaluation doit donc porter sur les effets concrets des actions réalisables, et non uniquement sur leur nombre.

Leur réversibilité

La capacité à revenir en arrière constitue un facteur déterminant.

Certaines actions peuvent être annulées ou corrigées sans conséquence majeure. D’autres produisent des effets irréversibles ou particulièrement coûteux à réparer.

👉 Plus une action est difficile à annuler, plus les mécanismes de validation et de supervision doivent être renforcés.

L’étendue des permissions

Le risque dépend directement des privilèges effectivement accordés au système.

Une architecture simple disposant d’un accès étendu à des ressources critiques peut présenter un niveau de risque supérieur à celui d’un agent beaucoup plus sophistiqué mais strictement limité dans ses permissions.

👉 Le principe du moindre privilège reste donc un élément central de l’évaluation.

Les capacités de supervision et de révocation

Enfin, aucune analyse ne serait complète sans examiner les moyens de reprendre le contrôle du système.

L’organisation doit être en mesure :

• d’observer les décisions prises ;
• de retracer les actions exécutées ;
• d’interrompre rapidement un traitement ;
• de suspendre des permissions ;
• de révoquer l’identité du système si nécessaire.

👉 La capacité à superviser et à arrêter un agent constitue un élément aussi important que son niveau d’autonomie.

4.3. La matrice d’agenticité : un cadre d’analyse avant toute décision d’architecture

Les éléments étudiés jusqu’à présent peuvent désormais être réunis dans une méthode unique d’évaluation.

La matrice d’agenticité ne cherche pas à produire un score universel ni à établir un classement des technologies. Son objectif est beaucoup plus pragmatique : fournir une grille de lecture permettant de relier les capacités réelles d’un système aux décisions d’architecture qui en découlent.

Elle s’articule autour de quatre étapes successives.

Étape 1 : Identifier le niveau d’agenticité

La première étape consiste à situer le système dans le continuum présenté au chapitre précédent.

S’agit-il :

• d’un modèle de langage sans capacité d’action ;
• d’un assistant enrichi par des données ;
• d’un workflow piloté par un LLM ;
• d’un agent utilisant un ou plusieurs outils ;
• d’un agent autonome ;
• d’un système multi-agents ;
• d’une architecture agentique distribuée ?

👉 Cette première classification fournit une vision globale du pouvoir d’action attendu.

Étape 2 : Mesurer les cinq dimensions d’autonomie

Le deuxième niveau d’analyse consiste à établir un profil détaillé du système en évaluant séparément :

• son autonomie décisionnelle ;
• son autonomie d’exécution ;
• son autonomie temporelle ;
• son autonomie d’accès ;
• son autonomie de délégation.

👉 Cette approche évite les classifications simplistes.

Deux agents appartenant à la même catégorie peuvent ainsi présenter des profils très différents selon les dimensions analysées.

Étape 3 : Évaluer le pouvoir d’action réel

Une fois le profil établi, il devient possible d’analyser ce que le système est réellement capable de faire.

Cette étape consiste notamment à répondre aux questions suivantes :

• Quelles décisions peut-il prendre seul ?
• Quelles actions peut-il exécuter ?
• Quelles ressources peut-il consulter ou modifier ?
• Quelles opérations peut-il déléguer ?
• Jusqu’où peut-il agir avant qu’une intervention humaine ne soit nécessaire ?

👉 Cette analyse permet de mesurer le pouvoir d’action effectif du système, indépendamment de la technologie utilisée.

Étape 4 : Déduire les exigences d’architecture

La dernière étape transforme l’analyse en décisions concrètes.

À partir du profil d’agenticité obtenu, il devient possible de définir :

• le modèle d’identité du système ;
• les permissions minimales à lui accorder ;
• les opérations nécessitant une validation humaine ;
• les mécanismes d’observabilité ;
• les exigences de journalisation ;
• les procédures de suspension et de révocation.

👉 La matrice cesse alors d’être un simple outil descriptif. Elle devient un instrument d’aide à la conception permettant d’aligner les choix d’architecture sur le niveau réel d’autonomie du système.

Prise de position éditoriale — De la classification à la décision

La plupart des typologies des agents IA s’arrêtent à une description des architectures : assistants, workflows, agents autonomes ou systèmes multi-agents. Cette classification est utile pour comprendre les technologies, mais elle reste insuffisante pour concevoir des systèmes fiables en entreprise.

La matrice d’agenticité défendue dans cet article poursuit un objectif différent.

👉 Elle ne cherche pas à dire ce qu’est un agent, mais à mesurer ce qu’il est réellement capable de faire.

En reliant le niveau d’agenticité aux exigences d’identité, de permissions, de validation humaine, d’observabilité et de révocation, elle transforme une classification théorique en une méthode d’aide à la décision.

C’est cette évolution qui en fait un véritable cadre d’analyse. Avant de choisir une architecture, de définir une politique de sécurité ou d’accorder des permissions à un système agentique, la première question ne devrait jamais être : « Quel type d’agent allons-nous construire ? »

Elle devrait toujours être :

👉 « Quel pouvoir d’action sommes-nous prêts à lui confier, et comment allons-nous le maîtriser ? »

Conclusion

L’analyse des différents niveaux d’agenticité montre qu’il est insuffisant de considérer un système comme un simple « agent IA ». Derrière cette appellation se trouvent des architectures dont les capacités peuvent être radicalement différentes : certains systèmes se limitent à générer une réponse, tandis que d’autres peuvent décider, exécuter des actions, poursuivre une tâche dans le temps, accéder à des ressources sensibles ou déléguer des capacités à d’autres composants.

👉 L’agenticité doit donc être comprise comme un profil de capacités, et non comme une étiquette technologique.

Ce profil se construit progressivement à mesure que le système acquiert davantage de pouvoir d’action. Un modèle de langage sans capacité d’exécution ne présente pas le même profil qu’un agent capable d’utiliser plusieurs outils. De la même manière, un agent autonome ou un système multi-agents ne doit pas être évalué uniquement à partir de son architecture apparente, mais à partir de ce qu’il peut réellement décider, exécuter, maintenir dans le temps, consulter ou déléguer.

Cette distinction est essentielle pour les organisations qui souhaitent déployer des systèmes agentiques en environnement professionnel.

Plus le pouvoir d’action augmente, plus les exigences de contrôle doivent augmenter

L’un des principes fondamentaux qui ressort de cette analyse est simple :

👉 Plus le pouvoir d’action d’un système augmente, plus les exigences en matière de contrôle doivent être renforcées.

Cette relation ne signifie pas qu’il faudrait systématiquement éviter les architectures autonomes. Elle signifie que l’autonomie doit être proportionnée au besoin réel et accompagnée de mécanismes de contrôle adaptés.

Un système capable de produire une recommandation ne doit pas nécessairement être soumis aux mêmes contraintes qu’un système capable d’exécuter directement cette recommandation. De la même manière, un agent disposant d’un accès limité à une ressource ne présente pas le même profil qu’un système pouvant combiner plusieurs outils et déléguer des actions à d’autres composants.

👉 Le niveau de contrôle doit donc être déterminé par le pouvoir d’action effectif, et non par le simple fait qu’un système soit présenté comme un agent.

Cette approche permet également d’éviter une erreur fréquente : rechercher systématiquement le niveau d’autonomie le plus élevé. Dans de nombreux cas, l’architecture la plus pertinente n’est pas celle qui maximise l’autonomie, mais celle qui atteint l’objectif métier avec le niveau d’agenticité minimal nécessaire.

La question n’est donc pas de savoir comment rendre un système aussi autonome que possible.

Elle est de déterminer :

👉 Quelle autonomie est réellement nécessaire, et quel pouvoir d’action sommes-nous prêts à lui confier ?

Mesurer l’agenticité avant de sécuriser et de gouverner

Cette réflexion conduit à une conséquence pratique majeure : avant de sécuriser, de gouverner ou de déployer un agent IA, il faut d’abord être capable de mesurer objectivement son niveau d’agenticité.

Cette mesure repose sur deux niveaux complémentaires.

Le premier consiste à situer le système dans un continuum allant du LLM sans capacité d’action jusqu’aux systèmes agentiques distribués.

Le second consiste à analyser son profil d’autonomie selon cinq dimensions :

• l’autonomie décisionnelle ;
• l’autonomie d’exécution ;
• l’autonomie temporelle ;
• l’autonomie d’accès ;
• l’autonomie de délégation.

👉 Cette double lecture permet d’aller au-delà des catégories technologiques pour comprendre le pouvoir d’action réel du système.

C’est précisément le rôle de la matrice d’agenticité.

Elle permet de transformer une notion souvent abstraite en une grille d’analyse exploitable. En identifiant le niveau d’agenticité, puis en évaluant les cinq dimensions de l’autonomie, il devient possible de caractériser le système, d’apprécier son pouvoir d’action et d’en déduire les exigences nécessaires à sa maîtrise.

La matrice ne constitue donc pas une fin en soi. Elle sert de point de départ à une démarche de conception.

Elle permet de poser les bonnes questions avant que les choix d’architecture ne soient figés :

• Quelle identité le système doit-il posséder ?
• Quelles permissions sont réellement nécessaires ?
• Quelles actions peuvent être automatisées ?
• Quelles décisions doivent rester soumises à une validation humaine ?
• Quel niveau d’observabilité est nécessaire ?
• Comment interrompre ou révoquer le système si son comportement devient indésirable ?

👉 En ce sens, la classification de l’agenticité devient une étape préalable à la conception plutôt qu’un exercice de documentation réalisé après coup.

Mesurer le pouvoir d’action avant d’accorder l’autonomie

Un système n’est pas plus risqué parce qu’il est présenté comme un « agent IA ».

Il le devient parce que son architecture lui confère un certain pouvoir d’action.

Cette distinction constitue le principe central de l’approche défendue dans cet article. L’agenticité ne doit pas être évaluée à partir du vocabulaire utilisé pour décrire une solution, ni uniquement à partir du modèle de langage qu’elle embarque. Elle doit être mesurée à partir de ses capacités réelles : ce que le système peut décider, ce qu’il peut exécuter, combien de temps il peut agir, quelles ressources il peut atteindre et jusqu’où il peut déléguer ses capacités.

👉 Avant de sécuriser un agent, il faut donc mesurer son agenticité.

👉 Avant de lui accorder des permissions, il faut comprendre son pouvoir d’action.

👉 Avant de concevoir son architecture, il faut déterminer le niveau d’autonomie réellement nécessaire.

C’est dans cette perspective que la matrice d’agenticité prend tout son sens. Elle n’est pas un simple outil de classification destiné à ranger les systèmes dans différentes catégories. Elle constitue une méthode d’analyse permettant de relier les capacités réelles d’un système aux décisions concrètes qui doivent encadrer son fonctionnement.

Elle fournit ainsi un langage commun pour analyser les architectures agentiques et une grille de lecture réutilisable pour les concevoir.

La question fondamentale n’est donc plus :

👉 « Est-ce un agent IA ? »

Mais :

👉 « Quel pouvoir d’action son architecture lui confère-t-elle, et quels contrôles devons-nous mettre en place pour que ce pouvoir reste maîtrisé ? »

C’est à partir de cette question que peut commencer une véritable démarche d’architecture agentique responsable.