SAP Composable Storefront : architecture, avantages, limites et quand en avoir besoin

Le SAP Composable Storefront (anciennement Spartacus) est le frontend Angular de SAP pour Commerce Cloud et le choix recommandé par SAP pour les nouveaux projets. C’est un bon choix par défaut, mais pas automatique : il exige des compétences Angular, modifie la façon de travailler de votre équipe et ajoute une couche de rendu côté serveur à exploiter. Pour beaucoup d’entreprises, cela en vaut la peine ; pour certaines, un frontend headless sur mesure ou une autre approche convient mieux.

Ce guide explique ce qu’est la vitrine, comment fonctionne l’architecture, ce dont un projet a besoin avant de démarrer, quels sont les avantages et les limites réels, et comment trancher.

En bref : le Composable Storefront est une application Angular qui communique avec SAP Commerce Cloud uniquement via les API REST OCC, avec rendu côté serveur, pages pilotées par SmartEdit et composants B2B et B2C. Il est inclus dans la licence Commerce Cloud. Choisissez-le si vous voulez les composants et le chemin de mise à niveau de SAP et disposez de compétences Angular (ou comptez les développer) ; préférez un frontend React ou Next.js sur mesure si la liberté de design ou une pile frontend existante comptent davantage. L’ancien Accelerator basé sur JSP est déprécié et sa suppression est prévue pour septembre 2027.

Qu’est-ce que le SAP Composable Storefront ?

Le Composable Storefront est le frontend headless de SAP Commerce Cloud. Beaucoup de développeurs l’appellent encore Spartacus, du nom du projet open source dont il est issu. Depuis la version 5.0, SAP livre les bibliothèques officielles sous le nom « SAP Commerce Cloud, composable storefront », et depuis la version 2211.19 sa numérotation suit celle de Commerce Cloud (SAP Help : About Composable Storefront).

Ce qui le caractérise :

• Angular, avec NgRx pour la gestion d’état. SAP fait passer la vitrine à une nouvelle version majeure d’Angular une fois par an, en février.
• Headless : la communication avec Commerce Cloud passe exclusivement par les API REST OCC.
• Piloté par le CMS : les mises en page viennent de SmartEdit et non de modèles codés en dur.
• Rendu côté serveur (SSR) pour les moteurs de recherche et un premier affichage rapide, ainsi que des fonctions de progressive web app.
• Licence : incluse dans la licence Commerce Cloud. Les clients cloud installent les bibliothèques depuis le dépôt de SAP ; le code source reste ouvert sur GitHub.

Il remplace la vitrine Accelerator, c’est-à-dire les modèles JSP générés sur les serveurs d’application de Commerce Cloud et étroitement liés au backend. SAP a déprécié les modèles d’interface Accelerator et planifié leur suppression ainsi que la fin de la maintenance standard pour septembre 2027, avec une période d’adoption prolongée jusqu’en septembre 2028 (SAP Help : Deprecation of Accelerator UIs).

Comment fonctionne l’architecture ?

Trois couches avec une répartition claire des rôles :

1. Backend Commerce Cloud : panier, tunnel de commande, prix, commandes, gestion des produits et recherche, le tout exposé par des API. (Les couches du backend lui-même sont décrites dans notre présentation de SAP Commerce Cloud.)
2. Couche API OCC : les points de terminaison REST que la vitrine appelle pour la recherche de produits, le panier, la commande et la gestion du compte. La vitrine n’accède jamais directement à la base de données.
3. Composable Storefront : l’application Angular dans le navigateur ou, pour le SSR, sur un serveur Node.js. Elle affiche l’interface, gère l’état côté client et appelle les API OCC.

Cette séparation permet de livrer le frontend indépendamment du backend, de servir plusieurs frontends (web, application, borne) depuis un seul backend et, si nécessaire, de remplacer entièrement le frontend.

Comment fonctionne l’intégration du CMS

1. Les responsables de contenu créent dans SmartEdit des pages avec des emplacements de contenu (en-tête, corps, pied de page, barre latérale).
2. Chaque emplacement contient des composants CMS : bannières, carrousels de produits, blocs de texte, navigation.
3. La vitrine charge la structure de la page depuis l’API du CMS.
4. Chaque type de composant CMS est associé à un composant Angular qui l’affiche.
5. Les modifications faites dans SmartEdit apparaissent dans la vitrine sans déploiement.

