WebMCP expliqué

Le 10 février 2026, André Cipriani Bandarra, de Google, a publié sur Chrome for Developers un court billet présentant une préversion de WebMCP, le Web Model Context Protocol. L'idée de départ était d'une simplicité trompeuse : et si les sites web pouvaient indiquer précisément aux agents IA ce qu'ils savent faire, au lieu de les laisser deviner ?

Cette idée, remplacer les tâtonnements par un contrat structuré entre les sites et l'IA, est désormais en passe de devenir un standard web officiel. Elle est soutenue à la fois par Google et par Microsoft, elle est incubée au sein du W3C, et sa première implémentation dans un navigateur est déjà disponible dans Chrome Canary.

Pour mesurer l'enjeu, prenons ce qui se passe aujourd'hui lorsque vous demandez à un assistant IA de vous réserver un vol. L'agent fait une capture d'écran du site de la compagnie aérienne, la transmet à un modèle de vision, essaie de repérer le champ de départ, y saisit du texte, refait une capture, cherche le bouton de recherche, clique dessus, refait une capture, et ainsi de suite : des dizaines d'appels d'inférence coûteux simplement pour remplir un formulaire. Et si la compagnie refond sa page la semaine suivante, plus rien ne fonctionne.

WebMCP remplace toute cette boucle par un seul appel de fonction : searchFlights("AMS", "JFK", "2026-06-15"). Le site publie la fonction, l'agent l'appelle, et c'est tout.

La communauté SEO a réagi immédiatement. L'expert en SEO technique Dan Petrovic y a vu le plus grand bouleversement du SEO technique depuis les données structurées, et WordLift a trouvé une analogie parlante : si Schema.org a fourni les noms standardisés du web, WebMCP en fournit les verbes standardisés.

Qu'est-ce que WebMCP ?

WebMCP signifie Web Model Context Protocol. Il s'agit d'un projet de standard web qui permet aux sites d'exposer leurs fonctionnalités sous forme d'« outils » structurés et appelables, que les agents IA peuvent invoquer directement via le navigateur.

La spécification a été co-rédigée par des ingénieurs de Google et de Microsoft : Brandon Walderman, Leo Lee et Andrew Nolan pour Microsoft, David Bokan, Khushal Sagar et Hannah Van Opstal pour Google. Elle est développée au sein du W3C Web Machine Learning Community Group, l'instance du W3C qui incube d'autres standards d'apprentissage automatique côté navigateur, avec l'objectif de devenir un standard web largement adopté.

En février 2026, WebMCP est disponible derrière un flag expérimental dans Chrome 146 Canary. Les développeurs peuvent accéder à la documentation et aux démos en rejoignant l'Early Preview Program de Google. Vu le rôle actif de Microsoft dans la rédaction de la spécification, la prise en charge par Edge devrait suivre, de l'avis général.

La spécification décrit WebMCP comme « une interface JavaScript qui permet aux développeurs web d'exposer les fonctionnalités de leur application web sous forme d'"outils", c'est-à-dire de fonctions JavaScript accompagnées de descriptions en langage naturel et de schémas structurés, que peuvent invoquer des agents IA, des assistants de navigateur et des technologies d'assistance ».

Ce dernier point, les technologies d'assistance, passe facilement inaperçu, mais il est important. Une bonne partie de ce qui rend le web difficile pour les agents IA le rend aussi difficile pour les lecteurs d'écran et les autres outils d'accessibilité. L'approche de WebMCP, fondée sur des outils structurés, pourrait nettement améliorer les deux.

Le problème que WebMCP résout

Aujourd'hui, les agents IA interagissent avec les sites web selon deux grandes approches, toutes deux fondamentalement limitées.

Les agents visuels prennent des captures d'écran des pages, les transmettent à des modèles de vision et tentent de localiser boutons et champs de formulaire en analysant les pixels. Chaque interaction exige une nouvelle capture et un nouvel appel d'inférence. Une simple recherche de produit peut demander une douzaine d'allers-retours. Et si la mise en page bouge un tant soit peu (une refonte, un test A/B, une taille d'écran différente), l'agent peut échouer.

