SAP Composable Storefront vs React/Next.js : comment choisir

Cette question revient dans chaque atelier frontend SAP Commerce Cloud que nous animons. À gauche du tableau blanc : le SAP Composable Storefront, le frontend headless de SAP basé sur Angular. À droite : un frontend React ou Next.js sur mesure qui consomme les mêmes API OCC. La réponse dépend de cinq facteurs, et la préférence pour un framework n’en fait pas partie.

En bref : le SAP Composable Storefront vous met en ligne plus vite (environ 8 à 12 semaines pour une vitrine type), avec une large bibliothèque de composants commerce préconstruits, l’intégration de SmartEdit et le rendu côté serveur inclus. Un frontend React/Next.js sur mesure offre une liberté de design totale, davantage d’options de rendu et un vivier de développeurs plus large, mais coûte en général 40 à 60 % de plus à construire et demande 12 à 20 semaines. Choisissez le Composable Storefront pour le B2B et le B2C standard, la rapidité et l’alignement sur SAP ; choisissez React/Next.js pour des expériences B2C distinctives et des équipes React existantes. Une approche hybride (Composable Storefront comme socle, micro-frontends React pour certaines pages) combine souvent les deux.

La décision en 30 secondes

Choisissez le SAP Composable Storefront si :

• vous devez être en ligne rapidement (moins de 12 semaines) ;
• votre cas d’usage relève du commerce B2B ou B2C standard ;
• SmartEdit compte pour votre équipe de contenu ;
• vos développeurs connaissent Angular ou peuvent l’apprendre ;
• l’alignement sur la feuille de route de SAP est une priorité.

Choisissez React/Next.js si :

• une expérience utilisateur distinctive est un avantage concurrentiel central ;
• vous disposez déjà d’une solide équipe React ;
• vous avez besoin de maîtriser chaque interaction ;
• le rendu en périphérie (edge) et la régénération statique incrémentale sont importants pour vous ;
• vous prévoyez de servir plusieurs marques ou canaux avec une seule bibliothèque de composants.

Envisagez une approche hybride si vous voulez le socle commerce du Composable Storefront mais avez besoin d’expériences sur mesure pour certaines pages, comme des configurateurs de produits ou des pages de campagne.

Comparaison des architectures

Les deux approches utilisent le même backend. SAP Commerce Cloud expose ses fonctions via les API REST OCC, et la vitrine n’est qu’un consommateur d’API. C’est précisément ce découplage qui rend le choix possible.

Composable Storefront

Navigateur → Application Angular (Composable Storefront)
           ├── Composition des pages pilotée par le CMS (SmartEdit)
           ├── Gestion d'état NgRx
           ├── Composants commerce préconstruits
           └── Rendu côté serveur (Angular SSR sur Node.js)
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (backend)

Les composants de la vitrine correspondent directement à la structure CMS de Commerce Cloud, SmartEdit pilote la mise en page et le rendu côté serveur d’Angular produit la première page. SAP a conçu ces éléments pour fonctionner ensemble (SAP Help : About Composable Storefront).

React/Next.js

Navigateur → Application Next.js
           ├── Bibliothèque de composants propre (à construire)
           ├── Gestion d'état (au choix : Zustand, Redux ...)
           ├── SSR / SSG / ISR / streaming (intégrés à Next.js)
           └── CMS headless (Contentful, Storyblok, Sanity ...)
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (backend)

Vous construisez vous-même les composants commerce et choisissez librement le CMS, la gestion d’état et la stratégie de rendu. Les API OCC sont les mêmes, tout le reste vous appartient. Les couches du backend derrière les API sont décrites dans notre présentation de SAP Commerce Cloud.

SAP Composable Storefront : ce que vous obtenez d’emblée

Le Composable Storefront (anciennement Spartacus) arrive avec de nombreuses fonctionnalités opérationnelles. C’est son principal atout : vous partez d’un commerce qui fonctionne, pas d’une page blanche.