C’est ce qui rend la vitrine « composable » en pratique : les pages sont assemblées à partir de composants que le marketing contrôle lui-même.

Les fonctions qui comptent en projet

• SSR : le serveur génère la première page, puis le navigateur prend le relais. Les robots d’indexation reçoivent un HTML complet, les utilisateurs un premier affichage rapide.
• Chargement différé : les modules se chargent à la demande ; la liste de produits n’embarque donc pas le code du tunnel de commande.
• Internationalisation : fichiers de traduction par langue, changement de langue par URL ou selon la préférence de l’utilisateur.
• Extensibilité : vous remplacez les composants SAP par les vôtres via l’injection de dépendances d’Angular, sans modifier le code source de SAP. Cela paraît contraignant au début, et c’est précisément ce qui garde les mises à niveau maîtrisables.

De quoi un projet a-t-il besoin avant de démarrer ?

Prérequis techniques

• Un environnement Commerce Cloud avec les points de terminaison OCC activés pour les produits, le panier, la commande, le CMS et les utilisateurs.
• Des versions de Node.js et d’Angular CLI compatibles avec votre version de la vitrine (SAP documente la compatibilité ; vérifiez-la avant d’écrire du code).
• Un accès au dépôt de SAP pour les bibliothèques de la vitrine.

Prérequis dans l’équipe

• De l’expérience avec Angular, TypeScript et RxJS. Ce n’est pas négociable : des équipes habituées à React, qui pensaient Angular suffisamment proche, ont perdu des semaines rien qu’avec RxJS et l’injection de dépendances.
• La compréhension de l’authentification OCC (OAuth 2.0).
• Un accès au Backoffice et à SmartEdit pour la configuration du CMS.

Mise en place en cinq étapes : générer l’application avec les schematics de SAP ; configurer l’URL du backend, le base site, la langue et la devise ; associer les types de composants CMS à des composants Angular (SAP fournit les associations standard, vos propres composants demandent les vôtres) ; configurer le SSR ; enfin, habiller et étendre. La communauté SAP propose un pas-à-pas pour l’installation des versions 2211 actuelles.

Les erreurs les plus fréquentes

• Incompatibilité de versions entre les bibliothèques de la vitrine et le backend. Vérifiez d’abord la compatibilité ; sinon, un sprint entier peut y passer.
• SSR ajouté trop tard. Le SSR influe sur les performances, les aperçus sur les réseaux sociaux et le comportement de chargement. Mettez-le en place dès le départ ; l’ajouter après coup est laborieux.
• Contenus codés en dur au lieu de composants CMS, ce qui impose des déploiements pour de simples changements de contenu.
• Tout chargé d’emblée. Vérifiez quels modules se chargent au démarrage ; sur mobile, la différence se fait sentir.
• Le bureau d’abord. Testez vos composants sur mobile dès le début.

Gardez votre code dans des modules fonctionnels, des surcharges de composants via l’injection de dépendances, des modules partagés et des surcharges de style par propriétés CSS personnalisées. SAP met régulièrement la vitrine à jour, et un code entremêlé avec celui de SAP transforme chaque mise à niveau en projet.

Quels sont les avantages réels ?

Des livraisons indépendantes. Une bannière promotionnelle, une modification du tunnel de commande ou une correction d’affichage partent en production sans version complète de la plateforme ; le frontend suit son propre rythme pendant que le backend reste stable.

Un frontend flexible. Comme la vitrine ne communique avec Commerce Cloud que par des API, vous pouvez intégrer des composants d’autres sources : configurateurs de produits, visionneuses 3D, chat.

Le référencement. Avec le SSR, les pages produits et catégories sont indexables sans dépendre du JavaScript côté client.

L’autonomie sur les contenus. Le marketing gère les mises en page dans SmartEdit, sans ticket pour les développeurs.

La feuille de route de SAP. Les développements de SAP pour les vitrines vont au Composable Storefront, tandis que les modèles Accelerator disparaissent progressivement.

Quelles sont les limites réelles ?

La dépendance à Angular. Votre équipe frontend doit maîtriser Angular, TypeScript et RxJS. La plupart des équipes SAP Commerce sont orientées Java ; prévoyez donc recrutement ou formation. Un développeur Java a généralement besoin de plusieurs mois pour être pleinement productif avec la vitrine ; le modèle de composants et les patterns réactifs d’Angular ont peu en commun avec le développement JSP.

