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

Quatre-vingt-dix jours entre le lancement et la mise en production, c’est rapide pour un projet SAP Commerce. La plupart des entreprises prévoient huit à douze mois pour passer de SAP Hybris à SAP Commerce Cloud, et pour les plateformes volumineuses et très personnalisées, c’est le bon plan. Pour une plateforme de taille moyenne, avec une équipe préparée et un périmètre figé, 90 jours sont atteignables. Cet article décrit la méthode que nous utilisons : ce qui se passe avant le début du compte à rebours, ce que livre chaque sprint et ce que nous laissons délibérément de côté.

Ce rythme, nous le connaissons par notre propre travail. Chez Franke, nous avons mis en production la plateforme SAP Commerce Cloud en 90 jours ; ce chiffre se rapporte au lancement commerce, dans le cadre d’un partenariat plus long au cours duquel nous avons remplacé une ancienne plateforme par une architecture headless. Le projet a reçu le SAP Quality Award pour « Rapid Time to Value » (témoignage Franke).

En bref : une plateforme SAP Hybris de taille moyenne peut arriver sur SAP Commerce Cloud en 90 jours si 30 jours de préparation la précèdent : audit de la plateforme, profilage des données, environnements, alignement de l’équipe. Viennent ensuite trois sprints : plateforme de base et premier chargement de données (jours 1 à 21), intégrations et frontend (jours 22 à 50), performance, recette, répétition générale et mise en production (jours 51 à 90). Ce qui fait tenir l’ensemble : la discipline sur le périmètre, des chantiers parallèles et des démonstrations hebdomadaires. Depuis la fin de la maintenance principale de l’on-premise, le 31 juillet 2026, ce même plan est la sortie la plus rapide.

Vous préférez un partenaire à un guide à faire soi-même ? Spadoom est SAP Gold Partner pour le Cloud ERP et l’expérience client et réalise des projets SAP Commerce Cloud en Suisse, en Allemagne, en Autriche et en Italie, avec la Cloud Edition comme avec l’ERP Edition pour S/4HANA Public Cloud. Demandez un entretien de cadrage.

Pourquoi 90 jours sont-ils atteignables ?

D’après notre expérience, les longs calendriers de migration sont gonflés davantage par le gaspillage que par la complexité. Une migration en 90 jours ne bâcle rien ; elle supprime trois choses qui consomment du temps sans créer de valeur.

La paralysie de l’analyse. Les équipes passent des mois à documenter des exigences qui existent déjà dans le système en service. La plateforme actuelle est la meilleure spécification dont vous disposez : lisez-la au lieu de la réécrire.

La reproduction à l’identique de personnalisations dont personne n’a besoin. Un contournement de 2017 n’a pas sa place sur la nouvelle plateforme simplement parce qu’il existe sur l’ancienne.

Des phases successives avec des délais de passation. Chaque validation, passation et changement de contexte entre équipes coûte des jours, souvent une semaine.

Sans ces trois freins, le vrai travail (migration des données, configuration de la plateforme, reconnexion des intégrations, tests) tient en 90 jours pour une plateforme commerce de taille moyenne. Pour les plus grandes, la même méthode raccourcit aussi le projet, mais pas à 90 jours ; notre checklist de migration indique les fourchettes typiques par scénario.

Que se passe-t-il avant le début du compte à rebours ? (semaines -4 à 0)

Le compte à rebours des 90 jours démarre au lancement. Les 30 jours qui précèdent décident si le projet sera un sprint maîtrisé ou une course désordonnée.

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

Nous cartographions tout ce que contient l’instance SAP Hybris actuelle :

• Extensions maison : les compter, les classer (toujours nécessaires, remplaçables, obsolètes) et estimer l’effort pour chacune.
• Modèles de données : types, relations et attributs personnalisés, et lesquels correspondent directement à Commerce Cloud.
• Intégrations : chaque connexion entrante et sortante (ERP, PIM, CRM, paiement, expédition, fiscalité) avec protocole, format et fréquence.
• Points chauds de personnalisation : la petite partie du code maison qui porte l’essentiel de la logique métier.

L’audit montre régulièrement qu’une partie des extensions étaient des contournements de limites de l’on-premise que Commerce Cloud couvre en standard. Elles sortent immédiatement du périmètre, et chacune est du code que vous n’avez ni à migrer, ni à tester, ni à maintenir. Les cinq erreurs de migration les plus courantes commencent précisément là où cet audit est sauté.

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

