Le commerce composable en B2B : quand c'est pertinent et quand ça ne l'est pas

Sur un tableau blanc, le commerce composable est convaincant : pour chaque tâche le meilleur outil, relié par API, remplaçable dès qu’il existe mieux. Pour une équipe B2B sur SAP Commerce Cloud, la question utile est plus précise. Quelles parties de votre boutique gagnent à être indépendantes, et votre équipe peut-elle assumer les pièces mobiles supplémentaires ?

Ce guide répond à cette question. Il distingue le headless du composable, montre comment SAP Commerce Cloud prend en charge les deux et se termine par les questions de décision que nous utilisons dans nos évaluations d’architecture. Les principes techniques derrière ces termes sont expliqués dans notre article sur l’architecture MACH dans SAP Commerce Cloud.

En bref : le headless sépare la vitrine du moteur commerce ; le composable remplace en plus certaines fonctions, comme la recherche, le CMS ou les paiements, par des services spécialisés. Sur SAP Commerce Cloud, les deux passent par les API OCC. Le composable se justifie avec une forte ambition UX, plusieurs vitrines ou des mises en production front-end fréquentes. C’est le mauvais choix pour une petite équipe, un délai serré ou un simple portail de réassort. Notre approche par défaut : SAP Commerce Cloud comme cœur, Composable Storefront ou un front-end sur mesure, et des services spécialisés ajoutés un à un.

Headless, composable, MACH : trois notions différentes

Ces termes sont souvent employés comme synonymes. Ils répondent pourtant à des questions différentes.

Headless répond à : comment ma vitrine communique-t-elle avec mon moteur commerce ? Uniquement par API. Le back-end ne génère pas de pages, le front-end n’accède pas à la base de données. Vous pouvez ainsi construire la vitrine avec le framework de votre choix, publier front-end et back-end indépendamment et servir le web, une application et des bornes depuis le même back-end. Cela implique aussi des développeurs front-end, une couche API avec authentification et gestion des versions, ainsi qu’un pipeline et une supervision propres au front-end.

Composable répond à : comment assembler l’ensemble de la pile ? Au lieu d’une suite qui fait tout, vous choisissez des services spécialisés pour la recherche, les contenus, les paiements ou la personnalisation, reliés par API. Chacun peut être remplacé sans reconstruire le reste.

MACH (Microservices, API-first, Cloud-native, Headless) décrit les principes techniques qui rendent le composable possible. Il faut des briques de type MACH pour construire de façon modulaire, mais les utiliser ne rend pas automatiquement composable.

On peut donc être headless sans être composable (une vitrine React sur un moteur commerce intégré) et composable sans être headless (une boutique rendue côté serveur qui appelle un service de recherche externe). La plupart des projets SAP Commerce Cloud se situent aujourd’hui entre les deux : vitrine découplée, cœur commerce intégré et deux ou trois services spécialisés.

Comment SAP Commerce Cloud prend en charge les deux

SAP Commerce Cloud est headless par conception et composable en périphérie.

API REST OCC. Produits, catégories, paniers, checkout, commandes et clients sont exposés comme points de terminaison REST. Tout front-end ou système externe peut les appeler, et vos propres extensions permettent d’ajouter des points de terminaison. Sans cette couche, le composable resterait un transparent de présentation.

Composable Storefront. La vitrine Angular de SAP (anciennement Spartacus) ne communique avec Commerce Cloud que via OCC. Vous pouvez l’étendre ou la remplacer par React ou Next.js sans toucher au moteur commerce. SAP la documente dans le guide Composable Storefront sur SAP Help. En septembre 2026, SAP a aussi annoncé un partenariat avec Vercel pour des vitrines Next.js sur Commerce Cloud ; nous comparons les options front-end dans Composable Storefront ou React/Next.js.

Extensions side-by-side sur SAP BTP. Une logique propre, comme une règle de prix particulière ou un service de recommandation, peut tourner sur SAP BTP et être appelée par Commerce Cloud, au lieu d’être intégrée au cœur.

Services spécialisés en périphérie. Recherche (Solr intégré ou service externe), gestion de contenu (SmartEdit ou CMS headless), paiements via des intégrations de passerelles, SAP Engagement Cloud (anciennement SAP Emarsys) pour l’automatisation marketing et SAP Customer Data Cloud pour l’identité et les consentements.

Ce que Commerce Cloud n’est pas : un ensemble de microservices déployables indépendamment. Panier, calcul des prix, promotions et commandes fonctionnent comme une seule plateforme. En B2B, c’est généralement un avantage, car c’est précisément là que se trouvent les prix contractuels, les hiérarchies clients et le lien avec l’ERP.

Quand le composable a-t-il du sens en B2B ?

Le composable se justifie dans trois situations. Si aucune ne vous correspond, la complexité supplémentaire n’en vaut probablement pas la peine.

La vitrine fait partie de votre marque, ce n’est pas qu’un catalogue. Si vos acheteurs doivent trouver un configurateur de produits, des contenus riches ou une sélection guidée plutôt qu’une liste avec un bouton de commande, un front-end découplé donne à vos designers et développeurs une marge que les modèles standard n’offrent pas.

