Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
L'avenir du e-commerce
Lors de l'eCommerce BBQ 2026, une phrase a résumé l'ambiance de toute la soirée : hier, nous faisions ce qui était possible dans le e-commerce. Demain, nous ferons ce qui crée de la valeur. Une formule accrocheuse, et gênante dès que l'on regarde honnêtement sa propre stack.
Car c'est ainsi que la plupart des boutiques sont construites. Année après année, les équipes ont ajouté ce qui était possible à ce moment-là : un outil ici, une intégration là, une fonctionnalité de plus par-dessus. Le résultat fonctionne, mais il est rarement le fruit d'une décision. Il est le fruit d'une multitude de petites adaptations.
Cet article reprend l'idée centrale de cette soirée et la pousse plus loin sous l'angle du frontend : pourquoi l'adaptation n'est pas l'évolution, pourquoi la tour d'outils atteint sa limite, et pourquoi la couche storefront est désormais l'endroit où se crée la valeur dans le e-commerce.
Le marché repart à la hausse, mais les règles changent
D'abord les faits. Le commerce en ligne allemand renoue avec la croissance. Selon l'IFH Köln, le marché progresse de 5,7 pour cent en 2025, après 3,8 pour cent l'année précédente. Cela représente environ 92 milliards d'euros de chiffre d'affaires sur les produits neufs, et un bon 103 milliards en incluant la seconde main. Pour 2026, la courbe continue de monter.
Une croissance solide. Mais la croissance seule ne dit rien de ceux qui en profitent. Pendant que le marché s'élargit, quelque chose de fondamental se déplace en dessous, et cela porte un nom : l'IA.
L'IA n'est pas le prochain outil de la liste. Jusqu'ici, chaque nouvelle technologie suivait le même schéma : elle arrive, et nous nous demandons comment l'intégrer à notre modèle économique existant. Avec l'IA, ce schéma ne suffit plus. La vraie question n'est pas de savoir comment adapter l'IA à notre modèle, mais quelle partie de notre modèle l'IA rend obsolète. L'IA ne change pas une fonctionnalité. Elle change l'endroit et la manière dont la valeur se crée dans le commerce.
L'adaptation n'est pas l'évolution
C'est là l'erreur de raisonnement qui coûte cher. Adapter, c'est prendre la nouveauté et la faire entrer dans l'ancien. Évoluer, c'est reconstruire l'ancien parce que la nouveauté a changé les fondations.
Henry Ford a parfaitement résumé la différence. S'il avait demandé aux clients ce qu'ils voulaient, ils auraient réclamé un cheval plus rapide. Appliqué au commerce d'aujourd'hui : optimiser votre stack existante vous donne une tour plus stable, pas de nouvelles fondations. L'image du hamster fonctionne tout aussi bien. Courir dans la roue, c'est de l'activité ; grimper l'échelle, c'est du progrès. Vu de l'extérieur, les deux ressemblent à du mouvement. Un seul vous fait monter.
C'est pourquoi la vraie question posée à l'eCommerce BBQ n'était pas une question technique mais une question business : quelle partie de votre dispositif ne tient que parce que vous avez toujours fait ainsi ?
Le vrai problème : le e-commerce comme tour d'outils
Regardez une stack typique et vous verrez presque toujours la même image. La boutique en ligne à la base, et empilés par-dessus : PIM, search, A/B testing, analytics, CRM, personnalisation, paiements, marketing automation. Chaque couche son outil, chaque outil son intégration, chaque intégration sa synchronisation de données.
Cette tour tient aussi longtemps que personne n'y touche. Mais elle est fragile, coûteuse et difficile à faire évoluer. Chaque nouvelle capacité coûte une interface de plus et un point de rupture supplémentaire. Essayez de remplacer une fonctionnalité et vous retirez rarement un seul bloc sans que toute la structure bouge.
C'est l'adaptation dans sa forme la plus pure. Pendant des années, les équipes ont ajouté tout ce qui était possible, et au bout du compte elles gèrent plus d'intégrations que de contenu. La complexité n'est pas le moyen d'arriver au chiffre d'affaires, c'est l'impôt que le chiffre d'affaires paie.
Comment savoir que vous êtes encore en train d'adapter
Le passage de l'adaptation à l'évolution est rarement un grand moment unique. La plupart du temps, il se lit dans de petits signaux du quotidien. Trois d'entre eux reviennent sans arrêt.
Premier signal : une simple landing page nécessite un ticket développeur et attend dans le backlog du sprint. Quand le marketing dépend de l'engineering pour une page de campagne, la création de valeur est à l'arrêt dans les embouteillages.
Deuxième signal : personne n'ose remplacer un outil. Quand la réponse à « peut-on changer le moteur de recherche ? » est régulièrement « en théorie oui, en pratique mieux vaut éviter », c'est la tour qui dirige l'équipe et non l'inverse.
Troisième signal : un nouveau marché ou une nouvelle marque signifie chaque fois un projet à repartir de zéro. Une architecture évolutive déploie des marques et marchés supplémentaires depuis une seule base au lieu de les dupliquer.
Si vous vous reconnaissez dans l'un de ces signaux, rien n'a mal tourné. C'est la conséquence normale d'avoir ajouté pendant des années tout ce qui était possible. Le point est simplement celui-ci : optimiser raccourcit l'embouteillage, découpler le dissout.
L'évolution se joue dans le frontend
La bonne nouvelle : la sortie ne passe pas par une suite plus grosse ni par une tour encore plus haute. Elle passe par une séparation nette entre deux couches.
Le backend devient la source de vérité. Produits, stocks, commandes et prix y vivent, maintenus une seule fois et proprement. Le frontend devient l'endroit où ces données se transforment en valeur client : vitesse, contenu, personnalisation, conversion. Entre les deux se place une couche storefront découplée qui consomme les données et compose l'expérience.
Une phrase de la soirée résume le basculement : les boutiques en ligne étaient autrefois des projets techniques, aujourd'hui ce sont des projets commerciaux. Autrement dit, la couche frontend n'est plus un détail d'implémentation en bout de chaîne. C'est le levier de la vitesse marketing, de l'entrée sur de nouveaux marchés et de la conversion. C'est précisément pour cela qu'elle appartient au centre de l'architecture, et non à la fin de la chaîne. À quoi ressemble concrètement cette couche découplée, c'est à découvrir sur notre page Composable Headless Frontend.
Évoluer ne veut pas dire échanger un monolithe contre un autre
C'est là que se cache la tentation : tout recomprimer dans un seul système fermé. Cela donne l'impression de faire du rangement, mais cela ne fait que reconstruire la tour avec de plus jolis murs et crée la dépendance suivante. Un monolithe reste un monolithe, même quand il a l'air moderne.
Notre point de vue est différent. Évoluer dans le frontend signifie composable, pas fermé. Une Frontend Management Platform (FMP) regroupe les capacités qui pèsent sur la conversion dans une seule couche de contrôle, sans avaler le backend. L'architecture reste ouverte, la propriété des données reste entre vos mains et la stack reste interchangeable. Si vous voulez la comparaison avec la suite classique, elle est sur notre page Composable Digital Experience Platform.
La différence n'est pas cosmétique. Avec un monolithe, vous échangez du confort contre du lock-in. Avec le composable, vous gardez le contrôle sur chaque couche et pouvez remplacer des briques individuelles sans toucher à l'ensemble du système.
Ce qu'apporte une architecture frontend évolutive
Les capacités aujourd'hui éparpillées dans dix outils faiblement connectés appartiennent à la couche storefront, pilotables depuis un seul endroit. Concrètement :
- Personalization qui s'exécute à l'edge, au lieu d'être chargée tardivement par un script.
- A/B testing et optimisation où la variante est déjà en place avant d'être servie, sans impact sur la performance.
- Composition de contenu et de pages dans le Visual Page Builder, pour que le marketing construise de nouvelles landing pages en heures plutôt qu'en semaines.
- SEO and GEO avec un balisage Schema.org propre, pour que le storefront reste visible aussi dans les réponses des IA.
- Performance et Core Web Vitals comme propriété de l'architecture, pas comme rattrapage de dernière minute.
- Multi-marque et multi-marché, pour que de nouvelles marques et de nouveaux marchés se déploient depuis une seule base.
- Accessibilité conforme WCAG, intégrée dès le départ plutôt que rajoutée après coup.
L'effet concret : les équipes marketing itèrent en autonomie, l'engineering relit et étend. Plus de ticket bannière qui traîne une semaine dans le backlog du sprint. La tour fragile devient une couche de contrôle rapide, stable et efficace sur la conversion.
Le backend reste, le frontend se libère
C'est peut-être le point le plus important de cette évolution : elle n'exige pas de replatforming. Vous n'avez pas besoin de changer votre backend pour moderniser votre frontend.
Une couche découplée se pose au-dessus de la stack commerce existante. Que ce soit Shopware, Shopify, commercetools, OXID ou Magento, le backend reste la source de vérité et le frontend se libère. Cela réduit au minimum le risque classique du replatforming : pas de projet greenfield de 18 mois, mais un chemin frontend-first où le backend reste de toute façon interchangeable plus tard.
L'ajout d'autres capacités passe par des API ouvertes et des connecteurs prêts à l'emploi plutôt que par du code de liaison écrit à la main. Les intégrations et applications que vous pouvez connecter sont listées dans le Laioutr App Store. C'est la différence décisive avec la tour d'outils : pas moins de capacités, mais moins de points de rupture.
Pourquoi cela compte particulièrement sur le marché DACH
Dans la région DACH, deux sujets renforcent l'argument du découplage. D'abord, l'hébergement et la protection des données. Hébergé dans l'UE et conforme au RGPD ne sont pas ici des options, c'est un socle. Une architecture découplée facilite l'exécution de la couche storefront là où les données doivent vivre, sans avoir à toucher au backend pour cela.
Ensuite, l'accessibilité. Avec l'entrée en vigueur de l'European Accessibility Act, l'accessibilité devient obligatoire pour de nombreuses boutiques, et une accessibilité rajoutée après coup coûte cher. Un frontend qui prend WCAG en compte dès le départ évite précisément ce rattrapage. Ni l'un ni l'autre n'est un add-on, les deux sont des propriétés de l'architecture, ce qui est une raison de plus de choisir la couche frontend de façon délibérée au lieu de la laisser s'agréger au fil des années.
Agentic commerce : l'étape suivante de l'évolution
Si l'IA change l'endroit où la valeur se crée, elle change aussi qui opère le storefront. À l'ère de l'agentic commerce, humains et agents IA travaillent sur la même bibliothèque de composants. Les agents IA prennent en charge des tâches concrètes : générer des variantes de contenu, optimiser les balises meta et le maillage interne, surveiller les Core Web Vitals et alerter en cas de régression.
En parallèle, la demande se déplace. De plus en plus souvent, des agents font la recherche et l'achat pour le compte des personnes. Un storefront doit donc être agent-ready : données structurées, Schema.org propre, API claires. Mettre cela au propre tôt, c'est rester visible quand la requête ne vient plus d'un navigateur mais d'un agent. C'est exactement ce pour quoi est conçue une Agentic Frontend Management Platform.
Ce n'est pas une vision lointaine. C'est la suite logique de la séparation du backend et du frontend. Si la couche storefront est de toute façon l'endroit où la valeur se crée, c'est aussi l'endroit où l'IA a le plus grand levier.
Ce que cela signifie pour vous
La soirée au bord de la Spree s'est terminée par un clin d'œil à la citation de Ford : si vous aviez demandé aux clients, ils auraient seulement souhaité une tour plus stable. La chute vaut pour tout le marché. Une tour plus stable, c'est de l'adaptation. De nouvelles fondations, c'est de l'évolution.
En pratique, cela ne veut pas dire tout reconstruire demain. Cela veut dire commencer par la question de l'endroit où la valeur rencontre le client dans votre dispositif. Cet endroit, c'est presque toujours le frontend. C'est là que le premier pas évolutif est rentable, parce qu'il donne des résultats rapidement, ne touche pas au backend et maintient le risque de replatforming à un niveau faible.
Le marché repart à la hausse. La seule question est de savoir si vous courez plus vite dans la roue ou si vous grimpez l'échelle.
Si vous voulez savoir à quoi ressemble le premier pas pour votre stack, rendez-vous sur la page d'accueil Laioutr ou continuez la lecture sur le blog Insights.
Pages associées
À lire également : From API Gateway to AI Agent Layer: BFF in Agentic Commerce et From DXP to Composable Commerce: The Architectural Evolution Every Brand Must Understand.