Agents à usage ordinateur : l'IA qui voit l'écran

CONCEPTS · AGENTS À USAGE ORDINATEUR

Capacités et chiffres relevés sur les sources officielles et les publications primaires, vérifiés au 22 juillet 2026.

La plupart des intégrations d'IA passent par une porte de service : une interface de programmation, un connecteur, une clé d'accès. L'agent parle au logiciel dans la langue des machines. Une autre approche, plus brutale et plus universelle, consiste à faire entrer l'agent par la grande porte, celle des humains : lui donner une capture de l'écran, le laisser décider où cliquer, puis exécuter ce clic. Aucune interface de programmation, aucun connecteur — l'écran, la souris, le clavier. C'est ce qu'on appelle un agent à usage ordinateur.

L'idée est séduisante, car elle promet d'atteindre tout logiciel doté d'une interface visible, y compris les applications anciennes qui n'exposent rien. Elle est aussi la plus exigeante en fiabilité, parce qu'elle empile des décisions perceptives fragiles là où une interface de programmation offrirait une prise nette. En 2026, la question n'est plus « la machine sait-elle cliquer ? » — elle le sait. Elle est devenue : « le fait-elle assez souvent bien pour qu'on lui confie une tâche sans la surveiller ? »

La boucle voir → décider → agir

Le mécanisme tient en trois temps répétés. L'agent voit : il reçoit une image de l'écran, éventuellement accompagnée d'un objectif en langage naturel. Il décide : le modèle multimodal interprète l'image, localise l'élément pertinent et choisit un geste. Il agit : le geste est traduit en événement système — un clic à des coordonnées précises, une frappe clavier. Puis une nouvelle capture est prise, et le cycle recommence jusqu'à ce que l'objectif soit jugé atteint, ou abandonné.

La boucle voir → décider → agir : l'agent reçoit une capture d'écran, un modèle multimodal localise l'élément et choisit un geste, puis ce geste est exécuté avant qu'une nouvelle capture ne relance le cycle. Faute de signal de retour autre que l'écran, une perception fausse se propage au tour suivant.

Cette boucle ressemble à celle de n'importe quel agent — nous avons décrit ce schéma général de perception, décision et action dans notre article sur les agents. Ce qui change ici, c'est la nature de la perception et celle de l'action. Un agent classique perçoit des données propres et agit par des appels de fonctions. L'agent à usage ordinateur perçoit des pixels bruyants et agit à l'aveugle sur des coordonnées : il doit deviner qu'un rectangle bleu portant « Valider » est un bouton, estimer son centre, et espérer qu'aucune fenêtre ne s'est glissée par-dessus entre-temps.

Chaque maillon de cette chaîne peut se rompre. Une icône mal identifiée, un menu déroulant qui met un instant à s'ouvrir, un défilement mal dosé, et l'agent agit sur un écran qu'il ne voit plus. Comme rien ne l'informe en retour, sauf la capture suivante, il peut poursuivre plusieurs gestes sur une fausse hypothèse avant de s'en apercevoir — s'il s'en aperçoit.

Percevoir par les pixels ou par la structure

Deux écoles de perception coexistent, et la différence est déterminante. La première lit l'écran par les pixels : le modèle ne reçoit qu'une image et doit tout en tirer, y compris les coordonnées où cliquer. C'est l'approche la plus générale — elle fonctionne sur n'importe quelle application, même une image de bureau distant ou un logiciel métier fermé — et la plus difficile, car elle exige ce qu'on nomme le grounding visuel : relier une intention (« ouvrir le second onglet ») à un point exact de l'image.

La seconde lit l'écran par sa structure : sur une page web, l'agent dispose de l'arbre du document (le DOM) ou de l'arbre d'accessibilité, où chaque élément est déjà nommé et positionné. Cliquer devient plus fiable, puisqu'on désigne un nœud plutôt qu'un pixel. Mais cette prise n'existe que là où la structure est exposée : elle disparaît dès qu'on sort du navigateur, ou face à une interface dessinée sur un canevas graphique sans étiquettes.

