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

Le commerce composable est brillant sur un tableau blanc. Choisir le meilleur outil pour chaque tâche. Les câbler ensemble. Remplacer des pièces dès que quelque chose de mieux arrive. Je comprends. Le concept est élégant.

Mais si vous êtes une équipe B2B qui fait tourner SAP Commerce Cloud, le tableau blanc ne paie pas les factures. La vraie question est de savoir si les compromis fonctionnent réellement dans votre situation. Le marché mondial de l’e-commerce B2B pèse 32,1 billions de dollars, avec une croissance annuelle de 14,5 % (Statista, 2025). Votre choix d’architecture compte donc. Mais « composable pour tout le monde » est la mauvaise réponse.

TL;DR : 76 % des organisations prévoient d’adopter le commerce composable dans les deux ans (MACH Alliance, 2024). Mais le composable n’est pas le choix par défaut pour tous les scénarios B2B. Il fonctionne quand vous avez une forte ambition UX, plusieurs vitrines, ou que vous livrez des changements frontend en permanence. Il est inadapté aux petites équipes, aux délais serrés ou aux simples portails de commande. Notre position : commencez avec SAP Commerce Cloud + Composable Storefront, puis passez au composable de manière incrémentale.

Que signifie réellement « composable » dans le contexte SAP ?

SAP est Leader du Gartner Magic Quadrant for Digital Commerce depuis 11 années consécutives (SAP News Center, 2025). En termes SAP Commerce Cloud, le composable se résume à trois couches découplées :

Le moteur de commerce (SAP Commerce Cloud) gère le contenu produit, la tarification, la gestion des commandes et le stock. Une vitrine découplée se place devant : Composable Storefront (l’ancien Spartacus), une application React/Vue.js sur mesure, ou une DXP comme Contentful. Puis une couche d’expérience gère la personnalisation, les tests A/B et la gestion de contenu via des outils dédiés.

Ce qui rend tout cela possible, c’est la couche API OCC (Omnichannel Commerce) de SAP Commerce Cloud. Chaque capacité commerce exposée en API REST. Sans cette couche, vous êtes coincé avec la pile frontend de SAP et le composable reste une jolie idée sur une slide.

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

Nous avons mené des évaluations d’architecture sur un bon nombre de projets commerce B2B à ce stade. Le composable fonctionne dans trois situations. Si aucune ne vous décrit, la complexité supplémentaire n’en vaut probablement pas la peine.

Vous voulez une vraie expérience de marque, pas un catalogue. Si votre vitrine doit être un véritable point de contact de marque, le composable donne à vos équipes design et frontend la liberté de construire exactement ce qu’elles veulent. Sans lutter contre la plateforme. 80 % des ventes B2B seront générées numériquement d’ici fin 2025 (Shopify, 2025). Les attentes des acheteurs B2B convergent rapidement vers celles du B2C. Votre vitrine ne peut plus ressembler à un tableur.

Vous exploitez plusieurs vitrines. B2B et B2C ? Plusieurs marques ou marchés ? Découpler le frontend permet à chaque expérience d’évoluer indépendamment à partir d’un noyau commerce partagé. Une instance Commerce Cloud, des frontends complètement différents. C’est là que le composable gagne vraiment sa place.

Vous livrez des changements frontend en permanence. Quand le métier a besoin de mises à jour plusieurs fois par semaine, séparer la vitrine du moteur de commerce découple les cycles de release. Les mises à jour backend suivent leur propre calendrier. Le frontend déploie quand vous voulez. Personne n’attend personne.

Quand le composable est-il le mauvais choix ?

Votre équipe n’a pas de spécialistes frontend dédiés. Le composable nécessite des développeurs React, Angular ou Vue capables de construire et maintenir une vraie application JavaScript. Si votre équipe est surtout composée de profils SAP et backend, vous passerez plus de temps à gérer la pile frontend qu’à construire des fonctionnalités commerce.

Vous êtes pressé. Le composable prend plus de temps à livrer initialement. Une échéance à 6 mois ? Une approche basée sur l’accélérateur Composable Storefront vous y amènera plus vite. Le surcoût de mise en place du composable (choisir les composants, les câbler, construire les pipelines de déploiement) ajoute 4 à 8 semaines par rapport à un démarrage intégré. C’est du temps bien réel.

Votre cas d’usage est simple. Si vous construisez un portail de commande B2B fonctionnel avec des fonctionnalités standard, et non une expérience de marque phare, la flexibilité du composable ne justifie pas la complexité. À quoi bon un frontend React sur mesure pour un portail de réassort ? Composable Storefront gère cela nativement.

Quel est le juste milieu pragmatique ?

Pour la plupart des projets B2B SAP Commerce Cloud que nous voyons, le juste milieu l’emporte. 90 % des entreprises ayant migré leur plateforme e-commerce ont rapporté des améliorations de chiffre d’affaires (commercetools, 2024). Mais le choix d’architecture compte moins que la solidité des fondamentaux.

