Architecture composable : retour d'expérience sur un projet à 500K€

Le contexte : un monolithe qui étouffe

Un retailer mode multi-marques. 4 marques, 12 marchés, 80 000 SKU, 45 millions d’euros de CA en ligne. La plateforme historique : un monolithe Magento 2 customisé sur 5 ans, qui porte les 4 marques sur une seule instance.

Les symptômes étaient classiques :

• Temps de déploiement : 4 heures en fenêtre de maintenance nocturne, une fois par mois
• Couplage entre marques : un changement sur la marque A cassait régulièrement la marque B
• Performance dégradée : temps de chargement de 4-6 secondes sur mobile, avec des pics à 12 secondes pendant les soldes
• Coût de développement : chaque nouvelle fonctionnalité nécessitait de tester l’impact sur les 4 marques
• Scalabilité limitée : le Black Friday imposait un gel des déploiements 3 semaines avant et un surdimensionnement x10 de l’infrastructure

Le CTO avait un mandat clair : moderniser la plateforme sans interrompre le business. Budget : 500K euros sur 12 mois.

La décision architecturale

Pourquoi composable et pas un autre monolithe

Le réflexe classique aurait été de migrer vers Shopify Plus ou Salesforce Commerce Cloud. Mais ces options avaient des limites pour ce contexte :

• Multi-marques : gérer 4 identités visuelles radicalement différentes sur une seule plateforme nécessite une flexibilité front-end que les solutions SaaS monolithiques offrent difficilement
• Multi-marchés : 12 marchés avec des règles fiscales, logistiques et promotionnelles spécifiques
• Intégrations existantes : ERP SAP, PIM Akeneo, OMS custom — des intégrations qui fonctionnaient et qu’il ne fallait pas casser

L’architecture composable permettait de garder ce qui marchait, remplacer ce qui ne marchait pas, et ajouter de la flexibilité pour le futur.

L’architecture cible

Après 3 semaines de cadrage technique, voici le schéma retenu :

Couche Commerce :

• Commercetools comme moteur commerce headless (catalogue, panier, commandes, promotions)
• Migration progressive depuis Magento 2 via le pattern Strangler Fig

Couche Front-end :

• Next.js avec App Router pour chaque marque (4 applications front-end indépendantes)
• Design system partagé avec des tokens de marque pour la personnalisation
• Déploiement sur Vercel avec Edge Functions pour la personnalisation

Couche Contenu :

• Contentful comme CMS headless (remplace le CMS Magento)
• Modèle de contenu partagé avec des variantes par marque

Couche Recherche :

• Algolia pour la recherche et le merchandising (remplace ElasticSearch custom)

Couche Orchestration :

• BFF (Backend For Frontend) en Node.js sur Google Cloud Run
• Le BFF agrège les appels aux différents services et expose une API unifiée au front-end

Intégrations préservées :

• SAP ERP (stock, comptabilité) via les connecteurs existants, re-routés vers Commercetools
• Akeneo PIM (catalogue produit) — publication vers Commercetools au lieu de Magento
• OMS custom — adapté pour recevoir les commandes depuis Commercetools

Le séquencement : 12 mois en 4 phases

Phase 1 : Fondations (mois 1-3) — 120K euros

Objectif : poser le socle technique et migrer la première brique.

Réalisations :

• Setup Commercetools avec le modèle de données (types produit, catégories, attributs custom)
• Migration du catalogue depuis Akeneo vers Commercetools (synchronisation bidirectionnelle)
• Développement du BFF avec les endpoints critiques (catalogue, recherche, panier)
• Premier front-end Next.js pour la marque principale (la plus grosse en CA)
• Pipeline CI/CD complet : GitHub Actions + Vercel + Google Cloud Run
• Intégration Algolia avec synchronisation depuis Commercetools

Résultat mesurable : le nouveau front-end de la marque principale est en production en canary (10% du trafic). Temps de chargement : 1,2 secondes vs 4,5 secondes sur l’ancien.

Phase 2 : Commerce core (mois 4-6) — 150K euros

Objectif : migrer le tunnel d’achat et les fonctionnalités commerce critiques.

Réalisations :

• Tunnel d’achat complet sur le nouveau front-end (panier, checkout, paiement, confirmation)
• Intégration des passerelles de paiement (Adyen pour les 12 marchés)
• Gestion des promotions dans Commercetools (migration des 200+ règles promo de Magento)
• Gestion des comptes clients avec SSO (migration des 500K comptes)
• Connexion OMS : les commandes passées sur le nouveau front-end arrivent dans l’OMS existant
• Basculement du trafic de la marque principale à 100%

Le moment critique : la migration des règles promotionnelles. Magento stockait des promotions avec des logiques custom complexes (remise conditionnelle croisée entre catégories, offres fidélité multi-niveaux). Il a fallu 3 semaines de reverse engineering pour documenter les 200 règles et les recréer dans Commercetools. C’est le genre de complexité invisible qu’aucun planning théorique ne capture.

Phase 3 : Multi-marques (mois 7-9) — 130K euros

