WebMCP : pourquoi rendre votre site "agent-ready" va changer les règles de la visibilité

Les agents IA sont partout. Ils répondent à des questions, comparent des offres, remplissent des formulaires, réservent des services. Et pour faire tout ça, ils doivent interagir avec des sites web qui n'ont pas été conçus pour eux.

C'est là que le problème commence.

Aujourd'hui, quand un agent IA visite une page, il fait avec les moyens du bord : il prend des screenshots, parse le DOM, devine où cliquer, attend que la page charge, recommence si ça échoue. C'est lent, fragile, et ça casse au moindre changement de layout.

WebMCP est une tentative de corriger ça à la source. Pas en rendant les agents plus intelligents, mais en donnant aux sites un moyen de se rendre explicitement lisibles pour eux.

Comprendre le problème : comment les agents naviguent aujourd'hui

Jusqu'au 10 février 2026, un agent IA n'avait que deux façons d'interagir avec un site web.

La première est visuelle : l'agent capture un screenshot de la page, l'envoie à un modèle de vision, et tente d'inférer où cliquer, quoi saisir, comment naviguer. C'est la méthode la plus répandue. C'est aussi la plus coûteuse en tokens, la plus lente, et la moins fiable.

La seconde est sémantique : l'agent parse le code HTML brut, explore l'arbre d'accessibilité, et tente d'identifier les éléments interactifs pour déclencher des événements. C'est plus précis que les screenshots, mais toujours indirect, toujours dépendant de la structure du DOM.

Les deux méthodes partagent le même défaut fondamental : l'agent doit interpréter ce que le site peut faire, plutôt que le site lui expliquer directement. Cette ambiguïté génère des erreurs, de la latence et des comportements non déterministes. Le même agent, sur la même page, peut réussir neuf fois et échouer la dixième parce qu'un élément a bougé de quelques pixels.

Pour des démos, c'est acceptable. Pour de la production, c'est un bloquant.

Ce qu'est WebMCP

WebMCP est une API JavaScript native du navigateur qui permet aux développeurs d'exposer les fonctionnalités de leur site sous forme d'"outils" directement appelables par des agents IA.

Concrètement : au lieu d'attendre qu'un agent devine comment réserver un vol sur votre site, vous lui dites explicitement "voici l'action book_flight, voici les paramètres qu'elle accepte, voici ce qu'elle retourne". L'agent n'a plus à interpréter l'interface, il appelle l'outil.

C'est co-développé par Google et Microsoft, sous l'égide du groupe Web Machine Learning du W3C. La spécification officielle a été publiée le 10 février 2026 comme draft Community Group Report. Chrome 146 est le premier navigateur à en proposer une preview.

La métaphore qui revient dans toutes les discussions sur le sujet est celle du responsive design : quand le mobile est arrivé, la plupart des équipes n'ont pas tout reconstruit. Elles ont ajouté des breakpoints, et le site était mobile-ready. WebMCP suit la même logique : annoter ses formulaires existants, enregistrer ses actions clés, et le site devient agent-ready sans refonte complète.

WebMCP vs MCP : ce n'est pas la même chose

La confusion est fréquente, et elle mérite d'être clarifiée.

MCP (Model Context Protocol), développé par Anthropic fin 2024, est un protocole client-serveur. Un agent se connecte à un serveur MCP distant qui expose des outils. La communication passe par le réseau, avec une architecture séparée de l'interface utilisateur.

WebMCP s'exécute entièrement dans le navigateur. Pas de serveur distinct, pas de communication réseau dédiée. Les outils sont définis dans le code JavaScript de la page elle-même, via l'API navigator.modelContext. Le navigateur fait le travail de traduction entre les outils déclarés et l'agent qui les appelle.

Comme le précise Patrick Brosset, ingénieur de l'équipe Microsoft Edge impliqué dans la spec, dans son article de clarification publié le 23 février 2026 :

WebMCP partage la surface API et le modèle conceptuel de MCP, mais ce n'est pas du MCP au sens strict

Le navigateur est l'intermédiaire entre la page et l'agent, pas un serveur externe.

