SAP Composable Storefront vs React/Next.js : Comment Choisir

Cette question revient dans chaque atelier de stratégie frontend SAP Commerce Cloud que nous animons. L’équipe projet s’assied, dessine deux cadres au tableau blanc. À gauche : Composable Storefront, le frontend headless Angular de SAP. À droite : un projet React ou Next.js sur mesure consommant les mêmes API OCC. Puis quelqu’un demande lequel choisir. Et la réponse honnête est toujours la même — cela dépend de cinq facteurs qui n’ont rien à voir avec les préférences de framework.

Le commerce en ligne mondial a atteint 6,3 billions de dollars en 2024, en hausse de 8,4 % d’une année sur l’autre (eMarketer, 2025). Votre frontend n’est pas un détail technique. C’est ce que vos clients touchent. C’est là que le chiffre d’affaires se concrétise ou non.

TL;DR : SAP Composable Storefront vous amène sur le marché plus rapidement (8-12 semaines) avec plus de 200 composants commerce pré-construits, l’intégration SmartEdit et le SEO natif. Un build React/Next.js sur mesure offre une liberté totale de design, un vivier de talents plus large et une optimisation des performances supérieure — mais coûte 40-60 % de plus initialement et prend 12-20 semaines. Choisissez Composable Storefront pour le B2B/B2C standard, la rapidité et l’alignement avec l’écosystème SAP. Choisissez React/Next.js pour des expériences B2C différenciées, des équipes React existantes et la flexibilité à long terme. L’approche hybride — Composable Storefront comme noyau avec des micro-frontends React — offre souvent le meilleur des deux mondes.

La Décision en 30 Secondes

Choisissez SAP Composable Storefront si :

• Vous devez lancer rapidement (moins de 12 semaines)
• Votre cas d’usage est du B2B ou B2C commerce standard
• L’intégration SmartEdit est importante pour votre équipe contenu
• Vos développeurs connaissent Angular ou peuvent se former
• L’alignement avec l’écosystème SAP est une priorité stratégique

Choisissez React/Next.js si :

• La différenciation UX est un avantage concurrentiel central
• Vous avez déjà une équipe React/frontend solide
• Vous avez besoin d’un contrôle pixel-perfect sur chaque interaction
• L’optimisation des performances en edge (ISR, Streaming SSR) est critique
• Vous prévoyez de servir plusieurs marques ou canaux depuis une seule codebase

Envisagez une approche hybride si :

• Vous voulez les fondations commerce du Composable Storefront mais avez besoin d’expériences sur mesure pour des pages spécifiques (PDP, landing pages, configurateurs)

Comparaison Architecturale

Les deux approches consomment le même backend. SAP Commerce Cloud expose ses fonctionnalités via des API REST OCC. Le storefront est un pur consommateur d’API. Ce découplage est la raison même pour laquelle ce choix existe.

Architecture Composable Storefront

Navigateur → Application Angular (Composable Storefront)
           ├── Composition de pages pilotée par CMS (SmartEdit)
           ├── NgRx state management
           ├── 200+ composants commerce pré-construits
           └── SSR via Angular Universal
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (Backend)

Le storefront inclut des composants qui mappent directement sur la structure CMS de Commerce Cloud. SmartEdit contrôle la mise en page. Angular Universal gère le rendu côté serveur. L’intégration est étroite et intentionnelle — SAP a conçu ces systèmes pour fonctionner ensemble.

Architecture React/Next.js

Navigateur → Application Next.js
           ├── Bibliothèque de composants sur mesure (vous la construisez)
           ├── State management (votre choix : Zustand, Redux, etc.)
           ├── SSR / SSG / ISR / Streaming (Next.js intégré)
           └── CMS headless (Contentful, Storyblok, Sanity, etc.)
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (Backend)

Vous construisez les composants commerce vous-même. Vous choisissez votre propre CMS, state management et stratégie de rendu. Les API OCC sont les mêmes. Tout le reste est entre vos mains.

