L'illusion des benchmarks GUI : ce que les scores à 90% ne racontent pas

Voici une expérience simple à tester. Prenez un agent GUI dernier cri, pointez-le sur un site que vous connaissez bien, puis réglez le zoom de votre navigateur à 70%. Le layout est identique. Les boutons sont aux mêmes endroits. Le texte est simplement... plus petit.

Le modèle va probablement échouer.

Ce n'est pas un cas limite. C'est un aperçu d'un décalage fondamental entre ce que les benchmarks AI mesurent et ce dont les AI en production ont réellement besoin. Et comprendre ce fossé compte — que vous construisiez un assistant de navigation AI, un scraper web autonome, ou la prochaine génération d'agents computer-use.

L'illusion du benchmark

Soyons clairs sur ce que ces chiffres signifient réellement. Les modèles GUI modernes atteignent maintenant 90%+ de précision sur des benchmarks comme ScreenSpot-v2. Pour un développeur qui évalue ses options, c'est un chiffre facile à lire comme « ce problème est résolu, la perception n'est plus le goulot d'étranglement ».

Le problème, c'est ce que ces chiffres ne capturent pas.

ScreenSpot-v2, comme la plupart des benchmarks GUI, teste les modèles sur des screenshots figés. La même page, rendue de la même façon, à chaque fois. Les vrais sites web ne fonctionnent pas comme ça. Les utilisateurs zooment ou dézooment. Les équipes déploient des redesigns. Le mode sombre change les relations de couleurs. Différents navigateurs rendent le même CSS légèrement différemment.

Le modèle n'a pas appris à gérer la variation — il a appris à reconnaître des screenshots spécifiques. Ces scores élevés mesurent la capacité de mémorisation, pas une véritable compréhension visuelle.

Les chercheurs derrière GUI-Perturbed (de chez Fig, Inc.) ont cherché à quantifier exactement combien de cette performance de benchmark survit au contact d'une variation ordinaire. Leur approche : perturber systématiquement les scènes visuelles le long d'axes contrôlés et mesurer la chute de précision. Ce qu'ils ont trouvé devrait mettre mal à l'aise quiconque construit des systèmes computer-use en production.

Le problème du triple alignement

Avant de plonger dans les résultats, parlons de ce que le GUI grounding exige réellement. Quand un modèle voit un screenshot et une commande comme « clique sur le bouton submit », trois types d'alignement différents doivent se produire simultanément :

L'alignement visuel est ce que ça suggère — faire correspondre des motifs de pixels aux éléments d'interface. Le bouton a une forme, une couleur et une taille particulière que le modèle doit reconnaître.

L'alignement fonctionnel signifie comprendre ce que l'élément fait réellement. Un champ de saisie diffère visuellement d'un label d'affichage, et un bouton cliquable diffère d'une icône statique, même s'ils partagent des caractéristiques visuelles.

L'alignement géométrique résout les relations spatiales. « Le bouton au-dessus de la barre de recherche » ou « le champ de formulaire à droite du label » exige de comprendre où sont les choses relativement les unes aux autres, pas juste à quoi elles ressemblent.

Voici la partie inconfortable : la plupart des benchmarks mélange tout ça. Quand un modèle score 85%, impossible de savoir s'il a réussi les trois ou s'il a cartonné le visuel tout en devinant complètement la géométrie. Ça compte parce que les modes d'échec sont différents, et les correctifs aussi.

Là où les modèles cassent réellement

La méthodologie GUI-Perturbed stress-teste chaque axe d'alignement indépendamment. Les résultats révèlent une hiérarchie de fragilité :

1. Les instructions spatiales sont catastrophiquement faibles

C'est le point majeur. Quand les instructions passent de « clique sur le bouton submit » à « clique sur le bouton au-dessus du formulaire de contact », la précision chute de 27 à 56 points selon le modèle. Une chute de 27 points est préoccupante. Une chute de 56 points est disqualifiante pour tout usage en production.

Le modèle peut identifier un bouton spécifique quand il est nommé directement. Demandez-lui de raisonner sur où ce bouton se trouve dans l'espace, et la performance s'effondre.

C'est particulièrement problématique parce que les instructions en langage naturel incluent souvent des références spatiales. « Défile vers le bas et clique sur le formulaire » ou « sélectionne l'option sous l'en-tête » sont des façons intuitives pour les humains de décrire des tâches. Elles cassent les modèles actuels presque immédiatement.

2. Les perturbations visuelles mordent fort

