WebMCP sort des flags : Chrome 149 ouvre l'origin trial

Pendant des mois, WebMCP a vécu derrière un flag obscur. chrome://flags/#enable-webmcp-testing, depuis Chrome 146 en février. Le genre de truc que seuls les devs qui suivent les release notes Chromium activaient pour voir ce que ça donnait. Le 19 mai 2026, à Google I/O, Google a annoncé le passage en origin trial public dans Chrome 149. La différence n'est pas cosmétique : un site peut maintenant exposer WebMCP à de vrais utilisateurs, en production, sans demander à personne de bidouiller ses flags.

C'est le moment où une techno passe du labo au terrain. Et pour le SEO, ça mérite qu'on regarde sous le capot plutôt que de relayer le hype.

Un origin trial, c'est le mécanisme par lequel Chrome teste une API expérimentale grandeur nature. Vous enregistrez votre domaine, vous récupérez un token, vous l'injectez dans la page, et l'API devient active pour tous les visiteurs Chrome 149. L'essai court de Chrome 149 jusqu'à Chrome 156 selon plusieurs sources secondaires (la durée exacte n'est pas confirmée verbatim sur la doc officielle Chrome, donc je la donne sous réserve).

Concrètement, vous pouvez déclarer ce que votre site sait faire et le rendre directement consommable par un agent IA. Plus besoin que l'agent parse votre HTML, devine où est le bouton « rechercher » ou simule un clic au pixel près. Le site annonce ses capacités, l'agent les appelle.

J'ai testé l'Early Preview en mars sur un projet perso, un petit moteur de recherche interne. Brancher la version flag, c'était bricolage : ça marchait un coup sur deux selon la build Canary. Le passage en origin trial, c'est précisément ce qui rend la chose utilisable pour autre chose qu'une démo.

Le cœur technique tient dans une méthode. La spec W3C l'expose via document.modelContext ; les implémentations Chrome et la plupart des articles parlent plutôt de navigator.modelContext. Pour éviter de vous induire en erreur, je vais dire « l'API modelContext du navigateur » sans trancher sur le préfixe, parce que les deux circulent et que la spec n'est pas figée.

La méthode centrale, c'est registerTool(). Vous lui passez un nom, une description en langage naturel, un inputSchema au format JSON Schema, et un callback execute. L'agent lit la description pour comprendre à quoi sert l'outil, valide ses arguments contre le schéma, puis appelle votre fonction. Pour les devs dans la salle : c'est exactement la philosophie d'un endpoint typé, sauf que le contrat est lisible par une IA et que l'exécution se passe dans le même environnement JavaScript que votre appli.

Il y a deux façons d'exposer ces outils. L'Imperative API : vous définissez vos outils en JavaScript standard, comme décrit ci-dessus. La Declarative API : vous annotez des formulaires HTML pour qu'ils deviennent des outils WebMCP, sans écrire de JS. Sur le papier, la seconde est séduisante pour les sites sans grosse équipe technique. Sauf qu'elle est marquée « TODO » dans la spec W3C. Elle existe en exemples, pas en spécification finalisée. Donc à manier comme expérimental, pas comme acquis.

Côté outillage, Chrome DevTools a gagné un support expérimental pour inspecter les outils enregistrés sur une page, les invoquer manuellement et vérifier les définitions JSON Schema. Il existe aussi une extension, le Model Context Tool Inspector, pour jouer avec un agent et voir comment vos outils réagissent en conditions réelles. C'est ce que j'aurais aimé avoir en mars.

Là où il faut être précis, parce que je vois passer beaucoup d'approximations. WebMCP n'est pas « un standard W3C ». Le document publié le 17 juin 2026 est un Draft Community Group Report. La spec elle-même le dit noir sur blanc : ce document n'est pas un standard W3C et n'est pas sur la Standards Track du W3C. C'est un brouillon incubé par le Web Machine Learning Community Group.

Les éditeurs du standard sont Brandon Walderman (Microsoft), Khushal Sagar et Dominic Farolino (Google). Notez qui n'est pas dans la liste : Anthropic. C'est l'autre confusion fréquente.

WebMCP s'inspire du Model Context Protocol qu'Anthropic a lancé en novembre 2024, mais c'est un projet distinct, co-développé par Google et Microsoft sous l'égide du W3C, indépendamment d'Anthropic. La spec formule le lien avec honnêteté : une page qui utilise WebMCP peut être vue comme un serveur MCP qui implémente ses outils en script côté client. L'idée vient de MCP, l'implémentation web est autre chose. J'avais déjà abordé cette pile dans MCP et web agentique face au SEO, mais à l'époque WebMCP n'était qu'une couche en preview. Aujourd'hui elle a une spec datée et un origin trial. Ça vaut le coup d'y revenir.

