7 erreurs SAP Commerce Cloud qui font dérailler les projets (et comment les éviter)

SAP Commerce Cloud est une plateforme solide. Elle est aussi assez complexe pour que les mêmes erreurs continuent de faire dérailler des projets, dans tous les secteurs et quelles que soient la taille des équipes et les budgets. Les schémas sont prévisibles, et c’est une bonne nouvelle : des erreurs prévisibles peuvent être évitées.

Voici les sept que nous rencontrons le plus souvent, chacune avec la manière de l’éviter.

En bref : les projets SAP Commerce Cloud déraillent pour sept raisons récurrentes : des développeurs Java généralistes au lieu de spécialistes Commerce, des mises à niveau reportées, une plateforme sur-personnalisée, des exigences floues, des performances négligées, une migration des données mal planifiée et des tests insuffisants. Chacune a sa mesure de prévention concrète, et le fil conducteur est de décider tôt plutôt que de corriger tard. Si vous êtes encore sur SAP Commerce on-premise, lisez d’abord notre guide des options après la fin de la maintenance mainstream.

Erreur 1 : recruter des généralistes Java plutôt que des spécialistes Commerce

Commerce Cloud tourne sur Java ; les entreprises recrutent donc de bons développeurs Java et s’attendent à ce qu’ils soient productifs dès le premier jour. Ce ne sera pas le cas.

Commerce Cloud possède son propre modèle de données (le type system), son propre mécanisme d’import (ImpEx), sa propre architecture d’extensions, sa propre chaîne de build et de déploiement, ainsi que son propre cache et sa propre indexation de recherche (Solr). Un développeur Java senior sans expérience de Commerce Cloud a besoin de plusieurs mois pour monter en compétence et commet, pendant ce temps, précisément les erreurs d’architecture coûteuses à corriger : sur-personnaliser le type system, compromettre le chemin de mise à niveau, écrire du code spécifique là où la configuration standard aurait suffi.

Nous avons repris des projets où c’était exactement ce qui s’était passé, et le nettoyage a coûté plus cher que de choisir les bonnes personnes dès le départ.

Comment l’éviter : recrutez des développeurs ayant une expérience avérée de SAP Commerce Cloud. Demandez des références de projets précises et vérifiez les certifications SAP. Si vous constituez une équipe interne, associez chaque nouveau développeur à un consultant Commerce Cloud expérimenté pendant les premiers mois. Si vous cherchez encore un partenaire d’intégration, notre aperçu des partenaires SAP Commerce Cloud en Suisse indique ce qu’il faut vérifier.

Erreur 2 : sauter ou reporter les mises à niveau

SAP met régulièrement à jour Commerce Cloud (SAP Help Portal). Chaque mise à jour apporte des correctifs de sécurité, des améliorations de performance, de nouvelles fonctionnalités et des corrections. Les sauter donne l’impression de gagner du temps ; en réalité, cela crée un problème qui s’accumule. Plus vous attendez, plus les mises à jour s’empilent, et plus la mise à niveau finale devient difficile.

Après deux ou trois releases sautées, l’effort de mise à niveau peut rivaliser avec l’implémentation initiale. Du code spécifique qui fonctionnait en version N peut ne plus compiler en N+3, les dépendances divergent et l’effort de test se multiplie. Des changements de plateforme comme le passage à Java 21 et Spring 6 rendent cela très concret ; nous décrivons ce que cette migration implique dans notre guide Java 21 et Spring 6 pour SAP Commerce Cloud.

Comment l’éviter : traitez les mises à niveau comme de la maintenance courante, pas comme des projets. Réservez chaque année un budget fixe aux mises à jour de Commerce Cloud et appliquez-les dans le cycle de release qui suit leur disponibilité. Si vous ne pouvez pas mettre à niveau aussi souvent, vos personnalisations sont probablement trop nombreuses, ce qui nous amène à l’erreur 3.

Erreur 3 : sur-personnaliser la plateforme

Le framework d’extensions de Commerce Cloud permet de modifier presque tout. Trop facilement. Chaque extension spécifique est du code que vous possédez, maintenez et testez à chaque mise à niveau. Chacune alourdit la mise à niveau, élargit la surface de test et crée des risques de compatibilité.

