Microsoft Fara : lancer un agent Browser-Use dans Google Colab avec un endpoint OpenAI factice

Microsoft lance le "vibe working" dans Word, Excel et PowerPoint

Microsoft déploie cette semaine un nouveau mode appelé Agent Mode dans ses applications Office, Word, Excel et PowerPoint. Baptisé en interne "vibe working", ce mode représente une version nettement plus avancée de Copilot, l'assistant IA que Microsoft commercialise auprès des entreprises depuis 2023. Sumit Chauhan, vice-président de l'Office Product Group, reconnaît publiquement les limites de la première version : "Quand nous avons lancé Copilot, les modèles fondationnels n'étaient pas assez puissants pour lui permettre d'agir directement dans les applications." Ce basculement vers un agent actif change fondamentalement la nature du produit. Jusqu'ici, Copilot dans Office se contentait de répondre à des questions ou de générer du contenu dans un volet latéral, sans pouvoir modifier directement un document, une feuille de calcul ou une présentation. Agent Mode franchit cette barrière : l'assistant peut désormais prendre des actions concrètes sur le "canvas", c'est-à-dire manipuler le contenu des fichiers de façon autonome, sur instruction de l'utilisateur. Pour les entreprises qui paient l'abonnement Copilot 365 (environ 30 dollars par utilisateur par mois), cela justifie enfin une partie de la promesse initiale. Cette annonce s'inscrit dans une course industrielle intense. Google a lancé des fonctionnalités similaires dans Workspace, et les grands éditeurs de productivité misent tous sur les "agents" comme prochaine étape après les assistants génératifs. Microsoft, qui a investi plusieurs milliards dans OpenAI, dispose d'un accès privilégié aux dernières versions de GPT-4o et o-series, ce qui lui permet aujourd'hui de tenir des promesses que les modèles de 2023 ne pouvaient pas encore tenir.

Microsoft Research lance Webwright, un agent web en terminal qui atteint 60,1% sur Odysseys (GPT-5.4 de base : 33,5%)

Microsoft Research a publié Webwright, un framework open source pour agents web dont l'architecture tranche radicalement avec les approches existantes. Là où la plupart des agents pilotent un navigateur action par action en analysant des captures d'écran ou du texte DOM, Webwright fournit à l'agent un terminal. Celui-ci rédige du code Playwright pour automatiser les interactions, exécute des commandes bash, inspecte des logs et affine ses scripts de manière itérative. Playwright est une bibliothèque d'automatisation de navigateur, également développée par Microsoft, compatible avec Chromium, Firefox et WebKit. L'architecture repose sur trois composants volontairement légers : un Runner (environ 150 lignes de code), une interface de modèle (550 lignes) et un environnement terminal (300 lignes), sans orchestration multi-agents ni hiérarchie de planification. Sur le benchmark Odysseys, Webwright atteint 60,1% de réussite contre seulement 33,5% pour GPT-5.4 en configuration classique. Sur Online-Mind2Web, qui couvre 300 tâches sur 136 sites courants, GPT-5.4 sous Webwright plafonne à 86,67% de précision globale, tandis que Claude Opus 4.7 obtient 84,7% au global mais devance GPT-5.4 sur les tâches difficiles à 100 étapes : 80,5% contre 76,6%. Ce changement de paradigme a des implications concrètes pour l'automatisation web. En traitant le navigateur comme un outil scriptable plutôt qu'un état à maintenir en temps réel, l'agent peut exprimer des interactions complexes (sélectionner une date, remplir un formulaire entier) en quelques lignes de code réutilisables, à la façon d'un script RPA. Le code, les logs et les captures d'écran s'accumulent dans un workspace local, rendant chaque exécution entièrement traçable et reproductible. Microsoft Research a par ailleurs résolu deux problèmes techniques récurrents dans ce domaine : la tendance des agents à déclarer prématurément une tâche terminée, et l'explosion du contexte sur les longues trajectoires. Pour le premier, l'agent doit générer une configuration de réflexion critique, relancer un script final dans un dossier vierge et valider lui-même la réussite avant d'émettre le signal de complétion. Pour le second, l'historique est automatiquement compacté en un résumé synthétique toutes les 20 étapes. Cette publication s'inscrit dans une tendance plus large : les grands modèles de langage, devenus capables de rédiger et déboguer du code complexe, sont désormais utilisés comme agents de programmation plutôt que comme automates de clics. La contrainte action-par-action était héritée d'une époque où les capacités de raisonnement restaient limitées. Webwright s'appuie sur Playwright, outil open source largement adopté dans l'industrie, pour offrir une base fiable. Le lab AI Frontiers de Microsoft Research positionne ainsi ce framework comme une alternative sérieuse aux solutions existantes, notamment grâce à sa sobriété architecturale : moins de 1 000 lignes de code au total pour l'ensemble des composants principaux. Alors qu'Anthropic, OpenAI et Google s'affrontent sur ces benchmarks avec leurs modèles respectifs, l'émergence de frameworks standardisés comme Webwright pourrait progressivement déplacer la compétition du modèle lui-même vers la qualité du harness d'exécution.

💬 Donner un terminal à l'agent au lieu de le forcer à cliquer action par action, ça semblait évident, mais personne n'avait vraiment poussé l'idée jusqu'au bout. GPT-5.4 passe de 33% à 60% sur Odysseys avec ce seul changement, et tout le framework tient en moins de 1000 lignes. Ce genre d'architecture sobre, ça donne envie de réécrire tes vieux scrapers maison.

