Agents d'utilisation de l'ordinateur : pourquoi une démonstration réussie peut tout de même être un système peu fiable

Les agents capables d'utiliser un ordinateur peuvent désormais cliquer, taper du texte, naviguer, modifier des fichiers, faire fonctionner des applications de bureau et accomplir d'impressionnantes tâches en plusieurs étapes. Cela rend les démonstrations réussies faciles à comprendre et faciles à surinterpréter. Un flux de travail réussi une seule fois montre que l'agent peut réussir dans ces conditions précises. Il n'indique pas à quelle fréquence il réussit, comment il se comporte lorsque l'environnement change, s'il vérifie le résultat, ni avec quel niveau de sécurité il agit lorsque l'objectif devient ambigu.

Pourquoi la démo est le test de fiabilité le plus facile qui soit

Une démo montre habituellement une trajectoire unique qui a fonctionné. L'environnement est connu, la tâche est sélectionnée à l'avance, l'opérateur peut redémarrer après un échec et le public voit le parcours réussi. Les systèmes en production sont au contraire confrontés à une distribution variée : pages différentes, conditions de réseau changeantes, états des comptes, fenêtres contextuelles, latence, modifications de l'interface utilisateur, états cachés, permissions, interruptions et utilisateurs formulant des objectifs de manière imparfaite.

Cette distinction est essentielle, car les agents d'utilisation d'ordinateurs interagissent via des interfaces conçues pour des humains plutôt que par le biais d'API déterministes. Leur boucle d'action dépend de la perception, de l'interprétation de l'état, de la planification, du timing des interactions et de la réponse de l'environnement. De légères modifications peuvent altérer la trajectoire, même lorsque l'objectif de l'utilisateur reste inchangé.

Les travaux WAREX de Microsoft Research mettent le problème en évidence : les agents évalués sur benchmark qui semblent performants dans des cadres contrôlés voient leur taux de réussite chuter considérablement lorsque l'instabilité réaliste du Web est introduite. Cet échec ne signifie pas nécessairement que « le modèle est devenu moins intelligent ». C'est simplement que l'environnement a cessé d'être déterministe.

Capacité, taux de réussite, fiabilité et sécurité sont des affirmations distinctes

L'échelle de fiabilité de l'utilisation de l'ordinateur

Une méthode utile pour évaluer les systèmes d'utilisation d'ordinateurs consiste à passer d'une capacité ponctuelle à des propriétés de fiabilité de plus en plus exigeantes. Les niveaux supérieurs présupposent les niveaux inférieurs, mais ne découlent pas automatiquement d'eux.

Niveau 1 — Capacité : la question posée par la démo

La capacité cherche à déterminer si un agent peut exécuter la tâche, tout simplement. Il s'agit d'un point précieux. Les systèmes d'utilisation d'ordinateurs ont progressé rapidement, et les agents modernes peuvent accomplir des flux de travail que les anciens systèmes ne pouvaient pas exécuter de manière fiable.

Mais la capacité constitue un faible critère de déploiement. Une exécution réussie ne vous dit pas si l'agent réussit 95 % du temps ou 30 % du temps, si les échecs sont inoffensifs ou destructeurs, ni si le succès dépend d'un état particulièrement favorable de la page.

Niveau 2 — Répétabilité : la même tâche reste-t-elle résolue ?

Les trajectoires d'utilisation de l'ordinateur sont stochastiques. Les sorties des modèles varient, les pages se chargent à des vitesses différentes, les états visuels changent et les longs flux de travail créent de nombreuses opportunités de bifurcation. Un test en production devrait donc exécuter la même tâche plusieurs fois plutôt que de considérer une seule trace réussie comme représentative.

Mesurez non seulement le taux de réussite moyen, mais également la distribution des modes de défaillance : mauvais clic, interruption prématurée, confirmation manquée, champ incorrect, action en double, boucle de navigation, hypothèse d'état obsolète et faux rapport de réussite.

Niveau 3 — Robustesse environnementale : que se passe-t-il lorsque le Web se comporte comme le Web ?

