Aujourd’hui, le marché du e-commerce se retrouve coincé entre innovation business et innovation technologique.
D’une part, le secteur hyper concurrentiel, oblige ses acteurs à innover pour rester compétitifs (commerce unifié, quick-commerce, économie circulaire, expérience immersive). D’autre part, les technologies évoluent très vite, obligeant ces mêmes acteurs à rester à jour pour bénéficier des avantages de ces technologies et rester attractifs dans le recrutement de talents.
Les principes Micro-service, API-First, Cloud-Native et Headless, se sont largement développés au cours des dernières années. Lorsque l’on allie ces principes ensemble, leurs avantages sont décuplés, garantissant une forte évolutivité, scalabilité et un rapide time-to-market, permettant ainsi aux acteurs de suivre les changements rapides et rester dans la partie.
Cette architecture, communément appelé “MACH”, est couramment utilisée pour construire des sites e-commerce. Elle permet de faire du “composable commerce”, c’est à dire construire son architecture comme si on assemblait des legos. On assemble des briques Saas prêtes à l’emploi ou des briques custom lorsque les besoins sont trop spécifiques. Il est alors facile de remplacer une brique si celle-ci est dépréciée ou si le besoin évolue, ce qui permet de bénéficier des dernières innovations sans devoir réécrire toute l’application.
Dans cet article, nous allons voir quels bénéfices tirer d’une architecture MACH et quelles sont les contraintes associées.
1er bénéfice : Faire évoluer sa plateforme plus rapidement grâce à une forte modularité
Ce sont notamment les promesses des micro-services par rapport à une architecture monolithique, en découpant, on découple les différents modules entre eux, et on peut rapidement en ajouter ou en faire évoluer sans impacter les autres. On peut également déployer un unique service sans avoir à redéployer toute son architecture, réduisant ainsi les cycles de mise en production.
Avoir ces briques entièrement utilisables par API permet de les rendre interchangeables, on peut ainsi facilement remplacer une brique en modifiant les contrats API.
Et on peut remplacer nos briques par des solutions Saas cloud en adoptant une stratégie “best-of-the-breed”, choisissant parmi les meilleures du marché dans leur domaines, au lieu de les ré-implémenter nous même. Utiliser des solutions clé en main réduit d’autant plus le time-to-market de nouvelles fonctionnalités pointues, on bénéficie automatiquement des mises à jour qu’elles proposent, tout en nous affranchissant de la maintenance de l’infrastructure de ces solutions.
Et tout cela peut se réaliser de manière transparente pour le frontend en étant headless. En séparant le frontend des services possédant la logique business, on les découple, et on peut ainsi remplacer ou faire évoluer nos services backend sans trop impacter le frontend, encore une fois en changeant uniquement les contrats APIs.
2ème bénéfice : Construire des expériences client pointues
De nos jours, les services e-commerce ne se consomment plus uniquement via un site web. On peut acheter des produits et services via des applications mobiles, des chats, en magasin, des stores sur les réseaux sociaux Facebook ou Instagram, et ainsi fournir une expérience omnicanal à ses client. Et ces nouvelles tendances se confirment avec par exemple une croissance de 45% lors des deux dernières années du e-commerce sur mobile.
Pour supporter ces multiples canaux de distributions et ces nouveaux business models, avoir une architecture headless et API-first est indispensable. Cela permet l’utilisation, et même la réutilisation, des différents services e-commerce sans avoir a ré-implementer leurs comportements. Par exemple, un même module de gestion de panier ou de recherche pourra être utilisé à la fois sur la version mobile ou la version web.
Les équipes de développement frontend peuvent alors se concentrer sur la construction d’une expérience utilisateur poussée. Construire une identité forte et des fonctionnalités immersives vont permettre aux plateformes de se démarquer.
Ces sites web bénéficient des avantages de technologies frontend récentes comme NextJS, alliant l’aspect dynamique d’une librairie Javascript comme ReactJS avec la performance et le référencement apporté par du rendu coté serveur.
3ème bénéfice : Apporter robustesse et scalabilité sur son architecture
Enfin, une architecture micro-service et cloud-native apporte résilience et scalabilité. En effet, avoir des micro-services va nous permettre de scaler à la demande uniquement les services qui on en le plus besoin.
Si un incident se déroule, on va pouvoir proposer une expérience dégradée sans que tout le site soit inaccessible. Par exemple, si le service de recommandations de produits e-commerce est en panne, cela n’empêchera pas l’utilisateur de réaliser ses achats.
Les cloud providers vont également augmenter cette robustesse et scalabilité, car on n’administre plus manuellement les serveurs et les applications mais on utilise des services managés. On peut même utiliser des technologies serverless afin d’avoir une scalabilité optimale.
Et si on utilise directement des Saas cloud ou des Paas (Vercel, Heroku), même la configuration d’infrastructure cloud n’est plus à faire, et on bénéficie automatiquement de la scalabilité et des SLAs fournies par ces services. Par exemple Shopify a fourni un uptime de 99.99% sur tous ces services lors des 90 derniers jours au moment de la rédaction de cet article.
1ere contrainte : Complexité technique
En contrepartie, mettre en place une architecture MACH est loin d’être trivial, ces architectures ajoutent de la complexité technique par rapport à des architecture plus classiques. Il est important de respecter un bon découpage pour éviter de se retrouver avec “l’enfer des dépendances”, c’est à dire devoir modifier trop de nombreux services a chaque fois que l’on souhaite ajouter une nouvelle fonctionnalité, ralentissant ainsi le time-to-market.
D’un autre coté, il conviendra de ne pas créer de couplage fort entre les services, ce qui empêcherait d’obtenir la modularité promise par cette architecture.
Les APIs développées doivent également être de qualité et performantes. La dette technique sur une API pouvant rapidement impacter tous les autres services qui en dépendent. Une bonne maitrise des montées de version d’API est également requise afin de permettre leurs évolutions sans casser leurs utilisations.
Les données se retrouvent distribuées entre les services et il faut veiller à bien sécuriser leurs accès.
2ème contrainte : Complexité organisationnelle
La complexité des systèmes se retrouve également au niveau organisationnel. Les différents domaines fonctionnels pouvant être répartis sur plusieurs équipes, cela demande ainsi une bonne synchronisation pour déployer des fonctionnalités lorsque plusieurs domaines sont impactés. Avoir des fronts headless encourage également cette séparation, on se retrouve alors avec des équipes expertes sur le frontend tandis que d’autres seront spécialisés sur les services backend. Il est important de mettre en place une gouvernance projet efficace et d’aligner les équipes sur des objectifs communs.
L’architecture technique étant plus complexe, il est alors nécessaire d’avoir des profils techniques plus qualifiés, qui comprennent les enjeux d’une telle architecture et arrivent à en faire une implémentation de qualité. Ce qui rend ainsi le recrutement plus difficile.
3ème contrainte : La résolution d’incident est plus complexe
La complexité ajoutée sur l’architecture technique se retrouve également sur la détection et correction d’erreur. D’autant plus si on n’a pas la main sur les services en erreur, ceux-ci sont comme des boites noires et il est plus difficile de les débugger.
Afin de lutter contre cela, il est important de mettre en place un monitoring applicatif efficace et pertinent. Ce monitoring sera construit a l’aide d’outils modernes comme Datadog ou Sentry, permettant de faire du Distributed Tracing. Et il faudra loguer dans nos systèmes les réponses des services sur lesquels on n’a pas la main.
Conclusion
Au cours de cet article, nous avons vu qu’une architecture MACH, apportant scalabilité et modularité, apporte également des contraintes techniques et organisationnelles. Afin de limiter l’impact de ces contraintes et réussir la mise en place d’une architecture MACH, il est important de respecter des bonnes pratiques. Un deuxième article détaillant ces bonnes pratiques est en cours de rédaction. Suivez Theodo sur Twitter ou Linkedin pour être informé lors de sa publication.