Les agents basés sur le DOM analysent le HTML brut de la page et son arbre d'accessibilité pour extraire des données et déclencher des événements. C'est plus fiable que l'analyse de pixels, mais l'agent doit quand même engloutir une grande partie de sa fenêtre de contexte à parcourir la structure de la page, et deviner par rétro-ingénierie ce que fait réellement chaque élément. Un <button> intitulé « Go » peut aussi bien lancer une recherche que valider un formulaire, changer de page ou supprimer quelque chose : l'agent doit le déduire du contexte.

Les deux approches partagent le même défaut de fond : l'IA essaie d'utiliser une interface humaine qui n'a jamais été pensée pour des machines. Comme le dit la spécification de WebMCP, « même lorsque les agents y parviennent, des opérations simples exigent souvent plusieurs étapes et peuvent être lentes ou peu fiables ».

WebMCP propose une troisième voie. Au lieu que l'agent cherche à comprendre ce qu'un site sait faire, le site déclare explicitement ses capacités, et l'agent les appelle directement.

Comment fonctionne WebMCP

WebMCP introduit une nouvelle API de navigateur : navigator.modelContext. Grâce à elle, un site enregistre des « outils », c'est-à-dire des fonctions JavaScript dotées de descriptions en langage naturel et de schémas de paramètres typés. Ensemble, ces définitions forment ce qu'on appelle le Tool Contract du site : un menu lisible par une machine, qui recense toutes les actions qu'un agent IA peut effectuer sur la page.

La spécification propose deux façons complémentaires de définir ces outils.

L'API déclarative (basée sur HTML)

C'est la voie la plus simple. Les développeurs ajoutent de nouveaux attributs à leurs formulaires HTML existants, et le navigateur les convertit automatiquement en outils appelables par les agents. Aucun JavaScript n'est nécessaire.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

Les attributs toolname et tooldescription sont les seuls ajouts. Le navigateur lit la structure existante du formulaire (noms des champs, types, motifs de validation, champs obligatoires) et génère un schéma qu'un agent IA peut comprendre et invoquer. Pour les sites dont les formulaires sont déjà bien structurés, la mise à niveau est presque immédiate.

Lorsqu'un agent invoque un outil déclaratif, le navigateur déclenche un SubmitEvent dont la propriété agentInvoked vaut true. Le backend peut ainsi distinguer les soumissions humaines de celles des agents, ce qui sert pour les statistiques, la limitation de débit ou le renvoi de données dans un format pensé pour les machines plutôt qu'en HTML.

L'API impérative (basée sur JavaScript)

Pour les interactions qui vont au-delà d'un simple envoi de formulaire (workflows dynamiques en plusieurs étapes, traitement de données en temps réel, logique conditionnelle), les développeurs enregistrent les outils par programmation :

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

Cette approche donne un contrôle total. Les développeurs peuvent ajouter et retirer des outils à la volée selon l'état de l'application, et proposer des capacités différentes selon que l'utilisateur est connecté ou non, la page sur laquelle il se trouve ou l'étape qu'il a atteinte dans un parcours. Surtout, les fonctions de traitement peuvent réutiliser la logique frontend qui fait déjà tourner l'interface du site. Inutile de construire une couche d'intégration séparée : vous exposez ce que vous avez déjà construit.

Le navigateur comme intermédiaire

L'un des choix de conception les plus lourds de conséquences de WebMCP est que le navigateur sert d'intermédiaire pour toute communication entre le site et l'agent. Le site enregistre ses outils via navigator.modelContext. Le navigateur les présente à l'agent dans le format que celui-ci attend. Le site et l'agent ne communiquent jamais directement.

Comme l'explique Patrick Brosset, de l'équipe Microsoft Edge : « C'est le navigateur qui parle à l'agent. La spécification emploie le terme "Model context provider". Via navigator.modelContext, votre page web fournit du contexte, à savoir les outils qu'un agent IA utilise ensuite, mais c'est le navigateur qui se charge pour vous de tout le travail lié au protocole. »

Cette architecture règle trois problèmes à la fois.

