Comment Spadoom et Franke ont construit une plateforme de commerce électronique moderne en seulement 90 jours

La plupart des migrations SAP Commerce Cloud prennent 4 à 6 mois pour un seul marché. Franke Group, fabricant mondial de systèmes de cuisine, devait passer en production dans neuf pays européens. Le délai : 90 jours.

Ils l’ont fait. Zéro hotfix après le lancement. SAP Quality Award dans la catégorie « Time to Market ». Et non, l’équipe n’a pas simplement travaillé plus vite. Elle a fait des choix méthodologiques précis qui ont éliminé le gaspillage qui traîne la plupart des migrations jusqu’au sixième, septième, huitième mois.

TL;DR : Franke a migré de son système on-premise historique vers SAP Commerce Cloud dans 9 pays en 90 jours, remportant un SAP Quality Award. Le projet a généré une hausse de 20 % des conversions et un traitement des commandes 30 % plus rapide. Méthodologie clé : architecture « standard d’abord » (minimiser le code sur mesure), sprints agiles avec pilotage hebdomadaire et go-live par phases. 83 % des migrations dépassent leur budget (Bloor Group, 2023) : une gouvernance structurée et une discipline de périmètre sont ce qui distingue les 17 % qui réussissent.

Pourquoi la plupart des migrations commerce durent-elles si longtemps ?

83 % des projets de migration de données dépassent leur budget ou leur calendrier (Bloor Group, 2023). Les coupables habituels ne sont pas techniques. Ils sont organisationnels. Dérive du périmètre pendant la construction. Surprises d’intégration découvertes trop tard. Structures de gouvernance incapables de prendre une décision plus d’une fois par mois. J’ai assisté à ces revues mensuelles. C’est là que les projets vont mourir.

Les projets agiles réussissent dans 42 % des cas, contre 13 % pour le waterfall (Standish Group, 2020). Mais « faire de l’agile » ne suffit pas. Ce qui compte, c’est de savoir si vos sprints compressent réellement le cycle de décision ou s’ils ne font que renommer des phases waterfall avec des étiquettes plus tendance.

Franke a compressé les décisions grâce à trois choix précis : des comités de pilotage hebdomadaires dotés d’une vraie autorité, une architecture « standard d’abord » qui a tué la plupart des débats sur le développement sur mesure avant même qu’ils ne commencent, et un go-live par phases qui a ramené le risque de lancement près de zéro.

Qu’est-ce qui a rendu le délai de 90 jours possible ?

SAP est Leader du Magic Quadrant de Gartner pour le commerce numérique depuis 11 années consécutives (SAP News Center, 2025). La maturité de la plateforme était un prérequis. Mais la compression du calendrier est venue de quatre décisions méthodologiques.

Architecture « standard d’abord ». L’équipe s’est engagée tôt : utiliser les capacités prêtes à l’emploi de SAP Commerce Cloud et les composants du Composable Storefront partout où c’est possible. Le développement sur mesure était réservé aux vrais manques, pas aux préférences. Cette seule décision a probablement économisé 30 à 40 % de l’effort de développement par rapport à l’approche lourde en personnalisations que nous voyons sur la plupart des projets. Quand quelqu’un demandait « peut-on personnaliser ceci ? », la réponse par défaut était « pourquoi ? ».

Gouvernance structurée dès le premier jour. Réunions hebdomadaires du comité de pilotage avec la direction, les chefs de projet et les experts fonctionnels. Voies d’escalade claires. Chaque personne dans la salle connaissait son autorité décisionnelle. Dans un projet de 90 jours, vous ne pouvez tout simplement pas vous permettre des décisions qui attendent la prochaine revue mensuelle.

Sprints agiles avec progrès visibles. Cycles de sprint de deux semaines avec démos fonctionnelles après chacun. JIRA donnait à toutes les parties prenantes une visibilité en temps réel. Des victoires rapides après chaque sprint maintenaient l’élan : une fonctionnalité de conformité achevée, un module UI intégré, un jalon de test validé.

Composition intelligente de l’équipe. Les équipes internes de Franke apportaient une connaissance approfondie des processus et des clients. Nous apportions l’expertise SAP Commerce Cloud et l’expérience des déploiements multi-pays. Ce mélange signifiait que les décisions tombaient vite, parce que les deux côtés étaient toujours dans la salle : les personnes qui comprenaient le métier et les personnes qui comprenaient la plateforme.

Comment un déploiement dans 9 pays a-t-il tenu en 3 mois ?

