Génération 4 : les 25 ans d'évolution du monolithe au Frontend as a Service

Les frontends commerce ne sont pas passés du monolithe au moderne en un seul cycle de release. Ils ont traversé quatre générations bien distinctes sur environ 25 ans, chacune existant pour résoudre le point de rupture de la précédente. Savoir dans quelle génération votre storefront se trouve réellement, et non celle que suggère la présentation commerciale du fournisseur, est le moyen le plus rapide de préparer le prochain replatforming sans répéter les erreurs du précédent.

Génération 1 : le monolithe (2000 à 2010)

La première génération de plateformes commerce, Demandware (aujourd'hui Salesforce Commerce Cloud), ATG et hybris entre autres, regroupait logique backend, templating et rendu dans une seule application déployable. Modifier une landing page signifiait un edit de template, un cycle de QA et une fenêtre de release comptée en semaines. Le marketing dépendait entièrement de la capacité IT, et chaque campagne entrait en concurrence avec tout le reste du backlog pour le même créneau de release.

Génération 2 : le Headless Commerce (2011 à 2018)

La génération 2 a découplé le backend de la couche de présentation. commercetools a lancé une approche API-first, Shopify Plus a ouvert son Storefront API, et BigCommerce a suivi avec ses propres options headless. L'avantage était réel : les équipes pouvaient enfin choisir le meilleur backend disponible sans hériter de son moteur de templating. Le revers : quelqu'un devait tout de même construire le frontend depuis zéro, généralement une équipe React ou Vue dédiée, et cette équipe devenait le nouveau goulot d'étranglement. Le marketing continuait à ouvrir des tickets, simplement sur un backlog différent.

Génération 3 : les frontends Composable (2019 à 2023)

La MACH Alliance a formalisé le terme en 2020, suivie d'une vague d'outils basés sur des composants : Vue Storefront, Frontastic, et des starter kits construits sur Next.js. Les frontends sont devenus des assemblages de pièces interchangeables plutôt qu'un build sur mesure complet, ce qui a réduit sensiblement le temps de développement. Mais un frontend composable restait une codebase interne, possédée, déployée et maintenue par l'ingénierie. Ajouter un nouveau type de section ou remplacer un composant hero était plus rapide qu'en génération 2, mais restait un ticket de sprint.

Génération 4 : le Frontend as a Service (FaaS) (2023 à 2026)

Le Frontend as a Service déplace le frontend d'une chose que l'équipe assemble vers une chose qu'une plateforme exploite. Une Frontend Management Platform (FMP) livre le storefront, l'éditeur visuel et le pipeline de release comme un seul produit géré et hébergé en UE. Le marketing modifie les sections directement dans Studio, l'ingénierie garde la responsabilité du design system et de la couche d'intégration, pas de chaque changement de contenu. C'est le modèle FaaS commerce : le composable reste vrai en dessous (backend, recherche et PIM restent interchangeables), tandis que la couche frontend passe d'une chose que votre équipe construit à un service sur lequel votre équipe s'appuie.

Les quatre générations en un coup d'œil

Ce que ce changement de modèle opérationnel signifie vraiment pour les équipes

C'est une évolution du frontend commerce autant dans l'ownership que dans la technologie. Des générations 1 à 3, la réponse à « qui peut modifier le frontend » a presque toujours été : l'ingénierie. En génération 4, cette question se divise : l'ingénierie possède la plateforme, les intégrations et le design system via une composable digital experience platform, tandis que le marketing prend en charge le contenu quotidien du storefront. Cette division devient plus importante dès que les outils agentiques entrent en jeu : une agentic frontend management platform peut proposer des modifications de section ou signaler des pages sous-performantes, mais il faut toujours un environnement gouverné et hébergé en UE pour publier le résultat sans déploiement. Pour comprendre plus en détail ce qui qualifie une plateforme de FMP, consultez ce qu'est vraiment une frontend management platform. Si vous êtes encore plus tôt dans votre recherche FaaS, notre article complémentaire parcourt la catégorie FaaS depuis sa définition.

FAQ

Qu'est-ce que le Frontend as a Service (FaaS) ? Le Frontend as a Service est la quatrième génération d'architecture de frontend commerce : le storefront, son éditeur visuel et son pipeline de release sont livrés comme un service géré et hébergé en UE plutôt que comme une codebase que votre équipe assemble et exploite elle-même.

Le FaaS est-il la même chose que le composable commerce ? Non. Le composable commerce décrit des services backend interchangeables (moteur de commerce, recherche, PIM, CMS). Le FaaS décrit la manière dont la couche frontend au-dessus de ces services est exploitée. Un frontend composable peut rester construit en interne, un frontend FaaS est géré pour vous, les deux catégories se complètent plutôt qu'elles ne s'opposent.

Perdons-nous en flexibilité en passant à un frontend géré ? Pas côté backend. Votre backend commercetools, Shopify ou Shopware reste aussi interchangeable qu'en génération 3. Ce qui change, c'est que votre équipe cesse de maintenir l'infrastructure frontend et configure à la place une plateforme.

Comment le FaaS s'intègre-t-il avec un backend commercetools ou Shopify existant ? Les plateformes FaaS se connectent aux backends composable existants via des API, comme le ferait un frontend sur mesure de génération 3. La différence : la couche de connexion, l'hébergement et l'éditeur sont déjà construits et maintenus, ce qui limite le travail d'intégration à votre catalogue et votre logique de checkout spécifiques plutôt qu'à l'ensemble du stack frontend.

À quoi ressemble un replatforming vers la génération 4 en pratique ? Cela commence généralement par les templates à plus fort trafic (liste produits, fiche produit, landing pages), migrés section par section plutôt qu'en bascule big-bang, pendant que le frontend existant continue de servir le trafic. La plupart des équipes conservent leur backend et leurs intégrations de recherche inchangés pendant la transition.

Prochaine étape

Si votre équipe ouvre encore des tickets pour chaque modification de section sur un frontend de génération 2 ou 3, le moyen le plus rapide de voir la génération 4 en pratique est de découvrir la plateforme Frontend as a Service.