WebMCP : j'ai branché mon site aux agents ChatGPT en 90 min

Depuis le 25 août, un site web peut proposer ses propres actions directement à un agent ChatGPT — au lieu de le laisser deviner vos boutons et remplir vos champs à tâtons. OpenAI appelle ça les Site tools, sa mise en œuvre du standard ouvert WebMCP. J'ai passé une soirée à en équiper un petit site de réservation maison. Voici ce qui marche, ce qui m'a fait perdre une heure, et pour quel type de site ça vaut vraiment le coup.

Le timing n'est pas neutre : OpenAI a lancé dans la foulée un challenge WebMCP doté de 35 000 $, dont les soumissions ferment le 3 septembre à 13 h heure du Pacifique. Autrement dit, demain. Si vous lisez ça à temps et que vous avez déjà un site sous la main, le ticket d'entrée technique est plus bas que vous ne le pensez.

WebMCP ou MCP : ne confondez pas les deux

Première source de confusion, et pas des moindres. WebMCP n'est pas le protocole MCP que vous connaissez peut-être déjà. MCP — le Model Context Protocol d'origine Anthropic, désormais gouverné par la Linux Foundation — connecte une application IA à un serveur, local ou distant, indépendamment de toute page ouverte. C'est ce que j'utilise quand je branche un connecteur métier sur un assistant. Si le sujet vous parle, on l'a détaillé dans notre guide sur le protocole MCP côté serveur.

WebMCP, lui, vit dans le navigateur. L'agent et l'utilisateur voient la même page, dans la même session connectée. Le site déclare des fonctions JavaScript comme outils appelables ; l'agent les invoque au lieu de parcourir votre DOM comme un humain pressé. La nuance est capitale : jusqu'ici, un agent qui voulait agir sur un site sans API passait par du pilotage de navigateur qui scrape l'interface, fragile et lent. WebMCP renverse la logique — c'est vous qui définissez exactement ce que l'agent a le droit de faire.

La spécification est encore expérimentale, poussée via le W3C, la dernière révision datant du 23 avril 2026. Ne construisez rien de critique dessus. Mais pour prototyper, c'est déjà utilisable.

Site tools ChatGPT : ce qui a été lancé le 25 août

Concrètement, le navigateur intégré de l'app ChatGPT desktop (Windows et macOS) sait désormais découvrir et appeler les Site tools d'une page. Quand un utilisateur visite un site compatible, ChatGPT Work et Codex détectent automatiquement les outils exposés et s'en servent pour boucler une tâche : prendre un rendez-vous, soumettre un formulaire, démarrer un tunnel d'achat.

Quelques limites qui m'ont sauté aux yeux dès le premier test :

• Ça ne marche qu'avec les modèles GPT-5.6 Sol et Terra. Sur Luna, la fonctionnalité est désactivée — j'ai perdu dix minutes à me demander pourquoi rien ne se passait.
• Pas disponible dans les espaces Enterprise ni Edu à ce stade.
• Les outils dans une iframe (même origine ou non) ne sont pas découverts. Tout doit vivre dans la page de premier niveau.
• L'API déclarative (attributs HTML sur les formulaires) n'est pas supportée par l'implémentation d'OpenAI pour l'instant. Il faut passer par l'enregistrement impératif en JavaScript.

OpenAI résume sa promesse ainsi : « Au lieu de laisser les agents deviner leur chemin dans votre interface, vous définissez exactement comment ils peuvent utiliser votre application. » C'est exactement l'angle qui m'intéresse en tant que dev : reprendre la main sur ce qu'un agent tiers fait chez moi.

Comment rendre votre site utilisable par un agent : le tuto en 3 étapes

Étape 1 — activer WebMCP dans Chrome pour tester

Vous n'avez pas besoin de ChatGPT pour développer. Chrome 149 est en Origin Trial ouvert — plus besoin de Canary. Si vous êtes en Chrome 146 Canary, activez le flag chrome://flags#webmcp. Edge 147 embarque déjà l'implémentation native. Firefox et Safari, eux, n'ont rien livré. Développez donc sur base Chromium.

Étape 2 — déclarer un premier outil en JavaScript

Le cœur du sujet tient en un appel. J'ai commencé par exposer une action de réservation. Notez la détection de fonctionnalité en tête : sans elle, votre script casse sur les navigateurs qui ne connaissent pas encore l'API.

if (navigator.modelContext?.registerTool) {
  navigator.modelContext.registerTool({
    name: 'creerReservation',
    description: 'Réserve un créneau pour un service donné, à une date et une heure.',
    inputSchema: {
      type: 'object',
      properties: {
        service: { type: 'string' },
        date: { type: 'string', format: 'date' },
        heure: { type: 'string' },
        email: { type: 'string' }
      },
      required: ['service', 'date', 'heure', 'email']
    },
    annotations: { readOnlyHint: false },
    execute: async ({ service, date, heure, email }) => {
      const res = await fetch('/api/reservations', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ service, date, heure, email })
      });
      return res.ok
        ? { success: true, message: 'Créneau confirmé.' }
        : { success: false, message: 'Créneau indisponible.' };
    }
  });
}

