Mise en œuvre de SAP Commerce Cloud : ce qui se passe vraiment dans un projet

La plupart des contenus consacrés aux mises en œuvre de SAP Commerce Cloud ressemblent à des brochures. Cet article décrit ce qui se passe réellement dans un projet : les décisions qui comptent, les phases qui durent plus longtemps que prévu et les habitudes qui distinguent une mise en ligne sereine d’une mise en ligne douloureuse.

SAP Commerce Cloud est une plateforme mature, mais une plateforme mature ne rend pas une mise en œuvre facile. Budgets et plannings dérapent rarement à cause du logiciel ; ils dérapent à cause de décisions prises trop tard, de données que personne n’a examinées et d’intégrations que personne n’a cadrées.

En bref : les mises en œuvre de SAP Commerce Cloud durent généralement de trois à neuf mois selon le périmètre. Quatre phases déterminent le résultat : la découverte (décisions d’architecture et audit des adaptations), la construction (livraisons itératives par sprints de deux à quatre semaines), l’intégration (ERP, PIM, paiement, livraison) et la mise en ligne (migration des données, tests de performance, bascule). L’atelier de découverte et l’audit des adaptations se rentabilisent plusieurs fois pendant la construction.

Vous cherchez un partenaire plutôt qu’un guide à suivre seul ? Spadoom est SAP Gold Partner et met en œuvre SAP Commerce Cloud en Suisse, en Allemagne, en Autriche et en Italie, aussi bien la Cloud Edition que la nouvelle ERP Edition, avec le cœur ERP. Demandez un entretien de cadrage ou lisez le cas client Franke.

Phase	Durée type	Contenu
Découverte	Deux à quatre semaines	Architecture, exigences, audit des adaptations
Construction	Six à seize semaines	Modèle de données, vitrine, sprints itératifs
Intégration	Quatre à huit semaines, en parallèle de la construction	ERP, PIM, paiement, livraison
Mise en ligne	Trois à quatre semaines	Tests de recette, tests de performance, migration des données, bascule

Que se passe-t-il pendant la phase de découverte ?

C’est en phase de découverte que les projets se gagnent ou se perdent. C’est là que vous trouvez la dette technique de l’ancienne plateforme, avant qu’elle ne fasse dérailler la construction.

Une phase de découverte solide (deux à quatre semaines) couvre :

Les décisions d’architecture. SAP Composable Storefront ou frontend sur mesure ? Combien d’environnements ? Quelle chaîne CI/CD ? Ces choix sont difficiles à revenir en arrière.

L’audit des adaptations. Si vous migrez depuis l’on-premise, classez chaque adaptation : toujours nécessaire, remplaçable par une fonction standard ou obsolète. Une part importante s’avère en général superflue, et chaque adaptation abandonnée est du code que vous n’aurez ni à migrer ni à maintenir.

L’analyse des données. Examinez le catalogue produits, les données clients, l’historique des commandes et les contenus, et repérez les problèmes de qualité avant qu’ils ne bloquent la migration. Des projets perdent des semaines parce que personne n’a regardé les données produits avant le quatrième sprint.

La cartographie des intégrations. Documentez chaque flux entrant et sortant : ERP, PIM, CRM, paiement, livraison, fiscalité, analytique. Pour chacun : protocole, format de données, fréquence et gestion des erreurs.

L’organisation de l’équipe et la gouvernance. Qui est responsable de quoi, comment les décisions sont prises, démonstrations hebdomadaires ou revues mensuelles. Les projets à la gouvernance floue s’enlisent.

Comment la phase de construction doit-elle se dérouler ?

Les mises en œuvre de Commerce Cloud fonctionnent le mieux en mode itératif : des sprints de deux à quatre semaines, chacun produisant un incrément utilisable.

Sprint 1 : modèle de données et configuration de base. Types spécifiques, structure du catalogue, règles de prix, moteur de promotions. L’objectif est un catalogue fonctionnel en préproduction dès les premières semaines.

Sprints 2 et 3 : vitrine et tunnel de commande. Déployez la vitrine avec vos données produits et construisez le tunnel de commande, la logique du panier et la gestion du compte. Chaque sprint livre quelque chose que les parties prenantes peuvent utiliser et commenter.

À partir du sprint 4 : logique métier et cas particuliers. Prix propres au client et dégressifs, stocks multi-entrepôts, fonctions B2B comme les circuits d’approbation, les plafonds d’achat et les hiérarchies d’acheteurs.

La discipline qui compte : chaque sprint se termine par un système fonctionnel que les parties prenantes peuvent tester. « Nous vous montrerons quelque chose au quatrième mois », c’est trop tard pour corriger le cap.

Pourquoi l’intégration est-elle la partie la plus difficile ?

