WebMCP en octobre 2026 : rendre un site utilisable par des agents IA, et ce que signifie vraiment l'origin trial

WebMCP permet à une page web de remettre à un agent IA une courte liste de choses qu'il peut faire, chacune avec un nom, une description et un schéma d'entrée, au lieu de laisser l'agent déchiffrer la page à partir de captures d'écran et du DOM. Un agent qui trouve un outil check_order_status peut l'appeler avec un numéro de commande. Sans cet outil, il doit repérer le bon champ et cliquer sur le bon bouton.

Voilà pour la promesse. L'état des lieux au 22 octobre 2026 est plus restreint que ne le suggèrent la plupart des articles. WebMCP est une proposition d'un groupe communautaire du W3C, pas une norme. Chrome l'exécute sous forme d'origin trial, sans décision de la livrer pour l'instant. Un seul agent grand public appelle les outils (le navigateur intégré à l'application de bureau ChatGPT), et cet agent ignore la version déclarative, par formulaire, qui a été retirée de la spécification le 8 octobre. L'équipe du moteur de Safari s'oppose à la proposition ; Mozilla est neutre.

Cet article s'adresse aux développeurs et aux responsables produit qui se demandent s'il faut ajouter WebMCP dès maintenant. Il explique ce qu'est l'API, qui l'appelle, comment l'activer pour de vrais visiteurs, comment écrire des outils qui ne mettent pas une arme chargée entre les mains d'un agent, et ce qu'il faut corriger en premier si vous voulez que des agents utilisent votre site.

Ce qu'est WebMCP

La spécification définit une API JavaScript sur document.modelContext par laquelle une page enregistre des outils : « L'API WebMCP permet aux applications web de fournir des outils basés sur JavaScript aux agents IA. » Un outil a un name, une description et une fonction de rappel execute, et, facultativement, un title, un inputSchema (JSON Schema) et des annotations. Le code de la page s'exécute lorsque l'agent appelle l'outil, avec la session de l'utilisateur.

Trois points se prêtent facilement à confusion :

• Ce n'est pas une norme. Le document est un Draft Community Group Report du Web Machine Learning Community Group, et il le dit : « Ce n'est pas une norme du W3C, et elle ne figure pas non plus dans la voie de standardisation du W3C. » La documentation de Chrome parle elle-même d'« une norme web proposée ». La date du rapport change tous les quelques jours en octobre ; ses éditeurs viennent de Microsoft et de Google.
• Il n'y a pas de MCP dedans. La spécification dit que les pages qui l'utilisent « peuvent être considérées comme des serveurs Model Context Protocol qui implémentent des outils dans un script côté client », puis qu'elle « ne prescrit pas le format dans lequel les outils sont exposés à l'agent du navigateur ». Mozilla l'a dit sans détour dans son examen : « Le nom est trompeur […] Il n'y a pas de MCP ici. » Un outil WebMCP ne se connecte pas à votre serveur MCP côté backend, et il ne le remplace pas.
• Il ne vous rend pas découvrable. La documentation de Chrome énonce elle-même la limite : « Les clients et les navigateurs doivent visiter un site directement pour savoir s'il propose des outils appelables. » WebMCP aide un agent qui est déjà sur votre page. Il ne fait rien pour que vous soyez trouvé.

L'API est limitée aux contextes sécurisés et protégée par une Permissions Policy tools dont la liste d'autorisation par défaut est 'self' ; une iframe d'une autre origine ne peut donc pas enregistrer d'outils, à moins que la page qui l'intègre ne l'autorise.

Où en est-il au 22 octobre 2026

Chrome 156, dernière version de la fenêtre initiale de l'essai, est arrivé sur le canal stable le 20 octobre 2026. Chrome 162, qui clôt la prolongation demandée, doit passer en stable le 2 février 2027. La console de l'essai ne permettait pas de confirmer que la prolongation est active ; partez donc du principe qu'elle est probable, mais pas certaine.

La demande de prolongation explique pourquoi Chrome veut plus de temps : « Les retours de l'OT ont suggéré des améliorations de l'API, que nous sommes en train d'implémenter. » Dans le même fil, Dominic Farolino, de Google, a écrit que l'équipe espère « passer à l'I2S dans la fenêtre de prolongation », c'est-à-dire demander l'autorisation de livrer, et que « l'API impérative est beaucoup plus populaire que la déclarative, donc nous investissons davantage dans la première pour répondre aux besoins des utilisateurs. » Il a aussi mentionné une API de continuation, une API de stabilité des outils et des limites de taille des outils en cours de prototypage. L'API sur laquelle vous écrivez aujourd'hui va changer.