Des composants commerce préconstruits. Listes et fiches produits, panier, tunnel de commande, espace client, historique des commandes, gestion des organisations B2B, circuits d’approbation, paniers enregistrés, commande rapide. Ce sont des composants de production alignés sur les fonctions du backend de Commerce Cloud, pas des démonstrations.

L’intégration de SmartEdit. Votre équipe de contenu réorganise les mises en page, change les bannières et gère les promotions dans l’éditeur visuel de SAP sans toucher au code. Cela compte plus que la plupart des équipes techniques ne l’admettent. Notre guide du Composable Storefront détaille l’architecture CMS.

Le SEO dès le premier jour. Balises meta, URL canoniques, données structurées et rendu côté serveur pour les robots d’indexation. Vous l’affinerez, mais vous ne le construirez pas.

L’internationalisation. Plusieurs langues et devises, formats locaux ; les contenus par langue viennent du backend.

Des fonctions PWA. Fonctionnement hors ligne, installation sur l’écran d’accueil, mise en cache par service worker. Utile pour les scénarios B2B à connectivité faible, par exemple pour le personnel d’entrepôt.

L’accessibilité. Les composants intègrent la navigation au clavier, les libellés ARIA et la gestion du focus. Pas parfait, mais un vrai point de départ par rapport à un développement de zéro.

Le revers : c’est Angular. Si votre équipe connaît React et pas Angular, la courbe d’apprentissage est réelle. NgRx est plus verbeux que les bibliothèques d’état React modernes, et le rendu côté serveur d’Angular propose moins de stratégies par route que Next.js. SAP fait passer la vitrine à une nouvelle version majeure d’Angular une fois par an, en février ; la version 2211.36, par exemple, est passée à Angular 19 et Node.js 22.

React/Next.js : ce que vous construisez vous-même

React/Next.js, c’est la liberté, avec la responsabilité qui l’accompagne.

Davantage d’options de rendu. Next.js prend en charge la génération statique (SSG), le rendu côté serveur (SSR), la régénération statique incrémentale (ISR) et le streaming avec React Suspense, combinables route par route. Une liste de produits peut être générée statiquement et revalidée chaque minute, tandis que le panier reste entièrement dynamique.

L’optimisation des images. Next.js gère les tailles adaptatives, le chargement différé, la conversion de format (WebP, AVIF) et la diffusion par CDN. Les sites de commerce sont riches en images, et le gain s’additionne.

Le runtime edge. Déploiement sur Vercel, Cloudflare Workers ou AWS Lambda@Edge, avec un rendu au plus près de l’utilisateur. Le SSR du Composable Storefront tourne sur un serveur Node.js ; SAP ne propose pas d’option de rendu en périphérie.

Les React Server Components. La récupération des données et le rendu passent côté serveur, et le navigateur reçoit moins de JavaScript.

Un écosystème très large. Options de CMS headless, bibliothèques de composants (Radix, shadcn/ui), outils d’animation et de test. L’écosystème React est immense.

Ce que vous construisez vous-même : chaque composant commerce. Listes et fiches produits, panier, tunnel de commande, espace client, parcours B2B, paniers enregistrés, circuits d’approbation. Vous utilisez les mêmes API OCC, mais vous écrivez chaque composant, chaque intégration d’API et chaque schéma d’état que le Composable Storefront fournit tout prêts. Pour le débat d’architecture plus large, lisez notre article sur le composable commerce en B2B.

Comparaison des fonctionnalités

Dimension	Composable Storefront	React/Next.js
Délai de mise sur le marché	Environ 8 à 12 semaines (B2B/B2C type)	12 à 20 semaines
Composants commerce préconstruits	Large bibliothèque, prête pour la production	À construire de zéro
SmartEdit / CMS	Intégration native	CMS headless nécessaire (coût et intégration supplémentaires)
SEO	SSR, balises meta, URL canoniques intégrés	Plus d’options : SSG, ISR, SSR edge, streaming
Core Web Vitals	Bons avec un réglage standard	Excellents si bien optimisés
Stratégies de rendu	SSR (Angular)	SSR, SSG, ISR, streaming, edge
Vivier de développeurs	Plus restreint (Angular)	Plus large (React)
Limite de personnalisation	Élevée, dans le cadre d’Angular	Illimitée
Mobile / PWA	Fonctions PWA intégrées	PWA à configurer, option React Native
Accessibilité	Composants accessibles comme base	À construire (ou Radix, Headless UI)
Gestion d’état	NgRx (inclus)	Au choix (Zustand, Redux, Jotai)
Alignement sur SAP	Complet : feuille de route, support et correctifs SAP	Aucun : tout est à votre charge
CDN / déploiement edge	Serveur Node.js	Vercel, Cloudflare, AWS edge
Chemin de mise à niveau	Versions gérées par SAP	Framework et code propre : vous gérez les deux
Coût de construction initial	Plus bas	En général 40 à 60 % plus élevé

