De SAP Hybris à Commerce Cloud en 90 jours : un guide de migration

Nous avons migré Franke de SAP Hybris vers SAP Commerce Cloud en 90 jours. Quatre-vingt-dix. L’équipe IT du client a cru à une plaisanterie lorsque nous avons posé ce calendrier sur la table. La plupart des entreprises traitent ce type de projet comme un chantier de 8 à 12 mois.

SAP nous a décerné un Quality Award pour ce travail. Et cet article partage le guide réel : la méthodologie, le calendrier, les décisions qui l’ont rendu possible. Pas la version marketing. La vraie.

TL;DR : nous avons migré Franke de SAP Hybris vers Commerce Cloud en 90 jours (SAP Quality Award). La clé : 30 jours de préparation avant le kickoff, une gestion impitoyable du périmètre (35 % des personnalisations éliminées), des chantiers parallèles et une livraison itérative. Les approches agiles affichent 42 % de réussite contre 13 % pour le waterfall (Standish Group, 2020). Ce guide couvre toutes les phases, de l’audit au go-live.

Besoin d’un partenaire plutôt que d’un guide ? Spadoom est SAP Gold Partner spécialisé dans l’implémentation de SAP Commerce Cloud en Suisse, Allemagne, Autriche et Italie — Cloud Edition et la nouvelle ERP Edition. Demandez un appel de cadrage gratuit ou lisez le cas client Franke en 90 jours.

Pourquoi 90 jours sont-ils atteignables ?

83 % des projets de migration de données échouent ou explosent leur budget (Bloor Group, 2023). De quoi faire frémir. Mais notre expérience montre que la plupart des calendriers de migration trop longs sont gonflés par du gaspillage, pas par la complexité.

Une migration en 90 jours ne consiste pas à rogner sur les coins. Elle consiste à éliminer trois choses qui dévorent le temps sans rien apporter.

La paralysie par l’analyse. Les équipes passent des mois à documenter des exigences qui existent déjà dans le système en production. Il suffit de regarder ce que vous avez. Le système est juste là, sous vos yeux.

La réplication 1:1 de personnalisations inutiles. Déplacer du code dont la plateforme cible n’a pas besoin. N’emportez pas un contournement de 2017 simplement parce qu’il existe. Si la roue était cassée, ne l’embarquez pas avec vous.

Les phases séquentielles avec délais de passation. Attendre des validations, des handovers, des changements de contexte entre équipes. Chaque passation coûte une semaine.

Supprimez ces trois facteurs et le vrai travail (migration des données, configuration de la plateforme, reconnexion des intégrations, tests) tient dans 90 jours pour une plateforme de commerce de taille moyenne.

Que se passe-t-il avant le démarrage du chronomètre ? (Semaines -4 à 0)

Le chronomètre des 90 jours démarre au kickoff. Mais ce sont les 30 jours qui précèdent le kickoff qui font la différence entre un sprint maîtrisé et une course chaotique. Les projets agiles réussissent dans 42 % des cas contre 13 % pour le waterfall (Standish Group, 2020). Cet avantage commence par une préparation soignée.

Audit de la plateforme (semaines -4 à -3)

Nous cartographions tout ce qui existe dans l’instance SAP Hybris actuelle. Extensions personnalisées : les compter, les classer (encore nécessaire / remplaçable / obsolète), estimer l’effort de migration pour chacune. Modèles de données : documenter les types personnalisés, les relations, les attributs. Identifier ce qui se mappe directement sur Commerce Cloud et ce qui demande une transformation. Intégrations : lister chaque connexion entrante et sortante (ERP, PIM, CRM, paiement, expédition, fiscalité). Documenter les protocoles, les formats de données, les fréquences. Points chauds de personnalisation : identifier les 20 % de code personnalisé qui couvrent 80 % de la logique métier.

