Agents’ Last Exam : ce que mesure un agent de travail réel et pourquoi son taux de réussite ne signifie pas « automatiser un emploi »

Quel problème Agents’ Last Exam cherche à résoudre

Les benchmarks d’agents simplifient souvent le travail professionnel afin de pouvoir le mesurer : une question avec une réponse, une modification de code dans un dépôt, ou une action isolée dans une interface. Cette simplification peut être nécessaire, mais elle laisse de côté une part importante des flux de travail réels : préparer des fichiers, examiner des informations locales, utiliser plusieurs applications, produire un artefact et laisser un état final qu’une autre personne peut vérifier.

Agents’ Last Exam, généralement abrégé en ALE, se présente comme un cadre d’évaluation d’agents qui exécutent de longues tâches professionnelles dans des environnements de système d’exploitation isolés. La documentation décrit une unité composée d’un agent, d’une tâche et d’un environnement sandbox. La tâche n’est pas seulement une instruction textuelle : elle comprend également un état initial et un mécanisme permettant d’évaluer le résultat produit après l’exécution.

Le changement d’unité de mesure est important. Au lieu de demander uniquement si un modèle connaît une procédure, ALE cherche à observer si une configuration précise parvient à terminer une tâche dans des conditions opérationnelles définies. Cette configuration inclut, au minimum, le modèle, la boucle de l’agent, les outils mis à sa disposition, l’environnement, les contraintes d’exécution et l’évaluateur. Le résultat appartient donc à une exécution configurée, et non à un modèle considéré comme une capacité abstraite.

Cela peut rapprocher ALE d’un test de flux de travail davantage qu’une évaluation de compétence isolée. Toutefois, « plus proche » ne veut pas dire équivalent à la pratique professionnelle. Un emploi combine des tâches non couvertes, des priorités changeantes, une coordination humaine, des responsabilités, l’accès à des systèmes internes, des politiques de sécurité et des conséquences économiques. Une évaluation en sandbox peut fournir des éléments de preuve sur les performances à l’intérieur de ce sandbox, sans mesurer directement tous ces éléments.

L’unité réelle d’évaluation : tâche, environnement, harness et budget

Pour interpréter un résultat, il faut reconstituer ce qui a été exécuté. La tâche définit l’objectif et l’état initial. L’environnement sandbox contient les fichiers, applications, données et restrictions avec lesquels l’agent peut interagir. L’agent décide de ses actions au moyen d’un harness, qui relie le modèle à des outils tels qu’un terminal, une interface graphique, la navigation ou la lecture et l’écriture de fichiers. Enfin, un grader examine le résultat suivant des critères définis pour la tâche.

Chaque composant peut modifier le résultat. Une tâche qui paraît identique peut être plus simple si l’environnement comprend un utilitaire préinstallé, des identifiants, une documentation locale ou des données déjà normalisées. Le résultat peut aussi changer si l’agent reçoit des captures d’écran, des informations d’accessibilité structurées, des commandes de terminal, un navigateur automatisé ou une combinaison de ces moyens. Comparer deux pourcentages sans connaître ces conditions peut attribuer au modèle une différence qui provient en réalité du harness ou du sandbox.

Le budget fait également partie de l’expérience. La limite de temps, le nombre maximal d’étapes, le coût autorisé, la longueur de contexte, les tentatives supplémentaires et la politique appliquée aux erreurs transitoires modifient la probabilité d’aboutir. Un agent qui requiert de nombreuses interactions peut obtenir un résultat élevé avec un budget généreux, tout en étant non viable lorsque la latence ou le coût sont limités. Inversement, une contrainte très stricte peut masquer une stratégie qui fonctionnerait dans un processus asynchrone.

Le dépôt officiel inclut du code, des tâches publiques et une infrastructure d’exécution, tandis que la documentation technique explique le cycle de création et d’évaluation des tâches. C’est une base utile pour auditer des configurations, mais la reproductibilité pratique exige d’enregistrer les versions exactes, les paramètres, les images ou dépendances de l’environnement, ainsi que les résultats de chaque répétition. L’existence de code ne garantit pas que toute exécution historique puisse être reproduite sans ces éléments.

Couverture professionnelle : 13 clusters et 55 sous-domaines ne signifient pas 13 secteurs automatisés

Les documents du projet décrivent une couverture de 55 sous-domaines regroupés en 13 clusters et relient leur taxonomie à O*NET et SOC 2018. Ce choix sert à organiser des tâches professionnelles hétérogènes et à montrer que l’évaluation ne se limite pas à la programmation ou à une seule application de bureau. Il permet aussi de demander quels domaines sont représentés et lesquels le sont peu.

La taxonomie professionnelle ne transforme toutefois pas automatiquement une collection de tâches en mesure des professions. O*NET classe et décrit les professions, les connaissances, les compétences, les activités et d’autres attributs du travail ; un poste réel rassemble de multiples tâches, de fréquence, de criticité et de dépendance au contexte différentes. Une tâche sélectionnée dans un sous-domaine peut représenter une opération concrète sans représenter l’ensemble de l’emploi associé.