Comparaison des performances

C’est sur les performances que l’argument en faveur de React/Next.js devient convaincant, à condition que le travail soit bien fait.

Core Web Vitals. Le Composable Storefront donne des résultats corrects d’emblée. Le bundle Angular est plus lourd qu’une application React bien optimisée, et l’hydratation ajoute du travail. Un build Next.js soigné, avec React Server Components, streaming et rendu en périphérie, peut aller plus loin. Pour les vitrines grand public, l’écart compte, car les Core Web Vitals font partie des signaux avec lesquels Google Search évalue l’expérience sur la page.

Premier affichage. Grâce à la génération statique, Next.js peut servir du HTML déjà construit depuis le CDN sans attendre un rendu serveur, ce qui raccourcit en général nettement le First Contentful Paint.

Largest Contentful Paint. Les fiches produits riches en images sont le vrai test. La gestion des images de Next.js, avec chargement prioritaire et négociation de format, fait en général mieux qu’une configuration Angular standard.

Travail sur le thread principal. La détection de changements d’Angular et NgRx génèrent plus de travail sur le thread principal qu’une configuration React légère ; les React Server Components réduisent précisément cette charge.

La réserve. Un site Next.js mal construit est plus lent qu’un Composable Storefront bien configuré. L’écosystème React offre davantage de leviers de performance, mais encore faut-il les actionner.

Le facteur compétences

C’est le facteur que la plupart des documents d’architecture passent sous silence, et c’est souvent lui qui tranche.

Dans le Stack Overflow Developer Survey 2024, 39,5 % des répondants utilisaient React et 17,1 % Angular (Stack Overflow Developer Survey 2024), soit un rapport de plus de deux contre un.

Ce que cela signifie en pratique :

• Recrutement. Les postes React attirent en général nettement plus de candidatures que des postes Angular équivalents, ce qui compte sur des marchés tendus comme Zurich ou Munich.
• Tarifs. Les développeurs Angular expérimentés sur SAP sont recherchés et plus chers ; les développeurs React sont plus disponibles.
• Prestataires externes. Pour monter rapidement en capacité avec des développeurs externes, le vivier React est bien plus profond.
• Intégration des nouveaux. Les nouveaux membres de l’équipe connaissent plus souvent React.

L’argument contraire. Les développeurs Angular sont souvent plus familiers des patterns d’entreprise (injection de dépendances, services typés, RxJS). Si votre équipe maîtrise déjà Angular, passer à React pour suivre une tendance du marché est coûteux et risqué. Misez sur ce que votre équipe sait faire.

Comparaison des coûts

Ordres de grandeur indicatifs pour planifier une vitrine B2B ou B2C standard avec un catalogue de taille moyenne, un tunnel de commande standard, plusieurs langues et un prestataire de paiement. Ce sont des estimations d’orientation, pas des offres.

Poste de coût	Composable Storefront	React/Next.js
Construction initiale	CHF 120’000 à 180’000	CHF 180’000 à 300’000
Licence CMS headless	Incluse (SmartEdit)	CHF 6’000 à 24’000 par an
Maintenance annuelle (développement)	CHF 40’000 à 60’000 (1 à 2 développeurs)	CHF 60’000 à 100’000 (2 à 3 développeurs)
Licence SAP	Incluse dans Commerce Cloud	Incluse dans Commerce Cloud
Hébergement / CDN	Serveur Node.js sur SAP Commerce Cloud	Vercel/Cloudflare (CHF 2’400 à 12’000 par an)
Total sur trois ans	CHF 240’000 à 360’000	CHF 370’000 à 600’000

