Découvrez le "Composable Commerce" avec Jean-Charles Bordes de SMILE : comment ça marche, qui est concerné et ses implications, expliqués comme une recette de cuisine.
Le 6 juin prochain, participez à notre Matinale Composable commerce avec Casino & Caudalie !
Le “Composable quoi ?”
"Jeudi soir dernier, j'ai retrouvé deux amis de longue date dans notre restaurant habituel. L’un est Directeur IT Digital et l’autre Directrice e-commerce. Durant le dîner, l’un d’eux me dit : “ça tombe bien que tu sois là ce soir, mon boss m’a demandé de lui expliquer le "Composable Commerce"… Tu m’expliques en 3 min ?”.
C'est vrai que la plupart des articles sur le sujet sont soit inintelligibles par le commun des mortels du e-commerce soit remplis de promesses sans expliquer le pourquoi du comment. Je lui partage mes clés pour expliquer l’approche simplement. Mais avant tout, il faut comprendre le cheminement qui nous emmène au Composable Commerce !
“C’est une histoire de cuisine”
Nous sommes dans un restaurant, quoi de mieux que de prendre l’analogie de la cuisine ? Pour beaucoup de nos clients, je trouve que maîtriser l'e-commerce c’est comme pratiquer la cuisine.
Au début, on suit une recette scrupuleusement, ligne après ligne sur le type et la quantité des ingrédients à utiliser, la cuisson à réaliser, le plat dans lequel il faut servir… La création finale ressemble comme deux gouttes d’eau à la recette du livre, mais finalement aussi comme deux gouttes d’eau à celle de n’importe quel autre cuisinier qui aurait suivi la même recette.
Le e-commerce c’est pareil. Au départ, nous étions tous guidés par les bonnes pratiques d’une plateforme, c’est ce qu’on appelle le “one-fit-all-model platform” et l’approche “architectures monolithiques”. Elles devaient (sur le papier) embarquer 80 % des besoins du e-commerce. Par exemple, le catalogue produit ou l’orchestration des commandes étaient gérés, bon an mal an, dans la solution e-commerce de base. Au fil des projets, on sentait bien chez SMILE que ça commençait à poser quelques difficultés en termes de volumétrie ou de cohérence avec les autres canaux de vente qui se multipliaient.
En cuisine, au fil du temps, plus on teste, plus le jeu se complexifie ! On ne prépare plus pour 2 personnes mais pour 10. Et vos convives deviennent exigeants : il faut se réinventer et apporter de la singularité dans ses plats.
“Concrètement, pour le e-commerce ça veut dire quoi ?”
Depuis quelques années, nos clients sortent des architectures monolithiques qui les limitaient pour construire une expérience unique et différente de leurs concurrents. Ils ont pu offrir une plus grande qualité dans l’expérience client, augmenter leurs taux de conversion, un meilleur scoring de performance, etc.
En effet, la compétition plus forte, des points de contacts multiples et des clients plus exigeants les ont poussés à acquérir de nouveaux outils très performants sur un domaine particulier. C’est l'avènement il y a quelques années des solutions PIM, OMS, CDP, Search, etc. A ce moment-là, on parlait de "best-of-breed".
Puis, compétition oblige, c’est le premier grand saut... nos clients utilisent les nouvelles possibilités technologiques pour être plus performant sur leur stratégie omnicanale. Le changement peut être progressif ! C'est ce qu'on appelle des architectures "hybrides", qui visent à séparer le "backend" du "frontend", ou "headless" pour les intimes. A ce stade, on conserve le back (la solution e-commerce) et de plus en plus de composants communiquent directement avec le front de la solution qui n’est plus utilisé, par l’intermédiaire d’une plateforme API et s’affranchissent du moteur transactionnel. Par exemple, vous faites passer la donnée produit par un outil de Search comme Gally qui expose le contenu personnalisé au front sans l’intermédiaire de la solution e-commerce.
L’avantage, c’est une décomposition de l’écosystème qui permet une plus grande indépendance vis-à-vis de la plateforme e-commerce. Les services sont plus facilement interchangeables, le "vendor lock-in" (cette dépendance qui peut exister entre un acheteur et un vendeur) est limité et nos clients gagnent en performance et cela sans remettre en question, l’application encore la plus sensible pour eux, le moteur e-commerce.
C’est le cas de LVMH, Cultura, Weldom, Snowleader ou Kaporal par exemple qui sont passés d’un eCommerce monolithe à une architecture plus flexible et découplée.
“Et le Composable Commerce alors ?”
C’est comme être finaliste de Top Chef ! Il intègre les bénéfices du best-of-breed et il va plus loin que le headless.
D’une part, la solution e-commerce est restreinte à un moteur transactionnel et n’est plus le composant principal, voire il n’y a plus de solution e-commerce du tout pour certains de nos clients. Chaque composant est très ouvert pour communiquer avec le reste de l’écosystème. Ces composants sont “cloud native”, c’est à dire pensés pour exploiter au maximum les capacités de scalabilité (encore appelées “élasticité”) d’un cloud, la montée de version est gérée et ils offrent une très forte performance. C’est ce qu’on appelle parfois l’architecture MACH.
Cela offre un maximum d’agilité technologique ET business. Nous pouvons interfacer ou désinstaller les services plus rapidement et plus simplement que s’ils passaient par une architecture monolithique ou hybride. La recherche du gain de performance et d’expérience supplémentaire est toujours viable mais il faut quand même bien le mesurer.
Enfin, quand un SI possède déjà un fort legacy, l’intérêt de se pencher sur les architectures Composable ou Microservices est de pouvoir s’intégrer sans trop perturber l’IT. On intègre seulement LE composant manquant (par exemple : le moteur transactionnel). Chez Renault, nous avons construit une plateforme digitale et e-commerce qui adresse l’ensemble des pays pour les 5 marques du groupe (offres, produits, services, etc.). Ce n’est pas une solution du marché mais une architecture microservices qui s’appuie sur de nombreux référentiels et services internes.
C’est également une bonne opportunité d’insérer le développement dans le cloud de composants spécifiques liés à un contexte et des besoins métier particuliers. C’est très agile, adapté à leurs besoins spécifiques et à un SI difficile à faire bouger.
“Alors, concrètement, quels sont les avantages du Composable Commerce ?”
Le Composable Commerce est devenu le sujet qu’il faut connaître et étudier pour son business digital et omnicanal. Alors si vous ne devez retenir que les principaux avantages pour les expliquer à votre boss et à vos équipes, je partage ici mon top 5 :
- Une expérience unique et différenciante : pas de compromis, vous choisissez les composants/services/technologies du marché qui sont les plus adéquates pour vos clients, votre business et vos contraintes internes ou externes.
- Facilement intégrable au SI : l’architecture Composable est une librairie d’API par définition très ouverte pour échanger les données et les fonctionnalités qu’elles portent aux autres composants et au front.
- Plus d’agilité : c’est lié aux avantages des deux premiers points. Ce type d’architectures permet d’intégrer de nouveaux services bien plus facilement qu’un monolithe et limiter les effets de bords sur l’écosystème eCommerce et le SI. Cela permet de tester et s’adapter rapidement.
- La performance : ils sont cloud native c’est à dire scalable par nature et de surcroît le front client n’affiche que les composants nécessaires. Tout cela permet un site, en théorie, plus rapide. En théorie parce que c’est aussi une affaire d’intégration et les architectures “non composable” démontrent également de belles performances parfois bien suffisantes.
- L’omnicanal : l’objectif est de bénéficier de l’intelligence des composants (le catalogue produit et la recommandation merchandising par exemple) sur l’ensemble des points de contacts client et non sur seulement sur une interface web.
Le bonus : rarement noté par les entreprises de la tech, c’est une belle opportunité pour offrir un design et une UX sans être restreint par le template d’une solution monolithique et sans complexifier la partie front du projet. Utilisé aussi pour le headless, nous utilisons pour cela les opportunités du développement javascript.
“On est tous obligé de faire du Composable ?”
Évidemment, tout le monde ne doit pas faire le choix du Composable Commerce. C’est même parfois une erreur. Il faut savoir identifier les bénéfices pour l’organisation au-delà des grands messages du marché. Ce n’est parfois pas adapté au contexte interne, aux attentes métiers ni même au budget à allouer. Vous l’avez compris, l’une des plus grandes limites du Composable Commerce c’est la capacité à financer tout cet écosystème d’éditeurs. C’est comme en cuisine, vous n’avez peut-être pas besoin de vous acheter une cuisinière 5 feux, 3 fours et un grill qui sera totalement hors budget et dont vous n’exploiterez pas vraiment toute la valeur ! Peut-être aussi, que c’est encore mieux pour vous en utilisant seulement un couteau et une poêle.
Une autre limite est très certainement son coût global. Plus il y a de composants, plus il y a d’éditeurs, plus il y a de licences… le ROI doit se mesurer. Il y a les composants mais aussi leur intégration, la gestion des flux et les développements nécessaires en front.
On peut aussi noter le manque de customisation possible. Il faut souvent acheter les composants tel quel avec “seulement” de la configuration. La flexibilité de l’architecture existe mais il y a une limite au composant lui-même. Il est rarement possible de développer une fonctionnalité en plus pour vous spécialement, hormis quelques éditeurs du marché dont certains avec qui nous travaillons. C'est pourquoi certains de nos clients développement certains microservices critiques eux-mêmes au lieu de passer par un éditeur.
Un dernier point mais pas des moindres. Le Composable Commerce ne fait pas, à lui seul, la réussite de votre expérience client et la performance business. L’exploitation et la valorisation de vos données sont aussi essentielles. Les bons outils ne font pas forcément les bons artisans.
Pour aller plus loin, je vous invite à lire l’article de Guillaume Lanthier “DXC Vs. DXP : comprendre les différences d’architectures pour une expérience utilisateur unifiée”. Si vous souhaitez en savoir plus sur les avantages et limites des différentes approches, vous préparer à les expliquer à votre boss ou pousser l’analyse en intégrant d’autres enjeux autour du digital, de l’UX et de la data, contactez-nous !"
