A l’occasion du « Modern Commerce Day » qui s’est tenu le 16 juin 2021 pour la France, Clever Age vous partage sa compréhension et son analyse de ces « nouvelles architectures MACH ».
MACH, qu’est-ce que c’est ?
Terminologie et définitions
Depuis le début des années 2000, on trouve des architectures (Web, notamment) composées de solutions que l’on peut qualifier de « monolithes » : un ensemble applicatif structuré et cohérent, avec une partie « front-end », c’est-à-dire des interfaces visibles par les utilisateurs finaux, une partie « core », avec des fonctionnalités et un modèle de données, et une partie « back-office » pour configurer puis opérer la solution.
Cet ensemble structuré peut aussi bien être une solution e-commerce, une solution de gestion de contenu web (CMS), ou encore une application métier spécifique.
Ces applications étaient généralement hébergées « on premise », sur ses propres machines, chez un exploitant-hébergeur, et tarifées en fonction de la « puissance technologique » requise pour opérer l’application.
Les technologies ont beaucoup évolué ces 20 dernières années, et les architectures « MACH », en rupture avec ces anciennes architectures, en sont devenues petit à petit le reflet.
Voici la définition de ce qui se cache derrière ce nouvel acronyme, M.A.C.H. :
M = Micro-Services : architecture dans laquelle chaque composant, chaque « service », offre une fonction spécifique, techniquement et fonctionnellement bien délimitée, qui peut être conçue, développée, et déployée individuellement. On parle de composants, parfois de « briques Lego™ ».
A = API-First : architecture dans laquelle chaque solution, chaque composant, chaque service, va exposer ses propres API et consommer les API exposées par les autres composants (ou des services tiers / externes)
C = Cloud-native : architecture disponible dans un cloud, où les composants sont pensés nativement pour être déployés dans un cloud (public ou privé) et tenir compte des caractéristiques liées à ces infrastructures comme la scalabilité, l’isolation, la sécurité, la configuration
H = Headless : architecture dans laquelle la partie « visible » – le ou les « front-end » – est totalement découplée des services et applicatifs qui exposent services & données. Un eCommerce « headless », par exemple, ne va pas proposer un « front-end » ; cela va permettre d’utiliser un « front » créé complètement spécifiquement ou sur la base d’un framework front existant. Un CMS « headless », par exemple, va proposer les outils et fonctions de création de contenus, de gestion du cycle de vie des contenus, de la contribution… mais sans présager de quelles solutions, technologies, ou applications vont consommer ces contenus. Cette « mécanique » headless impose l’utilisation d’API pour que différentes applications (existantes ou développées, front-end ou back-end) puissent gérer des contenus et services, pour les unes, et l’affichage de ces contenus ou services, pour les autres. Les API forment un écosystème commun de services, permettant l’interopérabilité des solutions, et notamment ce découplage entre « front » et « back ».
Ambitions et valeur ajoutée
Les architectures MACH ont plusieurs ambitions, comme profiter de l’ensemble des évolutions apportées d’une part par le Cloud, et d’autre part par l’ensemble des outils et processus DevOps. Ainsi, la gestion du cycle de vie des développements et des déploiements est industrialisée, automatisée, et de meilleure qualité. Ces architectures permettent un déploiement immédiat ou récurrent, régulier, et apportent ainsi cette agilité dans la capacité à livrer aussi souvent que souhaité, une bonne intégration avec une méthodologie agile et ses livraisons régulières, et une flexibilité pour livrer – modifier – et re-livrer sans « effort » supplémentaire.
Le développement de micro-services a pour objectif de procéder à un découpage applicatif cohérent – qui peut même bénéficier d’une approche DDD – en délimitant chaque fonctionnalité (ou groupe cohérent de fonctionnalités) et en l’isolant dans un micro-service dédié. Ainsi, il sera possible de dédier des équipes à chaque micro-service, chaque équipe pouvant décider d’un outillage, de technologies, et d’un processus de développement adapté (et potentiellement différent d’autres équipes). Ces équipes travaillent facilement en parallèle, et livrent leurs services qui exposent les API permettant de les faire communiquer les unes avec les autres. L’approche par micro-services va permettre une excellente appropriation des fonctionnalités ainsi développées, et les API exposées seront pleinement maîtrisées – c’était l’un des soucis importants avec les monolithes et leurs listes d’API partielles, aux niveaux de granularité pas toujours bien pensés, et aux comportements parfois incertains. Enfin, l’approche micro-services a une autre importante vertu, celle de permettre une approche par « Composants », et surtout, une transformation « progressive » d’une architecture « ancienne » vers une architecture « moderne », en développant successivement des micro-services et en débranchant, progressivement, une fonctionnalité ou un service existant pour utiliser à la place un nouveau micro-service dédié. Cette approche d’architecture « composée » permet aussi de mixer des solutions « du marché », des monolithes installés, et de nouveaux composants en micro-services.
Le futur n’est pas fait que d’écrans. Ou en tout cas pas uniquement ceux que l’on connaît aujourd’hui : PC, tablettes, smartphones (dans le désordre). Les interfaces hommes-machines de demain incluent réalité virtuelle et réalité augmentée, écrans de TV connectées, écrans dans les voitures, et… absence d’écrans, notamment dans les « enceintes intelligentes » qui fleurissent dans nos maisons. Ces nouvelles architectures, notamment headless, promettent l’agilité et la flexibilité liées au développement de services et de fonctionnalités agnostiques de la façon dont ils seront consommés. Que je commande demain depuis ma voiture, ma TV, ou mon enceinte connectée, les services qui vont me proposer des produits, prendre ma commande, et me notifier de son évolution seront similaires, et développés une seule fois. Seule la partie « front-end » sera développée pour autant de « canaux / modes d’interaction » avec les utilisateurs que nécessaire. Ou sera même absente, dans les architectures développant l’IoT notamment, qui peuvent consommer des services ou mettre à jour des informations sans nécessaire brique de « visualisation » par un utilisateur.
Challenges et points de risques
Les architectures MACH font la part belle aux replatforming partiels ou totaux, avec des équipes de développeurs aux commandes, et une promesse d’agilité, de flexibilité, et de modernité aussi bien pour l’IT que pour les Métiers.
Cependant, ces architectures ont aussi des challenges et risques associés. Ces architectures sont complexes à concevoir, à mettre en œuvre ; elles requièrent une expertise pointue, tant dans les architectures à mettre en place par les architectes que par les équipes de développement, qui doivent maîtriser des concepts, des outils et des frameworks récents et sophistiqués.
Ces architectures vont souvent rassembler de nombreuses technologies et de multiples frameworks, tant pour le développement de micro-services que pour la gestion d’API ou encore la gestion du headless by design ou bien encore une variété de différents front-end. Une complexité de ces architectures est justement la sereine cohabitation de ces technologies multiples et la capacité à bien appréhender l’intégration et l’orchestration de la chaîne logicielle lors de la conception puis tout au long des développements successifs sur la plate-forme.
La partie headless est un sujet épineux du point de vue de la gouvernance : de nombreuses solutions vont suggérer de développer tout ce qui est spécifique du côté du « front », puisque l’on peut faire « ce que l’on veut » en front, il « suffira » d’appeler les bonnes API des services existants ou nouvellement créés. Deux problèmes surgissent alors : le risque de déporter des règles métier, voire toute une partie du fonctionnel, uniquement en front (dans un front) – on est dans ce cas à l’opposé de la philosophie d’un développement unique et agnostique du front-end. L’autre problème est la plus grande complexité du front-end qui doit gérer – en plus de la partie visible – la tuyauterie de gestion des appels des API des différents services.
De nombreuses architectures MACH vont inclure des « composants éditeurs », des frameworks open source, et des développements spécifiques. Une architecture « typique » e-commerce, par exemple, va inclure :
- une solution e-commerce MACH du marché, qui va apporter les fonctions « génériques » du e-commerce
- des composants (micro-services) e-commerce maison, dédiés à certaines fonctionnalités spécifiques au métier de l’entreprise
- une solution de type CMS headless, pour gérer des modèles de contenus, des types de pages, et des contenus éditoriaux
- une solution de « front-end » pour gérer un (ou plusieurs) fronts PWA et des développements spécifiques pour mettre en oeuvre des parcours clients originaux et différenciants sur la base de la solution retenue
- un service tiers (ou un composant) de « recherche » (produits et contenus éditoriaux)
Dans cet exemple, une grande complexité réside dans la « glue » entre tous ces services, composants, applications. API gateway et management, multiplicité des frameworks (voire même compatibilité entre différents frameworks), scalabilité horizontale et verticale, SEO, performances… sont autant de challenges de ce type d’architectures, et ne se résolvent pas simplement.
Tous ces applicatifs, solutions, composants, services sont, MACH oblige, dans le Cloud. Ou plutôt, chacun est dans son Cloud (du SaaS, du PaaS, du IaaS, du mono-tenant, du multi-tenants, du cloud public, du cloud privé, il y en a pour tous les goûts). Il y a là aussi un challenge d’orchestration multi-clouds (architecture, interopérabilité, performances, gouvernance) qui ne paraît pas évident à adresser.
Chaque solution (MACH ou non) vient par ailleurs avec son propre modèle de pricing. Le coût de cette multiplication de services est bien souvent complexe à estimer correctement, les paramètres de prix étant bien entendu distincts selon la nature de chaque service utilisé.
Enfin, et au-delà de l’architecture MACH, les référentiels « classiques » (MACH ou non) continuent à apporter une vraie valeur ajoutée – tout en complexifiant certainement l’architecture à mettre en oeuvre :
- un PIM pour gérer le référentiel Produits
- un DAM pour gérer le référentiel Médias
- un OMS pour gérer les référentiels stocks et commandes, et pour gérer l’orchestration de ces dernières
- une CDP pour gérer les données prospects et clients
Autant de solutions (« à l’ancienne » pour la plupart) que l’on devra accoster à notre nouvelle architecture MACH.
Conclusion et l’avis de Clever Age
Clever Age n’a pas attendu l’avènement de la mouvance MACH pour réaliser des projets aux caractéristiques proches ; plusieurs retailers dès 2013 ont ainsi, avec l’aide de Clever Age, pensé, mis en oeuvre, maintenu et fait évoluer des architectures e-commerce « composées », riches, headless, APIsées, et dans le Cloud – avec un découpage clair des services, des technologies distinctes entre front-end et core services, du search scalable externalisé, des API enrichies, un déploiement automatisé et récurrent dans une infrastructure cloud.
Clever Age promeut publiquement, depuis plus de 5 ans, un découpage applicatif entre les « front-end », les « business services » isolés en composants, et les référentiels de master data exposés en API temps réel, le tout pour offrir un cadre architectural permettant une réelle omnicanalité.
Les promesses vantées par les promoteurs du mouvement MACH, regroupés notamment au sein de la « MACH Alliance« , sont réelles, intéressantes, et porteuses de valeurs. Cependant, il est illusoire de penser que ces architectures sont aujourd’hui applicables à tout nouveau projet de « transformation numérique ». Elles requièrent une volonté et une capacité forte à développer du sur-mesure, des équipes de développements de grande taille, la mise en oeuvre d’une factory logicielle, l’intégration d’architectes experts, une gouvernance technique écoutée, une forte mobilisation vers l’agilité, et la prise en compte dans les budgets d’un coût initial et récurrent importants pour gérer la vie de ces nouvelles architectures en constante évolution.
Soucieux de son devoir de conseil pragmatique et indépendant, Clever Age – une fois n’est pas coutume – pourrait bien reprendre à son compte l’intervention de Forrester lors de l’événement « Modern Commerce Day 2021 » : « ces architectures représentent le futur, mais il faudra au moins 5 ans pour qu’elles deviennent matures ».
Dans le cadre de programmes ambitieux et d’une volonté indéfectible au plus haut niveau de proposer des services innovants, différenciants, performants, flexibles, et évolutifs rapidement, Clever Age recommandera ces architectures MACH prometteuses et justifiées et saura donner à ces projets toute l’expertise et la valeur qu’ils représentent.
Mais tous les projets de replatforming, notamment e-commerce, ne sauront bénéficier de ces nouvelles architectures, lorsqu’elles ne sont pas compatibles avec la taille des équipes, le niveau d’expertise logicielle, les ambitions du COMEX, ou plus prosaïquement les budgets des organisations dédiés à la « transformation numérique ».