5 erreurs que commettent les entreprises en quittant SAP Commerce on-premise

Nous avons mené des projets SAP Commerce pour Franke, ANWR et Distrelec, chacun avec ses contraintes, ses délais et son architecture. Les leçons les plus utiles ne sont pas venues de ce qui a bien fonctionné. Elles sont venues des erreurs que nous avons aidé nos clients à éviter, ou dont nous les avons aidés à sortir lorsqu’ils les avaient déjà commises.

Depuis la fin de la maintenance mainstream de SAP Commerce on-premise le 31 juillet 2026 (SAP Help Portal), de nombreuses entreprises planifient la transition sous pression. C’est précisément à ce moment que ces cinq erreurs se commettent. Pour la vue d’ensemble des options (continuer, faire une passerelle, migrer ou quitter SAP), commencez par notre guide sur SAP Commerce on-premise après la fin de la maintenance mainstream. Cet article porte sur la manière de bien réussir la migration.

En bref : les cinq erreurs qui rendent les migrations SAP Commerce lentes et coûteuses sont : copier à l’identique les personnalisations on-premise, sous-estimer la migration des données, transférer la dette technique au lieu de la résorber, tout livrer en un seul big bang et prendre la maintenance spécifique client pour un plan. Chacune s’évite pendant la préparation : passer en revue les personnalisations, analyser les données dès la première semaine, faire le ménage d’abord, livrer par incréments et fixer une date.

Erreur 1 : reproduire à l’identique les personnalisations on-premise

L’erreur la plus coûteuse consiste à vouloir tout emporter sans rien changer.

Les entreprises développent pendant des années des fonctionnalités spécifiques sur leur plateforme on-premise et, au moment de migrer, le réflexe est de tout reprendre. C’est compréhensible : chaque personnalisation a été créée pour une raison. Mais beaucoup étaient des contournements de limites on-premise que SAP Commerce Cloud a déjà résolues. Couches de cache maison, scripts de montée en charge manuels et pipelines de déploiement artisanaux sont pris en charge par la plateforme.

Chaque ligne de code transférée sans nécessité allonge la migration, augmente l’effort de test et les coûts de maintenance futurs, et complique chaque mise à niveau ultérieure (le même effet que nous décrivons dans les sept erreurs SAP Commerce Cloud qui font dérailler les projets).

Ce qu’il faut faire à la place : avant de migrer la moindre ligne de code, passez en revue chaque personnalisation et classez-la : toujours nécessaire, remplaçable par une fonction standard ou obsolète. Seul le premier groupe migre. Dans nos assessments, cette liste est presque toujours plus courte que ce que le client imaginait, et chaque élément supprimé raccourcit le projet.

Erreur 2 : sous-estimer la migration des données

Sur le papier, la migration des données paraît simple : exporter, transformer, importer. En pratique, c’est la phase qui fait le plus souvent déraper les plannings.

Les problèmes commencent par la qualité des données. Les systèmes on-premise accumulent pendant des années des données incohérentes : fiches clients en double, références produit orphelines, commandes aux attributs manquants et structures de catalogue qui ont grandi sans nettoyage. Vient ensuite le volume. Une plateforme B2B de taille moyenne peut contenir plusieurs millions de lignes de commande, et les transférer proprement exige une conception ETL soignée, plusieurs cycles d’essai et une stratégie delta pour la fenêtre de bascule.

Sur les plateformes exploitées depuis de nombreuses années, avec un long historique commercial, le seul mapping des données peut prendre des semaines. Ce temps n’est pas perdu : c’est lui qui empêche un problème de qualité des données d’apparaître après la mise en production.

Ce qu’il faut faire à la place : lancez l’analyse des données dès la première semaine. Vérifiez la qualité des données avant d’écrire le moindre script de migration et prévoyez la migration delta dès le départ, car vous en aurez besoin. Planifiez le travail sur les données comme un chantier à part, avec son propre budget et son propre responsable. Si quelqu’un vous dit que la migration des données, c’est « juste un export et un import », il n’en a jamais fait une à grande échelle.

Erreur 3 : migrer la dette technique au lieu de la résorber

Un système désordonné donne un déploiement cloud désordonné. La dette technique ne disparaît pas quand on change de plateforme : elle suit.

La dette technique que nous rencontrons le plus souvent dans les installations SAP Commerce on-premise :

• Extensions inutilisées. Installées il y a des années pour une fonctionnalité abandonnée depuis, toujours chargées, toujours sources de conflits de dépendances.
• Configuration codée en dur. Des valeurs propres à l’environnement inscrites dans le code au lieu d’être externalisées. Cela fonctionne on-premise, où vous maîtrisez l’infrastructure, et casse dans le cloud, où les environnements sont provisionnés pour vous.
• Intégrations obsolètes. Des connexions vers des systèmes remplacés ou arrêtés, qui tournent encore et ajoutent de la complexité.
• Données de test en production. Des restes d’anciennes recettes qui faussent les analyses et créent de fausses dépendances.

Le temps consacré au ménage avant le développement se rentabilise pendant le développement, car l’équipe ne court pas après des dépendances fantômes.

Ce qu’il faut faire à la place : réalisez un audit de la dette technique avant de lancer la migration. Supprimez les extensions inutilisées, externalisez la configuration, décommissionnez les intégrations mortes et purgez les données de test. Traitez-le comme un livrable à part entière, avec sa propre validation. L’équipe de migration doit hériter d’une base de code propre, pas d’un musée.

Erreur 4 : tout livrer en un seul big bang

Les grands programmes technologiques ont un bilan médiocre : selon BCG, plus des deux tiers des programmes technologiques de grande envergure ne devraient pas être livrés dans les délais, le budget et le périmètre prévus (BCG, 2024). Dans les migrations commerce, trois facteurs jouent contre une livraison unique en big bang :

