WorkArena : comment les agents Web LLM se comportent face au travail de connaissance réel en entreprise

Après avoir lu l'évaluation de τ-bench sur les agents d'appel d'outils dans les domaines de la vente au détail et de l'aérien, j'ai voulu explorer les logiciels d'entreprise — le territoire où les agents de type Beancount doivent réellement opérer. WorkArena (Drouin et al., ServiceNow Research, 2024) évalue les agents Web LLM sur 33 tâches réelles au sein de la plateforme d'entreprise ServiceNow, ce qui en fait le test existant le plus direct pour déterminer si les modèles actuels peuvent automatiser de véritables flux de travail de connaissance plutôt que des scénarios théoriques simplifiés.

L'article

"WorkArena: How Capable Are Web Agents at Solving Common Knowledge Work Tasks?" présente un benchmark de 33 tâches et 19 912 instances uniques tirées de la plateforme logicielle d'entreprise ServiceNow. Les tâches couvrent six catégories que les travailleurs de la connaissance effectuent réellement au quotidien : filtrage et tri de listes, remplissage de formulaires, recherche dans des bases de connaissances, commande dans des catalogues de services, lecture de tableaux de bord et navigation dans les menus. En plus du benchmark, les auteurs publient BrowserGym, un environnement d'évaluation qui fournit aux agents des observations multimodales riches — HTML, arbres d'accessibilité, captures d'écran — ainsi qu'un espace d'action standardisé pour les interactions Web.

La question centrale posée par l'article est de savoir si les LLM actuels peuvent gérer les flux de travail structurés, en plusieurs étapes et contraints par l'interface utilisateur (UI) qu'exigent les logiciels d'entreprise réels. Il ne s'agit pas de tâches de recherche ouvertes ou de questions-réponses en un seul tour ; ce sont des séquences dirigées d'actions (clics, saisies de formulaires, opérations de filtrage) qui laissent des traces vérifiables dans un système en direct. Cette propriété de vérification par l'état du système est ce qui rend WorkArena significativement différent de la plupart des benchmarks d'agents, et c'est exactement la propriété qu'un agent d'écriture Beancount devrait satisfaire.

Idées clés

• GPT-4o atteint 42,7 % globalement sur WorkArena avec un prompt en chaîne de pensée (chain-of-thought) ; GPT-3.5-Turbo ne parvient qu'à 6,1 %, et le modèle open-source Llama3-70B-Instruct se situe à 17,9 % — un écart de 25 points entre les modèles propriétaires de pointe et les modèles open-source de pointe.
• Les tâches de filtrage de liste constituent un mur infranchissable : 0 % pour chaque modèle. Le widget de liste de ServiceNow utilise un HTML non standard avec lequel aucun des agents testés n'a pu interagir de manière fiable. Le tri n'est guère meilleur : GPT-4o n'obtient que 10 % sur les tâches de tri de liste.
• Les tâches de catalogue de services sont étonnamment abordables : GPT-4o atteint 77,8 % sur les neuf tâches de catalogue de services, où l'interface utilisateur est plus conventionnelle et où les actions requises correspondent étroitement aux schémas de remplissage de formulaires que le modèle a probablement rencontrés lors de son entraînement.
• Les observations multimodales n'aident pratiquement pas. L'ajout de captures d'écran aux observations de GPT-4o n'a produit que des « améliorations de performance très mineures », suggérant que le goulot d'étranglement réside dans la compréhension de la structure de l'interface utilisateur, et non dans l'absence d'entrée visuelle.
• La chaîne de pensée est un pilier essentiel. Sa suppression fait chuter Llama3-70B d'environ 10 points sur WorkArena, confirmant que les tâches Web en plusieurs étapes nécessitent un raisonnement intermédiaire explicite, et pas seulement une prédiction d'action.
• Les mécanismes de mémoire ont eu l'effet inverse. L'activation d'un indicateur use_think_history a poussé les agents à « s'en tenir à des décisions prises lors des premières étapes, même erronées » — un exemple concret de rigidité de l'engagement se faisant passer pour de la planification.

Ce qui tient la route — et ce qui ne la tient pas

La propriété la plus précieuse du benchmark est qu'il s'exécute sur une instance ServiceNow en direct : le succès est déterminé par le fait que l'état du système a réellement été modifié correctement, et non par une comparaison de chaînes de caractères avec une sortie attendue. Cela rend le score de 0 % sur les tâches de filtrage de liste particulièrement accablant — il n'y a nulle part où se cacher. La variété des tâches est également véritablement représentative : les six catégories couvrent l'étendue de ce sur quoi les travailleurs de la connaissance passent du temps, et non des tâches d'exposition choisies arbitrairement.

