OpenAI donne à ChatGPT et Codex un accès WebMCP structuré aux sites web

OpenAI a ajouté les Site tools au navigateur intégré de l’application de bureau ChatGPT, donnant à ChatGPT et à Codex un moyen structuré d’utiliser les fonctions exposées par les sites web au lieu de dépendre uniquement de la navigation visuelle, des clics et de la saisie simulée. La fonctionnalité repose sur WebMCP, un standard web proposé pour déclarer des outils qu’un agent peut découvrir et invoquer directement sur la page. Pour les développeurs, le changement essentiel est qu’un agent peut désormais utiliser une surface d’outils explicitement définie par le site tout en restant dans la session active et authentifiée de l’utilisateur.

Selon la documentation Site tools d’OpenAI, une page compatible peut exposer des actions que ChatGPT découvre automatiquement lorsqu’elles correspondent à la demande de l’utilisateur. Celui-ci peut inspecter les outils disponibles, voir s’ils lisent ou modifient des informations et consulter les outils récemment utilisés. OpenAI précise que la fonctionnalité n’est disponible que lorsque le compte, le modèle sélectionné et la page courante la prennent en charge, et qu’elle peut être désactivée dans les paramètres d’autorisation du navigateur de bureau.

De l’automatisation du navigateur aux outils déclarés

La plupart des agents de navigateur actuels doivent déduire comment utiliser un site à partir de son interface. Ils inspectent la page, identifient les boutons et les champs, estiment la fonction des contrôles, puis simulent les interactions humaines. Cette méthode peut fonctionner, mais elle reste fragile. Une petite modification de mise en page, un libellé ambigu, un composant dynamique ou un état caché peuvent amener l’agent à choisir le mauvais contrôle ou à perdre le fil du workflow.

WebMCP modifie cette frontière d’intégration. Un site peut décrire des capacités précises sous forme d’outils structurés avec des paramètres et un comportement compréhensibles par l’agent. La documentation WebMCP de Chrome présente cette approche comme une amélioration progressive pour l’exécution de tâches agentiques : l’interface destinée aux humains reste en place, tandis que les déclarations structurées offrent aux agents de navigateur un contrat d’action plus clair.

Concrètement, un site de voyage peut exposer une action de recherche ou d’itinéraire, un éditeur collaboratif des opérations sur les documents, et un site marchand des fonctions de catalogue ou de panier. L’agent n’a plus besoin de transformer chaque tâche en une suite de clics déduits. Le site définit lui-même la surface d’action prise en charge.

ChatGPT et Codex disposent maintenant d’un chemin produit pour WebMCP

Le protocole n’est pas nouveau en soi. Google Chrome développe WebMCP à titre expérimental depuis plusieurs mois, et Cloudflare ainsi que d’autres fournisseurs d’infrastructure ont déjà testé des moyens d’exposer des outils WebMCP. Ce qui change cette semaine est l’intégration produit d’OpenAI : les Site tools rendent ces déclarations directement utilisables par ChatGPT et Codex dans le navigateur intégré de l’application de bureau.

Le WebMCP Challenge d’OpenAI montre également que l’entreprise encourage activement les développeurs à construire des applications prêtes pour les agents autour de ce standard. La page du challenge explique que WebMCP permet aux sites d’exposer des outils structurés directement utilisables par les agents et indique que les applications compatibles peuvent être testées dans le navigateur intégré de ChatGPT ainsi que dans des environnements expérimentaux de Chrome.

Le média technique japonais indépendant gihyo.jp a rapporté que la mise à jour ChatGPT et Codex du 25 août a ajouté les Site tools fondés sur WebMCP au navigateur intégré, permettant à Work et Codex de détecter et d’utiliser les fonctions fournies par les pages compatibles. Cela confirme qu’il s’agit d’une intégration livrée dans un produit, et pas seulement d’une proposition de standard ou d’une préversion pour développeurs.

La frontière de sécurité se rapproche du site

Les outils structurés peuvent améliorer la fiabilité, mais ils ne suppriment pas les problèmes de sécurité des agents. Ils rendent même certaines frontières de contrôle plus explicites. Un outil agit dans le contexte d’un utilisateur qui peut déjà être authentifié sur le site. Les développeurs doivent donc traiter avec soin l’autorisation, la confirmation, la portée et la différence entre opérations de lecture et d’écriture.

La documentation d’OpenAI indique que les utilisateurs peuvent inspecter les autorisations des outils et qu’une demande d’accès au site peut apparaître avant que ChatGPT poursuive. Elle précise aussi que les outils restent disponibles uniquement tant que la page concernée est ouverte et qu’ils ne se transportent pas automatiquement d’un site à l’autre. Ces contraintes sont importantes car WebMCP n’est pas une couche d’autorisation générale. Le site reste responsable de l’identité de l’utilisateur et des droits associés à sa session.

Pour les équipes applicatives, une règle de conception se dégage : exposer une opération à un agent doit être traité davantage comme la publication d’une méthode d’API que comme l’ajout d’un libellé accessible à un bouton. Description de l’outil, validation des paramètres, contrôle des droits, exigences de confirmation et auditabilité font désormais partie de l’interface agent du produit.

WebMCP ne remplace pas le MCP conventionnel

La proximité des noms peut prêter à confusion. WebMCP est conçu pour les agents qui opèrent dans le navigateur sur la page que l’utilisateur consulte. Les intégrations classiques Model Context Protocol relient généralement un agent à des outils, services ou sources de données distants en dehors du cycle de vie de la page. Les deux peuvent coexister.

Cette distinction compte pour l’architecture. Une équipe peut utiliser MCP pour un accès back-end durable à un service et WebMCP pour des actions sensibles au contexte d’une page authentifiée en direct. La session du navigateur fournit l’état utilisateur et le contexte immédiat de l’interface, tandis que la déclaration structurée réduit le besoin d’interpréter visuellement la page.

Pour les équipes qui construisent des produits agentiques, cela crée une nouvelle couche d’interopérabilité à évaluer. L’avantage est un contrat plus explicite entre le site et l’agent de navigateur. Le coût est une surface supplémentaire à versionner, tester, sécuriser et superviser en plus de l’interface humaine et des API existantes.

Ce que les développeurs devraient tester maintenant

La fonctionnalité reste liée à un standard expérimental et sa disponibilité dépend du compte, du modèle et du support du site. Les équipes ne doivent donc pas considérer WebMCP comme une interface de production universelle. L’approche raisonnable à court terme est l’expérimentation contrôlée.

Les développeurs devraient tester la stabilité des schémas d’outils lorsque l’interface évolue, le comportement de l’agent lorsque plusieurs outils semblent appropriés, les actions qui exigent une confirmation explicite, la remontée des erreurs et l’identité entre les contrôles d’autorisation des opérations agentiques et humaines. Ils doivent aussi tester les scénarios d’injection de prompt et de contenu non fiable, car une interface d’outils structurés ne rend pas automatiquement la page environnante digne de confiance.

L’enjeu plus large est que les agents de navigateur obtiennent une voie d’intégration de premier ordre située entre l’automatisation fragile de l’interface et une intégration d’API back-end séparée. Avec Site tools, OpenAI rend cette voie directement utilisable par ChatGPT et Codex. Si le standard mûrit, les équipes web pourraient de plus en plus concevoir deux interfaces en parallèle : une pour les personnes et une surface d’actions structurées pour les agents qui agissent au nom de ces mêmes personnes.

Sources
- Using site tools in the ChatGPT desktop app
- WebMCP Challenge
- WebMCP
- ChatGPT built-in browser adds WebMCP site tools