Objectif : déployer les 3 autres marques sur la nouvelle architecture.

Réalisations :

• Fork du front-end pour les marques 2, 3 et 4 avec les tokens de design spécifiques
• Configuration Commercetools multi-store (un projet par marque, catalogue partagé avec des variations)
• Migration du contenu éditorial de chaque marque vers Contentful
• Tests de charge : simulation du Black Friday (x15 le trafic normal)
• Décommissionnement progressif de Magento (marque par marque)

La bonne surprise : grâce au design system partagé, le déploiement des marques 2, 3 et 4 a pris 60% moins de temps que la marque 1. Les patterns étaient établis, les intégrations éprouvées. C’est le bénéfice tangible de l’investissement dans le socle.

Phase 4 : Optimisation et décommissionnement (mois 10-12) — 100K euros

Objectif : optimiser les performances, décommissionner Magento, stabiliser.

Réalisations :

• Extinction complète de Magento 2
• Optimisation front-end : lazy loading avancé, prefetch intelligent, optimisation des images
• Mise en place de l’observabilité complète (OpenTelemetry + Grafana)
• Définition des SLO par parcours critique
• Documentation technique et transfert aux équipes internes
• Formation des équipes sur la stack Commercetools + Next.js

Les résultats mesurés

Après 12 mois, comparaison avant/après sur les métriques clés :

Performance :

• Temps de chargement mobile : 4,5s vers 1,4s (-69%)
• Core Web Vitals : toutes les pages en vert (LCP < 2,5s, FID < 100ms, CLS < 0,1)
• Temps de réponse API p95 : 800ms vers 120ms

Business :

• Taux de conversion global : +23% (principalement grâce à la performance et au nouveau tunnel d’achat)
• Taux d’abandon panier : -31%
• CA en ligne sur les 3 premiers mois post-migration : +18% vs même période année précédente

Opérationnel :

• Fréquence de déploiement : 1/mois vers 3/jour
• Lead time d’un changement : 3 semaines vers 2 jours
• Incidents en production : 4/mois vers 0,5/mois
• Coût d’infrastructure : -25% (malgré une meilleure performance)

Indépendance des marques :

• Chaque marque déploie indépendamment
• Un changement sur la marque A ne peut plus casser la marque B
• Time-to-market pour une nouvelle fonctionnalité spécifique à une marque : divisé par 4

Les leçons apprises

Ce qui a bien fonctionné

• Le séquencement progressif : migrer marque par marque a réduit le risque et permis d’apprendre
• Le BFF : la couche d’orchestration a absorbé la complexité d’intégration et simplifié les front-ends
• L’investissement dans le design system : le coût initial a été largement compensé par la vitesse de déploiement des marques suivantes

Ce qui a été plus difficile que prévu

• La migration des promotions : +3 semaines par rapport au planning initial
• La synchronisation des stocks en temps réel entre SAP, Commercetools et l’OMS : des edge cases sur les réservations de stock qui ont nécessité du développement custom
• La formation des équipes : la montée en compétence sur Commercetools et Next.js a pris plus de temps que prévu pour les développeurs habitués à Magento

Ce qu’on ferait différemment

• Commencer par Algolia avant le front-end : l’impact business immédiat de la recherche est plus rapide à démontrer
• Prévoir 20% de buffer sur chaque phase pour les imprévus (on était à 10%, c’était insuffisant)
• Impliquer les équipes métier plus tôt dans la configuration de Commercetools, pas seulement en fin de phase

FAQ

L’architecture composable est-elle adaptée à toutes les tailles d’entreprise ?

Non. En dessous de 10 millions de CA en ligne, la complexité d’une architecture composable est rarement justifiée. Un Shopify Plus bien configuré ou un monolithe moderne couvrent largement le besoin. Le composable prend son sens quand vous avez des besoins de multi-marques, multi-marchés, d’intégrations complexes, ou de performance extrême.

Commercetools était-il le bon choix ?

Pour ce contexte, oui. Le modèle de données flexible, le support natif multi-store et l’API-first étaient déterminants. Les alternatives sérieuses étaient Medusa (open source, moins mature à l’époque) et Elastic Path (plus cher, moins flexible sur le multi-store). Le choix dépend fortement du contexte — il n’y a pas de réponse universelle.

Comment gérer la dépendance aux multiples fournisseurs SaaS ?

C’est un risque réel. Notre stratégie : des contrats d’API stables entre les services, un BFF qui isole les front-ends des changements de fournisseur, et une architecture qui permet de remplacer un composant sans tout reconstruire. Nous avons aussi documenté les critères de sortie pour chaque fournisseur et identifié les alternatives en cas de besoin.

Le budget de 500K euros est-il réaliste pour un projet similaire ?

Pour un périmètre comparable (4 marques, 12 marchés, intégrations existantes), oui. La clé est d’avoir une équipe senior de 3-4 personnes qui maîtrisent à la fois l’architecture composable et le domaine e-commerce. Avec des profils juniors ou une ESN généraliste, le même périmètre coûterait facilement le double et prendrait 18-24 mois au lieu de 12.