[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system:fr":205,"related:post:computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system:fr:1":1918},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","fr","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":1917},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":939,"featuredImage":940,"featuredImageAlt":941,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":942,"publishedAt":943,"createdAt":944,"updatedAt":945,"seoLocalePaths":946,"categories":955,"author":968,"translations":973},"477","Agents d'utilisation de l'ordinateur : pourquoi une démonstration réussie peut tout de même être un système peu fiable","computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Sommaire\">\u003Cstrong class=\"editorjs-toc__title\">Sommaire\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">Pourquoi la démo est le test de fiabilité le plus facile qui soit\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Capacité, taux de réussite, fiabilité et sécurité sont des affirmations distinctes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-12\" class=\"editorjs-toc__link\">L'échelle de fiabilité de l'utilisation de l'ordinateur\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-15\" class=\"editorjs-toc__link\">Niveau 1 — Capacité : la question posée par la démo\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-18\" class=\"editorjs-toc__link\">Niveau 2 — Répétabilité : la même tâche reste-t-elle résolue ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">Niveau 3 — Robustesse environnementale : que se passe-t-il lorsque le Web se comporte comme le Web ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-25\" class=\"editorjs-toc__link\">Niveau 4 — Contrôle à long terme : le succès évolue lorsque la tâche devient un travail réel\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-29\" class=\"editorjs-toc__link\">Niveau 5 — Conscience de l'état : l'environnement peut changer sous le plan d'action\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-33\" class=\"editorjs-toc__link\">Niveau 6 — Vérification des résultats : l'action a-t-elle réellement fonctionné ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-37\" class=\"editorjs-toc__link\">Niveau 7 — Gestion sécurisée des objectifs : l'agent doit savoir quand ne pas continuer\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-41\" class=\"editorjs-toc__link\">Le stress test de la démo à la production\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Le succès à un benchmark a une limite de validité\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-48\" class=\"editorjs-toc__link\">La réussite du processus et la réussite du résultat doivent être évaluées séparément\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">La fiabilité en production est une distribution, pas un taux de réussite unique\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-54\" class=\"editorjs-toc__link\">La fiabilité a besoin d'un budget d'erreur, pas de la perfection\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">Une matrice pratique de fiabilité pour l'utilisation de l'ordinateur\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">Que consigner lors d'une défaillance d'utilisation de l'ordinateur\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">La sécurité fait partie intégrante de la fiabilité des agents utilisant l'ordinateur\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-67\" class=\"editorjs-toc__link\">Qu'est-ce qui changerait ce constat ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">Limites\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-73\" class=\"editorjs-toc__link\">Conclusion\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-76\" class=\"editorjs-toc__link\">FAQ\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">Glossaire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-80\" class=\"editorjs-toc__link\">Sources principales et lectures complémentaires\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Réponse directe\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\"><strong>Une démonstration d'utilisation de l'ordinateur réussie prouve une capacité, non la fiabilité.<\u002Fstrong> La fiabilité en production exige que l'agent réussisse de manière répétée malgré les variations environnementales, se rétablisse des pannes transitoires, préserve les contraintes sur de longs horizons temporels, détecte les états cachés ou changeants, vérifie le résultat effectif et s'arrête ou demande des instructions lorsque l'objectif devient ambigu ou risqué. La véritable question en production n'est pas « L'agent peut-il accomplir cette tâche ? », mais « Sous quelles conditions pouvons-nous lui faire confiance pour accomplir cette tâche de manière répétée ? »\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Un domaine en évolution rapide\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Cet article reflète l'état de la recherche sur les agents d'utilisation d'ordinateurs et les recommandations des plateformes disponibles au <strong>25 septembre 2026<\u002Fstrong>. Les résultats des benchmarks ne sont pas directement comparables entre différents ensembles de tâches, environnements, modèles, limites d'étapes, évaluateurs ou bancs d'essai. Analysez chaque résultat de benchmark conjointement avec ses conditions d'évaluation.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Le modèle utilisé dans cet article\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">L'échelle de fiabilité de l'utilisation de l'ordinateur (Computer-Use Reliability Ladder) et le test de résistance de la démo à la production (Demo-to-Production Stress Test) présentés ci-dessous sont des modèles d'évaluation pratiques proposés ici. Ils ne constituent pas des normes industrielles formelles.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-6\">Pourquoi la démo est le test de fiabilité le plus facile qui soit\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-10\">Capacité, taux de réussite, fiabilité et sécurité sont des affirmations distinctes\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Affirmation\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce que cela prouve réellement\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce que cela ne prouve pas\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent a accompli la tâche une fois\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Capacité démontrée sur une trajectoire observée\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Répétabilité, robustesse, sécurité ou généralisation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent obtient un score élevé sur un benchmark\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Performance dans les conditions de tâches et d'évaluation spécifiques à ce benchmark\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Performance équivalente en production dans des environnements différents\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent atteint généralement l'objectif\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Fréquence de réussite du résultat final\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Processus adéquat, comportement sûr ou preuve que le résultat a été vérifié\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent suit le processus prévu\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qualité de la trajectoire selon les critères évalués\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Acceptation effective du résultat final par l'environnement externe\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'agent évite les actions dangereuses dans un jeu de test\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Performance sur les cas de sécurité répertoriés\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sécurité face à toute nouvelle ambiguïté, injection ou effet secondaire\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-12\">L'échelle de fiabilité de l'utilisation de l'ordinateur\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Échelle de fiabilité de l'utilisation de l'ordinateur\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Capacité\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'agent peut-il accomplir la tâche au moins une fois dans des conditions connues ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Répétabilité\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Peut-il accomplir la même tâche de manière constante au fil de plusieurs essais consécutifs ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Robustesse environnementale\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Résiste-t-il aux variations de timing, aux problèmes de réseau, aux fenêtres pop-up, aux changements d'interface et aux légères perturbations de l'environnement ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Maîtrise sur de longs horizons\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Peut-il préserver les objectifs, les contraintes et la progression à travers de nombreuses étapes, applications et événements différés ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Conscience de l'état\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Peut-il détecter lorsqu'un environnement a changé, lorsqu'un état caché entre en jeu ou lorsqu'une hypothèse n'est plus valable ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Vérification du résultat\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vérifie-t-il que le résultat escompté a bien eu lieu au lieu de simplement se fier à sa propre séquence d'actions ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Gestion sécurisée des objectifs\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Peut-il s'arrêter, poser des questions, refuser d'agir ou rendre la main lorsque l'objectif est ambigu, irréalisable, contradictoire ou à fort impact ?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch3 id=\"section-15\">Niveau 1 — Capacité : la question posée par la démo\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"section-18\">Niveau 2 — Répétabilité : la même tâche reste-t-elle résolue ?\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"section-21\">Niveau 3 — Robustesse environnementale : que se passe-t-il lorsque le Web se comporte comme le Web ?\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--tip my-6 rounded-xl border p-5 border-violet-300 bg-violet-50 dark:border-violet-900 dark:bg-violet-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Test de fiabilité\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Injectez des délais, des pannes HTTP transitoires, des états de page obsolètes, des fenêtres modales, des expirations de session, des réponses en double et des variations contrôlées de l'interface utilisateur. Si l'agent ne fonctionne que sur le chemin idéal, il s'agit d'un système adapté aux démonstrations, mais non fiable en production.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch3 id=\"section-25\">Niveau 4 — Contrôle à long terme : le succès évolue lorsque la tâche devient un travail réel\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"section-29\">Niveau 5 — Conscience de l'état : l'environnement peut changer sous le plan d'action\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"section-33\">Niveau 6 — Vérification des résultats : l'action a-t-elle réellement fonctionné ?\u003C\u002Fh3>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"section-37\">Niveau 7 — Gestion sécurisée des objectifs : l'agent doit savoir quand ne pas continuer\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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).\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-41\">Le stress test de la démo à la production\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Stress test de la démo à la production\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Réexécuter la tâche propre\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Établir la répétabilité sur plusieurs essais avant d'ajouter de la complexité.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Perturber l'environnement\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Ajouter de la latence, des nouvelles tentatives, des fenêtres contextuelles, des variations de pages, des sessions expirées et des pannes temporaires.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Étendre l'horizon\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Transformer la courte démo en flux de travail réel complet avec état intermédiaire, applications multiples et étapes différées.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Modifier l'état masqué\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Modifier le compte, le fichier, la tâche ou l'état externe après que l'agent a formé un plan et vérifier s'il détecte le changement.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Injecter de l'ambiguïté\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Supprimer une hypothèse importante et vérifier si l'agent pose des questions au lieu de deviner.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Injecter une contradiction contrôlée\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Présenter l'ancien et le nouvel état en même temps et vérifier que l'état actuel faisant autorité prévaut.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Exiger une preuve du résultat\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Faire dépendre l'achèvement de la tâche d'un état final vérifiable, et non de l'auto-évaluation du modèle.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Tester les limites à fort impact\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Confirmer que les actions irréversibles ou sensibles déclenchent l'approbation, le refus ou le transfert attendu.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">9\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">9. Répéter après des modifications de l'infrastructure ou du modèle\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Traiter les mises à niveau de l'environnement d'exécution comme des changements de fiabilité nécessitant des tests de régression.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-44\">Le succès à un benchmark a une limite de validité\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">La limite de validité des réponses : la couche manquante entre pertinence et réponses fiables de l'IA\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Un cadre pour expliciter les conditions sous lesquelles une affirmation de l'IA reste valide et les modifications qui exigent une restriction, un recalcul ou un abandon.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire la limite de validité des réponses →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-48\">La réussite du processus et la réussite du résultat doivent être évaluées séparément\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Quatre issues possibles pour une exécution d'agent sur ordinateur\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Processus\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Résultat\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Interprétation\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Processus correct \u002F résultat correct\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Processus erroné \u002F résultat correct\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Processus correct \u002F résultat erroné\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Processus erroné \u002F résultat erroné\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">La fiabilité en production est une distribution, pas un taux de réussite unique\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Dimension\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Exemple de variation\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi cela importe\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Environnement\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Réseau rapide vs lent, pannes transitoires, temps de chargement des pages\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste les comportements de récupération et d'attente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Interface utilisateur\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Fenêtre d'affichage différente, modale, élément réorganisé, refonte mineure\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste les hypothèses visuelles\u002Fd'action fragiles\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">État\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Connecté\u002Fdéconnecté, panier vide\u002Fnon vide, fichier existant, permissions modifiées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste le raisonnement sur l'état masqué\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Horizon de la tâche\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">5 étapes vs 50+ étapes, une application vs plusieurs applications\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste l'accumulation d'erreurs au cours de la trajectoire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ambiguïté\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Préférence manquante ou instruction utilisateur incomplète\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste si l'agent pose des questions au lieu de deviner\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Conséquence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lecture seule vs achat\u002Fenvoi\u002Fsuppression\u002Fmodification\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste les contrôles de confirmation et d'autorisation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Contenu contradictoire ou malveillant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Injection de prompt ou texte trompeur sur la page\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste la hiérarchie des instructions et le confinement\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Version du modèle \u002F de l'infrastructure\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mise à niveau de l'environnement d'exécution\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Teste la régression liée aux modifications au niveau du système\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-54\">La fiabilité a besoin d'un budget d'erreur, pas de la perfection\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-57\">Une matrice pratique de fiabilité pour l'utilisation de l'ordinateur\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Catégorie d'action\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Exemple\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Contrôle recommandé\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lecture \u002F inspection\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ouvrir des pages, lire des fichiers, collecter des informations\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Délimiter le périmètre, consigner les sources, tolérer les erreurs de navigation récupérables\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modification locale réversible\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Modifier un brouillon, réorganiser un espace de travail temporaire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Créer un point de contrôle ou une version avant modification ; vérifier le résultat\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Communication externe\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Envoyer un e-mail, publier du contenu, soumettre un formulaire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confirmation par l'utilisateur ou délégation explicite d'autorité ; vérifier l'état validé\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Financière \u002F transactionnelle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Achat, paiement, abonnement payant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mandat strict, contraintes sur les montants et commerçants, confirmation finale et vérification du reçu\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Destructrice \u002F modifiant les privilèges\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Supprimer des données, modifier les permissions, révoquer des accès\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorisation restreinte, confirmation explicite, procédure réversible si possible, audit post-action\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-59\">Que consigner lors d'une défaillance d'utilisation de l'ordinateur\u003C\u002Fh2>\n\u003Cul>\u003Cli>Objectif de l'utilisateur et contraintes explicites.\u003C\u002Fli>\u003Cli>Version du modèle et de l'environnement de test (harness).\u003C\u002Fli>\u003Cli>Versions de l'environnement et des applications.\u003C\u002Fli>\u003Cli>Captures d'écran ou observations structurées pertinentes pour la défaillance.\u003C\u002Fli>\u003Cli>Actions effectuées avec horodatages.\u003C\u002Fli>\u003Cli>Résultats des outils, clics, saisies clavier et navigation.\u003C\u002Fli>\u003Cli>Transitions d'état et temps d'attente.\u003C\u002Fli>\u003Cli>Événements d'approbation, de refus ou de transfert.\u003C\u002Fli>\u003Cli>Erreurs externes et pannes réseau.\u003C\u002Fli>\u003Cli>État final observable de l'environnement.\u003C\u002Fli>\u003Cli>Résultat rapporté par l'agent.\u003C\u002Fli>\u003Cli>Résultat du vérificateur et indication si la défaillance était contrôlable par l'agent.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">Fiabilité des agents IA : pourquoi la réponse finale ne suffit pas\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Un modèle de fiabilité plus large pour évaluer les trajectoires des agents, l'utilisation des outils et les décisions intermédiaires, plutôt que de considérer la réponse finale comme la preuve du bon fonctionnement du système.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire l'article sur la fiabilité des agents →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-63\">La sécurité fait partie intégrante de la fiabilité des agents utilisant l'ordinateur\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-67\">Qu'est-ce qui changerait ce constat ?\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">Limites\u003C\u002Fh2>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-73\">Conclusion\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-76\">FAQ\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Fiabilité des agents d'utilisation d'ordinateurs\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Une démonstration réussie d'un agent d'utilisation d'ordinateurs prouve-t-elle sa fiabilité en production ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. Elle prouve une capacité sur une trajectoire observée. La fiabilité en production exige des succès répétés face aux variations environnementales, aux tâches de longue durée, aux changements d'état, à l'ambiguïté, aux conditions de récupération et aux actions à fort impact.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Pourquoi les benchmarks d'utilisation d'ordinateurs peuvent-ils sembler bien meilleurs que les performances réelles ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Les benchmarks peuvent faire appel à des environnements plus contrôlés, des tâches plus courtes, des conditions réseau stables, des combinaisons d'applications plus simples ou des critères d'évaluation qui ne capturent pas l'ensemble des défaillances de processus. La limite exacte de validité dépend de chaque benchmark.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Quel est le contrôle de fiabilité le plus important après une action d'utilisation de l'ordinateur ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Vérifier le résultat externe réel. Ne considérez pas l'affirmation finale de l'agent ou sa séquence de clics prévue comme une preuve que le système cible a bien accepté l'opération.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Pourquoi les tâches informatiques à long horizon restent-elles difficiles ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Les erreurs s'accumulent au fil des nombreuses actions, les contraintes sont oubliées, l'état externe change, le travail s'étend sur plusieurs applications, l'état sous-jacent compte, et l'agent doit décider quand attendre, demander, vérifier ou récupérer plutôt que de simplement continuer à agir.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Comment tester un agent de navigation web ou de bureau avant son déploiement ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Répétez des tâches standard, injectez des défaillances environnementales réalistes, variez l'interface utilisateur et les états, étendez l'horizon des flux de travail, introduisez de l'ambiguïté, exigez des preuves de résultat observables, testez les contrôles d'actions à fort impact et réexécutez la suite de tests après chaque modification du modèle ou du banc d'essai.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Les agents d'utilisation d'ordinateurs doivent-ils toujours exiger une confirmation humaine ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Pas pour chaque action à faible risque. Les exigences de confirmation doivent s'adapter en fonction des conséquences, de la réversibilité, de l'autorité et de l'incertitude. Les actions à fort impact, visibles de l'extérieur ou difficiles à annuler nécessitent des contrôles plus stricts.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">Glossaire\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Termes clés relatifs à la fiabilité\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"computer-use-agent\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Agent d'utilisation d'ordinateurs\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un agent d'IA qui interagit avec des interfaces graphiques ou des environnements informatiques par le biais d'observations et d'actions telles que cliquer, taper au clavier, faire défiler, effectuer des opérations sur des fichiers ou exécuter des flux de travail multi-applications.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"repeatability\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Répétabilité\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Le degré auquel un agent peut accomplir la même tâche de manière cohérente au fil d'exécutions répétées, plutôt que de réussir uniquement sur des trajectoires sélectionnées.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"environmental-robustness\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Robustesse environnementale\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">La capacité à préserver un comportement correct en dépit de variations réalistes telles que la latence, les erreurs temporaires, les modifications d'interface utilisateur, l'état des sessions et les états de page imprévus.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"outcome-verification\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Vérification des résultats\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Le fait de vérifier l'état externe réel après une action afin de confirmer que le résultat attendu a bien été obtenu, au lieu de se fier à l'auto-évaluation de l'agent.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"blind-goal-directedness\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Poursuite aveugle de l'objectif (Blind Goal-Directedness)\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un schéma de défaillance dans lequel un agent d'utilisation d'ordinateurs continue de poursuivre un objectif malgré l'ambiguïté, la non-faisabilité, des conditions contradictoires ou des raisons de s'arrêter pour réévaluer la situation.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"reliability-boundary\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Limite de fiabilité\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">L'ensemble des conditions dans lesquelles un taux de réussite observé ou une déclaration de capacité reste suffisamment représentatif pour une décision de déploiement spécifique.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-80\">Sources principales et lectures complémentaires\u003C\u002Fh2>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Ftools-computer-use\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OpenAI — Computer use\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations actuelles pour les développeurs concernant l'isolation des environnements, le traitement du contenu à l'écran comme non fiable, la confirmation des actions à fort impact, la délimitation des exécutions et la vérification des résultats.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fopenai.com\u002Findex\u002Frunning-codex-safely\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OpenAI — Running Codex safely at OpenAI\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations actuelles de production sur les limites techniques, l'approbation humaine, la télémétrie et le contrôle pour les agents interagissant avec des systèmes réels.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fwarex-web-agent-reliability-evaluation-on-existing-benchmarks\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Research — WAREX\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Évaluation de 2026 montrant que le manque de fiabilité réaliste du Web entraîne une baisse significative du taux de réussite des agents de navigation sur les benchmarks existants.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Farticles\u002Fthe-art-of-building-verifiers-for-computer-use-agents\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Research — The Art of Building Verifiers for Computer Use Agents\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Travaux de 2026 sur l'évaluation des processus par rapport aux résultats, les défaillances contrôlables par rapport aux incontrôlables et la vérification fiable des trajectoires.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fweavebench-a-long-horizon-real-world-benchmark-for-computer-use-agents-with-hybrid-interfaces\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Research — WeaveBench\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Benchmark à long horizon de 2026 combinant interfaces graphiques (GUI), interfaces en ligne de commande (CLI) et flux de code, montrant un écart substantiel entre les agents actuels et une exécution fiable en conditions réelles.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2606.29537\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OSWorld 2.0 — Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Benchmark de 2026 axé sur des flux de travail réalistes d'utilisation d'ordinateurs à long horizon, l'état sous-jacent et le raisonnement multi-sources.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fsentinelbench-a-benchmark-for-long-running-monitoring-agents\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Research — SentinelBench\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Benchmark de 2026 pour les tâches évolutives dans le temps où les agents doivent surveiller les environnements et réagir aux changements d'état plutôt que d'agir en continu.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fjust-do-it-computer-use-agents-exhibit-blind-goal-directedness\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Microsoft Research — Just Do It!? Computer-Use Agents Exhibit Blind Goal-Directedness\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recherche ICLR 2026 sur les agents continuant de poursuivre des objectifs ambigus, contradictoires ou irréalisables.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":938},1790353377747,[214,222,228,236,243,250,255,260,265,270,275,305,310,315,344,349,354,359,364,369,374,379,384,389,396,401,406,411,416,421,426,431,436,441,446,451,456,461,466,471,476,481,486,519,524,529,534,543,548,582,587,592,597,638,643,648,653,658,687,692,712,717,725,730,735,740,745,750,755,760,765,770,775,780,785,790,795,825,830,860,865,875,884,893,902,911,920,929],{"id":215,"data":216,"type":220,"tunes":221},"IYG9UPcPY0",{"title":217,"maxLevel":218,"minLevel":219},"Sommaire",3,2,"tableOfContents",{},{"id":223,"data":224,"type":226,"tunes":227},"intro",{"text":225},"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.","paragraph",{},{"id":229,"data":230,"type":234,"tunes":235},"direct",{"body":231,"title":232,"variant":233},"\u003Cstrong>Une démonstration d'utilisation de l'ordinateur réussie prouve une capacité, non la fiabilité.\u003C\u002Fstrong> La fiabilité en production exige que l'agent réussisse de manière répétée malgré les variations environnementales, se rétablisse des pannes transitoires, préserve les contraintes sur de longs horizons temporels, détecte les états cachés ou changeants, vérifie le résultat effectif et s'arrête ou demande des instructions lorsque l'objectif devient ambigu ou risqué. La véritable question en production n'est pas « L'agent peut-il accomplir cette tâche ? », mais « Sous quelles conditions pouvons-nous lui faire confiance pour accomplir cette tâche de manière répétée ? »","Réponse directe","info","callout",{},{"id":237,"data":238,"type":234,"tunes":242},"freshness",{"body":239,"title":240,"variant":241},"Cet article reflète l'état de la recherche sur les agents d'utilisation d'ordinateurs et les recommandations des plateformes disponibles au \u003Cstrong>25 septembre 2026\u003C\u002Fstrong>. Les résultats des benchmarks ne sont pas directement comparables entre différents ensembles de tâches, environnements, modèles, limites d'étapes, évaluateurs ou bancs d'essai. Analysez chaque résultat de benchmark conjointement avec ses conditions d'évaluation.","Un domaine en évolution rapide","warning",{},{"id":244,"data":245,"type":234,"tunes":249},"model-note",{"body":246,"title":247,"variant":248},"L'échelle de fiabilité de l'utilisation de l'ordinateur (Computer-Use Reliability Ladder) et le test de résistance de la démo à la production (Demo-to-Production Stress Test) présentés ci-dessous sont des modèles d'évaluation pratiques proposés ici. Ils ne constituent pas des normes industrielles formelles.","Le modèle utilisé dans cet article","note",{},{"id":251,"data":252,"type":42,"tunes":254},"h-demo",{"text":253,"level":219},"Pourquoi la démo est le test de fiabilité le plus facile qui soit",{},{"id":256,"data":257,"type":226,"tunes":259},"p-demo-1",{"text":258},"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.",{},{"id":261,"data":262,"type":226,"tunes":264},"p-demo-2",{"text":263},"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é.",{},{"id":266,"data":267,"type":226,"tunes":269},"p-demo-3",{"text":268},"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.",{},{"id":271,"data":272,"type":42,"tunes":274},"h-claims",{"text":273,"level":219},"Capacité, taux de réussite, fiabilité et sécurité sont des affirmations distinctes",{},{"id":276,"data":277,"type":303,"tunes":304},"claims-table",{"content":278,"stretched":43,"withHeadings":14},[279,283,287,291,295,299],[280,281,282],"Affirmation","Ce que cela prouve réellement","Ce que cela ne prouve pas",[284,285,286],"L'agent a accompli la tâche une fois","Capacité démontrée sur une trajectoire observée","Répétabilité, robustesse, sécurité ou généralisation",[288,289,290],"L'agent obtient un score élevé sur un benchmark","Performance dans les conditions de tâches et d'évaluation spécifiques à ce benchmark","Performance équivalente en production dans des environnements différents",[292,293,294],"L'agent atteint généralement l'objectif","Fréquence de réussite du résultat final","Processus adéquat, comportement sûr ou preuve que le résultat a été vérifié",[296,297,298],"L'agent suit le processus prévu","Qualité de la trajectoire selon les critères évalués","Acceptation effective du résultat final par l'environnement externe",[300,301,302],"L'agent évite les actions dangereuses dans un jeu de test","Performance sur les cas de sécurité répertoriés","Sécurité face à toute nouvelle ambiguïté, injection ou effet secondaire","table",{},{"id":306,"data":307,"type":42,"tunes":309},"h-ladder",{"text":308,"level":219},"L'échelle de fiabilité de l'utilisation de l'ordinateur",{},{"id":311,"data":312,"type":226,"tunes":314},"p-ladder-intro",{"text":313},"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.",{},{"id":316,"data":317,"type":342,"tunes":343},"ladder-flow",{"steps":318,"title":340,"orientation":341},[319,322,325,328,331,334,337],{"label":320,"description":321},"1. Capacité","L'agent peut-il accomplir la tâche au moins une fois dans des conditions connues ?",{"label":323,"description":324},"2. Répétabilité","Peut-il accomplir la même tâche de manière constante au fil de plusieurs essais consécutifs ?",{"label":326,"description":327},"3. Robustesse environnementale","Résiste-t-il aux variations de timing, aux problèmes de réseau, aux fenêtres pop-up, aux changements d'interface et aux légères perturbations de l'environnement ?",{"label":329,"description":330},"4. Maîtrise sur de longs horizons","Peut-il préserver les objectifs, les contraintes et la progression à travers de nombreuses étapes, applications et événements différés ?",{"label":332,"description":333},"5. Conscience de l'état","Peut-il détecter lorsqu'un environnement a changé, lorsqu'un état caché entre en jeu ou lorsqu'une hypothèse n'est plus valable ?",{"label":335,"description":336},"6. Vérification du résultat","Vérifie-t-il que le résultat escompté a bien eu lieu au lieu de simplement se fier à sa propre séquence d'actions ?",{"label":338,"description":339},"7. Gestion sécurisée des objectifs","Peut-il s'arrêter, poser des questions, refuser d'agir ou rendre la main lorsque l'objectif est ambigu, irréalisable, contradictoire ou à fort impact ?","Échelle de fiabilité de l'utilisation de l'ordinateur","auto","processFlow",{},{"id":345,"data":346,"type":42,"tunes":348},"h-capability",{"text":347,"level":218},"Niveau 1 — Capacité : la question posée par la démo",{},{"id":350,"data":351,"type":226,"tunes":353},"p-capability-1",{"text":352},"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.",{},{"id":355,"data":356,"type":226,"tunes":358},"p-capability-2",{"text":357},"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.",{},{"id":360,"data":361,"type":42,"tunes":363},"h-repeatability",{"text":362,"level":218},"Niveau 2 — Répétabilité : la même tâche reste-t-elle résolue ?",{},{"id":365,"data":366,"type":226,"tunes":368},"p-repeat-1",{"text":367},"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.",{},{"id":370,"data":371,"type":226,"tunes":373},"p-repeat-2",{"text":372},"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.",{},{"id":375,"data":376,"type":42,"tunes":378},"h-robustness",{"text":377,"level":218},"Niveau 3 — Robustesse environnementale : que se passe-t-il lorsque le Web se comporte comme le Web ?",{},{"id":380,"data":381,"type":226,"tunes":383},"p-robust-1",{"text":382},"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.",{},{"id":385,"data":386,"type":226,"tunes":388},"p-robust-2",{"text":387},"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.",{},{"id":390,"data":391,"type":234,"tunes":395},"robust-tip",{"body":392,"title":393,"variant":394},"Injectez des délais, des pannes HTTP transitoires, des états de page obsolètes, des fenêtres modales, des expirations de session, des réponses en double et des variations contrôlées de l'interface utilisateur. Si l'agent ne fonctionne que sur le chemin idéal, il s'agit d'un système adapté aux démonstrations, mais non fiable en production.","Test de fiabilité","tip",{},{"id":397,"data":398,"type":42,"tunes":400},"h-long",{"text":399,"level":218},"Niveau 4 — Contrôle à long terme : le succès évolue lorsque la tâche devient un travail réel",{},{"id":402,"data":403,"type":226,"tunes":405},"p-long-1",{"text":404},"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.",{},{"id":407,"data":408,"type":226,"tunes":410},"p-long-2",{"text":409},"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.",{},{"id":412,"data":413,"type":226,"tunes":415},"p-long-3",{"text":414},"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.",{},{"id":417,"data":418,"type":42,"tunes":420},"h-state",{"text":419,"level":218},"Niveau 5 — Conscience de l'état : l'environnement peut changer sous le plan d'action",{},{"id":422,"data":423,"type":226,"tunes":425},"p-state-1",{"text":424},"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.",{},{"id":427,"data":428,"type":226,"tunes":430},"p-state-2",{"text":429},"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.",{},{"id":432,"data":433,"type":226,"tunes":435},"p-state-3",{"text":434},"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.",{},{"id":437,"data":438,"type":42,"tunes":440},"h-verify",{"text":439,"level":218},"Niveau 6 — Vérification des résultats : l'action a-t-elle réellement fonctionné ?",{},{"id":442,"data":443,"type":226,"tunes":445},"p-verify-1",{"text":444},"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é.",{},{"id":447,"data":448,"type":226,"tunes":450},"p-verify-2",{"text":449},"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.",{},{"id":452,"data":453,"type":226,"tunes":455},"p-verify-3",{"text":454},"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.",{},{"id":457,"data":458,"type":42,"tunes":460},"h-safe-goal",{"text":459,"level":218},"Niveau 7 — Gestion sécurisée des objectifs : l'agent doit savoir quand ne pas continuer",{},{"id":462,"data":463,"type":226,"tunes":465},"p-safe-1",{"text":464},"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.",{},{"id":467,"data":468,"type":226,"tunes":470},"p-safe-2",{"text":469},"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).",{},{"id":472,"data":473,"type":226,"tunes":475},"p-safe-3",{"text":474},"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.",{},{"id":477,"data":478,"type":42,"tunes":480},"h-stress",{"text":479,"level":219},"Le stress test de la démo à la production",{},{"id":482,"data":483,"type":226,"tunes":485},"p-stress-intro",{"text":484},"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.",{},{"id":487,"data":488,"type":342,"tunes":518},"stress-flow",{"steps":489,"title":517,"orientation":341},[490,493,496,499,502,505,508,511,514],{"label":491,"description":492},"1. Réexécuter la tâche propre","Établir la répétabilité sur plusieurs essais avant d'ajouter de la complexité.",{"label":494,"description":495},"2. Perturber l'environnement","Ajouter de la latence, des nouvelles tentatives, des fenêtres contextuelles, des variations de pages, des sessions expirées et des pannes temporaires.",{"label":497,"description":498},"3. Étendre l'horizon","Transformer la courte démo en flux de travail réel complet avec état intermédiaire, applications multiples et étapes différées.",{"label":500,"description":501},"4. Modifier l'état masqué","Modifier le compte, le fichier, la tâche ou l'état externe après que l'agent a formé un plan et vérifier s'il détecte le changement.",{"label":503,"description":504},"5. Injecter de l'ambiguïté","Supprimer une hypothèse importante et vérifier si l'agent pose des questions au lieu de deviner.",{"label":506,"description":507},"6. Injecter une contradiction contrôlée","Présenter l'ancien et le nouvel état en même temps et vérifier que l'état actuel faisant autorité prévaut.",{"label":509,"description":510},"7. Exiger une preuve du résultat","Faire dépendre l'achèvement de la tâche d'un état final vérifiable, et non de l'auto-évaluation du modèle.",{"label":512,"description":513},"8. Tester les limites à fort impact","Confirmer que les actions irréversibles ou sensibles déclenchent l'approbation, le refus ou le transfert attendu.",{"label":515,"description":516},"9. Répéter après des modifications de l'infrastructure ou du modèle","Traiter les mises à niveau de l'environnement d'exécution comme des changements de fiabilité nécessitant des tests de régression.","Stress test de la démo à la production",{},{"id":520,"data":521,"type":42,"tunes":523},"h-benchmark-boundary",{"text":522,"level":219},"Le succès à un benchmark a une limite de validité",{},{"id":525,"data":526,"type":226,"tunes":528},"p-boundary-1",{"text":527},"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.",{},{"id":530,"data":531,"type":226,"tunes":533},"p-boundary-2",{"text":532},"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.",{},{"id":535,"data":536,"type":541,"tunes":542},"ref-avb",{"url":537,"title":538,"excerpt":539,"ctaLabel":540},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","La limite de validité des réponses : la couche manquante entre pertinence et réponses fiables de l'IA","Un cadre pour expliciter les conditions sous lesquelles une affirmation de l'IA reste valide et les modifications qui exigent une restriction, un recalcul ou un abandon.","Lire la limite de validité des réponses","referralArticle",{},{"id":544,"data":545,"type":42,"tunes":547},"h-process-outcome",{"text":546,"level":219},"La réussite du processus et la réussite du résultat doivent être évaluées séparément",{},{"id":549,"data":550,"type":580,"tunes":581},"process-outcome-comparison",{"rows":551,"title":569,"layout":303,"columns":570},[552,557,561,565],{"id":553,"label":554,"values":555},"good-good","Processus correct \u002F résultat correct",[556,556,556],"",{"id":558,"label":559,"values":560},"bad-good","Processus erroné \u002F résultat correct",[556,556,556],{"id":562,"label":563,"values":564},"good-bad","Processus correct \u002F résultat erroné",[556,556,556],{"id":566,"label":567,"values":568},"bad-bad","Processus erroné \u002F résultat erroné",[556,556,556],"Quatre issues possibles pour une exécution d'agent sur ordinateur",[571,574,577],{"id":572,"label":573},"process","Processus",{"id":575,"label":576},"outcome","Résultat",{"id":578,"label":579},"interpretation","Interprétation","comparison",{},{"id":583,"data":584,"type":226,"tunes":586},"p-process-1",{"text":585},"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.",{},{"id":588,"data":589,"type":42,"tunes":591},"h-distribution",{"text":590,"level":219},"La fiabilité en production est une distribution, pas un taux de réussite unique",{},{"id":593,"data":594,"type":226,"tunes":596},"p-dist-1",{"text":595},"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.",{},{"id":598,"data":599,"type":303,"tunes":637},"distribution-table",{"content":600,"stretched":43,"withHeadings":14},[601,605,609,613,617,621,625,629,633],[602,603,604],"Dimension","Exemple de variation","Pourquoi cela importe",[606,607,608],"Environnement","Réseau rapide vs lent, pannes transitoires, temps de chargement des pages","Teste les comportements de récupération et d'attente",[610,611,612],"Interface utilisateur","Fenêtre d'affichage différente, modale, élément réorganisé, refonte mineure","Teste les hypothèses visuelles\u002Fd'action fragiles",[614,615,616],"État","Connecté\u002Fdéconnecté, panier vide\u002Fnon vide, fichier existant, permissions modifiées","Teste le raisonnement sur l'état masqué",[618,619,620],"Horizon de la tâche","5 étapes vs 50+ étapes, une application vs plusieurs applications","Teste l'accumulation d'erreurs au cours de la trajectoire",[622,623,624],"Ambiguïté","Préférence manquante ou instruction utilisateur incomplète","Teste si l'agent pose des questions au lieu de deviner",[626,627,628],"Conséquence","Lecture seule vs achat\u002Fenvoi\u002Fsuppression\u002Fmodification","Teste les contrôles de confirmation et d'autorisation",[630,631,632],"Contenu contradictoire ou malveillant","Injection de prompt ou texte trompeur sur la page","Teste la hiérarchie des instructions et le confinement",[634,635,636],"Version du modèle \u002F de l'infrastructure","Mise à niveau de l'environnement d'exécution","Teste la régression liée aux modifications au niveau du système",{},{"id":639,"data":640,"type":42,"tunes":642},"h-budget",{"text":641,"level":219},"La fiabilité a besoin d'un budget d'erreur, pas de la perfection",{},{"id":644,"data":645,"type":226,"tunes":647},"p-budget-1",{"text":646},"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.",{},{"id":649,"data":650,"type":226,"tunes":652},"p-budget-2",{"text":651},"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.",{},{"id":654,"data":655,"type":42,"tunes":657},"h-matrix",{"text":656,"level":219},"Une matrice pratique de fiabilité pour l'utilisation de l'ordinateur",{},{"id":659,"data":660,"type":303,"tunes":686},"control-matrix",{"content":661,"stretched":43,"withHeadings":14},[662,666,670,674,678,682],[663,664,665],"Catégorie d'action","Exemple","Contrôle recommandé",[667,668,669],"Lecture \u002F inspection","Ouvrir des pages, lire des fichiers, collecter des informations","Délimiter le périmètre, consigner les sources, tolérer les erreurs de navigation récupérables",[671,672,673],"Modification locale réversible","Modifier un brouillon, réorganiser un espace de travail temporaire","Créer un point de contrôle ou une version avant modification ; vérifier le résultat",[675,676,677],"Communication externe","Envoyer un e-mail, publier du contenu, soumettre un formulaire","Confirmation par l'utilisateur ou délégation explicite d'autorité ; vérifier l'état validé",[679,680,681],"Financière \u002F transactionnelle","Achat, paiement, abonnement payant","Mandat strict, contraintes sur les montants et commerçants, confirmation finale et vérification du reçu",[683,684,685],"Destructrice \u002F modifiant les privilèges","Supprimer des données, modifier les permissions, révoquer des accès","Autorisation restreinte, confirmation explicite, procédure réversible si possible, audit post-action",{},{"id":688,"data":689,"type":42,"tunes":691},"h-log",{"text":690,"level":219},"Que consigner lors d'une défaillance d'utilisation de l'ordinateur",{},{"id":693,"data":694,"type":710,"tunes":711},"log-list",{"meta":695,"items":696,"style":709},{},[697,698,699,700,701,702,703,704,705,706,707,708],"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.","unordered","list",{},{"id":713,"data":714,"type":226,"tunes":716},"p-log-1",{"text":715},"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.",{},{"id":718,"data":719,"type":541,"tunes":724},"ref-reliability",{"url":720,"title":721,"excerpt":722,"ctaLabel":723},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","Fiabilité des agents IA : pourquoi la réponse finale ne suffit pas","Un modèle de fiabilité plus large pour évaluer les trajectoires des agents, l'utilisation des outils et les décisions intermédiaires, plutôt que de considérer la réponse finale comme la preuve du bon fonctionnement du système.","Lire l'article sur la fiabilité des agents",{},{"id":726,"data":727,"type":42,"tunes":729},"h-security",{"text":728,"level":219},"La sécurité fait partie intégrante de la fiabilité des agents utilisant l'ordinateur",{},{"id":731,"data":732,"type":226,"tunes":734},"p-sec-1",{"text":733},"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.",{},{"id":736,"data":737,"type":226,"tunes":739},"p-sec-2",{"text":738},"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.",{},{"id":741,"data":742,"type":226,"tunes":744},"p-sec-3",{"text":743},"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.",{},{"id":746,"data":747,"type":42,"tunes":749},"h-change",{"text":748,"level":219},"Qu'est-ce qui changerait ce constat ?",{},{"id":751,"data":752,"type":226,"tunes":754},"p-change-1",{"text":753},"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.",{},{"id":756,"data":757,"type":226,"tunes":759},"p-change-2",{"text":758},"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.",{},{"id":761,"data":762,"type":42,"tunes":764},"h-limitations",{"text":763,"level":219},"Limites",{},{"id":766,"data":767,"type":226,"tunes":769},"p-limit-1",{"text":768},"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é.",{},{"id":771,"data":772,"type":226,"tunes":774},"p-limit-2",{"text":773},"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.",{},{"id":776,"data":777,"type":42,"tunes":779},"h-conclusion",{"text":778,"level":219},"Conclusion",{},{"id":781,"data":782,"type":226,"tunes":784},"p-conclusion-1",{"text":783},"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.",{},{"id":786,"data":787,"type":226,"tunes":789},"p-conclusion-2",{"text":788},"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.",{},{"id":791,"data":792,"type":42,"tunes":794},"h-faq",{"text":793,"level":219},"FAQ",{},{"id":796,"data":797,"type":796,"tunes":824},"faq",{"items":798,"title":823},[799,803,807,811,815,819],{"id":800,"answer":801,"question":802},"faq1","Non. Elle prouve une capacité sur une trajectoire observée. La fiabilité en production exige des succès répétés face aux variations environnementales, aux tâches de longue durée, aux changements d'état, à l'ambiguïté, aux conditions de récupération et aux actions à fort impact.","Une démonstration réussie d'un agent d'utilisation d'ordinateurs prouve-t-elle sa fiabilité en production ?",{"id":804,"answer":805,"question":806},"faq2","Les benchmarks peuvent faire appel à des environnements plus contrôlés, des tâches plus courtes, des conditions réseau stables, des combinaisons d'applications plus simples ou des critères d'évaluation qui ne capturent pas l'ensemble des défaillances de processus. La limite exacte de validité dépend de chaque benchmark.","Pourquoi les benchmarks d'utilisation d'ordinateurs peuvent-ils sembler bien meilleurs que les performances réelles ?",{"id":808,"answer":809,"question":810},"faq3","Vérifier le résultat externe réel. Ne considérez pas l'affirmation finale de l'agent ou sa séquence de clics prévue comme une preuve que le système cible a bien accepté l'opération.","Quel est le contrôle de fiabilité le plus important après une action d'utilisation de l'ordinateur ?",{"id":812,"answer":813,"question":814},"faq4","Les erreurs s'accumulent au fil des nombreuses actions, les contraintes sont oubliées, l'état externe change, le travail s'étend sur plusieurs applications, l'état sous-jacent compte, et l'agent doit décider quand attendre, demander, vérifier ou récupérer plutôt que de simplement continuer à agir.","Pourquoi les tâches informatiques à long horizon restent-elles difficiles ?",{"id":816,"answer":817,"question":818},"faq5","Répétez des tâches standard, injectez des défaillances environnementales réalistes, variez l'interface utilisateur et les états, étendez l'horizon des flux de travail, introduisez de l'ambiguïté, exigez des preuves de résultat observables, testez les contrôles d'actions à fort impact et réexécutez la suite de tests après chaque modification du modèle ou du banc d'essai.","Comment tester un agent de navigation web ou de bureau avant son déploiement ?",{"id":820,"answer":821,"question":822},"faq6","Pas pour chaque action à faible risque. Les exigences de confirmation doivent s'adapter en fonction des conséquences, de la réversibilité, de l'autorité et de l'incertitude. Les actions à fort impact, visibles de l'extérieur ou difficiles à annuler nécessitent des contrôles plus stricts.","Les agents d'utilisation d'ordinateurs doivent-ils toujours exiger une confirmation humaine ?","Fiabilité des agents d'utilisation d'ordinateurs",{},{"id":826,"data":827,"type":42,"tunes":829},"h-glossary",{"text":828,"level":219},"Glossaire",{},{"id":831,"data":832,"type":831,"tunes":859},"glossary",{"title":833,"entries":834},"Termes clés relatifs à la fiabilité",[835,839,843,847,851,855],{"term":836,"anchor":837,"definition":838},"Agent d'utilisation d'ordinateurs","computer-use-agent","Un agent d'IA qui interagit avec des interfaces graphiques ou des environnements informatiques par le biais d'observations et d'actions telles que cliquer, taper au clavier, faire défiler, effectuer des opérations sur des fichiers ou exécuter des flux de travail multi-applications.",{"term":840,"anchor":841,"definition":842},"Répétabilité","repeatability","Le degré auquel un agent peut accomplir la même tâche de manière cohérente au fil d'exécutions répétées, plutôt que de réussir uniquement sur des trajectoires sélectionnées.",{"term":844,"anchor":845,"definition":846},"Robustesse environnementale","environmental-robustness","La capacité à préserver un comportement correct en dépit de variations réalistes telles que la latence, les erreurs temporaires, les modifications d'interface utilisateur, l'état des sessions et les états de page imprévus.",{"term":848,"anchor":849,"definition":850},"Vérification des résultats","outcome-verification","Le fait de vérifier l'état externe réel après une action afin de confirmer que le résultat attendu a bien été obtenu, au lieu de se fier à l'auto-évaluation de l'agent.",{"term":852,"anchor":853,"definition":854},"Poursuite aveugle de l'objectif (Blind Goal-Directedness)","blind-goal-directedness","Un schéma de défaillance dans lequel un agent d'utilisation d'ordinateurs continue de poursuivre un objectif malgré l'ambiguïté, la non-faisabilité, des conditions contradictoires ou des raisons de s'arrêter pour réévaluer la situation.",{"term":856,"anchor":857,"definition":858},"Limite de fiabilité","reliability-boundary","L'ensemble des conditions dans lesquelles un taux de réussite observé ou une déclaration de capacité reste suffisamment représentatif pour une décision de déploiement spécifique.",{},{"id":861,"data":862,"type":42,"tunes":864},"h-sources",{"text":863,"level":219},"Sources principales et lectures complémentaires",{},{"id":866,"data":867,"type":873,"tunes":874},"src-openai-computer",{"link":868,"meta":869},"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Ftools-computer-use",{"image":870,"title":871,"description":872},{"url":556},"OpenAI — Computer use","Recommandations actuelles pour les développeurs concernant l'isolation des environnements, le traitement du contenu à l'écran comme non fiable, la confirmation des actions à fort impact, la délimitation des exécutions et la vérification des résultats.","linkTool",{},{"id":876,"data":877,"type":873,"tunes":883},"src-openai-safety",{"link":878,"meta":879},"https:\u002F\u002Fopenai.com\u002Findex\u002Frunning-codex-safely\u002F",{"image":880,"title":881,"description":882},{"url":556},"OpenAI — Running Codex safely at OpenAI","Recommandations actuelles de production sur les limites techniques, l'approbation humaine, la télémétrie et le contrôle pour les agents interagissant avec des systèmes réels.",{},{"id":885,"data":886,"type":873,"tunes":892},"src-ms-warex",{"link":887,"meta":888},"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fwarex-web-agent-reliability-evaluation-on-existing-benchmarks\u002F",{"image":889,"title":890,"description":891},{"url":556},"Microsoft Research — WAREX","Évaluation de 2026 montrant que le manque de fiabilité réaliste du Web entraîne une baisse significative du taux de réussite des agents de navigation sur les benchmarks existants.",{},{"id":894,"data":895,"type":873,"tunes":901},"src-ms-verifier",{"link":896,"meta":897},"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Farticles\u002Fthe-art-of-building-verifiers-for-computer-use-agents\u002F",{"image":898,"title":899,"description":900},{"url":556},"Microsoft Research — The Art of Building Verifiers for Computer Use Agents","Travaux de 2026 sur l'évaluation des processus par rapport aux résultats, les défaillances contrôlables par rapport aux incontrôlables et la vérification fiable des trajectoires.",{},{"id":903,"data":904,"type":873,"tunes":910},"src-ms-weavebench",{"link":905,"meta":906},"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fweavebench-a-long-horizon-real-world-benchmark-for-computer-use-agents-with-hybrid-interfaces\u002F",{"image":907,"title":908,"description":909},{"url":556},"Microsoft Research — WeaveBench","Benchmark à long horizon de 2026 combinant interfaces graphiques (GUI), interfaces en ligne de commande (CLI) et flux de code, montrant un écart substantiel entre les agents actuels et une exécution fiable en conditions réelles.",{},{"id":912,"data":913,"type":873,"tunes":919},"src-osworld2",{"link":914,"meta":915},"https:\u002F\u002Farxiv.org\u002Fabs\u002F2606.29537",{"image":916,"title":917,"description":918},{"url":556},"OSWorld 2.0 — Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks","Benchmark de 2026 axé sur des flux de travail réalistes d'utilisation d'ordinateurs à long horizon, l'état sous-jacent et le raisonnement multi-sources.",{},{"id":921,"data":922,"type":873,"tunes":928},"src-ms-sentinel",{"link":923,"meta":924},"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fsentinelbench-a-benchmark-for-long-running-monitoring-agents\u002F",{"image":925,"title":926,"description":927},{"url":556},"Microsoft Research — SentinelBench","Benchmark de 2026 pour les tâches évolutives dans le temps où les agents doivent surveiller les environnements et réagir aux changements d'état plutôt que d'agir en continu.",{},{"id":930,"data":931,"type":873,"tunes":937},"src-ms-blind",{"link":932,"meta":933},"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fjust-do-it-computer-use-agents-exhibit-blind-goal-directedness\u002F",{"image":934,"title":935,"description":936},{"url":556},"Microsoft Research — Just Do It!? Computer-Use Agents Exhibit Blind Goal-Directedness","Recherche ICLR 2026 sur les agents continuant de poursuivre des objectifs ambigus, contradictoires ou irréalisables.",{},"2.31","Les agents d'utilisation de l'ordinateur peuvent désormais accomplir d'impressionnants flux de travail sur navigateur et sur bureau, mais une seule exécution réussie prouve la capacité—non la fiabilité. Cet article montre comment tester la répétabilité, la robustesse environnementale, le contrôle à long horizon, la conscience de l'état, la vérification des résultats et la gestion sécurisée des objectifs.","\u002Fuploads\u002F2026\u002F09\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system-1790352854690-75qnrg.webp","computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system-1790352854690-75qnrg","PUBLISHED","2026-09-25T12:13:00.000Z","2026-09-25T16:13:28.344Z","2026-09-25T19:19:11.089Z",{"en":947,"de":948,"sr":949,"es":950,"fr":951,"it":952,"ru":953,"zh":954},"\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fde\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fsr\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fes\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Ffr\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fit\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fru\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","\u002Fzh\u002Fblog\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system",[956,960,964],{"id":957,"name":958,"slug":959},58,"Évaluation et garde-fous qualité","evaluation",{"id":961,"name":962,"slug":963},97,"Vérification sur jeu de test","verification",{"id":965,"name":966,"slug":967},73,"Vérification et diff","verification-and-diffing",{"id":969,"login":970,"email":971,"displayName":972},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[974,1563],{"lang":975,"title":976,"content":977,"contentJson":978,"excerpt":1562},"en","Computer-Use Agents: Why a Successful Demo Can Still Be an Unreliable System","{\"time\":1790352872794,\"blocks\":[{\"id\":\"IYG9UPcPY0\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3},\"tunes\":{}},{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Computer-use agents can now click, type, browse, edit files, operate desktop applications, and complete impressive multi-step tasks. That makes successful demos easy to understand and easy to overinterpret. A single completed workflow shows that the agent can succeed under those conditions. It does not show how often it succeeds, how it behaves when the environment changes, whether it verifies the result, or how safely it acts when the goal becomes ambiguous.\"},\"tunes\":{}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>A successful computer-use demo proves capability, not reliability.\u003C\u002Fstrong> Production reliability requires the agent to succeed repeatedly across environmental variation, recover from transient failures, preserve constraints over long horizons, detect hidden or changing state, verify the actual outcome, and stop or ask when the goal becomes ambiguous or unsafe. The correct production question is not “Can the agent do this task?” but “Under which conditions can we trust it to do this task repeatedly?”\"},\"tunes\":{}},{\"id\":\"freshness\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"Fast-moving field\",\"body\":\"This article reflects computer-use agent research and platform guidance available on \u003Cstrong>25 September 2026\u003C\u002Fstrong>. Benchmark results are not directly comparable across different task sets, environments, models, step limits, judges, or harnesses. Treat every benchmark number together with its evaluation conditions.\"},\"tunes\":{}},{\"id\":\"model-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"The model used in this article\",\"body\":\"The Computer-Use Reliability Ladder and Demo-to-Production Stress Test below are practical evaluation models proposed here. They are not formal industry standards.\"},\"tunes\":{}},{\"id\":\"h-demo\",\"type\":\"header\",\"data\":{\"text\":\"Why the demo is the easiest possible reliability test\",\"level\":2},\"tunes\":{}},{\"id\":\"p-demo-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A demo normally shows one trajectory that worked. The environment is known, the task is selected in advance, the operator can restart after a failure, and the audience sees the successful path. Production systems face a distribution instead: different pages, network conditions, account states, pop-ups, latency, UI changes, hidden state, permissions, interruptions, and users who describe goals imperfectly.\"},\"tunes\":{}},{\"id\":\"p-demo-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"That distinction matters because computer-use agents operate through interfaces designed for humans rather than deterministic APIs. Their action loop depends on perception, state interpretation, planning, interaction timing, and environment response. Small changes can alter the trajectory even when the user goal is unchanged.\"},\"tunes\":{}},{\"id\":\"p-demo-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft Research's WAREX work makes the problem explicit: benchmark agents that look capable in controlled settings lose substantial task success when realistic web instability is introduced. The failure is not necessarily “the model became less intelligent.” The environment stopped being deterministic.\"},\"tunes\":{}},{\"id\":\"h-claims\",\"type\":\"header\",\"data\":{\"text\":\"Capability, success rate, reliability, and safety are different claims\",\"level\":2},\"tunes\":{}},{\"id\":\"claims-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Claim\",\"What it actually establishes\",\"What it does not establish\"],[\"The agent completed the task once\",\"Capability under one observed trajectory\",\"Repeatability, robustness, safety, or generalization\"],[\"The agent scores highly on a benchmark\",\"Performance under that benchmark's task and evaluation conditions\",\"Equivalent production performance on different environments\"],[\"The agent usually reaches the goal\",\"Outcome success frequency\",\"Correct process, safe behaviour, or evidence that the result was verified\"],[\"The agent follows the intended process\",\"Trajectory quality under the evaluated rubric\",\"That the external environment actually accepted the final outcome\"],[\"The agent avoids unsafe actions in a test set\",\"Performance on represented safety cases\",\"Safety under every novel ambiguity, injection, or side effect\"]]},\"tunes\":{}},{\"id\":\"h-ladder\",\"type\":\"header\",\"data\":{\"text\":\"The Computer-Use Reliability Ladder\",\"level\":2},\"tunes\":{}},{\"id\":\"p-ladder-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"A useful way to evaluate computer-use systems is to move from one-off capability toward progressively harder reliability properties. Higher levels assume the lower levels but do not follow automatically from them.\"},\"tunes\":{}},{\"id\":\"ladder-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Computer-Use Reliability Ladder\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Capability\",\"description\":\"Can the agent complete the task at least once under known conditions?\"},{\"label\":\"2. Repeatability\",\"description\":\"Can it complete the same task consistently across repeated trials?\"},{\"label\":\"3. Environmental robustness\",\"description\":\"Does it survive timing changes, network issues, pop-ups, UI variation, and small environmental perturbations?\"},{\"label\":\"4. Long-horizon control\",\"description\":\"Can it preserve goals, constraints, and progress across many steps, applications, and delayed events?\"},{\"label\":\"5. State awareness\",\"description\":\"Can it detect when the environment changed, when hidden state matters, or when an assumption is no longer valid?\"},{\"label\":\"6. Outcome verification\",\"description\":\"Does it verify that the intended result actually happened instead of trusting its own action sequence?\"},{\"label\":\"7. Safe goal handling\",\"description\":\"Can it stop, ask, refuse, or hand control back when the goal is ambiguous, infeasible, contradictory, or high impact?\"}]},\"tunes\":{}},{\"id\":\"h-capability\",\"type\":\"header\",\"data\":{\"text\":\"Level 1 — Capability: the demo question\",\"level\":3},\"tunes\":{}},{\"id\":\"p-capability-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Capability asks whether an agent can perform the task at all. This is valuable. Computer-use systems have advanced rapidly, and modern agents can complete workflows that older systems could not execute reliably.\"},\"tunes\":{}},{\"id\":\"p-capability-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"But capability is a weak deployment criterion. One successful run does not tell you whether the agent succeeds 95% of the time or 30% of the time, whether failures are harmless or destructive, or whether success depends on a lucky page state.\"},\"tunes\":{}},{\"id\":\"h-repeatability\",\"type\":\"header\",\"data\":{\"text\":\"Level 2 — Repeatability: does the same task stay solved?\",\"level\":3},\"tunes\":{}},{\"id\":\"p-repeat-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Computer-use trajectories are stochastic. Model outputs vary, pages load at different speeds, visual states change, and long workflows create many branching opportunities. A production test should therefore run the same task multiple times rather than treating one passing trace as representative.\"},\"tunes\":{}},{\"id\":\"p-repeat-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Measure not only the average success rate but also the distribution of failure modes: wrong click, premature termination, missed confirmation, incorrect field, duplicate action, navigation loop, stale-state assumption, and false success report.\"},\"tunes\":{}},{\"id\":\"h-robustness\",\"type\":\"header\",\"data\":{\"text\":\"Level 3 — Environmental robustness: what happens when the web behaves like the web?\",\"level\":3},\"tunes\":{}},{\"id\":\"p-robust-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Real websites are not benchmark fixtures. Requests fail, elements load late, sessions expire, pages change, consent banners appear, servers return errors, and network conditions fluctuate.\"},\"tunes\":{}},{\"id\":\"p-robust-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"WAREX evaluates this gap by injecting realistic web unreliability into existing benchmark environments and reports significant drops in task success. This is a critical production insight: a benchmark can measure task competence while under-measuring recovery from environmental instability.\"},\"tunes\":{}},{\"id\":\"robust-tip\",\"type\":\"callout\",\"data\":{\"variant\":\"tip\",\"title\":\"Reliability test\",\"body\":\"Inject delays, transient HTTP failures, stale page state, modal dialogs, session expiration, duplicate responses, and controlled UI variation. If the agent only works on the clean path, it is a demo-capable system, not a production-reliable one.\"},\"tunes\":{}},{\"id\":\"h-long\",\"type\":\"header\",\"data\":{\"text\":\"Level 4 — Long-horizon control: success changes when the task becomes real work\",\"level\":3},\"tunes\":{}},{\"id\":\"p-long-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Short tasks hide a class of failures that appear only after dozens or hundreds of actions: forgotten constraints, duplicated work, premature completion, missed state changes, cross-application inconsistencies, and accumulated small errors.\"},\"tunes\":{}},{\"id\":\"p-long-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"OSWorld 2.0 was designed specifically around long-horizon real-world workflows. Its tasks take human users a median of roughly 1.6 hours and require many more tool calls than earlier computer-use benchmarks. Under its primary completion metric, even the strongest evaluated systems remain far from complete task reliability.\"},\"tunes\":{}},{\"id\":\"p-long-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"WeaveBench reaches a similar conclusion from another angle. It evaluates hybrid GUI, CLI and code workflows and reports that the best evaluated model-runtime pairing passes only 41.2% of tasks. The important result is not one leaderboard number; it is that realistic cross-interface orchestration exposes failures hidden by simpler single-interface tasks.\"},\"tunes\":{}},{\"id\":\"h-state\",\"type\":\"header\",\"data\":{\"text\":\"Level 5 — State awareness: the environment can change underneath the plan\",\"level\":3},\"tunes\":{}},{\"id\":\"p-state-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Long-running tasks often depend on hidden or changing state: an email arrives, a calendar changes, a form is submitted, a background process finishes, a browser session expires, a user modifies a file, or an external system changes availability.\"},\"tunes\":{}},{\"id\":\"p-state-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Microsoft's SentinelBench argues that many long-running tasks should not be solved through continuous action at all. The correct behaviour may be to monitor, wait for an external event, then act when the state changes. This is a different capability from clicking faster or planning more steps.\"},\"tunes\":{}},{\"id\":\"p-state-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"A reliable computer-use agent therefore needs to distinguish actionable now, waiting for state, state changed, and assumption invalidated.\"},\"tunes\":{}},{\"id\":\"h-verify\",\"type\":\"header\",\"data\":{\"text\":\"Level 6 — Outcome verification: did the action actually work?\",\"level\":3},\"tunes\":{}},{\"id\":\"p-verify-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"An agent can execute an apparently correct sequence and still fail the task. A button click may not register. A form may reject hidden validation. A file may save to the wrong directory. A purchase may remain unconfirmed. A site may display a success-looking screen while the underlying operation failed.\"},\"tunes\":{}},{\"id\":\"p-verify-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"OpenAI's current computer-use guidance explicitly recommends bounding and verifying the run instead of relying only on the model's final answer. Microsoft Research's work on computer-use verifiers reaches the same conclusion from evaluation: process and outcome need to be judged separately.\"},\"tunes\":{}},{\"id\":\"p-verify-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The Universal Verifier research reports that earlier verifier setups can produce high false-positive rates, while stronger rubric design and explicit separation of process, outcome, controllable failures, and uncontrollable failures substantially improve agreement with human labels.\"},\"tunes\":{}},{\"id\":\"h-safe-goal\",\"type\":\"header\",\"data\":{\"text\":\"Level 7 — Safe goal handling: the agent must know when not to continue\",\"level\":3},\"tunes\":{}},{\"id\":\"p-safe-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Computer-use agents are optimized to complete goals, but goal persistence can itself become a failure mode. An ambiguous request, impossible condition, contradictory instruction, suspicious webpage, or changed environment may require clarification or stopping rather than more action.\"},\"tunes\":{}},{\"id\":\"p-safe-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The BLIND-ACT benchmark studies this problem as Blind Goal-Directedness. Across the systems evaluated in that work, agents frequently continued pursuing tasks despite ambiguity, infeasibility, conflicting context, or other reasons to reconsider. The authors identify patterns such as execution-first bias and request primacy.\"},\"tunes\":{}},{\"id\":\"p-safe-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This failure class matters because a highly capable agent can make a bad situation worse faster. Reliability therefore includes a policy for when not to act.\"},\"tunes\":{}},{\"id\":\"h-stress\",\"type\":\"header\",\"data\":{\"text\":\"The Demo-to-Production Stress Test\",\"level\":2},\"tunes\":{}},{\"id\":\"p-stress-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Before deploying a computer-use workflow, take the successful demo and systematically remove the assumptions that made it easy.\"},\"tunes\":{}},{\"id\":\"stress-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Demo-to-Production Stress Test\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Re-run the clean task\",\"description\":\"Establish repeatability over multiple trials before adding complexity.\"},{\"label\":\"2. Perturb the environment\",\"description\":\"Add latency, retries, pop-ups, page variation, stale sessions and temporary failures.\"},{\"label\":\"3. Extend the horizon\",\"description\":\"Turn the short demo into the full real workflow with intermediate state, multiple applications and delayed steps.\"},{\"label\":\"4. Change hidden state\",\"description\":\"Modify account, file, task or external state after the agent has formed a plan and test whether it detects the change.\"},{\"label\":\"5. Inject ambiguity\",\"description\":\"Remove one important assumption and test whether the agent asks instead of guessing.\"},{\"label\":\"6. Inject a controlled contradiction\",\"description\":\"Present old and new state together and verify that authoritative current state wins.\"},{\"label\":\"7. Require outcome proof\",\"description\":\"Make task completion depend on verifiable final state, not the model's self-report.\"},{\"label\":\"8. Test consequential boundaries\",\"description\":\"Confirm that irreversible or sensitive actions trigger the expected approval, refusal or handoff.\"},{\"label\":\"9. Repeat after harness or model changes\",\"description\":\"Treat runtime upgrades as reliability changes that need regression testing.\"}]},\"tunes\":{}},{\"id\":\"h-benchmark-boundary\",\"type\":\"header\",\"data\":{\"text\":\"Benchmark success has a validity boundary\",\"level\":2},\"tunes\":{}},{\"id\":\"p-boundary-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A benchmark score is a conditional statement. It is valid for a particular model, harness, environment, task set, judge, tool interface, step budget, retry policy, date and evaluation method.\"},\"tunes\":{}},{\"id\":\"p-boundary-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The number becomes misleading when those conditions disappear from the claim. “Agent X scores 80%” is weaker than “Agent X scored 80% on benchmark Y under environment Z with judge J and step budget N.” The second statement preserves the boundary that tells you whether the number transfers to your application.\"},\"tunes\":{}},{\"id\":\"ref-avb\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers\",\"title\":\"The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers\",\"excerpt\":\"A framework for making explicit the conditions under which an AI claim remains valid and what changes require restriction, recalculation, or abandonment.\",\"ctaLabel\":\"Read the Answer Validity Boundary\"},\"tunes\":{}},{\"id\":\"h-process-outcome\",\"type\":\"header\",\"data\":{\"text\":\"Process success and outcome success must be scored separately\",\"level\":2},\"tunes\":{}},{\"id\":\"process-outcome-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Four possible outcomes of one computer-use run\",\"layout\":\"table\",\"columns\":[{\"id\":\"process\",\"label\":\"Process\"},{\"id\":\"outcome\",\"label\":\"Outcome\"},{\"id\":\"interpretation\",\"label\":\"Interpretation\"}],\"rows\":[{\"id\":\"good-good\",\"label\":\"Correct process \u002F correct outcome\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"bad-good\",\"label\":\"Wrong process \u002F correct outcome\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"good-bad\",\"label\":\"Correct process \u002F wrong outcome\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"bad-bad\",\"label\":\"Wrong process \u002F wrong outcome\",\"values\":[\"\",\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"p-process-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"WeaveBench reports that outcome-only grading can materially overestimate computer-use performance because an agent may produce an apparently successful artifact through a shortcut or fabricated evidence. The verifier must inspect the trajectory and deliverables, not merely the final claim.\"},\"tunes\":{}},{\"id\":\"h-distribution\",\"type\":\"header\",\"data\":{\"text\":\"Production reliability is a distribution, not a single pass rate\",\"level\":2},\"tunes\":{}},{\"id\":\"p-dist-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A useful production evaluation samples the dimensions that actually vary in your environment. For a browser workflow, that might include account age, locale, viewport, page version, network quality, authentication state, existing cart state, cookies, pop-ups, user permissions and whether a human interrupts the run.\"},\"tunes\":{}},{\"id\":\"distribution-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Dimension\",\"Example variation\",\"Why it matters\"],[\"Environment\",\"Fast vs slow network, transient failures, page timing\",\"Tests recovery and waiting behaviour\"],[\"UI\",\"Different viewport, modal, reordered element, minor redesign\",\"Tests brittle visual\u002Faction assumptions\"],[\"State\",\"Logged in\u002Fout, empty\u002Fnon-empty cart, existing file, changed permissions\",\"Tests hidden-state reasoning\"],[\"Task horizon\",\"5 steps vs 50+ steps, one app vs several apps\",\"Tests accumulated trajectory error\"],[\"Ambiguity\",\"Missing preference or incomplete user instruction\",\"Tests whether the agent asks instead of guesses\"],[\"Consequence\",\"Read-only vs purchase\u002Fsend\u002Fdelete\u002Fchange\",\"Tests confirmation and authorization controls\"],[\"Adversarial content\",\"Prompt injection or misleading page text\",\"Tests instruction hierarchy and containment\"],[\"Model \u002F harness version\",\"Runtime upgrade\",\"Tests regression from system-level changes\"]]},\"tunes\":{}},{\"id\":\"h-budget\",\"type\":\"header\",\"data\":{\"text\":\"Reliability needs a failure budget, not perfection\",\"level\":2},\"tunes\":{}},{\"id\":\"p-budget-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"No production system is perfectly reliable. The useful engineering question is which failures are acceptable, detectable and recoverable. A failed attempt to sort a local folder is not equivalent to sending the wrong email, purchasing the wrong product or changing an account setting.\"},\"tunes\":{}},{\"id\":\"p-budget-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Classify actions by consequence and reversibility. Low-impact reversible actions can tolerate more autonomy. High-impact, externally visible or hard-to-reverse actions need stronger confirmation, state verification, authorization and post-action checks.\"},\"tunes\":{}},{\"id\":\"h-matrix\",\"type\":\"header\",\"data\":{\"text\":\"A practical computer-use reliability matrix\",\"level\":2},\"tunes\":{}},{\"id\":\"control-matrix\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Action class\",\"Example\",\"Recommended control\"],[\"Read \u002F inspect\",\"Open pages, read files, gather information\",\"Bound scope, log sources, tolerate recoverable navigation errors\"],[\"Reversible local change\",\"Edit draft file, reorganize temporary workspace\",\"Checkpoint or version before change; verify result\"],[\"External communication\",\"Send email, publish content, submit form\",\"User confirmation or explicit delegated authority; verify accepted state\"],[\"Financial \u002F transactional\",\"Purchase, checkout, paid subscription\",\"Strict mandate, amount\u002Fmerchant constraints, final confirmation and receipt verification\"],[\"Destructive \u002F privilege-changing\",\"Delete data, change permissions, revoke access\",\"Narrow authorization, explicit confirmation, reversible path where possible, post-action audit\"]]},\"tunes\":{}},{\"id\":\"h-log\",\"type\":\"header\",\"data\":{\"text\":\"What to log for a computer-use failure\",\"level\":2},\"tunes\":{}},{\"id\":\"log-list\",\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"meta\":{},\"items\":[\"User goal and explicit constraints.\",\"Model and harness version.\",\"Environment and application versions.\",\"Screenshots or structured observations relevant to the failure.\",\"Actions taken with timestamps.\",\"Tool, click, keyboard and navigation results.\",\"State transitions and waiting periods.\",\"Approval, refusal or handoff events.\",\"External errors and network failures.\",\"Final observable environment state.\",\"The agent's reported outcome.\",\"Verifier result and whether the failure was controllable by the agent.\"]},\"tunes\":{}},{\"id\":\"p-log-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The crucial comparison is between reported success and observable success. A system that cannot distinguish those two will eventually accumulate false positives in production.\"},\"tunes\":{}},{\"id\":\"ref-reliability\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough\",\"title\":\"AI Agent Reliability: Why the Final Answer Is Not Enough\",\"excerpt\":\"A broader reliability model for evaluating agent trajectories, tool use and intermediate decisions instead of accepting the final answer as proof that the system worked correctly.\",\"ctaLabel\":\"Read the agent reliability article\"},\"tunes\":{}},{\"id\":\"h-security\",\"type\":\"header\",\"data\":{\"text\":\"Security is part of reliability for computer-use agents\",\"level\":2},\"tunes\":{}},{\"id\":\"p-sec-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Computer-use agents do not merely read untrusted content; they can act after reading it. That turns prompt injection, malicious page content and phishing into execution-path risks.\"},\"tunes\":{}},{\"id\":\"p-sec-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"OpenAI's current computer-use guidance recommends isolating the environment, allow-listing sites and actions, treating screen content as untrusted, confirming consequential actions, bounding the run and verifying the actual outcome. ChatGPT agent similarly uses confirmations, prompt-injection monitoring and supervised modes for sensitive contexts.\"},\"tunes\":{}},{\"id\":\"p-sec-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture principle is broader than any one provider: content observed by the agent must not be allowed to redefine the user's authority. A webpage can provide data. It cannot grant permission to send data elsewhere, purchase something, change credentials or override the task boundary.\"},\"tunes\":{}},{\"id\":\"h-change\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The reliability gap would narrow if computer-use models became robust to long horizons, dynamic state, UI variation, environmental failures and ambiguous goals across representative production distributions. Better native state APIs, standardized machine-readable interfaces and stronger verifier infrastructure could also reduce the amount of fragile GUI interaction required.\"},\"tunes\":{}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The deployment threshold also changes with task consequence. A 70% success rate can be useful for a supervised low-risk research task and unacceptable for an autonomous financial or destructive workflow. Reliability must therefore be evaluated against the cost of each failure class, not one universal pass-rate threshold.\"},\"tunes\":{}},{\"id\":\"h-limitations\",\"type\":\"header\",\"data\":{\"text\":\"Limitations\",\"level\":2},\"tunes\":{}},{\"id\":\"p-limit-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The cited benchmarks evaluate different environments and should not be ranked against one another as if they measured the same thing. WAREX stresses web unreliability; WeaveBench targets hybrid long-horizon work; OSWorld 2.0 targets realistic long workflows; BLIND-ACT focuses on goal handling under ambiguity and infeasibility.\"},\"tunes\":{}},{\"id\":\"p-limit-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Benchmark results also age quickly. Model, harness and verifier improvements can materially change scores within months. The durable lesson is therefore the evaluation method: vary conditions, separate process from outcome, verify external state, and preserve the boundary around each performance claim.\"},\"tunes\":{}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"tunes\":{}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Computer-use agents are already capable enough to be useful. That is exactly why the evaluation question has changed. The challenge is no longer only whether an agent can click through a workflow. It is whether the system remains dependable when the clean demo conditions disappear.\"},\"tunes\":{}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Treat one successful run as evidence of capability. Then test repeatability, environmental robustness, long-horizon control, state awareness, outcome verification and safe goal handling. A production computer-use agent is not the one that can complete the demo. It is the one whose failure boundaries are known, measured and controlled.\"},\"tunes\":{}},{\"id\":\"h-faq\",\"type\":\"header\",\"data\":{\"text\":\"FAQ\",\"level\":2},\"tunes\":{}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"Computer-use agent reliability\",\"items\":[{\"id\":\"faq1\",\"question\":\"Does a successful computer-use agent demo prove production reliability?\",\"answer\":\"No. It proves capability under one observed trajectory. Production reliability requires repeated success across environmental variation, long-running tasks, changing state, ambiguity, recovery conditions and consequential actions.\"},{\"id\":\"faq2\",\"question\":\"Why can computer-use benchmarks look much better than real-world performance?\",\"answer\":\"Benchmarks can use more controlled environments, shorter tasks, stable network conditions, simpler application combinations or outcome criteria that do not capture all process failures. The exact validity boundary depends on each benchmark.\"},{\"id\":\"faq3\",\"question\":\"What is the most important reliability check after a computer-use action?\",\"answer\":\"Verify the actual external outcome. Do not treat the agent's final statement or intended click sequence as proof that the target system accepted the operation.\"},{\"id\":\"faq4\",\"question\":\"Why do long-horizon computer tasks remain difficult?\",\"answer\":\"Errors accumulate across many actions, constraints are forgotten, external state changes, work spans multiple applications, hidden state matters, and the agent must decide when to wait, ask, verify or recover rather than simply continue acting.\"},{\"id\":\"faq5\",\"question\":\"How should I test a browser or desktop agent before deployment?\",\"answer\":\"Repeat clean tasks, inject realistic environmental failures, vary UI and state, extend the workflow horizon, introduce ambiguity, require observable outcome proof, test high-impact action controls and rerun the suite after model or harness changes.\"},{\"id\":\"faq6\",\"question\":\"Should computer-use agents always require human confirmation?\",\"answer\":\"Not for every low-risk action. Confirmation requirements should scale with consequence, reversibility, authority and uncertainty. High-impact, externally visible or difficult-to-reverse actions need stronger controls.\"}]},\"tunes\":{}},{\"id\":\"h-glossary\",\"type\":\"header\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"tunes\":{}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Key reliability terms\",\"entries\":[{\"term\":\"Computer-use agent\",\"definition\":\"An AI agent that interacts with graphical user interfaces or computer environments through observations and actions such as clicking, typing, scrolling, file operations or cross-application workflows.\",\"anchor\":\"computer-use-agent\"},{\"term\":\"Repeatability\",\"definition\":\"The degree to which an agent can complete the same task consistently across repeated runs rather than succeeding only on selected trajectories.\",\"anchor\":\"repeatability\"},{\"term\":\"Environmental robustness\",\"definition\":\"The ability to preserve correct behaviour despite realistic variation such as latency, transient errors, UI changes, session state and unexpected page conditions.\",\"anchor\":\"environmental-robustness\"},{\"term\":\"Outcome verification\",\"definition\":\"Checking the actual external state after an action to confirm that the intended result occurred instead of relying on the agent's self-report.\",\"anchor\":\"outcome-verification\"},{\"term\":\"Blind Goal-Directedness\",\"definition\":\"A failure pattern in which a computer-use agent continues pursuing a goal despite ambiguity, infeasibility, contradictory conditions or reasons to stop and reassess.\",\"anchor\":\"blind-goal-directedness\"},{\"term\":\"Reliability boundary\",\"definition\":\"The set of conditions under which an observed success rate or capability claim remains representative enough for a specific deployment decision.\",\"anchor\":\"reliability-boundary\"}]},\"tunes\":{}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and further reading\",\"level\":2},\"tunes\":{}},{\"id\":\"src-openai-computer\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Ftools-computer-use\",\"meta\":{\"title\":\"OpenAI — Computer use\",\"description\":\"Current developer guidance on isolating environments, treating screen content as untrusted, confirming consequential actions, bounding runs and verifying outcomes.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-openai-safety\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fopenai.com\u002Findex\u002Frunning-codex-safely\u002F\",\"meta\":{\"title\":\"OpenAI — Running Codex safely at OpenAI\",\"description\":\"Current production guidance on technical boundaries, human approval, telemetry and control for agents that act on real systems.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-ms-warex\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fwarex-web-agent-reliability-evaluation-on-existing-benchmarks\u002F\",\"meta\":{\"title\":\"Microsoft Research — WAREX\",\"description\":\"2026 evaluation showing that realistic web unreliability causes significant drops in browser-agent task success on existing benchmarks.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-ms-verifier\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Farticles\u002Fthe-art-of-building-verifiers-for-computer-use-agents\u002F\",\"meta\":{\"title\":\"Microsoft Research — The Art of Building Verifiers for Computer Use Agents\",\"description\":\"2026 work on process versus outcome evaluation, controllable versus uncontrollable failures and reliable trajectory verification.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-ms-weavebench\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fweavebench-a-long-horizon-real-world-benchmark-for-computer-use-agents-with-hybrid-interfaces\u002F\",\"meta\":{\"title\":\"Microsoft Research — WeaveBench\",\"description\":\"2026 long-horizon benchmark combining GUI, CLI and code workflows and showing a substantial gap between current agents and reliable real-world completion.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-osworld2\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2606.29537\",\"meta\":{\"title\":\"OSWorld 2.0 — Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks\",\"description\":\"2026 benchmark focused on realistic long-horizon computer-use workflows, hidden state and cross-source reasoning.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-ms-sentinel\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fsentinelbench-a-benchmark-for-long-running-monitoring-agents\u002F\",\"meta\":{\"title\":\"Microsoft Research — SentinelBench\",\"description\":\"2026 benchmark for time-evolving tasks where agents must monitor environments and respond to state changes rather than continuously act.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}},{\"id\":\"src-ms-blind\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fpublication\u002Fjust-do-it-computer-use-agents-exhibit-blind-goal-directedness\u002F\",\"meta\":{\"title\":\"Microsoft Research — Just Do It!? Computer-Use Agents Exhibit Blind Goal-Directedness\",\"description\":\"ICLR 2026 research on agents continuing to pursue ambiguous, contradictory or infeasible goals.\",\"image\":{\"url\":\"\"}}},\"tunes\":{}}],\"version\":\"2.31.6\"}",{"time":979,"blocks":980,"version":1561},1790352872794,[981,985,989,994,999,1004,1008,1012,1016,1020,1024,1052,1056,1060,1086,1090,1094,1098,1102,1106,1110,1114,1118,1122,1127,1131,1135,1139,1143,1147,1151,1155,1159,1163,1167,1171,1175,1179,1183,1187,1191,1195,1199,1231,1235,1239,1243,1250,1254,1278,1282,1286,1290,1329,1333,1337,1341,1345,1373,1377,1394,1398,1405,1409,1413,1417,1421,1425,1429,1433,1437,1441,1445,1448,1452,1456,1459,1482,1486,1509,1513,1519,1525,1531,1537,1543,1549,1555],{"id":215,"data":982,"type":220,"tunes":984},{"title":983,"maxLevel":218,"minLevel":219},"Contents",{},{"id":223,"data":986,"type":226,"tunes":988},{"text":987},"Computer-use agents can now click, type, browse, edit files, operate desktop applications, and complete impressive multi-step tasks. That makes successful demos easy to understand and easy to overinterpret. A single completed workflow shows that the agent can succeed under those conditions. It does not show how often it succeeds, how it behaves when the environment changes, whether it verifies the result, or how safely it acts when the goal becomes ambiguous.",{},{"id":229,"data":990,"type":234,"tunes":993},{"body":991,"title":992,"variant":233},"\u003Cstrong>A successful computer-use demo proves capability, not reliability.\u003C\u002Fstrong> Production reliability requires the agent to succeed repeatedly across environmental variation, recover from transient failures, preserve constraints over long horizons, detect hidden or changing state, verify the actual outcome, and stop or ask when the goal becomes ambiguous or unsafe. The correct production question is not “Can the agent do this task?” but “Under which conditions can we trust it to do this task repeatedly?”","Direct answer",{},{"id":237,"data":995,"type":234,"tunes":998},{"body":996,"title":997,"variant":241},"This article reflects computer-use agent research and platform guidance available on \u003Cstrong>25 September 2026\u003C\u002Fstrong>. Benchmark results are not directly comparable across different task sets, environments, models, step limits, judges, or harnesses. Treat every benchmark number together with its evaluation conditions.","Fast-moving field",{},{"id":244,"data":1000,"type":234,"tunes":1003},{"body":1001,"title":1002,"variant":248},"The Computer-Use Reliability Ladder and Demo-to-Production Stress Test below are practical evaluation models proposed here. They are not formal industry standards.","The model used in this article",{},{"id":251,"data":1005,"type":42,"tunes":1007},{"text":1006,"level":219},"Why the demo is the easiest possible reliability test",{},{"id":256,"data":1009,"type":226,"tunes":1011},{"text":1010},"A demo normally shows one trajectory that worked. The environment is known, the task is selected in advance, the operator can restart after a failure, and the audience sees the successful path. Production systems face a distribution instead: different pages, network conditions, account states, pop-ups, latency, UI changes, hidden state, permissions, interruptions, and users who describe goals imperfectly.",{},{"id":261,"data":1013,"type":226,"tunes":1015},{"text":1014},"That distinction matters because computer-use agents operate through interfaces designed for humans rather than deterministic APIs. Their action loop depends on perception, state interpretation, planning, interaction timing, and environment response. Small changes can alter the trajectory even when the user goal is unchanged.",{},{"id":266,"data":1017,"type":226,"tunes":1019},{"text":1018},"Microsoft Research's WAREX work makes the problem explicit: benchmark agents that look capable in controlled settings lose substantial task success when realistic web instability is introduced. The failure is not necessarily “the model became less intelligent.” The environment stopped being deterministic.",{},{"id":271,"data":1021,"type":42,"tunes":1023},{"text":1022,"level":219},"Capability, success rate, reliability, and safety are different claims",{},{"id":276,"data":1025,"type":303,"tunes":1051},{"content":1026,"stretched":43,"withHeadings":14},[1027,1031,1035,1039,1043,1047],[1028,1029,1030],"Claim","What it actually establishes","What it does not establish",[1032,1033,1034],"The agent completed the task once","Capability under one observed trajectory","Repeatability, robustness, safety, or generalization",[1036,1037,1038],"The agent scores highly on a benchmark","Performance under that benchmark's task and evaluation conditions","Equivalent production performance on different environments",[1040,1041,1042],"The agent usually reaches the goal","Outcome success frequency","Correct process, safe behaviour, or evidence that the result was verified",[1044,1045,1046],"The agent follows the intended process","Trajectory quality under the evaluated rubric","That the external environment actually accepted the final outcome",[1048,1049,1050],"The agent avoids unsafe actions in a test set","Performance on represented safety cases","Safety under every novel ambiguity, injection, or side effect",{},{"id":306,"data":1053,"type":42,"tunes":1055},{"text":1054,"level":219},"The Computer-Use Reliability Ladder",{},{"id":311,"data":1057,"type":226,"tunes":1059},{"text":1058},"A useful way to evaluate computer-use systems is to move from one-off capability toward progressively harder reliability properties. Higher levels assume the lower levels but do not follow automatically from them.",{},{"id":316,"data":1061,"type":342,"tunes":1085},{"steps":1062,"title":1084,"orientation":341},[1063,1066,1069,1072,1075,1078,1081],{"label":1064,"description":1065},"1. Capability","Can the agent complete the task at least once under known conditions?",{"label":1067,"description":1068},"2. Repeatability","Can it complete the same task consistently across repeated trials?",{"label":1070,"description":1071},"3. Environmental robustness","Does it survive timing changes, network issues, pop-ups, UI variation, and small environmental perturbations?",{"label":1073,"description":1074},"4. Long-horizon control","Can it preserve goals, constraints, and progress across many steps, applications, and delayed events?",{"label":1076,"description":1077},"5. State awareness","Can it detect when the environment changed, when hidden state matters, or when an assumption is no longer valid?",{"label":1079,"description":1080},"6. Outcome verification","Does it verify that the intended result actually happened instead of trusting its own action sequence?",{"label":1082,"description":1083},"7. Safe goal handling","Can it stop, ask, refuse, or hand control back when the goal is ambiguous, infeasible, contradictory, or high impact?","Computer-Use Reliability Ladder",{},{"id":345,"data":1087,"type":42,"tunes":1089},{"text":1088,"level":218},"Level 1 — Capability: the demo question",{},{"id":350,"data":1091,"type":226,"tunes":1093},{"text":1092},"Capability asks whether an agent can perform the task at all. This is valuable. Computer-use systems have advanced rapidly, and modern agents can complete workflows that older systems could not execute reliably.",{},{"id":355,"data":1095,"type":226,"tunes":1097},{"text":1096},"But capability is a weak deployment criterion. One successful run does not tell you whether the agent succeeds 95% of the time or 30% of the time, whether failures are harmless or destructive, or whether success depends on a lucky page state.",{},{"id":360,"data":1099,"type":42,"tunes":1101},{"text":1100,"level":218},"Level 2 — Repeatability: does the same task stay solved?",{},{"id":365,"data":1103,"type":226,"tunes":1105},{"text":1104},"Computer-use trajectories are stochastic. Model outputs vary, pages load at different speeds, visual states change, and long workflows create many branching opportunities. A production test should therefore run the same task multiple times rather than treating one passing trace as representative.",{},{"id":370,"data":1107,"type":226,"tunes":1109},{"text":1108},"Measure not only the average success rate but also the distribution of failure modes: wrong click, premature termination, missed confirmation, incorrect field, duplicate action, navigation loop, stale-state assumption, and false success report.",{},{"id":375,"data":1111,"type":42,"tunes":1113},{"text":1112,"level":218},"Level 3 — Environmental robustness: what happens when the web behaves like the web?",{},{"id":380,"data":1115,"type":226,"tunes":1117},{"text":1116},"Real websites are not benchmark fixtures. Requests fail, elements load late, sessions expire, pages change, consent banners appear, servers return errors, and network conditions fluctuate.",{},{"id":385,"data":1119,"type":226,"tunes":1121},{"text":1120},"WAREX evaluates this gap by injecting realistic web unreliability into existing benchmark environments and reports significant drops in task success. This is a critical production insight: a benchmark can measure task competence while under-measuring recovery from environmental instability.",{},{"id":390,"data":1123,"type":234,"tunes":1126},{"body":1124,"title":1125,"variant":394},"Inject delays, transient HTTP failures, stale page state, modal dialogs, session expiration, duplicate responses, and controlled UI variation. If the agent only works on the clean path, it is a demo-capable system, not a production-reliable one.","Reliability test",{},{"id":397,"data":1128,"type":42,"tunes":1130},{"text":1129,"level":218},"Level 4 — Long-horizon control: success changes when the task becomes real work",{},{"id":402,"data":1132,"type":226,"tunes":1134},{"text":1133},"Short tasks hide a class of failures that appear only after dozens or hundreds of actions: forgotten constraints, duplicated work, premature completion, missed state changes, cross-application inconsistencies, and accumulated small errors.",{},{"id":407,"data":1136,"type":226,"tunes":1138},{"text":1137},"OSWorld 2.0 was designed specifically around long-horizon real-world workflows. Its tasks take human users a median of roughly 1.6 hours and require many more tool calls than earlier computer-use benchmarks. Under its primary completion metric, even the strongest evaluated systems remain far from complete task reliability.",{},{"id":412,"data":1140,"type":226,"tunes":1142},{"text":1141},"WeaveBench reaches a similar conclusion from another angle. It evaluates hybrid GUI, CLI and code workflows and reports that the best evaluated model-runtime pairing passes only 41.2% of tasks. The important result is not one leaderboard number; it is that realistic cross-interface orchestration exposes failures hidden by simpler single-interface tasks.",{},{"id":417,"data":1144,"type":42,"tunes":1146},{"text":1145,"level":218},"Level 5 — State awareness: the environment can change underneath the plan",{},{"id":422,"data":1148,"type":226,"tunes":1150},{"text":1149},"Long-running tasks often depend on hidden or changing state: an email arrives, a calendar changes, a form is submitted, a background process finishes, a browser session expires, a user modifies a file, or an external system changes availability.",{},{"id":427,"data":1152,"type":226,"tunes":1154},{"text":1153},"Microsoft's SentinelBench argues that many long-running tasks should not be solved through continuous action at all. The correct behaviour may be to monitor, wait for an external event, then act when the state changes. This is a different capability from clicking faster or planning more steps.",{},{"id":432,"data":1156,"type":226,"tunes":1158},{"text":1157},"A reliable computer-use agent therefore needs to distinguish actionable now, waiting for state, state changed, and assumption invalidated.",{},{"id":437,"data":1160,"type":42,"tunes":1162},{"text":1161,"level":218},"Level 6 — Outcome verification: did the action actually work?",{},{"id":442,"data":1164,"type":226,"tunes":1166},{"text":1165},"An agent can execute an apparently correct sequence and still fail the task. A button click may not register. A form may reject hidden validation. A file may save to the wrong directory. A purchase may remain unconfirmed. A site may display a success-looking screen while the underlying operation failed.",{},{"id":447,"data":1168,"type":226,"tunes":1170},{"text":1169},"OpenAI's current computer-use guidance explicitly recommends bounding and verifying the run instead of relying only on the model's final answer. Microsoft Research's work on computer-use verifiers reaches the same conclusion from evaluation: process and outcome need to be judged separately.",{},{"id":452,"data":1172,"type":226,"tunes":1174},{"text":1173},"The Universal Verifier research reports that earlier verifier setups can produce high false-positive rates, while stronger rubric design and explicit separation of process, outcome, controllable failures, and uncontrollable failures substantially improve agreement with human labels.",{},{"id":457,"data":1176,"type":42,"tunes":1178},{"text":1177,"level":218},"Level 7 — Safe goal handling: the agent must know when not to continue",{},{"id":462,"data":1180,"type":226,"tunes":1182},{"text":1181},"Computer-use agents are optimized to complete goals, but goal persistence can itself become a failure mode. An ambiguous request, impossible condition, contradictory instruction, suspicious webpage, or changed environment may require clarification or stopping rather than more action.",{},{"id":467,"data":1184,"type":226,"tunes":1186},{"text":1185},"The BLIND-ACT benchmark studies this problem as Blind Goal-Directedness. Across the systems evaluated in that work, agents frequently continued pursuing tasks despite ambiguity, infeasibility, conflicting context, or other reasons to reconsider. The authors identify patterns such as execution-first bias and request primacy.",{},{"id":472,"data":1188,"type":226,"tunes":1190},{"text":1189},"This failure class matters because a highly capable agent can make a bad situation worse faster. Reliability therefore includes a policy for when not to act.",{},{"id":477,"data":1192,"type":42,"tunes":1194},{"text":1193,"level":219},"The Demo-to-Production Stress Test",{},{"id":482,"data":1196,"type":226,"tunes":1198},{"text":1197},"Before deploying a computer-use workflow, take the successful demo and systematically remove the assumptions that made it easy.",{},{"id":487,"data":1200,"type":342,"tunes":1230},{"steps":1201,"title":1229,"orientation":341},[1202,1205,1208,1211,1214,1217,1220,1223,1226],{"label":1203,"description":1204},"1. Re-run the clean task","Establish repeatability over multiple trials before adding complexity.",{"label":1206,"description":1207},"2. Perturb the environment","Add latency, retries, pop-ups, page variation, stale sessions and temporary failures.",{"label":1209,"description":1210},"3. Extend the horizon","Turn the short demo into the full real workflow with intermediate state, multiple applications and delayed steps.",{"label":1212,"description":1213},"4. Change hidden state","Modify account, file, task or external state after the agent has formed a plan and test whether it detects the change.",{"label":1215,"description":1216},"5. Inject ambiguity","Remove one important assumption and test whether the agent asks instead of guessing.",{"label":1218,"description":1219},"6. Inject a controlled contradiction","Present old and new state together and verify that authoritative current state wins.",{"label":1221,"description":1222},"7. Require outcome proof","Make task completion depend on verifiable final state, not the model's self-report.",{"label":1224,"description":1225},"8. Test consequential boundaries","Confirm that irreversible or sensitive actions trigger the expected approval, refusal or handoff.",{"label":1227,"description":1228},"9. Repeat after harness or model changes","Treat runtime upgrades as reliability changes that need regression testing.","Demo-to-Production Stress Test",{},{"id":520,"data":1232,"type":42,"tunes":1234},{"text":1233,"level":219},"Benchmark success has a validity boundary",{},{"id":525,"data":1236,"type":226,"tunes":1238},{"text":1237},"A benchmark score is a conditional statement. It is valid for a particular model, harness, environment, task set, judge, tool interface, step budget, retry policy, date and evaluation method.",{},{"id":530,"data":1240,"type":226,"tunes":1242},{"text":1241},"The number becomes misleading when those conditions disappear from the claim. “Agent X scores 80%” is weaker than “Agent X scored 80% on benchmark Y under environment Z with judge J and step budget N.” The second statement preserves the boundary that tells you whether the number transfers to your application.",{},{"id":535,"data":1244,"type":541,"tunes":1249},{"url":1245,"title":1246,"excerpt":1247,"ctaLabel":1248},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","The Answer Validity Boundary: The Missing Layer Between Relevance and Reliable AI Answers","A framework for making explicit the conditions under which an AI claim remains valid and what changes require restriction, recalculation, or abandonment.","Read the Answer Validity Boundary",{},{"id":544,"data":1251,"type":42,"tunes":1253},{"text":1252,"level":219},"Process success and outcome success must be scored separately",{},{"id":549,"data":1255,"type":580,"tunes":1277},{"rows":1256,"title":1269,"layout":303,"columns":1270},[1257,1260,1263,1266],{"id":553,"label":1258,"values":1259},"Correct process \u002F correct outcome",[556,556,556],{"id":558,"label":1261,"values":1262},"Wrong process \u002F correct outcome",[556,556,556],{"id":562,"label":1264,"values":1265},"Correct process \u002F wrong outcome",[556,556,556],{"id":566,"label":1267,"values":1268},"Wrong process \u002F wrong outcome",[556,556,556],"Four possible outcomes of one computer-use run",[1271,1273,1275],{"id":572,"label":1272},"Process",{"id":575,"label":1274},"Outcome",{"id":578,"label":1276},"Interpretation",{},{"id":583,"data":1279,"type":226,"tunes":1281},{"text":1280},"WeaveBench reports that outcome-only grading can materially overestimate computer-use performance because an agent may produce an apparently successful artifact through a shortcut or fabricated evidence. The verifier must inspect the trajectory and deliverables, not merely the final claim.",{},{"id":588,"data":1283,"type":42,"tunes":1285},{"text":1284,"level":219},"Production reliability is a distribution, not a single pass rate",{},{"id":593,"data":1287,"type":226,"tunes":1289},{"text":1288},"A useful production evaluation samples the dimensions that actually vary in your environment. For a browser workflow, that might include account age, locale, viewport, page version, network quality, authentication state, existing cart state, cookies, pop-ups, user permissions and whether a human interrupts the run.",{},{"id":598,"data":1291,"type":303,"tunes":1328},{"content":1292,"stretched":43,"withHeadings":14},[1293,1296,1300,1304,1308,1312,1316,1320,1324],[602,1294,1295],"Example variation","Why it matters",[1297,1298,1299],"Environment","Fast vs slow network, transient failures, page timing","Tests recovery and waiting behaviour",[1301,1302,1303],"UI","Different viewport, modal, reordered element, minor redesign","Tests brittle visual\u002Faction assumptions",[1305,1306,1307],"State","Logged in\u002Fout, empty\u002Fnon-empty cart, existing file, changed permissions","Tests hidden-state reasoning",[1309,1310,1311],"Task horizon","5 steps vs 50+ steps, one app vs several apps","Tests accumulated trajectory error",[1313,1314,1315],"Ambiguity","Missing preference or incomplete user instruction","Tests whether the agent asks instead of guesses",[1317,1318,1319],"Consequence","Read-only vs purchase\u002Fsend\u002Fdelete\u002Fchange","Tests confirmation and authorization controls",[1321,1322,1323],"Adversarial content","Prompt injection or misleading page text","Tests instruction hierarchy and containment",[1325,1326,1327],"Model \u002F harness version","Runtime upgrade","Tests regression from system-level changes",{},{"id":639,"data":1330,"type":42,"tunes":1332},{"text":1331,"level":219},"Reliability needs a failure budget, not perfection",{},{"id":644,"data":1334,"type":226,"tunes":1336},{"text":1335},"No production system is perfectly reliable. The useful engineering question is which failures are acceptable, detectable and recoverable. A failed attempt to sort a local folder is not equivalent to sending the wrong email, purchasing the wrong product or changing an account setting.",{},{"id":649,"data":1338,"type":226,"tunes":1340},{"text":1339},"Classify actions by consequence and reversibility. Low-impact reversible actions can tolerate more autonomy. High-impact, externally visible or hard-to-reverse actions need stronger confirmation, state verification, authorization and post-action checks.",{},{"id":654,"data":1342,"type":42,"tunes":1344},{"text":1343,"level":219},"A practical computer-use reliability matrix",{},{"id":659,"data":1346,"type":303,"tunes":1372},{"content":1347,"stretched":43,"withHeadings":14},[1348,1352,1356,1360,1364,1368],[1349,1350,1351],"Action class","Example","Recommended control",[1353,1354,1355],"Read \u002F inspect","Open pages, read files, gather information","Bound scope, log sources, tolerate recoverable navigation errors",[1357,1358,1359],"Reversible local change","Edit draft file, reorganize temporary workspace","Checkpoint or version before change; verify result",[1361,1362,1363],"External communication","Send email, publish content, submit form","User confirmation or explicit delegated authority; verify accepted state",[1365,1366,1367],"Financial \u002F transactional","Purchase, checkout, paid subscription","Strict mandate, amount\u002Fmerchant constraints, final confirmation and receipt verification",[1369,1370,1371],"Destructive \u002F privilege-changing","Delete data, change permissions, revoke access","Narrow authorization, explicit confirmation, reversible path where possible, post-action audit",{},{"id":688,"data":1374,"type":42,"tunes":1376},{"text":1375,"level":219},"What to log for a computer-use failure",{},{"id":693,"data":1378,"type":710,"tunes":1393},{"meta":1379,"items":1380,"style":709},{},[1381,1382,1383,1384,1385,1386,1387,1388,1389,1390,1391,1392],"User goal and explicit constraints.","Model and harness version.","Environment and application versions.","Screenshots or structured observations relevant to the failure.","Actions taken with timestamps.","Tool, click, keyboard and navigation results.","State transitions and waiting periods.","Approval, refusal or handoff events.","External errors and network failures.","Final observable environment state.","The agent's reported outcome.","Verifier result and whether the failure was controllable by the agent.",{},{"id":713,"data":1395,"type":226,"tunes":1397},{"text":1396},"The crucial comparison is between reported success and observable success. A system that cannot distinguish those two will eventually accumulate false positives in production.",{},{"id":718,"data":1399,"type":541,"tunes":1404},{"url":1400,"title":1401,"excerpt":1402,"ctaLabel":1403},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","AI Agent Reliability: Why the Final Answer Is Not Enough","A broader reliability model for evaluating agent trajectories, tool use and intermediate decisions instead of accepting the final answer as proof that the system worked correctly.","Read the agent reliability article",{},{"id":726,"data":1406,"type":42,"tunes":1408},{"text":1407,"level":219},"Security is part of reliability for computer-use agents",{},{"id":731,"data":1410,"type":226,"tunes":1412},{"text":1411},"Computer-use agents do not merely read untrusted content; they can act after reading it. That turns prompt injection, malicious page content and phishing into execution-path risks.",{},{"id":736,"data":1414,"type":226,"tunes":1416},{"text":1415},"OpenAI's current computer-use guidance recommends isolating the environment, allow-listing sites and actions, treating screen content as untrusted, confirming consequential actions, bounding the run and verifying the actual outcome. ChatGPT agent similarly uses confirmations, prompt-injection monitoring and supervised modes for sensitive contexts.",{},{"id":741,"data":1418,"type":226,"tunes":1420},{"text":1419},"The architecture principle is broader than any one provider: content observed by the agent must not be allowed to redefine the user's authority. A webpage can provide data. It cannot grant permission to send data elsewhere, purchase something, change credentials or override the task boundary.",{},{"id":746,"data":1422,"type":42,"tunes":1424},{"text":1423,"level":219},"What would change this answer?",{},{"id":751,"data":1426,"type":226,"tunes":1428},{"text":1427},"The reliability gap would narrow if computer-use models became robust to long horizons, dynamic state, UI variation, environmental failures and ambiguous goals across representative production distributions. Better native state APIs, standardized machine-readable interfaces and stronger verifier infrastructure could also reduce the amount of fragile GUI interaction required.",{},{"id":756,"data":1430,"type":226,"tunes":1432},{"text":1431},"The deployment threshold also changes with task consequence. A 70% success rate can be useful for a supervised low-risk research task and unacceptable for an autonomous financial or destructive workflow. Reliability must therefore be evaluated against the cost of each failure class, not one universal pass-rate threshold.",{},{"id":761,"data":1434,"type":42,"tunes":1436},{"text":1435,"level":219},"Limitations",{},{"id":766,"data":1438,"type":226,"tunes":1440},{"text":1439},"The cited benchmarks evaluate different environments and should not be ranked against one another as if they measured the same thing. WAREX stresses web unreliability; WeaveBench targets hybrid long-horizon work; OSWorld 2.0 targets realistic long workflows; BLIND-ACT focuses on goal handling under ambiguity and infeasibility.",{},{"id":771,"data":1442,"type":226,"tunes":1444},{"text":1443},"Benchmark results also age quickly. Model, harness and verifier improvements can materially change scores within months. The durable lesson is therefore the evaluation method: vary conditions, separate process from outcome, verify external state, and preserve the boundary around each performance claim.",{},{"id":776,"data":1446,"type":42,"tunes":1447},{"text":778,"level":219},{},{"id":781,"data":1449,"type":226,"tunes":1451},{"text":1450},"Computer-use agents are already capable enough to be useful. That is exactly why the evaluation question has changed. The challenge is no longer only whether an agent can click through a workflow. It is whether the system remains dependable when the clean demo conditions disappear.",{},{"id":786,"data":1453,"type":226,"tunes":1455},{"text":1454},"Treat one successful run as evidence of capability. Then test repeatability, environmental robustness, long-horizon control, state awareness, outcome verification and safe goal handling. A production computer-use agent is not the one that can complete the demo. It is the one whose failure boundaries are known, measured and controlled.",{},{"id":791,"data":1457,"type":42,"tunes":1458},{"text":793,"level":219},{},{"id":796,"data":1460,"type":796,"tunes":1481},{"items":1461,"title":1480},[1462,1465,1468,1471,1474,1477],{"id":800,"answer":1463,"question":1464},"No. It proves capability under one observed trajectory. Production reliability requires repeated success across environmental variation, long-running tasks, changing state, ambiguity, recovery conditions and consequential actions.","Does a successful computer-use agent demo prove production reliability?",{"id":804,"answer":1466,"question":1467},"Benchmarks can use more controlled environments, shorter tasks, stable network conditions, simpler application combinations or outcome criteria that do not capture all process failures. The exact validity boundary depends on each benchmark.","Why can computer-use benchmarks look much better than real-world performance?",{"id":808,"answer":1469,"question":1470},"Verify the actual external outcome. Do not treat the agent's final statement or intended click sequence as proof that the target system accepted the operation.","What is the most important reliability check after a computer-use action?",{"id":812,"answer":1472,"question":1473},"Errors accumulate across many actions, constraints are forgotten, external state changes, work spans multiple applications, hidden state matters, and the agent must decide when to wait, ask, verify or recover rather than simply continue acting.","Why do long-horizon computer tasks remain difficult?",{"id":816,"answer":1475,"question":1476},"Repeat clean tasks, inject realistic environmental failures, vary UI and state, extend the workflow horizon, introduce ambiguity, require observable outcome proof, test high-impact action controls and rerun the suite after model or harness changes.","How should I test a browser or desktop agent before deployment?",{"id":820,"answer":1478,"question":1479},"Not for every low-risk action. Confirmation requirements should scale with consequence, reversibility, authority and uncertainty. High-impact, externally visible or difficult-to-reverse actions need stronger controls.","Should computer-use agents always require human confirmation?","Computer-use agent reliability",{},{"id":826,"data":1483,"type":42,"tunes":1485},{"text":1484,"level":219},"Glossary",{},{"id":831,"data":1487,"type":831,"tunes":1508},{"title":1488,"entries":1489},"Key reliability terms",[1490,1493,1496,1499,1502,1505],{"term":1491,"anchor":837,"definition":1492},"Computer-use agent","An AI agent that interacts with graphical user interfaces or computer environments through observations and actions such as clicking, typing, scrolling, file operations or cross-application workflows.",{"term":1494,"anchor":841,"definition":1495},"Repeatability","The degree to which an agent can complete the same task consistently across repeated runs rather than succeeding only on selected trajectories.",{"term":1497,"anchor":845,"definition":1498},"Environmental robustness","The ability to preserve correct behaviour despite realistic variation such as latency, transient errors, UI changes, session state and unexpected page conditions.",{"term":1500,"anchor":849,"definition":1501},"Outcome verification","Checking the actual external state after an action to confirm that the intended result occurred instead of relying on the agent's self-report.",{"term":1503,"anchor":853,"definition":1504},"Blind Goal-Directedness","A failure pattern in which a computer-use agent continues pursuing a goal despite ambiguity, infeasibility, contradictory conditions or reasons to stop and reassess.",{"term":1506,"anchor":857,"definition":1507},"Reliability boundary","The set of conditions under which an observed success rate or capability claim remains representative enough for a specific deployment decision.",{},{"id":861,"data":1510,"type":42,"tunes":1512},{"text":1511,"level":219},"Primary sources and further reading",{},{"id":866,"data":1514,"type":873,"tunes":1518},{"link":868,"meta":1515},{"image":1516,"title":871,"description":1517},{"url":556},"Current developer guidance on isolating environments, treating screen content as untrusted, confirming consequential actions, bounding runs and verifying outcomes.",{},{"id":876,"data":1520,"type":873,"tunes":1524},{"link":878,"meta":1521},{"image":1522,"title":881,"description":1523},{"url":556},"Current production guidance on technical boundaries, human approval, telemetry and control for agents that act on real systems.",{},{"id":885,"data":1526,"type":873,"tunes":1530},{"link":887,"meta":1527},{"image":1528,"title":890,"description":1529},{"url":556},"2026 evaluation showing that realistic web unreliability causes significant drops in browser-agent task success on existing benchmarks.",{},{"id":894,"data":1532,"type":873,"tunes":1536},{"link":896,"meta":1533},{"image":1534,"title":899,"description":1535},{"url":556},"2026 work on process versus outcome evaluation, controllable versus uncontrollable failures and reliable trajectory verification.",{},{"id":903,"data":1538,"type":873,"tunes":1542},{"link":905,"meta":1539},{"image":1540,"title":908,"description":1541},{"url":556},"2026 long-horizon benchmark combining GUI, CLI and code workflows and showing a substantial gap between current agents and reliable real-world completion.",{},{"id":912,"data":1544,"type":873,"tunes":1548},{"link":914,"meta":1545},{"image":1546,"title":917,"description":1547},{"url":556},"2026 benchmark focused on realistic long-horizon computer-use workflows, hidden state and cross-source reasoning.",{},{"id":921,"data":1550,"type":873,"tunes":1554},{"link":923,"meta":1551},{"image":1552,"title":926,"description":1553},{"url":556},"2026 benchmark for time-evolving tasks where agents must monitor environments and respond to state changes rather than continuously act.",{},{"id":930,"data":1556,"type":873,"tunes":1560},{"link":932,"meta":1557},{"image":1558,"title":935,"description":1559},{"url":556},"ICLR 2026 research on agents continuing to pursue ambiguous, contradictory or infeasible goals.",{},"2.31.6","Computer-use agents can now complete impressive browser and desktop workflows, but one successful run proves capability—not reliability. This article shows how to test repeatability, environmental robustness, long-horizon control, state awareness, outcome verification, and safe goal handling.",{"lang":7,"title":208,"content":210,"contentJson":1564,"excerpt":939},{"time":212,"blocks":1565,"version":938},[1566,1569,1572,1575,1578,1581,1584,1587,1590,1593,1596,1606,1609,1612,1623,1626,1629,1632,1635,1638,1641,1644,1647,1650,1653,1656,1659,1662,1665,1668,1671,1674,1677,1680,1683,1686,1689,1692,1695,1698,1701,1704,1707,1720,1723,1726,1729,1732,1735,1751,1754,1757,1760,1773,1776,1779,1782,1785,1795,1798,1803,1806,1809,1812,1815,1818,1821,1824,1827,1830,1833,1836,1839,1842,1845,1848,1851,1861,1864,1874,1877,1882,1887,1892,1897,1902,1907,1912],{"id":215,"data":1567,"type":220,"tunes":1568},{"title":217,"maxLevel":218,"minLevel":219},{},{"id":223,"data":1570,"type":226,"tunes":1571},{"text":225},{},{"id":229,"data":1573,"type":234,"tunes":1574},{"body":231,"title":232,"variant":233},{},{"id":237,"data":1576,"type":234,"tunes":1577},{"body":239,"title":240,"variant":241},{},{"id":244,"data":1579,"type":234,"tunes":1580},{"body":246,"title":247,"variant":248},{},{"id":251,"data":1582,"type":42,"tunes":1583},{"text":253,"level":219},{},{"id":256,"data":1585,"type":226,"tunes":1586},{"text":258},{},{"id":261,"data":1588,"type":226,"tunes":1589},{"text":263},{},{"id":266,"data":1591,"type":226,"tunes":1592},{"text":268},{},{"id":271,"data":1594,"type":42,"tunes":1595},{"text":273,"level":219},{},{"id":276,"data":1597,"type":303,"tunes":1605},{"content":1598,"stretched":43,"withHeadings":14},[1599,1600,1601,1602,1603,1604],[280,281,282],[284,285,286],[288,289,290],[292,293,294],[296,297,298],[300,301,302],{},{"id":306,"data":1607,"type":42,"tunes":1608},{"text":308,"level":219},{},{"id":311,"data":1610,"type":226,"tunes":1611},{"text":313},{},{"id":316,"data":1613,"type":342,"tunes":1622},{"steps":1614,"title":340,"orientation":341},[1615,1616,1617,1618,1619,1620,1621],{"label":320,"description":321},{"label":323,"description":324},{"label":326,"description":327},{"label":329,"description":330},{"label":332,"description":333},{"label":335,"description":336},{"label":338,"description":339},{},{"id":345,"data":1624,"type":42,"tunes":1625},{"text":347,"level":218},{},{"id":350,"data":1627,"type":226,"tunes":1628},{"text":352},{},{"id":355,"data":1630,"type":226,"tunes":1631},{"text":357},{},{"id":360,"data":1633,"type":42,"tunes":1634},{"text":362,"level":218},{},{"id":365,"data":1636,"type":226,"tunes":1637},{"text":367},{},{"id":370,"data":1639,"type":226,"tunes":1640},{"text":372},{},{"id":375,"data":1642,"type":42,"tunes":1643},{"text":377,"level":218},{},{"id":380,"data":1645,"type":226,"tunes":1646},{"text":382},{},{"id":385,"data":1648,"type":226,"tunes":1649},{"text":387},{},{"id":390,"data":1651,"type":234,"tunes":1652},{"body":392,"title":393,"variant":394},{},{"id":397,"data":1654,"type":42,"tunes":1655},{"text":399,"level":218},{},{"id":402,"data":1657,"type":226,"tunes":1658},{"text":404},{},{"id":407,"data":1660,"type":226,"tunes":1661},{"text":409},{},{"id":412,"data":1663,"type":226,"tunes":1664},{"text":414},{},{"id":417,"data":1666,"type":42,"tunes":1667},{"text":419,"level":218},{},{"id":422,"data":1669,"type":226,"tunes":1670},{"text":424},{},{"id":427,"data":1672,"type":226,"tunes":1673},{"text":429},{},{"id":432,"data":1675,"type":226,"tunes":1676},{"text":434},{},{"id":437,"data":1678,"type":42,"tunes":1679},{"text":439,"level":218},{},{"id":442,"data":1681,"type":226,"tunes":1682},{"text":444},{},{"id":447,"data":1684,"type":226,"tunes":1685},{"text":449},{},{"id":452,"data":1687,"type":226,"tunes":1688},{"text":454},{},{"id":457,"data":1690,"type":42,"tunes":1691},{"text":459,"level":218},{},{"id":462,"data":1693,"type":226,"tunes":1694},{"text":464},{},{"id":467,"data":1696,"type":226,"tunes":1697},{"text":469},{},{"id":472,"data":1699,"type":226,"tunes":1700},{"text":474},{},{"id":477,"data":1702,"type":42,"tunes":1703},{"text":479,"level":219},{},{"id":482,"data":1705,"type":226,"tunes":1706},{"text":484},{},{"id":487,"data":1708,"type":342,"tunes":1719},{"steps":1709,"title":517,"orientation":341},[1710,1711,1712,1713,1714,1715,1716,1717,1718],{"label":491,"description":492},{"label":494,"description":495},{"label":497,"description":498},{"label":500,"description":501},{"label":503,"description":504},{"label":506,"description":507},{"label":509,"description":510},{"label":512,"description":513},{"label":515,"description":516},{},{"id":520,"data":1721,"type":42,"tunes":1722},{"text":522,"level":219},{},{"id":525,"data":1724,"type":226,"tunes":1725},{"text":527},{},{"id":530,"data":1727,"type":226,"tunes":1728},{"text":532},{},{"id":535,"data":1730,"type":541,"tunes":1731},{"url":537,"title":538,"excerpt":539,"ctaLabel":540},{},{"id":544,"data":1733,"type":42,"tunes":1734},{"text":546,"level":219},{},{"id":549,"data":1736,"type":580,"tunes":1750},{"rows":1737,"title":569,"layout":303,"columns":1746},[1738,1740,1742,1744],{"id":553,"label":554,"values":1739},[556,556,556],{"id":558,"label":559,"values":1741},[556,556,556],{"id":562,"label":563,"values":1743},[556,556,556],{"id":566,"label":567,"values":1745},[556,556,556],[1747,1748,1749],{"id":572,"label":573},{"id":575,"label":576},{"id":578,"label":579},{},{"id":583,"data":1752,"type":226,"tunes":1753},{"text":585},{},{"id":588,"data":1755,"type":42,"tunes":1756},{"text":590,"level":219},{},{"id":593,"data":1758,"type":226,"tunes":1759},{"text":595},{},{"id":598,"data":1761,"type":303,"tunes":1772},{"content":1762,"stretched":43,"withHeadings":14},[1763,1764,1765,1766,1767,1768,1769,1770,1771],[602,603,604],[606,607,608],[610,611,612],[614,615,616],[618,619,620],[622,623,624],[626,627,628],[630,631,632],[634,635,636],{},{"id":639,"data":1774,"type":42,"tunes":1775},{"text":641,"level":219},{},{"id":644,"data":1777,"type":226,"tunes":1778},{"text":646},{},{"id":649,"data":1780,"type":226,"tunes":1781},{"text":651},{},{"id":654,"data":1783,"type":42,"tunes":1784},{"text":656,"level":219},{},{"id":659,"data":1786,"type":303,"tunes":1794},{"content":1787,"stretched":43,"withHeadings":14},[1788,1789,1790,1791,1792,1793],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],[683,684,685],{},{"id":688,"data":1796,"type":42,"tunes":1797},{"text":690,"level":219},{},{"id":693,"data":1799,"type":710,"tunes":1802},{"meta":1800,"items":1801,"style":709},{},[697,698,699,700,701,702,703,704,705,706,707,708],{},{"id":713,"data":1804,"type":226,"tunes":1805},{"text":715},{},{"id":718,"data":1807,"type":541,"tunes":1808},{"url":720,"title":721,"excerpt":722,"ctaLabel":723},{},{"id":726,"data":1810,"type":42,"tunes":1811},{"text":728,"level":219},{},{"id":731,"data":1813,"type":226,"tunes":1814},{"text":733},{},{"id":736,"data":1816,"type":226,"tunes":1817},{"text":738},{},{"id":741,"data":1819,"type":226,"tunes":1820},{"text":743},{},{"id":746,"data":1822,"type":42,"tunes":1823},{"text":748,"level":219},{},{"id":751,"data":1825,"type":226,"tunes":1826},{"text":753},{},{"id":756,"data":1828,"type":226,"tunes":1829},{"text":758},{},{"id":761,"data":1831,"type":42,"tunes":1832},{"text":763,"level":219},{},{"id":766,"data":1834,"type":226,"tunes":1835},{"text":768},{},{"id":771,"data":1837,"type":226,"tunes":1838},{"text":773},{},{"id":776,"data":1840,"type":42,"tunes":1841},{"text":778,"level":219},{},{"id":781,"data":1843,"type":226,"tunes":1844},{"text":783},{},{"id":786,"data":1846,"type":226,"tunes":1847},{"text":788},{},{"id":791,"data":1849,"type":42,"tunes":1850},{"text":793,"level":219},{},{"id":796,"data":1852,"type":796,"tunes":1860},{"items":1853,"title":823},[1854,1855,1856,1857,1858,1859],{"id":800,"answer":801,"question":802},{"id":804,"answer":805,"question":806},{"id":808,"answer":809,"question":810},{"id":812,"answer":813,"question":814},{"id":816,"answer":817,"question":818},{"id":820,"answer":821,"question":822},{},{"id":826,"data":1862,"type":42,"tunes":1863},{"text":828,"level":219},{},{"id":831,"data":1865,"type":831,"tunes":1873},{"title":833,"entries":1866},[1867,1868,1869,1870,1871,1872],{"term":836,"anchor":837,"definition":838},{"term":840,"anchor":841,"definition":842},{"term":844,"anchor":845,"definition":846},{"term":848,"anchor":849,"definition":850},{"term":852,"anchor":853,"definition":854},{"term":856,"anchor":857,"definition":858},{},{"id":861,"data":1875,"type":42,"tunes":1876},{"text":863,"level":219},{},{"id":866,"data":1878,"type":873,"tunes":1881},{"link":868,"meta":1879},{"image":1880,"title":871,"description":872},{"url":556},{},{"id":876,"data":1883,"type":873,"tunes":1886},{"link":878,"meta":1884},{"image":1885,"title":881,"description":882},{"url":556},{},{"id":885,"data":1888,"type":873,"tunes":1891},{"link":887,"meta":1889},{"image":1890,"title":890,"description":891},{"url":556},{},{"id":894,"data":1893,"type":873,"tunes":1896},{"link":896,"meta":1894},{"image":1895,"title":899,"description":900},{"url":556},{},{"id":903,"data":1898,"type":873,"tunes":1901},{"link":905,"meta":1899},{"image":1900,"title":908,"description":909},{"url":556},{},{"id":912,"data":1903,"type":873,"tunes":1906},{"link":914,"meta":1904},{"image":1905,"title":917,"description":918},{"url":556},{},{"id":921,"data":1908,"type":873,"tunes":1911},{"link":923,"meta":1909},{"image":1910,"title":926,"description":927},{"url":556},{},{"id":930,"data":1913,"type":873,"tunes":1916},{"link":932,"meta":1914},{"image":1915,"title":935,"description":936},{"url":556},{},"Post erfolgreich abgerufen",{"items":1919,"source":1982,"manualIds":1983,"manualMatchedIds":1984},[1920,1927,1934,1941,1947,1954,1961,1968,1975],{"id":1921,"slug":1922,"title":1923,"excerpt":1924,"featuredImage":1925,"publishedAt":1926},"457","should-you-buy-5g-openwrt-router-old-firmware","Faut-il acheter un routeur 5G OpenWrt avec un ancien firmware ? Le ZBT Z8102AX comme exemple concret","Acheter un routeur 5G OpenWrt avec un ancien firmware peut avoir du sens, mais uniquement dans les bonnes conditions. Le ZBT Z8102AX illustre clairement les deux aspects : le matériel est utile, le modem fonctionne et le routeur est resté stable lors des tests, mais OpenWrt 21.02, un emballage faible et des chemins de mise à niveau peu clairs nécessitent une décision d'achat réfléchie.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-05-1781620596218-5ldld4.webp","2026-06-16T10:41:00.000Z",{"id":1928,"slug":1929,"title":1930,"excerpt":1931,"featuredImage":1932,"publishedAt":1933},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Comment savoir si un agent IA a réellement utilisé les bonnes preuves","Un agent IA peut citer des sources et tout de même utiliser les mauvais éléments de preuve. Cet article présente une méthode pratique pour vérifier le soutien des affirmations, l'autorité de la source, l'applicabilité, la provenance et si les éléments de preuve ont réellement influencé la réponse.","\u002Fuploads\u002F2026\u002F09\u002Fhow-to-know-whether-an-ai-agent-actually-used-the-right-evidence-1790351317188-o5z9ve.webp","2026-09-25T11:47:00.000Z",{"id":1935,"slug":1936,"title":1937,"excerpt":1938,"featuredImage":1939,"publishedAt":1940},"459","ollama-is-not-the-product-building-production-ready-open-llm-applications","Ollama n'est pas le produit : construire des applications Open-LLM prêtes pour la production","Exécuter un modèle local avec Ollama est facile. Construire une application Open-LLM prête pour la production est plus difficile : cela nécessite du RAG, du contrôle d'accès, de l'abstraction de fournisseur, de l'évaluation, de la journalisation, de la discipline de déploiement et une couche applicative contrôlée autour du modèle.","\u002Fuploads\u002F2026\u002F06\u002Follama-is-not-the-product-building-production-ready-open-llm-applications-1782679361640-h0usqf.webp","2026-06-28T16:39:00.000Z",{"id":1942,"slug":1943,"title":721,"excerpt":1944,"featuredImage":1945,"publishedAt":1946},"460","ai-agent-reliability-why-the-final-answer-is-not-enough","Une sortie correcte ne prouve pas un raisonnement correct, une exécution sûre ou un système digne de confiance.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz.webp","2026-09-09T04:01:00.000Z",{"id":1948,"slug":1949,"title":1950,"excerpt":1951,"featuredImage":1952,"publishedAt":1953},"474","migrating-from-openai-agents-sdk-to-the-agents-api-what-actually-changes-architecturally","Migration du SDK OpenAI Agents vers l'API Agents : qu'est-ce qui change réellement sur le plan architectural ?","La migration du SDK OpenAI Agents vers la nouvelle API Agents n'est pas un simple renommage d'import. La frontière d'exécution change : la boucle d'agent, la session durable, l'orchestration, la compaction du contexte et la récupération se déplacent vers un harnais managé. Ce guide montre ce qui doit être déplacé, ce qui doit rester dans votre application, et comment prouver la migration avant le basculement.","\u002Fuploads\u002F2026\u002F09\u002Fmigrating-from-openai-agents-sdk-to-the-agents-api-what-actually-changes-architecturally-1790352171968-ienxr9.webp","2026-09-25T12:01:00.000Z",{"id":1955,"slug":1956,"title":1957,"excerpt":1958,"featuredImage":1959,"publishedAt":1960},"472","why-more-context-can-make-ai-answers-worse","Pourquoi plus de contexte peut rendre les réponses de l'IA pires","Une fenêtre de contexte plus grande ne garantit pas une meilleure réponse. Cet article explique comment la dilution du signal, les preuves contradictoires, l'état obsolète, la sensibilité à la position et la compression avec perte peuvent réduire la fiabilité de l'IA — et présente un test pratique de pression de contexte.","\u002Fuploads\u002F2026\u002F09\u002Fwhy-more-context-can-make-ai-answers-worse-1790351615793-2ntv2v.webp","2026-09-25T11:51:00.000Z",{"id":1962,"slug":1963,"title":1964,"excerpt":1965,"featuredImage":1966,"publishedAt":1967},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement","Le RAG semble compliqué, mais l'idée est simple : avant qu'une IA ne réponde, elle recherche d'abord des informations utiles dans une source de connaissances et transmet ces informations au modèle de langage. Ce guide explique le RAG, les LLM, l'état, la mémoire et les outils à l'aide d'un modèle mental simple.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":1969,"slug":1970,"title":1971,"excerpt":1972,"featuredImage":1973,"publishedAt":1974},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Maîtriser le flux de travail SEO : Stratégies d'optimisation essentielles pour la croissance organique","Un flux de travail SEO structuré est crucial pour une croissance organique durable. Découvrez les dix stratégies fondamentales, de la recherche de mots-clés et l'optimisation technique à la qualité du contenu et l'analyse des performances.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":1976,"slug":1977,"title":1978,"excerpt":1979,"featuredImage":1980,"publishedAt":1981},"469","rag-failed-but-which-layer-actually-failed-a-diagnostic-method","Échec du RAG — mais quelle couche a réellement échoué ? Une méthode de diagnostic","Lorsqu'une réponse RAG est erronée, blâmer la récupération ou le modèle est trop vague. Cette méthode de diagnostic isole la couverture des sources, la construction de la requête, la récupération, le classement, l'assemblage du contexte, la génération, l'attribution des preuves et la fraîcheur—afin que la défaillance réelle puisse être reproduite et corrigée.","\u002Fuploads\u002F2026\u002F09\u002Frag-failed-but-which-layer-actually-failed-a-diagnostic-method-1790350847177-pior4c.webp","2026-09-24T19:39:00.000Z","fallback",[],[]]