Vous exploitez plusieurs vitrines. B2B et B2C, plusieurs marques ou pays sur un même cœur commerce : le découplage permet à chaque expérience d’évoluer séparément, tandis que prix, stocks et commandes restent au même endroit.

Vous publiez sans cesse des changements front-end. Quand le métier demande des modifications plusieurs fois par semaine, des cycles de mise en production séparés suppriment l’attente des déploiements back-end. Distrelec en est notre référence : après le découplage de son front-end de SAP Commerce Cloud, le délai de mise sur le marché des changements front-end a baissé de 70 %.

Quand le composable est-il le mauvais choix ?

Pas de développeurs front-end dédiés. Un front-end sur mesure est une application JavaScript que quelqu’un doit construire et maintenir. Si votre équipe se compose surtout de développeurs SAP et back-end, vous passerez plus de temps sur la pile front-end que sur les fonctions commerce.

Un délai serré. Choisir les composants, les relier et construire les pipelines prend du temps avant la première commande. Dans nos évaluations, cela représente plusieurs semaines de plus qu’un démarrage intégré. Avec une date de mise en service ferme, commencez avec Composable Storefront.

Un cas d’usage simple. Un portail de réassort aux fonctions B2B standard n’a pas besoin d’un front-end sur mesure. Composable Storefront le couvre, et le budget est mieux investi dans des prix justes et une intégration ERP qui fonctionne.

Par où commencer

Ne décomposez pas tout d’un coup. Commencez là où le bénéfice pour les acheteurs est le plus grand et le risque pour le flux de commande le plus faible.

Ordre	Composants	Pourquoi ici
Commencer ici	Recherche, paiements, analytique commerce	Bénéfice visible, interfaces claires, retour arrière facile
Ensuite	CMS headless à côté de SmartEdit, personnalisation, automatisation marketing (p. ex. SAP Engagement Cloud)	Suppose des données propres et des processus de contenu en place
Plus tard	Vitrine entièrement sur mesure, PIM propre au lieu du contenu produit intégré, fonctions déplacées vers des services BTP	Effort maximal, touche le flux de commande

Pendant ce temps, gardez le cœur commerce stable : panier, checkout, calcul des prix, commandes et gestion des produits restent dans Commerce Cloud. Validez chaque nouvelle intégration avant d’ajouter la suivante.

Les risques qui n’apparaissent sur aucun transparent

Effort d’intégration. Chaque composant ajoute une interface, un contrat et un cycle de mise à jour. Cinq services, ce sont cinq fournisseurs et cinq points de défaillance possibles. Le code de liaison entre eux peut coûter plus cher que n’importe quel composant.

Exploitation. Superviser une plateforme est une routine. En superviser dix exige du traçage distribué, des alertes entre fournisseurs et une équipe capable de trouver la panne quand une commande reste bloquée entre deux systèmes. C’est une autre compétence que le développement commerce classique.

La dépendance se déplace, elle ne disparaît pas. Vous ne dépendez plus d’un seul fournisseur, mais de votre couche d’intégration. Si le code de liaison est complexe, remplacer un composant est plus difficile que ne le promettent les brochures.

Les meilleurs composants ne font pas automatiquement le meilleur ensemble. La meilleure recherche, le meilleur CMS et le meilleur prestataire de paiement ne produisent pas d’eux-mêmes la meilleure expérience d’achat. Ce qui compte, c’est leur fonctionnement commun sur une vraie commande.

Après la fin de l’on-premise : trois voies

La maintenance standard de SAP Commerce on-premise (dernière version 2205) a pris fin le 31 juillet 2026 ; depuis, seule une maintenance spécifique au client est disponible (SAP Help). Pour beaucoup d’équipes, c’est le moment de se poser la question du composable. Il existe trois voies réalistes :

Voie	Ce qu’elle signifie	Notre ordre de grandeur de planification	Convient lorsque
SAP Commerce Cloud	Porter la logique existante sur la plateforme exploitée par SAP	Environ 3 à 6 mois	Les adaptations sont liées aux modèles de données SAP, l’équipe connaît SAP Commerce
Hybride	Commerce Cloud comme cœur, front-end sur mesure découplé, services spécialisés au fil du temps	Environ 4 à 8 mois	Vous voulez de la liberté côté front-end sans réimplémenter la logique commerce
Entièrement composable	Remplacer la plateforme par des services distincts pour le commerce, les contenus, la recherche et les commandes	Souvent 9 à 15 mois	Équipe interne solide, paysage API-first, exigences inhabituelles

Ces fourchettes proviennent de nos propres évaluations et dépendent du périmètre ; ce n’est pas une offre. La plateforme Franke montre ce qu’un périmètre ciblé permet : Spadoom a mis en production la plateforme SAP Commerce Cloud en 90 jours, un chiffre qui se rapporte à ce lancement commerce. Si vous êtes encore on-premise, notre article sur ce qu’il faut faire maintenant que le support on-premise a pris fin présente les prochaines étapes.

