Retailer omnicanal — Architecture composable CommerceLayer + Akeneo + Mirakl

#Contexte

Retailer omnicanal français, anonymisé au titre d'un accord de confidentialité. Distribution multi-marques, magasins physiques, site e-commerce propriétaire et vente sur des places de marché tierces. La plateforme est copilotée par la direction e-commerce et la DSI — configuration fréquente dans le secteur E-commerce & Retail : l'une porte le chiffre d'affaires en ligne, l'autre le contrat de licence.

Le socle historique est une suite monolithique : catalogue, commande, contenu et front-office vivent dans le même produit, sous le même contrat annuel. Le catalogue, lui, ne vit pas vraiment dans la plateforme. Il vit dans des classeurs Excel que l'équipe produit s'échange, complète et corrige à la main. Les traductions sont confiées à des traducteurs externes, au fil de l'eau, fichier par fichier, sans référentiel commun.

Ce montage a tenu tant que l'enseigne vendait sur un canal. Il a cédé quand la direction générale a décidé d'élargir l'offre par une place de marché.

#L'enjeu

Trois problèmes se cumulaient, et un seul apparaissait dans les tableaux de bord de direction.

Le premier est financier. La licence du monolithe représentait une ligne fixe importante, pour un périmètre fonctionnel dont l'entreprise n'utilisait qu'une partie. Payer chaque année des modules qu'on n'active pas est la dépense la plus indolore du mid-market : elle ne déclenche aucune alerte, elle se reconduit.

Le deuxième est opérationnel. Chaque évolution du front dépendait du calendrier de la suite : livrer une nouvelle mécanique commerciale se comptait en trimestres, pas en semaines.

Le troisième est humain, et personne ne le chiffrait. L'équipe produit passait l'essentiel de son temps à saisir, relire des tableurs et coordonner des traducteurs — des profils recrutés pour arbitrer un assortiment, occupés à de la recopie.

Notre position d'entrée : on chiffre le ROI avant de signer. Avant tout engagement, nous avons reconstitué le coût complet du statu quo — licences, charge d'équipe absorbée par la saisie, délais subis — et l'avons comparé à celui d'une architecture cible. C'est ce chiffrage, et non une préférence technologique, qui a déclenché la décision.

#La solution

Une architecture composable : des briques spécialisées reliées par API, plutôt qu'un produit unique qui prétend tout couvrir (définition composable commerce, guide stack composable mid-market).

CommerceLayer comme moteur de commerce headless : panier, prix, stocks et commandes exposés en API et consommés par un front découplé (définition headless commerce). Akeneo PIM devient le référentiel produit unique : le catalogue quitte les classeurs Excel pour un outil où chaque attribut a un propriétaire, un statut de complétude et un cycle de validation (définition PIM). Mirakl porte la brique place de marché et permet d'élargir l'offre sans porter le stock.

Le point déterminant n'est pas la liste des outils, c'est le contrat de responsabilité entre eux. Akeneo est source de vérité du contenu produit, CommerceLayer du transactionnel, Mirakl de l'offre des vendeurs tiers. Chaque donnée a un et un seul propriétaire système, ce qui supprime la classe de bugs la plus coûteuse en e-commerce omnicanal : deux référentiels qui divergent sans que personne ne sache lequel fait autorité.

Nous avons écarté le big bang : le monolithe est sorti surface par surface, chaque brique quittant le périmètre historique une fois sa remplaçante vérifiée en production.

#Déroulé

Trente-deux semaines entre le lancement de la migration et le décommissionnement du socle historique.

La séquence a commencé par le référentiel produit, délibérément. Tant que le catalogue reste dans des tableurs, aucune brique en aval ne peut être fiable. La reprise du catalogue, le modèle d'attributs et les règles de complétude ont constitué le premier jalon — démarche détaillée dans notre guide implémentation Akeneo PIM en ETI.

Le moteur de commerce a suivi, avec une bascule progressive et une période de fonctionnement en parallèle pour comparer les comportements réels avant coupure.

La place de marché est arrivée en dernier, une fois le référentiel stabilisé : l'ouvrir sur un catalogue non maîtrisé revient à industrialiser le désordre.

Le décommissionnement du contrat de licence historique a clôturé la séquence. C'est cette date, et non la mise en production, qui déclenche l'économie réelle.

#Résultats

L'économie de licences s'établit à 419 k€ par an, par sortie du contrat monolithique remplacé par des abonnements aux briques effectivement utilisées.

Le time-to-market est divisé par 3 sur les évolutions front. Une modification qui devait s'aligner sur le calendrier de la suite se livre au rythme propre de l'équipe.

Le troisième résultat est le moins spectaculaire et probablement le plus structurant : l'équipe produit a été déchargée du travail manuel Excel et de la coordination des traducteurs, et s'est recentrée sur la stratégie et le merchandising. Le PIM a absorbé la saisie et la propagation multilingue ; les personnes qui portaient ces tâches sont revenues à leur métier.

#Enseignements

Commencer par le référentiel produit. C'est contre-intuitif — le PIM est la brique la moins visible pour un comité de direction — mais c'est la seule séquence qui évite de reconstruire deux fois.

L'économie de licences ne se réalise qu'à la sortie du contrat. Une migration qui ne planifie pas explicitement le décommissionnement produit un gain qui n'arrive jamais dans le compte de résultat.

Le composable n'est pas un objectif, c'est un arbitrage. Il apporte de la modularité et coûte de l'intégration : chaque brique est un contrat d'API à maintenir. Sur un catalogue simple et mono-canal, une suite intégrée reste souvent le bon choix. Ici, l'ouverture marketplace et la contrainte multilingue rendaient l'arbitrage net (service Headless Commerce Nehos).

Une limite assumée : nous ne publions pas le budget de ce projet. Le montant relève du NDA, et nous préférons une étude de cas sans budget à une étude de cas avec un chiffre approximatif. Ce qui engage un client, c'est le chiffrage produit avant signature.