L'authentification est héritée. Les outils s'exécutent dans l'onglet du navigateur, dans le cadre de la session déjà ouverte par l'utilisateur. Si vous êtes connecté à un site marchand, l'agent profite de la même session : pas de parcours OAuth séparé, pas de clés d'API, pas de gestion de jetons.

L'utilisateur garde la main. Tout se passe dans l'onglet visible du navigateur, si bien que l'utilisateur voit ce que fait l'agent. Pour les actions sensibles (achats, envoi de données personnelles, suppressions), la spécification prévoit agent.requestUserInteraction(), qui suspend l'exécution et demande au navigateur d'obtenir la confirmation explicite de l'utilisateur avant d'aller plus loin.

L'indépendance vis-à-vis des plateformes. Que l'agent qui visite le site tourne sur ChatGPT, Claude, Gemini ou un modèle d'entreprise sur mesure, le Tool Contract du site reste le même. Le navigateur normalise l'interaction.

D'où vient WebMCP

WebMCP n'est né ni chez Google ni chez Microsoft, mais chez Amazon, de la frustration d'un ingénieur.

Début 2025, Alex Nahas développait des agents IA internes chez Amazon à l'aide du Model Context Protocol (MCP) d'Anthropic. Amazon avait monté ce qui revenait à un gigantesque serveur MCP exposant des milliers d'outils répartis sur ses services internes. « Il fallait les désactiver avec des commandes de processus dans la chaîne de connexion », a raconté Nahas à Arcade.dev. C'était peu maniable, mais le vrai blocage venait de l'authentification. La spécification MCP avait adopté OAuth 2.1, que pratiquement aucun service interne d'Amazon n'avait implémenté. Chaque service avait son propre système d'authentification, et aucun ne parlait OAuth.

Nahas a alors eu une intuition : le navigateur avait déjà résolu ce problème. Les employés d'Amazon étaient connectés à chaque service interne grâce à une authentification fédérée passant par le navigateur. Si l'on pouvait exécuter des outils de type MCP dans l'onglet du navigateur, on hériterait gratuitement de toute cette authentification.

Il a créé MCP-B (Model Context Protocol for Browser) comme preuve de concept. Cela fonctionnait. Il l'a publié en open source.

Pendant ce temps, des ingénieurs de Google et de Microsoft travaillaient chacun de leur côté sur des problèmes similaires. Les équipes se sont rapprochées via le W3C, ont convergé vers une spécification unifiée en août 2025 et l'ont publiée sur GitHub. Le W3C Web Machine Learning Community Group l'a acceptée comme livrable officiel en septembre 2025. En février 2026, Google a livré la première implémentation dans un navigateur.

Une nuance importante : malgré son nom, WebMCP n'est pas techniquement du MCP. Comme l'a expliqué Nahas, il avait d'abord plaidé pour porter le protocole MCP complet (JSON-RPC compris) dans le navigateur, mais le groupe de travail a choisi de ne pas trop se lier à la spécification d'Anthropic. WebMCP reprend le modèle conceptuel de MCP (des outils dotés de schémas, que les agents appellent), mais c'est un standard distinct, natif du navigateur.

WebMCP, MCP et NLWeb

Les noms prêtent à confusion ; il vaut donc la peine de préciser la place de WebMCP parmi les autres protocoles de l'écosystème des agents IA.

Le MCP (Model Context Protocol) d'Anthropic est un protocole backend. Il relie les plateformes d'IA à des services externes au moyen d'intégrations côté serveur reposant sur JSON-RPC. Si vous voulez que Claude ou ChatGPT interroge la base de données de votre entreprise, c'est avec MCP que vous construisez cette connexion. Il nécessite une infrastructure serveur dédiée.

NLWeb, de Microsoft, annoncé en mai 2025, dote les sites d'une interface de requête en langage naturel et fait de chaque site un serveur MCP pour les agents de l'écosystème au sens large. Il fonctionne au niveau des API : les agents s'adressent directement au backend du site.