90 % des entreprises ayant migré leur plateforme e-commerce ont constaté une amélioration de leur chiffre d’affaires (commercetools, 2024). Mais les déploiements multi-pays accumulent une complexité que les projets mono-marché ne touchent jamais : règles de TVA, codes fiscaux, exigences légales, variantes linguistiques, moyens de paiement locaux, prestataires logistiques régionaux. Neuf pays, cela signifie neuf variantes de tout cela.

Le déploiement de Franke couvrait la France, l’Allemagne, l’Autriche, le Luxembourg, l’Italie, les Pays-Bas, la Pologne, la Suisse et le Liechtenstein. Chaque marché avait des besoins de conformité uniques : configurations de champs TVA, numéros d’identification fiscale, mentions légales spécifiques au pays.

L’approche qui a fonctionné : traiter la configuration spécifique à chaque pays comme des données, pas comme du code. Règles de TVA, champs fiscaux et textes légaux sont allés dans des couches de configuration plutôt que dans des branches de développement sur mesure. Ajouter un nouveau pays est devenu un exercice de configuration, pas un sprint de développement. C’est le genre de décision d’architecture qui produit des intérêts composés.

Les intégrations paiement et logistique sont passées par le framework d’extension de SAP Commerce Cloud : passerelles de paiement, transporteurs et calculateurs de tarifs connectés via des API standardisées plutôt que du code d’intégration sur mesure.

Que s’est-il passé quand les choses ont mal tourné ?

Chaque migration rencontre des obstacles imprévus. Chacune, sans exception. La question est de savoir si votre structure de gouvernance peut les absorber sans faire dérailler le calendrier.

Trois problèmes ont émergé en cours de projet. L’intégration avec les fournisseurs externes de logistique et de paiement s’est avérée plus difficile que prévu. Des exigences de conformité dans certains marchés sont apparues tardivement : champs fiscaux supplémentaires et validations d’identification que personne n’avait cadrés. Et l’adoption utilisateur au sein des équipes internes de Franke a nécessité plus d’attention que planifié.

Voici comment nous avons géré chacun.

Complexité d’intégration : déploiement par phases. Chaque composant système a été intégré et testé isolément avant le déploiement complet. Cela a contenu le rayon d’impact quand quelque chose cassait.

Exigences de conformité tardives : nous avons intégré les consultations juridiques plus tôt dans le cycle de sprint. Examiner et ajuster les configurations avant le go-live, pas dans la précipitation de dernière minute.

Adoption utilisateur : ateliers de formation intensifs, démonstrations guidées et sessions de retour d’expérience intégrés directement dans la cadence des sprints. Les équipes internes ont appris les nouveaux workflows aux côtés de l’équipe de développement, pas après le lancement. Un point à temps en vaut cent.

Aucun de ces défis n’a repoussé le calendrier. La structure de gouvernance les a absorbés : pilotage hebdomadaire, escalade claire, décisions rapides.

Quels ont été les résultats métier ?

47 % des responsables IT citent la dette technique comme facteur majeur de surcoûts (IDC, 2024). La migration de Franke a éliminé la dette technique de son système on-premise historique tout en livrant des améliorations métier mesurables.

Hausse de 20 % des taux de conversion en ligne. Pages plus rapides, design responsive, checkout simplifié. Meilleure expérience d’achat, plus de gens achètent. C’est aussi simple que ça.

Réduction de 30 % du temps de traitement des commandes. Des workflows propres et l’automatisation backend ont remplacé les processus manuels incrustés dans le système historique.

Coût total de possession réduit. Passer d’une infrastructure on-premise à la plateforme gérée de SAP Commerce Cloud a réduit les charges opérationnelles. Plus de patching, d’hébergement ni de gestion d’infrastructure côté Franke.

Zéro hotfix après le lancement. Le go-live par phases a attrapé les problèmes en étapes contrôlées plutôt qu’en production. Le support hyper-care était en veille, mais à peine nécessaire.

SAP Quality Award en Time to Market. La reconnaissance de SAP lui-même pour la vitesse de livraison sans rogner sur la qualité. Celle-là a fait plaisir, je l’admets.

Que peuvent en apprendre les autres entreprises ?

Plus de 3’200 entreprises utilisent actuellement SAP Commerce Cloud (6sense, 2025). Toutes les migrations n’ont pas besoin de se faire en 90 jours. La plupart des projets de taille moyenne durent 4 à 6 mois. Mais les patterns méthodologiques de Franke s’appliquent quel que soit le calendrier.

