Aller au contenu principal

Intelligence Artificielle — tous les articles de cette catégorie9 min de lecture

Agents IA : jusqu’où faut-il leur donner de l’autonomie ?

La question n’est plus ce qu’un agent sait faire, mais ce qu’on accepte de lui laisser faire seul — et à quelles conditions.

Illustration d’un système d’agents IA avec plusieurs niveaux d’autonomie et de contrôle : un parcours qui franchit un point de contrôle puis bifurque, une voie poursuivant seule et l’autre s’interrompant.

Pendant longtemps, utiliser une intelligence artificielle en entreprise revenait à lui poser une question et à attendre une réponse.

Avec les agents, la relation change. On ne demande plus seulement d’expliquer comment faire : on donne accès à des outils et on demande de faire. Retrouver une information, modifier un fichier, interroger une application, préparer une réponse, déclencher un workflow, enchaîner plusieurs opérations jusqu’à atteindre un objectif.

La différence peut sembler technique. Elle est surtout opérationnelle.

Une réponse incorrecte et une action incorrecte n’ont pas les mêmes conséquences.

Après avoir cherché à démontrer ce que les agents savaient faire, les entreprises doivent maintenant décider ce qu’elles acceptent de leur laisser faire seuls. Avec quel niveau de fiabilité, et à quel coût.

Un agent n’est pas simplement un chatbot plus sophistiqué

Un chatbot répond. Un agent poursuit un objectif.

Concrètement, il décompose la tâche, choisit un outil, lance une recherche, interprète le résultat, décide de l’étape suivante — et recommence jusqu’à ce qu’il estime avoir terminé.

Dans un logiciel classique, le chemin d’exécution est écrit à l’avance. Avec un agent, une partie de ce chemin dépend de décisions prises pendant l’exécution.

L’entreprise ne contrôle donc plus seulement du code. Elle doit aussi contrôler un comportement.

C’est un changement de nature, pas de degré. Les outils de test qu’on applique à un logiciel déterministe ne suffisent plus quand deux exécutions identiques peuvent emprunter deux chemins différents.

Une démonstration réussie ne prouve pas la fiabilité

Une démonstration répond à une question simple : l’agent peut-il réaliser cette tâche ?

La production en pose une autre : peut-il la réaliser correctement, suffisamment souvent, y compris dans des situations que nous n’avons pas toutes prévues ?

Ce sont deux choses différentes. La capacité se démontre en une fois ; la fiabilité s’établit sur la durée. Elle recouvre le taux de réussite, mais aussi la constance d’une exécution à l’autre, la tenue face à des entrées inhabituelles, la capacité à reconnaître qu’on ne sait pas — et la gravité des erreurs quand elles surviennent, qui n’est pas la même selon qu’on se trompe de ton ou de compte bancaire.

Les travaux de Princeton sur l’évaluation des agents ont documenté cet écart : des agents qui brillent sur un banc d’essai s’avèrent coûteux, peu reproductibles ou peu robustes dès qu’on sort du protocole. Le problème n’est pas la performance affichée. Il est ce qu’elle ne dit pas.

Il faut ajouter un mécanisme que tout le monde sous-estime : sur une tâche longue, les erreurs se cumulent. Un agent correct à chaque étape prise isolément devient nettement moins fiable quand il doit en enchaîner vingt. Le taux de réussite d’une séquence n’est pas celui de ses maillons.

Tester seulement le résultat final ne suffit donc plus.

La qualité se joue aussi entre les étapes

Prenons un agent chargé de traiter une demande de support interne.

Il doit comprendre la demande, identifier le collaborateur, retrouver les règles applicables, consulter parfois plusieurs systèmes, puis proposer ou exécuter une action.

Le résultat peut être correct alors que le parcours ne l’était pas. L’agent a consulté la mauvaise source et est tombé juste. Il a utilisé une donnée périmée qui se trouvait encore valable. Il a appelé quatre outils là où un seul suffisait. Il a ignoré une règle que personne n’a vérifiée parce que la réponse convenait.

Ces cas ne se voient pas en comparant une entrée et une sortie. Ils se voient en regardant ce qui s’est passé entre les deux.

C’est précisément l’objet des travaux d’Anthropic sur l’évaluation des agents : évaluer la trajectoire autant que le résultat, c’est-à-dire les outils appelés, l’ordre des opérations, les actions réellement effectuées. Un agent qui obtient le bon résultat par un mauvais chemin produira tôt ou tard un mauvais résultat par le même chemin.