Les sites web réels ne sont pas des environnements figés de référence. Des requêtes échouent, des éléments se chargent tardivement, des sessions expirent, des pages changent, des bannières de consentement apparaissent, des serveurs renvoient des erreurs et les conditions réseau fluctuent.

WAREX évalue cet écart en injectant une instabilité web réaliste dans les environnements de référence existants et constate des baisses significatives du taux de réussite des tâches. Il s'agit d'un enseignement essentiel pour la production : un benchmark peut mesurer la compétence sur une tâche tout en sous-évaluant la capacité de récupération face à l'instabilité environnementale.

Niveau 4 — Contrôle à long terme : le succès évolue lorsque la tâche devient un travail réel

Les tâches courtes masquent une classe de défaillances qui n'apparaissent qu'après des dizaines ou des centaines d'actions : contraintes oubliées, travail dupliqué, achèvement prématuré, changements d'état manqués, incohérences entre applications et accumulation de petites erreurs.

OSWorld 2.0 a été conçu spécifiquement autour de flux de travail réels à long terme. Ses tâches prennent aux utilisateurs humains une médiane d'environ 1,6 heure et nécessitent bien plus d'appels d'outils que les benchmarks d'utilisation de l'ordinateur précédents. Selon sa métrique principale d'achèvement, même les systèmes évalués les plus performants restent loin d'une fiabilité totale des tâches.

WeaveBench parvient à une conclusion similaire sous un autre angle. Il évalue des flux de travail hybrides combinant interface graphique (GUI), interface en ligne de commande (CLI) et code, et rapporte que la meilleure combinaison modèle-moteur d'exécution évaluée ne réussit que 41,2 % des tâches. Le résultat essentiel n'est pas un chiffre de classement ; c'est que l'orchestration réaliste entre interfaces met au jour des défaillances masquées par des tâches plus simples à interface unique.

Niveau 5 — Conscience de l'état : l'environnement peut changer sous le plan d'action

Les tâches de longue durée dépendent souvent d'un état masqué ou changeant : un e-mail arrive, un calendrier est modifié, un formulaire est envoyé, un processus en arrière-plan se termine, une session de navigateur expire, un utilisateur modifie un fichier ou la disponibilité d'un système externe change.

SentinelBench de Microsoft soutient que de nombreuses tâches de longue durée ne devraient pas du tout être résolues par une action continue. Le comportement approprié peut consister à surveiller, attendre un événement externe, puis agir lorsque l'état change. Il s'agit d'une compétence distincte de celle consistant à cliquer plus vite ou à planifier davantage d'étapes.

Un agent d'utilisation de l'ordinateur fiable doit donc faire la distinction entre immédiatement actionnable, en attente d'état, état modifié et hypothèse invalidée.

Niveau 6 — Vérification des résultats : l'action a-t-elle réellement fonctionné ?

Un agent peut exécuter une séquence en apparence correcte tout en échouant à accomplir la tâche. Un clic sur un bouton peut ne pas être pris en compte. Un formulaire peut échouer à une validation masquée. Un fichier peut être enregistré dans le mauvais répertoire. Un achat peut rester non confirmé. Un site peut afficher un écran semblant indiquer un succès alors que l'opération sous-jacente a échoué.

Les directives actuelles d'OpenAI concernant l'utilisation de l'ordinateur recommandent explicitement de délimiter et de vérifier l'exécution plutôt que de se fier uniquement à la réponse finale du modèle. Les travaux de Microsoft Research sur les vérificateurs d'utilisation de l'ordinateur parviennent à la même conclusion par l'évaluation : le processus et le résultat doivent être évalués séparément.

Les recherches sur l'Universal Verifier indiquent que les configurations de vérificateurs antérieures peuvent produire des taux élevés de faux positifs, tandis qu'une conception de grille d'évaluation plus rigoureuse et une séparation explicite du processus, du résultat, des défaillances contrôlables et des défaillances incontrôlables améliorent considérablement la concordance avec les annotations humaines.

Niveau 7 — Gestion sécurisée des objectifs : l'agent doit savoir quand ne pas continuer

