D'Accelerator à Composable Storefront : un guide pratique de migration

Migrer d’Accelerator vers SAP Composable Storefront n’est pas une montée de version. C’est un changement de plateforme du frontend : de modèles JSP côté serveur vers une application Angular headless. Le backend reste, le frontend est reconstruit. Les équipes qui le planifient comme une montée de version sous-estiment l’effort, et nous le disons d’emblée parce que c’est l’erreur la plus fréquente que nous voyons.

Il y a aussi désormais une date. SAP a déclaré obsolètes les modèles d’interface Accelerator avec la version 2205 et, selon son plan publié, les retire de SAP Commerce Cloud en septembre 2027 (SAP KBA 3263872). Une migration de trois à six mois qui démarre à l’automne 2026 a assez de marge ; une qui démarre au printemps 2027, non.

En bref : passer d’Accelerator (JSP) à SAP Composable Storefront (Angular, anciennement Spartacus) prend trois à six mois pour les implémentations standard, davantage pour les configurations B2B et multisites. Le backend et les API OCC restent ; tout le frontend est reconstruit. Auditez d’abord vos personnalisations, comblez tôt les lacunes des API OCC, configurez le rendu côté serveur dès le départ et faites tourner les deux vitrines en parallèle avant la bascule. SAP prévoit de retirer les modèles Accelerator en septembre 2027.

Pourquoi une simple « mise à niveau » ne suffit-elle pas ?

On a l’impression que cela devrait être simple : même plateforme, nouveau frontend. Ce n’est pas le cas. Accelerator et Composable Storefront diffèrent à chaque niveau du frontend : JSP côté serveur contre Angular côté client, appels directs au modèle contre API REST OCC, sessions serveur contre état NgRx. Il n’existe pas d’outil de migration automatique, car au niveau du frontend les deux architectures n’ont rien en commun. Les indications de SAP sur ce passage (KBA 3285373) et la documentation de Composable Storefront décrivent la cible ; le chemin pour y arriver relève du projet.

Savoir si Composable Storefront est vraiment la bonne cible, ou si un frontend headless maison convient mieux, est une décision à part. Nous la traitons dans Avez-vous besoin de SAP Composable Storefront ? et dans Composable Storefront vs React/Next.js.

Comment se déroule la migration ?

Dix étapes. La performance mobile en fait partie dès le départ, pas d’un projet ultérieur.

Étape 1 : auditer les personnalisations Accelerator. Recensez chaque balise JSP maison, chaque contrôleur, chaque feuille de style et chaque fichier JavaScript. C’est un travail peu spectaculaire qui évite les surprises : sur un projet, cette semaine d’audit a mis au jour 47 composants maison que personne n’avait documentés.

Étape 2 : trouver les équivalents dans Composable Storefront. La plupart des composants standard ont une contrepartie. Les composants maison doivent être reconstruits en Angular.

Étape 3 : vérifier la couverture des API OCC. Les fonctions qui appellent directement des services peuvent nécessiter de nouveaux points de terminaison OCC. C’est ce qui prend le plus souvent les équipes au dépourvu.

Étape 4 : mettre en place Composable Storefront. Générer l’application, configurer la connexion au backend et définir les mappings CMS.

Étape 5 : reconstruire les composants maison. Priorisez selon l’impact métier : d’abord les personnalisations du checkout et les fonctions B2B.

Étape 6 : migrer les contenus CMS. Réassocier les emplacements de contenu et les composants des mappings Accelerator à ceux de Composable Storefront.

Étape 7 : configurer le rendu côté serveur. Mettre en place le SSR pour les moteurs de recherche et la performance. Une vitrine commerce sans SSR est difficile à indexer et lente au premier chargement : ne sautez pas cette étape.

Étape 8 : thème et identité visuelle. Appliquer le design : surcharges de styles, typographie, couleurs.

