Les agents computer-use entrent en production : ce qui marche vraiment en entreprise

Les agents IA computer-use pilotent les logiciels comme le feraient des humains : ils voient l’écran et actionnent souris et clavier à travers applications et navigateurs.

Deux ans après que les laboratoires de pointe ont livré leurs premières boucles capture d’écran → action, les agents IA computer use ne se limitent plus à des démonstrations de laboratoire. Les éditeurs exposent des outils de contrôle d’ordinateur dans les API et les produits desktop ; les entreprises les testent sur des interfaces graphiques héritées qui n’ont jamais eu d’API propre. La question centrale n’est plus de savoir si un agent peut cliquer un bouton. C’est de savoir si la production d’agents IA tient face aux workflows réels, aux budgets de tokens et aux équipes risque.

Cet article sépare ce que les benchmarks publics mesurent désormais de ce qui rapporte réellement sur le poste de travail d’entreprise — et où la falaise de capacité continue de dicter la feuille de route.

Ce que signifie « computer use » en pratique

Un agent computer-use observe une interface graphique (le plus souvent via des captures d’écran, parfois avec des canaux d’accessibilité ou DOM en complément) et émet des actions de bas niveau : déplacer, cliquer, taper, faire défiler, glisser, attendre. Contrairement à un script RPA classique accroché à des sélecteurs, l’agent replanifie à partir de l’état visuel. Cette souplesse explique pourquoi les équipes y recourent quand la cible est un portail éditeur, un client lourd, ou un assemblage navigateur + desktop qu’aucun projet d’intégration n’a jamais terminé.

Les propres recommandations produit d’Anthropic sont franches sur la maturité : le computer use reste précoce par rapport aux forces de Claude en code et en texte ; l’agent peut se tromper ; il faut commencer par des applications de confiance et éviter les données sensibles ; certaines apps restent interdites par défaut ; et le système demande une autorisation avant d’ouvrir de nouvelles applications tout en scrutant les motifs d’injection de prompts. Ce cadrage — utile, supervisé, pas encore un autopilote silencieux — est le bon modèle mental pour les agents IA d’entreprise qui touchent des systèmes de production.

Le pari architectural est portable : traiter l’écran comme une surface d’E/S universelle. Le pari opérationnel est plus étroit : placer la boucle dans un bac à sable que l’on contrôle, verrouiller les étapes irréversibles, et mesurer les résultats dans le système d’enregistrement — pas dans l’auto-évaluation de l’agent.

Benchmarks : les tâches courtes montent ; les workflows longs, non

D’OSWorld 1.0 à OSWorld 2.0

La suite OSWorld d’origine plongeait des agents multimodaux dans de vrais environnements Ubuntu, Windows et macOS, avec des centaines de tâches bureau et web ouvertes. À la publication, les humains achevaient plus de 72 % des tâches tandis que le meilleur modèle évalué plafonnait près de 12 %. Cet écart a défini la première génération de recherche computer-use : les agents peinaient sur l’ancrage GUI et la connaissance opérationnelle, même sur des interactions relativement courtes.

À la mi-2026, le domaine disposait d’un étalon plus révélateur. OSWorld 2.0 remplace une grande partie des tâches en une seule passe par 108 workflows à long horizon. Des humains expérimentés mettent une médiane d’environ 1,6 heure par tâche ; environ 70 % des tâches prennent plus d’une heure. Les agents de pointe brûlent de l’ordre de 318 appels d’outils sur une configuration Claude Opus exigeante, contre environ 30 dans OSWorld 1.0. Les tâches s’ancrent dans des artefacts authentiques et des profils utilisateur à état, et la suite inclut des audits de sécurité séparés pour l’exécution sensible.