Ce que je trouve moins satisfaisant, c'est le traitement des modes d'échec. L'article identifie que les structures HTML exotiques, les iFrames imbriquées et les DOM fantômes (shadow DOMs) perturbent les agents, mais il ne procède pas à une ablation systématique des caractéristiques structurelles responsables ou de leur proportion. Le problème de la taille du DOM — des arbres HTML allant de 40 000 à 500 000 jetons — est mentionné mais n'est pas analysé en profondeur : nous ne savons pas si la synthèse, le découpage en morceaux (chunking) ou les observations limitées à l'arbre d'accessibilité permettraient de retrouver des performances. L'architecture à agent unique n'est jamais non plus comparée à une configuration multi-agents décomposée (une séparation sélecteur/exécuteur, par exemple), de sorte qu'il n'est pas clair si le résultat de 0 % en filtrage de liste est un problème d'interface, un problème de planification, ou les deux.

Une question sur la validité de la plateforme mérite également d'être soulevée. ServiceNow est une pile logicielle d'entreprise spécifique avec des modèles d'interface utilisateur idiosyncrasiques. Les résultats nous en disent beaucoup sur les agents ServiceNow et un peu moins sur les agents Web d'entreprise en général. Généraliser l'échec du filtrage de liste à, disons, une interface beanquery ou un outil de feuille de calcul nécessite des preuves indépendantes.

Pourquoi c'est important pour l'IA financière

Les résultats de WorkArena sont un point d'étalonnage sur lequel je reviens sans cesse pour le programme d'automatisation de Beancount. Le schéma d'échec est instructif : les agents réussissent bien les tâches qui ressemblent à des formulaires Web (catalogue de services, 77,8 %) et s'effondrent sur les tâches qui nécessitent une interaction précise avec des widgets d'interface utilisateur structurés et non standard (filtrage de liste, 0 %). Un agent Beancount effectuant la saisie du grand livre ferait face à un tableau contrasté : la partie passage du langage naturel à la transaction ressemble aux tâches de remplissage de formulaires où les performances sont raisonnables ; mais les parties de requête, de filtrage et de rapprochement — trouver des entrées spécifiques, trier par date, appliquer des filtres de compte — ressemblent beaucoup plus aux tâches de liste où tout échoue.

L'article renforce également une leçon tirée des journaux de CRITIC et Reflexion : la vérification externe importe plus que le raisonnement interne. Les tâches WorkArena réussissent ou échouent en fonction de l'état du système, et cette vérité de terrain propre est ce qui rend le benchmark honnête. Pour les agents d'écriture Beancount, cela plaide fortement en faveur d'une conception où chaque modification de registre validée est vérifiée par rapport à l'API Python de Beancount avant d'être acceptée, et pas seulement vérifiée par le propre raisonnement de l'agent. Le plafond de 42,7 % sur le meilleur modèle à l'ICML 2024 suggère que même pour les tâches classiques d'interface utilisateur d'entreprise, l'écart entre « occasionnellement utile » et « fiable pour l'automatisation » est encore grand.

Que lire ensuite

• WorkArena++ (arXiv:2407.05291, NeurIPS 2024) — la suite de la même équipe ServiceNow avec 682 tâches compositionnelles nécessitant planification, raisonnement arithmétique et recherche de documents multiples ; répond directement à la question de savoir si l'augmentation de la complexité des tâches expose de nouveaux modes d'échec au-delà du mur de l'interaction UI.
• WebArena (arXiv:2307.13854, ICLR 2024) — le benchmark compagnon pour agents Web à usage général (812 tâches couvrant le e-commerce, les forums, l'hébergement de code, les CMS) où GPT-4 n'atteint que 14,41 % contre 78 % de performance humaine ; place les chiffres de WorkArena dans le paysage plus large des agents Web.
• OSWorld (arXiv:2404.07972, NeurIPS 2024) — étend l'évaluation de l'automatisation d'entreprise aux environnements de bureau complets, y compris les applications réelles (LibreOffice, VS Code, Chrome) ; le test le plus complet pour déterminer si les modes d'échec de WorkArena sont spécifiques à l'interface utilisateur ou reflètent un déficit de compétence plus profond des agents.