Exemple de situation — Retailer omnicanal : architecture composable CommerceLayer, Akeneo et Mirakl
Exemple de situation, sans client nommé : sortie d'une suite e-commerce monolithique vers une architecture composable, surface par surface, avec un seul propriétaire système par donnée.
Durée
Plusieurs mois, du lancement de la migration au décommissionnement du contrat de licence historique, à ajuster selon le périmètre réel.
Équipe
Équipe dimensionnée selon le projet
Technologies clés
Coût du statu quo
Licences, charge de l'équipe produit et délais subis, reconstitués avant tout engagement pour servir de base de comparaison
Délai front
Délai de livraison d'une évolution du front, relevé avant le découplage puis après
Charge manuelle
Temps de l'équipe produit passé en saisie et en coordination de traducteurs, avant et après le PIM
Un propriétaire
Chaque donnée a un seul système qui fait autorité : contenu produit, transactionnel, offre des vendeurs tiers
#Contexte (exemple de situation)
Ce cas est un exemple de situation, construit pour illustrer notre méthode : il ne décrit aucun client réel et ne contient aucun résultat chiffré.
Le profil retenu est un retailer omnicanal français. Distribution multi-marques, magasins physiques, site e-commerce propriétaire et vente sur des places de marché tierces. La plateforme est souvent 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 tient tant que l'enseigne vend sur un canal. Il cède quand la direction générale décide d'élargir l'offre par une place de marché.
#L'enjeu
Trois problèmes se cumulent dans ce type de situation, et un seul apparaît clairement dans les tableaux de bord de direction. Le premier est financier : la licence de la suite monolithique représente une ligne fixe importante, pour un périmètre fonctionnel dont l'entreprise n'utilise qu'une partie.
Payer chaque année un moteur de recherche interne, un CMS et un module marketing qu'on n'active pas est la dépense la plus indolore du commerce mid-market : elle ne déclenche aucune alerte, elle se reconduit.
Le deuxième problème est opérationnel : chaque évolution du front dépend du calendrier de la suite et de ses fenêtres de mise à jour. Livrer une nouvelle mécanique commerciale se compte en trimestres, pas en semaines, ce qui interdit toute logique d'itération.
Le troisième problème est humain, et personne ne le chiffre : l'équipe produit passe l'essentiel de son temps à saisir, relire des tableurs et coordonner des traducteurs. Des profils recrutés pour construire une offre et arbitrer un assortiment sont occupés à de la recopie. Une contrainte s'ajoute : l'ouverture d'une place de marché est déjà décidée par la direction générale.
Il ne s'agit pas d'évaluer si le retailer doit élargir son offre, mais de déterminer sur quelle architecture cet élargissement peut tenir sans multiplier les référentiels divergents.
#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 écartons le big bang : le monolithe sort surface par surface, chaque brique quittant le périmètre historique une fois sa remplaçante vérifiée en production.
#Déroulé
La durée dépend du périmètre : elle court du lancement de la migration au décommissionnement du socle historique.
La séquence commence 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 constituent le premier jalon — démarche détaillée dans notre guide implémentation Akeneo PIM en ETI.
Le moteur de commerce suit, 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é arrive 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 clôt la séquence. C'est cette date, et non la mise en production, qui déclenche l'économie réelle.
#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. Quand une place de marché s'ajoute et que la contrainte multilingue s'impose, l'arbitrage devient net (service Headless Commerce Nehos).
Questions & réponses
Questions fréquentes sur cet exemple de situation
Le prix dépend du périmètre (nombre de catalogues, de langues, de canaux, de connecteurs). Nous chiffrons sur devis, en 48 h après un premier échange, sur la base du coût réel du statu quo : c'est ce chiffrage qui engage, pas un montant publié sur une page web. Nous commençons par un audit adapté : audit IA express d'une journée (990 € HT, déduit du projet s'il est lancé dans les trois mois) ou audit approfondi de cinq jours (2 125 € HT).
Parce que tant que le catalogue vit dans des classeurs Excel, aucune brique en aval ne peut être fiable. Le moteur de commerce et la place de marché consommeraient des données dont personne ne garantit la fraîcheur ni la complétude, et il faudrait reconstruire une fois le référentiel assaini. Commencer par le référentiel produit est contre-intuitif pour un comité de direction — le PIM est la brique la moins visible — mais c'est la seule séquence qui évite de payer deux fois le même travail.
Non. Cette page est un exemple de situation construit pour illustrer notre méthode. Elle ne décrit aucun client réel et ne contient aucun résultat chiffré. Les clients dont nous pouvons parler sont présentés sur la page des références clients.
Non, et c'est une limite qu'on assume. Le composable apporte de la modularité et coûte de l'intégration : chaque brique ajoutée est un contrat d'API à maintenir. Sur un catalogue simple, mono-canal et mono-langue, une suite intégrée reste souvent l'arbitrage rationnel. Quand une place de marché s'ajoute et que la contrainte multilingue s'impose, l'arbitrage devient plus net. Nous le démontrons chiffres à l'appui avant de signer, pas après.
Par différence entre le contrat de la suite monolithique sortie du périmètre et les abonnements aux briques effectivement utilisées dans l'architecture cible. Le calcul se date du décommissionnement du contrat historique, pas de la mise en production de la nouvelle plateforme : une migration qui ne planifie pas explicitement la sortie du contrat produit un gain qui n'arrive jamais dans le compte de résultat.
Que pour chaque type de donnée, une seule brique fait autorité. Le contenu produit appartient au PIM, le transactionnel appartient au moteur de commerce, l'offre des vendeurs tiers appartient à la place de marché. Les autres briques la consomment mais ne la modifient pas. Cette règle 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 a raison.