Microsoft Research a sorti Webwright cette semaine — un framework de web agent qui jette le DOM-clicking et la prédiction de coordonnées sur screenshot au profit de faire écrire du code Playwright à l'agent dans un terminal. Le pari architectural : traiter le browser comme un outil lançable, pas une session stateful. L'agent reçoit le contexte, retourne du code et du raisonnement, exécute via un Terminal Environment, et incorpore les observations (logs, screenshots, valeurs de retour) back dans le contexte. Trois composants, environ 1000 lignes total : Runner à ~150 LOC orchestre la loop, Model Endpoint à ~550 LOC gère l'interface LLM, Terminal Environment à ~300 LOC exécute tout. Single agent loop, pas d'orchestration multi-agent. Pour les builders qui ont vu la browser-agent stack accumuler des wrappers DOM style Operator et des pipelines de screenshots, c'est le move de minimalisme architectural.
Benchmarks : Odysseys (browsing multi-site long-horizon, tâches faisant en moyenne 272,3 mots) — GPT-5.4 base 33,5%, Webwright sur GPT-5.4 lift à **60,1%** (amélioration relative 79,4%). Le précédent SOTA sur Odysseys était Opus 4.6 à 44,5%, set en avril 2026. Claude Opus 4.7 avec Webwright complete les tâches en moins de steps (mean 21,9 vs 26,3) mais à $6,09 par tâche versus $2,37 pour GPT-5.4 — le tradeoff coût/step est réel et explicite. Online-Mind2Web (300 tâches, 136 sites) : Webwright+GPT-5.4 atteint 86,67% d'accuracy. Qwen3.5-9B avec scripts d'outils pre-built : 66,2% sur le split hard. Caveats d'ingénierie que Microsoft documente honnêtement : les modèles déclarent "done" prématurément sans finir, mitigé par self-reflection plus fresh-folder validation plus jugement explicite succès/échec ; explosion de contexte sur les trajectoires longues, mitigé par compaction d'historique aux 20 steps.
Lecture écosystème : c'est la seconde release majeure browser-agent en quinzaine après la propre famille Fara1.5 de Microsoft (modèles 4B/9B/27B). Fara était le côté modèle ; Webwright est le harness. Les deux représentent une stance cohérente — garder la surface modèle minimale et laisser le code Playwright (la lib d'automation browser de Microsoft, à l'origine pour les tests) porter le vocabulaire d'action. C'est un pari différent de l'Operator d'OpenAI (perception DOM-tree, coordonnées de clic) et d'Antigravity 2.0 de Google (browser-comme-runtime). Pour les builders, l'implication est concrète : si t'as écrit des harness custom de DOM-scraping ou luttes avec la prédiction screenshot-vers-coordonnée, le path Playwright-code-as-action-language a maintenant une baseline publiée qui bat le précédent SOTA de 15,6 points absolus sur Odysseys. Repo : github.com/microsoft/Webwright. Ship avec un Claude Code skill — pas de clé LLM séparée au-delà d'un abonnement Claude, avec des paths d'install project-scoped ou user-scoped.
Lundi matin : si tu shippes un produit web-agent, clone le repo et roule le split Odysseys contre ton harness actuel — la comparaison apples-to-apples c'est ce qui te dit si ton DOM-walker fait du vrai travail ou si un générateur de code Playwright sur le même modèle base ferait mieux. Le budget de 1000 LOC rend ce test cheap à setup. Si tu prototypes des web agents from scratch, la shape Webwright (Runner / Model Endpoint / Terminal Env) est une décomposition de départ raisonnable — assez petite pour être lue dans une soirée, assez structurée pour être étendue. Le tradeoff coût/step avec Opus 4.7 vaut aussi la peine d'être modélisé explicitement dans ton budget : $2,37 vs $6,09 par tâche avec Opus peut ou peut ne pas valoir la réduction de 4,4 steps selon ce que ton agent est réellement payé à faire.