Il ne faut pas non plus inférer une couverture proportionnelle. Le fait qu’un cluster existe ne révèle ni le nombre de tâches qu’il contient, ni la variété interne couverte, ni la difficulté de ses cas, ni leur poids économique. Pour évaluer son propre cas d’usage, la bonne question n’est pas de savoir si son secteur figure dans l’étiquette, mais si l’ensemble comprend des entrées, outils, exceptions et critères de qualité comparables à ceux de son processus.

Le lien avec O*NET peut aider à assurer une traçabilité conceptuelle. Il permet de discuter des activités que l’on a cherché à approcher et des lacunes restantes. Mais une classification professionnelle ne fournit pas à elle seule un taux d’automatisation, une prévision salariale ou une estimation de réduction des effectifs. De telles conclusions exigeraient des données supplémentaires sur l’adoption, la refonte des processus, la supervision, les coûts et des performances soutenues.

Réussite complète, crédit partiel et références cachées

La page de résultats distingue le Pass Rate et le Score. Selon cette définition, le Pass Rate correspond à la proportion d’exécutions qui obtiennent un score parfait, tandis que le Score résume le crédit partiel moyen. Les deux métriques répondent à des questions différentes. La première exige que le résultat satisfasse pleinement au critère de la tâche ; la seconde peut indiquer qu’un agent a progressé partiellement sans livrer un résultat entièrement valide.

Le crédit partiel est informatif, notamment pour diagnostiquer les points de défaillance des agents. Il peut signaler que des fichiers corrects ont été créés mais qu’une vérification manque, qu’une partie de la procédure a été réalisée ou que le résultat final s’approche de ce qui était attendu. Il ne faut cependant pas le présenter comme une réussite opérationnelle si le cas d’usage exige une livraison complète. Lors d’une clôture financière, d’une migration de données ou d’une mise à jour de conformité, une solution partiellement correcte peut être inutile, voire introduire un risque.

La documentation sur la création des tâches explique que la référence employée pour l’évaluation reste cachée et est matérialisée au moment de l’évaluation. Le grader exécute une fonction d’évaluation qui renvoie un score, habituellement compris entre zéro et un. Cette conception cherche à empêcher l’agent d’obtenir directement la solution de référence disponible pour l’évaluateur et permet d’appliquer des contrôles déterministes sur des artefacts ou des états finaux.

Le caractère déterministe du grader n’élimine pas toutes les décisions de mesure. Il faut définir quelles propriétés sont vérifiées, quelle tolérance est admise et quel résultat mérite un crédit partiel. Un grader peut être cohérent lorsqu’il répète la même entrée, tout en ne mesurant que les conditions qui ont été formalisées. La validité du score dépend autant de cette définition que de la capacité de l’agent à exécuter des actions.

CLI, GUI et le problème de la comparaison entre agents différents

ALE envisage des interactions par interface en ligne de commande, interface graphique et configurations pouvant combiner les deux. La modalité importe, car elle détermine les observations et les actions disponibles. Dans un terminal, l’agent peut examiner des structures de fichiers, lancer des commandes et automatiser des transformations de manière compacte. Dans une interface graphique, il doit percevoir l’état visuel, localiser les contrôles et gérer les changements de focus, les fenêtres, les temps de chargement ou les éléments ambigus.

Le leaderboard identifie des sous-ensembles, dont ALE-CLI. Ce sous-ensemble peut servir à étudier des agents orientés terminal, mais il ne doit pas être considéré comme une version numériquement interchangeable de l’évaluation complète. Un score CLI exclut ou réduit certains aspects de l’interaction graphique ; un score combiné impose une exigence différente. La comparaison n’est défendable que si le jeu de tâches, les règles, l’environnement et la métrique coïncident, ou si les différences sont déclarées explicitement.

Un agent généraliste de computer use ne se définit pas seulement par sa capacité à manipuler un curseur. Du point de vue de l’évaluation, il importe de savoir s’il peut observer l’état pertinent, sélectionner des outils, conserver le contexte d’une tâche longue, se remettre de résultats inattendus et vérifier son propre travail. Un harness qui ajoute des outils spécialisés peut améliorer les performances, mais le résultat évalue alors le système formé par le modèle et les outils, et non uniquement la politique du modèle.

Cette précaution vaut également face à Terminal-Bench, OSWorld-Verified et SWE-Bench Verified. Chaque benchmark pose une question différente et utilise ses propres tâches, environnements et méthodes de vérification. Terminal-Bench se concentre sur les tâches de terminal ; OSWorld-Verified étudie l’interaction avec des environnements de bureau vérifiés ; SWE-Bench Verified vise la résolution d’incidents logiciels. Aucun résultat ne se transforme automatiquement en un autre parce qu’un modèle ou une étiquette d’agent est partagé.

Comment lire un leaderboard ou une annonce de fournisseur