Qui appelle réellement les outils

Enregistrer des outils ne demande rien. Les utiliser demande un agent, et la liste des agents est courte.

Les extensions de test de Chrome. La documentation de Chrome propose deux extensions, dont le Model Context Tool Inspector, pour essayer les outils dans des démos et sur vos propres pages. Elles exigent votre propre clé d'API de modèle, et Chrome précise : « Ces extensions sont distinctes de Gemini dans Chrome. » Ce sont des outils de développement, pas des clients.

Le navigateur intégré de ChatGPT. Un message d'un employé d'OpenAI sur son forum des développeurs disait le 25 août 2026 : « Les site tools sont l'implémentation par ChatGPT de la norme WebMCP proposée. » Sa documentation pose des conditions : certains modèles, la dernière application de bureau, l'autorisation d'un administrateur dans les espaces de travail Enterprise, pas d'espaces de travail Edu, et « La disponibilité dépend aussi du déploiement ». Elle liste aussi ce qui n'est pas pris en charge : « API déclarative : les outils définis par des attributs de formulaire HTML ne sont pas disponibles comme site tools », ainsi que les outils enregistrés dans des iframes, y compris de même origine. La consigne d'OpenAI est claire : « Utilisez JavaScript pour enregistrer les outils dans la page de premier niveau ». La documentation ne dit pas si une page a besoin d'un token d'origin trial de Chrome pour que ChatGPT voie ses outils.

Gemini dans Chrome. Google a dit en mai qu'il « prendra bientôt en charge les API WebMCP ». Nous n'avons trouvé aucune source primaire, depuis, disant que c'est fait. Ne bâtissez pas encore de plan là-dessus.

Tous les autres se rabattent sur l'ancienne méthode. Chaque agent, dans chaque navigateur, lit encore les pages comme avant. Chrome le dit dans sa propre évaluation des risques : « Les agents de navigateur dans Chrome peuvent continuer à actionner les sites comme avant en simulant des comportements d'utilisateur. » OpenAI : « Si aucun outil adapté n'est disponible, l'agent peut toujours utiliser ses capacités de navigation habituelles. » Un site sans WebMCP n'est pas invisible pour les agents. Un site aux boutons défaillants et aux champs sans étiquette est difficile pour tous.

L'API impérative

C'est la version que définit la spécification, celle que ChatGPT prend en charge et celle que, selon Chrome, les développeurs préfèrent. Un outil enrobe une logique que la page possède déjà. Voici une consultation en lecture seule pour un client connecté, sur le modèle de la documentation de Chrome et de la détection de fonctionnalité d'OpenAI :

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Ce qui compte dans cet exemple :

• Le nom, la description et le schéma sont ce que le modèle lit. Chrome recommande au plus 500 caractères par description d'outil, 150 par description de paramètre, 30 par nom d'outil et de paramètre, et 1,5 K caractères par sortie d'outil, en précisant que « ces recommandations sont susceptibles de changer ». L'explainer de la spécification avertit qu'« exposer trop d'outils (des dizaines ou des centaines, par exemple) peut dégrader sévèrement les performances de l'agent » : enregistrez ce dont l'état actuel de la page a besoin, et retirez le reste avec le signal de l'AbortController.
• Le second argument de execute porte un AbortSignal, de sorte qu'un appel annulé puisse interrompre une requête en cours.
• Les annotations sont des indications. readOnlyHint signale une consultation. consequentialHint signale tout ce qui réserve, achète, envoie, supprime ou transfère, et la documentation de Chrome dit qu'il « permet aux agents et aux navigateurs d'imposer des demandes de confirmation obligatoires à l'utilisateur ». untrustedContentHint signale une sortie qui contient des avis, des contenus d'utilisateurs ou des données de tiers. Une annotation debugging existe depuis Chrome 156.
• Le code de la page peut aussi lister et exécuter les outils, avec document.modelContext.getTools() et executeTool(), et un événement toolchange se déclenche quand la liste change. Les arguments sérialisés en JSON passés à executeTool() sont dépréciés depuis Chrome 155.

React, Angular et Vue ont chacun des utilitaires expérimentaux, et le paquet npm webmcp-types fournit les typages TypeScript. Les tutoriels plus anciens qui appellent navigator.modelContext sont périmés : la spécification a déplacé l'API vers document le 27 mai 2026.