Voici ce que nous recommandons réellement dans la plupart des cas. Utilisez SAP Commerce Cloud comme moteur de commerce. Utilisez Composable Storefront comme accélérateur frontend, personnalisé selon vos besoins. Ajoutez Emarsys ou une DXP pour la personnalisation et la gestion de contenu. Puis passez au composable de manière incrémentale à mesure que les capacités de votre équipe et la complexité de votre activité grandissent.

Commencer intégré. Évoluer vers le composable. Ce n’est pas un compromis. C’est l’approche qui livre de la valeur le plus vite tout en gardant l’option de décomposer plus tard. La couche API OCC signifie que vous pouvez remplacer le frontend à tout moment sans toucher au moteur de commerce. Prima vista, cela ressemble à repousser le problème, mais non. C’est pragmatique.

Pour les détails sur notre mise en oeuvre de SAP Commerce Cloud, y compris la livraison de Composable Storefront, les scénarios B2B et l’architecture d’intégration, consultez notre page solution SAP Commerce Cloud.

Comment décider ?

Cinq questions. Soyez honnête avec vous-même.

1. Votre équipe compte-t-elle au moins 2 développeurs frontend dédiés ? Si non, commencez intégré.
2. Avez-vous besoin de plusieurs vitrines distinctes ? Si oui, le composable a un dossier solide.
3. Votre échéance de go-live est-elle à moins de 6 mois ? Si oui, commencez intégré.
4. La vitrine est-elle un différenciateur de marque ou un outil fonctionnel ? Différenciateur de marque : composable. Outil fonctionnel : intégré.
5. Pouvez-vous investir dans la maintenance à long terme d’un frontend sur mesure ? Le composable n’est pas une construction ponctuelle. C’est un engagement continu.

Soyons clairs, le tout-composable est véritablement la bonne réponse pour certaines entreprises. Mais ce n’est pas le choix par défaut. La bonne architecture est celle qui correspond à votre équipe, votre calendrier et votre modèle commercial.

Vous voulez déterminer quelle approche correspond à votre situation ? Nous menons des évaluations d’architecture qui analysent votre équipe, votre calendrier et vos exigences, puis recommandent l’approche qui livre de la valeur le plus vite. Échangez avec nos architectes commerce.

Questions fréquentes

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

Headless signifie séparer le frontend du backend via des API. C’est un choix architectural. Le composable va plus loin : vous choisissez des composants best-of-breed pour chaque capacité commerce (recherche, PIM, OMS, paiements) et vous les câblez ensemble. Toutes les architectures composables sont headless, mais toutes les implémentations headless ne sont pas composables. SAP Commerce Cloud supporte les deux via sa couche API OCC.

Peut-on commencer avec Composable Storefront et passer au tout-composable plus tard ?

Oui. Et c’est exactement ce que nous recommandons pour la plupart des projets B2B. Composable Storefront est construit sur Angular et consomme les API OCC de Commerce Cloud. Comme tout passe par des API, vous pouvez brancher plus tard un frontend React ou Next.js sur mesure sans toucher au moteur de commerce. Votre investissement dans la configuration Commerce Cloud, les modèles de données et les intégrations est entièrement conservé. C’est tout l’intérêt.

Combien de développeurs une architecture composable exige-t-elle ?

Une pile composable nécessite typiquement 2 à 3 développeurs frontend dédiés plus 1 à 2 développeurs backend Commerce Cloud pour la maintenance continue. Comparez cela à une approche Composable Storefront intégrée, qui peut tourner avec 1 à 2 développeurs full-stack. Il vous faut aussi des capacités DevOps pour gérer plusieurs pipelines de déploiement, configurations CI/CD et dépendances de services. Cela s’additionne vite.

Le commerce composable est-il plus cher que l’intégré ?

Initialement, oui. Le surcoût de mise en place ajoute 4 à 8 semaines et typiquement 20 à 30 % au coût initial du projet. Mais sur un horizon de 3 à 5 ans, le composable peut revenir moins cher si vous avez réellement besoin de la flexibilité. Remplacer des composants individuels coûte moins que re-plateformer toute une pile intégrée. Le point d’équilibre dépend de la fréquence d’évolution de votre frontend et du nombre de vitrines que vous exploitez.

SAP supporte-t-il l’architecture composable sur Commerce Cloud ?

SAP soutient activement les approches composables via la couche API OCC de Commerce Cloud et le framework Composable Storefront. Ses propres recommandations d’architecture positionnent Commerce Cloud comme un « moteur de commerce composable » capable de servir plusieurs expériences frontend. La couverture API de la plateforme est solide pour la plupart des scénarios B2B, même si certains cas limites peuvent nécessiter des extensions API sur mesure via SAP BTP.