Commerce composable et architecture MACH : définition et quand l'adopter

Le commerce composable est une façon de construire une activité en ligne à partir de composants séparés et remplaçables, chacun couvrant une capacité métier comme le catalogue produit, les prix, le panier et le paiement, la recherche, le contenu ou la gestion des commandes. Les composants communiquent entre eux via des API, souvent selon une architecture MACH. Au lieu d'une plateforme qui fait tout, tu choisis un composant pour chaque tâche et tu peux en remplacer un sans reconstruire le reste. Shopify le décrit comme le fait de sélectionner et d'intégrer des « best-in-breed technologies » reliées par des API (Shopify).

Shopify attribue l'invention du terme au cabinet d'analystes Gartner. Les composants s'appellent des packaged business capabilities (PBC), et l'architecture suit généralement les principes MACH. Pour la plupart des marchands du mid-market, la réponse pratique n'est pas « passer au tout composable » mais « rendre le stack modulaire là où ça fait mal » : garder une plateforme e-commerce au cœur et y brancher des composants spécialisés un par un. Dans tous les cas, les données produit ont besoin d'un seul et unique propriétaire, et c'est le rôle d'un PIM.

Packaged business capabilities : une tâche métier par composant

Une packaged business capability est, selon les mots de Shopify, un composant logiciel qui représente « a particular business function », comme le paiement ou la recherche. Commerce Layer décrit un stack composable comme un stack construit autour de PBC « individually developed, deployed, and managed, connected through APIs » (Commerce Layer).

Dans un stack e-commerce typique, les PBC et les données dont chacune est propriétaire se présentent ainsi :

• Information produit : produits, attributs, variantes, traductions, images et affectations de catégories.
• Prix et promotions : listes de prix par marché ou groupe de clients, remises et règles de coupons.
• Panier et paiement : paniers, options de livraison et calcul des taxes au paiement.
• Paiements : moyens de paiement, autorisations et remboursements.
• Recherche et merchandising : l'index de recherche, les synonymes, le classement et les règles de mise en avant.
• Contenu : pages d'atterrissage, bannières, guides d'achat et autres pages éditoriales.
• Gestion des commandes : commandes, répartition des stocks entre entrepôts, expédition et retours.
• Comptes clients : identifiants, adresses, comptes entreprise B2B et soldes de fidélité.

Une PBC n'est pas la même chose qu'un microservice. Le paiement est une PBC parce qu'il produit un résultat métier complet ; la validation d'adresse à l'intérieur du paiement est un microservice. Une PBC peut contenir plusieurs microservices, et un éditeur peut vendre plusieurs PBC.

L'architecture MACH, lettre par lettre

MACH est l'étiquette que la plupart des éditeurs composables utilisent pour les principes techniques derrière leurs produits. Elle a été promue par la MACH Alliance, lancée en juin 2020 par commercetools, Contentstack, EPAM Systems et Valtech, et signifie « Microservices based, API-first, Cloud-native SaaS and Headless » (Gilbane).

• M pour microservices : chaque capacité est construite comme un ensemble de petits services, chacun tournant dans son propre processus et communiquant via des API légères, selon la définition donnée par Martin Fowler et James Lewis en 2014 (Martin Fowler). Consulte notre fiche architecture microservices pour voir comment cela s'applique au commerce.
• A pour API-first : chaque fonction est disponible via une API documentée avant qu'une interface utilisateur ne soit construite par-dessus.
• C pour cloud-native SaaS : l'éditeur héberge, dimensionne et met à jour le service ; tu le consommes au lieu de l'installer.
• H pour headless : pas de vitrine intégrée ; le front-end est une application séparée.

MACH décrit des composants ; composable décrit la façon de les assembler. Un stack peut être composable sans que chaque élément soit MACH. Beaucoup de configurations composables gardent un ERP sur site ou un ancien système d'entrepôt et l'enveloppent d'une API. Notre fiche architecture MACH traite de la certification.

Ce que t'apporte le remplacement d'un composant à la fois

L'intérêt du commerce composable repose sur quelques gains concrets. Ils sont réels, mais chacun dépend du travail d'intégration décrit plus bas.

• Remplacer une capacité faible sans changer de plateforme. Si la recherche sur le site échoue sur les références techniques, tu changes le composant de recherche et tu laisses le paiement, les commandes et la vitrine tels quels.
• Un spécialiste par tâche. Un vendeur B2B peut ajouter un moteur de prix qui gère des listes de prix par revendeur, ce que beaucoup de plateformes tout-en-un ne couvrent que via des apps.
• Des cycles de mise en production séparés. L'équipe front-end peut livrer une nouvelle fiche produit sans attendre une mise en production back-end, et inversement.
• Monter en charge là où se trouve la charge. Avec des composants cloud-native SaaS, l'éditeur dimensionne la recherche ou la vitrine pour un pic de soldes sans que tu aies à dimensionner des serveurs pour tout le stack.