Pour un regard approfondi sur les couches backend de Commerce Cloud, consultez notre guide d’architecture Commerce Cloud.

SAP Composable Storefront : Ce que Vous Obtenez d’Emblée

Composable Storefront (le produit anciennement connu sous le nom de Spartacus) est livré avec un volume substantiel de fonctionnalités pré-construites. C’est son avantage principal : vous démarrez avec du commerce fonctionnel, pas une toile vierge.

200+ composants pré-construits. Pages de liste de produits, pages de détail produit, panier, checkout, mon compte, historique des commandes, gestion d’organisations B2B, workflows d’approbation, paniers sauvegardés, commande rapide. Ce ne sont pas des composants de démonstration. Ce sont des implémentations prêtes pour la production qui mappent directement sur les fonctionnalités backend de Commerce Cloud.

Intégration SmartEdit. Votre équipe contenu peut réorganiser les mises en page, changer les bannières et gérer les promotions via l’éditeur visuel de SAP sans toucher au code. Cela compte plus que la plupart des équipes techniques ne l’admettent. Pour un approfondissement sur SmartEdit et l’architecture CMS, consultez notre guide des fonctionnalités du Composable Storefront.

SEO natif. Balises meta, URL canoniques, données structurées, rendu côté serveur pour la crawlability. Pas parfait, mais fonctionnel dès le premier jour. Vous l’optimiserez, mais vous ne le construirez pas de zéro.

Internationalisation (i18n). Multi-langue, multi-devise, formatage spécifique par locale. Tout est intégré. Le backend Commerce Cloud gère le contenu par locale ; le storefront le rend.

Fonctionnalités PWA. Support hors ligne, installation sur l’écran d’accueil, mise en cache par service worker. Utile pour les scénarios B2B mobile où les représentants travaillent dans des entrepôts avec une connectivité instable.

Accessibilité (a11y). Conformité WCAG 2.1 AA intégrée dans la bibliothèque de composants. Navigation au clavier, labels ARIA, gestion du focus. Pas irréprochable, mais un vrai point de départ comparé à la construction de zéro.

Le revers : c’est Angular. Si votre équipe connaît React mais pas Angular, la courbe d’apprentissage est réelle. Le state management NgRx est plus verbeux que les bibliothèques React modernes. Et le SSR d’Angular Universal n’est pas aussi mature que celui de Next.js pour les stratégies de rendu complexes.

React/Next.js : Ce que Vous Construisez Vous-Même

Choisir React/Next.js signifie choisir la liberté — et la responsabilité. Voici ce que Next.js offre que Composable Storefront n’a pas, et ce que vous devrez construire par vous-même.

Rendu côté serveur, mieux réalisé. Next.js 15 supporte la génération statique (SSG), le rendu côté serveur (SSR), la regénération statique incrémentale (ISR) et le streaming avec React Suspense. Vous pouvez combiner les stratégies par route. Une page de liste de produits peut être générée statiquement et revalidée toutes les 60 secondes. Une page panier peut être entièrement dynamique. Cette granularité n’existe pas dans l’approche Angular Universal du Composable Storefront.

Optimisation d’images. Next.js Image gère les tailles responsives, le lazy loading, la conversion de format (WebP/AVIF) et l’intégration CDN automatiquement. Les sites commerce sont riches en images. Cela s’accumule.

Edge Runtime. Déployez sur Vercel, Cloudflare Workers ou AWS Lambda@Edge. Exécutez la logique de rendu au plus près de l’utilisateur. Le SSR de Composable Storefront tourne sur un serveur Node.js — pas d’option de déploiement edge.

React Server Components. Réduire le JavaScript côté client en déplaçant le data fetching et le rendu sur le serveur. Moins de JS envoyé au navigateur. Time to Interactive plus rapide.

Étendue de l’écosystème. CMS headless (Contentful, Storyblok, Sanity, Builder.io), bibliothèques de composants (Radix, shadcn/ui), animations (Framer Motion), testing (Playwright, Testing Library) — l’écosystème React est vaste.