• Les exigences évoluent en cours de projet. Le métier avance, et SAP livre des mises à jour de la plateforme en pleine migration. Ce que vous avez spécifié le premier mois peut être dépassé le cinquième.
• Des tests tardifs trouvent des problèmes tardifs. Une erreur de mapping découverte le dernier mois implique de retravailler tout le développement.
• Les bascules big bang concentrent le risque. Basculer tous les marchés, storefronts et intégrations en un seul week-end, c’est accepter qu’une seule défaillance touche tout.

Le lancement commerce de Franke en 90 jours a fonctionné parce qu’il a été livré en incréments parallèles et testés plutôt qu’en une bascule finale ; le playbook des 90 jours décrit l’approche.

Ce qu’il faut faire à la place : découpez la migration en cycles de livraison de deux à quatre semaines, chacun produisant un incrément fonctionnel et testable. Priorisez selon la valeur métier : d’abord le storefront au plus fort trafic, stabilisez-le, puis étendez. Testez l’intégration ERP sous charge réaliste dès la mi-projet, pas la dernière semaine. Pilotez le déploiement avec des feature flags.

Erreur 5 : prendre la maintenance spécifique client pour un plan

Avant le 31 juillet 2026, cette erreur s’appelait « démarrer trop tard ». Elle a aujourd’hui une nouvelle forme : comme la plateforme continue de tourner et que SAP résout encore les problèmes connus dans le cadre de la maintenance spécifique client, il est tentant de considérer cette phase comme une salle d’attente confortable.

Ce n’en est pas une. La maintenance spécifique client n’apporte ni nouveaux support packages, ni modifications légales, ni mises à jour des bibliothèques, et la résolution de nouveaux problèmes peut être facturée (SAP Support). Pendant ce temps, une migration précipitée est une migration coûteuse : pas de temps pour le ménage, des tests compressés, aucun plan de repli pour la bascule et des tarifs plus élevés, parce que les équipes SAP Commerce expérimentées sont déjà prises par ceux qui ont démarré plus tôt.

Ce qu’il faut faire à la place : fixez une date cible et planifiez à rebours. Même une migration rapide nécessite une phase de préparation pour l’assessment, le ménage et le choix du partenaire avant le début du développement. 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. Le reste figure dans la checklist pas à pas de migration SAP Hybris.

Ce qui relie les cinq erreurs

Toutes les erreurs de cette liste ont la même cause : traiter la migration comme une copie technique plutôt que comme une occasion de simplifier. Les entreprises qui migrent sans heurts vérifient avant de construire, font le ménage avant de déménager, livrent par incréments et fixent une date assez tôt pour garder des options.

Un point de plus pour les entreprises sous SAP ERP : la plupart des surprises d’une migration se trouvent à la jonction entre commerce et ERP (prix, disponibilité, transfert des commandes), pas dans la boutique elle-même. Si un passage à S/4HANA figure aussi sur votre feuille de route, planifiez les deux ensemble ; notre guide SAP Commerce Cloud avec S/4HANA Public Cloud en B2B montre comment les deux s’articulent.

Notre offre complète autour de SAP Commerce Cloud, de la planification de la migration à la réalisation avec Composable Storefront, se trouve sur notre page solution SAP Commerce Cloud.

---

Vous planifiez une migration SAP Commerce ? Nous menons des assessments de migration structurés qui identifient les personnalisations supprimables, analysent la qualité des données et estiment un calendrier réaliste. Contactez-nous.

Questions fréquentes

Combien de temps dure une migration typique vers SAP Commerce Cloud ?

Une migration typique dure de 6 à 12 mois, un projet accéléré bien discipliné de 4 à 6 mois. À l’extrême le plus rapide, nous avons mis en production la plateforme SAP Commerce Cloud de Franke en 90 jours. La variable principale n’est pas la taille de la plateforme, mais la quantité de dette technique et de code spécifique que vous emportez ; c’est pourquoi la phase de préparation compte le plus.

Quelle est la différence entre SAP Commerce on-premise et SAP Commerce Cloud ?

SAP Commerce Cloud est la version de SAP Commerce exploitée par SAP dans le cloud : SAP gère l’infrastructure, la montée en charge, les déploiements et les mises à jour de la plateforme. SAP Commerce on-premise (dernière release 2205) a quitté la maintenance mainstream le 31 juillet 2026 et ne reçoit plus qu’une maintenance spécifique client, donc plus de nouveaux support packages, de modifications légales ni de mises à jour des bibliothèques.

Combien coûte une migration SAP Commerce ?

Cela dépend surtout du nombre de personnalisations, d’intégrations et de storefronts, ainsi que de l’état de vos données : un chiffre fiable nécessite donc un assessment de votre code. Les économies les plus importantes viennent de la suppression des personnalisations et des données inutiles avant le lancement de la migration, pas de la négociation des tarifs journaliers.

Pouvons-nous migrer SAP Commerce par étapes plutôt qu’en une seule fois ?

Oui, et nous le recommandons. Migrez d’abord la plateforme de base, puis un storefront ou un marché après l’autre, chacun testé avant de passer au suivant. Les feature flags permettent de piloter le déploiement sans bascule big bang un week-end.

Que faire de nos personnalisations pendant la migration ?

Ne partez pas du principe que chaque personnalisation doit migrer. Classez-les comme toujours nécessaires, remplaçables par une fonction standard ou obsolètes. De nombreuses personnalisations on-premise, comme le cache maison, les scripts de montée en charge et les pipelines de déploiement, sont gérées nativement par SAP Commerce Cloud.