Le big bang est un pari que vous allez perdre
Combien de fois ai-je entendu ce scénario : “On arrête tout, on repart de zéro, et dans 18 mois on lance la nouvelle plateforme.” Spoiler : dans 18 mois, le projet est en retard de 6 mois, le budget a doublé, et le business a perdu des fonctionnalités critiques qu’on avait oubliées dans le cahier des charges.
Les refontes big bang échouent plus souvent qu’elles ne réussissent. Et quand elles échouent, les conséquences sont sévères : perte de chiffre d’affaires, désorganisation des équipes, perte de confiance des parties prenantes.
Pourquoi s’obstiner alors qu’il existe une alternative prouvée ?
Pourquoi le big bang est si risqué
La complexité invisible
Un site e-commerce en production depuis 5 ans accumule des centaines de règles métier implicites. Des promotions complexes, des logiques de calcul de frais de port qui dépendent de 15 paramètres, des intégrations avec des systèmes tiers qui ont évolué indépendamment.
Personne ne connaît l’intégralité de ces règles. Elles ne sont pas documentées. Elles sont dans le code, dans la configuration, dans la tête de personnes qui ont parfois quitté l’entreprise.
Le tunnel sans visibilité
Pendant 12 à 18 mois de développement big bang, le business ne voit rien. Pas de livraison intermédiaire. Pas de valeur incrémentale. Juste des reportings de projet et une promesse que “ça avance”.
Le jour du lancement, tout doit fonctionner du premier coup. La moindre régression est visible immédiatement par tous les clients. La pression est maximale, la marge de manoeuvre est nulle.
L’effet ciseaux des coûts
Pendant la refonte, il faut maintenir l’ancienne plateforme ET développer la nouvelle. Double équipe, double infrastructure, double maintenance. Et si la refonte prend du retard (ce qui arrive presque toujours), cette période de double coût s’allonge.
La méthode progressive : le Strangler Fig Pattern
Le principe est emprunté à la nature. Le figuier étrangleur pousse autour d’un arbre existant, le remplaçant progressivement sans jamais tuer l’hôte d’un coup.
Appliqué au e-commerce, le concept est simple : remplacer la plateforme morceau par morceau, en gardant l’ancien système fonctionnel jusqu’à ce que chaque composant soit migré.
Étape 1 : Cartographier et découper
Identifiez les domaines fonctionnels de votre plateforme :
- Catalogue produit et PIM
- Moteur de recherche et navigation
- Panier et tunnel d’achat
- Gestion des commandes (OMS)
- CMS et contenu éditorial
- Gestion des comptes clients
- Promotions et pricing
- Paiement
- Logistique et livraison
Chaque domaine est un candidat à une migration indépendante.
Étape 2 : Prioriser par la valeur et le risque
Tous les domaines ne se valent pas. Priorisez selon deux axes :
- Valeur business : quel impact sur le CA, la conversion, l’expérience client ?
- Risque technique : quelle complexité d’intégration, quelles dépendances ?
Commencez par les domaines à forte valeur et risque maîtrisé. Le moteur de recherche est souvent un excellent premier candidat : impact direct sur la conversion, intégration relativement isolée, résultat visible rapidement.
Étape 3 : Façade et routage
Mettez en place une couche de façade (API Gateway ou reverse proxy) qui route les requêtes vers l’ancien ou le nouveau système selon le domaine fonctionnel.
Le client ne voit pas la transition. Pour lui, c’est un seul site, une seule expérience. En coulisses, certaines requêtes sont traitées par l’ancien système, d’autres par le nouveau.
Étape 4 : Migrer, mesurer, itérer
Pour chaque domaine migré :
- Développer le nouveau composant en parallèle de l’existant
- Tester avec un pourcentage réduit du trafic (canary deployment)
- Mesurer les performances : temps de réponse, taux d’erreur, impact sur la conversion
- Basculer progressivement le trafic (10%, 25%, 50%, 100%)
- Décommissionner l’ancien composant une fois la migration validée
Étape 5 : Répéter jusqu’à l’extinction de l’ancien système
Chaque migration renforce la confiance et améliore le processus. L’équipe apprend, les patterns d’intégration se stabilisent, la vélocité augmente.
Les bénéfices concrets
Livraison de valeur dès le premier mois
Pas besoin d’attendre 18 mois pour voir un résultat. Le premier domaine migré apporte de la valeur en 2-3 mois. Le business voit des améliorations concrètes, régulières, mesurables.
Risque maîtrisé à chaque étape
Si la migration d’un domaine pose problème, on revient en arrière. Le rollback est simple car l’ancien système est toujours là. Le risque est local, jamais global.
Budget prévisible
Chaque incrément a un coût identifié et un ROI mesurable. Plus de tunnel budgétaire de 18 mois — des investissements séquencés dont on peut mesurer le retour à chaque étape.
Adaptation continue
Les besoins métier évoluent pendant une refonte de 18 mois. Avec une approche progressive, chaque incrément intègre les dernières évolutions du marché et du business. Le décalage entre le besoin et le livrable est minimal.
Les pièges à éviter
Ne pas investir dans la façade
La couche de routage entre l’ancien et le nouveau système est critique. Si elle est mal conçue, elle devient un goulot d’étranglement qui dégrade l’expérience utilisateur. Investissez dans cette couche dès le départ.
Négliger la cohérence de l’expérience
Le client ne doit pas percevoir qu’il passe d’un système à l’autre. L’identité visuelle, les performances perçues, le comportement des fonctionnalités transverses (panier, compte client) doivent être cohérents. C’est un effort de design et d’intégration permanent.
Garder l’ancien système trop longtemps
La migration progressive n’est pas une excuse pour ne jamais finir. Fixez un horizon clair (12-24 mois selon la taille) et tenez-le. Plus l’ancien système reste en place, plus le coût de double maintenance pèse.
Sous-estimer la migration de données
Les données sont le sujet le plus complexe de toute migration. Schémas différents, historiques à préserver, références croisées entre domaines. Prévoyez un chantier dédié avec des spécialistes de la donnée.
Un cas typique : refonte d’un e-commerce mode
Un retailer mode avec un monolithe Magento 1, 50 000 SKU, 8 marchés, 15 millions de CA en ligne. Le big bang vers Shopify avait été estimé à 18 mois et 1,2M d’euros.
Approche progressive retenue :
- Mois 1-3 : Migration du moteur de recherche vers Algolia. Résultat : taux de conversion +12%
- Mois 3-6 : Migration du CMS vers un headless CMS. Résultat : time-to-market des contenus divisé par 4
- Mois 6-9 : Refonte du tunnel d’achat sur Shopify. Résultat : abandon de panier -18%
- Mois 9-14 : Migration du catalogue et de l’OMS. Décommissionnement de Magento
Durée totale : 14 mois. Budget respecté. Zéro interruption de service. Et des résultats business mesurables dès le troisième mois.
FAQ
La méthode progressive coûte-t-elle plus cher que le big bang ?
Le coût total est généralement comparable, mais il est réparti différemment. Vous payez un surcoût d’intégration lié à la façade et à la cohabitation des systèmes. En revanche, vous économisez sur les dépassements budgétaires, les incidents de lancement, et la période de double run. Le vrai avantage est la prévisibilité : chaque incrément a un budget connu et un ROI mesurable.
Comment gérer les dépendances entre domaines pendant la migration ?
C’est le sujet technique le plus complexe. La clé est de bien cartographier les dépendances en amont et de choisir l’ordre de migration en conséquence. Les domaines les plus indépendants migrent en premier. Pour les dépendances inévitables, utilisez des contrats d’API stables entre l’ancien et le nouveau système, et prévoyez des adaptateurs.
Cette approche fonctionne-t-elle pour les petites plateformes ?
Pour un petit site avec 500 produits et un trafic modeste, le big bang peut être acceptable — le risque est limité et la complexité gérable. La méthode progressive prend tout son sens à partir du moment où le site génère un chiffre d’affaires significatif et où une interruption aurait un impact business mesurable. En général, au-delà de 2-3 millions de CA en ligne.
Quelle est la compétence clé pour réussir une migration progressive ?
L’architecture d’intégration. La personne qui conçoit la façade, les contrats d’API et les stratégies de routage est le maillon critique. Ce rôle nécessite une expertise senior en architecture distribuée et une compréhension fine du domaine métier e-commerce. C’est typiquement un profil qu’on ne trouve pas chez les ESN généralistes.