Commerce composable : définition, architecture et méthode pour migrer depuis un monolithe

Le commerce composable désigne une architecture e-commerce assemblée à partir de solutions spécialisées (plateforme commerce, CMS, PIM, moteur de recherche, paiement…), reliées entre elles par des API. Chaque brique assure une fonction et peut être remplacée sans reconstruire le reste du système. Le front-end est découplé du back-end : c'est le principe du headless commerce.

Sommaire

• 1. Quelles sont les différence entre monolithe, headless, composable, microservices ?
  • Le monolithe
  • Le headless commerce
  • Le commerce composable
  • Les microservices
  • Tableau comparatif
• 2. Les architectures hybrides qui restent des monolithes
  • Le cas Shopify
• 3. Pourquoi passer à un e-commerce composable ?
• 4. L'architecture type d'un commerce composable
  • Les briques
  • Le rôle du Back for Front
  • L'hébergement du front
  • L'architecture réelle : trois générations qui cohabitent
• 5. Quels sont les points de friction d'un projet de headless commerce ?
  • 5.1 Le front-end
  • 5.2 La dispersion des données
  • 5.3 La multiplication des licences
  • 5.4 L'organisation
• 6. Quelle solution choisir : les acteurs du marché
• 7. Comment migrer vers un e-commerce composable : méthode et recommandations
  • Les étapes
  • Recommandations pour la direction
  • Ce qui change pour chaque métier
• 8. Quelles sont les questions à trancher avant de démarrer ?
• 9. FAQ
  • Quelle différence entre headless commerce et commerce composable ?
  • Le commerce composable est-il réservé aux grandes entreprises ?
  • Combien de temps dure une migration vers un e-commerce composable ?
  • Peut-on conserver son ERP dans une architecture composable ?
  • Shopify est-il une solution composable ?
  • Comment éviter l'explosion des coûts de licences ?
• Kaliop, partenaire de vos projets de commerce composable

1. Quelles sont les différence entre monolithe, headless, composable, microservices ?

Le monolithe

Un monolithe réunit dans un même logiciel le front-office et le back-office. Magento, PrestaShop, WordPress/WooCommerce ou Drupal en sont des exemples côté open source. Le back-office permet de gérer produits, contenus, promotions, stocks, commandes, livraisons et comptes B2B avec peu de code. Chaque nouvelle fonctionnalité s'ajoute au même socle, qui grossit au fil des versions et ne se découpe pas.
Les connecteurs vers des solutions tierces passent toujours par le monolithe. Magento, par exemple, a besoin d'importer et de dupliquer produits, prix et stocks, car c'est lui qui génère le front.
Les solutions SaaS tout-en-un fonctionnent sur le même modèle. Shopify, utilisé avec un thème, fournit back-office, front-office et hébergement. Changer de solution impose alors de tout migrer.

Le headless commerce