WebMCP fonctionne entièrement côté client, dans le navigateur. Le site enregistre ses outils au chargement de la page, et le navigateur les expose aux agents qui le visitent. Aucune infrastructure serveur n'est nécessaire, et l'authentification est héritée de la session de l'utilisateur.

Les trois sont complémentaires, pas concurrents. Une entreprise peut utiliser MCP pour des intégrations backend poussées, NLWeb pour un accès en langage naturel au niveau des API, et WebMCP pour les interactions dans le navigateur, quand l'utilisateur est présent. La différence essentielle : WebMCP est le seul des trois qui permet de réutiliser le code frontend existant sans exiger la moindre nouvelle infrastructure côté serveur.

Pourquoi c'est important

Ce qui fait l'intérêt de WebMCP, c'est moins une fonctionnalité en particulier que la combinaison de plusieurs propriétés.

Un coût par interaction bien plus faible. Un seul appel d'outil structuré remplace ce qui exigeait auparavant des dizaines d'échanges successifs mêlant captures d'écran, inférence par un modèle de vision et analyse du DOM. Les premiers retours font état d'une réduction d'environ 67 % de la charge de calcul par rapport aux agents visuels. Pour des sites très fréquentés, qui traitent des milliers d'interactions d'agents par jour, les économies sont considérables.

Une fiabilité indépendante du design. Les appels de fonction structurés ne cessent pas de fonctionner quand un designer déplace un bouton, renomme une classe CSS ou lance un test A/B. Le Tool Contract offre une interface stable, indépendante de la mise en page, ce qui permet aux agents et aux designers web d'évoluer chacun de leur côté.

Un effort minimal pour les développeurs. L'API déclarative demande simplement d'ajouter deux attributs HTML aux formulaires existants. Pas de JavaScript, pas de nouveaux endpoints, pas de documentation d'API à maintenir. Pour la majorité des sites, le chemin pour devenir « prêt pour les agents » est plus court que la plupart des optimisations SEO.

L'accessibilité en prime. Les mêmes définitions d'outils structurées qui aident les agents IA aident aussi les technologies d'assistance. Les lecteurs d'écran et autres outils d'accessibilité se heurtent à bon nombre des mêmes difficultés que les agents IA pour comprendre ce qu'une page fait, et pas seulement ce qu'elle dit. WebMCP pourrait sensiblement améliorer les deux.

Secteurs et cas d'usage

La documentation de la préversion de Google met en avant plusieurs cas d'usage principaux, qui reposent tous sur des parcours utilisateur structurés en plusieurs étapes.

Le commerce en ligne est le bénéficiaire le plus évident. Au lieu qu'un agent IA tâtonne entre les filtres de produits, les sélecteurs de taille et le tunnel de paiement, une boutique expose des outils comme searchProducts(query, priceRange, category), addToCart(productId, quantity, size) et checkout(paymentMethod). Tout le parcours, de la découverte à l'achat, se résume à une série d'appels de fonction propres. Pour les entreprises, cela pourrait se traduire par des taux de conversion nettement plus élevés pour les achats passés par des agents.

Le voyage et l'hôtellerie s'y prêtent naturellement. La recherche de vols, la réservation d'hôtels et la location de voitures sont des transactions structurées, à plusieurs paramètres, qui se traduisent directement en définitions d'outils. Google a explicitement cité la réservation de voyages comme l'un des principaux cas d'usage validés.

Les produits SaaS peuvent exposer leurs principaux workflows aux agents. Imaginez dire à un assistant IA « crée un nouveau tableau de projet avec trois colonnes et invite mon équipe » et le voir exécuter la demande au moyen d'appels d'outils structurés plutôt que de clics et de frappes simulés.

Le support client peut définir des outils pour créer des tickets, vérifier leur statut et catégoriser les problèmes. Un agent capable d'appeler directement createTicket(category, urgency, description) est bien plus fiable qu'un agent obligé de parcourir visuellement un formulaire d'assistance en plusieurs étapes.

Les conséquences pour le SEO

La vive réaction de la communauté SEO à WebMCP n'a rien d'un effet de mode : elle traduit un changement structurel dans la manière dont les sites sont découverts et utilisés.