Étape 9 : tester en parallèle. Faire tourner les deux vitrines sur le même backend et comparer fonctionnalités et conversion pendant deux à quatre semaines. Nos migrations les plus réussies ont toutes utilisé ce fonctionnement en parallèle. Il coûte du temps, et c’est là qu’apparaît ce que l’assurance qualité ne voit pas.

Étape 10 : basculer. Rediriger le trafic, surveiller de près pendant deux semaines et garder Accelerator disponible comme solution de repli.

Quels délais sont réalistes ?

• B2C standard (10 à 20 composants maison) : 3 à 4 mois
• Fortes personnalisations (30 composants ou plus) : 4 à 6 mois
• Vitrine B2B : 5 à 7 mois
• Plusieurs sites et plusieurs langues : 6 à 9 mois

La principale variable est le nombre de composants maison, et la plupart des équipes le sous-estiment. D’abord l’audit, ensuite le plan. Si le changement de vitrine s’inscrit dans une migration plus large depuis SAP Commerce on-premise, notre checklist de migration montre comment les chantiers s’articulent.

Quelles sont les erreurs de migration les plus courantes ?

Vouloir reproduire Accelerator à l’identique. Profitez de la migration pour simplifier. Un client a exigé une correspondance au pixel près avec sa vitrine Accelerator ; au bout de trois mois, il s’est rendu compte que la moitié de ces choix de design étaient déjà des erreurs la première fois.

Tout migrer d’un coup. Avancez section par section : liste de produits, puis panier et checkout, puis B2B. Sur le papier, cela paraît plus lent ; en pratique, c’est plus rapide, car les problèmes apparaissent tant que leur impact reste limité.

Ignorer les lacunes des API OCC. Les fonctions maison qui appellent directement des services demandent du travail côté backend. Repérez-les tôt, sinon elles bloquent l’équipe frontend pendant des semaines.

Sous-estimer la courbe d’apprentissage d’Angular. Prévoyez quatre à huit semaines de formation ou intégrez des développeurs Angular à l’équipe. Les compétences JSP ne se transposent pas dans cet univers.

Si vous cherchez un partenaire pour ce passage, notre panorama des meilleurs partenaires SAP Commerce Cloud en Suisse énumère les critères qui comptent, et notre page SAP Commerce Cloud montre comment nous travaillons. Parlez-nous de votre vitrine.

Questions fréquentes

Jusqu’à quand pouvons-nous garder la vitrine Accelerator ?

SAP a déclaré obsolètes les modèles d’interface et les add-ons Accelerator avec la version 2205. Selon le plan publié par SAP (KBA 3263872), ils sont retirés de SAP Commerce Cloud en septembre 2027, avec une période d’adoption étendue qui s’achève en septembre 2028. Jusque-là, les vitrines continuent de fonctionner, mais sans évolutions : planifiez le passage dès maintenant.

Pouvons-nous faire fonctionner les deux vitrines en même temps ?

Oui. Accelerator et Composable Storefront peuvent fonctionner sur le même backend Commerce Cloud. Vous pouvez répartir le trafic par URL, par domaine ou par pourcentage, migrer section par section et comparer la conversion avant la bascule définitive.

Nos personnalisations Accelerator sont-elles reprises ?

Pas le code frontend : modèles JSP, balises, contrôleurs et JavaScript sont reconstruits sous forme de composants Angular. La logique métier du backend reste et est appelée via les API REST OCC ; les fonctions qui appellent des services directement depuis la vitrine nécessitent de nouveaux points de terminaison OCC.

Comment protéger le SEO pendant la migration ?

Conservez les structures d’URL autant que possible et mettez en place des redirections 301 là où elles changent. Configurez le rendu côté serveur dès le départ, car une vitrine Angular uniquement côté client est difficile à indexer. Surveillez de près la Google Search Console pendant et après la bascule.

Faut-il mettre à jour Commerce Cloud et migrer la vitrine en même temps ?

De préférence non. Mettez d’abord à jour le backend, validez sa stabilité, puis migrez la vitrine. Faire les deux à la fois double le risque et rend très difficile d’identifier ce qui a cassé lorsqu’un problème survient.