La nuance. React/Next.js coûte plus cher au départ et la première année. Avec plusieurs vitrines, une bibliothèque de composants partagée se répartit toutefois sur plusieurs sites et, dès la troisième année, elle peut coûter moins cher par vitrine que plusieurs Composable Storefronts adaptés séparément. Le budget global de la plateforme est détaillé dans notre guide des prix et du TCO de SAP Commerce Cloud.

L’approche hybride

Ce que nous recommandons de plus en plus souvent depuis 2025 : utiliser les deux, de manière ciblée.

Le principe : le Composable Storefront gère le parcours commerce principal : listes et fiches produits, panier, tunnel de commande, espace client. C’est là que ses composants préconstruits sont rentables. Certaines expériences à fort impact sont construites en React et intégrées comme micro-frontends dans la structure de la vitrine.

Où les micro-frontends React trouvent leur place :

• Configurateurs de produits. Configurateurs 3D ou outils de composition de produits, où l’écosystème React (Three.js, React Three Fiber) a un net avantage.
• Pages de campagne. Pages avec animations sur mesure, narration interactive ou mises en page riches en contenu, là où la liberté de design compte le plus.
• Applications mobiles. React Native partage la logique avec votre code React web ; le Composable Storefront n’a pas d’application native propre.
• Personnalisation. Widgets de recommandation en temps réel ou expériences fondées sur l’IA.

Sur le plan technique : le CMS de Commerce Cloud prend en charge les composants spécifiques. Vous enregistrez un micro-frontend React comme composant CMS, et SmartEdit peut le placer sur n’importe quelle page à côté des composants standard. Le micro-frontend se charge de manière indépendante et communique avec la structure via des événements personnalisés ou un canal d’état partagé.

Vous conservez ainsi l’essentiel de l’avance du Composable Storefront en matière de délais, tout en profitant de la flexibilité de React là où elle compte.

Grille de décision

Parcourez ces cinq questions dans l’ordre. Chacune affine le choix.

1. Quel est votre calendrier ? Moins de 12 semaines avant la mise en ligne : Composable Storefront. Ses composants et l’intégration de SmartEdit font gagner plusieurs semaines par rapport à un développement sur mesure, et aucun talent React ne compense cela quand le temps est la contrainte.

2. Que sait faire votre équipe ? Une équipe Angular avec une expérience SAP : Composable Storefront. Une équipe React sans Angular : React/Next.js. La reconversion a un coût : comptez quelques mois de productivité réduite pendant que les développeurs apprennent un nouveau framework, un nouveau schéma d’état et une nouvelle approche des tests. Une équipe mixte : envisagez l’approche hybride.

3. La vitrine est-elle une expérience de marque ou un outil fonctionnel ? Portails de commande B2B, libre-service et recommandes sont couverts par le Composable Storefront avec peu d’adaptations. Une expérience de marque grand public, où chaque interaction est conçue, appelle React/Next.js. La plupart des vitrines B2B sont des outils fonctionnels ; la plupart des expériences B2C ambitieuses sont des expériences de marque.

4. Quelle importance a SmartEdit ? Si le marketing doit gérer contenus, mises en page et promotions sans développeurs, SmartEdit est un avantage considérable. Un CMS headless peut le remplacer, mais c’est un système de plus, avec sa propre courbe d’apprentissage, sa licence et son intégration.

5. Quel est votre plan à trois ans ? Une seule vitrine, des exigences stables et un investissement dans SAP : la feuille de route du Composable Storefront, alignée sur SAP, est un atout. Plusieurs vitrines, un frontend qui évolue vite ou un éventuel changement de framework plus tard : React/Next.js avec une bibliothèque de composants partagée vous laisse plus de marge.

Ce que nous constatons en pratique