Ce que vous construisez vous-même : chaque composant commerce. PLP, PDP, panier, checkout, mon compte, flux B2B, paniers sauvegardés, workflows d’approbation. Vous consommez les mêmes API OCC, mais vous écrivez chaque composant, chaque intégration API, chaque pattern de state management. Ce sont plus de 200 composants que Composable Storefront fournit gratuitement.

Pour une perspective plus large sur les architectures headless et composable, notre guide headless vs composable commerce couvre la réflexion stratégique derrière ces architectures.

Comparaison des Fonctionnalités

Comparaison des Performances

Les performances sont le domaine où l’argument React/Next.js devient convaincant. Quand c’est bien fait.

Core Web Vitals. Composable Storefront délivre des scores corrects d’emblée. La performance Lighthouse typique se situe entre 70 et 85 pour une implémentation standard. Le bundle Angular est plus lourd qu’une application React bien optimisée, et l’hydration d’Angular Universal ajoute de l’overhead. Un build Next.js optimisé avec React Server Components, streaming SSR et rendu edge atteint régulièrement 90+ sur Lighthouse. C’est un écart significatif pour les storefronts orientés consommateur. Google a confirmé que les Core Web Vitals restent un signal de classement et que les marchands avec des sites plus rapides constatent 15-20 % de taux de conversion en plus (Google Web.dev, 2024).

First Contentful Paint (FCP). Composable Storefront : 1,5-2,5s typique. Next.js avec SSG/ISR : 0,5-1,2s typique. La différence vient de la génération statique — Next.js peut servir du HTML pré-construit depuis un CDN sans attendre un rendu serveur.

Largest Contentful Paint (LCP). Les pages de détail produit avec des images lourdes sont le test décisif. Next.js Image avec priority loading et négociation de format surpasse systématiquement l’approche d’Angular. Des gains de 0,5 à 1,5 seconde sont courants.

Total Blocking Time (TBT). La change detection d’Angular et le state management NgRx génèrent plus de travail sur le thread principal qu’un setup React léger. Les React Server Components ciblent précisément ce problème en déplaçant le rendu hors du client.

La mise en garde. Un site Next.js mal construit performe moins bien qu’un Composable Storefront bien configuré. Ces chiffres supposent une implémentation compétente des deux côtés. L’écosystème React vous donne plus de leviers de performance, mais vous devez les actionner.

Le Facteur Talent

C’est le facteur que la plupart des documents d’architecture passent sous silence. Souvent, c’est celui qui est décisif.

Le Stack Overflow Developer Survey 2025 place React comme le framework web le plus populaire, utilisé par 39,5 % des développeurs professionnels, tandis qu’Angular se situe à 17,1 % (Stack Overflow, 2025). C’est un écart de 2,3x dans le vivier de talents.

Ce que cela signifie concrètement :

• Recrutement. Un poste de développeur frontend React attire environ deux fois plus de candidats qu’un poste Angular équivalent. Sur les marchés concurrentiels (Zurich, Munich, Londres), c’est significatif.
• Salaires. Les développeurs Angular spécialisés avec une expérience SAP exigent une prime. Les développeurs React sont plus disponibles, ce qui maintient les tarifs du marché plus compétitifs.
• Disponibilité de prestataires. Si vous devez monter en charge rapidement avec des prestataires externes ou des agences, le vivier React est nettement plus profond.
• Transfert de connaissances. Les nouveaux membres de l’équipe sont opérationnels plus vite sur les projets React parce qu’ils ont plus de chances d’avoir une expérience préalable.

Le contre-argument. Les développeurs Angular tendent à avoir plus d’expérience avec les patterns enterprise (injection de dépendances, services typés, RxJS). Si votre équipe connaît déjà Angular, changer pour React pour suivre une tendance du marché est coûteux et risqué. Utilisez ce que votre équipe connaît.

Comparaison des Coûts

Chiffres réels issus de projets frontend Commerce Cloud comparables. Hypothèses : un storefront B2B ou B2C standard avec 50-100 produits, checkout standard, multi-langue et intégration d’un fournisseur de paiement.