Pour Franke, cet audit a révélé que 35 % des extensions personnalisées étaient des contournements de limitations on-premise que Commerce Cloud gère nativement. Nous les avons immédiatement sorties du périmètre. Trois semaines d’effort de migration économisées d’un coup. Voilà la force d’un audit mené correctement.

Profilage des données (semaines -3 à -2)

Avant de toucher aux outils de migration, comprenez vos données. 64 % des organisations citent la qualité des données comme leur principal défi d’intégrité (McKinsey, 2024). Profilez chaque entité sur la complétude, la cohérence et la qualité. Identifiez les doublons, les enregistrements orphelins, les données auxquelles personne n’a touché depuis 2 ans ou plus. Construisez et testez votre pipeline ETL avec un petit échantillon. Un point fait à temps en épargne cent.

Mise en place des environnements (semaines -2 à -1)

Provisionner les environnements SAP Commerce Cloud (développement, staging, production). Configurer les pipelines CI/CD. Mettre en place la supervision et les alertes. Ouvrir les accès à tous les membres de l’équipe. Rien de spectaculaire. Tout est nécessaire.

Alignement de l’équipe (semaine -1)

Finaliser le backlog. Attribuer une responsabilité claire à chaque chantier : plateforme, données, intégrations, frontend, tests. Convenir de la Definition of Done pour chaque incrément. Mettre en place les stand-ups quotidiens et les démos hebdomadaires avec les parties prenantes. Au jour 1, chacun sait ce qu’il a à faire.

Que livre-t-on lors du sprint 1 ? (Jours 1-21)

Les trois premières semaines. La plateforme cœur tourne sur Commerce Cloud avec vos modèles de données et la configuration de base. Aucune distraction.

Migration du modèle de données. Transférer les types personnalisés, les enums, les relations vers Commerce Cloud. Valider par rapport à l’audit de la plateforme.

Logique métier cœur. Migrer les 20 % critiques de personnalisations identifiées lors de l’audit. Calcul du panier, règles tarifaires, configuration du moteur de promotions, calcul des taxes. Ce sans quoi l’entreprise ne peut pas tourner.

Storefront de base. Déployer le Composable Storefront avec votre catalogue produits. Pas de style personnalisé pour l’instant. La justesse fonctionnelle d’abord.

Premier chargement de données. Lancer une migration complète vers l’environnement de staging. Valider les volumes d’enregistrements, l’intégrité des données, les flux métier clés.

Ce qui n’est PAS livré : les retouches de design visuel, les intégrations non critiques (analytique, plateformes d’avis, fidélité), l’optimisation des performances, la logique métier des cas limites. Au sprint 1, on dit non à beaucoup de choses. C’est précisément le but.

Jalon au jour 21 : un storefront opérationnel sur Commerce Cloud staging avec des données réelles, la logique métier cœur et un parcours de commande de base. Les parties prenantes peuvent parcourir le catalogue, ajouter au panier, finaliser une commande. Ce n’est pas beau. Ça fonctionne.

Comment les intégrations s’assemblent-elles au sprint 2 ? (Jours 22-50)

La plateforme cœur étant prouvée, le sprint 2 reconnecte l’écosystème et affine l’expérience. Les intégrations sont traitées par ordre de criticité métier :

1. ERP / gestion des commandes : export des commandes, synchronisation des stocks, mises à jour tarifaires
2. Prestataire de paiement : reconnecter la passerelle de paiement avec l’extension paiement de Commerce Cloud
3. Expédition / logistique : calcul des tarifs, génération d’étiquettes, mises à jour de suivi
4. PIM / contenus : flux de données produits, synchronisation des médias
5. CRM / CDP : synchronisation des données clients

Pour chaque intégration : valider le contrat d’API existant, mettre à jour les endpoints et l’authentification, exécuter des tests de bout en bout avec des données réelles, documenter les éventuelles différences de comportement.

En parallèle : appliquer le style de marque au Composable Storefront, implémenter les composants UI personnalisés, optimiser le mobile, traiter les exigences SEO (balises meta, données structurées, redirections d’URL depuis les anciens chemins).

