Architecture MACH : principes fondamentaux et étapes à suivre pour la mettre en place sur son projet

L'architecture MACH (Microservices, API-first, Cloud-native, Headless) est en train de révolutionner la manière dont les entreprises développent et déploient leurs applications web. Cette approche moderne permet de créer des systèmes plus flexibles, évolutifs et performants.

Dans cet article, Marie vous apporte ses retours d’expérience et conseils sur l’Architecture MACH. De la définition des principes fondamentaux jusqu'aux étapes à suivre pour la mettre en place, elle vous livre tous ses conseils technologiques et méthodologiques. Suivez le guide !

Concrètement, que signifie Architecture MACH ?

Globalement, MACH est un acronyme de la combinaison de 4 principes de développement d’architectures : Microservices, API First, Cloud-Native et Headless. Tout simplement.

Pour rentrer plus dans le détail :

Microservices

API First

Cloud-Native

Headless

C’est un ensemble de petits services indépendants qui peuvent être développés, testés et déployés indépendamment les uns des autres. Généralement, un microservice correspond à un domaine métier d’une application. C’est le développement d’une interface logicielle qui permet de connecter un logiciel ou service à un autre service. On met en place une API pour échanger des données ou profiter des fonctionnalités que propose ce service. Cela est lié à un besoin de réponse en temps réel. Dans ce cas, c'est très courant de faire communiquer les microservices via des API. C’est une approche logicielle qui permet de créer, déployer et gérer ses applications sur un environnement Cloud. Cela veut tout simplement dire déployer ses applications vers un fournisseur plutôt que de gérer soi-même son infrastructure. Mais c’est de toute façon ce qui se fait de plus en plus, même en dehors du principe de MACH. Cette approche consiste à dissocier le frontend du backend afin de complètement séparer le cycle de vie logiciel et  les responsabilités. Cela implique d’avoir des roadmaps dédiés pour chaque partie. L’avantage est d’avoir deux parties qui évoluent et vivent séparément sans impacter l’autre. Par exemple, changer de technologie sur du backend n’impactera pas le frontend.

Exemple d'une schéma d'architecture MACH


Représentation schématique d'une architecture MACH

“Ces solutions permettent d’offrir aux entreprises de meilleures capacités d’agilité et d’être à l’épreuve du temps. Grâce à ce type d'architecture, les évolutions sont facilitées et plus rapides. Cela permet d’être concurrentiel et d’être à l’affût du marché et de ses changements.“

Quels sont les avantages d’adopter une architecture MACH (Microservices, API First, Cloud-native et Headless) ?

Concrètement, l’avantage de ce type d’architecture, c’est l’avantage de chacune des briques qui la compose. C’est ça qui est intéressant.

  • Microservices : avoir des briques fonctionnelles séparées

    Le fait d’avoir des briques fonctionnelles séparées qui existent, permet de les faire évoluer indépendamment les unes des autres. En termes de maintenance, de mise à jour, c’est beaucoup plus fluide.

    On peut avoir des équipes dédiées avec une connaissance métier sur un microservice plutôt qu’un autre ou encore pouvoir scaler un service qui est très demandé par rapport aux autres. Cela permet d’avoir de la granularité dans la gestion des services et de rendre le code plus maintenable et facilement testable.

  • API First : avoir des interfaces logicielles qui communiquent

    Les avantages des API c’est d’avoir des interfaces logicielles sur lesquelles on a communiqué. Aujourd’hui, on parle majoritairement d’API REST qui impose (normalement) d’avoir une structure. Cela implique un certain nombre de standards à respecter. Comme par exemple, les codes de réponse HTTP : une personne qui consomme votre API s'attend à ce qu’une réponse 200 soit une réponse "ok". Qu'une réponse 201 soit une réponse suite à une création d’entité etc.

    API REST respecte les codes et les verbes HTTP. L'utilisateur sait à quoi s’attendre et c’est aujourd’hui un standard de communication dans nos applications web.

  • Cloud-Native : avoir une infrastructure facilement scalable

    Grâce au cloud, on se décharge de la maintenance de son infrastructure. Le fournisseur se charge de mettre à jour le serveur physique, les composants, la sécurité, la scalabilité… en fonction de la formule choisie.

    Il existe aussi aujourd’hui une grande communauté qui est disponible pour accompagner dans le choix du bon hébergeur.

    Le prix peut aussi être un avantage. On peut avoir des infrastructures qui s’adaptent à la charge de travail.

    Après, les avantages supplémentaires vont dépendre du besoin et du type d’hébergement choisi.

  • Headless : pouvoir dissocier le frontend du backend pour faire évoluer les briques indépendamment

    Avoir son backend dissocié de son frontend permet d’être plus agile et de pouvoir faire évoluer ses briques indépendamment. On a ainsi un cycle de vie dédié par partie. 

