5 erreurs que commettent les entreprises lors de la migration hors de SAP Commerce On-Prem

Nous avons migré des plateformes SAP Commerce pour Franke, ANWR et Distrelec. Chaque projet, sans exception, nous a appris quelque chose. Mais les leçons les plus précieuses sont venues des erreurs que nous avons aidé nos clients à éviter (ou à corriger quand ils avaient déjà mis le pied dedans).

83 % des projets de migration de données échouent ou dépassent leur budget et leur calendrier (Bloor Group, 2023). Les migrations SAP Commerce ne font pas exception. Les cinq erreurs ci-dessous expliquent pourquoi la plupart de ces projets partent de travers.

TL;DR : 83 % des migrations de données dépassent leur budget (Bloor Group, 2023). De nos projets SAP Commerce avec Franke, ANWR et Distrelec, les cinq erreurs les plus courantes sont : répliquer les personnalisations on-prem à l’identique, sous-estimer la migration des données, ignorer la dette technique, livrer en cascade et démarrer trop tard. Les approches agiles affichent 42 % de réussite contre 13 % pour le waterfall (Standish Group, 2020). Commencez tôt, nettoyez d’abord, livrez par itérations.

Pourquoi les entreprises répliquent-elles les personnalisations on-prem à l’identique ?

90 % des entreprises ayant migré leur plateforme e-commerce ont constaté des améliorations de ventes et de chiffre d’affaires (commercetools, 2024). Mais l’erreur la plus coûteuse, à elle seule, est d’essayer de tout emporter tel quel.

Les entreprises passent des années à construire des fonctionnalités personnalisées sur leur plateforme on-prem. Quand vient la migration, l’instinct est de tout déplacer à l’identique. Je le comprends. Vous avez construit tout cela pour une raison. Mais voilà : beaucoup de ces personnalisations étaient des contournements pour des limitations on-prem que Commerce Cloud a déjà résolues. Couches de cache sur mesure, scripts de mise à l’échelle manuels, pipelines de déploiement maison. Commerce Cloud gère tout cela nativement.

Nous avons vu des migrations où 30 à 40 % du code personnalisé était inutile sur la plateforme cible. Chaque ligne de ce code superflu ajoute du temps de migration, de l’effort de test et des coûts de maintenance futurs.

Ce qu’il faut faire à la place : avant de migrer une seule ligne de code, auditez chaque personnalisation. Classez-les : toujours nécessaire, remplaçable par une capacité de la plateforme, ou obsolète. Nous menons une évaluation structurée qui identifie généralement 25 à 35 % des personnalisations comme supprimables. Cela réduit directement le coût et le calendrier.

Comment la migration des données fait-elle dérailler les calendriers ?

83 % des projets de migration de données échouent ou dépassent leur budget et leur calendrier (Bloor Group, 2023). La migration des données semble simple sur le papier : export depuis la source, transformation, import vers la cible. En pratique, c’est la phase qui fait dérailler le plus de calendriers. Je l’ai vu arriver plus de fois que je ne peux compter.

Les problèmes commencent par la qualité des données. Les systèmes on-prem accumulent des années de données incohérentes. Doublons de fiches clients. Références produits orphelines. Commandes avec des attributs manquants. Structures de catalogue qui ont évolué sans nettoyage. Une étude évaluée par les pairs a montré que 94 % des feuilles de calcul d’entreprise contiennent des erreurs (Poon et al., Frontiers of Computer Science, 2024). Ce désordre se transfère directement dans les systèmes alimentés par des imports de tableurs.

Puis il y a le volume. Une plateforme de commerce B2B de taille moyenne peut compter 50 millions de lignes de commande, 2 millions de fiches clients et 500’000 variantes de produits. Migrer ces données proprement exige une conception ETL soignée, plusieurs exécutions de test et une stratégie de migration delta pour la fenêtre de bascule.

Un projet sur lequel nous avons travaillé comportait des données couvrant plus de 15 ans d’historique commercial. Le seul mapping des données a pris trois semaines. Cet investissement nous a évité un désastre de qualité des données qui serait apparu après le go-live.

Ce qu’il faut faire à la place : commencez la découverte des données dès la première semaine. Profilez vos données pour détecter les problèmes de qualité avant d’écrire un seul script de migration. Construisez la capacité de migration delta dès le départ, car vous en aurez besoin. Et budgétez 20 à 25 % de votre effort total de migration pour le travail sur les données. Si quelqu’un vous dit que la migration de données est « juste un export/import », il n’en a jamais réalisé une à grande échelle.