L’assurance qualité doit donc se déplacer. Elle ne vérifie plus une paire entrée-sortie : elle définit ce qu’est un comportement acceptable pendant l’exécution, et ce qui ne l’est pas.

L’autonomie n’est pas un interrupteur

La question est rarement « supervisé ou autonome ». Elle l’est encore moins à l’échelle d’un système entier.

Un même agent peut chercher une information seul sans que cela pose problème, préparer une décision qu’un humain validera, exécuter automatiquement une opération réversible, et s’arrêter net devant une action financière ou irréversible. Quatre régimes, un seul agent.

Ce qui détermine le régime tient en quelques questions. Que coûte une erreur ? Peut-on revenir en arrière, et à quel prix ? Quelle confiance a-t-on, mesurée et non supposée, sur ce type de cas précis ? Et que dit le métier — un rattrapage acceptable dans un service interne ne l’est pas face à un client ou devant un régulateur.

Le Forum économique mondial défend cette idée d’une gouvernance calibrée sur le niveau d’autonomie réellement accordé, plutôt qu’un régime unique appliqué à tout un système. Gartner observe de son côté que la difficulté, aujourd’hui, tient moins à ce que l’agentique promet qu’à la distinction entre ce qu’elle tient déjà et ce qui reste émergent.

L’autonomie ne devrait pas être accordée une fois pour toutes. Elle devrait être gagnée.

Observer d’abord. Puis recommander. Puis agir sous validation. Puis, sur un périmètre restreint et instrumenté, agir seul. Chaque palier se justifie par des résultats, pas par une décision de principe prise en comité.

Faire progresser l’autonomie
  1. Observer

    L’agent propose, on regarde

  2. Recommander

    L’agent prépare, l’humain décide

  3. Agir sous validation

    L’action part après accord

  4. Agir sur des cas maîtrisés

    Périmètre restreint, contrôle a posteriori

Mettre un humain dans la boucle ne résout pas tout

La réponse habituelle aux risques de l’IA tient en trois mots : un humain validera.

C’est rassurant. Ce n’est pas toujours vrai.

Un opérateur qui doit approuver quarante décisions par jour n’examine pas quarante décisions. Au bout de quelques semaines, il clique. Le contrôle existe sur le papier, il a disparu dans les faits — et il a même produit un effet pervers, puisqu’il donne à l’organisation le sentiment d’être couverte.

Ce n’est pas un travers individuel, c’est un effet de conception. On le connaît bien ailleurs : dans le contrôle interne, un contrôle exhaustif qu’on ne peut pas tenir est un contrôle qui ne sera pas tenu.

Il vaut mieux distinguer trois choses. La validation avant l’action, qui bloque et qui coûte cher — à réserver à ce qui est irréversible ou lourd. La supervision après coup, qui laisse passer mais permet de corriger. Et le contrôle par exception, où l’humain n’intervient que sur les cas signalés par le système lui-même : faible confiance, montant inhabituel, écart par rapport au profil attendu.

La bonne question n’est pas : faut-il un humain ? Elle est : à quel moment son jugement apporte-t-il réellement quelque chose ?

Le coût caché de l’autonomie

Un chatbot, c’est une demande, un appel au modèle, une réponse.

Un agent, c’est une demande, un plan, plusieurs recherches, des appels d’outils, l’analyse de leurs retours, une réévaluation, de nouvelles actions. L’utilisateur voit une interaction. L’infrastructure en exécute trente.

Cet écart explique la plupart des surprises de facturation sur les premiers déploiements agentiques. Rien de dramatique, mais quelque chose qu’on ne voit pas venir tant qu’on raisonne en coût de requête.

Or le coût d’une requête ne dit pas grand-chose. La métrique utile est le coût d’une tâche correctement accomplie, reprises comprises.

Un agent trois fois plus cher à l’exécution mais qui va au bout d’un dossier sans intervention peut être excellent. Un agent bon marché qui exige deux reprises humaines par dossier ne l’est pas, même si sa ligne de facturation est plus jolie.

Le bon indicateur n’est pas le prix d’un appel. C’est le prix du travail utile qui en sort.

Tous les appels ne nécessitent pas le meilleur modèle

Dans un enchaînement agentique, les étapes n’ont pas la même difficulté.

Classer une demande dans une catégorie, extraire un montant, vérifier qu’un format est valide, choisir une route : ce sont des opérations simples, souvent déterministes. Elles n’ont pas besoin du modèle le plus capable. Certaines n’ont besoin d’aucun modèle.