La nuance. React/Next.js coûte plus cher initialement et la première année. Mais si vous gérez plusieurs storefronts, la bibliothèque de composants partagée s’amortit sur toutes les propriétés. Au bout de trois ans, une bibliothèque React bien gérée servant trois storefronts peut coûter moins par storefront que trois personnalisations Composable Storefront séparées.

L’Approche Hybride

Voici ce que nous recommandons de plus en plus en 2025 et 2026 : utiliser les deux. Pas de manière désordonnée. Stratégiquement.

Le pattern : Composable Storefront gère le parcours commerce principal — liste de produits, détail produit, panier, checkout, mon compte. C’est là que les 200+ composants justifient leur existence. Puis vous construisez des expériences spécifiques à fort impact en React et les montez comme micro-frontends au sein du shell du storefront.

Où les micro-frontends React s’intègrent :

• Configurateurs de produits. Configurateurs 3D complexes ou product builders personnalisés où le modèle de composants React et l’écosystème (Three.js, React Three Fiber) ont un avantage clair.
• Pages d’atterrissage. Pages spécifiques à des campagnes avec des animations sur mesure, du storytelling interactif ou des mises en page riches en contenu où la liberté de design compte le plus.
• Applications mobiles. React Native partage la logique des composants avec votre code React web. Composable Storefront n’a pas de solution mobile native.
• Moteurs de personnalisation. Widgets de recommandation en temps réel ou expériences pilotées par l’IA construites avec des React Server Components en streaming.

Comment ça fonctionne techniquement : Le CMS de SAP Commerce Cloud supporte les composants personnalisés. Vous enregistrez un micro-frontend React comme composant CMS, et SmartEdit peut le placer sur n’importe quelle page aux côtés des composants standards du Composable Storefront. Le micro-frontend se charge indépendamment et communique avec le parent via des custom events ou un bus d’état partagé.

Cette approche vous garantit 80 % de l’avantage time-to-market de Composable Storefront tout en préservant la flexibilité de React là où elle compte le plus.

Cadre Décisionnel

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

1. Quel est votre délai ? Moins de 12 semaines avant le go-live ? Composable Storefront. Les composants pré-construits et l’intégration SmartEdit économisent 4 à 8 semaines par rapport à un build sur mesure. Aucun talent React ne compense cela quand le temps est la contrainte.

2. Que connaît votre équipe ? Équipe Angular existante avec expérience SAP ? Composable Storefront. Équipe React existante sans expérience Angular ? React/Next.js. Le coût de reconversion est réel : 2-3 mois de productivité réduite pendant que les développeurs apprennent un nouveau framework, un pattern de state management et une approche de testing. Équipe mixte ? Envisagez l’hybride.

3. Le storefront est-il un différenciateur de marque ou un outil fonctionnel ? Portail de commandes B2B, self-service client, fonctionnalité de réapprovisionnement ? Composable Storefront gère cela avec une personnalisation minimale. Expérience de marque orientée consommateur où chaque interaction est conçue ? React/Next.js vous donne le contrôle au pixel près. La distinction est importante. La plupart des storefronts B2B sont des outils fonctionnels. La plupart des expériences B2C ambitieuses sont des différenciateurs de marque.

4. Quelle est l’importance de SmartEdit ? Si votre équipe marketing doit gérer le contenu, les mises en page et les promotions sans intervention des développeurs, l’intégration SmartEdit est un avantage considérable. Reproduire cela avec un CMS headless (Contentful, Storyblok) fonctionne, mais c’est un système séparé avec sa propre courbe d’apprentissage, ses coûts de licence et son travail d’intégration.

5. Quel est votre plan à 3 ans ? Storefront unique, exigences stables, investissement dans l’écosystème SAP ? La roadmap alignée SAP de Composable Storefront est un atout. Storefronts multiples, évolution frontend rapide, migration de framework potentielle ? React/Next.js avec une bibliothèque de composants partagée offre plus de flexibilité.

Ce que Nous Observons en Pratique