Une installation comptant une centaine d’extensions spécifiques ou plus peut transformer chaque mise à niveau en projet de plusieurs mois. Les consolider en un ensemble restreint et justifié, couvrant les mêmes fonctions métier, est souvent le moyen le plus rapide de rendre les mises à niveau à nouveau routinières : mêmes résultats, une fraction de la maintenance.

Les pires cas : modifier les définitions de base du type system, surcharger les contrôleurs standard et remplacer des fonctions standard par des implémentations spécifiques qui font presque la même chose avec de légères différences.

Comment l’éviter : avant de créer une extension spécifique, demandez-vous si la configuration standard suffit. Sinon, utilisez les points d’extension de la plateforme et, côté storefront, les mécanismes de personnalisation de SAP Composable Storefront plutôt que de modifier le code de base. Fixez une limite au nombre d’extensions spécifiques (10 à 15 est un objectif raisonnable pour un projet de complexité moyenne) et documentez la justification métier de chacune.

Pour voir comment nous gardons les personnalisations légères tout en tirant le meilleur de la plateforme, consultez notre page solution SAP Commerce Cloud.

Erreur 4 : des exigences métier floues ou irréalistes

Selon une enquête de Gartner, seules 48 % des initiatives numériques atteignent ou dépassent leurs objectifs métier (Gartner, 2024). Des exigences peu claires y contribuent souvent.

« Nous voulons une plateforme e-commerce comme Amazon » n’est pas une exigence. « Il nous faut un storefront B2B avec des prix spécifiques par client, des quantités minimales de commande, des workflows d’approbation et une connexion à notre SAP ERP pour la disponibilité en temps réel » en est une.

Quand les exigences métier sont floues, l’équipe d’intégration comble les lacunes par des hypothèses, et ces hypothèses sont souvent fausses. Quelques mois plus tard, l’écart devient visible, et coûteux : reprises, dérive du périmètre et un système qui ne correspond pas aux besoins des utilisateurs.

Comment l’éviter : définissez les exigences au niveau des processus, pas des fonctionnalités. Utilisez des exemples concrets : « Lorsqu’un acheteur du client X se connecte, il voit sa liste de prix négociée et l’historique de ses commandes des 12 derniers mois. » Parcourez chaque parcours utilisateur : navigation, recherche, configuration des produits, commande, suivi des commandes et retours.

Erreur 5 : ignorer la performance jusqu’à ce qu’il soit trop tard

Une boutique lente coûte des ventes et, en B2B, elle coûte aussi la confiance des acheteurs qui l’utilisent chaque jour.

La performance de Commerce Cloud dépend d’une indexation de recherche correcte, de la configuration du cache, du paramétrage du CDN et d’un code spécifique efficace. Beaucoup d’équipes se concentrent uniquement sur les fonctionnalités pendant le développement et ne découvrent les problèmes de performance qu’aux tests de charge, voire après la mise en production.

Les tueurs de performance les plus courants : requêtes produit non optimisées, en-têtes de cache manquants, trop d’appels API par page, grands catalogues sans indexation adaptée et code spécifique qui contourne le cache intégré de la plateforme.

Comment l’éviter : fixez des budgets de performance dès le premier jour, par exemple un chargement de moins de 2 secondes pour les pages de liste de produits et de moins de 1,5 seconde pour les pages de détail. Lancez des tests de charge après chaque sprint, pas seulement avant la mise en production, et surveillez en continu les temps de requête de recherche, le taux de succès du cache et les temps de réponse des API.

Erreur 6 : sous-planifier la migration des données

La migration des données vers Commerce Cloud couvre les produits, les catégories, les prix, les clients, les commandes historiques et les contenus (pages CMS, médias). Chaque type de données a son propre format ImpEx, ses propres règles de validation et ses propres dépendances. Les produits dépendent des catégories, les prix des produits, les commandes des clients et des produits. La chaîne de dépendances est bien réelle.