Un leaderboard fournit une photographie utile, non une garantie indépendante de déploiement. Avant d’accepter un chiffre, il convient de vérifier si la version d’ALE, le sous-ensemble, le nombre de tâches évaluées, la métrique et la méthode d’agrégation sont indiqués. L’identité précise du modèle et du harness, les outils, les limites d’exécution et la politique appliquée aux tentatives supplémentaires, aux défaillances d’infrastructure ou aux exécutions incomplètes devraient également être disponibles.

Le taux de réussite requiert un dénominateur clair. Évaluer toutes les tâches disponibles n’est pas la même chose qu’exécuter une sélection, omettre des cas présentant des dépendances non résolues ou ne publier que les exécutions réussies. S’il existe plusieurs répétitions par tâche, il faut indiquer si le résultat utilise la moyenne, la meilleure tentative, la première tentative ou une autre règle. Choisir la meilleure de plusieurs tentatives peut répondre à une question de capacité maximale, mais ne mesure pas la fiabilité d’une exécution unique.

Il faut aussi distinguer les faits observés de leur interprétation. Un fait est qu’une configuration a obtenu une métrique déterminée selon des règles publiées. Une interprétation possible est que l’agent semble particulièrement adapté à un certain type de tâches. La seconde formulation exige d’examiner les résultats désagrégés, les échecs et la similarité avec le flux cible ; elle ne découle pas d’un seul chiffre global.

La condition de benchmark vivant ajoute une autre précaution. Si les tâches, le corpus public, l’environnement ou les graders changent, un chiffre à une date donnée peut ne plus être comparable à un chiffre ultérieur. Le projet documente le caractère vivant d’ALE et l’existence d’un corpus public. Pour les résultats longitudinaux, la version et la date ne sont pas des détails éditoriaux : elles font partie du sens de la donnée.

Limites d’ALE et tests manquants avant la production

ALE ne démontre pas qu’un système est sûr ou fiable dans une organisation donnée. Un sandbox réduit le périmètre et permet de vérifier des états finaux, mais il ne reproduit pas nécessairement les identités d’entreprise, les données sensibles, les permissions historiques, les intégrations instables, les exigences d’audit ou les effets sur les clients. L’absence d’accès à des systèmes réels peut être délibérée et souhaitable afin de mesurer de façon contrôlée, tout en limitant l’extrapolation.

Le benchmark ne résout pas non plus, à lui seul, le risque d’optimisation sur le test. La disponibilité de tâches publiques et de code facilite l’audit et la recherche, mais elle peut permettre à des modèles, prompts ou outils de s’adapter aux régularités de l’ensemble. Les références cachées et les graders réduisent une forme précise de fuite des réponses ; ils ne démontrent pas l’absence de contamination des données d’entraînement, de familiarité avec des motifs de tâches ou d’optimisation indirecte. Les éléments disponibles ne permettent pas, à eux seuls, de quantifier ce risque pour chaque modèle.

La représentativité constitue une autre limite. Les tâches sont sélectionnées et formalisées ; les processus réels comportent des ambiguïtés, des exceptions, des objectifs contradictoires et des standards de qualité qui peuvent évoluer pendant le travail. Un bon résultat est un élément de preuve indiquant que l’agent a satisfait aux critères établis dans les tâches sélectionnées. Conclure qu’il fonctionne dans un processus donné exige une évaluation locale avec des données, contrôles et erreurs pertinents pour ce processus.

Enfin, la métrique ne calcule pas la valeur économique. La décision de déployer dépend du temps de supervision, des taux de correction, de la gravité des erreurs, du coût de l’inférence et de l’infrastructure, de la vitesse, de la traçabilité, de la confidentialité et de la responsabilité. Dans certains cas, des performances modestes peuvent être utiles avec une révision humaine ; dans d’autres, un taux élevé reste insuffisant parce qu’une erreur isolée a des conséquences graves.

Liste de contrôle pour un cas d’usage propre

L’utilité d’ALE augmente lorsqu’il est employé comme filtre plutôt que comme verdict final. Si un agent obtient de bons résultats sur des tâches proches d’un flux propre, il y a une raison de concevoir un test interne ; s’il ne les obtient pas, cela peut signaler un risque ou une différence de configuration à examiner. Dans les deux cas, le transfert doit être démontré, et non présumé.

Le test interne devrait recueillir des exemples représentatifs, y compris des cas normaux, des cas rares et des échecs récupérables. Il doit évaluer à la fois l’artefact final et le parcours lorsque le processus requiert de la traçabilité. Il doit aussi définir à quel moment une personne intervient, quelles actions sont interdites, comment les modifications sont annulées et quelles métriques établissent que le système est utile sans augmenter le risque au-delà du seuil acceptable.

La conclusion la plus responsable n’est pas une proclamation d’autonomie générale, mais une affirmation délimitée : une configuration donnée peut terminer une proportion observée de tâches d’un ensemble connu dans des conditions publiées. ALE aide à formuler cette affirmation avec plus d’exigence qu’un exemple isolé. Il ne remplace pas la validation technique, opérationnelle et organisationnelle nécessaire pour automatiser une partie d’un processus réel.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.