Le « Composable Commerce » : qu'est-ce que c'est, combien ça coûte et qui devrait l'ignorer ?

Le « composable commerce » est une architecture de commerce électronique qui remplace une plateforme unique « tout-en-un » par des services déployés indépendamment, tels qu’une vitrine en ligne, un moteur de recherche, un panier d’achat et un système de gestion de contenu, reliés via des API plutôt que regroupés au sein d’une seule base de code. Elle permet aux grandes équipes de remplacer n’importe quel composant sans avoir à reconstruire le reste de la pile. Pour un fabricant ou un distributeur disposant d’une seule équipe de développement, cette flexibilité coûte généralement plus cher que la plateforme qu’elle remplace, tant en termes d’effectifs d’ingénieurs que de contrats avec les fournisseurs et de maintenance de l’intégration.

On nous pose désormais des questions sur le « composable commerce » presque chaque trimestre, généralement de la part d’un fondateur ou d’un directeur technique qui vient d’assister à une présentation d’un fournisseur entièrement axée sur la promesse de flexibilité. Cette présentation n’est pas fausse. Ce qu’il omet, c’est la facture. Assembler une vitrine en ligne, un moteur de recherche, un panier, un moteur de tarification, un système de gestion de contenu et un prestataire de paiement provenant de fournisseurs distincts ne simplifie pas votre infrastructure e-commerce : cela ne fait que déplacer cette complexité de la feuille de route d’un fournisseur de plateforme vers votre propre équipe, où elle se manifeste sous la forme de travaux d’intégration, de renouvellements de contrats et d’une rotation des astreintes que personne n’avait prévue dans le budget.

Cet article vous propose une définition claire, la liste des composants avec le nom des produits, ainsi qu'un modèle de coûts sur trois ans incluant les postes que la plupart des devis omettent. Il vous indique également sans détour quand la réponse est « non ».

Qu'est-ce que le « Composable Commerce », et qu'est-ce que ce n'est pas ?

Le « commerce modulable » (Composable Commerce) est une approche architecturale dans laquelle les fonctions traditionnelles d’une plateforme de commerce électronique, telles que le catalogue de produits, le panier, le paiement, la recherche et la gestion de contenu, sont décomposées en services distincts pouvant être déployés indépendamment les uns des autres. Au lieu de s’appuyer sur le code source d’un seul fournisseur, chaque fonction provient d’un fournisseur différent et est connectée via des API. L’entreprise assemble ainsi sa propre pile technologique plutôt que d’en acheter une toute faite.

Cette définition est souvent confondue avec celle du « headless commerce », alors que la distinction est importante. Le « headless commerce » consiste en une simple décomposition : la couche de présentation front-end est séparée du moteur de commerce back-end, généralement pour permettre à une entreprise de créer une vitrine personnalisée sur une plateforme telle qu’Adobe Commerce ou Shopify Plus tout en conservant le back-end intact. Le « composable commerce » va plus loin. Il décompose le back-end lui-même, en séparant la recherche, la tarification, le contenu et les paiements en services distincts de pointe, plutôt que de les regrouper au sein d’une seule plateforme.

L'architecture de référence du « Composable Commerce »

Une architecture de commerce modulable opérationnelle se divise généralement en cinq couches, chacune étant occupée par un fournisseur spécifique plutôt que par une catégorie générique :

1. Moteur de commerce électronique: commercetools ou Adobe Commerce fonctionnant en mode API uniquement, gérant la logique du panier, du catalogue et des commandes.
2. Front-end: un framework tel que Vue Storefront, conçu comme une application indépendante qui interroge le moteur de commerce via GraphQL.
3. Recherche et exploration: Algolia ou Elasticsearch, indexés indépendamment du moteur de commerce et interrogés directement par l'interface utilisateur.
4. Contenu et merchandising: Contentful, qui permet de gérer les pages d'accueil et la présentation des produits indépendamment des données produit elles-mêmes.
5. Paiements: Stripe ou Adyen, intégrés en tant que service autonome plutôt que sous forme de passerelle intégrée.

Chaque connexion entre ces cinq couches d'une architecture de commerce modulable constitue un contrat, un mappage de données et un point de défaillance potentiel. C'est justement ce que le schéma d'architecture ne montre jamais.

Quel est le coût réel du « Composable Commerce » sur trois ans ?

Les fournisseurs facturent le « composable commerce » à l'unité ou à l'appel d'API, et le devis que vous recevez couvre exactement ce que vous avez demandé, sans rien de ce que vous n'avez pas pensé à demander. Le coût réel sur trois ans comprend cinq postes qui apparaissent rarement dans une proposition :

