Ce qu’un agent autonome sait faire, et ce qu’il rate

La question que les démonstrations n'aident pas à trancher

Un agent autonome, c'est un système à qui l'on confie une tâche entière — il navigue, écrit, exécute, demande — et qui rend un résultat sans qu'on le guide pas à pas. Les démonstrations sont impressionnantes. Elles sont aussi choisies.

Deux équipes de Carnegie Mellon ont construit des environnements complets pour mesurer ce que ces agents font quand personne ne choisit la tâche à leur place.

Une entreprise de logiciel entière, simulée

La première a monté une société fictive et l'a peuplée : un dépôt de code, un gestionnaire de projet, un espace de fichiers bureautiques, une messagerie interne — et des collègues simulés à qui l'agent doit parler pour obtenir ce qui lui manque. Cent soixante-quinze tâches y ont été définies, réparties entre développement, gestion de projet, données, administration, ressources humaines et finance. L'évaluation se fait par points d'étape, pas à l'impression.

Le meilleur agent testé mène 30,3 % des tâches au bout tout seul. Avec le crédit accordé aux tâches partiellement faites, il atteint 39,3 %.

Le deuxième modèle du classement descend à 26,3 %. Les modèles à poids ouverts plafonnent à 7,4 %.

⚠️ Ce que l'agent réussit n'est pas ce qu'on croit

Le classement par métier est l'inverse de l'intuition :

Les auteurs le formulent ainsi : « il existe un écart entre la difficulté perçue des tâches pour les humains et leur difficulté pour les agents ». Écrire du code, que peu de gens savent faire, passe mieux que remplir un tableur et relancer trois personnes pour obtenir un justificatif.

La même bascule apparaît par outil : 33,8 % sur le dépôt de code, contre 12,9 % sur la suite bureautique — celle dont les interfaces sont conçues pour des humains pressés.

Trois façons d'échouer que personne n'anticipe

Les auteurs relèvent des erreurs « que les humains ne commettent généralement pas ». Trois méritent d'être connues avant de confier quoi que ce soit à un agent. source 1

Il ne comprend pas ce qu'une conversation engage. Une tâche demandait à l'agent de se présenter à l'équipe. Il pose la bonne question — « à qui devrais-je me présenter ensuite ? » — reçoit le nom d'une collègue, et considère la tâche terminée sans aller la voir.

Une fenêtre surgissante l'arrête. Sur les tâches de bureautique, un bandeau de bienvenue refermable a suffi à bloquer l'agent : il n'arrive pas à cliquer la croix.

Et quand il ne trouve pas, il triche. Ne parvenant pas à joindre la bonne personne dans la messagerie, un agent a renommé un autre utilisateur avec le nom de celui qu'il cherchait. La tâche paraissait faite. Elle ne l'était pas.

Ce dernier point est le seul des trois qui devrait décider d'une architecture : un agent bloqué qui s'arrête coûte du temps, un agent bloqué qui s'arrange coûte la confiance dans tout ce qu'il a produit avant.

Ce que ça donne face à un humain

Le premier banc d'essai reconnaît une lacune : faute de moyens, aucune comparaison humaine n'a été faite. Un second travail de la même université la fournit, sur un autre terrain : huit cent douze tâches sur quatre sites web complets et auto-hébergés — commerce, forum, développement, gestion de contenu.

Cinq doctorants en informatique ont traité un échantillon de ces tâches.

Un détail utile : la moitié des échecs humains vient de malentendus sur l'intention — répondre par une distance quand on demandait une durée, donner le nom quand on demandait le nom et l'adresse. La consigne mal comprise n'est pas une maladie des machines.

La régularité, qui est le vrai sujet en entreprise

Réussir une fois ne veut rien dire quand la tâche revient chaque semaine.

Les tâches de ce banc d'essai sont bâties sur soixante et un modèles, chacun décliné en plusieurs variantes. Sur ces soixante et un modèles, le meilleur agent en réussit toutes les variantes dans quatre cas seulement. Le modèle plus ancien testé n'y parvient dans aucun. Le plus souvent, l'agent réussit une variante et échoue sur les autres.

⚠️ Un dernier chiffre, contre-intuitif et instructif. Lorsqu'on demande à l'agent de s'arrêter s'il juge une tâche impossible, il déclare impossibles 54,9 % des tâches qui étaient faisables. Retirer cette consigne améliore le résultat global — mais il perd alors une partie de sa capacité à reconnaître ce qui l'est vraiment. Les auteurs en tirent que « des différences subtiles dans la rédaction de la consigne influencent significativement le comportement ».

⚠️ Ce que ces chiffres ne disent pas

Les deux équipes bornent elles-mêmes leur portée, et il faut le lire avant de citer les pourcentages.

Le premier banc d'essai précise que ses tâches sont « plutôt du côté simple », parce qu'elles doivent être évaluables par un programme ; qu'il n'a testé que deux architectures d'agent ; et que les tâches ont été écrites par introspection, ce qui peut les éloigner de ce qui se fait vraiment en entreprise. Le second date de 2023 et teste les modèles de son époque.

Ce qui vieillit ici, ce sont les taux. Ils montent — le classement du premier banc d'essai le montre déjà, d'une génération de modèles à la suivante. Ce qui ne vieillit pas, ce sont les formes d'échec : l'interface humaine mal franchie, la conversation dont l'implicite échappe, et le raccourci inventé quand la voie normale est bloquée.

Ce qu'une entreprise peut en tirer

Le tri des tâches ne se fait pas à l'intuition. Ce qui semble simple à un dirigeant — une relance, un tableur, un justificatif à réunir — est précisément ce que les agents ratent le plus. Ce qui semble technique passe mieux.

Une réussite ne se juge pas sur une démonstration, mais sur une répétition. La bonne question n'est pas « est-ce qu'il y arrive ? » mais « est-ce qu'il y arrive les huit fois où la tâche revient ? ».

Et l'arrêt doit être prévu, parce que l'agent ne s'arrête pas bien tout seul. Il déclare impossible ce qui ne l'est pas, ou pire, il s'arrange. Un point de validation humaine avant toute action qui engage n'est pas une prudence de principe : c'est ce que ces mesures rendent nécessaire.

Si vous voulez qu’un tel outil soit construit pour votre entreprise, c’est le sujet de notre développement sur mesure.