Que se passe-t-il quand vous ne nettoyez pas d’abord la dette technique ?

47 % des responsables IT citent la dette technique comme facteur principal de surcoûts sur l’infrastructure numérique (IDC, 2024). Migrer un système désordonné produit un déploiement cloud désordonné. La dette technique ne disparaît pas quand vous changez de plateforme. Elle vous suit.

La dette technique courante que nous trouvons dans les déploiements SAP Commerce on-prem :

Extensions inutilisées. Installées il y a des années pour une fonctionnalité ensuite abandonnée. Toujours chargées, toujours consommatrices de ressources, toujours sources de conflits de dépendances.

Configurations codées en dur. Valeurs spécifiques à l’environnement intégrées dans le code au lieu d’être externalisées. Ça fonctionne on-prem où vous contrôlez l’infrastructure. Ça casse dans le cloud où les environnements sont dynamiques.

Intégrations obsolètes. Connexions à des systèmes remplacés ou mis hors service. L’intégration tourne encore, génère encore des logs, ajoute encore de la complexité pour rien.

Données de test en production. Restes de cycles UAT jamais nettoyés. Elles polluent les analyses et créent de fausses dépendances.

Une phase du projet ANWR a nécessité deux semaines de nettoyage avant que le travail de migration proprement dit puisse commencer. Cet investissement initial a réduit le calendrier de migration d’un mois, car l’équipe ne déboguait pas des dépendances fantômes pendant la construction. Deux semaines bien investies.

Ce qu’il faut faire à la place : menez un audit de dette technique 2 à 3 mois avant le début de la migration. Supprimez les extensions inutilisées, externalisez les configurations, dépréciez les intégrations mortes et purgez les données de test. Traitez cela comme un livrable autonome avec son propre calendrier et sa propre validation. L’équipe de migration doit hériter d’une base de code propre, pas d’un musée.

Pourquoi la livraison en cascade échoue-t-elle dans les migrations commerce ?

Les projets agiles réussissent dans 42 % des cas contre 13 % pour le waterfall (Standish Group CHAOS Report, 2020). Cet écart se creuse dans les migrations commerce, où trois choses conspirent contre la livraison big-bang.

Les exigences évoluent pendant le projet. Les besoins métier changent. SAP publie des mises à jour de la plateforme en pleine migration. Ce que vous avez spécifié au mois un peut être obsolète au mois cinq.

Les tests tardifs révèlent des problèmes tardifs. Quand vous testez tout à la fin, les problèmes s’accumulent. Une erreur de mapping de données découverte au mois huit exige une reprise sur toute la construction. C’est une découverte qui coûte cher.

Les bascules big-bang sont à haut risque. Basculer chaque marché, chaque vitrine et chaque intégration en un seul week-end crée une exposition maximale. Un seul échec affecte tout.

La migration Franke a réussi en 90 jours en partie parce que nous avons livré de manière itérative. La plateforme centrale d’abord, puis les vitrines, puis les intégrations. Chaque phase testée et validée avant le démarrage de la suivante. Exécution nette.

Ce qu’il faut faire à la place : découpez la migration en cycles de livraison de 2 à 4 semaines. Chaque cycle produit un incrément fonctionnel et testable. Priorisez par valeur métier : migrez d’abord votre vitrine à plus fort trafic, stabilisez-la, puis étendez. Utilisez des feature flags pour contrôler le déploiement.

Quel est le vrai coût d’un démarrage trop tardif ?

C’est la méta-erreur. Et la plus courante.

Les entreprises connaissent l’échéance EoMM. Elles en discutent en comités de pilotage. Elles l’ajoutent aux registres de risques. Et puis elles n’agissent pas jusqu’à ce qu’il soit trop tard pour un calendrier confortable. Je l’ai vu arriver encore et encore.

Une migration précipitée est une migration coûteuse. Voici ce qui se passe quand vous démarrez trop tard.

Pas de temps pour le nettoyage. Vous migrez le désordre tel quel, puis passez des mois à le corriger dans le cloud. Pas de temps pour une vraie planification. Tarifs premium pour les talents, car chaque partenaire d’implémentation est complet. Tests compressés où des raccourcis sont pris et où des problèmes qui auraient dû être détectés en recette atteignent la production. Pas de plan de repli si quelque chose tourne mal pendant la bascule.