Le headless commerce sépare la couche de présentation (le site, l'application mobile) de la couche métier (catalogue, panier, commande). Le front-end est développé avec un framework JavaScript (React, Vue, Svelte) et consomme les données du back-end par API. Le front peut évoluer sans toucher au back-end, et inversement.

Le commerce composable

Le commerce composable va plus loin : il applique une logique « best of breed ». On sélectionne pour chaque fonction la solution spécialisée la plus adaptée (commerce, CMS, PIM, recherche, fidélité, paiement) et on compose l'architecture avec ces briques. La condition pour parler de composable : chaque solution doit rester interchangeable. On doit pouvoir remplacer un moteur de recherche sans modifier le front ni les autres briques.

Le commerce composable est souvent associé aux principes MACH (Microservices, API-first, Cloud-native SaaS, Headless), promus depuis 2020 par la MACH Alliance, qui réunit éditeurs et intégrateurs, dont commercetools et Contentful parmi les membres fondateurs. Dans les faits, une architecture composable repose surtout sur des solutions SaaS branchées par API. Les microservices développés sur mesure n'y sont présents que pour des besoins ciblés.

Les microservices

Une architecture microservices découpe les fonctions métier en services développés sur mesure et déployés indépendamment. Elle se justifie quand aucune solution du marché ne répond au besoin, ou quand une fonction exige une scalabilité propre : un calcul de prix ou de disponibilité qui doit tenir une charge dix fois supérieure au reste du système, un déploiement du back-end sur plusieurs zones géographiques. En e-commerce, ce besoin concerne surtout les acteurs de premier plan à très fort trafic international. On le rencontre davantage sur des applications métier complexes.

Tableau comparatif

Aucun de ces modèles n'est supérieur aux autres dans l'absolu. Beaucoup d'entreprises restent sur un monolithe qui correspond à leur modèle économique. D'autres passent au composable, puis reviennent en arrière quand la migration a été mal préparée.

2. Les architectures hybrides qui restent des monolithes

Plusieurs configurations sont présentées comme composables alors qu'elles conservent un couplage fort entre le front et le back.

• La plateforme e-commerce porte le front et se connecte à un CMS headless. Exemple : Shopify avec Contentful ou Strapi. Le front dépend toujours de la plateforme commerce, et le contenu produit dans le CMS a été structuré pour Shopify. Il sera difficile à réutiliser avec une autre plateforme.
• Le CMS porte le front et se connecte à des API commerce. Exemple : Drupal ou Adobe Experience Manager. Cette configuration se retrouve chez les entreprises dont l'historique est d'abord éditorial. Le couplage entre le CMS et le reste du système reste fort.
• Les storefronts sur étagère. Alokai (ex-Vue Storefront) ou Hydrogen, le framework React de Shopify, fournissent listings, fiches produits et panier prêts à l'emploi. En pratique, Hydrogen ne se connecte qu'à Shopify, et Alokai se branche difficilement à d'autres back-ends. Changer de plateforme revient à refaire le front.

Le cas Shopify

Shopify propose trois modes d'intégration :

• un mode monolithique, avec un thème personnalisé en Liquid, le moteur de templates de Shopify ;
• Hydrogen, qui permet de développer le front en React mais reste lié à Shopify ;
• un mode headless, où Shopify expose ses API à un front indépendant. C'est dans ce seul cas qu'on peut parler d'e-commerce composable.

3. Pourquoi passer à un e-commerce composable ?

Les projets composables démarrent rarement de zéro. Ils succèdent presque toujours à un monolithe qui a atteint ses limites. Les déclencheurs les plus fréquents :

• une dette technique accumulée au fil des versions et des plugins ;
• une stratégie multimarque difficile à porter sur une seule instance ;
• une ouverture à l'international (langues, devises, catalogues, règles fiscales) ;
• un volume de développements spécifiques élevé, parce que le modèle économique de l'entreprise s'écarte de ce que propose la solution standard ;
• des performances front insuffisantes.

Les bénéfices attendus d'une architecture composable :

• faire évoluer ou remplacer une brique sans refonte globale ;
• choisir pour chaque fonction la solution la plus avancée du marché ;
• exposer une API unique réutilisable par le site, l'application mobile, d'autres marques ou des partenaires ;
• maîtriser les performances front (rendu serveur, cache, Core Web Vitals) ;
• faire cohabiter l'existant (ERP, briques legacy) avec des solutions récentes.

La migration peut se faire en big bang ou progressivement. Certaines entreprises ont passé deux ans à tout reconstruire avant la mise en production. D'autres remplacent le monolithe fonction par fonction. Kaliop recommande la seconde approche (voir section 8).

4. L'architecture type d'un commerce composable

Les briques

Le rôle du Back for Front

Le Back For Front (ou API Gateway) fait le lien entre les fronts et l'ensemble des API. Sans cette couche, le front interroge directement le CMS, la plateforme commerce et le moteur de recherche : on recrée une dépendance forte entre front et back, donc un monolithe distribué. Le BFF permet de brancher ou débrancher une solution sans impact sur le front. Il protège aussi les systèmes lents par du cache : un ERP interrogé pour les prix et les stocks ne supporte généralement pas le trafic d'un site e-commerce.

L'hébergement du front

En headless, le front n'est plus hébergé par la solution e-commerce. Trois options :

• les services managés du cloud déjà utilisé par l'entreprise (AWS, GCP, Azure, Scaleway) ;
• un hébergeur spécialisé front-end : Vercel, Netlify, AWS Amplify, Cloudflare ;
• le cluster Kubernetes de l'entreprise, si les équipes internes l'opèrent déjà et imposent leurs règles de sécurité.

L'architecture réelle : trois générations qui cohabitent

Dans les projets que nous accompagnons, une architecture composable combine généralement :

• des solutions SaaS récentes, conçues pour le headless ;
• des systèmes legacy branchés en SOAP, ou par import-export de fichiers quand il n'y a pas d'API ;
• un monolithe conservé pour une ou deux fonctions, le temps de les remplacer ;
• quelques microservices développés pour un besoin de calcul précis, par exemple la disponibilité en temps
• réel sur des millions de combinaisons dans l'hôtellerie.

5. Quels sont les points de friction d'un projet de headless commerce ?

Les retours recueillis auprès d'e-commerçants en cours de migration font ressortir des situations récurrentes :

• une refonte livrée par un prestataire, suivie de trois ans de reprise ;
• une équipe technique qui développe son propre back-office, faute de savoir où gérer certaines fonctions comme les redirections ;
• un CTO qui ouvre plusieurs chantiers en parallèle sans mise en production ;
• des équipes marketing qui perdent les outils SEO et le back-office unique dont elles disposaient avec le monolithe.

Ces situations s'expliquent par quatre sources de friction.

5.1 Le front-end

Le front-end est souvent perçu comme la partie la plus simple du projet. Il concentre pourtant une large part des difficultés : performances inférieures aux attentes, délais d'affichage liés au cache, montées de version tous les six mois (Vue 2 vers Vue 3, Nuxt 3 vers Nuxt 4, nouvelles versions de React), vélocité en baisse.
Avec un monolithe, la technologie front était imposée (Twig pour Drupal, le moteur de templates de Magento). En headless, les décisions reviennent à l'équipe :

• le framework d'interface : React, Vue, Svelte ou Angular ;
• le framework de rendu serveur : Next.js, Nuxt ;
• la stratégie de génération : site statique, rendu serveur ou hybride (Astro, Gatsby, Hugo) ;
• la stratégie de style et de composants ;
• l'outillage : TypeScript, Storybook pour documenter le design system, Jest et Playwright pour les tests ;
• l'hébergement et son modèle de tarification.

Ces choix engagent la roadmap sur plusieurs années. Laissés à un développeur sans cadrage d'un directeur technique, ils produisent la dette technique constatée deux ou trois ans plus tard.
Le périmètre du développeur front s'est aussi élargi : Core Web Vitals, SEO, accessibilité, RGPD, écoconception, Progressive Web Apps, intégration de l'IA dans les outils de développement. Le métier s'est spécialisé entre profils orientés interface et composants, et profils orientés intégration des API, cache et architecture front. Trois facteurs aggravent la situation : des équipes qui passent de Magento à React ou Vue en quelques mois, des contrats au forfait qui privilégient le résultat visible au détriment de la qualité du code, et l'absence d'arbitrage technique.

5.2 La dispersion des données

Dans un commerce composable, la donnée produit traverse plusieurs systèmes avant d'arriver sur la fiche produit, les listings ou les recommandations :

• l'ERP fournit le catalogue brut, les prix et les stocks, souvent par export de fichiers ou en SOAP ;
• le PIM enrichit les produits (descriptions, images, catégories) pour tous les canaux ;
• le CMS permet à l'équipe e-merchandising de créer des landing pages et d'ajouter des vidéos ou des call-to-action absents du PIM ;
• la plateforme commerce gère les données de vente : titre, SKU, variantes, prix, stocks, moteur de remises ;
• le moteur de recherche agrège l'ensemble pour l'autocomplétion, les listings et les filtres.

Des contournements apparaissent en cours de projet :

• un catalogue ERP incomplet, complété par des fichiers annexes ;
• une arborescence PIM trop administrative pour la saisonnalité commerciale : pour la fête des mères, par exemple, le marketing a besoin de créer des catégories rapidement ;
• une gestion des images qui impose l'ajout d'un outil de redimensionnement et de conversion à la volée ;
• un rapprochement des comptes clients entre l'e-commerce, le CRM et les achats en boutique, pour l'omnicanal ;
• un moteur de remises natif qui ne couvre pas toutes les règles de fidélité ou la précision des messages à l'utilisateur (« votre code a expiré il y a une semaine »).

Chacun de ces cas génère du développement spécifique non prévu. La réponse passe par une gouvernance des données définie en amont : le rôle de chaque brique, l'emplacement de référence de chaque donnée, et la raison de ce choix.

5.3 La multiplication des licences

Une architecture composable réunit plusieurs éditeurs, chacun avec son modèle de tarification : nombre d'appels API, trafic, commandes, utilisateurs, chiffre d'affaires. Tenir un budget de licences sur trois ans suppose de connaître ces modèles, les roadmaps des éditeurs et l'impact de chaque fonctionnalité sur la facture.
Exemple : un moteur de recherche est d'abord utilisé pour la seule autocomplétion, les listings étant gérés par la plateforme commerce. L'équipe marketing découvre la fonction de search merchandising, qui permet de remonter certains produits dans une catégorie par glisser-déposer. Le moteur de recherche prend alors en charge tous les listings, filtres et paginations. Le nombre d'appels est multiplié par cent ou par mille, et la facture suit. Celle de la plateforme commerce ne baisse pas pour autant.
Cette compétence se situe entre les achats, la finance et la technique. Elle revient généralement à la direction technique, avec un profil habitué à la négociation.

5.4 L'organisation

Chaque équipe avance à son rythme : l'IT sur l'ERP et le PIM, le marketing sur des campagnes à la journée, les achats sur des budgets annuels, la data sur sa propre roadmap. Le composable rend ces écarts visibles.
Le CDN en est un exemple. L'IT le considère comme un point d'entrée de sécurité (anti-DDoS, WAF, certificats). L'équipe e-commerce en a besoin pour invalider le cache, gérer les redirections et traiter les images. Le marketing revendique la gestion des redirections. Les achats s'inquiètent d'une facturation au trafic, difficile à prévoir.
S'y ajoute une dimension RH : des équipes qui travaillent depuis longtemps en PHP abordent un nouvel environnement technique, avec des réactions variables selon les personnes. Frictions techniques et frictions organisationnelles s'alimentent mutuellement : la dette technique complique les décisions, et les décisions prises dans l'urgence créent de la dette technique.

6. Quelle solution choisir : les acteurs du marché

Le tableau ci-dessous présente les principales plateformes commerce et quelques briques fréquentes dans un e-commerce composable. Le choix dépend du modèle économique, du périmètre fonctionnel, des compétences internes et du modèle de tarification de chaque éditeur (voir section 5.3).
 

Kaliop réalise des missions de conseil en sélection de solutions avant toute phase d'intégration, y compris sur des solutions dont elle n'est pas partenaire.

7. Comment migrer vers un e-commerce composable : méthode et recommandations

Les étapes

1. Audit de l'existant. Cartographier la stack, la dette technique, les performances (Core Web Vitals, disponibilité), les coûts d'exploitation et les flux de données. Identifier les limites concrètes qui justifient la migration.
2. Architecture cible. Sélectionner les solutions par couche, concevoir le BFF, définir la gouvernance des données et les flux. Livrables : schéma d'architecture, budget de licences et d'exploitation sur trois ans, feuille de route.
3. Pilote. Démarrer sur un périmètre limité (une marque, un pays, une gamme) pour valider les choix techniques et les modes d'intégration.
4. Migration progressive. Remplacer le monolithe fonction par fonction, en le laissant fonctionner en parallèle pendant la transition (strangler pattern), jusqu'à son décommissionnement.
5. Exploitation et évolution. Suivre les performances en production, les montées de version front et API, et les coûts cloud et licences (FinOps).

Recommandations pour la direction

• Préparer l'organisation pendant quelques semaines à quelques mois avant de lancer le projet : rôles, circuits de décision, alignement des roadmaps.
• S'appuyer sur un regard externe agnostique pour les choix d'architecture, qui ne soit pas lié à un éditeur ou à un modèle d'architecture.
• Mobiliser des experts de chaque solution une fois celle-ci choisie : ateliers techniques, spécifications, revue de code.
• Migrer progressivement plutôt qu'en big bang. Des mises en production régulières démontrent la capacité de l'équipe à livrer et évitent d'attendre deux ans un résultat qui pourrait décevoir.

Ce qui change pour chaque métier

8. Quelles sont les questions à trancher avant de démarrer ?

• Quelles fonctions du monolithe migrer en premier, et lesquelles conserver temporairement ?
• Quelle brique est la référence pour chaque donnée : produit, catégorie, prix, stock, client, remise ?
• Qui arbitre les choix front-end, et selon quels critères ?
• Qui possède le CDN, les redirections et le SEO technique ?
• Quel budget de licences sur trois ans, avec quelles hypothèses de trafic et de croissance ?
• Où héberger le front, et qui l'opère ?
• Quelles compétences internes former, recruter ou compléter par un partenaire ?

9. FAQ

Quelle différence entre headless commerce et commerce composable ?

Le headless commerce désigne le découplage entre le front-end et le back-end. Le commerce composable applique ce découplage à l'ensemble de l'architecture : chaque fonction est assurée par une solution spécialisée et remplaçable. Une architecture composable est headless. Une architecture headless n'est pas forcément composable, si le back-end reste un monolithe.

Le commerce composable est-il réservé aux grandes entreprises ?

Il concerne les organisations dont les besoins dépassent ce qu'un monolithe permet de faire : multimarque, international, développements spécifiques nombreux. Il demande des compétences et un budget de licences supérieurs à ceux d'un monolithe. Les microservices, eux, restent réservés aux acteurs à très fort trafic.

Combien de temps dure une migration vers un e-commerce composable ?

Cela dépend du périmètre et de l'approche. Une migration progressive permet de mettre en production une première brique en quelques mois, puis de remplacer les autres fonctions par étapes. Un big bang peut mobiliser les équipes pendant deux ans avant la première mise en production.

Peut-on conserver son ERP dans une architecture composable ?

Oui. L'ERP reste en général en place, car il gère des fonctions au-delà du digital : entrepôts, boutiques physiques, facturation. Il est branché via API, SOAP ou échanges de fichiers, avec une couche de cache pour absorber le trafic du site.

Shopify est-il une solution composable ?

Seulement en mode headless, quand ses API alimentent un front indépendant. Utilisé avec un thème Liquid ou avec Hydrogen, Shopify reste un fonctionnement monolithique.

Comment éviter l'explosion des coûts de licences ?

En modélisant les coûts sur trois ans pour chaque éditeur, en identifiant les métriques de facturation (appels API, trafic, commandes) et en évaluant l'impact de chaque nouvelle fonctionnalité avant de l'activer.

Kaliop, partenaire de vos projets de commerce composable

Kaliop accompagne depuis plus de vingt ans des entreprises dans leurs projets e-commerce, de l'architecture à l'exploitation, parmi lesquelles Interflora, Accor, Cromology, Yelloh! Village, Aroma-Zone et Café Royal. Nos équipes interviennent sur l'ensemble de la chaîne : conseil en architecture, développement front-end et back-end en JavaScript full stack, intégration des solutions headless (commercetools, dont Kaliop est partenaire Platinum, Contentful, Algolia…), cloud et Kubernetes. 

Vous avez un projet e-commerce ou souhaitez faire évoluer votre plateforme ? Contactez nos équipes pour échanger sur vos enjeux et vos besoins.