Sous la métrique primaire de complétion binaire, avec un plafond de 500 étapes, la configuration la plus forte rapportée — Claude Opus 4.8 avec thinking maximal et appels d’outils groupés — n’achève encore que 20,6 % des tâches, pour un score de crédit partiel de 54,8 %. Un concurrent plus économe en tokens (GPT-5.5 dans la comparaison publiée) plafonne près de 14 % de complétion binaire. Les modes d’échec glissent de « ne sait pas cliquer » vers « perd les contraintes », « rate une information en cours de route », « devine au lieu de demander » et « saute la vérification », surtout quand l’état requis est caché.

L’économie des tokens fait désormais partie de l’histoire du benchmark, pas d’une note de bas de page. Sur la frontière rapportée d’OSWorld 2.0, GPT-5.5 atteint environ 14 % de récompense binaire avec à peu près 39K tokens de sortie, tandis que Claude Opus 4.7 monte à 18,2 % autour de 150K tokens et Opus 4.8 à 20,6 % autour de 244K. Une meilleure complétion est disponible — mais à un coût marginal très élevé. La longueur d’horizon aggrave le problème : la complétion binaire est déjà faible sur les tâches de moins d’une heure et tombe vers zéro dès que les workflows dépassent environ deux heures et demie dans les tranches publiées.

WebArena et la tranche navigateur

WebArena reste la référence pour le travail web multi-sites réaliste et auto-hébergé (e-commerce, forums, logiciels collaboratifs, CMS). Dans l’article d’origine, le meilleur agent GPT-4 atteignait 14,41 % de succès de bout en bout contre une baseline humaine de 78,24 % sur des tâches-modèles échantillonnées. Les classements communautaires ont bougé depuis, mais la leçon d’origine tient toujours pour la planification en production : l’autonomie navigateur est une surface produit différente de l’achèvement fiable d’un métier, et les harnais d’évaluation comptent autant que les noms de modèles.

La falaise entreprise : UI-CUBE

Des scores académiques bureau et web encourageants peuvent masquer une préparation entreprise encore mince. Le benchmark UI-CUBE d’UiPath a été conçu explicitement pour cet écart : 226 tâches réparties entre interactions UI simples (136) et workflows complexes (90, y compris copier-coller / processus métier et apps d’entreprise mockées telles que CRM, ERP, notes de frais, RH et tableaux de projet), avec tests multi-résolutions et contrôles programmatiques contre l’état applicatif.

Les résultats montrent une falaise de capacité, pas une courbe lisse. En moyenne sur les résolutions, les systèmes évalués atteignent environ 67–85 % de succès sur les interactions simples (humains : 97,9 %) mais seulement 9–19 % sur les workflows complexes. Des humains sans expérience préalable de l’app n’atteignent encore que 61,2 % sur ces tâches complexes — un plafond important pour quiconque compare les agents à « ce qu’une personne ferait le premier jour ». Relativement aux humains, les agents atteignent environ 68–87 % de la performance humaine sur le simple, mais seulement 15–32 % sur le complexe. La résolution amplifie la fragilité : plusieurs modèles perdent des dizaines de points de pourcentage sur les tâches simples en passant de XGA à 4K, car les erreurs d’ancrage augmentent avec un plus grand espace d’action pixel.

Les auteurs d’UI-CUBE estiment que la discontinuité pointe vers des limites architecturales de mémoire, de planification hiérarchique et de coordination d’état — des limites que le prompting seul n’effacera pas. Leur recommandation pratique rejoint ce que les équipes de production redécouvrent déjà : décomposer les processus complexes en étapes atomiques que les modèles actuels savent gérer, plutôt qu’espérer qu’une longue trajectoire tienne.

Les échecs silencieux battent les démos tape-à-l’œil

Les logiciels d’entreprise échouent autrement que les démos grand public. ERPBench évalue des agents « capture seule » contre un ERP live reproductible et note les tâches contre une vérité terrain en base, pas seulement contre les captures. L’avertissement central de l’article : une forte performance GUI générale ne se transfère pas en fiabilité entreprise. Les agents peuvent naviguer jusqu’au bon enregistrement et même appuyer sur enregistrer tout en écrivant la mauvaise valeur. Dans un schéma rapporté, un modèle ouvert atteignait la cible dans la plupart des runs et committait une sauvegarde dans une grande part d’entre eux, tout en laissant la bonne valeur en base dans seulement quelques pourcents des cas — presque chaque sauvegarde était donc un risque de corruption silencieuse.

