Comparatif des agents computer-use
Chaque grand laboratoire propose aujourd'hui un modèle capable de regarder un écran et de cliquer dessus. L'outil computer use d'Anthropic, l'outil computer d'OpenAI et l'outil computer_use de Google résolvent tous le même type de problème — prendre une capture d'écran, décider d'une action, l'exécuter, reprendre une capture — et tous les trois sont incompatibles entre eux au niveau du protocole, d'une manière qui ne saute pas aux yeux tant que les clics n'atterrissent pas 40 pixels à côté.
Cette page est le guide au niveau du harnais, pas le classement. Le classement change tous les mois ; les modes de défaillance ci-dessous sont les mêmes depuis la toute première préversion.
- Comprendre la boucle d'agent commune aux trois fournisseurs — et les trois points où ils divergent
- Corriger le bug de coordonnées qui casse silencieusement la plupart des premières tentatives (Retina, réduction d'échelle et limites de taille d'image)
- Connaître la barrière de sécurité de chaque fournisseur, car elle fait partie du protocole et n'est pas un ajout facultatif
- Lire OSWorld honnêtement : ce que signifie réellement la référence humaine
- Choisir correctement l'effort de raisonnement — le réglage le moins cher n'est pas celui qu'on croit
La boucle commune à tous
Une fois la marque mise de côté, les trois sont la même machine à états :
- Le modèle reçoit votre instruction et une image de l'écran courant. Certains fournisseurs veulent aussi l'URL courante ou un bref historique des actions récentes.
- Clique en (x, y). Tape ceci. Fais défiler ici. C'est une demande adressée à votre code — le modèle ne peut pas toucher la machine lui-même.
- Cette partie vous appartient. Anthropic le dit clairement : votre application doit exécuter l'outil ; Claude ne peut pas l'exécuter directement. C'est vous qui implémentez la capture d'écran, la souris et le clavier.
- Le nouvel écran repart comme résultat d'outil. Le modèle voit la conséquence de sa propre action — c'est tout le signal de retour dont il dispose.
- La terminaison, c'est l'absence de nouvelle demande d'action, pas un indicateur « terminé ». Votre boucle a besoin de son propre plafond d'étapes et d'une détection de blocage.
La conséquence qu'on néglige : la seule perception du monde qu'a le modèle est l'image que vous lui envoyez. Chaque défaillance ci-dessous est en réalité une défaillance de cette image, ou de l'espace de coordonnées qu'elle implique.
Là où les trois divergent
La divergence n'est pas « lequel est le plus intelligent ». C'est le contrat.
| Anthropic (Claude) | OpenAI (GPT) | Google (Gemini) | |
|---|---|---|---|
| Espace d'actions | Primitives brutes du bureau : screenshot, left_click, type, key, scroll, drag, hold_key, wait, plus zoom sur la version la plus récente de l'outil | Actions d'interface structurées : click, double_click, scroll, type, keypress, drag, move, wait, screenshot | Actions sémantiques : pas seulement click/type mais navigate, go_back, go_forward, open_app, long_press — les concepts du navigateur et du mobile sont de première classe |
| Coordonnées | Vous envoyez les dimensions en pixels ; le modèle renvoie des coordonnées en pixels bruts dans cet espace | Même contrat de pixels, avec des tailles de bureau recommandées | Idem, avec un champ intent expliquant le raisonnement derrière chaque action |
| Plomberie de la boucle | Blocs de résultat d'outil portant une image | computer_call → computer_call_output associés par call_id ; previous_response_id porte l'historique pour que vous n'ayez pas à le renvoyer | Appel de fonction → function_result avec une nouvelle capture d'écran |
| Barrière de sécurité | Des classificateurs d'injection s'exécutent automatiquement sur les captures d'écran | pending_safety_checks que vous devez explicitement acquitter | safety_decision avec des catégories de politique |
| Terrain de prédilection | Contrôle général du bureau / au niveau de l'OS | Bureau et navigateur, plus un chemin d'exécution de code | Navigateur d'abord ; fort sur mobile ; explicitement non optimisé pour le contrôle d'un OS de bureau |
Cette dernière ligne Anthropic/Google est celle qui décide de l'architecture. L'espace d'actions de Google est sémantique — go_back est un concept que le modèle peut nommer. Celui d'Anthropic est mécanique — revenir en arrière signifie que le modèle doit trouver et cliquer le bouton retour, ou presser la bonne combinaison de touches. Les actions sémantiques sont plus fiables dans un navigateur et inutiles en dehors. Les primitives mécaniques fonctionnent partout et échouent plus souvent.
Donc : porter un agent computer-use d'un fournisseur à un autre n'est pas un simple changement de modèle. C'est réécrire l'exécuteur d'actions du harnais. Budgétisez en conséquence. (Même leçon que dans Comparatif des CLI d'agents de codage : c'est au harnais, pas au modèle, que vous êtes réellement marié.)
Le bug de coordonnées qui dévore votre première semaine
C'est l'élément à plus forte valeur de cette page, parce que presque tout le monde le rencontre et que le symptôme ressemble à « le modèle est mauvais pour cliquer ».
Il n'est pas mauvais pour cliquer. Votre image et votre espace de coordonnées sont en désaccord.
Trois causes indépendantes, qui se cumulent :
1. Retina / HiDPI double votre image
Les écrans Retina de macOS capturent des captures d'écran avec un ratio de pixels de l'appareil de 2 — l'image fait deux fois la résolution des coordonnées logiques de l'écran. Envoyez-la telle quelle et le modèle raisonne sur une image de 2880 de large tandis que votre exécuteur de clics pense en points logiques de 1440 de large. Chaque clic atterrit à peu près à la moitié de la position visée, de manière constante, dans une seule direction.
Correctif : réduire l'échelle par 2 avant l'envoi, ou diviser par deux les coordonnées renvoyées par le modèle. Pas les deux.
2. L'API réduit silencieusement l'échelle des images trop grandes
Les modèles ont des limites de taille d'image — et elles diffèrent entre modèles d'un même laboratoire. Claude Sonnet 5, Opus 4.8 et Opus 4.7 acceptent jusqu'à 2576 pixels sur le côté long ; les modèles Claude antérieurs acceptent 1568 pixels et environ 1,15 mégapixel au total.
Voici le piège : si vous envoyez quelque chose de plus grand, l'API en réduit l'échelle pour vous au lieu de renvoyer une erreur. Le modèle renvoie alors des coordonnées dans l'espace de l'image que lui a vue — et vous n'avez jamais connu le facteur d'échelle, puisque le redimensionnement a eu lieu côté serveur. Seules les images vraiment énormes (au-delà d'environ 8 000 px de côté) sont rejetées d'emblée avec une erreur de validation.
Ainsi, c'est le comportement « serviable » qui est le bug. Redimensionnez toujours côté client, définissez display_width_px/display_height_px aux dimensions que vous avez réellement envoyées, et remettez vous-même à l'échelle les coordonnées renvoyées.
3. Réglages de détail et rapport d'aspect
Avec l'outil d'OpenAI, les captures d'écran doivent utiliser detail: "original" — "high" comme "low" dégradent la précision des clics pour cette tâche précisément. Et si vous redimensionnez sans préserver le rapport d'aspect, les clics atterrissent dans la bonne zone et ratent la cible.
Mise à l'échelle des coordonnées — la forme du correctif
# Before sending: shrink to fit the model's image limit, remember the factor. LONG_EDGE_LIMIT = 2576 # check YOUR model's limit; older Claude models: 1568 scale = min(1.0, LONG_EDGE_LIMIT / max(width, height)) sent_w, sent_h = round(width * scale), round(height * scale) # -> send the resized image, and declare display_width_px=sent_w, display_height_px=sent_h # After the model replies: map its coordinates back to the real screen. real_x, real_y = model_x / scale, model_y / scale # On a Retina capture you did NOT pre-downscale, divide by the device pixel ratio too.
Aide-mémoire symptôme → cause
| Symptôme | Presque certainement |
|---|---|
| Clics systématiquement décalés dans une direction | Vos display_width_px/display_height_px déclarés ne correspondent pas à l'image réellement envoyée |
| Les clics atterrissent dans la bonne zone mais ratent les petites cibles | Détail perdu à la réduction d'échelle, ou rapport d'aspect déformé au redimensionnement |
| Précision mauvaise partout | Résolution trop basse — essayez 1280x720 comme plancher |
| Le modèle lit mal les petits textes (titres d'onglet, noms de fichiers, numéros de ligne) | Il a besoin de zoomer, et vous ne l'avez pas activé |
Recommandations de résolution, données par les fournisseurs eux-mêmes : Anthropic suggère 1024x768 ou 1280x720 pour un bureau généraliste, 1280x800 ou 1366x768 pour les applications web, et déconseille explicitement de dépasser 1920x1080. OpenAI recommande 1440x900 ou 1600x900. Plus grand n'est pas mieux — vous payez des tokens pour des pixels, puis vous jetez le détail à la réduction d'échelle.
La soupape de secours du zoom
La toute dernière version de l'outil computer de Claude (computer_20251124) ajoute une action zoom, désactivée par défaut — il faut définir enable_zoom: true. Une fois activée, Claude zoome sur une région lorsqu'il doit lire du petit texte illisible à la résolution de base de la capture : noms de fichiers de la barre latérale, titres d'onglet, texte de la barre d'état, numéros de ligne, libellés de boutons.
Note opérationnelle non évidente : si Claude ne zoome pas alors que vous vous y attendez, le correctif consiste généralement à poser la question sur une région ou un élément précis plutôt que sur l'écran dans son ensemble.
Les barrières de sécurité font partie du protocole
Ne les traitez pas comme un rajout. Dans les trois API, le mécanisme de sécurité modifie la forme de votre boucle.
Anthropic a entraîné le modèle à résister à l'injection de prompt et exécute automatiquement des classificateurs sur vos prompts dès que les outils computer-use sont en jeu. Quand un classificateur repère une injection probable dans une capture d'écran, il oriente le modèle vers une demande de confirmation à l'utilisateur avant l'action suivante. C'est excellent avec un humain présent et carrément inadapté pour un pipeline non surveillé — d'où l'existence d'une désactivation, conditionnée à une prise de contact avec le support.
OpenAI expose des pending_safety_checks que votre code doit explicitement acquitter (acknowledged_safety_checks) avant que la boucle ne se poursuive. La barrière est entre vos mains, et la contourner est une décision que vous prenez dans le code.
Google renvoie une safety_decision — autorisée, require_confirmation, ou bloquée — pilotée par des catégories de politique dont FINANCIAL_TRANSACTIONS, COMMUNICATION_TOOL, ACCOUNT_CREATION, SENSITIVE_DATA_MODIFICATION et LEGAL_TERMS_AND_AGREEMENTS. Le filtrage des injections de prompt dans les captures d'écran est disponible en option à activer.
La menace est réelle et précise : une capture d'écran est une entrée non fiable. Du texte affiché sur une page web, dans une image, dans un PDF ouvert par l'agent — tout cela atteint le modèle par le même canal que vos instructions. La documentation d'Anthropic note elle-même que Claude suivra, dans certaines circonstances, des instructions trouvées dans le contenu même lorsqu'elles entrent en conflit avec les vôtres. Les mesures d'atténuation de chaque fournisseur convergent vers les trois mêmes règles : isolez l'environnement, gardez un humain sur les actions à fort impact, et considérez tout ce qui est à l'écran comme hostile.
Si l'agent doit se connecter, ce risque grimpe fortement — des identifiants plus du contenu injectable, c'est la pire combinaison dans ce domaine. Voir Sécuriser les agents locaux et hybrides et Injection de prompt pour le manuel défensif.
Lire OSWorld honnêtement
OSWorld est l'étalon partagé, et c'en est un bon parce qu'il est difficile à truquer : il place un agent dans un vrai OS avec de vraies applications, et note avec une vérification basée sur l'exécution — un script contrôle si le fichier a réellement été enregistré, pas si l'agent affirme l'avoir fait. Le benchmark couvre 369 tâches (361 dans le jeu d'évaluation standard, puisqu'une poignée de tâches Google Drive nécessitent une configuration manuelle) et fournit 134 fonctions d'évaluation basées sur l'exécution. OSWorld-Verified en est la révision nettoyée, avec les exemples cassés signalés par la communauté corrigés et le temps d'évaluation ramené à environ une heure sur AWS.
Deux chiffres qu'il faut tenir ensemble :
- La référence humaine est d'environ 72,4 %. Pas 100 %. Ces tâches sont réellement tatillonnes, et les humains s'y trompent aussi.
- Au lancement d'OSWorld, le meilleur modèle obtenait 12,24 %.
Les agents de pointe rapportent aujourd'hui des scores dans les 70 % et au-delà — ce qui signifie que le titre « les agents ont atteint le niveau humain sur l'usage de l'ordinateur » est arithmétiquement défendable et pratiquement trompeur. Un score de benchmark est un résultat modèle + harnais + échafaudage, exactement comme un benchmark de codage (voir L'écart capacité–fiabilité). Votre harnais n'est pas le leur. Et un taux de réussite de 75 % sur des tâches isolées se compose brutalement : un flux de huit étapes où chaque étape est fiable à 95 % réussit environ 66 % du temps.
Traitez OSWorld comme la preuve que la capacité existe, et votre propre jeu d'évaluation comme la seule preuve que votre produit fonctionne.
Le résultat sur l'effort de raisonnement auquel personne ne s'attend
Pour le computer use de Claude en particulier, le benchmarking interne d'Anthropic donne des recommandations qui inversent l'intuition habituelle :
- Opus 4.7 : effort
highpar défaut ; descendez àlowpour les charges à fort débit ou sensibles au coût. - Sonnet 4.6 et Opus 4.6 :
mediumoffre le meilleur rapport précision/coût. Évitezmax— sur les tâches d'interface, il ajoute du coût en tokens sans améliorer la précision. - Le contre-intuitif : sur ces modèles, l'effort
lowconsomme moins de tokens de sortie que la désactivation complète du raisonnement. Un peu de réflexion évite les erreurs, et les erreurs vous coûtent des reprises — et les reprises coûtent bien plus de tokens que la réflexion.
Donc « couper la réflexion pour économiser » est, pour le computer use, souvent faux. Le moins cher, c'est un peu de réflexion.
Une dernière subtilité de sélection de modèle : la précision mécanique du clic n'est pas le même axe que l'intelligence. Sonnet 4.6 est mécaniquement plus précis au clic qu'Opus 4.6, et plus robuste quand les captures d'écran ont été fortement réduites. Opus 4.7 resserre cet écart et relève la limite de pixels, si bien qu'il nécessite moins de réduction d'échelle au départ.
Un harnais qui survit au contact
- Un conteneur ou une VM sans rien de précieux dedans. Chaque fournisseur le dit et tous le pensent vraiment : l'agent finira par cliquer quelque chose que vous n'aviez pas prévu.
- Capturez, redimensionnez côté client à la limite de votre modèle, déclarez les dimensions exactes envoyées, et conservez le facteur d'échelle. Écrivez cela une fois et n'y pensez plus jamais.
- La terminaison, c'est « aucune action supplémentaire renvoyée » — ce qui ne se produit jamais si l'agent est coincé dans une fenêtre modale qu'il ne sait pas fermer. Ajoutez un budget d'étapes maximal et un détecteur de blocage (N captures d'écran identiques d'affilée).
- Humain dans la boucle, ou fonctionnement non surveillé avec désactivation et rayon d'impact réduit. Ne découvrez pas cela par accident quand une demande de confirmation bloquera votre tâche cron.
- Vérifiée par l'exécution, comme le fait OSWorld : contrôlez que le monde a changé, pas que l'agent l'a dit. C'est le seul chiffre sur votre système qui ait un sens.
- L'agent computer-use le plus fiable est celui qui n'a pas besoin d'utiliser l'ordinateur. Si la cible a une API, un serveur MCP ou une CLI, ce chemin est plus rapide, moins cher et infiniment plus fiable. Les écrans sont le repli, pas l'objectif.
Cette dernière étape est celle qui est stratégique. Le computer use est l'adaptateur universel pour les logiciels sans API — applications de bureau héritées, portails de fournisseurs, tout ce qui se cache derrière une connexion sans histoire d'intégration. C'est un magnifique bricolage, et cela reste un bricolage. Tournez-vous d'abord vers MCP et les vrais outils.
Check yourself
0/5Sources et lectures complémentaires
- Anthropic — Outil computer use — en-têtes beta, jeu d'actions, limites d'image, mise à l'échelle des coordonnées, recommandations d'effort, classificateurs d'injection.
- OpenAI — Guide computer use — la boucle
computer_call/computer_call_output, les contrôles de sécurité, les résolutions recommandées. - Google — Gemini computer use — l'espace d'actions sémantique sur navigateur, mobile et bureau ; les catégories de politique de
safety_decision. - OSWorld et xlang-ai/OSWorld — le benchmark, sa vérification basée sur l'exécution, et la référence humaine.
- anthropics/anthropic-quickstarts — l'implémentation de référence
computer-use-demo(conteneur, affichage virtuel, boucle d'agent). - openai/openai-cua-sample-app — le harnais computer-use de référence d'OpenAI.
- browser-use/browser-use — un harnais d'agent navigateur largement utilisé et agnostique du modèle, si vous voulez le cas navigateur sans construire la boucle vous-même.