Les équipes qui traitent la migration comme un simple script ponctuel découvrent en recette que certains produits ont des images cassées, que des comptes clients sont en double et que les commandes historiques ne s’affichent pas correctement. À ce stade, la date de mise en production est menacée. Nous détaillons les pièges propres à la migration dans les cinq erreurs les plus fréquentes lors d’une migration SAP Commerce.

Comment l’éviter : planifiez la migration comme un chantier à part avec son propre calendrier, pas comme une simple tâche. Effectuez au moins trois cycles de migration complets avant la mise en production : un pour valider la structure, un pour vérifier la qualité des données et un comme répétition générale. Validez les fichiers ImpEx avant l’import et contrôlez de manière automatisée les images, les affectations aux catégories et les associations de prix.

Erreur 7 : des tests insuffisants

Des tests insuffisants sont la voie par laquelle se matérialisent de nombreux dépassements, car les défauts découverts tard coûtent bien plus cher à corriger que ceux détectés tôt.

Les projets Commerce Cloud nécessitent plusieurs types de tests : tests unitaires pour le code spécifique, tests d’intégration pour les connexions API, tests de performance sous charge et recette utilisateur avec des scénarios métier réels. En omettre un seul crée un risque.

La lacune la plus dangereuse est le test d’intégration avec l’ERP. Commerce Cloud envoie les commandes à l’ERP et reçoit en retour les disponibilités, les prix et les mises à jour d’expédition. Si cette intégration n’est pas testée dans des conditions réalistes (utilisateurs simultanés, pics de volume, scénarios d’erreur), les problèmes apparaissent le jour du lancement. Pour les entreprises sous SAP S/4HANA, notre guide SAP Commerce Cloud avec S/4HANA Public Cloud en B2B explique où se situe cette jonction.

Comment l’éviter : consacrez aux tests une part substantielle de l’effort total du projet. Commencez les tests d’intégration à mi-projet, pas la dernière semaine. Utilisez des suites automatisées pour les tests de régression à chaque déploiement, et faites réaliser la recette par de vrais utilisateurs métier sur des scénarios réels, pas par l’équipe d’intégration qui se contente des cas nominaux.

Questions fréquentes

Quelle est l’erreur Commerce Cloud la plus coûteuse à corriger ?

La sur-personnalisation. Supprimer ou refondre des extensions spécifiques profondément ancrées peut coûter plus cher que l’implémentation initiale, et chaque extension alourdit chaque mise à niveau. Chaque extension spécifique devrait avoir une justification métier documentée et une évaluation de son impact sur le chemin de mise à niveau.

Combien de temps devrait durer une implémentation SAP Commerce Cloud ?

Les délais typiques sont de 4 à 9 mois pour un storefront B2B ou B2C standard et de 8 à 14 mois pour des implémentations complexes, multipays et multilingues. Les principaux facteurs sont le nombre d’intégrations, l’ampleur des personnalisations et l’état des données à migrer.

Faut-il migrer de SAP Hybris on-premise vers Commerce Cloud ?

Dans la plupart des cas, oui. La maintenance mainstream de SAP Commerce on-premise a pris fin le 31 juillet 2026 ; la release 2205 ne reçoit plus qu’une maintenance spécifique client, sans nouveaux support packages, modifications légales ni mises à jour des bibliothèques. La question est de savoir comment et à quel rythme, et si Commerce Cloud, l’ERP Edition ou un replatforming convient à votre situation.

À partir de combien d’extensions spécifiques est-ce trop ?

Il n’y a pas de chiffre absolu, mais 10 à 15 restent gérables pour la plupart des projets. Au-delà de 30, l’effort de mise à niveau augmente de façon plus que proportionnelle. Au-delà de 50, chaque mise à niveau tend à devenir un projet de plusieurs mois. Comptez régulièrement vos extensions et consolidez là où c’est possible.

Peut-on utiliser Commerce Cloud pour le B2B et le B2C sur la même plateforme ?

Oui. Commerce Cloud prend en charge plusieurs storefronts (sites) sur une seule instance, chacun avec son catalogue, ses prix, son modèle client et son tunnel de commande. B2B et B2C peuvent coexister, mais la complexité de l’implémentation augmente : planifiez le périmètre et le budget en conséquence.