L’intégration est souvent le plus gros bloc de travail. Voici les connexions qui comptent le plus.

ERP (SAP S/4HANA, ECC). Export des commandes, synchronisation des stocks, prix, données de base clients. C’est en général l’intégration la plus complexe, et celle qui doit fonctionner : si les commandes n’arrivent pas dans l’ERP, le reste ne compte plus. Le module d’intégration de SAP pour la gestion des commandes avec S/4HANA couvre les prix et stocks en temps réel, les contrôles de crédit et la création synchrone des commandes pour le B2B sur le Composable Storefront, mais le mapping vers la configuration de votre ERP reste un travail de projet. Nous livrons les côtés commerce et ERP avec une seule équipe ; notre article sur la pile intégrée S/4HANA Public Cloud et Sales Cloud V2 explique pourquoi c’est important. Si l’ERP derrière est encore SAP ECC, planifiez l’intégration commerce sur le système cible : notre page sur la fin de maintenance de SAP ECC en 2027 présente les échéances et les voies de migration.

PIM. Flux de données produits, médias, hiérarchies de classification. Si le PIM est le système de référence pour les données produits, il faut une intégration en temps réel ou quasi réel.

Paiement. Connexion au prestataire, tokenisation, 3-D Secure, remboursements. Commerce Cloud prend en charge plusieurs extensions de paiement, et bien choisir et configurer la bonne compte plus qu’on ne le pense.

Livraison et logistique. Calcul des frais, édition des étiquettes, suivi des envois. Souvent avec plusieurs transporteurs aux API différentes.

L’approche qui fonctionne : lancer le développement des intégrations en parallèle des derniers sprints de construction, sans attendre que la plateforme soit « terminée ». Sinon, une longue phase d’intégration vient s’ajouter à une construction déjà longue.

Que comprend réellement la mise en ligne ?

Tests de recette (deux à trois semaines). Les utilisateurs métier, et non les développeurs, testent chaque parcours critique avec des données réelles. Ils trouvent ce que les développeurs ne trouveraient jamais.

Tests de performance. Tests de charge avec un trafic réaliste, y compris la simulation d’un jour de pointe, validation de l’autoscaling et temps de chargement comparés aux objectifs. Commerce Cloud gère la montée en charge de l’infrastructure, mais votre code et vos requêtes doivent rester performants.

Répétition générale de la migration des données. Exécutez la migration complète de bout en bout et mesurez sa durée : elle détermine votre fenêtre de bascule. Testez la migration différentielle pour les données créées pendant la transition.

Bascule. Déroulez le plan de mise en ligne : gel de l’ancien système, migration différentielle, bascule du DNS, validation des parcours clés et surveillance pendant 48 heures avec toute l’équipe mobilisée. Ensuite, place à la mesure : quels KPI suivre et quels outils connecter, notre article sur l’analytique et la performance d’une boutique Commerce Cloud l’explique.

Si vous migrez depuis SAP Commerce on-premise, gardez à l’esprit que la maintenance standard de la version on-premise a pris fin le 31 juillet 2026 ; notre article sur ce qu’il faut faire maintenant que le support on-premise a pris fin présente les options.

Qu’est-ce qui distingue les bonnes mises en œuvre des mauvaises ?

Investir dans la découverte. Les projets qui consacrent deux à quatre semaines à une vraie phase de découverte en économisent plusieurs fois l’équivalent pendant la construction. Ceux qui la sautent passent la construction à découvrir ce qu’ils auraient dû planifier.

La discipline sur le périmètre. Le plus grand risque n’est pas technique, c’est l’élargissement du périmètre. « Tant qu’on y est, ajoutons aussi… » transforme un projet de quatre mois en projet de neuf mois. Définissez la première version, livrez-la, puis itérez. Vous ne dites pas non pour toujours, vous dites : pas encore.

L’intégration d’abord. Lancez l’architecture d’intégration dès la découverte et le développement des intégrations au sprint 2 ou 3. La plateforme n’est utile qu’une fois reliée à votre ERP.

Pour la plateforme elle-même, consultez notre présentation de SAP Commerce Cloud et la configuration étape par étape plus bas. Pour le budget, notre guide des prix et du TCO détaille les coûts de licence, de mise en œuvre et d’exploitation. Et si vous comparez des partenaires, notre panorama des meilleurs partenaires SAP Commerce Cloud en Suisse expose les critères.

Comment configurer SAP Commerce Cloud étape par étape ?

Sur le plan technique, la configuration de Commerce Cloud passe par dix étapes. La modélisation des données et l’intégration ERP déterminent le chemin critique ; la plupart des retards viennent de la sous-estimation de l’une des deux.

