Computer use ou Playwright pour tester une interface

De combien de façons un agent peut-il voir une interface ?

Quand un agent de codage modifie une interface, le travail n’est pas fini : il doit voir que le changement fonctionne vraiment. Nous avons décrit cette boucle, où l’agent vérifie son propre travail, dans l’article sur le harness engineering. Pour une interface, il y a trois façons de faire cette vérification, et les outils de codage les proposent toutes les trois dès aujourd’hui :

Avec computer use, l’agent voit l’écran comme une image et travaille à la souris et au clavier. L’outil d’Anthropic fournit des captures d’écran et le contrôle de la souris et du clavier. La documentation de Google écrit elle aussi que le modèle « voit » l’écran à travers des images et produit des actions comme des clics et des frappes au clavier. Cette voie atteint tout ce qui est à l’écran : l’outil de Google fonctionne dans le navigateur, sur mobile et sur ordinateur.

Avec browser use, l’agent ne regarde pas l’image de la page mais sa structure. L’outil browser use d’Anthropic lit la page dans l’arbre d’accessibilité : chaque élément arrive avec son rôle, son nom et une référence comme [ref_2], et pour cliquer, l’agent donne cette référence au lieu de coordonnées. Là où l’arbre ne voit rien, dans un canvas par exemple, il revient aux captures d’écran et aux coordonnées. Playwright MCP lit lui aussi la page dans cet arbre plutôt que dans des captures d’écran. La bibliothèque open source Browser Use, qui sort dans les résultats de recherche, est un projet distinct ; dans cet article, « browser use » désigne cette méthode.

Sur la voie code et tests, l’agent pilote le navigateur par une bibliothèque : il écrit un test Playwright ou appelle la CLI de Playwright. Playwright CLI ne charge pas les données de la page dans le modèle ; l’agent ne lit que la sortie de la commande. Le guide computer use d’OpenAI recommande lui aussi la voie du code pour GPT-6 Astra : le modèle écrit du code Playwright ou PyAutoGUI qui pilote l’interface, et l’outil structuré computer reste une alternative. Ce qui distingue vraiment le code, c’est qu’une fois écrit, il peut tourner à nouveau sans modèle.

Combien coûte chaque voie, et quelle est sa fiabilité ?

Nous avons comparé les trois voies sur trois questions : combien de tokens coûte une étape, combien de temps dure une tâche, et à quelle fréquence une tâche est menée de bout en bout. La plupart des chiffres viennent de la documentation des fournisseurs ; pour les résultats de benchmark, nous indiquons qui les a publiés.

Un agent qui travaille à partir de l’écran lit une capture à chaque étape, et les images sont facturées en tokens. Les trois fournisseurs ne comptent pas de la même façon : Anthropic découpe l’image en carrés de 28 pixels, OpenAI en carrés de 32 pixels, tandis que Google utilise pour Gemini 4 et 3 un nombre fixe, quelle que soit la taille. À la résolution 1280×800 qu’Anthropic recommande pour les applications web, une seule capture coûte :

Ce que le graphique ne montre pas, c’est l’accumulation. L’agent prend une nouvelle capture à chaque étape, et les anciennes restent dans le contexte. Selon Anthropic, une fenêtre de contexte de 200K tokens est pleine bien avant d’atteindre 100 captures. Dès qu’une requête contient plus de 20 images, chaque image est soumise à une limite de taille plus stricte. C’est pourquoi Anthropic recommande, pour ses modèles récents, de réduire les captures à 2000 pixels au plus par côté et d’effacer les anciennes côté serveur. Ce que l’agent oublie quand son contexte est plein, nous l’avons expliqué dans l’article sur l’auto compact.

Le jeu d’outils a lui aussi son propre coût. Chez Anthropic, le jeu d’outils computer use ajoute environ 4 500 tokens d’entrée à chaque requête, et le jeu d’outils browser use environ 6 600. Comme ce surcoût est le même à chaque requête, le prompt caching est utile ici. Pour l’arbre d’accessibilité, il n’y a pas de chiffre unique : cela dépend de la page. La documentation d’Anthropic indique que sur une page ordinaire, lire l’arbre coûte le plus souvent moins de tokens d’entrée qu’une capture. L’arbre peut lui aussi devenir volumineux : l’équipe de Playwright recommande aux agents de codage la CLI plutôt que MCP, parce que la CLI ne charge ni grands schémas d’outils ni longs arbres d’accessibilité dans le contexte du modèle.

