OpenAI a activé la prise en charge de WebMCP dans le navigateur intégré à l'application de bureau ChatGPT le mardi 25 août 2026, sous le nom d'outils de site. L'idée est petite, la conséquence ne l'est pas. Au lieu qu'un agent lise votre page, devine quel élément est le champ de recherche et simule des clics, votre site déclare les opérations qu'il prend en charge, avec un nom, une description et un schéma JSON pour les arguments. L'agent appelle ces outils. WebMCP reste une norme expérimentale plutôt qu'une fonctionnalité livrée de la plateforme web, l'implémentation n'en couvre qu'une partie, et Chrome travaille sur la sienne. Mais l'appel d'enregistrement tient en une quinzaine de lignes, il se désactive tout seul sur les navigateurs qui ne l'implémentent pas, et un concours avec une échéance au 3 septembre pousse fort à l'adoption.
The short answer
OpenAI a activé la prise en charge de WebMCP dans le navigateur de l'application de bureau ChatGPT le 25 août 2026, sous le nom d'outils de site. Une page enregistre des opérations nommées via document.modelContext, chacune avec une description et un schéma JSON, et l'agent de passage les appelle au lieu de simuler des clics. Cela fonctionne dans le navigateur ChatGPT de bureau, dans ChatGPT Work et dans Codex. Les outils déclarés par attributs de formulaire HTML ne sont pas lus, et ceux enregistrés dans une iframe ne sont pas découverts du tout.
Tout agent ayant un jour tenté d'utiliser votre application web a fait la même chose, pénible : capturer la page, deviner quelle boîte est le champ de recherche, cliquer, attendre, recapturer. Cela marche assez souvent pour une démonstration et assez rarement pour qu'on s'y fie.
Ce qui change
Le 25 août, OpenAI a activé WebMCP dans le navigateur intégré à l'application de bureau ChatGPT. WebMCP est une norme ouverte expérimentale, développée au sein du groupe communautaire Web Machine Learning du W3C, qui permet à une page web d'exposer des outils qu'un agent peut appeler directement au lieu de les déduire.
La formulation retenue par OpenAI mérite d'être répétée, car c'est tout l'enjeu : plutôt que de laisser les agents deviner leur chemin dans votre interface, vous définissez exactement comment ils peuvent utiliser votre application.
L'appel d'enregistrement
Les outils s'enregistrent depuis un module de premier niveau, derrière un test de présence pour ne rien casser ailleurs :
if (typeof document.modelContext?.registerTool === "function") {
await document.modelContext.registerTool({
name: "search_invoices",
description: "Rechercher des factures par client et par période",
inputSchema: { /* JSON Schema des arguments */ },
annotations: { readOnlyHint: true },
execute: async (args) => { /* appelle votre client existant, renvoie un résultat */ },
});
}Voilà toute la surface. Dans la plupart des applications, le corps de execute appelle la même fonction interne que votre propre gestionnaire de clic, ce qui explique pourquoi il s'agit d'un après midi plutôt que d'un projet.
Deux conseils comptent plus qu'il n'y paraît. readOnlyHint indique au client si un appel a des effets de bord, et c'est ce qui permet à une simple consultation de s'exécuter sans interrompre l'utilisateur pendant qu'une modification, elle, obtient une confirmation. Et la description est écrite pour un modèle, pas pour une personne : elle doit dire ce que l'outil fait et ce qu'il modifie, pas ressembler à une infobulle.
Ce qui n'est pas pris en charge
Trois limites sont documentées, et toutes les trois sont du genre à connaître avant d'écrire du code, pas après.
La voie déclarative ne fonctionne pas. Les outils définis par attributs de formulaire HTML, comme le montrent certains premiers exemples WebMCP, ne sont pas disponibles en tant qu'outils de site. L'enregistrement se fait uniquement en JavaScript.
Les iframes sont invisibles. Le navigateur ne découvre pas les outils enregistrés dans un cadre, donc un tunnel de paiement ou un widget de recherche embarqué n'expose rien. Si c'est votre architecture, les outils doivent être enregistrés par la page de premier niveau et aller chercher le cadre eux mêmes.
Et l'implémentation est partielle. Seul un sous ensemble des API WebMCP est pris en charge aujourd'hui, ce qui est la position honnête pour une norme encore en développement actif.
Qui peut appeler vos outils
Les outils de site fonctionnent dans le navigateur intégré à l'application de bureau ChatGPT en dernière version, dans ChatGPT Work et dans Codex. Le modèle compte aussi : OpenAI documente la prise en charge avec GPT-5.6 Sol et Terra, et précise que WebMCP est désactivé pour GPT-5.6 Luna.
Chrome travaille sur sa propre implémentation et publie un guide développeur, ce qui constitue le signal le plus important pour qui se demande si cela vaut la peine de construire dessus. Une capacité présente dans le navigateur applicatif d'un seul éditeur est un pari. La même capacité avec un moteur de navigateur derrière est une plateforme.
Sur le modèle de confiance, OpenAI est direct : les définitions d'outils et les résultats fournis par un site sont traités comme du contenu non fiable, chaque invocation est examinée avant exécution, et les actions sensibles telles qu'un achat ou une suppression passent par le circuit de confirmation habituel. La conséquence pratique pour vous est la plus ordinaire qui soit, celle qui vaut pour tout point d'entrée public : validez les arguments qui arrivent dans execute exactement comme vous valideriez un envoi de formulaire, parce que c'est un modèle qui les a choisis.
L'échéance qui fait le travail
En parallèle du lancement, OpenAI a ouvert un concours WebMCP de dix jours avec Google Chrome, Cloudflare, Shopify, Vercel, Render et Netlify. Il y a 35 000 dollars de prix en espèces, plus des Codex Micros et des abonnements ChatGPT Pro. Les candidatures ferment le 3 septembre à 17h heure du Pacifique et les gagnants sont annoncés le 23 septembre.
Les concours de développement sont d'ordinaire du bruit. Celui ci donne une lecture raisonnable de la direction que prend la norme, parce que la liste des partenaires réunit surtout les entreprises qui devraient l'implémenter pour qu'elle compte. Shopify est plus avancé que les autres : des millions de boutiques sont déjà compatibles WebMCP, avec des agents capables de parcourir un catalogue et de constituer un panier. Expedia, Instacart et Target sont cités comme expérimentateurs.
Ce que nous ferions vraiment
Choisissez la tâche que vos utilisateurs demandent le plus souvent à un agent sur votre site, et exposez celle là. Dans la plupart des applications c'est une recherche ou une consultation, ce qui tombe bien puisque les outils en lecture seule portent le moins de risque et n'ont besoin d'aucune danse de confirmation.
Écrivez le schéma plus strict qu'il ne semble nécessaire. Un outil avec une chaîne de recherche libre sera appelé avec n'importe quoi ; un outil avec une énumération et une plage de dates sera appelé correctement. Le modèle ne lit pas votre code source, il lit votre description et votre schéma, et ces deux éléments constituent tout le contrat.
Vérifiez ensuite ce qui se passe quand l'outil est absent. La détection de fonctionnalité fait qu'un navigateur sans document.modelContext ne voit rien, mais la défaillance la plus fréquente est un outil qui s'enregistre et renvoie quelque chose que l'agent ne peut pas vérifier : il revient alors cliquer dans votre interface et vous n'avez rien changé. Si l'agent ne peut pas déduire du résultat si l'opération a réussi, vous avez ajouté du code sans effet.
Nous avions couvert la direction sans état prise par la spécification MCP en juillet, et les outils de site s'y inscrivent naturellement : le même vocabulaire d'outils, moins le serveur qu'il fallait faire tourner.
Sources et pour aller plus loin
- Build agent ready websites with ChatGPT, communauté développeurs OpenAI, 25 août 2026
- Documentation des outils de site, ChatGPT Learn
- WebMCP Challenge, OpenAI
- Spécification WebMCP, groupe communautaire Web Machine Learning du W3C
- Guide développeur WebMCP, Chrome for Developers
- ChatGPT adds WebMCP support for site tools, Search Engine Journal
Questions fréquentes
En quoi un outil de site diffère t il d'un serveur MCP classique ?
La forme du protocole est familière et le mode de déploiement change complètement. Un serveur MCP classique est un processus séparé que l'utilisateur installe, configure et auquel il branche un client, avec sa propre authentification. Un outil de site vit dans la page que vous servez déjà, il est découvert dès que l'agent charge cette page, et il hérite de la session à laquelle l'utilisateur est déjà connecté. Rien à installer. C'est ce dernier point qui rend la chose intéressante pour qui exploite une application web : vous n'avez pas à convaincre vos utilisateurs d'ajouter un connecteur, vous enregistrez les outils dans le bundle frontend existant et tout agent de passage les trouve. La contrepartie est que ces outils vivent et meurent avec la page, donc ils ne sont disponibles que pendant la visite.
À quoi ressemble concrètement l'appel d'enregistrement ?
Vous testez la présence de l'API, puis vous enregistrez depuis un module de premier niveau. L'appel prend un nom, une description écrite pour un modèle et non pour un humain, un inputSchema au format JSON Schema, un objet annotations où readOnlyHint indique au client si l'appel a des effets de bord, et une fonction execute qui fait le travail et renvoie un résultat. Les recommandations d'OpenAI méritent d'être suivies à la lettre : gardez des entrées étroites, décrivez honnêtement les effets de bord, et renvoyez assez d'informations pour que l'agent puisse vérifier ce qui s'est passé. Un outil qui renvoie un succès opaque est un outil sur lequel l'agent ne peut pas raisonner : il retournera lire la page et vous n'aurez rien gagné.
Pourquoi les outils enregistrés dans une iframe ne sont ils pas découverts ?
Le navigateur ne parcourt que le document de premier niveau, donc tout ce qui est enregistré depuis un cadre reste invisible. C'est une vraie contrainte plutôt qu'un oubli, et elle touche une architecture très répandue : si votre tunnel de paiement, votre widget de recherche ou votre tableau de bord embarqué vit dans une iframe, aucune de ses capacités n'est exposée. Le contournement consiste à enregistrer les outils dans la page de premier niveau et à faire dialoguer la fonction execute avec le cadre via postMessage, ce qui suppose que le parent sache ce que le cadre sait faire. À vérifier tôt, parce que le découvrir après avoir écrit les outils est un remaniement pénible.
Cela remplace t il l'API REST que nous avons déjà ?
Non, et y voir un remplacement est l'erreur que nous nous attendons à voir commettre. Un outil de site est une couche déclarative mince au dessus de ce que votre application sait déjà faire, et dans la plupart des bases de code la fonction execute tient en quelques lignes qui appellent le même client interne que votre interface. La valeur n'est pas une capacité nouvelle, c'est que la capacité devient découvrable et appelable sans qu'un agent la déduise de votre balisage. Votre API REST ou GraphQL continue de servir les clients programmatiques qui ne chargent jamais votre page, ce qui reste la majorité. Voyez les outils de site comme une porte d'entrée supplémentaire pour les agents qui arrivent par le navigateur, pas comme une migration d'API.
Faut il ajouter des outils de site maintenant ou attendre que la norme se stabilise ?
Tout dépend de l'existence d'une tâche qui mérite d'être exposée. WebMCP est explicitement expérimental, OpenAI n'en implémente qu'un sous ensemble, et la spécification bouge encore au sein du groupe Web Machine Learning : ce que vous écrivez aujourd'hui devra peut être être ajusté. En face, la surface est vraiment réduite, la détection de fonctionnalité fait que les navigateurs non compatibles ne voient rien du tout, et enregistrer deux ou trois outils en lecture seule au dessus de vos points d'entrée de recherche existants coûte un après midi. Notre lecture : les outils en lecture seule valent la peine d'être livrés maintenant parce que le risque est borné, et tout ce qui dépense de l'argent ou modifie un état mérite d'attendre que la sémantique de confirmation soit moins expérimentale.