Au cours des trois dernières années, nous avons livré des frontends Commerce Cloud avec les deux approches. Le schéma est clair : Composable Storefront l’emporte sur la rapidité et les coûts pour le commerce standard. React/Next.js l’emporte sur la flexibilité et les performances pour les expériences différenciées. L’hybride l’emporte quand vous avez besoin des deux.

L’erreur la plus courante que nous observons : choisir React/Next.js parce que l’équipe « préfère React » puis passer 16 semaines à reconstruire des composants que Composable Storefront fournit d’emblée. La préférence de framework est légitime. Mais elle ne devrait pas coûter CHF 100’000 en effort dupliqué.

La deuxième erreur la plus courante : choisir Composable Storefront puis lutter avec Angular pendant 6 mois pour construire une expérience hautement personnalisée que React gérerait nativement. Si votre équipe de design livre des fichiers Figma qui ne ressemblent en rien à un storefront standard, les composants de Composable Storefront deviennent une contrainte, pas un accélérateur.

Adaptez l’outil au travail. Pas l’inverse.

Besoin d’aide pour décider ? Nous menons des évaluations d’architecture frontend pour SAP Commerce Cloud qui analysent votre équipe, vos délais et vos exigences — puis recommandent l’approche qui génère de la valeur le plus rapidement. Parlez à nos architectes commerce.

Pour en savoir plus sur les capacités de SAP Commerce Cloud, visitez notre page solutions E-Commerce.

Questions Fréquemment Posées

SAP Composable Storefront, est-ce la même chose que Spartacus ?

Oui. SAP a renommé Spartacus en « SAP Composable Storefront » en 2023. Même produit, même codebase Angular, même intégration API OCC de Commerce Cloud. Le nom a changé ; la technologie non. La plupart des développeurs disent encore Spartacus en conversation. La documentation SAP utilise exclusivement « Composable Storefront ».

Puis-je utiliser React avec SAP Commerce Cloud ?

Oui. Commerce Cloud expose des API REST OCC (Omni Commerce Connect) que n’importe quel framework frontend peut consommer. React, Next.js, Vue, Svelte — tout ce qui peut faire des requêtes HTTP fonctionne. La couche API OCC est agnostique par design. Vous perdez l’éditeur visuel de SmartEdit et les composants commerce pré-construits, mais vous gagnez le contrôle total sur l’architecture frontend.

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

Composable Storefront est plus rapide pour les scénarios B2B/B2C standards : 8-12 semaines contre 12-20 semaines pour un build React/Next.js sur mesure. Les plus de 200 composants pré-construits, l’intégration SmartEdit et le mapping CMS Commerce Cloud existant économisent un temps de développement significatif. L’écart se réduit pour les expériences hautement personnalisées où les composants de Composable Storefront nécessitent de toute façon d’importantes modifications.

Quelle approche est la plus coûteuse ?

Un React/Next.js sur mesure coûte 40-60 % de plus initialement parce que chaque composant commerce doit être construit de zéro. Vous avez aussi besoin d’une licence CMS headless séparée (CHF 6’000-24’000/an). Composable Storefront inclut SmartEdit et la bibliothèque de composants. Sur trois ans, la différence de coût se réduit si vous gérez plusieurs storefronts avec une bibliothèque React partagée — mais pour un storefront unique, Composable Storefront est systématiquement moins cher.

Angular est-il en train de mourir ? Dois-je m’inquiéter du framework du Composable Storefront ?

Angular ne meurt pas. Il est soutenu par Google, connaît un développement actif (Angular 18 a introduit la réactivité basée sur les signaux) et dispose d’une large base d’utilisateurs enterprise. Cela dit, le vivier de talents React est 2,3 fois plus large selon les données d’enquêtes auprès des développeurs. Cela affecte la rapidité de recrutement et la disponibilité de prestataires, pas la viabilité du framework. Si vous avez déjà des développeurs Angular, il n’y a pas de raison de changer. Si vous construisez une équipe de zéro, le vivier de talents plus large de React est un avantage pratique.