# WebMCP, c’est quoi ? Le guide d’un site qui l’utilise
> WebMCP expliqué : comment une page confie des outils à l’agent IA de votre navigateur, ce qui le distingue de MCP, pourquoi Safari s’y oppose, et ce que 25 outils en production nous ont appris.
Source : https://contenttosocial.com/fr/guides/webmcp
Mis à jour le 2026-10-01 · 25 min de lecture
WebMCP est un projet de standard web qui permet à une page de confier à l’agent IA de votre navigateur une courte liste d’**outils** : des fonctions nommées, décrites, aux paramètres typés. L’agent les appelle dans votre session, connecté comme vous, au lieu de lire des captures d’écran et de deviner où cliquer.
Il est rédigé au W3C par des ingénieurs de Google et de Microsoft, tourne en phase d’essai dans Chrome et Edge, et Safari s’y oppose. Ce site expose 25 outils WebMCP. Voici tout ce que nous avons appris, et ce qu’en disent ceux qui construisent le standard.
### Un appel d’outil, du début à la fin
1. **Page → Navigateur** : `registerTool(find_seo_agencies)`. La page déclare ce qu’elle sait faire.
2. **Agent → Navigateur** : `getTools()`. L’agent lit noms, descriptions, schémas.
3. **Agent → Page** : `executeTool({ city: "Lyon" })`. Il demande une action, avec des arguments typés.
4. **Page** : `execute()`. La page exécute son propre code, dans la session.
5. **Page → Agent** : `"[{ name: … }]"`. Des données reviennent. Ni capture, ni devinette.
- **2025** : Premières propositions
- **0,8 %** : Des pages Chrome qui déclarent un outil
- **1 sur 3** : Moteurs de navigateur engagés
- **1** : Agent qui l’utilise : ChatGPT
- **25** : Outils sur ce site
## Les agents lisent le web par le trou de la serrure.
Les agents IA utilisent déjà les sites web. ChatGPT, Claude, Gemini ou Copilot savent ouvrir une page, la lire et agir dessus. Mais ils le font comme une personne, sans les yeux : une capture d’écran ou la lecture du code de la page, une décision sur l’endroit où cliquer, un clic, une attente, puis un nouveau regard. À chaque étape, toute l’image repasse par le modèle.
Cette boucle est lente, coûteuse et fragile. Pour un modèle, une page moderne est un empilement de `div` dont le sens tient aux pixels et aux feuilles de style. Le développeur Maximiliano Firtman a résumé cette fragilité d’une question, dans le podcast AI Native Dev : que se passe-t-il si le JavaScript déplace le bouton pendant que le modèle réfléchit encore ?
Le site, lui, n’a pas voix au chapitre. Il ne peut pas indiquer à l’agent le bon chemin, l’étape risquée, ni le vrai sens d’un champ. À dotAI 2026, Patrick Brosset (Microsoft Edge) l’a dit simplement : les agents actuels fonctionnent malgré les sites, pas avec eux.
WebMCP inverse la relation. Plutôt que de laisser l’agent rétro-concevoir l’interface, le site annonce ce qu’on peut y faire (chercher un vol, ajouter au panier, remplir ce template) sous forme de fonctions aux paramètres typés. L’agent les appelle, et la page les exécute avec son propre code.
> “Que se passe-t-il si, pendant ces cinq à dix secondes, le JavaScript déplace ce bouton ?”
>
> — Maximiliano Firtman, Développeur web et auteur. [AI Native Dev, épisode 99](https://tessl.io/podcast/99)
### Sans WebMCP
1. Capturer la page ou lire son code
2. Deviner le prochain clic
3. Cliquer, attendre la page
4. Capturer à nouveau
5. Recommencer à chaque étape
Chaque étape repasse par le modèle.
### Avec WebMCP
1. Lire les outils de la page
2. En appeler un avec des arguments typés
3. Recevoir des données
La page fait le travail, dans la session de l’utilisateur.
### Ce que disent les chiffres, et ce qu’ils ne disent pas
- **5 à 11 fois moins de tokens, 3 à 5 fois plus rapide.** Le même modèle avec des outils WebMCP plutôt qu’à coups de clics, dans le [benchmark WindTunnel](https://webmcp.com/benchmark) de nekuda (8 sites, 49 tâches, 3 087 tentatives). C’est le seul benchmark d’envergure à ce jour, et celui d’un éditeur : nekuda a écrit les outils testés et vend des produits WebMCP.
- **Les outils gagnent en réussite, pas toujours en coût.** Dans l’étude [« Beyond Browsing »](https://arxiv.org/abs/2410.16464) de Carnegie Mellon, un agent qui appelle des API réussit deux fois plus souvent qu’un agent qui navigue (29,2 % contre 14,8 %), mais coûte environ 12 fois plus cher par tâche, sa documentation d’API remplissant le prompt. De courtes listes d’outils bien décrits sont la réponse de WebMCP.
- **La couverture décide.** Quand les outils ne couvrent pas la tâche, les agents qui n’ont qu’eux perdent : 53 % de réussite contre 71 % pour les agents d’écran dans [MCPWorld](https://arxiv.org/abs/2506.07672). Les hybrides, qui utilisent les outils et reviennent à l’interface au besoin, font le meilleur score dans toutes les études trouvées : c’est exactement le modèle de WebMCP.
Deux chiffres circulent sans leur origine. « 89 % de tokens en moins » vient d’une seule démo scriptée de MCP-B, pas de Google. « 67 % de calcul en moins et 98 % de précision » vient d’un autre article de 2025, sur un format de métadonnées aussi appelé webMCP, où la précision était en fait un peu plus basse que la référence (97,9 % contre 98,8 %). Google, Microsoft et OpenAI n’ont publié aucun chiffre de performance.
## Trois acteurs, un appel d’outil.
WebMCP met en jeu trois parties. La **page** déclare des outils. Le **navigateur** tient la liste et transmet les appels dans les deux sens. L’**agent**, intégré au navigateur, installé en extension ou logé dans le navigateur d’une application de bureau, lit la liste et décide quoi appeler. Aucun serveur au milieu : comme l’a dit un ingénieur à BlinkOn 21, le navigateur joue le rôle d’un serveur MCP, sans qu’aucun serveur n’existe.
- **La page** : Déclare ses outils depuis son propre JavaScript et les exécute quand on les appelle : mêmes fonctions que ses boutons, mêmes cookies, mêmes droits.
- **Le navigateur** : Garde les outils de chaque onglet, les présente à l’agent, achemine les appels vers la page et garde l’humain dans la boucle.
- **L’agent** : Lit les noms, descriptions et schémas, choisit un outil, envoie les arguments et lit le texte qui revient.
- **Il agit en tant qu’utilisateur.** Les outils s’exécutent dans l’onglet ouvert, avec la session que la personne a déjà. Ni clé d’API, ni OAuth, ni nouvel identifiant : l’onglet fermé, l’accès disparaît avec lui.
- **Il vit et meurt avec la page.** Les outils n’existent que tant que la page qui les a déclarés est ouverte. On change de page, ils disparaissent ; la suivante déclare les siens. Kasper Kulikowski (Chrome) les dit liés à l’onglet et éphémères.
- **Il garde l’humain dans la boucle.** La cible, c’est la navigation à deux : la personne voit la page changer pendant que l’agent travaille et garde les étapes qui engagent. Un outil de formulaire remplit les champs ; par défaut, c’est l’humain qui valide.
- **Il ne montre que ce que l’utilisateur peut faire.** Les outils sont déclarés par le code de la page, pour la personne qui la regarde. L’agent d’un visiteur déconnecté ne voit jamais « payer », parce que la page ne le déclare pas.
- **Il se dégrade sans casser.** Pas d’outil pour la tâche ? L’agent revient à l’interface, comme avant. WebMCP est un chemin plus rapide et plus sûr pour les agents, pas une barrière.
### La vie d’un outil
1. **Déclarer.** La page appelle `document.modelContext.registerTool()` avec un nom, une description, un schéma JSON, une fonction `execute` et un `AbortSignal`.
2. **Découvrir.** L’agent liste les outils de l’onglet ; un événement `toolchange` signale chaque changement de cette liste.
3. **Appeler.** L’agent envoie les arguments. Le navigateur déclenche `toolactivated` et achemine l’appel vers la page.
4. **Exécuter.** `execute(input, { signal })` tourne dans la page avec la session de l’utilisateur, met l’interface à jour et renvoie n’importe quelle valeur sérialisable en JSON.
5. **Libérer.** Annuler le signal, ou quitter la page, retire l’outil.
> “L’agent préférera toujours les outils conçus pour lui quand ils existent, mais il peut revenir à l’interface web, comme un utilisateur.”
>
> — Khushal Sagar, Ingénieur Chrome, éditeur de la spécification. [Web AI Summit 2025](https://www.youtube.com/watch?v=p1l8nkQAoUw)
## Deux façons d’écrire un outil.
Il existe deux variantes. L’API **impérative**, en JavaScript, peut tout faire. L’API **déclarative** tient en quelques attributs HTML posés sur un formulaire existant. Pour l’agent, aucune différence : comme le dit Dominic Farolino, éditeur de la spécification, à BlinkOn, il n’y a au fond que des outils.
### Impérative : une fonction JavaScript
Déclarez l’outil sur `document.modelContext`. Sa fonction `execute` doit appeler le même code que vos boutons, mettre à jour ce que voit la personne, et renvoyer des données (toute valeur sérialisable en JSON). Le navigateur ne valide pas encore les entrées : `execute` vérifie les siennes.
```js
if ("modelContext" in document) {
const registration = new AbortController();
await document.modelContext.registerTool(
{
name: "search_flights",
description:
"Search flights between two airports on one date. " +
"Returns up to 10 offers with price, duration and stops.",
inputSchema: {
type: "object",
properties: {
from: { type: "string", description: "Departure airport, IATA code" },
to: { type: "string", description: "Arrival airport, IATA code" },
date: { type: "string", format: "date" },
},
required: ["from", "to", "date"],
},
annotations: { readOnlyHint: true },
async execute({ from, to, date }, { signal }) {
// The same function the search button calls.
const offers = await searchFlights({ from, to, date, signal });
// The person sees what the agent asked for.
showResults(offers);
return offers.slice(0, 10);
},
},
{ signal: registration.signal },
);
}
// Later: registration.abort() removes the tool.
```
- **Les annotations sont des indices, pas des garde-fous.** Il y en a quatre : `readOnlyHint` (l’outil ne modifie rien), `untrustedContentHint` (son résultat contient du contenu que le site n’a pas écrit, comme des avis), `consequentialHint` (l’action mérite une confirmation) et `debugging`. WebMCP n’a pas de `destructiveHint`, quoi qu’en disent les tutoriels MCP, et rien n’impose de demander confirmation.
- **Les iframes demandent trois accords** : `allow="tools"` sur l’iframe, `exposedTo` sur l’outil, et `fromOrigins` quand l’appelant liste les outils. Une politique d’autorisations `tools` désactive WebMCP pour un document et ses cadres.
### Déclarative : des attributs sur un formulaire
Ajoutez `toolname` et `tooldescription` à un `
```
### Laquelle l’emporte ?
Pendant la phase d’essai de Chrome, des outils ont été déclarés en JavaScript **environ 172 millions de fois**, et par formulaire HTML **environ 20 000 fois**, selon les chiffres donnés par Dominic Farolino lors de la revue d’architecture du W3C. Le navigateur de ChatGPT ne prend en charge que l’API impérative, et seulement sur la page principale.
### L’API a bougé en 2026. La plupart des tutoriels, non.
Du code écrit avant juin 2026 échoue souvent aujourd’hui. Ce qui a changé, d’après l’historique de la spécification et la documentation de Chrome :
| Quand | Ce qui a changé | Que faire |
| --- | --- | --- |
| 5 mars | `provideContext()` et `clearContext()` supprimés | Déclarer les outils un par un. En partie parce qu’un script tiers pouvait remplacer en silence les outils de la page. |
| 27 mars | `unregisterTool()` supprimé | Passer un `AbortSignal` à la déclaration, puis l’annuler. |
| 27 mai | `navigator.modelContext` devient `document.modelContext` | Les outils appartiennent à une page, pas au navigateur. Détecter les deux tant que d’anciennes versions circulent. |
| 11 juin | `execute(input, client)` devient `execute(input, { signal })` ; `requestUserInteraction()` supprimé « pour l’instant » | La confirmation revient aux agents et aux navigateurs : prévoyez-la dans votre parcours. |
| 3 sept. | Ajout de `consequentialHint` | Signaler les paiements, envois et suppressions. |
| 4 sept. | Les agents sans interface entrent dans le périmètre | Les premières documentations promettaient un humain toujours présent. Ce n’est plus une hypothèse sûre. |
| 30 sept. | L’isolation d’origine n’est plus exigée | La documentation de Chrome dit encore le contraire ; il faudra quelques versions pour que cela arrive en stable. |
| Chrome 153 | Les arguments d’`executeTool()` passent en texte JSON | Des objets sont prévus pour Chrome 155 ; acceptez les deux dans vos tests. |
## WebMCP n’est pas MCP.
Le nom laisse croire à un portage dans le navigateur du Model Context Protocol d’Anthropic. Ce n’en est pas un. MCP est un protocole client-serveur : des messages JSON-RPC entre une application d’IA et un serveur que vous hébergez, désormais gouverné par l’Agentic AI Foundation de la Linux Foundation. WebMCP n’a ni protocole ni serveur. C’est une API JavaScript dans la page, rédigée au W3C.
Ce qu’ils partagent, c’est la forme d’un outil (un nom, une description, un schéma JSON) : les mêmes définitions peuvent donc servir aux deux. Alex Nahas, dont le projet a lancé le mouvement, voulait faire entrer le JSON-RPC de MCP dans le navigateur, et a perdu ce débat. Même l’éditeur de Microsoft, Brandon Walderman, disait tôt que le « P » le gênait : il s’agit d’une API du DOM, pas d’un protocole. La position de Mozilla est plus directe : « Il n’y a pas de MCP ici. »
**Quatre façons, pour un agent, d’utiliser un site**
| | WebMCP | Serveur MCP | Agent qui lit l’écran | llms.txt |
| --- | --- | --- | --- | --- |
| Où tourne le code | Dans la page ouverte | Sur votre serveur | Nulle part : l’agent clique | Nulle part : un fichier texte |
| Connexion | La session de l’utilisateur | OAuth ou clés d’API | La session de l’utilisateur | Aucune |
| Page ouverte nécessaire | Oui | Non | Oui | Non |
| Qui affiche le résultat | L’interface du site | L’interface de l’agent | L’interface du site | L’agent |
| Peut agir | Oui, via le code du site | Oui | Oui, en cliquant | Non, lecture seule |
| Idéal pour | Le travail en direct, connecté et visuel, sous les yeux de la personne | L’automatisation en arrière-plan et les tâches internes | Les sites qui n’offrent rien d’autre | Aider les agents à lire et à citer |
Beaucoup d’équipes feront les deux. **Shopify** propose Checkout MCP pour les agents sur serveur et Checkout WebMCP pour les agents dans le navigateur de l’acheteur, sur le même objet de commande, et conseille la version serveur dès que l’agent peut tourner sur un serveur. Les MCP Apps vont dans l’autre sens : elles font entrer l’interface d’un site dans la conversation de l’agent, quand WebMCP fait entrer l’agent dans le site.
### Ce que la plupart des articles se trompent à dire
- ~~« C’est un standard du W3C. »~~ C’est un brouillon de Community Group. Aucun Working Group ne l’a adopté, et la revue d’architecture est toujours ouverte.
- ~~« C’est sorti dans Chrome 146. »~~ 146 a apporté une option pour les développeurs. Chrome 149 à 156 mènent une phase d’essai, une prolongation jusqu’à 162 est demandée, et aucune intention de livrer n’a été déposée.
- ~~« Tous les agents peuvent s’en servir. »~~ Prendre en charge l’API et appeler des outils sont deux choses. Un seul agent grand public le fait : le navigateur de ChatGPT sur ordinateur. Gemini dans Chrome est annoncé ; Claude dans Chrome et Copilot dans Edge ne montrent aucun support public.
- ~~« Utilisez `navigator.modelContext` et `unregisterTool()`. »~~ Les deux ont disparu : c’est `document.modelContext`, et on retire un outil en annulant un signal.
- ~~« Les formulaires s’envoient tout seuls. »~~ Seulement avec `toolautosubmit`. Sinon l’agent remplit, et la personne envoie.
- ~~« Ça vous fera ranker dans la recherche IA. »~~ Les outils ne s’explorent pas : ils n’existent que tant que la page est ouverte dans un navigateur.
## D’un contournement chez Amazon à un brouillon du W3C.
WebMCP n’est pas né sur la feuille de route d’un navigateur. Il est né d’un problème de connexion.
- **Mars 2025, Le nom apparaît.** Le développeur Jason McGhee publie un projet appelé WebMCP, première apparition du nom, pour que des sites proposent des outils à des clients IA locaux.
- **Juin–juil. 2025, Un serveur MCP dans une page web.** Chez Amazon, Alex Nahas veut que ses collègues utilisent des agents sur les outils internes. Le MCP distant reposait sur OAuth, Amazon sur une authentification unique SAML, et le serveur MCP interne avait grossi jusqu’à des milliers d’outils. Sa réponse : faire tourner le serveur dans le JavaScript d’une page où l’utilisateur est déjà connecté. Il l’appelle MCP-B (le B pour browser, « Browser MCP » étant déjà pris), et le présente sur Hacker News le 9 juillet.
- **Juil. 2025, Deux navigateurs, la même idée.** Le 9 juillet, Chrome annonce son intention de prototyper une « Script Tools API ». Le 16 juillet, Microsoft Edge publie son explainer « Web Model Context », signé Andrew Nolan et Brandon Walderman.
- **Août 2025, Une seule proposition.** Les deux propositions fusionnent au sein du Web Machine Learning Community Group du W3C entre le 7 et le 18 août, le travail de Nahas étant reconnu comme expérience d’implémentation. Le 29 août, Patrick Brosset montre un prototype d’Edge piloté depuis VS Code.
- **25 sept. 2025, Officiellement au W3C.** La charte révisée du groupe entre en vigueur avec WebMCP parmi ses livrables. Éditeurs : Khushal Sagar et Dominic Farolino (Google), Brandon Walderman (Microsoft). En novembre, le groupe se réunit au TPAC de Kobe, et Sagar présente WebMCP au Web AI Summit de Google.
- **10 févr. 2026, L’essai développeurs de Chrome.** Chrome 146 livre WebMCP derrière une option, avec une extension d’inspection pour appeler les outils à la main. L’équipe relations développeurs de Chrome reconnaît ne pas avoir encore testé avec de vrais agents.
- **Mars–juin 2026, L’API est reconstruite.** `provideContext` et `unregisterTool` disparaissent, `modelContext` passe sur `document`, le mécanisme de consentement est retiré pour l’instant. Le 11 juin, l’équipe WebKit d’Apple s’oppose formellement à la proposition.
- **Mai–juin 2026, De Google I/O à la phase d’essai.** À Google I/O, le 19 mai, Chrome annonce une phase d’essai, un panneau WebMCP dans les DevTools et une catégorie « navigation agentique » dans Lighthouse. L’essai ouvre le 9 juin, de Chrome 149 à 156.
- **Août 2026, Les sites et les agents arrivent.** Les boutiques Shopify déclarent des outils à partir du 5 août, le jour où Mozilla passe sa position à « neutre ». Le 25 août, le navigateur de ChatGPT sur ordinateur commence à les appeler. Le WebMCP Challenge de Google réunit environ 5 000 participations.
- **Sept. 2026, Sans interface et sans date de sortie.** `consequentialHint` arrive et les agents sans interface entrent dans le périmètre. Le checkout de Shopify suit le 28 septembre. Le 29, Chrome demande à prolonger son essai jusqu’à la version 162 et espère livrer dans cette fenêtre. Le 1er octobre, la charte d’un nouvel Agentic Web Working Group entre en relecture.
## Qui est pour, qui est contre, et pourquoi.
WebMCP est un brouillon de Community Group, pas un standard du W3C. Un standard suppose plusieurs moteurs, et aujourd’hui seul Chromium l’implémente. Au sein même du W3C, les groupes accessibilité et vie privée sont critiques.
- **Google Chrome** (Implémente) : Deux des trois éditeurs. Essai développeurs dès Chrome 146, phase d’essai de 149 à 156, prolongation jusqu’à 162 demandée, pas encore d’intention de livrer.
- **Microsoft Edge** (Implémente) : Un éditeur et le premier prototype. Edge participe aussi à la phase d’essai.
- **OpenAI** (Appelle les outils) : Le navigateur de ChatGPT sur ordinateur appelle les outils WebMCP depuis le 25 août 2026 : outils JavaScript, sur la page principale seulement.
- **Mozilla Firefox** (Neutre) : Un prototype derrière un réglage désactivé par défaut. De l’intérêt pour l’API JavaScript, des réserves sur un nom qui promet MCP.
- **Apple Safari** (Opposé) : Veut combler les manques dans HTML et ARIA, et a prévenu qu’il ferait une objection formelle si WebMCP passait tel quel en Working Group.
- **Groupe accessibilité du W3C** (Pas en l’état) : Ne soutient pas la spécification dans sa forme actuelle, et voit dans `toolautosubmit` une porte ouverte à des interfaces trompeuses, proches du détournement de clic.
### Les arguments de Safari méritent d’être entendus
WebKit estime que le sens qui manque doit aller dans HTML et ARIA, là où les personnes, les technologies d’assistance et les agents en profitent tous à la fois. Un schéma typé, dit-il, contraint la forme d’un argument, pas son sens ; et permettre aux sites de repérer les agents ouvre la porte à la vieille erreur qui consiste à traiter certains utilisateurs à part.
La meilleure réponse à ce jour : la sémantique d’accessibilité dit ce qu’un contrôle **est**, pas ce qu’il **fait**. Deux formulaires identiques peuvent acheter une plante ou déposer une déclaration d’impôts. Yoav Weiss, chez Shopify, qui déploie des outils sur un grand nombre de boutiques, a déclaré lors de la revue d’architecture du W3C ne voir aucune alternative déclarative réaliste aux outils impératifs.
> “Un schéma typé contraint la forme d’un argument, pas le sens que l’agent doit en déduire : la fragilité passe simplement du DOM aux descriptions des outils.”
>
> — WebKit, Position de standardisation, juin 2026. [WebKit standards positions #670](https://github.com/WebKit/standards-positions/issues/670)
### Quatre objections, et les meilleures réponses
| Objection | Meilleure réponse | Ce qui reste vrai |
| --- | --- | --- |
| « Publiez donc une API. » | WebMCP agit dans la session que la personne a sous les yeux, sans jeton à créer, et convient aux applications dont la logique vit dans le navigateur. | Pour l’automatisation en arrière-plan, une API ou un serveur MCP reste le meilleur outil. |
| « Les sites ne l’adopteront pas. » | L’adoption apparaît là où les intérêts s’alignent : paiement, documentation, logiciels. | Les sites financés par la publicité ont peu de raisons de laisser un agent sauter leurs pages. |
| « Les outils divergeront de l’interface. » | Faire des outils de simples enveloppes autour des fonctions que l’interface appelle déjà. | Les descriptions peuvent encore diverger, et échouer en silence. |
| « C’est une prise de pouvoir de Google. » | Microsoft coédite la spécification et OpenAI la prend en charge. | Sans Safari, cela reste pour l’instant une fonction de Chromium. |
### Détecter l’agent : qualité ou défaut ?
Des événements comme `toolactivated` ou `SubmitEvent.agentInvoked` signalent à la page qu’un agent agit. Les développeurs apprécient : la page peut afficher une progression ou s’adapter. C’est exactement ce que craint WebKit : un site qui reconnaît les agents peut les bloquer, ou leur donner des pouvoirs que les personnes n’ont pas.
## Ce qui peut mal tourner.
WebMCP rend le travail d’un agent explicite, ce qui réduit ce qu’il doit toucher. Il ne rend pas les agents sûrs. La spécification le dit elle-même : rien ne garantit que l’intention déclarée d’un outil corresponde à son comportement réel.
1. **Les mots deviennent une surface d’attaque.** Noms, descriptions et résultats atterrissent tous dans le contexte du modèle. Une page malveillante peut y cacher des instructions, et une page honnête peut les relayer en renvoyant des avis ou des messages de forum. Marquez ces résultats avec `untrustedContentHint` et dites-le aussi en toutes lettres, comme le fait le site de documentation d’OpenAI.
2. **Le premier script à déclarer gagne.** Un nom d’outil est unique par page : un script d’analyse ou de publicité compromis qui déclare `checkout` en premier en prend le contrôle. Dans une étude de laboratoire de 2026 ([arXiv 2606.06387](https://arxiv.org/abs/2606.06387)), cette course a détourné GPT-5.4, Claude Opus 4.6 et Gemini 2.5 Flash à chaque essai.
3. **Des capacités blanchies en langage naturel.** Earlence Fernandes (UC San Diego) a glissé une instruction dormante dans la description d’un outil d’un site ; plus tard, sur un autre site, un mot déclencheur a poussé l’agent à appeler l’outil de ce second site. L’isolation entre origines ne vaut que ce que vaut la défense de l’agent contre l’injection de prompt.
4. **Votre bouton « Approuver » n’est pas un garde-fou.** Les outils agissent avec les cookies de l’utilisateur, et un agent qui appelle des outils sait souvent aussi cliquer. Le 2 septembre 2026, un développeur a vu le navigateur de ChatGPT appeler un outil qui ne faisait que proposer, puis cliquer sur le bouton « Approuver » de la page ; la page a enregistré « approuvé par vous » ([ticket #288](https://github.com/webmachinelearning/webmcp/issues/288)). La règle de Shopify : l’agent montre la commande et le total, demande à l’acheteur, et redemande si le total change.
5. **Les outils disparaissent en plein vol.** Les résultats meurent avec le document. Si un appel fait changer de page, la réponse peut ne jamais arriver (Shopify note qu’`executeTool()` renvoie alors null), et les agents ne retrouvent pas toujours les outils redéclarés après le trajet.
6. **Personne ne voit encore le trafic des agents.** Les sites peuvent compter les appels, pas savoir s’ils ont servi ce que voulait l’utilisateur. Yoav Weiss (Shopify) a ouvert un ticket sur la mesure en conditions réelles ; un des premiers sites marchands équipés dit ne pas encore pouvoir observer de vrai trafic d’agents.
### Où se trouvent vraiment les défenses
Surtout dans l’agent et le navigateur. Sarah Drasner (Chrome) décrit plusieurs couches : des classifieurs d’injection de prompt et un second modèle qui critique les actions de l’agent, des limites sur les sites qu’une tâche peut toucher, et une identité propre à l’agent avec son propre plafond de dépenses. Johann Hofmann (Google) a écrit que les agents doivent se protéger eux-mêmes, et que l’API ne peut pas les porter jusqu’au bout.
Même ses concepteurs divergent sur l’essentiel. Alex Nahas soutient qu’un agent n’a besoin d’aucune identité propre, seulement d’une partie de celle de l’utilisateur. Sarah Drasner en veut une distincte, qui ne pourrait par exemple dépenser que 20 dollars par semaine.
> “Une attaque catastrophique par injection de prompt va forcément finir par arriver.”
>
> — Alex Nahas, Créateur de MCP-B. [Coffee with Developers, février 2026](https://www.youtube.com/watch?v=YVWgoXWSvmk)
## 25 outils en production, sur ce site.
Contenttosocial transforme des contenus en posts à votre image pour Instagram, LinkedIn, Facebook, Pinterest et X. Les clients payants le pilotent depuis Claude ou ChatGPT via notre serveur MCP. En septembre 2026, nous avons ajouté WebMCP à la partie gratuite et publique du site, sans compte ni clé d’API, pour que l’agent de n’importe quel visiteur s’en serve sous ses yeux.
### Six types de pages, un même modèle
- **Page d’accueil** (14 sept.) : Répondre sur le produit et ses prix, afficher une section, ouvrir l’inscription pré-remplie. L’agent ne crée jamais le compte. Tools: `get_product_overview`, `get_pricing`, `show_landing_section`, `open_signup`.
- **Éditeur de templates** (22 sept.) : Créer ou remplir un visuel, le rendre, télécharger en PNG, JPEG, SVG, PDF ou ZIP, ou partager un lien. Le tout dans le navigateur du visiteur. Tools: `list_templates`, `load_template`, `get_template`, `get_template_schema`, `create_template`, `update_template`, `set_template_values`, `render_template`, `export_template`, `export_render`, `create_share_link`.
- **Classement des agences SEO** (25 sept.) : Trouver et comparer des agences SEO par ville, spécialité, secteur et taille, à partir des seules données publiées. Tools: `find_seo_agencies`, `get_seo_agency`, `compare_seo_agencies`, `get_city_seo_prices`, `list_seo_agency_awards`.
- **Pages templates** (29 sept.) : Parcourir le catalogue par réseau et lire les champs de n’importe quel template. Tools: `list_templates`, `get_template`, `show_templates`.
- **La page d’un template** (30 sept.) : Remplir un template pendant que le visiteur suit l’aperçu en direct et corrige les champs à la main. Tools: `get_template`, `set_template_values`, `render_template`, `export_render`, `create_share_link`.
- **Ce guide** (1er oct.) : Permettre à un agent de lire ce guide chapitre par chapitre, depuis la page elle-même. Tools: `list_guide_chapters`, `read_guide_chapter`, `show_guide_chapter`, `list_guide_sources`.
- **Un produit que les agents utilisent sans inscription.** Un visiteur demande à son agent un post Instagram. L’agent trouve un template, le remplit, le rend et remet le fichier. La partie gratuite du produit devient quelque chose que les agents peuvent utiliser, pas seulement lire.
- **Aucune facture de rendu.** Modifications, rendu et exports tournent dans le navigateur du visiteur. Seuls des fichiers statiques et des polices passent par nos serveurs ; aucun service de rendu payant à facturer.
- **Un seul chemin de code.** Chaque outil appelle les mêmes fonctions que les boutons. Il n’y a pas de second produit à maintenir pour les agents.
### Le plus dur : une personne et un agent sur le même visuel
La spécification ne dit rien de deux rédacteurs simultanés. Dans notre éditeur, le visiteur et son agent modifient le même fichier en même temps. Nous avons repris aux bases de données la **concurrence optimiste** : la session tient un numéro de version que chaque modification incrémente, et chaque écriture de l’agent doit citer la version qu’il a lue (`expected_version`).
Une écriture périmée échoue avec `VERSION_CONFLICT` et l’agent relit ; deux appels de l’agent qui se chevauchent reçoivent `BUSY`. Toute modification invalide le dernier rendu : un téléchargement ne montre jamais un visuel que la personne a modifié depuis.
```json
→ set_template_values
{ "expected_version": 7, "values": { "title": "Spring sale" } }
← {
"ok": false,
"error": {
"code": "VERSION_CONFLICT",
"message": "The design changed. Call get_template, then retry with its version."
}
}
```
### Dix choses que nous avons apprises
1. **Un schéma, deux usages.** Les mêmes schémas zod valident chaque appel et génèrent les manifestes statiques de l’éditeur de templates et du classement ([/templates/webmcp.json](https://contenttosocial.com/templates/webmcp.json), [/agencies/webmcp.json](https://contenttosocial.com/agencies/webmcp.json)). Ces manifestes ne peuvent pas diverger du code, et les agents qui n’exécutent pas WebMCP savent quand même ce qui est possible : l’étape de découverte que la spécification laisse de côté.
2. **S’arrêter une étape avant la décision.** `open_signup` remplit le formulaire et l’ouvre, puis répond « The account has not been created. » Les outils `show_*` déplacent la vue du visiteur au lieu d’agir à sa place.
3. **Les erreurs font partie de l’interface.** Chaque échec renvoie `{ ok: false, error: { code, message, issues } }` avec un code stable (`INVALID_INPUT`, `VERSION_CONFLICT`, `BUSY`, `CANCELLED`, `IMAGE_UNREADABLE`) et les champs exacts en cause, pour que le modèle se corrige seul.
4. **Zéro octet pour les autres.** Le code des outils ne se charge que si `document.modelContext` existe. Les autres navigateurs ne téléchargent rien : les pages restent aussi rapides qu’avant.
5. **Chaque outil a son interrupteur.** Chaque déclaration reçoit un `AbortSignal`. Quitter la page l’annule, et les requêtes encore en cours sont annulées avec lui.
6. **S’attendre à ce que le navigateur bouge.** Les premières versions de Chrome appelaient les outils sans contexte d’exécution : nous retombons alors sur le signal de la page. Chrome 153 passe les arguments d’`executeTool` en texte JSON, les objets étant prévus pour la 155. Nous codons selon la spécification et testons contre le navigateur.
7. **Tester la vraie API, sans modèle.** Nos tests de bout en bout lancent Chrome avec `--enable-blink-features=WebMCP` et appellent les vrais outils : découverte, entrées invalides, annulation, et les octets et dimensions réels de chaque PNG, PDF et ZIP exporté.
8. **Le contenu est une donnée.** Textes des templates, données des agences et chapitres de ce guide reviennent comme des données, jamais comme des instructions. Les images passent par le même décodeur borné que les envois, et les images distantes sont refusées proprement quand leur site en interdit la lecture.
9. **Garder une porte sans WebMCP.** Un agent qui se contente de lire le web peut quand même construire le lien d’un template rempli (`#v=1&template=…&values=…`). Le visuel voyage dans le fragment de l’URL, qui n’atteint jamais notre serveur, jusqu’à 64 Kio.
10. **Respecter les budgets.** Chrome recommande au plus 500 caractères par description et 30 par nom. Notre plus longue description fait 389 caractères : ce que fait l’outil d’abord, ses limites ensuite.
### Toute l’intégration tient là
Chaque page reprend la même dizaine de lignes : détecter, ne charger les outils que si nécessaire, les lier à la vie de la page.
```tsx
useEffect(() => {
const context = document.modelContext;
if (!window.isSecureContext || !context?.registerTool) return;
const controller = new AbortController();
// Tool code is downloaded only by browsers that can use it.
void import("@/lib/agencies/webmcp").then(({ registerAgencyTools }) =>
registerAgencyTools(context, locale, controller.signal),
);
// Leaving the page unregisters every tool.
return () => controller.abort();
}, [locale]);
```
### Ce que nous ne savons pas encore
Combien d’agents appellent nos outils, et si cela se transforme en inscriptions. Comme tous les premiers à l’adopter, nous ne savons pas encore isoler le trafic des agents. Le seul agent grand public qui embarque WebMCP aujourd’hui est le navigateur de ChatGPT sur ordinateur ; les conversations classiques de ChatGPT et de Claude ne l’exécutent pas, et les clients payants y retrouvent les mêmes fonctions via notre serveur MCP.
Essayez avec votre agent : [Templates gratuits](https://contenttosocial.com/fr/templates), [Créateur de templates](https://contenttosocial.com/fr/tools/template-editor), [Classement des agences SEO](https://contenttosocial.com/fr/agences-seo).
## Douze règles qui tiennent.
Tirées des recommandations de Chrome, des équipes qui livrent WebMCP et de nos propres erreurs.
1. **Penser en tâches, pas en éléments.** Un outil par tâche qu’un utilisateur vient accomplir, pas un par bouton. Nommer ce qu’il fait : `create_event` exécute, `start_event_creation` ouvre le formulaire.
2. **Garder la liste courte.** Des dizaines d’outils dégradent les agents et peuvent pousser les navigateurs à en écarter. Ne déclarer sur chaque page que ce que cette page sait faire.
3. **Respecter les budgets.** Les limites de Chrome : 30 caractères par nom, 500 par description, 150 par description de paramètre, environ 1 500 par résultat. Mettre la réserve importante en premier : ce qui dépasse est coupé sans prévenir.
4. **Accepter l’entrée brute.** Prendre « de 11 h à 15 h » tel que l’utilisateur l’a dit ; ne pas demander au modèle des minutes depuis minuit. Des valeurs d’énumération lisibles : « express », pas 1.
5. **Valider dans le code, souplement dans le schéma.** Rien ne garantit que les contraintes du schéma soient appliquées. Vérifier dans `execute` et renvoyer des erreurs qui disent comment corriger l’appel.
6. **Montrer ce qui s’est passé.** Mettre l’interface visible à jour à chaque appel : la personne partage l’onglet avec l’agent.
7. **Signaler ce que vous ne contrôlez pas.** `untrustedContentHint` sur les résultats qui contiennent du contenu d’utilisateurs, et le même avertissement dans la description.
8. **Laisser la décision à l’humain.** `consequentialHint` pour les paiements, envois et suppressions, une étape de confirmation dans le parcours, et les prix et stocks revérifiés à l’exécution.
9. **Survivre aux changements de page.** Faire le travail dans la page et renvoyer des données, faire de la navigation un outil à part, et déclarer les mêmes noms sur chaque page.
10. **Détecter, charger tard, nettoyer.** Tester `document.modelContext` (anciennes versions de Chrome : `navigator.modelContext`), ne charger le code des outils qu’à ce moment, et passer un `AbortSignal`.
11. **Surveiller vos scripts tiers.** Déclarer tôt les outils critiques, et auditer les balises qui partagent votre page.
12. **Tester comme un agent.** L’extension Model Context Tool Inspector de Chrome, le panneau WebMCP des DevTools, l’audit « navigation agentique » de Lighthouse, et un test navigateur qui appelle les vrais outils.
## Questions fréquentes
### WebMCP, c’est quoi, en une phrase ?
Une API du navigateur qui permet à une page web de déclarer des outils (des fonctions nommées, avec une description et un schéma d’entrée) que les agents IA du navigateur peuvent appeler au lieu de cliquer dans l’interface.
### WebMCP, est-ce la même chose que MCP ?
Non. WebMCP reprend l’idée d’outil de MCP, mais sans JSON-RPC, sans transport et sans serveur : les outils tournent dans le JavaScript de la page, dans la session de l’utilisateur. MCP est gouverné par l’Agentic AI Foundation de la Linux Foundation ; WebMCP est rédigé au W3C.
### Quels navigateurs prennent en charge WebMCP ?
Seulement ceux basés sur Chromium, pour l’instant. Chrome propose un essai développeurs depuis la version 146 et une phase d’essai depuis la 149 ; Edge participe aussi à cette phase d’essai. Mozilla est neutre et l’équipe WebKit d’Apple s’oppose à la proposition : ne l’attendez pas de sitôt dans Firefox ou Safari.
### Comment activer WebMCP dans Chrome ?
Pour tester, ouvrez `chrome://flags`, activez « WebMCP for testing » (Chrome 146 ou plus récent) et relancez ; l’extension Model Context Tool Inspector de Chrome liste et appelle alors les outils d’une page. Pour vos visiteurs, inscrivez votre site à la phase d’essai de Chrome (Chrome 149 à 156) et envoyez son jeton dans un en-tête `Origin-Trial`.
### Qui a créé WebMCP ?
Des ingénieurs de Google et de Microsoft, au sein du Web Machine Learning Community Group du W3C. Les éditeurs sont Khushal Sagar et Dominic Farolino (Google) et Brandon Walderman (Microsoft). WebMCP réunit « Web Model Context » de Microsoft Edge et « Script Tools » de Chrome, avec MCP-B d’Alex Nahas et le projet de Jason McGhee comme travaux antérieurs.
### Quels agents IA peuvent appeler des outils WebMCP aujourd’hui ?
Un seul agent grand public : le navigateur intégré de ChatGPT sur ordinateur (dans ChatGPT Work et Codex), depuis le 25 août 2026, pour les outils JavaScript de la page principale. Gemini dans Chrome a été annoncé à Google I/O mais n’est pas sorti ; Claude dans Chrome et Copilot dans Edge ne montrent aucun support public. Les extensions peuvent appeler des outils via des scripts de contenu, et les développeurs à la main avec l’inspecteur de Chrome. Les applications de conversation classiques n’exécutent pas WebMCP.
### Faut-il un serveur, une clé d’API ou OAuth ?
Non. Les outils tournent dans la page avec la session que la personne a déjà. C’est tout l’intérêt, et c’est aussi pourquoi WebMCP ne convient pas aux agents qui tournent sans navigateur : donnez-leur une API ou un serveur MCP.
### WebMCP est-il sûr ?
Il réduit ce qu’un agent doit toucher, mais l’injection de prompt, les outils trompeurs et le détournement par des scripts tiers sont des risques réels, laissés en grande partie aux agents et aux navigateurs. Traitez les résultats comme des données, gardez les étapes engageantes pour la personne, et auditez les scripts de vos pages.
### WebMCP aide-t-il le SEO ?
Aucun effet sur le classement n’a été annoncé. Les agents ne découvrent les outils qu’une fois la page chargée : être trouvé reste une affaire de recherche, où les liens comptent toujours (voir notre guide des [backlinks et liens nofollow](https://contenttosocial.com/fr/guides/backlinks)). Ce que WebMCP change, c’est ce qui se passe après le clic : un agent peut-il aller au bout de la tâche sur votre site ?
### Faut-il utiliser l’API impérative ou déclarative ?
Commencez par l’impérative : c’est celle qu’utilisent les agents (environ 172 millions de déclarations contre 20 000 pour les formulaires pendant l’essai de Chrome) et la seule que ChatGPT prend en charge. Les attributs déclaratifs sont un gain rapide pour des formulaires simples, où la personne doit valider elle-même.
### Peut-on essayer WebMCP sur cette page ?
Oui. Dans un navigateur compatible, ce guide déclare quatre outils : lister, lire et afficher un chapitre, et lister les sources. La ligne sous le titre vous dit si votre navigateur les expose.
## D’où vient ce guide
Les citations sont traduites de l’anglais, depuis les enregistrements et documents ci-dessous, et abrégées. Chaque chiffre nomme qui l’a mesuré ; les chiffres d’éditeurs sont signalés comme tels.
- [WebMCP, Community Group draft](https://webmachinelearning.github.io/webmcp/) — W3C Web Machine Learning CG, 2026-09-30
- [Specification repository, issues and history](https://github.com/webmachinelearning/webmcp) — GitHub, 2025–2026
- [WebMCP documentation](https://developer.chrome.com/docs/ai/webmcp) — Chrome for Developers, 2026
- [Secure WebMCP tools](https://developer.chrome.com/docs/ai/webmcp/secure-tools) — Chrome for Developers, 2026-09-01
- [Standards position on WebMCP (oppose)](https://github.com/WebKit/standards-positions/issues/670) — WebKit, 2026-06
- [Standards position on WebMCP (neutral)](https://github.com/mozilla/standards-positions/issues/1412) — Mozilla, 2026
- [Design review of WebMCP](https://github.com/w3ctag/design-reviews/issues/1238) — W3C TAG, 2026
- [Accessibility review (APA WG)](https://github.com/webmachinelearning/webmcp/issues/65) — W3C, issue #65, 2026-08-27
- [Privacy review](https://github.com/webmachinelearning/webmcp/issues/313) — W3C Privacy WG, issue #313, 2026-09-21
- [An agent can complete the page’s own approval step](https://github.com/webmachinelearning/webmcp/issues/288) — WebMCP issue #288, 2026-09-03
- [Web Model Context explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebModelContext/explainer.md) — Microsoft Edge, 2025-07-16
- [Site tools (WebMCP) in ChatGPT](https://learn.chatgpt.com/docs/webmcp) — OpenAI, 2026-08
- [Checkout WebMCP](https://shopify.dev/docs/agents/carts-and-checkout/checkout-webmcp) — Shopify, 2026-09
- [document.modelContext usage](https://webstatus.dev/features/document-modelcontext) — webstatus.dev, 2026-10-01
- [Syntax #1037: WebMCP is here (and you should care)](https://syntax.fm/1037) — Syntax, with Sarah Drasner and Dominic Farolino, 2026-09-09
- [Syntax #979: WebMCP, a new standard to expose your apps to AI](https://syntax.fm/979) — Syntax, 2026-02-16
- [Why every developer needs to know about WebMCP now](https://tessl.io/podcast/99) — AI Native Dev #99, with Maximiliano Firtman, 2026-03-31
- [From Hacker News to W3C](https://www.youtube.com/watch?v=yG2kpa0-iFk) — alphalist.CTO #138, with Alex Nahas, 2026-05-21
- [WebMCP: agents on the web and in the browser](https://www.youtube.com/watch?v=6Po39iD6Pfs) — Arcade MCP MVP, with Alex Nahas, 2026-02-11
- [The why and how of WebMCP](https://www.youtube.com/watch?v=YVWgoXWSvmk) — Coffee with Developers, with Alex Nahas, 2026-02-27
- [ShopTalk Show #729 (WebKit’s position, read on air)](https://www.youtube.com/watch?v=A8KcOZ5AVFM) — ShopTalk Show, 2026-08-24
- [Don’t let AI agents push your buttons: use WebMCP instead](https://www.youtube.com/watch?v=p1l8nkQAoUw) — Khushal Sagar, Web AI Summit, 2025-11
- [WebMCP and the agentic web](https://www.youtube.com/watch?v=M1cME470ugM) — BlinkOn 21, with Dominic Farolino, 2026-04
- [WebMCP explained](https://www.youtube.com/watch?v=GbfZSjJBQQ0) — Andrew Nolan, W3C Advisory Committee, 2026
- [Build your website for the agentic era](https://www.youtube.com/watch?v=HdCc-KezQPk) — Kasper Kulikowski, Google I/O 2026, 2026-05
- [WebMCP: stop scraping the web, start calling it](https://www.youtube.com/watch?v=3NDly38DWIE) — Patrick Brosset, dotAI 2026, 2026-09
- [Build agent-ready sites with WebMCP](https://www.youtube.com/watch?v=Is2NHa7awWY) — OpenAI, 2026-08
- [WindTunnel benchmark](https://webmcp.com/benchmark) — nekuda (vendor), 2026-09-18
- [Beyond Browsing: API-based web agents](https://arxiv.org/abs/2410.16464) — Carnegie Mellon, ACL Findings 2025, 2025
- [MCPWorld: tools against screen agents](https://arxiv.org/abs/2506.07672) — arXiv 2506.07672, 2025-06
- [Tool injection attacks on WebMCP agents](https://arxiv.org/abs/2606.06387) — arXiv 2606.06387, 2026-06
- [WebMCP and the same-origin policy](https://www.earlence.com/blog.html#/post/webmcp-sameorigin) — Earlence Fernandes, UC San Diego, 2026-04-30
- [webMCP: Web Machine Context & Procedure (a different proposal)](https://arxiv.org/abs/2508.09171) — arXiv 2508.09171, 2025-08