Jalon au jour 50 : un déploiement Commerce Cloud entièrement intégré, toutes les intégrations critiques en production, un frontend conforme à la marque, un parcours de commande de bout en bout, de la navigation à la livraison. On commence à voir le bout du tunnel.

Qu’est-ce qui rend le sprint 3 différent ? (Jours 51-90)

La phase finale est une affaire de confiance. Vous disposez déjà d’un système qui fonctionne. Reste à prouver qu’il est prêt pour la production.

Tests de performance (jours 51-60). Tests de charge avec des profils de trafic réalistes. Simulation des journées de pic. Identifier et résoudre les goulots d’étranglement. Valider le comportement de l’auto-scaling. Mesurer les temps de chargement des pages par rapport aux objectifs.

Recette utilisateur (jours 55-70). Les utilisateurs métier testent chaque parcours critique. Comptes clients réels, données produits réelles. Vérifier toutes les intégrations en conditions réelles. Résoudre toutes les anomalies P1 et P2.

Répétition générale de la migration des données (jours 65-75). Exécuter le pipeline complet de migration de bout en bout. Mesurer le temps écoulé : c’est ce qui définit votre fenêtre de bascule. Valider la migration delta pour les données créées entre la répétition et le go-live. Tester les procédures de rollback. Cette étape n’est pas négociable. La sauter, c’est jouer à la roulette.

Go-live et stabilisation (jours 85-90). Exécuter le runbook de go-live. Migration delta des données. Bascule DNS. Surveiller pendant 48 heures avec l’ensemble de l’équipe en astreinte.

Qu’est-ce qui a fait la réussite de la migration Franke ?

90 % des entreprises ayant migré leur plateforme e-commerce ont constaté une amélioration de leur chiffre d’affaires (commercetools, 2024). Mais toutes les migrations ne livrent pas ces résultats. Avec le recul sur Franke, cinq facteurs ont rendu le calendrier des 90 jours possible.

Une gestion impitoyable du périmètre. Nous n’avons pas tout migré. Nous avons migré ce dont l’entreprise avait besoin. Les 35 % de personnalisations inutiles sont restés derrière nous. Pas de nostalgie. Pas de « mais on a toujours fait comme ça ».

Des chantiers parallèles. Plateforme, données, intégrations et frontend ont avancé en parallèle, avec des points de synchronisation quotidiens. Pas de passations séquentielles. Quand une équipe rencontrait un blocage, les autres continuaient d’avancer.

Un investissement précoce sur les données. Le profilage des données a démarré avant le kickoff. Au jour 1, nous savions exactement ce que nous migrions et ce que nous laissions derrière. Zéro surprise côté données.

Une livraison itérative avec démos hebdomadaires. Les parties prenantes constataient les progrès chaque semaine. Les problèmes remontaient tôt. Les ajustements de trajectoire se faisaient en jours, pas en mois.

Une équipe expérimentée. Notre équipe avait déjà fait ce travail. Elle connaissait la plateforme, les schémas de migration, les écueils habituels. Cela compte plus qu’on ne le pense. Prima vista, on dirait n’importe quelle migration, mais la reconnaissance des schémas issus de projets antérieurs fait gagner des semaines.

SAP a décerné un Quality Award au projet pour la méthodologie, l’engagement des parties prenantes et la qualité de la livraison. Vitesse et qualité ne sont pas des opposés. Une migration ciblée et bien planifiée livre les deux. Festina lente, comme disaient les Romains.

Quand faut-il démarrer ?

Le guide fonctionne. Mais le chronomètre des 90 jours ne se déclenche qu’une fois la préparation terminée. Si vous êtes confronté à l’échéance EoMM de juillet 2026 (SAP Help Portal, 2026), le calcul est simple :

30 jours de préparation + 90 jours de migration = 120 jours au total. Pour un go-live d’ici juillet 2026, démarrez la préparation au plus tard en mars 2026. Pour un go-live confortable avec marge, démarrez d’ici janvier 2026.