Nous voyons des entreprises qui démarrent 12 mois avant l’EoMM terminer leur migration pour 30 à 40 % de moins que celles qui démarrent avec 4 mois devant elles. Le travail est le même. La différence de coût vient entièrement du rythme, de la planification et de la disponibilité des bonnes personnes.

Ce qu’il faut faire à la place : commencez maintenant. Pas le trimestre prochain. Maintenant. Même si la migration elle-même ne prend que 90 jours, comme pour Franke, il vous faut du temps pour l’évaluation, le nettoyage, la sélection du partenaire et l’alignement de l’équipe. Une migration de 90 jours exige une phase de préparation de 30 à 60 jours. Intégrez-la dans votre calendrier.

Quel schéma relie ces cinq erreurs ?

Chaque erreur de cette liste partage une cause racine : traiter la migration comme un exercice technique plutôt qu’une transformation métier. 90 % des entreprises ayant migré de plateforme ont constaté des améliorations de chiffre d’affaires (commercetools, 2024). Mais seulement quand elles ont abordé le passage de manière stratégique.

Les entreprises qui migrent en douceur sont celles qui auditent avant de construire, nettoient avant de déplacer, livrent par incréments et commencent assez tôt pour avoir des options.

Nous avons livré des migrations SAP Commerce pour ANWR, Franke, Distrelec et d’autres. Chacune avec des contraintes, des calendriers et des architectures différents. Le fil conducteur des projets réussis est la discipline dans la préparation. Prima vista, cela semble évident. Mais la statistique de 83 % d’échec vous dit que ça ne l’est pas.

Pour une vue complète de nos compétences SAP Commerce Cloud, de la planification de la migration à la livraison du Composable Storefront, consultez notre page solution SAP Commerce Cloud.

Vous planifiez une migration SAP Commerce ? Nous menons des évaluations de migration structurées qui identifient les personnalisations supprimables, profilent la qualité des données et estiment des calendriers réalistes. Contactez-nous.

Questions fréquentes

Combien de temps dure une migration SAP Commerce Cloud typique ?

Cela dépend de la complexité. Notre plus rapide (Franke) s’est achevée en 90 jours. La plupart des plateformes B2B de taille moyenne prennent 4 à 6 mois, préparation comprise. La plus grande variable n’est pas la taille de la plateforme. C’est la quantité de dette technique et de code sur mesure. Les entreprises qui mènent d’abord une phase de nettoyage raccourcissent généralement le calendrier de construction de 20 à 30 %.

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

SAP Commerce Cloud est la version gérée et hébergée dans le cloud de SAP Commerce. Elle gère automatiquement l’infrastructure, la montée en charge, les déploiements et les correctifs de sécurité. L’on-prem vous donne un contrôle total mais exige que vous gériez tout cela vous-même. Avec l’approche de la fin de la maintenance standard (EoMM) de SAP, les clients on-prem doivent planifier leur passage vers Commerce Cloud ou une plateforme alternative.

Combien coûte une migration SAP Commerce ?

Les coûts varient largement selon le volume de personnalisations, la complexité des données et le nombre d’intégrations. Un repère utile : budgétez 20 à 25 % de l’effort total rien que pour la migration des données. Les entreprises qui démarrent tôt (12 mois ou plus avant l’échéance) dépensent généralement 30 à 40 % de moins que celles qui se précipitent. L’évaluation de migration est le meilleur premier pas. Elle produit une estimation de coût réaliste basée sur votre base de code réelle.

Peut-on migrer SAP Commerce par phases plutôt qu’en une fois ?

Oui, et nous le recommandons fortement. Migrer une vitrine ou un marché à la fois réduit le risque et détecte les problèmes plus tôt. Les approches agiles affichent un taux de réussite de 42 % contre 13 % pour le waterfall (Standish Group, 2020). Les feature flags vous permettent de contrôler le déploiement sans bascules big-bang.

Que faire des personnalisations pendant la migration ?

Ne supposez pas que chaque personnalisation doit être déplacée. D’après notre expérience, 25 à 35 % des personnalisations on-prem sont inutiles sur SAP Commerce Cloud parce que la plateforme les gère nativement. Avant de migrer le code, menez une évaluation structurée : classez chaque personnalisation comme toujours nécessaire, remplaçable par une capacité de la plateforme, ou obsolète. Cette seule étape a le plus grand impact sur la réduction du coût et du calendrier de migration.