Cette classe d’erreur est invisible aux métriques du type « l’agent avait l’air occupé ? » et dévastatrice pour la finance, les stocks et les RH. Pour la production d’agents IA, les critères de succès doivent vivre dans le système d’enregistrement : assertions au niveau des champs, écritures idempotentes, et validation humaine avant les commits irréversibles.

Le coût en tokens n’est pas toute la facture — mais il façonne déjà le design

Les boucles computer-use sont gourmandes en captures. Chaque observation peut envoyer une charge multimodale volumineuse ; chaque reprise après un mauvais clic brûle un nouveau tour. La frontière tokens-contre-score d’OSWorld 2.0 explique pourquoi les directions financières s’en soucient : gagner quelques points de complétion peut multiplier les tokens de sortie plusieurs fois. Par ailleurs, les agents prennent souvent plus d’étapes que les humains pour la même tâche — des études d’efficacité citées aux côtés d’OSWorld rapportent environ 1,4–2,7× le nombre d’étapes humaines pour les agents leaders — si bien que latence et coût croissent avec le surcroît d’allers-retours, pas seulement avec les grilles tarifaires des modèles.

Une heuristique de production utile découle des preuves, sans inventer de théâtre ROI :

1. Préférer les API et connecteurs quand ils existent. La pile produit d’Anthropic elle-même priorise des connecteurs précis avant de retomber sur le contrôle d’écran.
2. Borner l’horizon. Les tâches qui tiennent dans quelques dizaines d’actions fiables sont candidates ; les odyssées multi-apps à l’échelle de l’heure restent de la recherche.
3. Budgéter l’automatisation partielle. Associer l’agent à des validateurs déterministes et à une revue humaine sur les mouvements d’argent, les changements d’identité et les messages externes.
4. Mesurer le coût par résultat vérifié, pas par token ni par démo. Une trajectoire bon marché qui écrit de mauvaises données ERP est infiniment chère.

Fiabilité et limites de sécurité qui décident du go-live

Les agents computer-use héritent de tous les risques classiques d’automatisation, puis y ajoutent des risques spécifiques aux modèles :

• Injection de prompts via l’écran. Contenu de page non fiable, e-mails et documents peuvent instruire l’agent. Les classifieurs éditeurs aident ; ils ne remplacent pas les listes d’autorisation réseau et d’actions au niveau d’exécution.
• Exfiltration d’identifiants et de données. Les captures peuvent contenir des secrets. Redaction avant inférence et comptes de service au moindre privilège sont des contrôles de base.
• Persistance de l’environnement. Les bureaux partagés accumulent cookies et fichiers. Conteneurs ou VM éphémères par run réduisent le rayon d’explosion.
• Actions irréversibles. Achats, suppressions, instructions de virement et déploiements de production exigent des portes humaines explicites — la même posture qu’Anthropic recommande quand des actions lourdes de conséquences apparaissent.
• Auditabilité. Journaliser observations, actions, validations et postconditions dans votre plan de contrôle. Ne pas dépendre uniquement d’une transcription de chat éditeur.

Ce qui marche réellement en entreprise aujourd’hui

En synthétisant benchmarks et guidance éditeurs, le schéma qui fonctionne pour les agents IA computer use en 2026 ressemble à ceci :

Bon ajustement (à livrer avec garde-fous)

• Corvées UI atomiques dans des apps connues : ouvrir un formulaire, remplir des champs depuis une charge structurée, télécharger un fichier, exporter un rapport, cliquer un assistant fixe.
• Tâches navigateur avec postconditions claires sur des domaines en liste blanche, surtout quand un chemin Playwright ou API peut prendre le relais après la navigation.
• Assistants développeurs et analystes qui pilotent IDE, terminaux et outils internes sous supervision — là où les erreurs sont réversibles et la revue naturelle.
• Dispatch humain dans la boucle : l’agent prépare ; une personne valide le commit.

