Une architecture de micro-frontends divise une application web en segments développés et déployés de manière indépendante, chacun étant pris en charge de bout en bout par une seule équipe. Au lieu d'une base de code unique où chaque équipe fait la queue pour apporter des modifications, on obtient plusieurs bases de code que chaque équipe déploie via son propre pipeline. Le frontend cesse ainsi d'être le goulot d'étranglement derrière un backend en microservices.
C'est là toute la promesse. Mais cela a un prix. Vous gagnez en indépendance de déploiement, en liberté de choix technologique par segment et en réduction de la taille des bundles ; en contrepartie, vous devez maintenir une plateforme commune, veiller à l'application d'un design system entre les équipes et gérer des coûts de coordination que seules quelques équipes peuvent absorber. En dessous de trois ou quatre équipes autonomes, la surcharge opérationnelle coûte généralement plus cher que le monolithe qu'elle remplace.
La question est-elle donc de savoir si les micro-frontends fonctionnent ? Non. La question est de savoir si votre organisation a atteint le stade où ils deviennent rentables. Cet article explique ce qu'est un micro-frontend, comment cette architecture s'articule avec les microservices, les avantages et les inconvénients réels en termes de livraison, les coûts de fonctionnement de la plateforme, ainsi qu'un test de préparation en trois étapes que vous pouvez appliquer à votre propre environnement avant de vous lancer.
Un micro-frontend est composé de plusieurs petits composants modulaires et autonomes. Ces modules sont indépendants et peuvent être réutilisés sur d'autres pages. Vous pouvez écrire ces composants dans n'importe quel langage de programmation : JavaScript et ses frameworks sont les choix les plus courants, mais tout ce qui peut être compilé et packagé dans un bundle JavaScript peut être importé et intégré par le reste du frontend.
Imaginez un centre commercial. Un seul toit, une entrée unique, un parking commun, une signalétique partagée, et derrière chaque vitrine, une équipe différente qui aménage son propre espace selon son propre calendrier. Les clients font l'expérience d'un lieu unique, tandis que chaque boutique est gérée par ceux qui maîtrisent le mieux leur métier.
Dans une architecture micro-frontend, c'est exactement le même principe. Vous divisez l'application monolithique en fragments plus petits que vous codez, testez et déployez séparément, permettant ainsi à des équipes pluridisciplinaires de développer chaque composant, de la base de données à l'interface utilisateur, de manière indépendante. Ce qui permet de masquer les jointures, c'est le shell et le système de design partagé : le shell assemble chaque fragment sur une page unique avec une navigation et une session communes, tandis que le système de design garantit l'uniformité des composants et du style.
Ce modèle a été nommé et répertorié sur micro-frontends.org, et l'équipe de Martin Fowler a publié l'article de référence sur le modèle des micro-frontends, incluant les styles d'intégration que nous détaillons plus bas.
Voici quelques entreprises bien connues qui utilisent les micro-frontends :
Considérez cette liste comme la preuve que le modèle est évolutif, et non comme une raison de l'adopter. Chaque entreprise citée gère des dizaines d'équipes frontend. C'est la condition à laquelle cette architecture répond.
L'objectif d'une architecture micro-frontend est d'apporter au front-end les avantages des microservices, sans les inconvénients liés à un monolithe front-end massif.
Pour comprendre pourquoi cela fonctionne, il faut être précis sur deux points : ce que les microservices ont réellement changé côté serveur, et ce qui est resté obstinément inchangé côté client. Nous avons vu ces deux aspects se reconstruire Intégration front-end et back-end d'Eurofound, où un back-end modulaire devait toujours s'adapter à un front-end unique.
L'architecture microservices est un modèle de conception utilisé dans le développement back-end. Là où une architecture monolithique est livrée en un seul bloc, les microservices sont constitués de plusieurs composants déployables indépendamment, séparés par domaines métier et connectés via des API.
Ce que cela apporte concrètement à une entreprise est plus limité que ce que suggère la liste habituelle d'adjectifs, et mérite d'être énoncé clairement :
Ces quatre points sont précisément les propriétés dont un monolithe front-end est dépourvu, aussi moderne soit le back-end qui le soutient. Notre guide sur l' architecture logicielle détaille les compromis à faire selon la taille des équipes.
Un monolithe frontend est la partie client d'une application web construite à partir d'une base de code unique. De nombreux produits en utilisent encore un, y compris ceux dont le backend est entièrement décomposé. Le côté serveur est modulaire, mais le frontend reste un bloc monolithique.
Pour une ou deux équipes, c'est la structure idéale. À vrai dire, c'est généralement la structure idéale bien plus longtemps qu'on ne le pense. Les symptômes apparaissent à mesure que le nombre d'équipes travaillant sur cette base de code augmente, et ils sont suffisamment spécifiques pour être identifiés :
En d'autres termes, un monolithe frontend restreint l'indépendance de livraison que vous recherchiez en adoptant les microservices. C'est précisément ce fossé que comblent les micro-frontends. Et il faut être franc sur la nature de ce fossé : il est organisationnel. Si le délai provient de la culture de revue de code ou d'un comité de changement plutôt que de la base de code elle-même, diviser le code ne résoudra rien.
Le déploiement indépendant n'est utile que si le processus de livraison qui le sous-tend est rigoureux, ce qui est là où les meilleures pratiques agiles trouvent toute leur utilité.
Grâce aux micro-interfaces, les entreprises peuvent :
Cette approche est idéale pour les équipes qui gèrent déjà des déploiements indépendants sur le back-end. Les avantages sont réels, mais chacun d'entre eux implique un coût, détaillé dans la section suivante.
Les listes d'avantages publiées pour cette architecture sont longues. Dans la pratique, elles se résument à quatre gains majeurs, chacun reposant sur un mécanisme précis et une condition nécessaire.
Ces coûts correspondent aux quatre mêmes propriétés, vues sous un autre angle. Aucune ne justifie de rejeter cette architecture. Mais chacune nécessite un responsable avant même de commencer.
Ces deux architectures répondent à des problématiques différentes. Voici un aperçu des compromis à prendre en compte : ne cherchez pas à savoir laquelle est la « meilleure », mais plutôt « à quelle contrainte êtes-vous réellement confronté ? ».
| Dimension | Frontend monolithique | Micro-frontend |
|---|---|---|
| Base de code | Un dépôt partagé que tout le monde modifie | Plusieurs modules indépendants |
| Déploiement | Un pipeline / train de déploiement partagé | Pipeline par module, déploiement à la demande |
| Taille de l'équipe adaptée | Une ou deux équipes | Trois, quatre équipes autonomes ou plus |
| Rythme des livraisons | Freiné par la modification la plus lente du lot | Chaque module est déployé dès qu'il est prêt |
| Rayon d'impact (Blast radius) | Une régression peut faire tomber l'ensemble du frontend | Limité à un seul module |
| Technologie | Framework et versions partagés ; une mise à niveau est un projet à l'échelle du produit entier | Choix par module ; une mise à niveau est d'abord éprouvée sur un seul module |
| Taille du bundle | Un seul bundle, aucune duplication | Uniquement le code dont une page a besoin — mais risque de duplication des frameworks |
| Tests | Plus simple de bout en bout : une seule unité à tester | Les modules sont testés de manière isolée ; le produit assemblé nécessite sa propre suite de tests E2E |
| Coût de la plateforme sous-jacente | Aucun au-delà de l'application elle-même | Coque (Shell) + composition + design system + suite E2E (≈ un ingénieur plus un responsable du design system) |
| Idéal lorsque | Les conflits de déploiement ne constituent pas votre goulot d'étranglement | Plusieurs équipes autonomes font la queue pour déployer sur la même base de code |
L'argument commercial repose sur un arbitrage entre coût de coordination et vitesse de livraison, qui n'est pertinent qu'à partir d'une certaine échelle. Les chiffres ci-dessous sont indicatifs et non universels. La nature de cet arbitrage importe davantage que les chiffres eux-mêmes.
L'architecture micro-frontend présente de réels avantages, mais ce n'est pas une solution universelle. Toutes les applications web ne s'y prêtent pas, et les facteurs déterminants sont autant organisationnels que techniques.
Avant d'adopter les micro-frontends, nous soumettons chaque projet à trois critères de validation. Si l'un d'eux échoue, le monolithe reste la meilleure option, et le critère en question devient le point à travailler en priorité.
Deux conditions de soutien sont également importantes. L'utilisation de piles technologiques distinctes pour différents modules doit être une exigence réelle plutôt qu'une simple préférence, et le budget doit pouvoir couvrir les coûts de plateforme permanents mentionnés précédemment.
Si vous n'êtes pas certain que les micro-frontends conviennent à votre projet, passez en revue ces trois étapes avec une personne ayant déjà mené une telle migration. En fin de compte, tout dépend des spécificités de votre plan d'affaires, et non des mérites théoriques de l'architecture.
Découper le frontend est la partie la plus simple. La cohérence du résultat dépend de quatre domaines dont aucun segment n'a la responsabilité exclusive, et chacun nécessite une décision avant la première migration plutôt qu'après.
Les composants utilitaires qui gèrent l'état ou interagissent avec l'environnement applicatif, plutôt que d'effectuer un rendu visuel, peuvent être chargés à la demande comme n'importe quel autre segment. Comme ils ne possèdent généralement pas d'interface utilisateur, il est facile de les oublier au moment de définir les responsabilités de chacun.
Vous pouvez intégrer des micro-interfaces de deux manières : au moment de la compilation ou au moment de l'exécution.
Le conteneur installe chaque segment comme une bibliothèque, tout comme vous installeriez un paquet depuis npm, le registre de paquets Node.js. C'est ainsi que la plupart du code est écrit aujourd'hui, et c'est la solution la plus simple qui fonctionne.
Les inconvénients expliquent pourquoi la plupart des équipes finissent par abandonner cette approche. Plusieurs versions de bibliothèques partagées doivent être maintenues synchronisées, ce qui entraîne des problèmes de compilation en cas de décalage. Combiner plusieurs technologies est difficile. Le paquet final contient toutes les dépendances, ce qui le rend volumineux. De plus, comme toute modification d'une dépendance nécessite de reconstruire et de redéployer le conteneur, celui-ci et tous ses segments restent étroitement couplés. C'est précisément ce couplage que cette architecture cherche à éliminer.
L'intégration à l'exécution compose la page à partir de segments déployés indépendamment au moment où elle est servie, ou après son chargement, permettant ainsi de publier un segment sans reconstruire le conteneur. Il existe trois types de composition :
@module-federation/nextjs-mf n'a jamais pris en charge que l'ancien Pages Router, jamais l'App Router par défaut, et ses mainteneurs ont annoncé sa fin de vie vers fin 2026. Pour les projets utilisant l'App Router, le paquet propriétaire de Vercel @vercel/microfrontends — basé sur un modèle Multi-Zones plutôt que sur l'assemblage de chunks à l'exécution — est désormais la solution recommandée. single-spa demeure l'alternative principale lorsque les segments sont développés avec des frameworks différents.Un micro-frontend est une partie de l'interface utilisateur d'une application web, conçue et déployée de manière autonome par l'équipe qui en est responsable. Au lieu d'une base de code frontend unique modifiée par tout le monde, la page est assemblée à partir de plusieurs segments indépendants, soit lors de la compilation, soit directement dans le navigateur. Chaque équipe peut ainsi effectuer ses déploiements sans attendre les autres.
Optez pour le monolithe, sauf si les conflits de déploiement constituent votre véritable goulot d'étranglement. Une base de code frontend unique est plus simple à construire, à tester et à appréhender, et reste la solution idéale pour une ou deux équipes. Les micro-frontends deviennent rentables lorsque plusieurs équipes autonomes font la queue pour déployer sur la même base de code, et que c'est cette file d'attente, et non le code lui-même, qui ralentit votre progression.
Au-delà des équipes elles-mêmes, prévoyez un budget pour les coûts de plateforme : le shell, la couche de composition, un design system partagé et une suite de tests de bout en bout. D'après nos observations, cela représente environ la capacité continue d'un ingénieur, plus un responsable du design system, et ce coût persiste après le lancement. L'économie réalisée se mesure en temps de cycle, et non en réduction d'effectifs.
Le seuil se situe généralement à trois ou quatre équipes frontend autonomes, l'autonomie étant plus déterminante que le nombre. Si chaque mise en production doit encore passer par un responsable unique ou un comité de validation, diviser le frontend ne fera que supprimer un goulot d'étranglement qui n'était pas la véritable contrainte. Une équipe isolée qui adopte les micro-frontends en supportera les coûts opérationnels sans en retirer aucun bénéfice organisationnel.
Trois erreurs reviennent souvent. Embarquer une copie du framework avec chaque segment, ce qui rend la page plus lente que le monolithe initial. Négliger la gouvernance du design system, entraînant une incohérence visuelle entre les segments. Et laisser les versions diverger entre des segments déployés indépendamment, ce qui ne se révèle qu'en production. Ces trois points relèvent davantage de la gouvernance que de la technique.
Cela dépend. Diviser l'application permet au navigateur de ne télécharger que le code nécessaire à la page, ce qui est un avantage. À l'inverse, la duplication des dépendances entre les segments peut alourdir la charge totale par rapport à l'original. Le résultat dépend de la gestion rigoureuse des dépendances partagées ; il est donc préférable de mesurer la vitesse de chargement à chaque version plutôt que de faire des suppositions.
Oui, et c'est l'approche la moins risquée. Installez un shell devant votre monolithe actuel, isolez une fonctionnalité verticale aux contours bien définis et confiez-en la responsabilité complète à une équipe. Répétez l'opération pour chaque segment suivant. Prévoyez une migration sur plusieurs trimestres plutôt que sur quelques sprints, et gardez toujours la possibilité d'interrompre le processus en cours de route.
Les micro-frontends apportent au frontend ce que les microservices ont apporté au backend : une livraison indépendante, en échangeant des coûts de coordination contre une vitesse de déploiement accrue. Ce compromis n'est rentable qu'à grande échelle : la plateforme entraîne des coûts fixes et les points de défaillance sont davantage organisationnels que techniques. Appliquez donc d'abord les trois filtres : nombre et autonomie des équipes, séparabilité des domaines et maturité des déploiements. Si l'un d'eux fait défaut, il est plus judicieux de le corriger en priorité, et le monolithe reste pour l'instant la meilleure solution.
Nous avons conçu, maintenu et migré aussi bien des micro-frontends que des monolithes, et nous serions ravis d'évaluer votre infrastructure au regard de ces trois filtres, même si la conclusion est de ne rien changer. Contactez-nous et nous étudierons votre situation.
Alexandra Mendes est spécialiste senior de la croissance chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction de textes sur le développement de logiciels, l'IA et la transformation numérique. Après avoir suivi un cours de développement frontend, Alexandra a acquis des compétences pratiques en matière de codage et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la façon dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
Votre développeur web de tous les jours qui aime se cacher dans le backend. Javascript et Ruby sont mes préférés. Je me débrouille toujours avec Docker et mes builds se cassent assez souvent.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