Les agents utilisant des ordinateurs sont optimisés pour atteindre des objectifs, mais la persistance envers l'objectif peut elle-même devenir un mode de défaillance. Une demande ambiguë, une condition impossible, une instruction contradictoire, une page web suspecte ou un environnement modifié peuvent nécessiter une clarification ou un arrêt plutôt qu'une action supplémentaire.

Le benchmark BLIND-ACT étudie ce problème sous le nom de Blind Goal-Directedness (orientation aveugle vers l'objectif). Parmi les systèmes évalués dans ce travail, les agents ont fréquemment continué à poursuivre des tâches malgré l'ambiguïté, la non-faisabilité, un contexte conflictuel ou d'autres raisons de reconsidérer la situation. Les auteurs identifient des schémas tels que le biais de l'exécution d'abord (execution-first bias) et la primauté de la requête (request primacy).

Cette catégorie de défaillance est cruciale car un agent hautement performant peut aggraver une mauvaise situation plus rapidement. La fiabilité inclut donc une politique définissant quand ne pas agir.

Le stress test de la démo à la production

Avant de déployer un flux de travail utilisant un ordinateur, prenez la démonstration réussie et supprimez systématiquement les hypothèses qui la rendaient facile.

Le succès à un benchmark a une limite de validité

Le score d'un benchmark est une proposition conditionnelle. Il est valide pour un modèle, une infrastructure d'évaluation, un environnement, un ensemble de tâches, un juge, une interface d'outils, un budget d'étapes, une politique de relance, une date et une méthode d'évaluation donnés.

Le chiffre devient trompeur lorsque ces conditions disparaissent de l'affirmation. « L'agent X obtient 80 % » est plus faible que « L'agent X a obtenu 80 % sur le benchmark Y dans l'environnement Z avec le juge J et un budget d'étapes N ». La seconde affirmation préserve la limite qui indique si le chiffre est transférable à votre application.

La réussite du processus et la réussite du résultat doivent être évaluées séparément

WeaveBench rapporte qu'une notation portant uniquement sur le résultat peut surestimer sensiblement les performances d'utilisation de l'ordinateur, car un agent peut produire un artefact apparemment réussi par le biais d'un raccourci ou de preuves fabriquées. Le vérificateur doit inspecter la trajectoire et les livrables, et pas seulement l'affirmation finale.

La fiabilité en production est une distribution, pas un taux de réussite unique

Une évaluation pertinente en production échantillonne les dimensions qui varient réellement dans votre environnement. Pour un flux de travail dans un navigateur, cela peut inclure l'ancienneté du compte, les paramètres régionaux, la taille de la fenêtre d'affichage, la version de la page, la qualité du réseau, l'état d'authentification, le panier existant, les cookies, les fenêtres contextuelles, les autorisations de l'utilisateur et l'interruption éventuelle de l'exécution par un humain.

La fiabilité a besoin d'un budget d'erreur, pas de la perfection

Aucun système en production n'est parfaitement fiable. La question d'ingénierie pertinente est de savoir quelles défaillances sont acceptables, détectables et récupérables. Une tentative infructueuse de tri d'un dossier local n'équivaut pas à l'envoi d'un mauvais e-mail, à l'achat du mauvais produit ou à la modification d'un paramètre de compte.

Classez les actions selon leurs conséquences et leur réversibilité. Les actions réversibles à faible impact peuvent tolérer une plus grande autonomie. Les actions à fort impact, visibles de l'extérieur ou difficiles à annuler nécessitent une confirmation plus stricte, une vérification de l'état, une autorisation et des contrôles post-action.

Une matrice pratique de fiabilité pour l'utilisation de l'ordinateur

Que consigner lors d'une défaillance d'utilisation de l'ordinateur

• Objectif de l'utilisateur et contraintes explicites.
• Version du modèle et de l'environnement de test (harness).
• Versions de l'environnement et des applications.
• Captures d'écran ou observations structurées pertinentes pour la défaillance.
• Actions effectuées avec horodatages.
• Résultats des outils, clics, saisies clavier et navigation.
• Transitions d'état et temps d'attente.
• Événements d'approbation, de refus ou de transfert.
• Erreurs externes et pannes réseau.
• État final observable de l'environnement.
• Résultat rapporté par l'agent.
• Résultat du vérificateur et indication si la défaillance était contrôlable par l'agent.

La comparaison essentielle réside entre le succès rapporté et le succès observable. Un système incapable de distinguer les deux finira par accumuler des faux positifs en production.

La sécurité fait partie intégrante de la fiabilité des agents utilisant l'ordinateur

Les agents utilisant l'ordinateur ne se contentent pas de lire du contenu non fiable ; ils peuvent agir après l'avoir lu. Cela transforme l'injection de prompts, les contenus de pages malveillants et le phishing en risques pesant directement sur le chemin d'exécution.

Les recommandations actuelles d'OpenAI pour l'utilisation de l'ordinateur préconisent d'isoler l'environnement, d'autoriser expressément certains sites et actions, de traiter le contenu à l'écran comme non fiable, de confirmer les actions lourdes de conséquences, de borner l'exécution et de vérifier le résultat réel. De même, l'agent ChatGPT utilise des confirmations, une surveillance contre l'injection de prompts et des modes supervisés pour les contextes sensibles.

Ce principe d'architecture dépasse largement un fournisseur particulier : le contenu observé par l'agent ne doit en aucun cas pouvoir redéfinir l'autorité de l'utilisateur. Une page web peut fournir des données. Elle ne peut pas donner l'autorisation d'envoyer des données ailleurs, d'effectuer un achat, de modifier des identifiants ou de contourner le périmètre de la tâche.

Qu'est-ce qui changerait ce constat ?

L'écart de fiabilité se réduirait si les modèles d'utilisation de l'ordinateur devenaient robustes face aux horizons longs, aux états dynamiques, aux variations d'interface graphique, aux défaillances environnementales et aux objectifs ambigus sur des distributions représentatives de la production. De meilleures API d'état natives, des interfaces standardisées lisibles par machine et une infrastructure de vérification plus solide pourraient également réduire le volume d'interactions IHM fragiles nécessaires.

Le seuil de déploiement évolue également avec les conséquences de la tâche. Un taux de réussite de 70 % peut être utile pour une tâche de recherche supervisée à faible risque, tout en étant inacceptable pour un flux de travail autonome financier ou destructif. La fiabilité doit donc être évaluée au regard du coût de chaque catégorie de défaillance, et non selon un seuil de taux de réussite universel.

Limites

Les benchmarks cités évaluent des environnements différents et ne doivent pas être comparés directement comme s'ils mesuraient la même chose. WAREX met à l'épreuve le manque de fiabilité du web ; WeaveBench cible le travail hybride sur des horizons longs ; OSWorld 2.0 vise des flux de travail longs et réalistes ; BLIND-ACT se concentre sur la gestion des objectifs en contexte d'ambiguïté et d'irréalisabilité.

Les résultats des benchmarks vieillissent également vite. Les améliorations apportées aux modèles, aux bancs d'essai et aux vérificateurs peuvent modifier sensiblement les scores en quelques mois. L'enseignement durable réside donc dans la méthode d'évaluation : varier les conditions, séparer le processus du résultat, vérifier l'état externe et préserver les limites de chaque affirmation de performance.

Conclusion

Les agents d'utilisation d'ordinateurs sont déjà suffisamment performants pour être utiles. C'est précisément la raison pour laquelle la question de l'évaluation a changé. Le défi n'est plus seulement de savoir si un agent peut parcourir un flux de travail en cliquant. Il s'agit de savoir si le système reste fiable lorsque les conditions idéales de la démonstration disparaissent.

Considérez une exécution réussie comme une preuve de capacité. Testez ensuite la répétabilité, la robustesse environnementale, le contrôle sur de longs horizons, la conscience de l'état, la vérification des résultats et la gestion sécurisée des objectifs. Un agent d'utilisation d'ordinateurs destiné à la production n'est pas celui qui sait mener à bien une démonstration. C'est celui dont les limites de défaillance sont connues, mesurées et maîtrisées.

FAQ

Glossaire

Sources principales et lectures complémentaires