Avant de toucher aux outils de migration, il faut comprendre les données. Profilez chaque entité en termes d’exhaustivité, de cohérence et de qualité. Repérez les doublons, les enregistrements orphelins et les données que personne n’a touchées depuis des années. Construisez et testez le pipeline d’extraction et de chargement sur un petit échantillon. Les problèmes trouvés ici coûtent des heures ; trouvés au Sprint 3, ils coûtent des semaines.

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

Provisionnez les environnements SAP Commerce Cloud (développement, préproduction, production), configurez les pipelines de build et de déploiement dans le Cloud Portal, mettez en place la supervision et les alertes, et donnez les accès à chacun. Un travail peu spectaculaire, et entièrement nécessaire. La documentation SAP Commerce Cloud décrit en détail le modèle d’environnements et de déploiement.

Alignement de l’équipe (semaine -1)

Finaliser le backlog. Confier chaque chantier (plateforme, données, intégrations, frontend, tests) à un responsable clairement désigné. Convenir de la Definition of Done de chaque incrément, mettre en place des points quotidiens et des démonstrations hebdomadaires pour les parties prenantes, afin que chacun sache dès le premier jour sur quoi il travaille.

Que réalise-t-on au Sprint 1 ? (jours 1 à 21)

Les trois premières semaines installent la plateforme de base sur Commerce Cloud avec vos modèles de données et la configuration de base.

• Migration du modèle de données : types, énumérations et relations personnalisés, validés par rapport à l’audit.
• Logique métier essentielle : les personnalisations critiques identifiées lors de l’audit, comme le calcul du panier, les règles de prix, les promotions et le calcul des taxes.
• Vitrine de base : SAP Composable Storefront avec votre catalogue de produits. Pas encore de mise en forme spécifique ; l’exactitude fonctionnelle passe d’abord.
• Premier chargement de données : une migration complète vers la préproduction, avec nombre d’enregistrements, intégrité des données et principaux flux métier validés.

Ce qui ne se fait pas au Sprint 1 : les finitions visuelles, les intégrations non critiques (analytique, avis, fidélisation), l’optimisation des performances et la logique des cas particuliers. C’est ce refus qui maintient le sprint dans les temps.

Jalon au jour 21 : une vitrine fonctionnelle sur la préproduction Commerce Cloud avec des données réelles, la logique métier essentielle et un checkout de base. Les parties prenantes peuvent parcourir les produits, les ajouter au panier et passer commande. L’aspect n’est pas encore définitif, mais cela fonctionne.

Comment les intégrations se mettent-elles en place au Sprint 2 ? (jours 22 à 50)

Une fois la plateforme de base éprouvée, le Sprint 2 reconnecte l’écosystème, par ordre d’importance pour l’activité :

1. ERP et gestion des commandes : export des commandes, synchronisation des stocks, mises à jour des prix
2. Prestataire de paiement : reconnexion de la passerelle via l’intégration de paiement de Commerce Cloud
3. Expédition et logistique : calcul des frais, étiquettes, suivi
4. PIM et contenus : flux de données produits, synchronisation des médias
5. CRM et CDP : synchronisation des données clients

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

En parallèle, l’équipe frontend applique l’identité visuelle, construit les composants d’interface spécifiques, optimise pour le mobile et s’occupe du SEO : métadonnées, données structurées et redirections depuis les anciennes URL.

Jalon au jour 50 : un déploiement Commerce Cloud entièrement intégré, avec toutes les intégrations critiques actives, un frontend conforme à la marque et un flux de commande complet, de la navigation à la livraison.

Qu’est-ce qui rend le Sprint 3 différent ? (jours 51 à 90)

La dernière phase est une affaire de confiance. Le système fonctionne ; il s’agit maintenant de 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 et simulation du jour de pointe. Repérer et éliminer les goulots d’étranglement, valider le dimensionnement automatique, comparer les temps de chargement aux objectifs.

Recette (jours 55 à 70). Les utilisateurs métier testent chaque flux critique avec de vrais comptes clients et de vraies données produits, ainsi que toutes les intégrations en conditions réalistes. Tous les problèmes P1 et P2 sont résolus.

Répétition générale de la migration des données (jours 65 à 75). Exécuter l’ensemble du pipeline de bout en bout et mesurer sa durée, qui détermine votre fenêtre de bascule. Valider la migration delta pour les données créées entre la répétition et la mise en production, et tester la procédure de retour arrière. Cette étape n’est pas facultative.

Mise en production et stabilisation (jours 85 à 90). Exécuter le runbook : migration delta, bascule DNS, puis 48 heures de surveillance avec toute l’équipe mobilisée.

Qu’est-ce qui fait tenir un calendrier de 90 jours ?

Avec le recul sur nos lancements commerce les plus rapides, Franke compris, cinq facteurs ont fait la différence.