Ajustement moyen (piloter étroitement)

• Copier-coller multi-étapes entre deux ou trois systèmes familiers, avec vérification programmatique après chaque saut.
• Gestion d’exceptions au-dessus d’une RPA existante : l’agent propose une voie de reprise ; l’automatisation ou un humain l’exécute.
• Reconnaissance surtout en lecture (recueillir un statut, preuves en capture, brouillon de ticket) sans accès en écriture aux systèmes d’enregistrement.

Mauvais ajustement (garder au labo)

• Workflows non surveillés à l’échelle de l’heure, traversant e-mail, portails bancaires, CAO et ERP patrimoniaux sans checkpoints intermédiaires — précisément là où OSWorld 2.0 et UI-CUBE montrent l’effondrement.
• Tout processus où une mauvaise sauvegarde est pire qu’aucune sauvegarde (données maîtres ERP critiques, paie, dossiers cliniques) sauf oracles au niveau base et validations obligatoires.
• Programmes du type « remplacer l’équipe de services partagés » vendus sur des captures de classements de tâches courtes.

L’implication stratégique pour les plateformes et les « acteurs majeurs de l’IA » est une convergence, pas un vainqueur unique : agents capture portables, automatisation native navigateur et contrôle piloté par le code (style Playwright) coexisteront. Les entreprises qui gagneront routeront chaque workflow vers le substrat fiable le moins cher — API d’abord, automatisation navigateur structurée ensuite, computer use complet en dernier — et bâtiront des suites d’évaluation qui ressemblent davantage à UI-CUBE et ERPBench qu’à des démos marketing.

Une checklist pratique de production

1. Définir le résultat dans les données, pas dans des récits d’UI. Préférer les diffs d’état et les contrôles en base.
2. Plafonner étapes, temps et domaines. Les coupe-circuits battent les boucles de retry infinies.
3. Décomposer les longs processus en unités à taille d’agent, avec checkpoints et crédit partiel dans votre propre harnais.
4. Séparer les stages naviguer / saisir / committer dans les métriques pour que les mauvaises écritures silencieuses ne se cachent pas derrière « a atteint le formulaire ».
5. Tarifer la boucle complète : tokens, compute du bac à sable, temps de revueur et reprise.
6. Modéliser la menace de l’écran comme un canal non fiable.
7. Rejouer les benchmarks sur vos apps à vos résolutions ; les scores OSWorld ou WebArena publiés sont des écrans, pas des certificats.

En résumé

Les agents computer-use sont entrés dans la boîte à outils de l’entreprise. Sur du travail UI court et bien borné, ils sont de plus en plus compétents ; sur des processus métier longs, à état et multi-apps, les preuves publiques — du plafond de ~21 % de complétion binaire d’OSWorld 2.0 aux taux à un chiffre / bas teens d’UI-CUBE sur le complexe et aux échecs de mauvaise sauvegarde d’ERPBench — disent qu’ils ne sont pas encore des autopilotes fiables.

Ce qui marche aujourd’hui, c’est une autonomie partielle disciplinée : des agents IA d’entreprise qui cliquent là où les API manquent, s’arrêtent là où le risque commence, et prouvent le succès dans le grand livre. Traitez les montées de classement comme un signal de recherche. Traitez la production comme un problème de systèmes — évaluation, bac à sable, coût et gouvernance — autour d’une compétence de modèle encore en maturation.

Lectures associées

• Modèles frontier open-weight vs API fermées : l’arbitrage de souveraineté
• Des chatbots au work OS : comment les assistants IA avalent le SaaS d’entreprise
• Navigateur, IDE et OS : les trois champs de bataille des interfaces IA

< !– Schema.org NewsArticle (CF_SEO) — image paths relative to draft ; replace with absolute CDN URLs at publish –>

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.