L'API déclarative : dans l'essai de Chrome, hors de la spécification

La version déclarative transforme un formulaire HTML existant en outil avec deux attributs. Elle séduit pour les sites anciens, riches en formulaires, parce que rien d'autre n'a à changer :

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

Dans l'essai de Chrome, « quand un agent appelle toolname, le navigateur met le formulaire au premier plan et remplit ses champs. Le formulaire reste visible pour l'utilisateur. » Le navigateur construit les paramètres à partir des contrôles : leurs noms, leurs <label>, required et les options d'un <select>. Sauf si le formulaire porte toolautosubmit, « l'utilisateur doit cliquer manuellement sur Envoyer pour terminer la tâche », ce qui est ce qu'il vous faut pour tout ce qui passe une commande ou envoie un lead. SubmitEvent.agentInvoked indique à votre gestionnaire qu'un agent a rempli le formulaire, et respondWith(), après preventDefault(), renvoie le résultat à l'agent. Écoutez les événements toolactivated et toolcancel sur document.modelContext avec addEventListener : window.ontoolactivated et window.ontoolcancel ne sont plus pris en charge depuis Chrome 156.

Le hic, c'est son statut. La modification la plus récente de l'explainer, le 8 octobre 2026, s'intitule « Remove declarative API from the spec for now », et il y est désormais écrit qu'une contrepartie déclarative « est explorée séparément […] mais ne fait pas partie de la spécification pour le moment ». ChatGPT ne la prend pas en charge. Chrome la documente encore dans l'essai, et Farolino, de Google, a soutenu dans le fil de Mozilla que « nous voyons de la valeur dans la proposition déclarative, ne serait-ce que pour les sites hérités, surtout ceux fondés sur des formulaires ». Considérez-la comme une expérience de Chrome au sein d'une expérience : bonne à essayer, imprudente comme unique voie.

L'activer pour de vrais visiteurs