Le Context Bridge d'IWE : graphe de connaissances IA avec RAG à base d'agents et appels de fonctions OpenAI

Un tutoriel publié récemment sur la plateforme analytique Towards Data Science détaille l'implémentation d'IWE, un système open-source de gestion des connaissances personnelles écrit en Rust, transformé en graphe de connaissances piloté par intelligence artificielle. Le projet s'appuie sur l'API OpenAI, la bibliothèque Python Graphviz et un pipeline RAG agentique (Retrieval-Augmented Generation) pour permettre à un agent IA de naviguer dans des notes Markdown interconnectées. Concrètement, le tutoriel guide le développeur dans la construction d'une base de connaissances complète à partir de zéro : chaque note devient un nœud dans un graphe orienté, les liens wiki ([[note]]) et les liens Markdown standard constituent les arêtes, et IWE expose ses opérations clés via une interface CLI — recherche floue (find), récupération contextuelle (retrieve), affichage de hiérarchie (tree), consolidation de documents (squash), statistiques (stats) et export au format DOT pour visualisation. L'intérêt concret de cette architecture réside dans la capacité d'un agent à effectuer un raisonnement multi-sauts entre documents reliés, à identifier des lacunes dans la base de connaissances et à générer automatiquement de nouvelles notes qui s'intègrent dans la structure existante. Pour les développeurs et les équipes techniques, cela représente un changement significatif dans la façon d'exploiter la documentation interne : au lieu de chercher manuellement dans des dossiers de notes, un agent invoque des outils de function calling OpenAI pour traverser le graphe, extraire des résumés, suggérer des liens manquants et isoler les tâches à accomplir (todo extraction). La précision du graphe de rétroliens — chaque document connaît ses documents référents — permet un contexte réellement pertinent transmis au modèle de langage, contrairement aux approches RAG classiques basées sur la similarité vectorielle seule. IWE s'inscrit dans un mouvement plus large autour des systèmes de gestion des connaissances personnelles (PKM) popularisés par des outils comme Obsidian ou Roam Research, mais avec une philosophie orientée développeur : tout est fichier texte, tout est scriptable, et le LSP (Language Server Protocol) permet une intégration directe dans les éditeurs de code comme Neovim ou VS Code. En greffant OpenAI par-dessus cette infrastructure légère, le tutoriel illustre une tendance croissante dans l'outillage IA : plutôt que de recourir à des plateformes centralisées et coûteuses, construire des pipelines agentiques sur des bases de connaissances locales, contrôlées, versionnées sous Git. La prochaine étape logique pour ce type de système serait l'intégration de modèles locaux via Ollama, afin de s'affranchir totalement des API externes pour les cas d'usage sensibles ou hors-ligne.

L'Agents SDK d'OpenAI renforce la gouvernance avec l'exécution en sandbox

OpenAI vient d'annoncer de nouvelles fonctionnalités pour son Agents SDK, avec notamment l'introduction de l'exécution en sandbox et d'un environnement d'exécution natif au modèle. Ces ajouts visent à permettre aux équipes de gouvernance en entreprise de déployer des workflows automatisés avec un contrôle accru des risques. Concrètement, le SDK intègre désormais une mémoire configurable, une orchestration adaptée aux environnements sandbox, et des outils de gestion de fichiers similaires à ceux de Codex. Les développeurs peuvent également utiliser des primitives standardisées comme l'appel d'outils via MCP, des instructions personnalisées via un fichier AGENTS.md, et un outil d'application de correctifs pour les modifications de fichiers. Une abstraction baptisée "Manifest" permet de décrire l'espace de travail de manière normalisée, avec la possibilité de connecter directement des environnements à des fournisseurs de stockage majeurs : AWS S3, Azure Blob Storage, Google Cloud Storage et Cloudflare R2. Ces évolutions répondent à un problème concret rencontré lors du passage des prototypes en production : les équipes devaient jusqu'ici choisir entre des frameworks agnostiques offrant de la flexibilité mais ne tirant pas pleinement parti des modèles frontier, ou des SDK propriétaires proches du modèle mais manquant de visibilité sur la couche de contrôle. Le résultat était souvent la construction de connecteurs maison fragiles. Le cas d'Oscar Health illustre bien l'impact potentiel : ce prestataire de santé américain a utilisé le nouveau SDK pour automatiser un workflow de traitement de dossiers cliniques que les approches précédentes ne pouvaient pas gérer de façon fiable. Rachael Burns, Staff Engineer et AI Tech Lead chez Oscar Health, précise que la différence n'était pas seulement d'extraire les bonnes métadonnées, mais de comprendre correctement les limites de chaque consultation au sein de longs dossiers médicaux complexes, permettant ainsi d'accélérer la coordination des soins et d'améliorer l'expérience patient. Ces avancées s'inscrivent dans une tendance plus large : la course à la standardisation des infrastructures pour agents IA en entreprise. OpenAI, face à la concurrence de frameworks comme LangChain, LlamaIndex ou les offres cloud de Google et Microsoft, cherche à imposer son SDK comme la référence native pour les équipes qui utilisent ses modèles. L'introduction du Manifest et de l'exécution en sandbox signale une ambition claire : capter les déploiements en production, segment où les enjeux de sécurité, de traçabilité et de gouvernance sont déterminants. En standardisant la couche d'infrastructure, OpenAI libère les équipes techniques de la maintenance des "plomberies" et les oriente vers la logique métier à valeur ajoutée. La prochaine étape sera de voir dans quelle mesure ces outils s'intègrent avec les systèmes legacy et si l'abstraction Manifest tient ses promesses à grande échelle.