1. Provisionnement des environnements : SAP fournit le Cloud Portal et trois environnements (développement, préproduction, production), chacun avec sa base de données, son index de recherche et sa configuration.
2. Structure du projet : choisir une recette (B2C, B2B ou sur mesure), activer les extensions nécessaires et décider du frontend ; la configuration du build se trouve dans manifest.json.
3. Modélisation des données : étendre le modèle produits, clients et catalogues via le système de types et y mapper vos données produit existantes.
4. Configuration de la vitrine : thème, navigation, modèles CMS et emplacements de contenu, mises en page responsives et paramètres SEO.
5. Intégration ERP : prix et disponibilités en temps réel, données de base clients, réplication des commandes et contrôles de crédit, en général via SAP Integration Suite.
6. Paiement et livraison : prestataire de paiement, modes de livraison par pays et moteur fiscal pour la vente transfrontalière.
7. Création des contenus : textes produits, images et pages d’atterrissage dans SmartEdit ; les gros volumes via ImpEx ou Hot Folders.
8. Tests : fonctionnels, d’intégration, de performance, de sécurité, navigateurs et appareils.
9. Optimisation des performances : mise en cache, index de recherche, diffusion par CDN, requêtes en base et autoscaling pour les pics.
10. Mise en ligne et stabilisation : déployer, basculer le DNS et prévoir deux à quatre semaines de surveillance étroite.

Envie de concrétiser tout cela ?

Spadoom met en œuvre SAP Commerce Cloud de bout en bout : la Cloud Edition pour le B2B et le B2C des grandes entreprises, l’ERP Edition pour les entreprises de taille moyenne sur S/4HANA Public Cloud, et les migrations depuis Hybris on-premise. Chez Franke, nous avons repris une plateforme à l’arrêt, mis en ligne le lancement commerce en 90 jours et réduit les commandes manuelles de 75 % ; le projet a reçu le SAP Quality Award « Rapid Time to Value ». Chaque projet commence chez nous par un atelier de découverte qui définit l’architecture, recense les intégrations et établit un planning réaliste. Parlons-en.

Questions fréquentes

Combien de temps dure une mise en œuvre type de SAP Commerce Cloud ?

Cela dépend du périmètre. La plupart des projets durent de trois à neuf mois : une migration depuis l’on-premise avec un volume d’adaptations modéré prend souvent trois à six mois, une nouvelle mise en œuvre B2B avec plusieurs vitrines, de nombreuses intégrations et une logique métier spécifique six à neuf mois. Chez Franke, le lancement commerce a été mis en ligne en 90 jours. La principale variable est la complexité des intégrations, pas la configuration de la plateforme.

Combien coûte une mise en œuvre de SAP Commerce Cloud ?

Pour les entreprises de taille moyenne, les coûts de mise en œuvre se situent généralement dans les centaines de milliers de francs ; les programmes complexes de grandes entreprises peuvent dépasser le million. Les principaux facteurs de coût sont le nombre d’intégrations, la complexité des adaptations, le volume de données, le nombre de vitrines et de marchés, et le fait de migrer depuis un système SAP existant ou de partir de zéro.

De quelle équipe avons-nous besoin pour un projet SAP Commerce Cloud ?

Un projet type de taille moyenne réunit trois à cinq consultants de mise en œuvre (SAP Commerce, frontend, intégration) et deux à trois personnes côté client (product owner, analyste métier, interlocuteur informatique). Le rôle le plus important est celui du product owner côté client, car il arbitre le périmètre et apporte le contexte métier. Les projets sans product owner dédié durent systématiquement plus longtemps.

Faut-il utiliser le Composable Storefront ou un frontend sur mesure ?

Pour la plupart des projets, commencez par le SAP Composable Storefront : il est intégré à la plateforme, activement développé et couvre les scénarios B2B et B2C standard. Un frontend sur mesure en React ou Next.js se justifie si vous avez besoin d’une expérience utilisateur fondamentalement différente ou exploitez plusieurs vitrines très différentes ; il allonge la construction de plusieurs semaines et exige des développeurs frontend dédiés pour la maintenance. Notre comparaison entre le Composable Storefront et React/Next.js entre dans le détail.

Quelle est la cause la plus fréquente des dépassements de budget sur Commerce Cloud ?

Une complexité d’intégration mal évaluée pendant la phase de découverte, suivie de l’élargissement du périmètre pendant la construction. Les deux se préviennent par une phase de découverte rigoureuse qui recense chaque intégration et classe chaque adaptation, et par une première version clairement définie.

Comment fonctionne le déploiement ?

La configuration du projet se trouve dans un fichier manifest.json de votre dépôt de code. Dans le Cloud Portal, vous créez un build à partir d’une branche et le déployez dans l’environnement de développement, de préproduction ou de production. Les déploiements progressifs (rolling) permettent de mettre à jour la production sans interruption de service.