- Pour une même tâche sur un panneau d’administration, l’agent de vision manipulait l’interface via captures d’écran et clics, tandis que l’agent API appelait les mêmes handlers d’application avec des réponses structurées, de sorte que seule l’interface variait en termes de coût
- Avec le prompt de base, l’agent API a terminé la tâche en 8 appels, mais l’agent de vision a manqué 3 avis en attente situés sous la zone visible et n’a approuvé qu’1 avis sur 4
- Après ajout d’un parcours UI en 14 étapes, l’agent de vision a lui aussi terminé la tâche, mais l’exécution a demandé environ 14 minutes et près de 500 000 tokens d’entrée, et ce niveau d’instructions détaillées représente lui-même un coût d’ingénierie supplémentaire
- Sur l’ensemble des résultats, avec Sonnet, le parcours vision a consommé en moyenne 53 étapes, 1003 secondes et 550 976 tokens d’entrée, contre 8 appels, 19,7 secondes et 12 151 tokens d’entrée pour le parcours API, avec une variabilité de coût et de temps bien plus faible
- L’écart de coût provenait de la structure de l’interface plutôt que des performances du modèle, et si des endpoints HTTP sont générés automatiquement à partir des gestionnaires d’événements, comme avec Reflex 0.9, le calcul économique devient plus favorable à un parcours via API structurée pour les outils internes développés en direct
Objectif du benchmark et configuration de l’expérience
- Le coût a été mesuré en faisant manipuler le même panneau d’administration par un agent de vision et par une API structurée, afin de comparer les approches de type usage du navigateur / usage de l’ordinateur
- Quand une web app n’expose pas d’API, un agent IA amené à la piloter choisira facilement par défaut un agent de vision
- Dans un contexte où chaque équipe possède plus de 20 outils internes, écrire une surface MCP ou REST pour chaque application devient un projet d’ingénierie à part entière, ce qui pousse de nombreuses équipes à choisir des agents de vision
- L’application de test est un panneau d’administration pour gérer clients, commandes et avis, inspiré de la démo react-admin Posters Galore
- Les deux agents utilisaient la même application en cours d’exécution, le même Claude Sonnet, le même jeu de données fixe et la même tâche ; seule l’interface variait
- La tâche consistait à trouver, parmi les clients nommés « Smith », celui qui avait passé le plus de commandes, puis à trouver sa commande en attente la plus récente, à approuver tous les avis en attente et à marquer la commande comme expédiée
- Cette tâche touche trois ressources, et combine filtrage, pagination, consultation entre entités, lecture et écriture, ce qui ressemble à un flux de travail classique d’outil interne
Les deux parcours d’exécution
-
Parcours A : agent de vision
- Claude Sonnet utilisait browser-use 0.12 en mode vision pour manipuler l’UI via captures d’écran et clics
-
Parcours B : agent API
- Claude Sonnet appelait directement les endpoints HTTP de l’application via un mode d’usage d’outils
- Chaque outil était mappé à un ou plusieurs gestionnaires d’événements du state de l’application, c’est-à-dire les mêmes fonctions que celles invoquées par un clic sur un bouton
- L’agent recevait des réponses structurées au lieu d’une page rendue
Pourquoi l’agent de vision a échoué avec le prompt de base
- La même tâche, décrite en six phrases, a été donnée aux deux agents
- L’agent API a terminé le travail en 8 appels
- Il a listé les avis clients filtrés sur l’état en attente
- Il a approuvé chaque avis
- Il a marqué la commande comme expédiée
- Les deux agents appelaient la même logique applicative, mais l’agent API lisait directement les réponses structurées au lieu de regarder une page rendue
- Avec le même prompt, l’agent de vision n’a trouvé et approuvé qu’1 seul des 4 avis en attente avant de passer à l’étape suivante
- Les 3 avis restants se trouvaient sous la zone visible de la page des avis, et rien n’indiquait à l’agent qu’il devait faire défiler
- Cet échec venait non pas d’un problème de raisonnement du modèle, mais de l’absence de signal indiquant que la page rendue n’affichait pas l’ensemble du contenu
- L’agent API appelait les mêmes handlers que l’UI, mais la réponse incluait l’ensemble du jeu de résultats retourné par le handler, et pas seulement les lignes actuellement rendues
- Au lieu d’interpréter des contrôles de pagination dans les pixels, l’agent API lisait directement des informations comme « page 1 sur 4, avec 50 éléments par page »
Résultat après ajout d’un guide UI en 14 étapes
- Pour rendre la comparaison équitable, le prompt vision a été réécrit sous forme de parcours UI explicite
- Les éléments d’interface avec lesquels l’agent devait interagir à chaque étape — éléments de la barre latérale, onglets, champs de formulaire, etc. — ont été désignés par leur nom
- Le chemin de navigation que l’agent ne trouvait pas seul auparavant a été transformé en 14 instructions numérotées
- Une fois ce guide fourni, l’agent de vision a réussi la tâche
- En revanche, l’exécution a pris 14 minutes et consommé environ 500 000 tokens d’entrée
- Chaque instruction numérotée ne se voit pas directement dans le comptage de tokens, mais représente un coût d’ingénierie réel
- Déployer un agent de vision sur des outils internes impose donc soit d’écrire des prompts de ce niveau de détail, soit d’accepter le risque que l’agent manque silencieusement certaines tâches
Mode d’exécution et variabilité
- Le parcours API a été exécuté 5 fois, le parcours vision 3 fois
- Le parcours vision prenait 14 à 22 minutes par exécution et consommait 400 000 à 750 000 tokens, d’où la limite à 3 essais
- Le parcours vision présentait une forte variance selon les runs
- Sur 3 exécutions, le temps mur variait de 749 à 1257 secondes
- Les tokens d’entrée variaient d’environ 407 000 à 751 000
- L’exécution la plus courte a demandé 43 cycles, la plus longue 68 cycles
- La boucle capture d’écran → raisonnement → clic comporte assez de non-déterminisme pour qu’une seule exécution ne suffise pas à estimer un coût représentatif
- Le parcours API ne présentait pas cette variabilité
- Sonnet utilisait exactement 8 appels d’outils sur les 5 exécutions
- Le nombre de tokens d’entrée ne variait que de ±27 sur l’ensemble des 5 runs
- Les réponses structurées ne donnaient pas à l’agent de raison de dévier, ce qui l’amenait à appeler les mêmes handlers dans le même ordre
Résultats globaux
| Indicateur | Agent de vision (Sonnet) | API (Sonnet) | API (Haiku) |
|---|---|---|---|
| Étapes / appels | 53 ± 13 | 8 ± 0 | 8 ± 0 |
| Temps mur | 1003 s ± 254 s, soit ~17 min | 19,7 s ± 2,8 s | 7,7 s ± 0,5 s |
| Tokens d’entrée | 550 976 ± 178 849 | 12 151 ± 27 | 9 478 ± 809 |
| Tokens de sortie | 37 962 ± 10 850 | 934 ± 41 | 819 ± 52 |
- Les chiffres correspondent à moyenne ± écart-type d’échantillon (n−1) ; pour le parcours API, n=5, et pour le parcours vision, n=3
- Le détail complet des exécutions est disponible dans le dépôt
- Haiku n’a pas réussi à terminer le parcours vision
- L’échec est limité au schéma de sortie structurée de browser-use 0.12, que Haiku ne parvient pas à générer de manière fiable, ni en mode vision ni en mode texte seul
- Sur le parcours API, Haiku a terminé en moins de 8 secondes et avec moins de 10 000 tokens d’entrée, ce qui en faisait la configuration la moins coûteuse du test
Un écart de coût structurel
- La différence de coût découle directement de l’architecture
- Un agent qui doit voir pour agir paiera toujours le coût de cette vision, même si le modèle s’améliore
- Un meilleur modèle de vision peut réduire le taux d’erreur par capture d’écran, mais pas le nombre de captures nécessaires pour atteindre les données pertinentes
- Chaque rendu devient une capture d’écran, et chaque capture d’écran représente des milliers de tokens d’entrée
- Les deux agents traversent la même logique applicative
- Tous deux appliquent filtrage, pagination et mises à jour comme le fait l’UI
- La différence tient à ce qu’ils lisent à chaque étape
- L’agent de vision lit des pixels, et doit rendre puis interpréter tous les états intermédiaires
- L’agent API lit des réponses structurées issues des mêmes handlers, qui contiennent déjà les données que l’UI voulait afficher
- Un meilleur modèle peut réduire le coût par étape, mais pas le nombre d’étapes, qui est déterminé par l’interface
Ce qui change quand le coût d’ingénierie API baisse
- Ce benchmark a pu être exécuté à faible coût grâce à Reflex 0.9
- Reflex 0.9 inclut un plugin qui génère automatiquement des endpoints HTTP à partir des gestionnaires d’événements d’une application Reflex
- L’argument structurel ne dépend pas de Reflex, mais Reflex permet d’exécuter le parcours API sans codebase séparée
- Le point essentiel est ce qui devient possible quand le coût d’ingénierie d’une surface API tend vers zéro
- Les agents de vision restent adaptés aux applications que l’on ne contrôle pas directement
- Produits SaaS tiers
- Systèmes legacy
- Applications impossibles à modifier
- Pour les outils internes que l’on développe soi-même, le calcul économique s’inverse
Portée de l’expérience et points d’attention
- Les résultats vision sont limités au mode vision de browser-use 0.12 ; d’autres agents de vision peuvent se comporter différemment
- Le runner du parcours B transformait les endpoints auto-générés en une petite surface d’outils REST d’environ 30 lignes
- L’agent voyait alors des outils comme
list_customersouupdate_order - Le jeu de données est fixe et petit
- 900 clients
- 600 commandes
- 324 avis
- Le comportement sur des données à l’échelle de la production n’a pas été mesuré
- L’agent de vision a été exécuté via
ChatAnthropicde LangChain - L’agent API a été exécuté directement avec le SDK Anthropic
- Les nombres de tokens rapportés correspondent à des tokens d’entrée non mis en cache
Éléments de reproduction
- Le dépôt contient la génération des données seed, la démo react-admin patchée, les scripts des deux agents et les résultats bruts
1 commentaires
Commentaires sur Hacker News
Voici comment rendre coûteuse la navigation d’un site web par un agent : déplacer les éléments à l’écran quand la souris bouge, faire en sorte que l’UI ne fonctionne que si l’on impose un mouvement de souris « naturel », renommer aléatoirement les libellés des boutons en JavaScript à chaque visite, et obliger à scroller jusqu’en bas de l’écran pour révéler des actions cachées
Attendez, on dirait une app SaaS d’entreprise tout à fait classique
Ils n’avaient pas la volonté de faire ça pour les humains, mais comme l’IA en a besoin, tout le monde s’y met. C’est à la fois intéressant et un peu déprimant. Au fond, on dirait qu’ils ne le font pour l’IA que parce qu’ils y voient un bénéfice personnel, plus que pour quelqu’un d’abstrait dans le futur
[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
Ce n’était même pas à l’époque de l’IA générative, mais il fallait déjà combiner OCR, saisie utilisateur simulée et capture d’impression pour faire tourner l’application et exporter les données. Je ne sais pas ce que les développeurs auraient fait s’ils avaient su qu’il existait des API DRM Windows pour bloquer les captures d’écran, ou qu’on pouvait récupérer facilement du texte depuis des fichiers PostScript avec un minimum de mise en forme
Ironiquement, le processus remplacé consistait à donner à une main-d’œuvre offshore bon marché un accès distant en lecture seule à toutes les données du système, ce qui était un risque de sécurité bien plus grave que de laisser des employés autorisés automatiser le travail avec un outil local d’un fournisseur de confiance, sans accès réseau
Je suis en train de construire exactement ce qu’il faut pour résoudre ce problème[1]
Ce n’est pas encore mis en avant sur la landing page, mais en substance cela fournit aux agents un petit ensemble d’outils pour explorer la surface des apps, ainsi que les API de fonctionnalités macOS courantes, en particulier celles liées à l’accessibilité
Une fois que l’agent a exploré l’app, il peut écrire un workflow reproductible, puis l’exécuter ensuite depuis le CLI avec quelque chose comme
invoke chrome pinTabSi on utilise l’accessibilité, c’est parce qu’au fond c’est un bon DOM pour les apps. Toutes les apps ne l’implémentent pas parfaitement, mais suffisamment le font pour que ce soit très utile
[1] https://getinvoke.com - pour l’instant la landing page vise les créateurs, donc ce cas d’usage n’y apparaît pas encore
On peut voir comment les cellules vertes peuvent guider un LLM pour qu’il ne lise qu’une partie précise de l’écran, ou n’ait besoin que d’OCR, à quel point il y a déjà beaucoup de texte intégré au moteur d’accessibilité, et comment cela peut déboucher non seulement sur MCP mais aussi sur des générateurs de code capables de créer et d’exécuter des scripts qui explorent la couche d’accessibilité d’un workflow
Je pense que c’est un domaine extrêmement fertile. Les grands labos sont obligés d’utiliser des approches qui fonctionnent sur plusieurs plateformes et sur des workflows arbitraires, et la vision plein écran est le plus petit dénominateur commun. Les approches spécifiques à chaque plateforme sont un espace vraiment passionnant et encore ouvert
En revanche, il faut absolument garantir que des workflows capables d’extraire des informations utilisateur, comme des mots de passe, ne puissent pas être partagés
Le gros problème, c’est que trop d’apps exposent très mal ce type d’éléments. Mon approche consistait à utiliser UIAccess ou un passage unique d’un modèle de vision pour créer des templates d’UI : https://github.com/willwade/app-automate?tab=readme-ov-file#...
Le contre-argument formulé sur reddit est que, dans la pratique, l’expérience est presque inverse. UIA semble uniforme dans la documentation, mais WPF, WinForms et Win32 exposent tous des patterns de contrôle différents, ce qui oblige à écrire des handlers par toolkit. Qt n’expose quelque chose que si QAccessible est compilé et qu’un plugin d’accessibilité est chargé à l’exécution, ce qui arrive rarement dans les binaires distribués. Electron est tout aussi opaque sous Windows que sous macOS, car au final c’est toujours Chromium qui dessine dans un canvas. La vraie séparation n’est pas entre systèmes d’exploitation, mais entre toolkits natifs et tout le reste
Dire que rédiger une surface MCP ou REST pour chaque app constitue un projet d’ingénierie à part entière n’est pas forcément vrai si le backend est suffisamment découplé du frontend et que les opérations côté serveur ont été conçues avec soin et de manière générique
Je me demande s’il serait possible de faire « cartographier » l’UI par un agent de vision, puis d’exposer cela à d’autres agents sous la forme d’un ensemble d’interfaces qui ressemblent davantage à des API
Si je comprends bien, aujourd’hui un agent de vision doit à la fois comprendre qu’un bouton « page suivante » affiche plus de résultats, et qu’il faut aller chercher plus de résultats dès le départ
Si un agent explorait uniquement l’UI dans un environnement de test afin de produire une description un peu structurée des différents éléments d’UI et de leurs actions, puis qu’un autre agent recevait cette description, je me demande s’il ne ferait pas mieux qu’un agent qui doit à la fois explorer l’UI et accomplir la tâche
Par exemple, « récupérer tous les avis » pourrait être défini comme le fait d’aller sur chaque page puis de cliquer sur « voir l’avis complet » pour chaque résumé d’avis, tandis que « aller sur chaque page » pourrait être défini comme le fait de partir de la page 1, valeur par défaut de l’onglet des avis, puis d’appuyer sur le bouton « suivant » jusqu’à sa disparition
Le second agent pourrait alors réduire sa réflexion sur la manière d’explorer, puisqu’il disposerait déjà de cette technique, et le premier agent n’aurait à explorer l’UI qu’une seule fois dans un environnement de test, sans crainte de faire une erreur. J’ai peut-être complètement mal compris l’article, mais je trouve ça intéressant quand même
Au final, il faut se frayer un chemin dans un HTML/CSS/JavaScript extrêmement complexe. Qu’on le veuille ou non, il n’est pas rare qu’une web app pèse 5 à 10 MiB
Plutôt que d’aborder le problème « de bas en haut », presque à rebours de ce que fait le moteur du navigateur, il semble plus simple de l’aborder « de haut en bas » en observant la représentation visuelle comme le ferait un humain
Il restera toujours un peu de travail de vision pour l’exploration, mais ce sera un travail de vision simple, sans vraie réflexion
L’image→image utilise l’image entière
Je ne comprends pas bien la prémisse. S’il s’agit d’une app interne, pourquoi en venir à l’usage d’ordinateur au lieu de faire produire à l’agent un CLI ou un MCP
Bien sûr que l’usage d’ordinateur est moins bon. C’est un dernier recours. Il ne faut pas l’utiliser quand on manipule un état stocké dans une base de données qu’on possède
Je trouve plutôt impressionnant que ce ne soit que 50 fois pire
Entièrement d’accord. J’ai récemment travaillé sur des outils de vision IA et j’ai expérimenté les deux approches : la latence et le coût de l’usage générique du navigateur « à la mode agent » sont aujourd’hui rédhibitoires pour une app grand public en temps réel
Des API structurées, voire de simples chaînes d’appels LLM avec des schémas JSON stricts, sont non seulement 40 fois moins chères, mais surtout déterminantes pour pouvoir mettre en production un produit stable. L’usage d’ordinateur, c’est une démo impressionnante ; ce sont les API structurées qui paient les factures serveur
Si vous pensez qu’un LLM est adapté à une tâche, alors construisez sur Openrouter un middleware bien défini et hautement déterministe, conçu pour cet objectif
Les API structurées exigent une vraie réflexion, et de nos jours réfléchir n’est pas très bien vu
Il y a quelques mois, j’ai créé un CLI desktopctl pour piloter des applications GUI, inspiré de
kubectlSur Mac, il combine OCR et Accessibility API pour représenter l’UI en Markdown et exposer les actions de souris et de clavier
L’idée centrale, c’est que la boucle de perception « rapide » est entièrement locale, optimisée GPU pour la tokenisation de l’UI et la détection des changements, tandis que la boucle de contrôle « lente » nécessite des allers-retours avec un LLM et utilise une interface Markdown économe en tokens pour la sortie CLI
Les contrôles utilisent des identifiants relativement stables, ce qui permet à l’agent de scripter des actions génériques comme
desktopctl pointer click --id btn_savesans avoir besoin de la boucle de tokenisation de l’UIhttps://github.com/yaroshevych/desktopctl/tree/main
Les bonnes apps rendent bien l’information visible et sont optimisées pour les clics, la saisie, etc.
Les meilleures GUI exploitent très bien la mémoire musculaire, ce qui en fait des candidates parfaites pour être scriptées via CLI. Par exemple, une séquence simple comme « ouvrir l’app Notes, appuyer sur Cmd+F, taper un terme de recherche, lire la liste des résultats » peut devenir une unique commande Bash invoquée par un agent IA
Le concept même d’« usage d’ordinateur » me laisse toujours sceptique. C’est un peu comme embaucher quelqu’un, le faire entrer chez soi, puis lui dire qu’il peut dormir dans votre lit, utiliser vos toilettes, manger ce qu’il y a dans le frigo, regarder la télé, et qu’au fait le code du coffre est aussi ici
Sauf que cette personne embauchée est en fait un singe
Les sites web qui tentent actuellement de bloquer Claude Code ou d’autres agents IA mènent un combat perdu d’avance
L’usage d’ordinateur en est encore à ses débuts, et ce qui freine son adoption grand public semble être le nombre de tokens nécessaires. Si un agent tâtonne avec 10 commandes CLI avant de trouver la bonne, cela nous importe à peine
Mais avec des agents visuels comme l’usage du navigateur ou de l’ordinateur, même s’ils finissent par atteindre le bon endroit, personne n’a la patience d’attendre 20 minutes pour un simple clic sur un bouton. Si les tokens deviennent plus rapides et moins chers, il y a de fortes chances qu’on voie apparaître des modèles capables d’utiliser des interfaces UI avec autant d’aisance qu’un CLI