Ce choix architectural a des conséquences pratiques importantes :

• Les outils partagent la session utilisateur existante dans le navigateur (authentification, cookies, état)
• Le traitement reste local, ce qui favorise la confidentialité
• Une seule codebase couvre l'interface humaine et l'intégration agent
• Mais cela nécessite un contexte de navigation actif, pas de mode "headless" pur à ce stade

Les deux approches d'implémentation

WebMCP propose deux façons de rendre un site agent-ready, complémentaires selon les cas d'usage.

L'API déclarative : partir de vos formulaires existants

C'est l'entrée la plus simple. Si vous avez déjà un formulaire de réservation, de contact ou de recherche, vous pouvez l'exposer à des agents IA en ajoutant quelques attributs HTML :

• toolname : l'identifiant de l'outil
• tooldescription : une description en langage naturel de ce que fait le formulaire
• toolparamdescription : la description de chaque champ
• toolautosubmit : si présent, l'agent peut soumettre le formulaire sans geste humain explicite

Sans toolautosubmit, le navigateur met l'action en pause et attend une confirmation de l'utilisateur. C'est une approche "permission-first" qui garde l'humain dans la boucle pour les actions sensibles.

Un bénéfice secondaire notable : WebMCP pousse à soigner les attributs label et aria-description de vos formulaires, car Chrome les utilise pour construire les descriptions de paramètres des outils. Les sites avec une bonne accessibilité de base ont déjà fait une grande partie du travail.

L'API impérative : enregistrer des outils en JavaScript

Pour les interactions plus complexes, les workflows dynamiques ou les retours de données structurées, l'API impérative permet d'enregistrer des outils directement via navigator .modelContext .registerTool().

Chaque outil est défini par un nom, une description en langage naturel, un schéma JSON qui décrit les paramètres attendus, et une fonction execute qui retourne un résultat structuré.

L'intérêt : remplacer 20 actions d'interface par un seul appel d'outil. Un agent qui cherche un produit n'a plus besoin de saisir du texte dans un champ, attendre le rendu, parser les résultats, filtrer par catégorie, parser à nouveau. Il appelle search_products avec les bons paramètres et reçoit du JSON propre.

Ce que ça change pour votre visibilité

C'est la question qui intéresse directement les équipes marketing et les responsables acquisition.

Jusqu'ici, la visibilité dans les IA s'est jouée sur deux niveaux. D'abord, la visibilité de citation : est-ce que votre contenu est repris dans les réponses de ChatGPT, Perplexity ou Gemini ? C'est ce que couvre le GEO et l'optimisation du contenu pour être cité par les IA. Ensuite, la visibilité de récupération : est-ce que vos pages font partie des sources que le modèle va consulter pour construire ses réponses ? C'est là qu'interviennent les mécanismes de RAG et de retrieval.

WebMCP ajoute un troisième niveau : la visibilité d'action. Est-ce que votre site est utilisable par un agent qui agit au nom d'un utilisateur ?

La distinction est importante. Être cité dans une réponse IA, c'est de la visibilité passive. Être le site sur lequel l'agent exécute l'action demandée par l'utilisateur, c'est de la visibilité active. Et dans un contexte où les agents commencent à gérer des achats, des réservations, des demandes de support, la question "est-ce qu'un agent peut accomplir une tâche sur votre site ?" va peser de plus en plus lourd.

Comme le souligne l'analyse de Thatware sur WebMCP et le LLM SEO : la question ne sera plus "est-ce qu'un bot peut lire votre page ?" mais "est-ce qu'un agent peut y exécuter une tâche ?". Cette distinction change le SEO en profondeur.

Les sites qui exposent des outils WebMCP bien définis offrent aux agents une interface fiable, rapide et prévisible. Les agents préfèrent les sources sur lesquelles ils peuvent agir sans risque d'erreur. C'est un signal de confiance qui va dans le même sens que les signaux E-E-A-T que Google valorise pour les réponses des AI Overviews.

Le lien avec les autres couches du web agentique

WebMCP ne fonctionne pas seul. Il s'inscrit dans un écosystème plus large qui est en train de se mettre en place.