La même fenêtre lue de deux façons : par les pixels, le modèle ne dispose que d'une image et doit estimer les coordonnées où cliquer — universel mais fragile ; par la structure (DOM ou arbre d'accessibilité), chaque élément est déjà nommé et positionné, on désigne un nœud plutôt qu'un pixel — fiable mais réservé au web et aux applications instrumentées. Les systèmes récents combinent les deux approches.

Les systèmes récents combinent souvent les deux : la structure quand elle existe, les pixels partout ailleurs. Cette hybridation explique pourquoi les mêmes agents réussissent bien mieux dans un navigateur que sur un bureau complet — le web offre une prise que le système d'exploitation refuse.

La fiabilité se mesure, et le verdict est sobre

Pour sortir des démonstrations flatteuses, la communauté a construit des bancs d'essai qui font exécuter à l'agent des tâches réelles et vérifient l'état final du système — pas la vraisemblance d'un récit, mais le fait que le fichier existe, que le formulaire est soumis, que la valeur est correcte.

Le plus exigeant est OSWorld. Selon l'article de référence, il comprend 369 tâches sur de vrais systèmes d'exploitation — Ubuntu, Windows, macOS — mêlant navigateur, bureautique, terminal et manipulation de fichiers. Le chiffre qui a marqué les esprits à sa parution en 2024 : un humain réussit 72,36 % des tâches, tandis que le meilleur agent évalué plafonnait à 12,24 %. Les auteurs pointaient déjà la cause : un grounding visuel défaillant et un manque de connaissance opératoire des logiciels.

Le même schéma se retrouve ailleurs. WebArena, décrit dans sa publication, place l'agent dans des sites web reconstitués — commerce, forum, gestion de contenu, développement collaboratif — et vérifie la réussite fonctionnelle : à sa sortie, un agent fondé sur GPT-4 atteignait 14,41 % contre 78,24 % pour l'humain. Côté mobile, AndroidWorld, présenté dans son article, propose 116 tâches paramétrées sur 20 applications Android réelles, avec vérification de l'état de l'appareil ; le meilleur agent testé y réussissait 30,6 %.

Ces chiffres fondateurs ont vieilli vite : les modèles multimodaux de 2025 et 2026 ont fait progresser les scores de façon spectaculaire, et OSWorld maintient un classement public qui bouge de mois en mois. Mais deux constats résistent. D'abord, l'écart entre le navigateur et le bureau complet reste marqué : agir dans une page reste bien plus fiable qu'agir sur un système d'exploitation entier. Ensuite, sur les tâches les plus longues, les meilleurs systèmes n'atteignent toujours pas de façon stable le niveau d'un utilisateur humain. Le récit de 2026 n'est plus « c'est possible », c'est « est-ce fiable ? ».

Qui expédie cette capacité, et jusqu'où

Les trois grands laboratoires proposent aujourd'hui une forme de contrôle d'ordinateur, avec des périmètres révélateurs. Anthropic expose un outil « computer use » — toujours en bêta au 22 juillet 2026 selon sa documentation — qui donne au modèle la capture d'écran, le contrôle de la souris et du clavier sur un environnement de bureau, avec une implémentation de référence tournant dans un conteneur isolé.

Google a suivi une autre voie : son modèle Gemini 2.5 Computer Use, publié en préversion le 7 octobre 2025, est explicitement « d'abord optimisé pour les navigateurs web » et, selon Google, « pas encore optimisé pour le contrôle au niveau du système d'exploitation ». Ce cadrage assumé confirme la ligne de fracture décrite plus haut : le web d'abord, parce qu'il offre une prise structurée. OpenAI, de son côté, a introduit dès janvier 2025 un agent d'usage d'ordinateur (CUA), lui aussi centré sur les tâches de navigation web.

Le message commun de ces sources est double. La capacité existe et se diffuse ; mais elle est encadrée par des statuts prudents — bêta, préversion, périmètre restreint au navigateur — qui traduisent une confiance mesurée de ceux-là mêmes qui la construisent. Aucun de ces acteurs ne présente son agent comme un exécutant autonome à qui l'on tourne le dos. Pour un panorama à jour des outils grand public qui s'appuient sur cette brique, nos décryptages d'outils IA suivent les versions et les périmètres, qui changent vite.