1. Middleware d'intégration: une plateforme telle qu'Alumio, ou une couche développée sur mesure, permettant d'assurer la synchronisation des données entre le moteur de commerce, l'ERP et l'index de recherche. Prévoyez ici un budget pour un contrat dédié, et non des frais de mise en place ponctuels.
2. Observabilité et journalisation: lorsque cinq fournisseurs gèrent chacun une partie du parcours client, diagnostiquer un problème au niveau du paiement implique de recouper les journaux sur cinq tableaux de bord. Ces outils, ainsi que le temps nécessaire à leur maintenance, représentent un coût récurrent.
3. Un deuxième développeur front-end: un front-end modulable est une application autonome. Il nécessite la même maintenance continue, les mêmes mises à jour des dépendances et les mêmes correctifs de sécurité que n’importe quelle autre base de code en production, ce qui implique un deuxième développeur à part entière, et non pas une fraction de poste.
4. Renouvellements de contrat basés sur l'utilisation: Algolia et Contentful proposent tous deux une tarification par paliers d'utilisation. Un catalogue passant de 10 000 à 40 000 références, ou un pic de trafic lors d'une campagne saisonnière, vous fait passer automatiquement à un palier supérieur, et ce chiffre diminue rarement lors du renouvellement.
5. Le coût du remplacement d'un composant décevant: tout l'intérêt du « composable commerce » réside dans le fait que l'on peut remplacer un élément sans toucher au reste. Dans la pratique, remplacer un moteur de recherche implique de réindexer le catalogue, de redéfinir les règles de pertinence et d'effectuer des tests de régression sur chaque page qui fait appel à ce service. C'est moins coûteux qu'une migration complète vers une nouvelle plateforme. Mais ce n'est pas gratuit.

Que signifient les affirmations de MACH Architecture Ecommerce une fois l'acronyme supprimé ?

À l'origine, l'architecture MACH dans le domaine du e-commerce était l'acronyme de « Microservices-based, API-first, Cloud-native et Headless », les quatre caractéristiques techniques utilisées par la MACH Alliance pour certifier les fournisseurs. Depuis, la MACH Alliance a évolué et décrit désormais ces mêmes caractéristiques comme « ouvertes », « modulaires » et « connectées », mais le principe fondamental de l’architecture MACH pour le commerce électronique reste inchangé : une pile certifiée MACH est constituée d’éléments déployables indépendamment, accessibles via des API, hébergés dans le cloud plutôt qu’en local, et découplés de toute interface utilisateur spécifique.

Il ne s’agit pas là d’un simple argument marketing. Chacune de ces caractéristiques est un trait architectural réel et vérifiable, et le rapport « 2026 Enterprise Technology Report » de la MACH Alliance, basé sur 600 décideurs issus de 7 marchés, a révélé que les organisations ayant atteint un niveau de maturité en matière de composabilité étaient 6 fois plus susceptibles de faire état d’un retour sur investissement (ROI) clair issu d’initiatives d’IA que les organisations encore aux premiers stades de planification. Ce que cet acronyme ne vous dit pas, c’est si votre équipe fait partie des organisations capables de tirer parti de ce retour sur investissement. Une pile certifiée MACH récompense les équipes qui possèdent déjà une solide discipline d’ingénierie. Elle ne crée pas cette discipline à elle seule.

Les écueils des projets de commerce B2B « headless »

Les implémentations de commerce « headless » en B2B échouent plus souvent que celles en B2C, et la raison est presque toujours la même : la tarification B2B n’est pas un chiffre statique extrait d’une fiche produit, mais dépend des conditions contractuelles, du niveau de clientèle, des paliers de volume et des exceptions négociées, souvent stockées dans un ERP tel que NetSuite OneWorld ou Microsoft Dynamics 365 Business Central plutôt que dans la plateforme de commerce elle-même.

Dans une solution de commerce B2B « headless », cette logique de tarification doit être mise à jour au moment même où un client consulte un prix, et non stockée en cache lors d’une synchronisation nocturne, car un prix contractuel obsolète constitue un problème de service client et, parfois, un problème de conformité. Cela signifie que chaque affichage d’une page produit, chaque mise à jour du panier et chaque demande de devis déclenche un appel en temps réel vers l’ERP. Si cette connexion est lente, mal mise en cache ou conçue à la va-vite, la vitrine en ligne donne l’impression de ne pas fonctionner correctement, même si chaque service pris individuellement fonctionne parfaitement.

Les 4 conditions qui doivent être remplies avant de décomposer quoi que ce soit

Avant de retirer un composant d'une plateforme en service, quatre conditions doivent être remplies simultanément. La plupart des fabricants et distributeurs avec lesquels nous travaillons ne respectent pas au moins deux d'entre elles.