Pour la durée, les fournisseurs ne donnent pas de chiffre par étape ; aucune des documentations que nous avons lues n’indique de secondes par action. Anthropic écrit que computer use peut être lent par rapport à une personne qui fait les mêmes opérations à la main, et le recommande pour les tâches où la vitesse ne compte pas, comme les tests logiciels automatisés. La durée par tâche, c’est OpenAI qui la publie : selon sa propre mesure, GPT-6 Astra a terminé une tâche d’OSWorld 2.0 en 40 minutes environ, et GPT-5.6 Sol en 75 minutes environ. Ces tâches sont longues : selon le site d’OSWorld 2.0, une personne met environ 1,6 heure pour en terminer une (médiane), et Claude Opus 4.7 fait en moyenne 318 appels d’outils par tâche ; sur l’ancien OSWorld, ce nombre était d’environ 30.

Pour la fiabilité, la mesure la plus suivie est OSWorld. Les trois fournisseurs ont mesuré leurs nouveaux modèles sur une version récente d’OSWorld et publié les résultats, mais chacun sur une version ou un sous-ensemble différent, et tous donnent des scores partiels :

Source : annonces et model cards des fournisseurs eux-mêmes, 20 octobre 2026 ; tous les résultats sont ceux que le fournisseur a publiés. Les versions et les sous-ensembles diffèrent, donc les lignes ne sont pas comparables entre elles. Les model cards de Google donnent un mois, pas un jour.

Le score partiel mesure la part des points de contrôle d’une tâche qui sont validés ; OSWorld 2.0 note une tâche avec 27,25 points de contrôle en moyenne. La mesure principale du benchmark, elle, consiste à savoir si la tâche est menée de bout en bout. L’écart entre les deux est grand. Dans le tableau d’OSWorld 2.0 (mise à jour du 15 octobre, version v2.1), le meilleur résultat parmi les exécutions où le modèle travaille seul est celui de Claude Opus 5 à l’effort le plus élevé : un score partiel de 77,67 %, et 44,33 % des tâches menées de bout en bout. À l’effort le plus bas, le même modèle en mène 18,81 %.

Le tableau n’a aucun modèle d’OpenAI sur la version actuelle ; sur le sous-ensemble hors ligne de la version précédente, GPT-5.6 Sol à l’effort le plus élevé a obtenu 64,13 % en score partiel et 28,1 % en tâches menées de bout en bout. Les modèles Gemini ne figurent pas du tout dans le tableau. Les chiffres annoncés par les fournisseurs disent donc que l’agent fait la plus grande partie du travail ; ils ne disent pas qu’il le termine. Comment lire un score, nous l’avons expliqué dans l’article sur SWE-bench.

Pourquoi le travail à partir de l’écran ne donne pas toujours le même résultat, les fournisseurs l’écrivent eux-mêmes. Selon GitHub, un changement de timing ou d’état d’une fenêtre peut produire un résultat différent, et pousser l’agent à répéter une action ou à rester bloqué. Anthropic écrit que le modèle peut se tromper en produisant des coordonnées, et Google que des pop-ups inattendus et des changements de mise en page peuvent dérouter le modèle. L’arbre d’accessibilité règle une partie de ce problème : selon Anthropic, une référence d’élément n’est pas affectée par les décalages de mise en page qui cassent les coordonnées en pixels. Dans un test Playwright, un élément est trouvé par son rôle et son nom, Playwright attend que l’état voulu soit atteint, et le test fait les mêmes étapes dans le même ordre à chaque exécution.

Source : les documentations liées dans cette section, 20 octobre 2026.

Que proposent les trois fournisseurs pour computer use et browser use ?

Si vous construisez votre propre agent sur l’API, les trois fournisseurs ont un outil prêt à l’emploi. La boucle est la même partout : le modèle demande une action, votre code l’exécute dans votre propre navigateur ou votre machine virtuelle et renvoie le résultat. Au 20 octobre 2026 :

Source : la documentation computer use, browser use et tarifs des trois fournisseurs, 20 octobre 2026. « Non précisé dans sa documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive.

Chez Anthropic, il y a eu récemment une transition. Selon les notes de version, computer use est sorti de la bêta le 19 août, et l’outil browser use est arrivé le même jour. Sur Opus 5.5, sorti le 22 septembre, l’ancien outil computer_20251124 renvoie une erreur 400 sur la Claude API et Google Cloud ; Sonnet 5.5 et Haiku 5.5 n’acceptent pas non plus les anciens outils. Le nouveau jeu d’outils peut renvoyer plusieurs actions ensemble en un seul tour ; votre code doit les exécuter dans l’ordre et s’arrêter à la première erreur.