Headless ou composable, et le juste milieu hybride

Nous avons traité la séparation du front-end dans qu'est-ce que le commerce headless. La distinction en bref : le headless déplace une frontière, entre la vitrine et le back-end. Le composable en déplace plusieurs, à l'intérieur du back-end. En pratique, les marchands se retrouvent dans l'une de quatre configurations :

• Plateforme tout-en-un : un seul éditeur gère vitrine, catalogue, paiement et commandes ; les fonctions supplémentaires viennent de l'app store de la plateforme.
• Headless sur une plateforme : un front-end sur mesure par-dessus un seul back-end e-commerce.
• Hybride ou modulaire : une plateforme e-commerce reste au cœur, et une ou deux capacités, souvent la recherche, le contenu ou l'information produit, viennent d'outils spécialisés.
• Entièrement composable : le back-end lui-même est assemblé à partir de PBC de différents éditeurs, avec un front-end headless et une couche d'intégration entre les deux.

Le juste milieu hybride est courant, même dans les grandes entreprises. Dans une enquête menée par Shopify avec IDC auprès de plus de 1 000 grandes entreprises, 45 % avaient « a composable front end with a full-stack back end » (Shopify). L'enquête porte sur de grandes entreprises, pas sur des marchands du mid-market, qui ont généralement moins de développeurs pour faire tourner un back-end entièrement composable.

Qui est propriétaire de quelles données dans un stack composable

La décision de conception la plus importante n'est pas le choix des éditeurs, mais le choix du système de référence pour chaque type de données. Prenons une marque mid-market d'équipement outdoor avec 4 000 SKU, des boutiques en ligne dans trois pays, un portail B2B pour les revendeurs et deux marketplaces :

La règle derrière ce tableau : chaque champ est écrit à un seul endroit et lu partout ailleurs. Quand le PIM et la plateforme e-commerce peuvent tous deux modifier les titres produit, ou que le CMS garde sa propre copie d'une description produit, les versions divergent et personne ne sait laquelle est la bonne. Le SKU et le GTIN deviennent les clés de jointure entre systèmes, ils doivent donc être uniques et stables.

Quand le commerce composable convient à un marchand du mid-market

Selon les propres recommandations de Shopify, le composable n'est « probably not right for you » sauf si tu as une vraie maturité digitale, avec une équipe technique expérimentée et des besoins de livraison complexes. Pour un marchand du mid-market, ces signaux aident à décider.

Signaux en faveur de composants composables

• Une capacité de ta plateforme actuelle bloque du chiffre d'affaires et aucune app ne règle le problème, par exemple des listes de prix B2B par revendeur ou une recherche sur 40 000 SKU techniques.
• Tu vends via plusieurs front-ends (boutiques en ligne par pays, portail B2B, bornes) qui doivent partager produits, prix et stock.
• Tu as des développeurs en interne ou une agence sous contrat longue durée, et quelqu'un qui est responsable de la couche d'intégration.
• Ton modèle de données produit est déjà propre : attributs typés, vraies variantes, un SKU par article vendable.

Signaux en faveur d'une plateforme avec quelques outils spécialisés

• Ton équipe modifie la boutique surtout via les écrans d'administration et les apps, sans développeur d'astreinte.
• Tes problèmes de croissance portent sur le trafic, l'assortiment ou le contenu produit, pas sur les limites de la plateforme.
• Tu gères une ou deux boutiques en quelques langues, et la plateforme couvre bien le paiement, les moyens de paiement et les commandes.
• Ton catalogue a encore des lacunes, comme des attributs manquants, des textes fournisseurs et des unités incohérentes. Séparer les systèmes répartirait ces lacunes à encore plus d'endroits.

Beaucoup de marchands du second groupe tirent quand même profit d'une étape composable : sortir l'information produit de l'administration de la boutique pour la mettre dans un PIM qui alimente chaque canal. Cela apporte l'essentiel des bénéfices côté données sans reconstruire le paiement.

Les coûts récurrents qu'un business case composable a tendance à oublier

Les licences par composant sont faciles à lister. Ces coûts-là ne le sont pas, et ils durent aussi longtemps que le stack :

