WebMCP, présenté par Google à la conférence I/O 2026 et co-conçu avec Microsoft, répond à une question restée ouverte depuis l’arrivée des agents IA dans le navigateur : comment un site peut-il offrir ses fonctions à un agent sans que celui-ci ait à cliquer à l’aveugle dans le DOM ? La proposition, portée au W3C, prolonge le protocole MCP jusqu’à l’onglet du navigateur.
De MCP au navigateur : ce que WebMCP ajoute
Le Model Context Protocol relie un agent à des ressources situées côté serveur : base de données, système de fichiers, API tierce. WebMCP déplace ce principe dans la page. Un site déclare ses propres actions comme des outils structurés, et l’agent qui s’exécute dans le navigateur les appelle directement, avec le contexte de session déjà en place : utilisateur authentifié, panier en cours, filtres actifs.
Le point décisif tient à la réutilisation. WebMCP reprend le schéma d’outil de MCP : une même définition peut vivre dans un serveur MCP et dans une exposition côté navigateur, sans réécrire le contrat.
WebMCP ne remplace pas MCP : il en prolonge la portée, du serveur jusqu’à l’onglet du navigateur.
Comment un site déclare ses outils
L’API repose sur un objet global, document.modelContext, et sa méthode registerTool. Chaque outil porte un nom, une description lisible par l’agent, un schéma d’entrée au format JSON Schema et un gestionnaire asynchrone qui renvoie un résultat structuré.
const controller = new AbortController();
await document.modelContext.registerTool({
name: "ajouter-tache",
description: "Ajoute un element a la liste de taches active de l'utilisateur",
inputSchema: {
type: "object",
properties: {
texte: { type: "string", description: "Contenu de la tache" }
},
required: ["texte"]
},
async execute({ texte }) {
await ajouterTache(texte);
return {
content: [{ type: "text", text: `Tache ajoutee : "${texte}"` }]
};
}
}, { signal: controller.signal });
Le signal d’AbortController permet de retirer l’outil quand le composant est démonté ou quand l’état de la page rend l’action caduque. Une variante déclarative, encore en cours de spécification, vise à exposer des formulaires HTML existants sans code supplémentaire.
Où en est le déploiement
WebMCP est un rapport de groupe communautaire du W3C, publié pour la première fois en août 2025 par le Web Machine Learning Community Group et révisé le 28 juillet 2026. Chrome ouvre un essai d’origine à partir de la version 149, avec une intégration de l’agent Gemini annoncée dans la foulée. Edge devrait suivre, Microsoft étant co-auteur ; Firefox et Safari n’ont pas encore pris d’engagement public ferme. Côté frameworks, Angular a intégré un support expérimental dans sa version 22, et des plateformes comme Shopify ou Cloudflare l’exposent à titre expérimental sur les sites qu’elles hébergent.
| Critère | MCP (côté serveur) | WebMCP (côté navigateur) |
|---|---|---|
| Où s’exécute l’outil | Serveur MCP, hors du navigateur | Dans la page, en JavaScript |
| Ce que l’agent atteint | Base de données, fichiers, API tierces | Fonctions et formulaires du site |
| Contexte de session | À reconstituer (jetons, identifiants) | Déjà présent (utilisateur connecté) |
| Schéma d’outil | Schéma MCP | Même schéma, réutilisé |
| Cas d’usage type | Agent relié à un back-office | Agent qui agit sur le site consulté |
Les questions que le standard laisse ouvertes
Exposer des actions à un agent, c’est ouvrir une surface. Un outil qui déclenche un paiement ou modifie des données doit rester sous contrôle explicite de l’utilisateur, et non s’exécuter au seul jugement d’un agent. La spécification s’appuie sur le modèle d’origine du navigateur et sur le contexte de session, mais le consentement, la journalisation des appels et la limitation de débit restent largement à la charge de celui qui implémente.
Point de vigilance. Un outil WebMCP hérite des droits de la session en cours. Réserver l’exposition aux actions idempotentes ou confirmables, exiger une validation de l’utilisateur pour toute opération sensible (paiement, suppression, envoi) et traiter les paramètres reçus comme des entrées non fiables restent des précautions indispensables.
Ce qu’il faut retenir
WebMCP standardise une brique qui manquait : un canal d’intention entre un site et l’agent qui l’utilise, adossé au schéma d’outil déjà connu de MCP. La proposition est jeune, limitée pour l’instant à un essai d’origine dans Chrome, et son adoption dépendra autant des autres navigateurs que des garde-fous de sécurité qui l’accompagneront. Pour les équipes web, elle dessine une compétence à surveiller de près : concevoir des sites lisibles non plus seulement par des humains, mais aussi par des agents.
Je vois dans WebMCP la suite logique de ce que MCP a lancé côté serveur, et le pari me paraît juste : plutôt que de laisser les agents deviner l’interface en cliquant dans le DOM, on leur donne un contrat explicite. Mais je reste prudent sur le calendrier. Tant que Firefox et Safari n’ont pas tranché, j’exposerais WebMCP en amélioration progressive, jamais comme unique chemin d’accès à une fonctionnalité. Et je garderais la règle qui vaut pour toute API publique : ne jamais exposer une action destructrice sans confirmation humaine. — Simon Janvier
Pour aller plus loin
Spécification WebMCP, W3C Web Machine Learning Community Group : github.com/webmachinelearning/webmcp
