WebMCP et MCP s'installent dans deux roles distincts : WebMCP fait agir un agent dans le navigat…
WebMCP vs. MCP pour le e-commerce : ou se situe la frontiere des agents
Deux protocoles se disputent aujourd'hui la meme mission : permettre a un agent IA d'agir sur un storefront. WebMCP execute l'action dans le navigateur, sur ce que l'utilisateur a deja ouvert. MCP l'execute sur un endpoint serveur que l'agent appelle directement. Les deux repondent a « comment l'agent agit », mais posent d'abord une autre question : ou cela se passe-t-il, cote client ou cote serveur ? Pour les equipes qui construisent des storefronts prets pour les agents en 2026, ce choix de placement est desormais une decision d'architecture, pas un detail d'implementation.
Deux couches, une seule mission : l'actuation
WebMCP expose des outils directement dans le contexte du navigateur. Un agent operant dans une session, une extension de navigateur ou un navigateur agentique peut appeler des fonctions que la page elle-meme enregistre : ajouter au panier, appliquer un filtre, lancer le checkout, en utilisant le DOM et l'etat client deja presents. Nous avons couvert le principe d'actuation lui-meme dans comment WebMCP fait agir les agents dans le navigateur ; cet article se concentre sur la decision de placement, pas sur le mecanisme.
MCP (Model Context Protocol), a l'inverse, definit des endpoints cote serveur qu'un agent appelle independamment de toute session navigateur : recherche produit, mutation panier, statut de commande, tous exposes comme des outils appelables sur votre backend ou une couche middleware. Nous avons etudie ce que font concretement les agents sur ces endpoints dans endpoints MCP et actions des agents sur le storefront. Plusieurs editeurs convergent aujourd'hui vers une exposition MCP cote serveur, une tendance que nous avons suivie dans storefronts lisibles par les agents chez plusieurs editeurs.
La decision de frontiere, concretement
- Ou l'actuation s'execute. WebMCP (navigateur): Dans la page chargee, cote client. MCP (serveur): Sur un endpoint backend/middleware dedie.
- Ce qu'il faut. WebMCP (navigateur): Une page qui enregistre des outils dans le DOM. MCP (serveur): Une surface API independante de toute page ouverte.
- Contexte de session. WebMCP (navigateur): Utilise ce que le client a deja ouvert (panier, connexion). MCP (serveur): L'agent doit s'authentifier et maintenir sa propre session.
- Gouvernance. WebMCP (navigateur): Liee au rendu, a la marque et aux regles d'acces du frontend. MCP (serveur): Liee aux permissions backend, aux limites de debit et aux contrats API.
- Cas d'usage ideal. WebMCP (navigateur): Actions assistees dans une session d'achat active. MCP (serveur): Agents autonomes ou planifies agissant sans navigateur.
Aucune couche ne remplace l'autre. Un agent dans une session navigateur profite de l'acces direct au DOM de WebMCP ; un agent operant sans aucune page ouverte, une integration backend, une tache de reachat planifiee, a besoin d'un endpoint MCP cote serveur qui ne depend pas du tout d'une page rendue.
Pourquoi le frontend reste maitre de cette decision
Quelle que soit la couche utilisee par un agent, il lit toujours les donnees structurees, les attributs produits et le balisage conforme a la marque du storefront pour decider ce que signifie « ajouter ceci au panier ». L'enregistrement des outils WebMCP vit dans le code frontend. Les endpoints MCP cote serveur ont toujours besoin de donnees produit et contenu maintenues par le frontend pour repondre correctement. C'est exactement la question operationnelle autour de laquelle notre Plateforme Agentic Frontend Management est construite : quelqu'un doit garder les deux surfaces d'actuation coherentes, conformes a la marque et a jour, quel que soit le protocole choisi par un agent donne.
Ce que cela signifie pour les marchands
- Si votre equipe commerce construit pour des assistants d'achat en session : commencez par l'enregistrement d'outils WebMCP sur vos pages a plus forte intention.
- Si vous exposez catalogue, panier ou donnees de commande a des agents autonomes sans navigateur : construisez d'abord les endpoints serveur MCP.
- La plupart des storefronts auront besoin des deux d'ici 12 a 18 mois. Concevez la couche de donnees une fois, exposez-la deux fois.
FAQ
WebMCP remplace-t-il MCP ? Non. WebMCP gere l'actuation cote navigateur pour les agents operant dans une page ou session ouverte. MCP gere l'actuation cote serveur pour les agents qui appellent votre backend directement, avec ou sans navigateur.
Lequel les marchands doivent-ils construire en premier ? Cela depend de l'origine de votre trafic d'agents aujourd'hui. Les assistants d'achat en session favorisent WebMCP ; les integrations backend et les agents autonomes favorisent MCP. La plupart des equipes finissent par avoir besoin des deux.
Cela change-t-il l'architecture du storefront ? Oui, les deux surfaces d'actuation dependent de la meme couche de donnees frontend sous-jacente, donnees produit structurees, balisage coherent et gouvernance de marque, qui doit rester exacte. C'est un travail de gestion du frontend, pas une integration de protocole ponctuelle.
Prochaines etapes
Si vous voulez une evaluation concrete de la position de votre storefront sur l'actuation navigateur versus serveur, parlons-en.
CTA : Verifiez si votre storefront est pret pour les agents
Plus sur la plateforme Laioutr
A propos de l'auteur : Marcel Thiesies est CEO & Co-Founder de Laioutr. Il ecrit sur l'architecture frontend, le commerce agentique et la construction de storefronts composables sans risque de replatforming.