Alex Nahas a intégré MCP dans un navigateur chez Amazon. Aujourd’hui, Microsoft et Google en font un standard W3C.

Cet article est adapté de l’interview d’Alex dans notre série vidéo MCP MVP*.

L’épisode 1 met en vedette Alex Nahas, créateur de MCP-B et l’une des chevilles ouvrières de la spécification WebMCP.

Des réactions sur WebMCP ? Partagez-les dans les commentaires de la vidéo ci-dessus ↑*

Imaginez votre site dire à l’agent ChatGPT d’un visiteur : “Voici ce que je sais faire. Voici comment me le demander.”

Jusqu’au 10 février 2026, un agent IA ne disposait que de deux façons d’interagir avec un site web :

  • VisuellementL’agent analyse des captures d’écran, lit le texte et déduit où déplacer le curseur à l’écran.
  • SémantiquementL’agent analyse des volumes de XML brut (DOM, arbre d’accessibilité) pour extraire des données et déclencher des événements sur les éléments.

Ces deux approches peuvent s’exécuter au niveau du navigateur ou de façon systémiquekel, l’agent contrôlant le système informatique et synthétisant les entrées. Elles nécessitent des allers-retours supplémentaires, de l’inférence et des modèles multimodaux, ce qui pénalise les performances, le coût et la fiabilité, en gaspillant tokens et temps pendant que les agents tâtonnent.

WebMCP vise à offrir une troisième option, efficace et fiable. Les sites peuvent exposer des outils structurés sous forme de fonctions JavaScript avec descriptions et schémas, que les agents peuvent appeler directement. Le standard est en cours d’incubation au sein du W3C Web Machine Learning Community Group et vient de débarquer sur Chrome.

Vous développez des sites web ? WebMCP mérite votre attention. Il pourrait changer ce que “construire un site” signifie.

L’origine Amazon

Alex Nahas était ingénieur backend chez Amazon quand MCP a émergé début 2025. Amazon, avec ses milliers de services internes, avait monté ce qui ressemblait à un immense serveur MCP unique, offrant des milliers d’outils entassés dans une seule fenêtre de contexte.

“Il fallait les désactiver avec des commandes de processus dans la chaîne de connexion”, explique Alex. C’était, pour le dire gentiment, le chaos.

Le vrai problème, c’était l’autorisation. La spec MCP avait adopté OAuth 2.1, que pratiquement personne chez Amazon n’avait implémenté en interne. Chaque service avait sa propre gestion de l’authentification, et aucun ne parlait OAuth 2.1.

Chez Amazon, toutes les autorisations passent par une expérience navigateur fédérée qui connecte les employés à l’ensemble des services, tableaux de bord et ressources disponibles. Alex a eu l’idée de faire tourner MCP dans le navigateur pour tirer parti du SSO, des cookies de session et des fournisseurs d’identité existants.

C’est ce qu’est MCP-B (le “B” est pour “browser”). Alex a intégré le SDK TypeScript MCP dans une application JavaScript côté client et a construit un transport personnalisé via postMessage pour communiquer avec une extension Chrome. Et ça a si bien fonctionné que le projet ne pouvait pas rester confiné chez Amazon.

Du projet perso au standard W3C

Les équipes Chrome de Google et Edge de Microsoft travaillaient chacune sur des idées parallèles. Chrome prototypait des “script tools”, et Edge tournait autour de la même question : comment permettre aux agents d’interagir avec des applications web de manière structurée ?

Quand MCP-B est arrivé, ils ont collaboré avec Alex via le W3C et ont appelé ça WebMCP.

Mais le nom peut induire en erreur : WebMCP n’est pas MCP. Il ne suit pas la spec JSON-RPC. Alex a poussé tôt pour porter le protocole MCP complet dans le navigateur, mais le groupe de travail ne voulait pas un couplage trop serré à la spec. WebMCP partage la surface d’API et le modèle conceptuel de MCP : des outils avec des schémas que les agents peuvent appeler.

Il est conçu spécifiquement pour le navigateur. Il tourne entièrement côté client, sans la dynamique client-serveur du MCP d’Anthropic, où des fournisseurs hébergent des serveurs MCP que des clients MCP viennent consommer. Ici, la page web est le “serveur” qui démarre quand un agent y atterrit. Les mêmes fonctions utilisées pour soumettre des formulaires ou interroger des bases de données dans des composants React peuvent désormais être exposées directement aux agents, sans qu’ils aient besoin de simuler des clics et des saisies.

Si vous pensez à “Java et JavaScript” en ce moment, vous n’êtes pas seul. Le nommage va créer de la confusion : WebMCP n’a pour l’instant aucun plan pour implémenter les prompts ou les resources, seulement la partie “tools” du standard MCP. Heureusement, Alex a créé un polyfill qui implémente l’API WebMCP et la convertit en JSON-RPC, ce qui vous donne un SDK MCP conforme à la spec qui tourne dans votre navigateur.

La triade létale

Les agents qui accèdent au web font face à un problème de sécurité non résolu : la triade létale.

Imaginez : vous avez deux onglets ouverts. L’onglet A, c’est votre banque. L’onglet B, un site malveillant. Un agent navigateur se trouve au milieu, avec le contexte des deux. Cet agent traite les deux sources de contexte comme équivalentes.

