En 2026, chaque couche du stack commerce obtient son propre serveur MCP. Le schema est clair : les agents lisent des API, pas des pixels. Mais les agents agissent toujours au niveau de la vitrine, et c'est la que chacune de ces surfaces vendor doit etre composee pour un acheteur qui se moque de savoir quel serveur a repondu a quel appel.

Ce qui se passe : un serveur MCP par couche

Les serveurs Model Context Protocol ont cesse d'etre une nouveaute cette annee. Ils sont devenus la maniere par defaut dont un vendor expose sa couche a un agent.

Le 30 juin 2026, Storyblok a profite de son webinaire "Product Update & Innovation Preview" pour presenter un serveur MCP dote de plus de 155 outils, avec acces complet en lecture et en ecriture a un espace. Il fonctionne avec Claude, Cursor et d'autres clients MCP, et rend le contenu existant lisible par les agents sans reconstruction ni migration. La couche de contenu parle desormais directement aux agents (source : storyblok.com/mp/mcp-server).

commercetools est arrive plus tot. Son Commerce-MCP rend les API backend accessibles aux agents depuis mai 2025, et son environnement "for Builders" (prompt-to-build pour le commerce d'entreprise, 23 juin 2026) porte la meme idee dans l'assemblage de la couche commerce. Salesforce a livre ses innovations B2B commerce en juin 2026, presentees comme un passage "du commerce agentique a la flexibilite headless".

Le ton est le meme chez les trois : les API comptent plus que les themes. Les agents lisent des API, pas des pixels. Chaque vendor rend sa propre couche lisible par un agent.

Le probleme : chaque serveur MCP s'arrete a sa couche

Voici l'ecart. Un serveur MCP de contenu expose du contenu. Un serveur MCP commerce expose le catalogue, le panier et les prix. Un serveur B2B expose les comptes, les contrats et les droits. Chacun est honnete sur sa frontiere, et chacun s'arrete exactement la ou sa couche se termine.

Un agent qui veut faire quelque chose d'utile pour un acheteur ne vit pas dans une seule couche. Il lit des donnees produit structurees, verifie une regle promotionnelle, extrait un bloc de contenu localise et confirme un prix specifique au compte. Cela fait quatre serveurs de trois vendors. Aucun d'eux ne possede le moment ou la reponse est assemblee et affichee.

Ce moment, c'est la vitrine. C'est la que l'acheteur lit le resultat, que l'agent agit, et que quatre surfaces vendor doivent converger en une experience coherente. La proliferation MCP resout la lisibilite par couche. Elle ne resout pas la composition entre couches.

Ou elles convergent : la couche d'experience

C'est la these de Laioutr, et elle est architecturale, pas publicitaire. Le point de convergence n'est pas un serveur MCP de plus. C'est la couche d'experience qui les consomme tous.

Une vitrine lisible par les agents se place au-dessus du stack composable et traite chaque surface MCP vendor comme une entree, pas comme une destination. La vitrine est l'endroit ou :

• les donnees structurees du backend commerce et du backend de contenu fusionnent en un seul rendu,
• un agent agissant pour un acheteur lit un contrat de composant clair et type, au lieu de scraper une page rendue,
• plusieurs surfaces d'agents vendor (contenu, catalogue, prix B2B) sont orchestrees en un flux unique que l'acheteur voit reellement.

Nous avons traite le cote lisible par la machine dans notre article sur le contrat de rendu deterministe : les agents ont besoin d'une surface previsible et adossee a un schema pour agir, sinon ils agissent au juge. La vague du MCP-par-couche rend ce contrat plus urgent, pas moins. Quand cinq serveurs peuvent chacun lire et ecrire leur couche, la vitrine doit etre le seul endroit qui garde le resultat compose deterministe.

Notre Composable Headless Frontend est concu exactement pour ce decouplage. Les couches backend restent independantes et interchangeables, chacune exposant son propre serveur MCP. Le frontend les compose sans heriter du verrouillage d'un seul vendor.

Ce que "agent-ready" signifie concretement au niveau de la vitrine

Agent-ready n'est pas un slogan. Sur la couche d'experience, cela signifie des choses precises :

• Des contrats de composants types, pour qu'un agent lise une ProductCard ou un PriceBlock comme des donnees structurees, pas comme une soupe de div a interpreter.
• Schema.org et des API propres au moment du rendu, pour que les AI Overviews, les agents shopping et les clients MCP obtiennent la meme reponse structuree. C'est le role de la couche produit SEO et GEO : garder la vitrine citable et lisible par la machine.
• Des regles de composition qui survivent a plusieurs sources, pour qu'une modification de contenu dans l'espace de Storyblok et un changement de prix dans un backend commerce atterrissent tous deux dans un seul rendu, sans reecriture du frontend.

Les garde-fous que nous avons decrits pour les agents pilotes par schema s'appliquent aussi ici. Quand les agents peuvent ecrire dans un espace de contenu et agir sur une vitrine, la couche d'experience est l'endroit ou l'on impose ce qu'un agent a le droit de composer et de publier. La lisibilite sans garde-fous n'est qu'un rayon d'impact plus large.

Pourquoi cela compte pour la decision que vous prenez maintenant

Si vous choisissez cette annee ou investir dans votre stack, la proliferation MCP change la question. Ce n'est plus "quel CMS ou backend commerce a une histoire d'agent". La plupart des vendors serieux en ont une desormais. La question est : ou ces histoires d'agents se composent-elles ?

Parier sur le serveur MCP d'un seul vendor pour posseder le moment cote acheteur, c'est parier contre sa propre composabilite. Le serveur de Storyblok est solide sur le contenu. commercetools est solide sur le commerce. Salesforce est solide sur le B2B. Aucun n'est la vitrine, et aucun ne veut etre la couche de composition neutre au-dessus des deux autres.

La couche d'experience est ce point neutre. Elle lit chaque surface MCP vendor, garde le rendu compose deterministe et lisible par les agents, et reste entre vos mains plutot que dans celles d'un backend. C'est la couche qui merite d'etre possedee alors que le commerce agentique passe du pilote a la production.

Parcourez les connecteurs et integrations de l'App Store pour voir quelles couches backend se branchent deja au point de composition, ou partez de la page d'accueil Laioutr et des Insights pour l'histoire d'architecture plus large.

FAQ

Un serveur MCP est-il la meme chose qu'une vitrine lisible par les agents ? Non. Un serveur MCP rend une couche lisible par un agent. Une vitrine lisible par les agents compose plusieurs de ces couches en la surface qu'un acheteur lit et sur laquelle un agent agit.

Faut-il tout reconstruire pour devenir agent-ready ? Non. Le serveur MCP de Storyblok rend le contenu lisible par les agents sans migration, et la couche d'experience compose les backends existants sans reecriture du frontend. Le decouplage est l'objectif.

Sur quel serveur MCP vendor faut-il se standardiser ? Standardisez par couche la ou cela a du sens, mais n'attendez pas qu'un seul serveur possede la composition. La vitrine est le point de convergence de tous.

A propos de l'auteur : Marcel Thiesies est Co-Founder de Laioutr. Nous construisons la Frontend Management Platform parce que les equipes frontend meritent le controle que l'ere composable a promis.