Le raisonnement sur un cas ambigu, lui, le justifie.

Router entre plusieurs modèles selon la difficulté de l’étape est l’un des rares choix d’architecture qui améliore à la fois le coût, la latence et la stabilité. Il demande simplement d’avoir regardé ce que fait réellement l’agent, étape par étape — ce que peu d’équipes prennent le temps de faire avant la mise en production.

Tout ce qu’un agent peut faire n’a pas nécessairement intérêt à être fait par une IA.

Il faut savoir arrêter un agent

Que fait l’agent quand il ne sait plus ?

Quand un outil renvoie une donnée incohérente ? Quand il répète trois fois la même action sans progresser ? Quand le budget de la tâche est dépassé ? Quand il tombe sur un cas qui ne ressemble à rien de ce qui a été évalué ?

Ces questions sont rarement posées avant la mise en production. Elles se posent toujours après.

Les réponses relèvent de mécanismes ordinaires, empruntés à l’exploitation : un arrêt net au-delà d’un seuil, une escalade vers un humain avec le contexte de ce qui a été tenté, un retour à l’état précédent quand les actions sont réversibles, une bascule vers le processus classique quand l’agent sort de son domaine. Il faut aussi des plafonds — de coût, d’étapes, de temps — et un seuil de confiance en dessous duquel l’agent se tait plutôt que d’agir.

Un agent qui boucle est un problème d’exploitation avant d’être un problème d’IA. Et un agent qui va au bout d’une action qu’il aurait dû refuser est un problème de conception.

La capacité à s’arrêter proprement fait partie de l’autonomie.

Mesurer ce qui compte réellement

Les tableaux de bord des premiers projets agentiques mesurent la satisfaction et la qualité perçue des réponses. C’est utile et très insuffisant.

Ce qu’il faut suivre est moins flatteur : la part de tâches menées à terme sans intervention, la fréquence des reprises humaines, le nombre d’étapes par tâche, le coût moyen d’une tâche réussie, les actions qu’il a fallu corriger ou annuler, et les situations qui ont déclenché une escalade — celles-là surtout, parce qu’elles disent où se trouvent les limites réelles du système.

Ces chiffres servent à répondre à une seule question, posée à intervalles réguliers :

Sur quelles tâches pouvons-nous augmenter l’autonomie sans dégrader la qualité ni perdre la maîtrise des coûts ?

C’est à cet endroit que l’expérimentation devient une industrialisation.

L’autonomie doit se mériter

Les agents permettent d’automatiser des séquences de travail qui demandent de l’adaptation et des décisions. C’est exactement ce qui rend leur mise en production plus exigeante que celle d’un logiciel ordinaire.

Le bon objectif n’est ni de garder un humain derrière chaque action, ni de viser l’autonomie maximale. C’est de trouver le niveau d’autonomie utile — celui où la qualité est mesurable, le coût proportionné à la valeur, les erreurs rattrapables, et l’organisation capable de reprendre la main.

La question n’est plus seulement : que peut faire cet agent ? Elle devient : que sommes-nous prêts à lui confier ?

C’est cette seconde question qui sépare une démonstration impressionnante d’un système réellement exploitable en production.

Sources et références

  • Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir et Arvind Narayanan (Princeton), AI Agents That Matter, 2024 — écart entre performance affichée sur un banc d’essai et fiabilité réelle, coût et reproductibilité des évaluations. arxiv.org/abs/2407.01502
  • Anthropic, Demystifying evals for AI agents, 9 janvier 2026 — évaluation des trajectoires, des outils appelés et des actions effectuées, et non du seul résultat. anthropic.com/engineering/demystifying-evals-for-ai-agents
  • World Economic Forum, From chatbots to personal assistants: how governance is key to harnessing the power of AI agents, 11 septembre 2026 — gouvernance calibrée sur le niveau d’autonomie accordé. weforum.org
  • Gartner, What the 2026 Hype Cycle for Agentic AI Reveals, 15 avril 2026 — distinction entre ce que l’agentique tient aujourd’hui et ce qui reste émergent. gartner.com

INTELLIGENCE ARTIFICIELLE

Vous travaillez sur un cas d’usage agentique ?

AXENEO accompagne le cadrage, l’architecture, l’évaluation et l’industrialisation de systèmes d’intelligence artificielle adaptés aux processus et aux exigences opérationnelles de l’entreprise.