Un agent IA trouve votre page produit. Il peut lire le texte, citer le prix, peut-être même vous mentionner dans une AI Overview. Mais peut-il réellement ajouter l'article au panier, appliquer un filtre ou finaliser un checkout ? C'est exactement la question à laquelle WebMCP répond, et c'est précisément là qu'un nouveau terrain de jeu se sépare de celui dont la plupart des équipes parlent déjà.

La réponse courte : qu'est-ce que WebMCP ?

WebMCP est un standard web proposé (spécification en draft sous webmachinelearning/webmcp, publiée le 18 mai 2026, mise à jour le 9 juin 2026) qui permet aux sites web d'exposer des outils structurés pour les agents IA. Plutôt que de laisser un agent deviner à quoi sert un bouton, le site le lui dit directement : "cet élément est un outil de checkout, il attend ces paramètres, il renvoie cette réponse." Chrome supporte actuellement WebMCP via un origin trial à partir de la version 149, testable en local via chrome://flags/#enable-webmcp-testing. Angular a déjà annoncé un support expérimental.

Le concept central derrière tout cela est l'actuation : le moment où un agent arrête de lire et commence à agir, clique, saisit, soumet, comme le ferait un utilisateur humain. WebMCP rend l'actuation plus fiable parce que le site déclare la fonction d'un élément au lieu de forcer l'agent à l'interpréter.

Deux moitiés de la visibilité IA, et pourquoi la plupart des équipes n'en connaissent qu'une

Quand on parle de "visibilité IA" aujourd'hui, on désigne presque toujours la première moitié : la lisibilité. Un modèle de langage peut-il citer votre contenu, Perplexity comprend-il votre structure, apparaissez-vous dans une AI Overview de Google. Un vocabulaire établi existe déjà pour cela : GEO, AEO, Schema.org, l'answer engine optimization (voir notre comparatif SEO vs. GEO vs. AEO).

La seconde moitié est à peine occupée : l'actionnabilité. Le même agent qui vous cite peut-il aussi faire quelque chose sur votre storefront. Ajouter un article au panier, vérifier une disponibilité, finaliser une réservation. Ce n'est plus une question de contenu, c'est une question d'architecture : comment votre frontend est-il construit, et cette construction permet-elle une interaction déclarée et lisible par une machine.

C'est exactement le point que la plupart des discussions sur l'agentic commerce en 2026 laissent de côté : elles parlent des agents, mais pas de ce que le site lui-même doit savoir faire pour qu'un agent puisse agir en toute sécurité. WebMCP est le premier standard qui rend cet écart techniquement concret.

Comment WebMCP fonctionne concrètement

WebMCP propose deux façons d'exposer des outils :

• API impérative : vous définissez des outils directement en JavaScript, par exemple checkout(), filter_results(), navigate(), ou l'accès à un état partagé de la page. Chaque outil reçoit un schéma JSON pour l'input et l'output, ce qui réduit les hallucinations car l'agent n'a plus à deviner quels paramètres sont attendus.
• API déclarative : vous annotez directement des formulaires HTML existants, sans écrire de définitions d'outils séparées. Cela convient bien aux interactions plus simples, basées sur des formulaires.

Trois briques portent le modèle :

1. Discovery : la page enregistre ses outils, un agent peut les trouver en la visitant.
2. Schémas JSON : les inputs et outputs sont explicitement typés, c'est la différence avec un agent qui clique au hasard.
3. State : les outils partagent le contexte de la page, un agent n'a pas besoin de reconstituer l'état à partir du DOM.

Ce qui compte pour la confiance et le contrôle de marque : les outils s'exécutent visiblement sur la page. L'agent simule de vraies interactions dans l'UI, pas un canal backend caché. Votre design reste visible, votre marque reste intacte, et pour des actions sensibles comme un achat, la page peut exiger une boîte de dialogue de confirmation avant que l'action ne s'exécute réellement.

La sécurité est pensée dès la conception, pas ajoutée après coup

WebMCP ne s'exécute que dans des documents isolés par origine et est gouverné par une permissions policy tools. La valeur par défaut est self, les iframes cross-origin ont besoin d'un allow="tools" explicite pour exposer des outils. C'est une différence délibérée par rapport à de nombreuses intégrations d'agents précoces, qui greffaient l'accès aux outils sur des pages existantes après coup.

Où WebMCP atteint ses limites aujourd'hui

WebMCP n'est pas une solution miracle, c'est un fondement en draft précoce mais sérieux :

• Nécessite un contexte de navigation : un onglet réel, pas une simple requête headless. Cela exclut pour l'instant certains scénarios d'automatisation batch.
• Overhead sur des interfaces complexes : plus une page a de surface d'interaction, plus elle a besoin de définitions d'outils, ce qui est un travail de maintenance continu.
• Découvrabilité des outils : un client doit visiter directement la page pour trouver ses outils. Il n'existe pas encore de catalogue central, contrairement aux marketplaces d'API.

Ces limites sont précisément la raison pour laquelle WebMCP doit être traité comme une brique dans une architecture frontend plus large, pas comme un plugin greffé sur une installation existante.

La thèse : l'actuation est une propriété d'architecture, pas un bolt-on

C'est ici que la plupart des équipes tirent la mauvaise conclusion. La réaction évidente face à WebMCP est : "ajoutons une poignée de définitions d'outils." Cela fonctionne à court terme, mais cela ne résout pas le vrai problème. Qu'un agent puisse réellement agir sur votre storefront ne se décide pas dans un script greffé après coup, cela se décide dans le fait que votre rendu soit déterministe, que vos composants soient clairement structurés, et que votre couche frontend soit ne serait-ce qu'une cible stable pour une interaction déclarée.

