Comprendre les Micro Frontends, même sans être développeur
Micro Frontends : Organiser son architecture par domaine client
Comprendre les Micro Frontends, même sans être développeur
TL;DR: Vous avez plusieurs types de clients (particuliers, pros, entreprises…) et vous hésitez entre une seule app lourde ou une app par profil ? Ni l'un ni l'autre. Avec les Micro Frontends, vous gardez une seule application qui s'adapte automatiquement à chaque utilisateur. Chaque profil est développé indépendamment, mais tout est réuni dans la même interface.
Le problème
Prenons l'exemple d'une néobanque.
Elle a plusieurs types de clients :
Les particuliers: qui veulent un compte courant, une carte, du virement instantané
Les professionnels: qui ont besoin de facturation, de gestion de paie, de plafonds élevés
Les premium: qui exigent un service dédié, des offres d'investissement, un suivi personnalisé
Les entreprises: qui demandent de la multi-signature, des API, du reporting
Tous ces clients se connectent sur la même application. Ils passent par la même page de connexion, le même tableau de bord, la même interface.
Sauf que leurs besoins sont complètement différents.
Résultat :
Une modification pour les Pros peut casser l'affichage des Particuliers
On doit déployer tout le monde en même temps, même si seul un segment est concerné
L'application devient lourde : chaque page charge des fonctionnalités inutiles pour 90% des utilisateurs
Les équipes se marchent sur les pieds
Le code devient un monstre difficile à maintenir
Pourquoi ? Parce qu'on a tout mis dans le même frontend et le même backend, comme si le client Particulier et le client Entreprise avaient les mêmes besoins.
La solution : Micro Frontends par profil client
L'approche classique serait de créer une application pour chaque profil :
Une app "Ma Banque Particuliers", une app "Ma Banque Pro", une app "Ma Banque Premium", une app "Ma Banque Entreprise".
Résultat : vos clients doivent télécharger, installer et apprendre plusieurs apps. Et si un utilisateur est à la fois Particulier ET Professionnel ? Il doit basculer entre deux apps, se reconnecter, perdre le contexte.
Avec les Micro Frontends, c'est différent.
Vous gardez une seule application. Mais à l'intérieur, chaque profil client est un module indépendant. L'utilisateur se connecte une fois, et l'app s'adapte automatiquement à son profil.
Un Particulier voit son tableau de bord personnel. Un Pro voit ses factures et sa gestion de paie. Un Premium voit son conseiller et ses investissements. Tout ça dans la même app, la même connexion, le même design.
Avant Une app par profil (la fausse bonne idée)
Un utilisateur doit télécharger, installer et naviguer entre plusieurs apps.
Après Une seule app qui s'adapte (Micro Frontends)
Un utilisateur se connecte une fois, l'app affiche uniquement ce qui le concerne.
Comment c'est possible ?
Imaginez un centre commercial. Chaque boutique (chaque profil) est indépendante, avec son propre stock, ses propres vendeurs, sa propre décoration. Mais le centre commercial (le Shell) fournit l'entrée, le parking, la sécurité et les espaces communs.
C'est exactement ça, les Micro Frontends.
Chaque profil client a :
Son propre frontend (React, Vue, Angular… au choix de l'équipe qui le développe)
Son propre backend
Sa propre base de données
Sa propre équipe
Son propre rythme de déploiement
Mais pour l'utilisateur, tout est dans la même application. Une seule connexion, une seule interface, une seule marque.
Résultat : si l'équipe "Professionnels" déploie une nouvelle fonctionnalité de facturation, les Particuliers ne voient rien. Si l'équipe "Premium" a un bug, les Entreprises continuent de fonctionner. Chaque profil est isolé des autres, mais tout le monde partage la même app.Comment ça marche ? (sans jargon)
Le Shell, c'est la coque
C'est l'application hôte. Elle ne fait rien de métier. Son rôle :
Connecter l'utilisateur (email + mot de passe)
Identifier son profil (particulier, pro, premium, entreprise)
Charger l'interface correspondante
Fournir le cadre commun (en-tête avec le logo, menu de navigation, thème visuel)
Le chargement
Chaque interface client est développée séparément, par des équipes différentes, avec des outils différents. Quand vous vous connectez, le Shell va chercher l'interface de votre profil et l'affiche.
Résultat : l'équipe "Particuliers" peut utiliser React, l'équipe "Pros" peut utiliser Vue, l'équipe "Premium" peut utiliser Angular. Tout fonctionne ensemble sans conflit.
Les règles
Les profils ne se parlent pas entre eux si le module Particuliers a besoin des données du module Entreprise, ça passe par l'API (un traducteur central)
Les événements globaux (déconnexion, changement de thème) sont gérés par le Shell
Chaque profil est indépendant un bug chez les Pros n'impacte pas les Particuliers
L'organisation des équipes (le vrai sujet)
La technique, ça se résout. L'humain, c'est plus complexe.
Avant L'organisation classique
Tout le monde touche à tous les profils. Personne ne maîtrise vraiment un métier.
Après Une équipe par profil client
Chaque équipe possède son profil client de bout en bout.
Chaque équipe est autonome. Elle possède son profil de bout en bout, du frontend à la base de données.
Exemple concret : l'équipe "Professionnels" peut décider de lancer une nouvelle fonctionnalité de devis en un clic. Elle la développe, la teste, la déploie. Les autres profils ne sont même pas au courant. Zéro impact. Zéro régression.
Le recrutement change : on ne cherche plus "un spécialiste React" ou "un spécialiste Java", mais quelqu'un qui comprend le métier de son profil client et qui est capable de livrer une fonctionnalité complète.
Ça sert à qui ?
Vous êtes… | Pourquoi ça vous concerne |
|---|---|
Dirigeant / CTO | Vous pouvez faire grandir vos équipes sans tout casser. Chaque profil client est isolé. |
Développeur | Vous travaillez sur un code plus propre, avec la techno de votre choix, et vous devenez expert d'un métier. |
Chef de projet | Vous livrez plus souvent, avec moins de risques. Un bug chez les Pros ne bloque pas les Particuliers. |
Client (Particulier, Pro, Premium, Entreprise) | Vous avez des fonctionnalités adaptées à vos vrais besoins, livrées plus vite. |
Les pièges à éviter
1. Trop découper Commencez avec 2 ou 3 profils maximum. Pas un micro frontend par fonctionnalité.
2. Oublier l'harmonie visuelle Si chaque équipe conçoit ses propres boutons et ses propres couleurs, l'application aura l'air d'un collage. Prévoyez une charte commune dès le début.
3. Négliger les temps de chargement Si chaque profil charge son propre framework, l'utilisateur télécharge tout en double. Il faut mutualiser ce qui peut l'être.
4. Penser que c'est seulement technique Le vrai défi, c'est l'organisation des équipes et la communication. La technique, il existe des solutions pour ça.
Comment se lancer ?
Identifier ses profils clients quels sont les vrais découpages métier ? Particuliers, Pros, Premium, Entreprises ?
Commencer petit un POC avec deux profils, le temps de valider l'approche
Mettre en place le Design System avant de développer les fonctionnalités
Former les équipes fullstack, autonomes, responsables d'un profil
Itérer on n'y arrive jamais du premier coup
Vous voulez voir le code ?
Cet article est la partie visible de l'iceberg. Si vous voulez voir l'implémentation complète avec les exemples concrets en React, Vue, Angular, Java et Node.js, la configuration Module Federation, l'API Gateway, les pipelines CI/CD et le Design System partagé
Contactez-moi.
Je vous montrerai l'architecture complète, adaptable à votre contexte (néobanque, SaaS, assurance, marketplace…).