Le description et le inputSchema ne sont pas cosmétiques : c'est là-dessus que l'agent s'appuie pour décider quand et comment appeler l'outil. Soyez explicite. J'ai obtenu de bien meilleurs déclenchements en écrivant des descriptions verbeuses plutôt que des libellés courts. À noter : l'implémentation d'OpenAI expose la même mécanique via document.modelContext dans son navigateur intégré ; le navigator.modelContext ci-dessus correspond à la version Chrome/W3C. Feature-détectez les deux si vous ciblez les deux environnements.

Étape 3 — vérifier avec l'inspecteur

Une fois le flag actif, ouvrez les DevTools puis Application → WebMCP. Vos outils enregistrés doivent y apparaître avec leur schéma. Si l'onglet est vide, c'est presque toujours que le script s'exécute dans une iframe, ou que le registerTool tourne avant le montage du composant. Pensez aussi à servir un manifeste .well-known/webmcp avec le bon Content-Type: application/json.

Ce qui m'a fait perdre une heure

Deux pièges, en toute honnêteté. Le premier : j'avais gardé en tête une vieille méthode provideContext() vue dans un article de mars. Elle a été retirée du standard en mars 2026. La bonne pratique désormais, c'est d'embarquer le contexte directement dans le description de chaque outil. J'ai cherché la fonction fantôme un bon moment avant de comprendre.

Le second : mes outils enregistrés dynamiquement après une navigation SPA restaient en double. Sur un front en composants, il faut désenregistrer les outils au démontage pour éviter les références mortes — sinon l'agent voit trois fois le même outil et hésite. Rien d'insurmontable, mais c'est le genre de détail qui n'est écrit nulle part clairement et qu'on découvre en galérant.

Dernier point qui casse l'enthousiasme : comme tout est côté navigateur, l'agent n'accède qu'à ce que la session connectée permet. Pratique pour la sécurité, mais ça veut dire zéro action possible pour un visiteur non authentifié. Pour un site vitrine, l'intérêt est mince ; pour un espace client, il devient réel.

Combien ça coûte et pour quel type de site

L'implémentation en elle-même est gratuite : c'est du JavaScript sur votre propre site, aucun abonnement, aucun appel d'API facturé côté OpenAI. Le seul « coût » est le temps de dev — comptez une demi-journée pour un premier outil propre, testé et sécurisé. Ma soirée à 90 minutes concernait un cas simple avec une API back-end déjà en place.

Pour qui ça vaut le coup ? Trois profils, à mon sens :

• Sites de réservation et de prise de rendez-vous : l'agent réserve un créneau sans naviguer dans un calendrier récalcitrant.
• Boutiques en ligne : ajout au panier, application d'un code promo, lancement d'un tunnel d'achat. C'est exactement la direction que prend le commerce agentique où les agents passent commande, et exposer des Site tools propres, c'est reprendre la main sur ce que l'agent fait de votre catalogue.
• Espaces client SaaS : déclencher une action métier précise (créer un ticket, exporter une facture) plutôt que de laisser l'agent cliquer partout.

Pour un blog ou un site vitrine, laissez tomber pour l'instant. Le jeu n'en vaut pas la chandelle tant que Firefox et Safari ne suivent pas, et tant que la spec reste expérimentale.

Si vous voulez expérimenter côté agent avant de coder, un simple abonnement à

Sécurité WebMCP : prompt injection et exfiltration, ce qu'il faut verrouiller

C'est le point que je refuse de survoler. La spécification est explicite : « les définitions et résultats d'outils fournis par le site sont du contenu non fiable ». Chaque invocation passe par une revue de sûreté avant exécution, et l'utilisateur doit accorder la permission d'accès. Mais le risque d'injection de prompt et d'exfiltration de données reste réel, surtout si votre execute touche à des données sensibles.

Concrètement : un outil en écriture qui déclenche un paiement ou une suppression doit toujours repasser par une confirmation utilisateur explicite, côté serveur. Le readOnlyHint: true dans les annotations aide l'agent à distinguer une lecture d'une action lourde — servez-vous-en systématiquement pour les outils de consultation.

Mon verdict après une soirée

WebMCP règle un vrai problème : jusqu'ici, faire agir un agent sur un site sans API, c'était du bricolage de scraping qui cassait au premier changement de CSS. Là, on déclare un contrat clair, typé, sécurisé. En tant que dev, j'aime cette approche — on reprend le contrôle.

Mais soyons lucides. C'est expérimental, ça ne tourne que sur Chromium et le navigateur ChatGPT, réservé à Sol et Terra, hors Enterprise. Trop tôt pour miser un projet client dessus. En revanche, si vous avez un site de résa ou une boutique et deux heures devant vous, monter un premier Site tool cette semaine — challenge OpenAI ou pas — vous met en avance sur la vague du commerce agentique. Et franchement, coder un registerTool propre est plus gratifiant que de maintenir un énième script Playwright fragile.