Applications mobiles, réseaux sociaux, front B2B/B2C, marketplaces, vente en magasin : les points de contact entre les consommateurs et une marque se sont démultipliés ces dernières années.

A ce stade c’est quasiment un poncif mais il est important de le rappeler car toute la complexité d’un écosystème ecommerce part de là ! Le modèle de vente au détail “d'antan” avait deux points de contact principaux : le magasin physique et le catalogue en ligne. Dans de nombreux cas, le catalogue en ligne était traité comme un magasin de plus et alimenté avec des données qui lui sont propres. La brique logicielle qui supportait ce travail était logiquement monolithique.

Depuis, l'écosystème e-commerce a connu de nombreux bouleversements avec le passage d’un modèle autour de solutions “tout en un” monolithiques à un écosystème de solutions spécialisées pour gérer des problématiques complexes : prix, commandes, logistique, compte client, marketplace, B2B... A cela s’ajoute la migration vers le cloud.

Les architectures continuent de suivre cette tendance : décommissionnement de monolithes, passage vers des architectures hybrides... C’est ce que reflète le dernier rapport de la Forrester Wave, qui a changé ses critères d’évaluation pour accorder une importance très forte à des patterns granulaires et l’architecture en “microservices”.

Cette tendance à la granularité est souvent recoupée sous la bannière du “modern commerce”. 

Derrière ce terme sont souvent apposés les microservices, les architectures hybride, découplées ou MACH, ou encore le composable commerce, CDN application, jamstack… Pas aisé de s’y retrouver, ni de comprendre l'intérêt de chaque concept.  Par ailleurs, sont-il pertinents dans tous les cas ? C’est ce que nous allons voir ci-dessous.

Monolithe API-sé

Commençons par le début en revenant sur la notion de monolithe. Il s'agit généralement d'applications “tout-en-un” qui englobent plusieurs fonctionnalités étroitement couplées. Étant donné leur large scope fonctionnel, les outils monolithiques ont tendance à avoir d'énormes bases de code une base de données massive avec éventuellement un niveau de visualisation construit par-dessus. Dans ce cas, c’est ce qu’on appelle un monolithe API-sé.

Ce modèle d’architecture était dupliqué à façon au sein de toute l'entreprise. Toute application qui allait s'appuyer sur les données d’un monolithe devait soit faire partie intégrante du monolithe, soit avoir besoin de stocker une version dupliquée des données. C’est ainsi que les briques de traitement en “batch” type ETL (Extract,Transform et Load) sont devenues le ciment qui a maintenu ensemble toutes ces solutions.

Les bénéfices

• Solutions “tout en un” capables de proposer un large spectre de fonctionnalités.
• Vous bénéficiez de la roadmap éditeur qui est encore plus riche quand il s’agit de solutions open-source !

Les limites

• Ne cible pas un besoin métier spécifique
• Code qui tend à devenir extensif qui ce qui pose problème au niveau de la maintenabilité

Headless

Le headless (appelé parfois “architecture découplée”) est apparu dans la mouvance d’API-sation des monolithes. Le principe est simple : exposer des flux d’information à de multiples points de contact avec des utilisateurs. C’est ce qu’on appelle le headless, ou aussi les architectures découplées. L’objectif : à partir d’une brique de gestion de contenu unique qui vient centraliser l’information, orchestrer la diffusion sur des interfaces web, mobiles, vocales, conversationnelles (chat, messenger…) et sur le lieu de vente. L’expérience montre que le headless permet une amélioration significative de la performance commerciale avec une augmentation du taux de conversion sur tous les canaux. Cependant, comme vu précédemment, attention de veiller à ce que l’API permettant de faire communiquer back et front soit suffisamment évolutive et véloce pour répondre aux besoins de performance.

Les bénéfices

• Indispensable pour gérer l’omnicanalité
• Meilleurs temps de réponse et meilleure performance

Les limites

• L’API doit être taillée avec précision pour éviter les problématiques “d’overfetching” ou “d’underfetching” (pousser trop d’info ou pas suffisamment !)
• Limites sur la prévisualisation du contenu au sein de certaines solutions

Composable commerce

Le commerce composable est une approche d’architecture qui consiste à sélectionner les meilleurs composants du briques du marché - généralement en SaaS - et à les combiner ou les "composer" en un ensemble répondant à des besoins business spécifiques. On parle aussi parfois d’approche “hybride” ou “best of breed”.

PIM, contenus, OMS, moteur de vente, moteur de recherche… chaque jour sortent de nouvelles solutions répondant à des besoins métiers de plus en plus précis. La “glue” nécessaire pour l’assemblage de ces briques devient alors un élément critique d’une architecture.

Les bénéfices

• L’état de l’art du marché !
• Des solutions spécialisées avec parfois une spécialisation sur votre verticale métier

Les limites

• Plus complexes à intégrer que des monolithes
• Veiller à intégrer des référentiels de données clairs pour s’assurer de la cohérence et de la donnée (prix dans un référentiel de prix, informations produit dans un PIM…)

MACH

Mach correspond à l’acronyme suivant :

• Microservices : code bénéficiant de sa propre base de données et sa propre API ciblant une fonctionnalité précise. Les microservices sont développés, déployés et gérés de manière indépendante car faiblement couplés au reste du SI.
• API first : la solution est nativement pensée pour exposer de l’information via une API.
• Cloud-native : la solution doit exploiter les avantages du cloud, au-delà du “simple” 'hébergement, pour intégrer notamment les notions d’élasticité et de scalabilité.
• Headless : vu précédemment.

Le concept de MACH est poussé par l’association américaine MACH Alliance qui estampille les solutions et les prestataires répondant à ces quatre critères. Il y a important roster de solutions à choisir mais avec trop peu de solutions open-source à notre goût !

Les bénéfices

• Des solutions performantes et ouvertes
• Cible des besoins spécifiques

Les limites

• Coûts de licence élevés avec un TCO (total cost of ownership) à bien évaluer
• Orchestration des flux à bien anticiper
• Peu de solutions open-source

Microservices

Revenons sur la notion de microservices ; il est possible de développer sur mesure l’ensemble ou une partie de votre stack e-commerce sur ce pattern d’architecture !

Les bénéfices

• Architecture totalement modulaire, chaque service est autonome
• Demain, c’est la possibilité de remplacer un module par un autre sans devoir changer de plateforme
• Cible des besoins très précis sans avoir à s’occuper du code de “tuyauterie” (dépendances…)
• Lorsque les microservices sont couplés à une plateforme cloud (containers, serverless…), vous bénéficiez d’une scalabilité et d’une robustesse sans pareils !

Les limites

• Le volume de code sera réduit au minimum et la complexité de la plateforme sera réduite… au prix d’un investissement initial plus important.
• Orchestration des flux à bien anticiper