Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
Trois protocoles de commerce, aucun standard
En quelques semaines seulement, début 2026, trois cadres concurrents décrivant la façon dont les agents IA accèdent aux données produit ont atterri sur les bureaux des CMO. Shopware a lancé son Agentic Experience Protocol (AXP), construit sur le Universal Commerce Protocol (UCP) et soutenu par une Agentic Commerce Alliance nouvellement créée. La spécification de base UCP existe elle-même comme standard ouvert pour l'échange de données entre agents et commerce. Et le parcours Instant Checkout d'OpenAI, une approche qui permet à ChatGPT de finaliser des achats directement, reste un signal précoce : à l'heure où nous écrivons, il est documenté comme actif auprès d'une trentaine de marchands, un chiffre qui n'a pas atteint l'échelle grand public que ses premières annonces laissaient entendre.
Mon avis : ce n'est pas une guerre de standards sur laquelle il vaut la peine de parier. C'est une question d'engagement qu'il vaut mieux trancher correctement.
Ce qu'on vous demande réellement de décider
Quand un éditeur, une alliance ou un rapport d'analyste vous invite à « adopter le protocole X », la demande implicite est en général l'une de ces deux choses : réarchitecturer votre flux de données produit pour que les agents puissent le lire, ou développer une logique d'intégration dédiée à cette pile protocolaire précise. Les deux ont un coût. Les deux comportent le risque de miser sur le mauvais standard.
Avant de trancher, il vaut la peine d'être précis sur ce que ces protocoles standardisent réellement, et sur ce qu'ils ne standardisent pas.
Des protocoles comme AXP et UCP standardisent la couche d'échange de données entre un backend commerce et un agent IA. Ils spécifient comment les données produit, les prix, la disponibilité et, dans le cas d'AXP, des signaux plus riches comme les assets 3D et les indicateurs de qualité circulent de votre système vers le contexte d'un agent. C'est réellement utile. Un flux produit structuré et lisible par une machine vaut mieux qu'un flux non structuré.
Ce que ces protocoles ne spécifient pas, c'est l'apparence de l'expérience côté client. Ils transportent des données. Ils ne les rendent pas. Le rendu, c'est-à-dire ce qu'un acheteur voit réellement, qu'il s'agisse d'un humain qui parcourt votre storefront ou d'un agent IA qui compose un comparatif produit, reste un problème de frontend.
Le risque de fragmentation est réel, mais il ne se trouve pas là où la plupart des équipes regardent
Le cadrage habituel de la fragmentation des protocoles est le suivant : « Nous risquons d'intégrer AXP, puis c'est UCP qui l'emporte, et nous avons perdu six mois. » C'est un risque réel. Mais c'est le risque secondaire.
Le risque principal est plus subtil : s'engager sur une pile d'intégration spécifique à un protocole au niveau du frontend. Construire un chemin de rendu étroitement couplé à la structure de données d'un seul protocole. Écrire des composants frontend qui présupposent le format Rich Experience d'AXP ou les noms de champs d'UCP. C'est à ce niveau que la fragmentation devient coûteuse, non pas parce que le protocole perd, mais parce que votre logique de rendu ne peut plus s'adapter quand le protocole évolue, qu'un deuxième protocole émerge ou que votre backend change.
C'est là que la couverture doit se situer.
La couverture rationnelle : une couche de rendu agnostique au protocole
Le cadrage au niveau CMO auquel je reviens sans cesse dans mes échanges avec les marques mid-market et enterprise est celui-ci : vous n'avez pas besoin de parier sur un protocole. Vous avez besoin d'une couche frontend capable de rendre celui qui l'emportera.
Trois protocoles veulent vos produits. C'est une question de flux de données pour votre backend commerce. Votre équipe backend peut évaluer quels flux exposer et à quelle fréquence. Ce travail est maîtrisable.
La question de l'expérience, à savoir à quoi ressemble votre marque quand un agent met en avant votre produit, ce qu'un humain voit en arrivant sur votre storefront, et comment ces deux surfaces restent cohérentes, est une question de frontend. Et elle appelle la même réponse quel que soit le protocole qui transporte les données.
Une couche frontend qui découple le rendu des spécificités protocolaires peut consommer un flux UCP, une charge utile AXP Rich Experience ou une structure produit compatible OpenAI et restituer la même expérience de marque dans les trois cas. Ce n'est pas une architecture théorique. C'est l'avantage concret de construire sur un frontend headless composable plutôt que sur un chemin d'intégration natif à un protocole.
La Agentic Frontend Management Platform de Laioutr est conçue exactement selon ce modèle : une couche de rendu, plusieurs flux protocolaires, une seule sortie de marque.
Implication budgétaire : où ne pas dépenser
Si votre discussion budgétaire de ce trimestre comporte une ligne « pile d'intégration du protocole X », soit une équipe d'ingénierie dédiée à parser et rendre le format de données propre à un seul protocole sur tout votre storefront, je marquerais une pause avant de la valider.
La question à poser est la suivante : cette pile d'intégration est-elle spécifique à un protocole, ou agnostique ?
Spécifique à un protocole : vous construisez des composants qui attendent les noms de champs d'AXP. Quand AXP évolue ou qu'un deuxième protocole devient obligatoire pour un canal de distribution clé, vous reconstruisez.
Agnostique au protocole : vous construisez une couche de normalisation des données qui mappe n'importe quel format de flux entrant vers la structure attendue par votre bibliothèque de composants. Les changements de protocole sont absorbés par l'adaptateur, pas au niveau des composants.
La seconde voie coûte plus cher à concevoir au départ. Elle coûte moins cher sur 24 mois, parce que vous ne reconstruisez pas le frontend à chaque déplacement du paysage protocolaire, et ce paysage va se déplacer. Aucun des trois standards cités en début d'article ne l'a emporté. La voie d'OpenAI a calé au moment de passer à l'échelle. AXP est soutenu par une alliance mais reste jeune. UCP est une base ouverte que plusieurs éditeurs étendent dans des directions différentes. Miser le frontend sur l'un d'eux est le choix coûteux.
Pour un examen plus approfondi des raisons pour lesquelles la couche backend vers agent et la couche de rendu frontend doivent être traitées comme deux décisions budgétaires distinctes, l'article Every Backend Ships Agents développe le cadrage CFO en détail.
La question d'audit de stack pour votre prochain point CMO et CFO
Une chose concrète que vous pouvez apporter à votre prochaine revue de stack :
« Lesquels de nos composants frontend actuels présupposent le format de données d'un protocole précis, et lesquels sont normalisés via une couche d'abstraction ? »
Si la réponse est « la plupart des composants sont étroitement couplés à la structure d'API de notre backend actuel », ce n'est pas immédiatement une crise. Cela le devient quand la deuxième ou la troisième demande d'intégration protocolaire arrive sur le bureau de l'équipe technique. Le moment de construire la couche d'abstraction est avant l'arrivée du deuxième protocole, pas après.
Un visual page builder qui se place au-dessus de la couche de données et permet aux équipes marketing d'itérer sur l'expérience indépendamment des changements backend est une partie de la réponse. L'autre partie est la couche de normalisation à la frontière du flux de données, celle qui fait que vos composants se moquent de savoir si le flux du jour est AXP, UCP ou quelque chose qui n'existe pas encore.
C'est aussi l'architecture qui vous donne une cohérence multi-marque à grande échelle. Une bibliothèque de composants qui restitue trois flux protocolaires relève du même principe qu'une bibliothèque de composants qui restitue trois storefronts régionaux. L'abstraction est l'actif. À lire également : Consolidation MarTech et prolifération des stacks.
Note d'architecture de Sebastian : Au niveau de l'implémentation, une couche de rendu agnostique au protocole fonctionne selon un pattern d'adaptateur de flux. Chaque protocole, AXP, UCP ou une API backend maison, se mappe sur un adaptateur léger qui normalise les données entrantes vers un schéma produit partagé (titre, prix, références média, attributs structurés). La bibliothèque de composants frontend ne consomme que ce schéma normalisé. Changer ou ajouter un protocole revient à écrire un nouvel adaptateur, pas à toucher aux composants. Dans un frontend composable, cela représente un service d'intégration supplémentaire, pas une reconstruction du frontend. L'arbre de composants reste stable pendant que les sources de données se multiplient.
Ce que la fragmentation dit de 2026 et 2027
Le fait que trois piles protocolaires concurrentes coexistent est en soi un signal utile. Il indique que la couche de données entre commerce et agents n'est pas stabilisée. Organismes de normalisation, grands éditeurs de plateformes et hyperscalers cherchent chacun à s'approprier cette couche, ce qui correspond exactement au schéma observé dans les années qui précèdent l'émergence d'un standard de fait. L'architecture MACH a connu une période comparable de « quel éditeur composable va imposer le standard » avant que les patterns de stack ne se stabilisent.
Le travail du CMO dans ce contexte n'est pas de désigner le vainqueur trop tôt. C'est de structurer le pari d'infrastructure de façon à pouvoir adopter n'importe quel vainqueur sans reconstruction complète. Voilà la couverture. Et l'endroit où la construire est la couche de rendu frontend, la partie de votre stack qui touche tous les protocoles de la même façon et que l'on peut rendre indifférente à chacun d'eux en particulier.
Rien de tout cela n'exige d'attendre. L'architecture agnostique au protocole est disponible aujourd'hui, précisément parce qu'elle ne porte pas vraiment sur les protocoles. Elle porte sur la façon dont vous construisez vos composants frontend.
Pour aller plus loin :
CTA : Si vous voulez auditer votre architecture frontend actuelle au regard de la question de la fragmentation des protocoles, je serai ravi de mener un audit de stack de 30 minutes avec vous. Une cartographie concrète des recoupements, pas une slide de démo.
Plus sur Laioutr : Personalization.