Gérer un site e-commerce avec (toujours) les meilleurs outils du marché 🤩
Pouvoir rapidement et simplement intégrer de nouvelles fonctionnalités à votre front office 🤩
Avoir la capacité de faire monter en charge rapidement et simplement votre front office 🤩
Tout cela de manière sécurisée 🤩
Si toutes ces promesses vous intéressent, vous devez vous intéresser au « Composable commerce ».
Comment les e-commercants en arrivent au composable commerce ?
De mon point de vue, le fait d’en arriver au composable commerce, est un cheminement tout à fait logique.
Pour reprendre ce cheminement je vais vous résumer l’article histoire des CMS e-commerce que j’ai écrit il y a quelque temps.
Au début de cette histoire, les CMS e-commerce monolithiques 🦖 étaient les rois (Hybris, ATG, Magento, OsCommerce, Prestashop…).
Mais au fur et à mesure que les e-commercants grandissaient, des besoins spécifiques naissaient.
Ils eurent, par exemple, :
- Besoin de travailler très spécifiquement sur leur catalogue, ceci donna naissance (chez les e-commercants) aux PIM.
- Besoin d’un outil pour gérer leur stock et leurs logistiques. Ils commencèrent alors à plus travailler avec les éditeurs de WMS, des OMS…
- Besoin d’outils pour optimiser leurs images, ceci donna naissance aux DAM.
Et ainsi de suite…
Nous sommes actuellement sur une sorte « d’entre-deux » où les e-commercants ont encore leurs CMS traditionnels mais ils ont également toute une série de logiciels connectés à celui-ci.
Progressivement ils enlèvent ces briques de leur système e-commerce monolithique et là nous en arrivons à du composable commerce.
Certains choisissent également de passer leur site vitrine en headless. Mais ça c’est un sujet important, restez jusqu’au bout, on va vite y revenir 😉
Exemple de système composable commerce
Afin d’être très concret, voici un schéma qui montre ce que pourrait donner un système composable commerce.
Vous l’avez peut être compris (avec ce schéma) les clés du succès de ce genre d’organisation technique sont :
- La plateforme d’API (située au centre dans le schéma).
- L’eco système (les outils qui gravitent autour du centre).
- Les briques techniques (les outils qui viennent en support des différentes connexions).
Restez jusqu’au bout on y reviendra 😉
Mais avant ça, j’aimerais vous parler d’un sujet qui amène souvent une confusion.
La grosse tendance du moment c’est le headless commerce et je croise beaucoup de personnes qui confondent headless commerce et composable commerce.
Quelle est la différence avec le headless commerce?
Le headless commerce est souvent perçu comme un prérequis au composable commerce.
Je pense que c’est un peu plus subtil que ça…
Donc si vous considérez que le meilleur outil pour gérer des commandes et des factures est un ERP et non un CMS e-commerce vous êtes libres de ne pas utiliser de CMS e-commerce.
Ce qui n’est pas le cas si, dans votre approche headless, vous incluez (de façon implicite) un CMS e-commerce…
En quoi cela peut être vu comme une étape ?
Le headless commerce peut être vu comme une étape vers du composable commerce car mener un projet de ce type, vous obligera à travailler en profondeur la gestion de vos API.
En faisant cela, vous aurez débuté une transformation de votre architecture monolithique vers une architecture en micro services.
Vous aurez également « mis à plat » les processus clés qui permettent ces communications.
Dans le jargon vous allez vous diriger vers une architecture MACH :
M pour Microservices
A pour API-First
C pour Cloud native
H pour Headless
C’est donc en effet une bonne méthodologie pour démarrer une stratégie composable car vous aurez déjà l’exhaustivité des API et des connexions en place.
Mais attention! Que ceci ne se retourne pas contre vous ! 😈
Si c’est une étape ça ne doit pas être une finalité.
Si votre objectif est de faire du composable commerce, ne vous arrêtez pas en route !
Je vois beaucoup de cas où les sociétés ont démarré des stratégies composables mais ne sont pas allées jusqu’au bout 😒
Bien souvent, ces sociétés ont (pour répondre à la stratégie initiale) dupliqué les données et les processus.
Elles se retrouvent par exemple avec un CMS e-commerce headless qui va gérer les commandes et la facturation et un ERP qui va faire la même chose augmentant ainsi :
- Les instabilités du système d’information.
- Les difficultés de gestion de la maintenance.
Tout en nivelant vers le bas les fonctionnalités liées aux commandes et factures😈
Bref, je vous conseille d’être vigilant et de systématiquement vous replonger sur votre schéma directeur afin de vous assurer qu’il est toujours le plus simple et le plus efficace possible.
Et n’hésitez pas à enlever des briques devenues inutiles ou qui ne font que générer des doublons de données.
Cependant, ce ne sera pas la bonne solution pour tout le monde, nous allons maintenant voir les avantages et inconvénients de cette solution.
Avantages et inconvénients du composable commerce
Les avantages
De mon point de vue, ce type d’approche à 4 gros avantages.
L’expérience utilisateur et collaborateur
En travaillant toujours avec les meilleurs outils du marché et en spécialisant des équipes sur le front office vous serez plus à même d’offrir la meilleure expérience pour vos utilisateurs.
L’agilité, la flexibilité et la mutualisation
Avec une plateforme d’API (ou un middleware) qui a la capacité de gérer la complexité, ceci vous permettra de pouvoir changer, modifier, intervertir des « briques » métiers, vous apportant ainsi une plus grande flexibilité.
C’est également un point important dans la mutualisation des processus de l’entreprise. Pas besoin par exemple de faire des processus métier spécifique pour l’e-commerce, ils peuvent être mutualisés avec les autres processus de la société…
La gestion de la scalabilité
Grâce au cloud, un fin découpage de vos processus métiers et un outil qui gérera la complexité.
Vous serez en mesure de beaucoup mieux anticiper et gérer la scalabilité de l’ensemble de votre environnement.
La sécurité
C’est un argument peu souvent mis en avant mais ce type d’architecture à l’avantage de :
1, Diversifier le risque.
2, N’ouvrir aucune base de données sur le web.
Passons maintenant au côté obscur de la force😈
Les inconvénients
Il y en a 2 principaux:
Le prix
Avoir autant d’outils vous augmentera mécaniquement le prix de l’ensemble.
Vous aurez un hébergement pour chacun de ces outils (oui même si c’est du Saas, la licence compensera forcément le coût de l’hébergement 😅).
Et vous devrez savoir gérer l’ensemble de ces flux dans un outil spécifique que vous hébergerez, pour lequel vous aurez de la maintenance…
La gestion de la complexité
Ca c’est une réelle difficulté, gérer autant d’outils interconnectés entre eux amène la nécessité de canaliser la complexité.
Si vous n’êtes pas en mesure d’avoir les équipes IT pour gérer cette complexité il n’est peut être pas raisonnable de vous diriger vers ce genre d’architecture.
Enfin, comment bien débuter une stratégie de composable commerce
Qui, même s’il parait simple, engage de nombreuses ressources…
Les annexes pour bien comprendre
Cet article fait suite à une série d’articles que j’ai rédigé sur des sujets connexes au composable commerce.
Pour aller encore plus loin sur ce sujet vous pouvez consulter :
0, Cet article sur l’architecture JAMSTACK
1, Cet article sur les différences entre des architectures techniques monolithiques et des architectures microservices.
2, Cet article sur les différences entre des systèmes best of breed et des systèmes monolithiques.
En lisant ces articles vous comprendrez mieux :
- Les architectures techniques qui permettent de mettre en place une stratégie de composable commerce.
- Les approches dites composables sur d’autres environnements fonctionnels tel que les ERP.
- L’intérêt du JAMSTACK et comment vous pouvez l’aborder