L'expérience du zoom n'est pas un cas isolé. Changer le zoom du navigateur à 70% fait chuter la précision de 2 à 6 points sur les trois modèles testés. Ce n'est pas catastrophique, mais considérez ce que ça implique : le modèle a appris à reconnaître les éléments à une échelle particulière, et les changements d'échelle cassent cette calibration.

Les vrais utilisateurs zooment. Différents moniteurs ont des paramètres DPI par défaut différents. Les applications web rendent à différentes tailles physiques selon l'appareil. Ce sont des événements quotidiens, pas des conditions adverses.

L'implication plus troublante est ce que cela nous dit sur la façon dont les modèles apprennent. Ils ne construisent pas de représentations invariantes à l'échelle comme les humains — ils mémorisent l'apparence aux résolutions de l'entraînement.

3. Le raisonnement chain-of-thought a des compromis

Ajouter une étape de raisonnement avant d'agir aide sur les tâches relationnelles difficiles mais nuit réellement à la performance sur les tâches directes simples. Le modèle a besoin de savoir quand réfléchir et quand agir.

Cela crée un problème pratique de déploiement. Vous ne pouvez pas simplement activer le chain-of-thought partout ; vous avez besoin soit d'un routeur qui décide quand penser, soit d'un modèle qui est réellement bon dans les deux modes. Les modèles actuels semblent trop réfléchir sur les tâches simples.

Ce que le post-training achète réellement

Voici la découverte la plus sobre : un post-training plus spécialisé GUI ne résout aucun de ces problèmes.

Les trois modèles testés partagent le même checkpoint de base mais ont traversé différentes quantités de fine-tuning spécifique GUI. L'entraînement supplémentaire a augmenté les scores de benchmark sur scènes fixes. Il n'a pas amélioré la robustesse aux perturbations visuelles, au raisonnement spatial, ni à la sensibilité au zoom.

Cela signifie que les gains de benchmark du post-training peuvent être partiellement illusoires — les modèles s'améliorent sur la distribution du test, pas sur la tâche sous-jacente. Ils adaptent le benchmark plus précisément sans construire de capacités généralisables.

Pour les équipes qui évaluent des modèles ou qui construisent dessus, c'est une distinction critique. « Atteint 92% sur ScreenSpot-v2 » vous dit que le modèle peut reconnaître des éléments GUI dans des screenshots. Ça ne vous dit rien sur sa capacité à gérer la variabilité de la vraie navigation web.

Implications pour les builders

Si vous construisez des applications par-dessus des agents computer-use, quelques choses découlent de cette recherche :

Votre environnement de production sera plus difficile que votre environnement d'évaluation. Si vous testez contre un ensemble fixe de pages, vous ne mesurez pas comment le système performera en production. Considérez intégrer des tests de perturbation dans votre pipeline d'évaluation — essayez vos tâches à différents niveaux de zoom, avec des variations CSS, sur des pages redesignées.

La gestion des instructions spatiales nécessite une attention particulière. Si votre application utilise des instructions en langage naturel qui incluent des références spatiales, les modèles généralistes actuels auront du mal. Cela pourrait signifier contraindre les formats d'instruction, ajouter des chemins de repli avec prédiction explicite de coordonnées, ou utiliser des modèles spécialisés pour les sous-tâches de raisonnement spatial.

Surveillez les casses de redesign. Quand les sites cibles changent leurs layouts, la précision de votre agent peut chuter soudainement — non pas parce que le modèle s'est dégradé, mais parce qu'il a rencontré une configuration visuelle qu'il n'avait pas vue auparavant. Pensez à cacher les stratégies de localisation d'éléments et à surveiller les dérives.

La route à suivre

Cette recherche ne signifie pas que les agents computer-use sont inutiles. Elle signifie que le domaine a besoin de meilleures façons de mesurer ce qui compte réellement : la robustesse, pas la performance de benchmark.

La bonne nouvelle, c'est que les problèmes sont maintenant visibles et mesurables. La méthodologie GUI-Perturbed fournit un moyen de stress-tester les modèles le long d'axes spécifiques. Si vous construisez ou achetez ces systèmes, demandez à voir des résultats d'évaluation résistant aux perturbations, pas juste des scores de benchmark statiques.

Le problème du triple alignement — compréhension visuelle, fonctionnelle et géométrique travaillant ensemble — est réel. Il est traçable. Et le résoudre débloquera la prochaine génération d'agents AI fiables qui travaillent vraiment dans le monde messager et variable où vivent vos utilisateurs.

Pour l'instant, treat ces scores de benchmark à 90%+ comme un point de départ, pas une ligne d'arrivée. Vos utilisateurs vous remercieront quand leur assistant AI gérera parfaitement un navigateur zoomé.