Quelles étapes suivre pour mettre en place une architecture MACH sur son projet digital ?

  • Comprendre le besoin

    Avant de plonger dans le développement, il est crucial de bien comprendre ce que représente MACH et comment il s'adapte à vos besoins. Analysez vos exigences, objectifs commerciaux et contraintes techniques. Définissez des objectifs clairs et des KPI pour mesurer le succès de votre projet.

  • Choisir les technologies et outils adaptés

    Sélectionnez les technologies et outils adaptés à chaque pilier de MACH :

    • Microservices : Choisissez des frameworks comme Node.js pour développer des microservices autonomes.
    • API-first : Utilisez des outils comme API Rest pour concevoir, documenter et tester vos API.
    • Cloud-native : Optez pour des plateformes cloud comme AWS, Azure ou Google Cloud Platform, et utilisez Docker et Kubernetes pour la gestion des conteneurs.
    • Headless : Sélectionnez un CMS headless tel que Hygraph, Strapi ou Webflow pour gérer votre contenu indépendamment de la présentation.
  • Concevoir l'architecture

    Dessinez une architecture détaillant les interactions entre les microservices via les API. Utilisez des Messages Brokers RabbitMQ ou des API REST pour assurer la communication entre les microservices. Assurez-vous que chaque service est autonome et peut évoluer indépendamment.

  • Développer les microservices

    Développez vos microservices en suivant les principes de découplage et de modularité. Chaque service doit avoir son propre cycle de vie, bases de données et déploiements. Utilisez des pipelines CI/CD pour automatiser les tests et les déploiements. Testez rigoureusement l'intégration des services via des API pour garantir leur interopérabilité.

  • Déployer sur le Cloud

    Déployez vos microservices sur une plateforme cloud. Utilisez des conteneurs pour une portabilité maximale et Kubernetes pour orchestrer les déploiements. Configurez la surveillance et la gestion des logs avec des outils comme Prometheus, Grafana et ELK Stack.

  • Mettre en place l'architecture Headless

    Intégrez un CMS headless pour la gestion de contenu. Connectez-le à vos microservices via les API, permettant une distribution du contenu sur plusieurs canaux (web, mobile, IoT) sans dépendance à une structure front-end spécifique.

  • Surveiller et optimiser votre architecture en continu

    Surveillez constamment les performances de vos microservices et des API une fois en production. Utilisez des outils d'observabilité pour détecter et résoudre rapidement les problèmes. Optimisez les services en fonction des feedbacks et des données de performance.

  • Former vos équipes et documenter

    Formez votre équipe sur les principes et les outils MACH. Assurez une documentation exhaustive pour faciliter la maintenance et les futures évolutions.

Ce principe d’architecture existe depuis longtemps ?

Effectivement ça existe depuis plusieurs dizaines d’années déjà. C’est très courant dans les projets digitaux de nos jours. C’est une architecture qui s’applique à divers domaines. 

 

Pourquoi l'architecture MACH est-elle associée au e-commerce principalement ?

Honnêtement, je n’ai pas la réponse à cette question. De nos jours, c’est finalement une architecture qui est de plus en plus standard et qui n’est pas du tout restreinte au domaine de l’e-commerce, au contraire. Elle peut correspondre aux besoins de plusieurs domaines.