Chez OpenAI, il y a deux voies. Le guide présente à la fois l’outil computer, où le modèle renvoie des actions comme des clics et de la saisie, et la voie où le modèle écrit du code Playwright ou PyAutoGUI. Sur la voie du code, le modèle peut combiner plusieurs actions, une boucle ou une condition en un seul appel. Le guide demande aussi de vérifier le résultat réel à la fin plutôt que de se fier à la réponse du modèle. Depuis le 29 septembre, l’Agents API propose aussi computer use dans un navigateur hébergé par OpenAI.

L’outil de Google est en préversion, et Google recommande une supervision étroite pour les tâches importantes. Le modèle donne des coordonnées sur une grille de 1000×1000 ; votre code les convertit à la taille de l’écran. Si une action est risquée, la réponse contient require_confirmation et vous devez demander à l’utilisateur. L’analyse des captures à la recherche de prompt injection est facultative et désactivée par défaut.

Pour le choix du modèle, les trois fournisseurs recommandent des choses différentes. Google recommande Gemini 3.8 Flash pour computer use. Anthropic juge Haiku 5.5 adapté aux tâches de browser use où la vitesse compte. La documentation de Codex recommande GPT-6 Astra pour les tâches difficiles qui dépendent de captures d’écran ou d’un jugement visuel. Les différences générales entre modèles sont dans l’article sur le choix du modèle.

Comment les agents de codage testent-ils une interface ?

Dans les cinq outils de codage, l’agent a un moyen d’utiliser le navigateur ou l’écran, mais l’endroit où cela tourne et les réglages par défaut diffèrent. Nous avons lu ce tableau dans la documentation de chaque outil le 20 octobre 2026 :

Source : la documentation et les notes de version de chaque outil, 20 octobre 2026. « Non précisé dans sa documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive. Dans Copilot, computer use est passé en préversion le 1 octobre et il est désactivé par défaut.

Si vous utilisez encore Gemini CLI, son agent de navigateur est désactivé par défaut ; une fois activé, il travaille avec la page via l’arbre d’accessibilité. Pour les utilisateurs de l’offre gratuite et de Google One, Google a remplacé Gemini CLI par Antigravity CLI le 18 juin 2026 ; avec des clés API payantes, Gemini CLI reste utilisable.

La documentation de trois de ces outils recommande le même ordre. Claude Code considère le contrôle de l’écran comme la voie la plus large et la plus lente : il essaie d’abord un serveur MCP, puis Bash, puis Claude in Chrome, et n’utilise l’écran que si rien de tout cela ne suffit. Selon GitHub, si une API, un serveur MCP, une commande de terminal ou un outil de navigateur peut faire le travail, ces outils donnent des informations plus structurées et des résultats plus prévisibles. La documentation de Codex recommande elle aussi d’abord le navigateur intégré pour une application web locale, et un serveur MCP pour les tâches répétées.

Une autre différence tient à la session. Claude in Chrome partage l’état de connexion de votre navigateur et peut accéder à tous les sites où vous êtes connecté ; devant une page de connexion ou un CAPTCHA, il s’arrête et vous demande. Dans VS Code, les pages que l’agent ouvre s’affichent dans une session séparée et temporaire. Le navigateur intégré de Codex et Antigravity IDE utilisent un profil distinct du vôtre.

Pourquoi vaut-il souvent mieux faire écrire un test Playwright à l’agent ?

La vérification que l’agent fait dans le navigateur disparaît à la fin de la session. Transformez-la en test Playwright : elle reste dans le dépôt et se relance sans modèle à chaque pull request. Elle ne dépense pas de tokens, n’accumule pas de captures d’écran et fait les mêmes étapes à chaque fois. La documentation de VS Code recommande la même chose : les outils de navigateur servent à vérifier au cours d’une session ; les vérifications qui doivent tourner en CI à chaque fois, ou détecter le retour d’un ancien bug, ont leur place dans le dépôt sous forme de tests Playwright ou d’autres tests automatisés.

En pratique, une démarche en deux temps fonctionne bien. D’abord, l’agent parcourt la page avec un outil de navigateur ou Playwright MCP et voit ce que sont réellement les sélecteurs et les textes. Ensuite, il écrit ce parcours dans un test, le lance et montre qu’il passe. Playwright fournit aussi des agents prêts à l’emploi pour cela : les Playwright Test Agents sont un planner qui parcourt l’application et rédige un plan de test, un generator qui écrit les tests à partir du plan et un healer qui répare les tests cassés. npx playwright init-agents --loop=claude ajoute ces définitions pour Claude Code ; il existe aussi les options codex et vscode. Le generator vérifie les sélecteurs et les assertions en direct pendant qu’il exécute le scénario. Voici un test qu’un agent pourrait écrire pour un formulaire d’inscription :