La discipline sur le périmètre. Nous migrons ce dont l’activité a besoin, pas tout ce qui existe. Les personnalisations obsolètes restent derrière, sans nostalgie.

Des chantiers parallèles. Plateforme, données, intégrations et frontend avancent en parallèle avec des points de synchronisation quotidiens. Quand une équipe est bloquée, les autres continuent.

Un investissement précoce dans les données. Le profilage commence avant le lancement, de sorte que dès le premier jour chacun sait ce qui est migré et ce qui reste.

Des livraisons itératives avec démonstrations hebdomadaires. Les parties prenantes voient des progrès chaque semaine, les problèmes apparaissent tôt et les corrections de cap prennent des jours, pas des mois.

Une équipe expérimentée. Ceux qui l’ont déjà fait reconnaissent tôt les schémas et les pièges. Cette expérience fait gagner plus de temps que n’importe quel outil.

Vitesse et qualité ne s’opposent pas. Chez Franke, le SAP Quality Award a été décerné pour « Rapid Time to Value », et c’est exactement ce qu’il dit.

L’échéance EoMM est déjà passée ?

La maintenance principale de SAP Commerce on-premise a pris fin le 31 juillet 2026 (SAP Help Portal). Si vous êtes encore on-premise, vous êtes désormais en maintenance spécifique au client : pas de correctifs de sécurité réguliers, pas de mises à jour réglementaires, un support tarifé individuellement. Ce que cela implique en détail, et quelles mesures transitoires ont du sens, est expliqué dans Le support on-premise de SAP Commerce est terminé : et maintenant ?.

Le calcul du playbook ne change pas : 30 jours de préparation plus 90 jours de migration font environ 120 jours. Ce qui a changé, c’est que chacun de ces jours se passe désormais hors de la maintenance principale. C’est une raison de commencer la préparation maintenant plutôt que d’attendre le moment idéal, et de garder le périmètre aussi serré que le playbook l’exige. Si votre plateforme est trop grande pour 90 jours, découpez-la en vagues pour que les premiers marchés quittent tôt le système on-premise.

Pour une vue plus large de ce qu’apporte SAP Commerce Cloud aujourd’hui, consultez notre page SAP Commerce Cloud. Si vous choisissez encore un partenaire d’implémentation, notre panorama des meilleurs partenaires SAP Commerce Cloud en Suisse énumère les critères qui comptent.

---

Nous analysons votre instance SAP Hybris, cartographions vos personnalisations, profilons vos données et établissons un plan de migration réaliste, en 90 jours là où le périmètre le permet. Contactez-nous.

Questions fréquentes

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

Non. Quatre-vingt-dix jours conviennent aux plateformes commerce de taille moyenne avec une préparation propre et un périmètre figé. Les projets avec plusieurs vitrines, beaucoup d’intégrations ou de gros volumes de données demandent généralement quatre à six mois, voire davantage. La variable décisive est la quantité de personnalisations inutiles et de dette technique que traîne la plateforme.

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

La migration des données. C’est pourquoi le profilage des données commence dans la phase de préparation, avant que le compte à rebours des 90 jours ne démarre. Le premier jour du Sprint 1, vous connaissez les volumes, les problèmes de qualité et les règles de transformation, et la répétition générale du Sprint 3 valide l’ensemble du pipeline avant la mise en production.

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

Une équipe resserrée est la norme : quelques consultants Spadoom pour SAP Commerce, le frontend et l’intégration, plus un product owner, un business analyst et un référent informatique côté client. Des chantiers parallèles aux responsabilités claires comptent plus que l’effectif ; une équipe plus grande avec des passations successives est généralement plus lente.

Qu’advient-il du SEO lors d’une migration de Hybris vers Commerce Cloud ?

Les changements d’URL exigent un plan de redirection complet : associer toutes les anciennes URL, mettre en place des redirections 301, reprendre les métadonnées et les données structurées et soumettre le nouveau sitemap. Lorsque les redirections sont complètes, le trafic organique se rétablit généralement en quelques semaines. Surveillez la Search Console chaque jour pendant le premier mois et corrigez les erreurs 404 le jour même.

L’ancienne plateforme Hybris et Commerce Cloud peuvent-elles fonctionner en parallèle ?

Oui, et nous le recommandons. L’ancienne plateforme continue de servir le trafic de production pendant que la recette et les tests de performance tournent sur Commerce Cloud. La fenêtre de bascule pour la migration delta et le changement de DNS dure généralement quelques heures. Revenir au DNS précédent n’est un retour arrière propre que si les commandes passées sur la nouvelle plateforme après la bascule sont rejouées dans l’ancien système : prévoyez cette étape dans le runbook.