La vraie question technique ici : MCP côté serveur, c'est un service persistant, en JSON-RPC, qui peut tourner sans navigateur. WebMCP, c'est l'inverse : éphémère, lié à l'onglet ouvert, exécuté côté client uniquement, et qui hérite de la session authentifiée de l'utilisateur. La page elle-même devient le fournisseur d'outils. Deux architectures, deux usages, qu'il ne faut pas confondre.

Pour la visibilité, le raisonnement est le même que celui qu'on tient depuis l'arrivée de l'agentic commerce : si un agent peut exécuter une action sur votre site, encore faut-il que votre site lui dise comment. WebMCP rend ce contrat explicite. Un site qui déclare proprement ses outils devient actionnable par un agent ; un site muet ne l'est pas.

Attention au piège : WebMCP n'est pas une couche de découverte. Les agents continuent de trouver votre site par les canaux classiques, autorité de domaine, backlinks, contenu indexé. WebMCP intervient après l'arrivée, comme couche d'action. Le SEO traditionnel reste nécessaire pour que l'agent vous trouve ; WebMCP sert à ce qu'il puisse faire quelque chose une fois sur place. C'est aussi ce que je répète à propos de l'optimisation pour les agents IA autonomes : la découverte et l'action sont deux problèmes séparés.

Et vos données structurées ne disparaissent pas pour autant. Un agent qui lit votre Product et votre Offer comprend ce que vous vendez ; vos outils WebMCP lui permettent ensuite d'agir dessus. Les deux couches se complètent, elles ne se remplacent pas.

Un point que ppc.land soulève et qui mérite réflexion : un agent qui n'utilise que les outils déclarés peut contourner les sections publicitaires de la page. Si vous monétisez par la pub display, un trafic agentique qui passe directement par vos outils ne voit jamais vos annonces. Le modèle économique des éditeurs prend un coup dont personne ne parle assez.

On lit partout que WebMCP réduit les erreurs de 67 %, qu'il est 89 % plus efficace en tokens, que la complétion de tâches grimpe de 45 % par rapport au scraping visuel. Ça circule dans des articles, mais je n'ai trouvé aucun benchmark indépendant publié derrière ces nombres. Ce sont des estimations de sources secondaires sans attribution à une étude primaire. Je les mentionne parce qu'ils donnent un ordre de grandeur, pas parce qu'ils sont solides. Si vous construisez un business case là-dessus, mettez-y un gros « selon certaines estimations ».

Même prudence pour l'adoption. Google a montré à I/O 2026 que de grandes marques exploraient WebMCP, Expedia, Booking.com, Shopify, Etsy, Instacart, Target entre autres. « Explorer » n'est pas « déployer en production ». C'est une exploration affichée, pas un déploiement massif vérifié.

Honnêtement, sur la question du calendrier multi-navigateurs, je préfère ne pas m'avancer. Firefox aurait engagé un support pour le troisième trimestre 2026, Safari serait attendu plus tard, mais rien n'est confirmé côté Mozilla ni côté Apple. Pour l'instant, WebMCP, c'est Chrome. Le fait que Google ait choisi un standard ouvert plutôt qu'une lib propriétaire est une invitation aux autres navigateurs à implémenter, ce qui est plutôt sain. Reste à voir qui répond.

Le passage en origin trial dans Chrome 149 fait sortir WebMCP du statut de curiosité de dev. Sous le capot, la mécanique est propre : registerTool, JSON Schema, exécution côté client. C'est un vrai pas, pas un coup de com.

Mais gardez la tête froide. WebMCP n'est pas encore un standard W3C : c'est un brouillon de Community Group. L'idée vient d'Anthropic, mais le standard, lui, est porté par Google et Microsoft, pas par Anthropic. Quant aux chiffres de performance qui circulent, aucun n'est benchmarké.

Ce que je ferais à votre place maintenant : si vous gérez un site transactionnel, jouez avec l'origin trial sur une fonction simple, une recherche ou un filtre, pour comprendre la mécanique avant que vos concurrents ne s'y mettent. Pas pour le SEO immédiat, il n'y a rien à gagner aujourd'hui. Pour ne pas découvrir l'API en panique le jour où les agents deviennent un vrai canal de trafic. C'est de l'apprentissage, pas un investissement à ROI court. Et l'apprentissage, ça se fait avant la bascule, pas pendant.

• WebMCP origin trial - Chrome for Developers
• WebMCP documentation - Chrome for Developers
• WebMCP specification - W3C Web Machine Learning Community Group
• WebMCP vs MCP - Chrome for Developers
• Chrome 149 origin trial puts WebMCP in developers hands - ppc.land
• WebMCP becomes a web agent standard in Chrome - InfoQ