Là où ça casse, et comment on l'encadre

Les modes d'échec sont désormais bien identifiés. Le grounding reste la première cause : viser le mauvais pixel, cliquer un élément voisin, rater une cible qui a bougé. Viennent ensuite les interfaces complexes et changeantes — tableaux denses, menus imbriqués, fenêtres modales, contenus qui se chargent avec retard — où l'agent agit sur un état périmé. S'ajoute la difficulté des tâches longues : plus la séquence s'allonge, plus une erreur intermédiaire a le temps de se propager, faute d'un mécanisme fiable pour détecter qu'on s'est trompé et revenir en arrière. Cette gestion du contexte sur la durée est un problème en soi, que nous abordons dans notre article sur la mémoire des agents.

Un risque plus insidieux tient à la nature même de la perception. Puisque l'agent lit l'écran, tout ce qui apparaît à l'écran peut lui parler — y compris un texte hostile glissé dans une page ou une image. La documentation d'Anthropic l'écrit sans détour : « Claude suivra parfois des instructions trouvées dans un contenu même lorsqu'elles entrent en conflit avec vos consignes », et des instructions sur une page web ou dans une image « peuvent passer outre vos instructions ». C'est le mécanisme de l'injection de prompt, transposé au visuel : la surface d'attaque n'est plus seulement le texte fourni à l'agent, mais tout ce que son regard croise.

Face à cela, les mesures d'encadrement recommandées convergent. La documentation officielle d'Anthropic préconise d'utiliser « une machine virtuelle ou un conteneur dédié avec des privilèges minimaux », d'éviter de donner au modèle l'accès à des données sensibles comme des identifiants de connexion, de limiter l'accès internet « à une liste blanche de domaines », et de « demander à un humain de confirmer les décisions susceptibles d'avoir des conséquences réelles significatives » — accepter des cookies, effectuer une transaction financière, accepter des conditions d'utilisation. Google décrit de son côté un « service de sécurité hors modèle » qui évalue chaque action proposée avant son exécution, et la possibilité d'exiger une confirmation pour les actions à haut risque.

On retrouve les deux piliers de tout déploiement défendable : le bac à sable, qui limite ce que l'agent peut casser, et l'humain dans la boucle, qui garde la main sur les gestes irréversibles. C'est l'application directe des garde-fous que nous détaillons par ailleurs : on ne fiabilise pas un agent faillible en améliorant seulement son taux de réussite, mais en rendant ses erreurs sans conséquence et ses décisions lourdes réversibles.

Dans ce cadre, des usages concrets tiennent déjà la route, à condition d'être supervisés. Le remplissage de formulaires répétitifs, la récupération d'informations sur des interfaces sans interface de programmation, l'automatisation de tests d'interface où l'agent rejoue des parcours et signale les régressions : autant de tâches où un humain valide en bout de chaîne, et où une erreur coûte un nouvel essai, pas un dégât. Là où ça casse, c'est dès qu'on demande une longue séquence autonome sur une interface riche, sans point de contrôle — précisément le scénario que les statuts « bêta » invitent à éviter.

L'agent à usage ordinateur est peut-être la forme la plus concrète de la promesse « une IA qui agit à votre place » : rien à intégrer, il se débrouille avec l'interface que vous utilisez déjà. C'est aussi la plus honnête sur ses limites, car l'écran ne pardonne pas — un clic manqué se voit. En 2026, la bonne posture n'est ni l'émerveillement devant une démonstration, ni le rejet devant un score fondateur médiocre, mais la mesure : quelle tâche, combien d'étapes, quel taux réel, quel filet de sécurité. Le reste n'est que promesse.

Une question, un projet IA ?

Vous envisagez d'automatiser un parcours logiciel par un agent qui voit l'écran, et vous voulez cadrer supervision, isolation et points de contrôle — échangeons.

Prendre contact →

Pour aller plus loin : côté pratique, nos décryptages d'outils IA suivent quelles plateformes exposent réellement un contrôle d'ordinateur et sous quel statut ; et notre article sur les garde-fous détaille comment rendre réversibles les gestes d'un agent faillible.