Une reconstruction entièrement composable implique de réimplémenter des années de règles promotionnelles, de calcul de prix et de logique B2B que Commerce Cloud conserve. Cela seul représente souvent un projet plus important que toute la migration vers le cloud.

Comment décider ?

Six questions. Répondez-y pour l’équipe que vous avez aujourd’hui, pas pour celle que vous espérez.

1. Disposez-vous d’au moins deux développeurs front-end dédiés ? Sinon, démarrez en intégré.
2. Avez-vous besoin de plusieurs vitrines distinctes ? Si oui, le composable a de solides arguments.
3. Votre mise en service est-elle dans moins de six mois ? Si oui, démarrez en intégré.
4. La vitrine distingue-t-elle votre marque ou est-ce un outil fonctionnel ? Si elle distingue la marque, découplez-la. Si c’est un outil, restez en intégré.
5. Vos systèmes ERP, PIM et logistiques offrent-ils déjà des API propres ? Si les données circulent encore par fichiers batch et tableurs, le composable ajoute de la complexité sans son principal avantage.
6. Pouvez-vous assumer pendant des années plusieurs relations fournisseurs et un front-end sur mesure ? Le composable n’est pas un chantier ponctuel.

Pour la plupart des projets B2B sur SAP Commerce Cloud, notre recommandation reste la même : démarrer en intégré, découpler le front-end là où cela aide, puis modulariser davantage à mesure que l’équipe et les exigences grandissent. Les API OCC gardent cette option ouverte sans toucher au moteur commerce. Quelle que soit la voie choisie, la commande doit arriver correctement dans l’ERP. C’est pourquoi nous planifions la vitrine et l’intégration ERP avec une seule équipe, comme décrit dans notre article sur une boutique B2B sur SAP Commerce Cloud avec S/4HANA Public Cloud. Si vous comparez des plateformes au-delà de SAP, lisez notre comparaison SAP, Salesforce et Adobe Commerce.

---

Vous voulez savoir quelle approche correspond à votre situation ? Nos évaluations d’architecture examinent votre équipe, votre calendrier, votre paysage ERP et vos exigences. Parlez à nos architectes commerce ou découvrez nos services SAP Commerce Cloud.

Questions fréquentes

Quelle est la différence entre commerce headless et commerce composable ?

Le headless sépare la vitrine (storefront) du back-end commerce, qui ne communiquent que par API. Le composable va plus loin : recherche, contenus, paiements ou personnalisation deviennent des services distincts et remplaçables. Toute architecture composable est headless, mais une vitrine headless reposant sur un moteur commerce intégré n’est pas composable. SAP Commerce Cloud prend en charge les deux via ses API REST OCC.

SAP Commerce Cloud est-il headless ou composable ?

Il est headless par conception et composable en périphérie. Les API OCC exposent produits, paniers, checkout, commandes et clients à n’importe quel front-end, et la recherche, le CMS, les paiements ou le marketing peuvent être des services externes. Le cœur commerce (panier, prix, promotions, commandes) reste une plateforme intégrée, pas un ensemble de microservices déployés indépendamment.

Peut-on démarrer avec Composable Storefront et passer plus tard à une architecture entièrement composable ?

Oui, et c’est ce que nous recommandons pour la plupart des projets B2B. Composable Storefront utilise les mêmes API OCC que tout front-end sur mesure : un passage ultérieur à React ou Next.js laisse intacts la configuration commerce, le modèle de données et l’intégration ERP. Remplacez un composant à la fois, en commençant par celui qui pose le plus de problèmes.

De combien de développeurs une architecture composable a-t-elle besoin ?

Prévoyez deux à trois développeurs front-end dédiés, un à deux développeurs commerce ou intégration, et une personne responsable du DevOps et de la supervision sur plusieurs pipelines de déploiement. Une architecture intégrée avec Composable Storefront fonctionne souvent avec une équipe plus réduite de développeurs SAP Commerce. Il faut aussi quelqu’un qui porte l’architecture d’ensemble.

Le commerce composable coûte-t-il plus cher qu’une architecture intégrée ?

Au départ, oui : le choix des composants, le travail d’intégration et les pipelines supplémentaires coûtent des semaines et du budget avant la première commande. Sur trois à cinq ans, l’investissement peut se justifier si vous changez réellement de composants ou exploitez plusieurs vitrines. Le principal facteur de coût n’est pas la licence, mais l’intégration et l’exploitation : chaque service ajouté apporte son contrat, son cycle de mise à jour et ses propres pannes possibles.

Qu’est-ce qui a changé pour les clients on-premise après le 31 juillet 2026 ?

La maintenance standard (mainstream maintenance) de SAP Commerce on-premise, dont la dernière version est la 2205, a pris fin le 31 juillet 2026 ; seule une maintenance spécifique au client reste disponible. Passer à SAP Commerce Cloud conserve la logique métier et les modèles de données existants, alors qu’une reconstruction entièrement composable oblige à les réimplémenter. Une voie médiane fréquente : Commerce Cloud comme cœur, avec un front-end découplé.