// Exemple : test écrit par l’agent, relancé en CI à chaque pull request.
import { test, expect } from '@playwright/test';

test('le formulaire d’inscription refuse un e-mail invalide', async ({ page }) => {
  await page.goto('/signup');
  await page.getByLabel('E-mail').fill('adresse-invalide');
  await page.getByRole('button', { name: 'S’inscrire' }).click();
  await expect(page.getByText('Saisissez une adresse e-mail valide')).toBeVisible();
  await expect(page).toHaveScreenshot('signup-erreur.png');
});

Le test fait deux sortes de vérification. toBeVisible regarde le comportement : le message d’erreur s’affiche-t-il ? toHaveScreenshot regarde l’apparence : la page est comparée pixel par pixel avec l’image de référence du dépôt. Selon Playwright, le système d’exploitation, la version du navigateur et même le matériel peuvent changer l’image ; générez donc l’image de référence dans l’environnement où le test tournera. Si vous voulez comparer la structure de la page via l’arbre d’accessibilité plutôt qu’avec une image, il existe toMatchAriaSnapshot.

Quand un test casse, laissez des preuves à l’agent pour qu’il voie pourquoi. La configuration ci-dessous enregistre une capture d’écran pour chaque test en échec, et une trace à la première relance en CI ; dans la trace, vous pouvez avancer et reculer pour voir ce qui s’est passé à chaque étape du test. Les fichiers arrivent dans le dossier de sortie des tests, en général test-results ; dites à l’agent d’y regarder d’abord quand il corrige l’échec.

// Exemple : configuration qui garde des preuves d’un test en échec.
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: 'http://localhost:3000',
    screenshot: 'only-on-failure',
    trace: 'on-first-retry',
  },
});

Les vérifications par capture d’écran restent nécessaires dans ces cas : décalages de mise en page, erreurs de couleur ou d’alignement, un graphique ou une carte dessinés dans un canvas. La documentation d’Anthropic range elle aussi le canvas, la vidéo intégrée et les surfaces de bureau à distance parmi les endroits que l’arbre ne voit pas. Pour trouver un tel bug, il suffit que l’agent regarde une fois une capture d’écran ; pour qu’il ne revienne pas, faites-lui écrire un test avec toHaveScreenshot.

Quelle voie choisir pour quel travail ?

Tous les éléments mènent au même ordre : si vous pouvez faire le travail avec du code, faites-le avec du code ; si la page est dans un navigateur, passez par l’arbre ; s’il n’y a pas d’autre accès, passez par l’écran. Pour les tâches courantes :

Les raisons derrière les cartes sont plus haut. Un test pour vérifier une interface web, parce que le test tourne en CI sans modèle et fait les mêmes étapes à chaque fois. Un outil de navigateur pour une vérification ponctuelle, parce que lire l’arbre coûte le plus souvent moins qu’une capture et qu’une référence n’est pas affectée par les décalages de mise en page. Gardez computer use pour les applications qui n’ont ni API, ni CLI, ni serveur MCP ; GitHub le présente lui aussi pour ce genre d’applications.

Pour les paiements, les mots de passe et les changements de compte, les trois fournisseurs disent la même chose : qu’un humain valide la dernière étape. Anthropic recommande une validation humaine pour des décisions comme accepter des cookies, effectuer une transaction financière ou accepter des conditions d’utilisation. OpenAI considère même la saisie d’informations sensibles dans un formulaire comme une transmission de données. Les instructions d’exemple de Google demandent au modèle de ne jamais essayer de résoudre un CAPTCHA. Faites tourner l’agent dans une machine virtuelle à part ou avec un profil de navigateur à part, et limitez les sites qu’il peut visiter avec une liste d’autorisation. Comment un texte sur une page peut orienter l’agent, nous l’avons expliqué dans l’article sur la sécurité MCP.

diffox, un outil de revue de code par IA, lit la pull request avec git ; il n’ouvre pas l’interface et ne prend pas de captures d’écran. C’est pourquoi le test que l’agent écrit pour l’interface sert deux fois dans la pull request : la CI montre que l’interface fonctionne, et pendant la review, on peut lire dans le diff ce que le test vérifie. Pourquoi un test qui passe ne vérifie pas toujours quelque chose, nous l’avons expliqué dans l’article sur la review du code écrit par l’IA.