1. Vous disposez d'au moins 4 ingénieurs dédiés au commerce électronique. Si vous en avez moins, vous ne disposez pas des effectifs nécessaires pour gérer à la fois les intégrations avec plusieurs fournisseurs et le développement de nouvelles fonctionnalités.
2. Vous effectuez des déploiements au moins une fois par semaine. L'architecture modulable est conçue pour les équipes qui déploient constamment des modifications. Si votre cadence de déploiement est mensuelle ou plus lente, la charge opérationnelle liée à la gestion de plusieurs services l'emporte sur le gain de flexibilité obtenu.
3. Les données de votre catalogue n'appartiennent pas à votre ERP. Si Prophet 21, NetSuite OneWorld ou un autre ERP constitue le système de référence pour la tarification et les stocks, cette dépendance dicte votre architecture, quelle que soit la présentation de l'interface utilisateur.
4. Votre tarification repose sur des tarifs catalogue, et non sur des contrats. La tarification par contrat, évoquée plus haut, ajoute un niveau de complexité en temps réel qu’une pile modulable doit résoudre, et non contourner.

Qui devrait complètement ignorer le « Composable Commerce » ?

Le « composable commerce » n’est pas un bon investissement pour une entreprise qui ne remplit pas au moins deux des quatre conditions ci-dessus, ce qui est le cas de la plupart des fabricants, distributeurs et grossistes avec lesquels nous discutons. Si votre équipe compte deux ou trois développeurs, effectue des déploiements toutes les quelques semaines plutôt que tous les quelques jours, et que votre tarification est gérée dans Prophet 21 ou un ERP similaire, une pile entièrement décomposée mobilisera du temps d’ingénierie qui devrait être consacré à l’expérience client sur la vitrine en ligne, celle que vos clients remarquent réellement.

Ce n'est pas une critique de l'architecture. C'est une question d'adéquation. Une plateforme bien conçue, comme Adobe Commerce ou Magento Open Source, associée à une interface utilisateur moderne, offre à cette même équipe une grande partie de la flexibilité recherchée, pour un coût opérationnel bien moindre.

Pour être juste envers l’autre camp : une architecture modulable offre véritablement un avantage qu’une architecture monolithique ne peut pas offrir. Elle permet à des équipes distinctes, travaillant selon des cycles de déploiement séparés, de prendre chacune en charge leur partie du parcours client sans avoir à attendre le déploiement d’une plateforme commune. Pour une organisation disposant d’équipes dédiées à la recherche, au contenu et au paiement, qui opèrent déjà de manière indépendante, cela représente un réel avantage financier. Pour une équipe unique qui doit tout gérer seule, cela constitue une charge supplémentaire qu’elle ne peut confier à personne.

Comment un distributeur utilisant Epicor Prophet 21 devrait interpréter cette décision

Si votre entreprise utilise Epicor Prophet 21 comme système de référence pour les stocks, l'historique des commandes et la tarification contractuelle, le choix de l'architecture s'impose en grande partie de lui-même. Prophet 21 est spécialement conçu pour les distributeurs et contient les données dont dépend votre site de vente en ligne pour chaque prix affiché à un client connecté. Séparer l'interface utilisateur de cette réalité ne supprime pas cette dépendance, cela ne fait qu'ajouter un saut réseau.

La meilleure approche consiste à considérer Prophet 21 comme la source de référence en matière de prix et de stocks, à le connecter à une plateforme de commerce électronique dotée de connecteurs ERP éprouvés, et à résister à la tentation de décomposer également la recherche, le contenu et le processus de paiement en relations avec des fournisseurs distincts, en plus de cette intégration. Notre travail d’intégration ERP avec Magento couvre les connecteurs spécifiques et les modèles de synchronisation qui garantissent la fiabilité de ce système en production, y compris la gestion des requêtes de prix en temps réel évoquées plus haut dans cet article.

L'architecture hybride que nous recommandons le plus souvent

Pour les fabricants et les distributeurs avec lesquels nous travaillons, la recommandation qui revient le plus souvent n’est ni entièrement modulable, ni un monolithe standard. Il s’agit d’Adobe Commerce ou de Magento Open Source comme moteur de commerce, conservé dans son intégralité plutôt que décomposé, dont deux éléments ont été délibérément dissociés : le front-end et, lorsque le volume le justifie, la fonction de recherche.

Côté front-end, Hyvä est désormais notre recommandation par défaut, plutôt qu’une solution entièrement personnalisée et modulable. Il s’agit d’un framework de thèmes natif de Magento qui supprime la pile front-end héritée pour la remplacer par une solution plus légère et plus rapide, sans que l’entreprise ait à mettre en place et à maintenir une application distincte, comme ce serait le cas avec un front-end entièrement « headless ».

Cette solution hybride offre à un distributeur ou à un fabricant l’essentiel de ce que promet le « composable commerce » : une vitrine plus rapide, des itérations front-end plus faciles et la possibilité d’ajouter ultérieurement une couche de recherche dédiée, sans avoir à conclure cinq contrats avec des fournisseurs ni à mettre en place l’équipe nécessaire pour les gérer. C’est la version qui correspond à l’équipe dont disposent réellement la plupart de nos clients, et non à celle que le dossier de présentation suppose qu’ils possèdent.