Nous avons déjà défendu cet argument dans le contexte des agents IA et des guardrails : les agents pilotés par schéma ont besoin d'un frontend qui leur donne des limites claires et des garanties claires, pas une structure DOM improvisée qui bouge à chaque refonte (voir Agentic Frontend Guardrails pour les agents pilotés par schéma). Et nous avons montré pourquoi un render contract, un accord contraignant entre les données backend et la présentation frontend, est la condition préalable aux interactions autonomes de commerce (voir Le render contract frontend pour le commerce autonome). WebMCP est la continuation logique de cette ligne : un standard qui ne rend l'actuation fiable qu'une fois que l'architecture en dessous est déjà propre.

C'est aussi pour cela que nous construisons l'Agentic Frontend Management Platform de manière à ce que designers humains et agents IA opèrent sur la même librairie de composants. Quand les composants se rendent de façon déterministe et que leur signification (prix, disponibilité, action panier) est structurellement explicite, le chemin vers des outils WebMCP déclarés cesse d'être un saut et devient une extension logique de la couche de composants existante. Concrètement : quand un storefront est construit à partir de sections et de blocs clairement définis, où chaque composant connaît déjà sa propre fonction (fiche produit, filtre, étape de checkout), l'étape suivante consiste à déclarer précisément ces fonctions comme des outils WebMCP au lieu de les deviner à partir de HTML généré. Nous travaillons activement sur ce lien ; ici, nous restons délibérément au niveau de la vision, le détail des fonctionnalités concrètes suivra une fois que le standard aura dépassé le stade de l'origin trial.

Qu'est-ce que cela signifie pour le marketing et les product owners ?

Si vous ne manipulez pas des schémas JSON tous les jours, voici ce qui compte : l'actuation décide si votre landing page de campagne, votre configurateur ou votre checkout est simplement "lisible" ou réellement "utilisable" par des agents IA. Un agent qui réserve un voyage, remplit un formulaire ou demande un diagnostic ne le fait de façon fiable que si la page lui indique quelle action produit quel effet. C'est pertinent pour les flux de support, les parcours de réservation, les formulaires structurés (par exemple submit_application) et les champs pensés humains d'abord comme la sélection de dates. Tout ce que vous investissez déjà aujourd'hui dans la personnalisation et l'optimisation de conversion est la même base de storefront dans laquelle vous investirez demain pour l'actionnabilité agent, c'est la même couche frontend, juste avec un second public.

WebMCP et GEO/AEO : réunir les deux moitiés

Lisibilité et actionnabilité ne sont pas un choix exclusif. Un storefront optimisé pour les answer engines (voir Answer Engine Optimization est architecture, pas un bolt-on et Le storefront prêt pour le GEO : frontend pour les answer engines IA) mais qui n'expose aucun outil déclaré se fait citer, jamais utiliser. Un storefront qui expose des outils WebMCP mais qui est illisible pour les crawlers IA se fait utiliser, jamais trouver. Les deux appartiennent à la même stratégie frontend, sur le même socle Schema.org, la même couche de données structurées, le même rendu déterministe. C'est exactement ce que couvre notre couche produit SEO and GEO, prolongée par la vision d'un storefront qui traite la découvrabilité IA non seulement comme une couche de lecture, mais aussi comme une couche d'action (voir notre positionnement sur l'IA pour la découvrabilité).

Le modèle d'interface est apparenté, sans être identique : Laioutr expose déjà sa propre interface MCP pour les agents côté serveur qui veulent dialoguer avec la plateforme. WebMCP déplace le même principe sous-jacent, des outils déclarés plutôt qu'une intention interprétée, dans le contexte du navigateur, directement sur la page du storefront. Les deux couches se complètent, elles ne sont pas le même protocole.

À retenir

WebMCP est un signal précoce mais techniquement concret : la prochaine vague de visibilité dans l'e-commerce ne se décidera pas uniquement à la qualité du contenu, mais à l'architecture frontend. Les équipes qui investissent aujourd'hui dans un frontend déterministe, construit par composants, posent la fondation sur laquelle l'actuation ne sera pas demain un projet à part, mais une extension logique.

Questions fréquentes sur WebMCP

Quelle est la différence entre WebMCP et le web scraping classique par des agents IA ?

Avec le scraping, l'agent interprète la page et doit deviner à quoi sert un élément. Avec WebMCP, la page déclare elle-même ses outils, y compris un schéma JSON pour l'input et l'output, l'agent n'a plus rien à interpréter.

WebMCP est-il déjà prêt pour la production ?

WebMCP est une spécification en draft, disponible via origin trial à partir de Chrome 149 et testable en local via les Chrome flags. C'est encore trop tôt pour un déploiement large en production, mais pas trop tôt pour préparer votre architecture.

WebMCP nécessite-t-il un onglet de navigateur visible ?

Oui. WebMCP suppose un vrai contexte de navigation ; les requêtes batch purement headless ne sont pas couvertes.

Quel est le lien entre WebMCP et GEO/AEO ?

GEO et AEO optimisent le fait que les systèmes IA citent votre contenu (lisibilité). WebMCP optimise le fait qu'un agent puisse réellement agir sur votre page (actionnabilité). Ensemble, ils forment une visibilité IA complète.

Quel est le lien entre WebMCP et l'interface MCP propre à Laioutr ?

L'interface MCP de Laioutr sert les agents côté serveur qui dialoguent avec la plateforme. WebMCP déplace le même principe, des outils déclarés plutôt qu'interprétés, dans le navigateur, directement sur le storefront.

À propos de l'auteur : Sebastian Langer est co-fondateur et CTO de Laioutr. Il est responsable de l'architecture technique de la Frontend Management Platform et travaille sur la question de savoir comment les couches frontend deviennent également accessibles aux humains et aux agents IA.