Un effort initial plus élevé. SSR, chaîne de build, déploiement et mapping CMS demandent plus de travail qu’un démarrage avec les modèles Accelerator. Prévoyez quelques semaines de plus.

Un environnement d’exécution supplémentaire. Le serveur SSR doit être déployé, surveillé et maintenu stable sous charge.

Plus de code pour de petites modifications. Surcharger des composants Angular et travailler avec NgRx demande plus de code que modifier un modèle JSP.

Les composants sont un point de départ. Les composants de SAP couvrent les parcours standard, mais correspondent rarement tels quels à votre marque. Pour un design distinctif, vous en surchargerez une bonne partie.

Comment décider ?

Critère	Composable Storefront	Headless sur mesure (React, Next.js)	Accelerator
Framework	Angular	Au choix	JSP (historique)
Délai pour une vitrine standard	Quatre à huit semaines	Plus long : commande, compte et rendu CMS à construire	Installations existantes uniquement
CMS	SmartEdit, intégré	Contenus SmartEdit ou CMS externe à intégrer soi-même	SmartEdit
Support SAP	Vitrine et API	API uniquement	Déprécié, suppression prévue en septembre 2027
Liberté de design	Moyenne	Totale	Limitée

Choisissez le Composable Storefront si vous partez de zéro, disposez de développeurs Angular ou voulez développer cette compétence, souhaitez SmartEdit sans effort supplémentaire et tenez au chemin de mise à niveau de SAP.

Choisissez un frontend headless sur mesure si votre équipe est solide en React ou Next.js, si votre marque exige un design entièrement spécifique ou si vous avez déjà opté pour un CMS externe. Notre comparaison détaillée entre le Composable Storefront et React/Next.js examine cet arbitrage. 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 %.

Restez sur l’Accelerator uniquement comme solution de transition, et planifiez le passage dès maintenant. Notre guide de migration de l’Accelerator vers le Composable Storefront décrit une démarche progressive. Si le choix de la vitrine s’inscrit dans un changement de plateforme plus large, lisez ce qui se passe vraiment dans une mise en œuvre de Commerce Cloud ou parlez à notre équipe SAP Commerce Cloud.

Questions fréquentes

Quelle est la différence entre Spartacus et le SAP Composable Storefront ?

C’est le même produit sous un nouveau nom. Depuis la version 5.0, SAP publie les bibliothèques officielles de Spartacus sous le nom « SAP Commerce Cloud, composable storefront ». L’architecture est la même et, depuis la version 2211.19, la numérotation suit celle de SAP Commerce Cloud.

Le Composable Storefront est-il payant ?

Non. Il est inclus sans frais supplémentaires dans la licence SAP Commerce Cloud. Les clients cloud obtiennent les bibliothèques depuis le dépôt de SAP ; le code source reste open source sur GitHub. Ce qui coûte, c’est l’équipe frontend qui construit et maintient votre vitrine.

Peut-on utiliser React ou Next.js au lieu d’Angular ?

Oui. Les API REST OCC sont indépendantes de la technologie ; vous pouvez donc développer un frontend headless sur mesure avec React, Vue ou Next.js. Vous renoncez aux composants de vitrine prêts à l’emploi de SAP, au rendu CMS intégré et au chemin de mise à niveau de SAP, et gagnez une liberté totale de design et de technologie.

L’Accelerator et le Composable Storefront peuvent-ils fonctionner en parallèle ?

Oui. Pendant une migration, les deux vitrines peuvent s’appuyer sur le même backend Commerce Cloud, le trafic étant réparti par URL ou par domaine. Planifiez la bascule : SAP a déprécié les modèles d’interface Accelerator et prévu leur suppression pour septembre 2027.

Combien de temps faut-il pour construire un Composable Storefront ?

Une vitrine de base fonctionne en quelques jours. Une vitrine B2C standard prête pour la production, construite avec les composants SAP, demande généralement quatre à huit semaines, huit à douze avec des adaptations importantes, et les fonctions B2B ajoutent deux à quatre semaines. Ces durées supposent une équipe qui maîtrise déjà Angular.

Le Composable Storefront prend-il en charge le commerce B2B ?

Oui. Les fonctions B2B couvrent la gestion des organisations et des budgets, les circuits d’approbation, la commande avec bon de commande, la saisie rapide et les paniers enregistrés. Les modules B2B et B2C peuvent cohabiter dans un même build ou être séparés si les expériences diffèrent fortement.