L'analogie avec Schema.org est éclairante. À leur lancement, les données structurées ont donné aux moteurs de recherche un moyen standardisé de comprendre ce que signifie un contenu. Les sites qui les ont adoptées tôt ont gagné des extraits enrichis, des places dans les knowledge panels et une meilleure visibilité dans les résultats. Ceux qui ne l'ont pas fait se sont retrouvés avec un retard qu'il leur a fallu des années pour combler.

WebMCP fait quelque chose de comparable, mais pour une autre époque. Il donne aux agents IA un moyen standardisé de comprendre quelles actions un site permet. À mesure que les agents deviennent un canal majeur par lequel les gens utilisent le web (réserver un voyage, faire des achats, gérer des services), les sites dotés de Tool Contracts clairs et fiables seront ceux avec lesquels les agents pourront travailler en toute confiance.

Cela crée une nouvelle dynamique concurrentielle. Si un agent IA peut appeler directement bookFlight() sur un site de voyage, mais doit se frayer un chemin à coups d'analyse de pixels sur un autre, l'option structurée sera plus rapide, moins coûteuse et moins sujette aux erreurs. Avec le temps, cet avantage de fiabilité fait boule de neige : les agents (et les plateformes qui les hébergent) orienteront naturellement les utilisateurs vers les sites avec lesquels il est plus simple et moins cher d'interagir.

Pour les entreprises, être prêt pour WebMCP pourrait devenir aussi important que l'était le responsive design il y a dix ans. Pas du jour au lendemain, mais progressivement, à mesure que la prise en charge par les navigateurs s'étend et que les interactions passant par des agents se multiplient.

Comment démarrer

WebMCP est en préversion, ce qui signifie que la fenêtre d'adoption précoce est ouverte dès maintenant.

Passez en revue les parcours clés de votre site. Identifiez les principales actions des utilisateurs (recherche, réservation, paiement, envoi de formulaires, gestion de compte) qui gagneraient à être exposées sous forme d'outils. Commencez par les transactions à plus forte valeur.

Commencez par l'API déclarative. Si vous avez des formulaires HTML propres et bien structurés, ajouter les attributs toolname et tooldescription est la voie la plus rapide. Cela ne demande aucun JavaScript et très peu de modifications de code.

Rejoignez l'Early Preview Program. L'EPP de Google donne accès à la documentation complète, aux démos et aux outils de test. L'inscription se fait sur le site Chrome for Developers.

Testez dans Chrome Canary. Activez le flag « WebMCP for testing » dans Chrome 146 Canary. Le Model Context Tool Inspector de Google fournit des outils de débogage pour valider vos définitions d'outils.

Explorez l'API impérative pour les workflows complexes qui nécessitent un enregistrement dynamique des outils ou une logique en plusieurs étapes.

Pour les développeurs qui veulent commencer avant que la prise en charge native se généralise dans les navigateurs, le polyfill MCP-B d'Alex Nahas (@mcp-b/global) permet dès aujourd'hui d'enregistrer des outils avec navigator.modelContext.registerTool(). Il fonctionne avec les frameworks frontend d'appel d'outils existants, comme CopilotKit, AGUI et SystintUI. La documentation complète se trouve sur docs.mcp-b.ai.

La spécification du W3C est disponible sur GitHub.

Et ensuite ?

La spécification n'est encore qu'un brouillon, mais la trajectoire est claire.

Un déploiement officiel dans les navigateurs est attendu entre le milieu et la fin de 2026. Google I/O et Google Cloud Next sont les rendez-vous les plus probables pour des annonces plus larges. Microsoft étant co-auteur de la spécification, la prise en charge par Edge devrait suivre le calendrier de Chrome. Patrick Brosset, de l'équipe Edge, a clairement indiqué que l'investissement se poursuivrait : « Dans l'équipe Edge, nous tenons à garder dans la boucle non seulement l'humain, mais aussi les développeurs. C'est pour cela que WebMCP nous importe. »

L'API continue d'évoluer. L'interface est déjà passée de l'ancien window.agent à window.navigator.modelContext, et des fonctions comme agent.requestUserInteraction() ont été ajoutées depuis la proposition initiale d'août 2025. La communauté du W3C affine activement la spécification à partir de tests en conditions réelles.