Le RAG (Retrieval-Augmented Generation) est la couche qui permet aux LLM de récupérer de l'information externe au moment de la génération d'une réponse. C'est ce qui permet à Perplexity d'aller lire vos pages en temps réel pour construire ses réponses.

WebMCP intervient en aval : une fois que l'agent a identifié votre site comme la bonne destination, il a besoin d'un moyen fiable d'interagir avec lui. Le RAG l'aide à vous trouver. WebMCP lui permet d'agir une fois qu'il est là.

Il existe aussi un projet connexe, agenticweb.md, un standard de découverte machine-readable qui permettrait aux agents de découvrir les outils disponibles sur un site avant même de le visiter. C'est encore à l'état de proposition, mais ça complète la logique WebMCP en résolvant la question de la discoverability, qui est l'une des limites actuelles du standard.

Où en est la standardisation et quelles sont les limites actuelles

WebMCP est encore tôt. Il faut être clair là-dessus.

La spec publiée par le W3C Web Machine Learning Community Group est un draft Community Group Report, pas une recommandation W3C formelle. Elle évolue : entre la publication initiale de février 2026 et mars 2026, les méthodes provideContext et clearContext ont déjà été supprimées de l'API. Les équipes qui commencent à expérimenter maintenant doivent s'attendre à des ajustements.

Le support navigateur est pour l'instant limité à Chrome 146 Canary, derrière un flag. Un support Edge est attendu mais pas encore formalisé. Firefox et Safari n'ont pas annoncé de plans. Le support stable sur Chrome et Edge est anticipé pour la seconde moitié de 2026.

Parmi les limites techniques actuelles, identifiées dans la spec et les retours de terrain :

• Pas de discoverability native : un agent ne peut pas savoir quels outils un site propose sans y accéder au préalable
• Pas de synchronisation d'état intégrée : aucun mécanisme natif pour maintenir la cohérence entre l'état de l'UI et l'état de l'application
• La section sécurité de la spec est actuellement vide : des questions ouvertes restent sur l'exposition aux attaques CSRF, XSS, et les risques liés à l'association avec d'autres API émergentes comme la Prompt API

Sur la sécurité, Silicon.fr note dans son analyse du standard que les domaines d'attaque existants pourraient s'appliquer de façon spécifique à WebMCP, et que les questions sont pour l'instant bien plus nombreuses que les réponses. WebMCP délègue l'arbitrage des accès au navigateur, ce qui assure une rétrocompatibilité entre les versions, mais ne résout pas encore tous les risques liés à l'exécution d'actions par des agents au nom d'utilisateurs.

Ce qu'il faut retenir maintenant

WebMCP n'est pas un standard à implémenter en production aujourd'hui. Mais c'est un signal clair sur la direction que prend le web.

Le responsive design nous a appris qu'attendre la stabilisation complète d'un standard avant de s'y intéresser, c'est souvent partir avec plusieurs longueurs de retard. Les équipes qui ont expérimenté le responsive dès 2011-2012 n'ont pas dû tout refaire en 2015 quand Google a commencé à pénaliser les sites non mobile-friendly.

La logique est similaire ici. Les sites qui auront identifié leurs formulaires clés, structuré leurs actions principales et commencé à penser en termes d'"outils exposables" seront dans une meilleure position quand WebMCP arrivera en support stable.

Concrètement, ce qu'on peut faire maintenant :

• Identifier les 3 à 5 actions les plus répétées sur votre site (recherche, réservation, contact, achat) et se demander comment elles seraient décrites à un agent
• Soigner l'accessibilité de vos formulaires : labels corrects, descriptions ARIA, champs nommés de façon explicite. WebMCP récompense les bonnes pratiques d'accessibilité déjà en place
• Suivre l'évolution de la spec via le repo GitHub du W3C Web Machine Learning Community Group et les annonces Chrome
• Tester en Chrome Canary avec le flag WebMCP activé si vous voulez commencer à expérimenter

Ce n'est pas urgent. Mais c'est le bon moment pour comprendre ce qui s'en vient.