Un indicateur (chrome://flags/#enable-webmcp-testing) active WebMCP dans votre propre navigateur pour les tests. Il ne fait rien pour les visiteurs. Pour eux, la page a besoin d'un token d'origin trial.

1. Enregistrez l'origine sur la page de l'essai WebMCP de Chrome. Les origin trials « sont publics et ouverts à tous les développeurs », et un token « active une fonctionnalité pour tous les utilisateurs de votre origine ».
2. Servez le token sur chaque page qui doit exposer des outils, sous la forme <meta http-equiv="origin-trial" content="..."> dans le <head> ou d'un en-tête de réponse Origin-Trial:. Un token peut aussi être injecté depuis un script. Un token couvre une origine ; une page peut en porter plusieurs.
3. Renouvelez-le. Quand un essai est prolongé, Chrome demande aux inscrits de « fournir un nouveau token pour chaque origine inscrite à l'essai », et « Chrome ignore les tokens invalides ou expirés ». Un token expiré échoue en silence : les outils cessent simplement d'apparaître.
4. Pour Edge, inscrivez-vous séparément sur la page d'essai d'Edge. Ses conditions demandent que, « lorsque c'est possible, vous acceptiez d'appliquer la détection de fonctionnalité et la dégradation progressive ».

Les audits WebMCP de Lighthouse exigent eux aussi l'inscription à l'essai ; un site qui les teste sans token les verra échouer.

Écrire des outils qu'on peut appeler sans danger

La section sécurité de la spécification est non normative, et elle dit franchement où repose la charge : empêcher la manipulation d'un agent « relève principalement du modèle de sécurité de l'agent lui-même, plutôt que de quelque chose que cette spécification peut imposer de façon normative ». Vos outils décident néanmoins des dégâts qu'un agent manipulé peut causer.

• Les indications peuvent mentir, donc les agents ne leur feront pas confiance. La spécification : « un site malveillant peut omettre ou déformer ces indications ». OpenAI : « Le nom d'un outil ou l'affirmation qu'il ne fait que lire des données ne prouve pas ce qu'il fait », et chaque appel dans son navigateur fait l'objet d'un contrôle de sécurité, la confirmation restant exigée pour les achats et les actions similaires. Annotez honnêtement malgré tout. C'est ce qu'un agent prudent utilise pour décider quand demander à l'utilisateur.
• Décrivez exactement les effets. Le mauvais exemple de la spécification est un outil décrit comme « Finalise le panier en cours » qui « déclenche en réalité un achat. L'utilisateur n'avait pas l'intention d'acheter quoi que ce soit. » Si un outil débite une carte, la description le dit, et consequentialHint vaut true.
• Autorisez côté serveur, à chaque fois. L'outil s'exécute avec la session de l'utilisateur : la spécification note que « les agents peuvent hériter de l'identité et du contexte d'authentification de l'utilisateur depuis le navigateur ». Un appel d'outil est une requête de cet utilisateur et subit les mêmes contrôles. Le conseil de l'explainer vaut toujours : « Validez strictement dans le code, souplement dans le schéma », car des échecs de schéma trop stricts peuvent faire caler les agents.
• Prévoyez l'injection de prompt. La spécification la place en tête, sous trois formes : des instructions cachées dans les métadonnées de l'outil, dans sa sortie, et des attaques qui utilisent les outils comme cibles. Une sortie qui contient des textes écrits par d'autres personnes (avis, messages, questions sur un produit) relève de untrustedContentHint et doit être renvoyée comme des données, non comme une prose qu'un agent pourrait prendre pour des instructions.
• Excluez délibérément certaines pages. Un en-tête Permissions-Policy: tools=() rend l'API indisponible pour un document et pour tout ce qu'il intègre. Les paramètres de compte, les pages de paiement et les écrans d'administration en sont des candidats.

Une réserve sur la documentation de Chrome : sa page sur la sécurité dit que le draft comprend une méthode requestUserInteraction() pour solliciter l'utilisateur en cours d'outil. Le draft de la spécification du 20 octobre 2026 n'a aucune méthode de ce nom, et l'explainer classe encore la confirmation par l'utilisateur parmi les questions ouvertes. Ne construisez rien autour.

Ce que reprochent les ingénieurs de Safari et de Firefox

Les objections valent la peine d'être lues même si vous ne développez que pour Chrome, parce qu'elles décrivent comment WebMCP peut mal tourner en pratique.

La position de WebKit, publiée le 3 juin 2026, soutient que les pages difficiles à utiliser doivent être corrigées en HTML et en ARIA, « là où l'utilisateur, les technologies d'assistance et les agents en profitent tous », et qu'avec des outils « la fragilité ne fait que passer du DOM aux descriptions des outils ». Elle traite l'agent comme une technologie d'assistance qui ne devrait pas être désignée à part : « WebMCP fait l'inverse, en faisant de “un agent est aux commandes” un fait observable. » Et elle note que la proposition « n'a aucun modèle de consentement ou de réversibilité pour les actions à conséquences ».

Mozilla a fini par se déclarer neutre en août : WebMCP « introduit une abstraction potentiellement précieuse », mais « ouvre une surface dont la dynamique réelle laisse trop de questions ouvertes pour l'approuver sans réserve ». Elle avertit que des sites pourraient « fournir des outils qui ne correspondent pas à l'expérience d'un utilisateur sur la page », par exemple pour « fournir une injection de prompt invisible pour les utilisateurs ordinaires ». Certains ingénieurs de Mozilla ont, à titre individuel, montré de l'intérêt pour une primitive d'appel de fonctions impérative ; ce n'est pas un soutien de Mozilla.

Chrome juge lui-même faible, pour les utilisateurs, le risque que d'autres moteurs n'adoptent pas WebMCP. L'envers de cela, c'est qu'un site ne gagne rien dans Safari ou Firefox à ajouter des outils aujourd'hui.

Ce qui marche aujourd'hui pour tous les agents

Chaque agent de navigateur lit des captures d'écran, du HTML et l'arbre d'accessibilité. Le guide web.dev de Google sur les sites adaptés aux agents dit que les agents « utilisent le DOM et l'arbre d'accessibilité pour obtenir une liste propre et structurée des éléments interactifs, puis la recoupent avec un rendu visuel ». Sa liste pratique est courte :

• Utilisez de vrais éléments <button> et <a>, pas des <div> et des <span> cliquables.
• Reliez chaque <label> à son champ avec for.
• Pas de superpositions transparentes sur les éléments interactifs, et rien d'interactif de moins de 8 pixels carrés.
• Une mise en page stable, qui ne bouge pas pendant que l'agent s'apprête à cliquer.

Sa conclusion : « Tout ce que nous suggérons pour rendre un site “prêt pour les agents” améliore aussi les sites pour les humains. » C'est aussi, presque mot pour mot, ce que WebKit demande à la place de WebMCP. Si votre page de paiement échoue à un audit d'accessibilité, corrigez cela avant d'écrire le moindre outil.

Lighthouse a une catégorie Agentic Browsing depuis la version 13.2.0 (1er mai 2026), disponible dans Chrome à partir de la version 150, et activée pour l'API PageSpeed Insights dans Lighthouse 13.4.1 (20 juillet 2026). Elle vérifie le sous-ensemble des audits d'accessibilité qui comptent pour les machines, la stabilité de la mise en page, les outils WebMCP enregistrés et les formulaires qui n'en ont pas, la validité du schéma et la présence d'un fichier llms.txt. Chrome la qualifie d'« informative et sans référentiel » : il n'y a pas de score de 0 à 100. Sur llms.txt, le guide de Google Search lui-même indique qu'il ignore ces fichiers : en ajouter un « ne nuira ni ne contribuera à la visibilité ou au classement de votre site dans Google Search ». Que Lighthouse vérifie la présence du fichier n'y change rien.

Faut-il ajouter WebMCP dès maintenant ?

Sur Shopify avec un thème Liquid : rien à faire. Les outils de boutique, de panier et de paiement de Shopify sont déjà actifs, « il n'y a rien à installer ni à configurer », avec la réserve de Shopify elle-même : « la prise en charge des agents est actuellement limitée aux navigateurs basés sur Chromium, via un origin trial ». Les boutiques headless ne sont couvertes que par l'aperçu développeur de Hydrogen. Nous n'avons trouvé aucune autre plateforme de commerce, aucun autre prestataire de paiement ni CDN qui active WebMCP pour ses clients.

Sur un site sur mesure, headless ou hérité : cela dépend de vos utilisateurs.

• Si vos clients ou votre personnel utilisent le navigateur de l'application de bureau ChatGPT, les outils impératifs dans la page de premier niveau sont les seuls qui les atteignent. Commencez par deux ou trois outils en lecture seule autour de votre tâche la plus courante (état d'une commande, disponibilité, un devis), derrière une détection de fonctionnalité, avec un token d'origin trial, et mesurez si quelqu'un les appelle.
• Si vous voulez expérimenter à peu de frais dans Chrome, des attributs déclaratifs sur des formulaires existants représentent quelques heures de travail. Ne vous arrêtez pas là : ChatGPT ne les verra pas, et la spécification ne les contient plus.
• Si vous n'avez aucune preuve que des agents vous visitent, corrigez d'abord la sémantique, les étiquettes et la mise en page. Ce travail profite à tous les agents et à toute personne qui utilise une technologie d'assistance, et rien n'en sera jeté quand l'API changera.