• Construction et maintenance des intégrations : chaque connexion entre composants est du code que quelqu'un doit écrire, tester et mettre à jour quand l'un des deux côtés change son API.
• Supervision multi-éditeurs : quand une commande échoue, tu dois la suivre à travers la vitrine, le paiement, les moyens de paiement et la gestion des commandes, chacun avec ses propres logs.
• Changements de version d'API : les éditeurs abandonnent des versions d'API selon leur calendrier, pas le tien.
• Correspondance des données : chaque composant a son propre modèle pour les produits, les prix et les clients, et quelqu'un maintient la correspondance entre eux.
• Gestion des éditeurs : plus de contrats, plus de renouvellements, plus d'audits de sécurité.
• Compétences : le composable exige des personnes qui comprennent le système dans son ensemble, pas un seul outil. Shopify note qu'avec plusieurs éditeurs, les coûts de maintenance et de mise à jour peuvent vite s'accumuler.

Le PIM, la capacité produit que tous les autres composants lisent

Dans un stack composable, l'information produit est une capacité à part entière. La vitrine, la recherche, les marketplaces, les feeds, le portail B2B et le CMS la lisent tous. Cela relève le niveau d'exigence pour le PIM :

• Un modèle de données clair : familles de produits, attributs typés avec unités, variantes et relations, pour que chaque consommateur lise la même structure.
• Une validation avant publication : règles de complétude et de format par canal, pour que la recherche et les feeds n'indexent pas de produits à moitié finis.
• Des API et des événements : une API pour la lecture et l'écriture, et des événements de modification ou des webhooks pour que les index de recherche et les caches de la vitrine se mettent à jour quand un produit change. Notre fiche architecture orientée événements explique ce modèle.
• Des sorties par canal : le même produit avec un titre court pour une marketplace, une description longue pour la boutique en ligne et un autre nom d'attribut pour un feed.
• La localisation : textes traduits et valeurs d'attributs localisées pour chaque marché.
• Des identifiants stables : SKU et GTIN uniques, puisque tous les autres systèmes font leurs jointures dessus.

Un PIM conçu pour ce rôle est souvent appelé PIM headless : il a une interface d'édition pour l'équipe contenu, mais ses données sont consommées par API au lieu d'être affichées dans sa propre vitrine.

Mettre en place cette capacité est généralement la première étape d'une feuille de route composable, pas la dernière, car chaque composant ultérieur en dépend. Notre plan de mise en œuvre PIM couvre ce projet pas à pas.

Avancer vers le composable une capacité à la fois

Un changement de plateforme d'un seul coup vers un stack entièrement composable est la voie la plus risquée. Un parcours par phases fonctionne mieux pour les équipes du mid-market :

Cinq façons dont les projets composables deviennent un monolithe distribué

1. Des composants qui partagent une base de données. Si la recherche et le paiement lisent les mêmes tables, tu ne peux pas modifier ou remplacer l'un sans casser l'autre.
2. De longues chaînes d'appels synchrones. Quand la fiche produit attend la recherche, qui attend les prix, qui attendent le stock, un seul service lent fait tomber toute la page.
3. Deux systèmes qui modifient le même champ. Des titres produit modifiés à la fois dans le PIM et dans l'administration e-commerce divergent en quelques semaines.
4. Du code de liaison sans propriétaire. Les intégrations écrites pour le lancement et jamais confiées à une équipe cassent au premier changement d'API.
5. Acheter des composants avant de définir la propriété des données. Sans système de référence par champ, chaque nouvel outil ajoute une copie de plus du catalogue.

Brancher WISEPIM sur un stack e-commerce hybride

WISEPIM couvre la capacité d'information produit. Il importe ton catalogue, remplit par AI les descriptions, attributs, traductions et catégories manquants, vérifie la complétude avec Quality Guard et pousse le résultat via la synchronisation des plateformes vers Shopify, WooCommerce, Magento 2, Lightspeed eCom, CCV Shop, Kaufland, Google Merchant Center et d'autres canaux connectés. Avec la synchronisation automatique (à activer), un produit enregistré atteint ces canaux environ 30 secondes plus tard ; les imports et exports planifiés passent par des automatisations avec un déclencheur horaire, quotidien, hebdomadaire ou mensuel. Les équipes qui utilisent déjà Akeneo peuvent le connecter comme source.

Si tu envisages un stack modulaire, commence par la capacité produit : importe ton catalogue avec l'offre gratuite (jusqu'à 100 produits) et vois de quels champs chaque autre composant aurait besoin avant de choisir le moindre éditeur.