Plus vous démarrez tard, plus le calendrier sera comprimé. Et les calendriers comprimés coûtent plus cher. C’est ainsi.

Pour une vision plus large de ce que livre SAP Commerce Cloud (tarification, cas d’usage sectoriels, méthodologie d’implémentation), consultez notre page solution SAP Commerce Cloud.

Nous passerons en revue votre instance SAP Hybris, cartographierons vos personnalisations, profilerons vos données et construirons un plan de 90 jours réaliste, ajusté à votre situation. Contactez-nous et transformons votre échéance EoMM en projet de 90 jours.

Besoin d’aide pour passer à la mise en œuvre ?

Spadoom implémente SAP Commerce Cloud de bout en bout — Cloud Edition pour B2B/B2C entreprise, ERP Edition pour PME sur S/4HANA Public Cloud, et migrations Hybris depuis on-premise. Consultez le cas client Franke en 90 jours pour un exemple concret, ou planifiez un appel de cadrage.

Foire aux questions

90 jours sont-ils réalistes pour toute migration SAP Commerce ?

Honnêtement, cela dépend de la complexité. Quatre-vingt-dix jours conviennent aux plateformes de commerce de taille moyenne avec une phase de préparation rigoureuse. Les déploiements plus importants, avec plusieurs storefronts, des travaux d’intégration lourds ou de gros volumes de données, peuvent nécessiter 4 à 6 mois. La variable clé n’est pas la taille de la plateforme. C’est la quantité de personnalisations inutiles et de dette technique en jeu. Notre audit structuré identifie en général 25 à 35 % des personnalisations comme supprimables, ce qui raccourcit directement le calendrier.

Quel est le plus grand risque d’une migration en 90 jours ?

La migration des données, sans hésitation. 83 % des projets de migration de données dépassent les budgets ou les délais (Bloor Group, 2023). C’est pourquoi nous démarrons le profilage des données dans la phase de pré-migration, avant que le chronomètre des 90 jours ne se déclenche. Au jour 1 du sprint 1, nous connaissons déjà le volume de données, les problèmes de qualité et les transformations à prévoir. La répétition générale du sprint 3 valide le pipeline complet avant le go-live.

Combien de personnes faut-il pour une migration en 90 jours ?

L’équipe Franke était resserrée : 3 à 4 consultants Spadoom plus 2 à 3 ressources côté client (product owner, business analyst, référent IT). Soit 6 à 7 personnes au total. Ce n’est pas une question de taille d’équipe. C’est une question de chantiers parallèles avec des responsabilités claires et des points de synchronisation quotidiens. Une équipe plus large avec des passations séquentielles serait en réalité plus lente.

Que devient le SEO lors d’une migration de Hybris vers Commerce Cloud ?

Les changements de structure d’URL imposent un plan de redirections solide. Nous le traitons au sprint 2 : cartographier toutes les anciennes URL vers les nouveaux chemins, mettre en place des redirections 301, mettre à jour les données structurées et les balises meta, soumettre le nouveau sitemap à Google. Bien fait, le trafic organique se rétablit en 2 à 4 semaines. Le Composable Storefront vous offre aussi de meilleurs Core Web Vitals d’emblée, ce qui améliore souvent le classement après migration.

Pouvons-nous faire tourner l’ancienne plateforme Hybris et la nouvelle Commerce Cloud en parallèle pendant la migration ?

Oui, et nous le recommandons. Durant le sprint 3, les deux systèmes tournent simultanément. L’ancienne plateforme absorbe le trafic de production pendant que nous finalisons la recette utilisateur et les tests de performance sur Commerce Cloud. La fenêtre de bascule (changement de DNS) dure typiquement 4 à 8 heures, le temps d’exécuter la migration delta des données. En cas de problème, le rollback consiste à rétablir le DNS vers l’ancienne plateforme. Propre et sûr.