Dans tous les cas, gardez l'interface normale complète. Le conseil d'OpenAI : « Préservez l'interface normale pour les personnes et les navigateurs qui ne prennent pas en charge WebMCP. »

Ce qui pourrait changer

• Un Intent to Ship. L'équipe de Chrome espère le demander dans la fenêtre de prolongation, qui s'achève avec Chrome 162 (2 février 2027) si la prolongation est confirmée. Une livraison supprimerait le besoin de tokens dans Chrome.
• La forme de l'API. Une API de continuation (des résultats qui arrivent sur la page suivante après une navigation), une API de stabilité des outils et des limites de taille sont en cours de prototypage. Des versions récentes ont déjà supprimé window.ontoolactivated et les arguments sérialisés.
• Le sort de l'API déclarative. Hors de la spécification « pour le moment », toujours dans l'essai de Chrome.
• Les appelants. La prise en charge dans Gemini dans Chrome a été annoncée, pas livrée. La page d'état d'implémentation de la spécification indique, comme bientôt disponible, WebMCP pour les applications web sur les lunettes Ray-Ban Display de Meta, ainsi qu'une prise en charge expérimentale dans l'assistant Leo de Brave.

Si vous ajoutez des outils maintenant, gardez-les dans un seul module, derrière une détection de fonctionnalité, pour que le prochain changement tienne en une modification.

Où trouver de l'aide

Nous construisons les parties d'un site web et de son backend que touchent les agents : des outils qui enrobent la logique existante des commandes, des réservations et des comptes, une autorisation qui traite l'appel d'un agent comme n'importe quelle autre requête de cet utilisateur, et les corrections de sémantique et d'accessibilité qui rendent un site utilisable avant même qu'un outil existe. Notre service de développement d'agents IA et d'intégration de serveurs MCP couvre les outils WebMCP comme les serveurs MCP côté backend, qui sont autre chose malgré le nom.

Si vous voulez savoir ce qu'un agent voit aujourd'hui sur votre site, et si des outils changeraient quelque chose pour vos clients, écrivez à office@c9group.dev.