La prise en charge multimodale figure dans la feuille de route de l'écosystème MCP au sens large. Les futures versions du protocole devraient gérer les images, la vidéo et l'audio : les agents ne se contenteront plus de lire et d'écrire, ils interpréteront aussi des contenus visuels et sonores dans le même cadre.

La communication entre agents est la prochaine frontière. La spécification actuelle se concentre sur l'interaction entre l'utilisateur et l'agent via le navigateur, mais la feuille de route prévoit des scénarios où des agents délèguent des tâches à d'autres agents, sur plusieurs services et plusieurs pages.

Questions fréquentes

WebMCP est-il la même chose que le MCP d'Anthropic ? Non. Ils partagent un modèle conceptuel (des outils dotés de schémas que les agents peuvent appeler), mais WebMCP est un standard distinct. Il n'utilise pas JSON-RPC, s'exécute entièrement dans le navigateur (et non sur des serveurs backend) et a été conçu spécifiquement pour la plateforme web. Les deux sont complémentaires : une entreprise peut adopter l'un et l'autre pour des usages différents.

Quels navigateurs prennent en charge WebMCP ? En février 2026, WebMCP est disponible dans Chrome 146 Canary, derrière le flag « WebMCP for testing ». La prise en charge par Edge est largement attendue, vu le rôle de Microsoft dans la rédaction de la spécification. Le déploiement officiel est prévu entre le milieu et la fin de 2026.

Dois-je réécrire mon site ? Non. L'API déclarative vous permet d'ajouter la prise en charge de WebMCP en ajoutant deux attributs HTML aux formulaires existants. Pour les sites au HTML propre et bien structuré, les modifications sont minimes. L'API impérative nécessite du JavaScript, mais peut réutiliser la logique frontend existante.

Les agents IA peuvent-ils agir sans l'autorisation de l'utilisateur ? Pas par conception. WebMCP inclut agent.requestUserInteraction(), qui suspend l'exécution pour obtenir la confirmation de l'utilisateur sur les actions sensibles. La spécification repose sur le principe qu'aucune action lourde de conséquences ne doit se produire sans que l'utilisateur en ait connaissance et y consente.

WebMCP améliore-t-il l'accessibilité ? Potentiellement, oui. Les définitions d'outils structurées qui aident les agents IA à comprendre ce que fait une page peuvent aussi aider les lecteurs d'écran et les autres technologies d'assistance. La spécification du W3C cite explicitement les technologies d'assistance comme cas d'usage visé, aux côtés des agents IA.

Quel est l'impact de WebMCP sur le SEO ? Le tableau complet reste à dessiner, mais le parallèle structurel avec Schema.org est évident. À mesure que les agents IA deviennent un canal de transaction et de découverte, les sites dotés de Tool Contracts bien définis seront plus simples et moins coûteux à utiliser pour les agents, ce qui leur donnera un avantage naturel, comparable à celui dont ont profité dans la recherche les premiers à adopter les données structurées.

En résumé

Depuis trente ans, le web est un espace conçu pour des yeux et des mains humains. Chaque page, chaque bouton, chaque formulaire suppose qu'une personne se trouve de l'autre côté. WebMCP est le premier effort sérieux, adossé à un standard, pour rendre le web nativement compréhensible et exploitable par les agents IA, sans pour autant retirer l'humain de la boucle.

Il est encore tôt. La spécification n'est qu'un brouillon, la prise en charge par les navigateurs reste expérimentale. Mais les fondations sont solides : deux des plus grands éditeurs de navigateurs qui collaborent au sein du W3C, une implémentation fonctionnelle déjà disponible pour les tests, et une expérience développeur assez simple pour que la plupart des sites puissent démarrer avec deux attributs HTML.

Les entreprises qui ont compris tôt l'importance des données structurées en ont tiré des années d'avance dans la recherche. La même fenêtre s'ouvre aujourd'hui avec WebMCP, et elle ne restera pas ouverte indéfiniment.