Par exemple : 
  • Si on a besoin d’avoir des microservices car on a beaucoup de fonctionnalités différentes et qu’on veut les splitter
  • Si on veut créer des briques par scopes fonctionnels séparés pour avoir une meilleure maintenabilité
  • Si on souhaite avoir un scope défini de fonctionnalités et plus de séparation dans nos différentes briques
Et bien on va retrouver les principes de MACH. Les applications vont communiquer entre elles via une API ou un Message Broker. Celles-ci vont ensuite être déployées dans la solution Cloud choisie. Puis pour plus d’agilité, on aura un frontend dissocié du backend donc on retrouve le principe Headless.

Finalement, c’est un principe d'architectures standards qui correspond à beaucoup de besoins. Evidemment, elle correspond au besoin d'une plateforme e-commerce mais elle n’est pas réservée uniquement à ce domaine.

 

Pourquoi est-elle très performante et doit être adoptée dans le secteur du e-commerce ?

Le secteur du e-commerce évolue très rapidement. L’architecture MACH répond parfaitement à ce besoin grâce à son principe agile et évolutif.

Une plateforme e-commerce possède de nombreux canaux de vente différents : le site web, l'application mobile, la tablette dans le magasin, le magasin physique, les items à la caisse… 

Pour pouvoir faire évoluer leurs canaux de distribution rapidement, ces entreprises ont potentiellement besoin d’avoir plusieurs app avec divers front qui vont pointer sur le même back.

Elles peuvent ainsi les développer et les faire évoluer différemment et à leur rythme sans impacter l’une ou l’autre.
Il y a également les pays de distribution. Les entreprises du e-commerce peuvent avoir besoin d’avoir un logiciel de vente différent par pays ou par zone géographique.

“MACH leur permet de répondre à leurs besoins de découpage et d’évolutivité rapide.“

Envie d’aller plus loin dans la conception d’applications ?

Retrouvez tous nos REX et conseils dans notre guide sur les bonnes pratiques de la conception agile d’applications web

Téléchargez notre livre blanc

Faut-il privilégier l'architecture MACH dans ses projets ?

Notre équipe Studio bosse majoritairement sur des gros projets donc effectivement c’est ce qu’on privilégie.

Pour te donner un exemple, sur un projet pour l’un de nos clients, on avait une cinquantaine de microservices. Donc ça commence à en faire pas mal. Ceux-ci communiquaient entre eux, soit via des API REST, soit via un Message Broker. Parce que parfois il y avait des traitements asynchrones donc un Message Broker, comme RabbitMQ, était la meilleure solution pour ce besoin.

Tout était déployé sur le Cloud, notamment GCP et AWS. Rien n'était hébergé chez nous au Studio. Et évidemment, on avait des fronts Headless. 5 applications front différentes associées à des “back for front” en GraphQL. C’est typiquement le type d’architecture qu’on met en place pour répondre aux besoins de nos clients. Souvent liés à des besoins d’agilité, d’évolutivité ou de données en temps réel. Ces briques sont les solutions principales.

Selon tes retours d’expérience, l'architecture MACH est-elle adaptée à tous les projets ?

Non, pas forcément. Je dirais qu’elle est à conseiller sur des moyens et gros projets. Et encore, cela va dépendre du besoin stratégique qui se cache derrière le besoin technique.

Pour te donner un exemple. Aujourd’hui, je bosse sur un projet pour un client pour lequel on est 3 développeurs. Donc plutôt un petit projet. Et pourtant, on a mis en place MACH.

Tout simplement parce qu’on a 2 scopes techniques sur la partie backend, donc on a 2 services qui le font. Nous n’avons pas un seul monolithe qui gère toute la partie back parce que ça avait plus de sens de séparer les 2. D’un point de vue de séparation, de besoin et de logique métier, il était nécessaire d’avoir 2 composants séparés.