Nous avons livré des frontends Commerce Cloud avec les deux approches. Le constat est constant : le Composable Storefront l’emporte en rapidité et en coût pour le commerce standard, React/Next.js en flexibilité et en performance pour les expériences distinctives, et l’approche hybride quand il faut les deux. Chez Distrelec, le découplage du frontend de SAP Commerce par une couche d’API propre a réduit le délai de mise sur le marché de 70 %.

L’erreur la plus fréquente : choisir React/Next.js parce que l’équipe préfère React, puis passer des mois à reconstruire des composants que le Composable Storefront fournit d’emblée. La préférence pour un framework est légitime, mais elle ne devrait pas coûter des centaines de milliers de francs de travail en double.

La deuxième : choisir le Composable Storefront, puis se battre des mois avec Angular pour construire une expérience très spécifique que React gérerait plus naturellement. Si votre équipe de design livre des maquettes qui ne ressemblent en rien à une vitrine standard, ses composants deviennent une contrainte plutôt qu’un accélérateur.

Choisissez l’outil en fonction du travail, pas l’inverse. Si le choix de la vitrine s’inscrit dans un projet plus large, notre article sur ce qui se passe vraiment dans une mise en œuvre de Commerce Cloud le replace dans son contexte.

---

Besoin d’aide pour décider ? Nous réalisons des évaluations d’architecture frontend pour SAP Commerce Cloud qui examinent votre équipe, votre calendrier et vos exigences, puis recommandent l’approche qui crée le plus vite de la valeur. Parlez à nos architectes commerce. Notre travail sur Commerce Cloud est présenté sur la page de la solution SAP Commerce Cloud.

Questions fréquentes

Le SAP Composable Storefront est-il la même chose que Spartacus ?

Oui. Depuis la version 5.0, SAP publie les bibliothèques officielles de Spartacus sous le nom « SAP Commerce Cloud, composable storefront ». C’est la même base de code Angular avec la même intégration via les API OCC ; depuis la version 2211.19, la numérotation suit celle de Commerce Cloud. Beaucoup de développeurs disent encore Spartacus, la documentation de SAP parle de Composable Storefront.

Peut-on utiliser React avec SAP Commerce Cloud ?

Oui. Commerce Cloud expose les API REST OCC (Omni Commerce Connect), utilisables par n’importe quel framework frontend : React, Next.js, Vue et d’autres. Vous renoncez au rendu de pages prêt à l’emploi de SmartEdit et aux composants commerce préconstruits de SAP, et gagnez la maîtrise complète de l’architecture frontend.

Quelle approche est la plus rapide à mettre en œuvre ?

Le Composable Storefront est plus rapide pour les scénarios B2B et B2C standard : environ 8 à 12 semaines pour une vitrine type adaptée, contre 12 à 20 semaines pour un frontend React/Next.js sur mesure. L’essentiel du gain vient des composants préconstruits et du mapping CMS existant. L’écart se réduit pour des expériences très spécifiques, où les composants standard doivent de toute façon être fortement modifiés.

Quelle approche coûte le plus cher ?

Un frontend React/Next.js sur mesure coûte en général 40 à 60 % de plus à construire, car chaque composant commerce doit être développé et un CMS headless séparé est le plus souvent nécessaire. Le Composable Storefront est inclus dans la licence Commerce Cloud et coûte moins cher à construire, mais peut demander beaucoup d’adaptations pour une expérience utilisateur très distinctive. Sur trois ans, l’écart se réduit si plusieurs vitrines partagent une bibliothèque de composants React ; pour une seule vitrine, le Composable Storefront reste en général moins cher.

Angular est-il en train de disparaître ? Faut-il s’inquiéter du framework du Composable Storefront ?

Non. Angular est soutenu par Google, publie une nouvelle version majeure tous les six mois et est largement utilisé en entreprise ; SAP fait passer la vitrine à une nouvelle version d’Angular une fois par an. React dispose certes d’un vivier de développeurs plus large, mais cela influe sur le recrutement et la disponibilité de prestataires, pas sur la pérennité du framework. Si vous avez déjà des développeurs Angular, rien ne justifie de changer ; si vous constituez une équipe de zéro, le vivier plus large de React est un avantage pratique.