Investissez dans la gouvernance dès le départ. Un projet de 90 jours ne peut pas se permettre de goulots d’étranglement décisionnels. Un projet de 6 mois non plus : les goulots semblent juste moins urgents jusqu’à ce qu’ils s’accumulent et écrasent votre date de go-live. Un pilotage hebdomadaire avec autorité de décision vaut le coup à n’importe quelle échelle.

Le standard par défaut, la personnalisation seulement si nécessaire. Chaque fonctionnalité sur mesure que vous construisez est une fonctionnalité que vous maintenez. SAP Commerce Cloud couvre plus de 80 % des besoins B2C et B2B typiques en standard. Utilisez ces capacités. Gardez votre budget sur mesure pour ce qui différencie vraiment votre entreprise.

Commencez l’intégration tôt. Franke a intégré les connexions paiement, logistique et ERP en parallèle du développement de la vitrine. Attendre que la plateforme soit « prête » avant de commencer les travaux d’intégration, c’est comme ça que des projets de 4 mois deviennent des projets de 8 mois. Nous l’avons vu arriver trop souvent.

Planifiez l’adoption utilisateur dès le sprint 1. Les équipes internes qui apprennent le système pendant le développement sont productives dès le premier jour. Les équipes formées après le lancement passent des semaines à rattraper. Ce sont des semaines de chiffre d’affaires perdu.

Pour un aperçu de ce que nous livrons avec SAP Commerce Cloud (tarification, architecture Composable Storefront et cas d’usage B2B), consultez notre page solution SAP Commerce Cloud.

Vous planifiez une migration SAP Commerce Cloud ? Nous commençons par un atelier de découverte qui définit votre architecture, cartographie vos intégrations et produit un calendrier réaliste. Que ce soit 90 jours ou 6 mois. Parlons-en.

Questions fréquentes

Toute migration SAP Commerce Cloud peut-elle se faire en 90 jours ?

Pas toutes, mais plus qu’on ne le pense. Le délai de 90 jours a fonctionné pour Franke parce que l’équipe s’était engagée sur une architecture « standard d’abord », disposait d’une gouvernance solide et avait accepté que le développement sur mesure serait minimal. Si votre projet nécessite une logique métier sur mesure étendue, des workflows B2B complexes ou une transformation complète des données, prévoyez 4 à 6 mois. Les principes méthodologiques compressent de toute façon le calendrier sur lequel vous travaillez.

Qu’est-ce qui distinguait le projet Franke d’une migration classique ?

La vitesse de décision, la discipline de périmètre et la philosophie d’architecture. La plupart des migrations ralentissent parce que les décisions attendent des revues mensuelles, que le périmètre s’étend en cours de construction (« tant qu’on y est… ») et que les équipes préfèrent le développement sur mesure aux capacités de la plateforme. Le comité de pilotage hebdomadaire de Franke, un périmètre MVP strict et l’approche « standard d’abord » ont éliminé ces gouffres à temps.

Combien coûte une migration SAP Commerce Cloud en 90 jours ?

Une migration de cette envergure (9 pays, Composable Storefront, intégration multi-systèmes) coûte généralement entre CHF 300’000 et 500’000 avec une approche « standard d’abord ». Des implémentations lourdes en personnalisations d’envergure comparable peuvent coûter CHF 600’000 à 1 million et plus, et durer 6 à 9 mois. Le « standard d’abord » économise à la fois du temps et du budget en réduisant le développement sur mesure et la charge de maintenance future.

Qu’est-ce qu’une architecture « standard d’abord » ?

Cela signifie utiliser les capacités intégrées de SAP Commerce Cloud et les composants du Composable Storefront par défaut, et n’écrire du code sur mesure que lorsque la plateforme ne peut réellement pas couvrir un besoin. En pratique, cela couvre plus de 80 % des fonctionnalités e-commerce typiques. Le développement sur mesure est réservé à la logique métier unique : règles de tarification propriétaires, fonctionnalités de conformité sectorielles, tout ce qu’aucune plateforme ne gère en standard.

Pourquoi ce projet a-t-il remporté un SAP Quality Award ?

Les SAP Quality Awards récompensent les projets qui démontrent l’excellence en méthodologie, résultats et innovation. Le projet Franke a gagné en « Time to Market » pour avoir livré un déploiement dans 9 pays en 90 jours avec zéro hotfix après le lancement, des améliorations métier mesurables (hausse de 20 % des conversions, traitement des commandes 30 % plus rapide) et un modèle de gouvernance que d’autres entreprises peuvent répliquer.