“Donc il n’y a pas de cas de figure précis, cela dépend réellement du besoin. Ce n’est pas une question de taille d'application, d’équipe ou de projet mais plutôt une question de séparation, de scope, de fonctionnalités et de besoin.“

Quand faut-il se poser la question de passer à une Architecture MACH ?

Si historiquement vous avez un monolithe qui a énormément grossi et que vous avez une application beaucoup trop importante que vous n’arrivez plus à maintenir : il est temps de se poser la question de migrer votre architecture. Vos développeurs se marchent sur les pieds en faisant du code. L’équipe est trop grande et génère des conflits lors des pull request. Ce sont clairement des signaux d’alertes.

Il faut donc se poser la question : Est-ce que j’ai des scopes fonctionnels à découper ?
Si oui et bien j’ai donc des briques différentes qui peuvent être exploitées dans plusieurs services. Cela permettra de découper les équipes par scope, de travailler séparément, de mieux s’organiser et d’être plus productif. 

Il y a aussi la question de la scalabilité qui peut entrer en compte dans l’équation. Parfois, certaines de vos briques fonctionnelles ont besoin d’être plus disponibles que d’autres car elles sont majoritairement sollicitées. Imaginons 2 briques, la brique pour passer des commandes et la brique de gestion des utilisateurs. La brique pour passer des commandes est beaucoup plus sollicitée et donc doit être beaucoup plus disponible. Il faut par exemple 5 instances de serveurs qui gèrent les commandes et uniquement 2 instances qui permettent la gestion des utilisateurs.

Grâce à la séparation par scopes fonctionnels de l’architecture MACH, il est facilement possible de scaler vos services selon vos besoins.

Architecture MACH et Architecture Composable, si différentes que ça ?

L’architecture composable c’est le fait d’utiliser différentes briques qui existent dans notre architecture pour en faire une app dédiée à un besoin spécifique

Prenons l’exemple d’un site de vente en ligne qui possède de nombreux services. Ils décident de lancer une application mobile car ils se rendent compte que beaucoup de leurs clients potentiels commandent majoritairement sur leur mobile.

Grâce à l’architecture composable, ils vont pouvoir récupérer les briques disponibles et correspondantes à leur besoin pour mettre en place leur application. C’est comme prendre les ingrédients nécessaires pour faire une recette et laisser ceux dont on a pas besoin au frigo.

“Si on part de ce principe, pour moi l’architecture MACH est une architecture composable. Puisqu'il s'agit de mettre en place des briques fonctionnelles, qui correspondent à un besoin et qui communiquent via des API. C’est exactement le même principe.“

Conclusion : réussir sa migration vers une architecture MACH performante

La première chose à faire lorsque l’on souhaite passer à une architecture MACH c’est de dessiner le diagramme d’architecture et bien définir les scopes de chacun des microservices. Je pense personnellement que c’est le plus compliqué à faire. Bien découper ses microservices.

La façon de communiquer entre eux via des API, Messages Broker ou autre, c’est plutôt standard. Ça demande généralement moins de réflexion stratégique.

Puis pour le déploiement dans le Cloud, le mieux c’est de se faire accompagner par quelqu’un qui maîtrise le sujet. Potentiellement avoir un collaborateur DevOps dans son équipe ou avoir des personnes à l'aise avec le sujet. Si vous n’avez personne qui a ces connaissances, c’est important de s'entourer des personnes qui pourraient vous aider.

La réussite de ce projet c’est d’y aller étape par étape. D’être sûr de ce que l’on veut d’un point de vue technique. Et de choisir les technologies adaptées au besoin. Puis évidemment, de s’entourer de collaborateurs compétents et en maîtrise du sujet.



Marie, Consultante Tech Lead et Architecte de Solutions chez Eleven Labs
Marie Minasyan
Architecte
@Eleven Labs

Marie est architecte de solutions et lead tech.
Elle est passionnée par le web, domaine dans lequel elle travaille depuis 15 ans.

Envie d’être accompagné dans la mise en place d’une architecture MACH ?

Organisons un échange !

Demander un rendez-vous

Découvrez d’autres articles autour de l’architecture site web