L’onglet malveillant pourrait demander à l’agent d’extraire des numéros de compte depuis l’onglet bancaire. Ou pousser des instructions dans l’autre sens pour lui faire virer des fonds. Ce n’est pas théorique ; c’est architecturalement inévitable avec le fonctionnement actuel des agents navigateurs. Comme Alex le formule : “Si vous allez utiliser Comet, si vous allez utiliser Atlas, il faut juste accepter que c’est un risque que vous prenez.”

WebMCP n’élimine pas ce problème, mais réduit significativement la surface d’attaque. Au lieu que l’agent opère sur des captures d’écran et le DOM brut, où il peut voir tout, y compris les éléments cachés, il opère sur des appels d’outils explicites. Des actions discrètes. Ce que le site a spécifiquement choisi d’exposer. Vous pouvez hacher les outils, mettre en place des flux d’élicitation pour les premières connexions, et limiter la confiance à des domaines spécifiques avec un TTL.

Est-ce hermétique ? Non. L’injection de prompts existe partout où vous avez des outils tiers dynamiques. Mais passer de “le modèle peut voir et faire tout ce qu’un utilisateur peut, plus lire le DOM” à “le modèle peut appeler ces fonctions précises” représente un rétrécissement significatif du périmètre, qui pourrait changer la façon dont les navigateurs sont construits à l’avenir.

Trois patterns d’outils WebMCP

Alex a construit plusieurs sites avec WebMCP, et il a constaté que les outils WebMCP se répartissent en catégories :

Les outils en lecture seuledoivent être exposés sous forme de liste plate, toujours disponible dans le contexte de l’agent. Ce sont vos opérations GET : récupérer des données, lire un état. Inutile que l’agent navigue dans votre interface juste pour lire des informations. Exposez tout ; laissez l’agent interroger ce dont il a besoin.

Les outils de navigation. sont le system prompt de votre site. Ils indiquent à l’agent ce que fait votre site et où se trouve l’information. “Voici les liens. D’autres outils seront révélés au fil de la navigation.” C’est le plan de masse. Vous les marquez comme destructifs parce qu’ils provoquent des changements visibles (la page navigue réellement), et un agent qui respecte les indications destructives signalera cela à l’utilisateur.

Les outils d’écriturepassent à l’action. Ils remplissent des formulaires, soumettent des données, effectuent des modifications. C’est là que l’élicitation MCP brille : l’agent peut remplir un formulaire, puis le soumettre à l’utilisateur (“Voici ce que je vais envoyer. Oui ou non ?”). L’humain reste dans la boucle.

Avec ces trois primitives, défend Alex, même un vieux site WordPress devient “une entreprise IA à part entière”. Tout peut être en JavaScript vanilla, sans framework.

Pourquoi le web ne va nulle part

Alex ne croit pas que MCP et les agents vont remplacer le web.

Regardons les cas d’usage : de nombreuses applications offrent bien plus que du texte. Les canevas (Figma) et les tableaux de bord complexes (Quickbooks, Shopify) nécessitent une interface visuelle où l’humain est l’acteur principal et où l’agent intervient en soutien. D’autres applications font des recherches de données et des transactions simples, mieux servies en ramenant l’application vers l’agent. WebMCP sert le premier camp : l’agent vient au site, pas l’inverse.

Quelle que soit la façon dont les gens naviguent sur le web à l’avenir, HTML, CSS et JavaScript resteront les briques fondamentales d’applications universellement compatibles que toutes les plateformes peuvent restituer. Le modèle d’interaction pourra passer du navigateur aux agents pour de nombreux utilisateurs et cas d’usage, mais le substrat sous-jacent ne disparaîtra pas.

WebMCP est une amélioration progressive du Web qui permet aux sites de servir aussi bien les humains que les agents. Les sites web perdurent. Les agents ont besoin d’un meilleur moyen d’interagir avec eux. Un standard web est le bon vecteur pour ça.

On en est aux débuts

WebMCP en est à ses prémices. La spec passe de l’incubation communautaire à un brouillon formel. Chrome dispose d’une implémentation expérimentale derrière un flag dans Chromium. Alex s’attend à des annonces officielles des navigateurs d’ici mi-fin 2026.

Pour essayer dès maintenant :

Ce que ça change pour vous

Si vous développez des applications web, WebMCP mérite un coup d’œil : il vous permet de définir comment les agents interagissent avec votre site, plutôt que de laisser l’agent se débrouiller tout seul. C’est une amélioration progressive et proactive, à l’image de l’ajout de fonctionnalités d’accessibilité à votre site.

Pas besoin de tout réarchitecturer. L’idée centrale, c’est que vous encapsulez de la logique côté client existante. Votre fonction add-to-cart(), votre recherche, votre soumission de formulaire fonctionnent déjà. WebMCP les rend simplement découvrables et appelables par les agents.

Que cela devienne le standard ou une étape vers autre chose, la direction est claire : les propriétaires de sites qui veulent attirer des utilisateurs passant par des agents comme Claude ou ChatGPT voudront une couche orientée agent pour offrir la meilleure expérience possible.

WebMCP est la tentative la plus sérieuse pour faire de tout ça une primitive de plateforme plutôt qu’une réflexion après coup.

MCP MVP est une série vidéo d’Arcade.dev qui met en lumière les builders qui façonnent l’écosystème agentique. Regardez la vidéo complète →

agenticweb.nearestnabors.com.

WebMCP apporte MCP au navigateur. Arcade est le runtime qui apporte MCP en production. Essayez gratuitement →