Pourquoi vos micro-frontends sont peut-être pires que votre monolithe
Dans un monde technologique où la décomposition est devenue synonyme de progrès, les micro-frontends se sont imposés comme l'architecture à adopter pour les applications web modernes. Pourtant, derrière cette promesse de liberté et d'agilité se cache une réalité plus complexe. Cet article est le fruit de mes recherches, de discussions avec mon réseau, et de nombreux retours terrain. Il ne s'agit pas d'une vérité gravée dans le marbre, mais d'un partage d'expérience — vécu, parfois grinçant, souvent instructif.
Là où ça a marché : les cas d’usage solides
Contentsquare : un cas d’école… très particulier
Lors de ma veille, je suis tombé sur une conférence de Gregory Houllier, Staff Engineer chez Contentsquare. Leur cas est parlant : plusieurs acquisitions, des produits à unifier, des stacks disparates — bref, un joyeux bazar à domestiquer. Là, l’architecture micro-frontend avait tout son sens.
- Shell en Svelte ultra-léger
- Design system en Web Components (Stencil) pour supporter Vue, React, Angular
-
Fédération des dépendances via
import maps(cartes de correspondance qui permettent de partager des bibliothèques entre micro-frontends sans les recharger plusieurs fois) - Déploiements modulaires par équipe, orchestrés via CDN et extension Chrome maison
"Une SPA monolithique bien faite peut parfaitement suffire. L’architecture micro-frontend n’est pas adaptée à tous les usages." — Gregory Houllier
IKEA : moduler à l’échelle mondiale
IKEA a adopté une architecture micro-frontend pour gérer la complexité de sa plateforme e-commerce internationale. Chaque pays ou marché peut adapter l’interface, tout en conservant une base technique unifiée. Des dizaines d’équipes collaborent en parallèle, avec une vraie indépendance sans sacrifier la cohérence.
HelloFresh : la modularité pour suivre l’appétit
HelloFresh, en pleine croissance et expansion géographique, a misé sur des micro-frontends pour permettre à ses équipes de livrer plus vite, plus souvent, et plus proprement. Chaque fonctionnalité devient un microservice frontal autonome, intégré dans un orchestrateur commun. L’architecture est alignée avec leur stratégie produit agile.
Là où ça coince : les retours terrain moins glorieux
Dans mes échanges avec des devs, sur Reddit, Hacker News, Slack, ou tout simplement en off lors de conférences, le ton est souvent plus sceptique. Beaucoup de projets ont implémenté les micro-frontends... et l'ont regretté.
Segment
Trop de micro
Segment a documenté son retour en arrière dans leur article "Goodbye Microservices". Le constat est sans appel : complexité opérationnelle, duplication des efforts, coûts de maintenance explosifs. Leur retour au monolithe a ramené clarté et vélocité.
Shopify
Le choix du monolithe
Shopify a fait le choix fort de ne pas céder à la hype. Leur monolithe frontend, bien structuré, bien maintenu, leur permet de livrer vite, sans se perdre dans l’orchestration. Leur stratégie : solidité plutôt que sophistication.
Medium
Un pas de côté
Chez Medium, une tentative d’architecture distribuée a rapidement mis en lumière des problèmes de performance, de cohérence UX et de gouvernance. Ils ont préféré revenir à une approche centralisée.
Les vrais coûts, ceux qu’on ne voit pas dans les slides
Parfois, ce n’est pas la tech qui plombe un projet, c’est tout ce qu’elle implique autour.
L’onboarding devient un casse-tête. Un nouveau développeur met plus de temps à comprendre l’archi qu’à coder.
Shells, import maps, runtime loader, plugin Vite custom… ça en fait du code pour faire tourner du code.
Un ticket transverse ? Bon courage pour faire bosser trois équipes, synchroniser les releases et corriger sans casser le reste.
Ajoutez à ça les joyeusetés du Shadow DOM (une encapsulation native du DOM et des styles dans les composants web, qui empêche les styles globaux d’y pénétrer — et parfois même les outils d’analytics d’y accéder) et vous obtenez une belle potion instable.
Et si le problème n'était pas l’architecture, mais nos fantasmes ?
Dans mes discussions avec des CTO et architectes, une question revient souvent :
“Pourquoi fait-on ça ? Parce que ça résout un vrai problème, ou parce que ça fait moderne ?”
Soyons honnêtes : beaucoup de décisions sont influencées par l’effet de mode, la volonté d’attirer des talents avec une stack "sexy", ou la promesse d’une scalabilité illimitée… rarement par des vrais problèmes de delivery.
Or, dans beaucoup de cas, un monolithe frontend bien pensé coche déjà les cases :
Prenez Shopify : leur monolithe frontend n’a rien de ringard. Il est maîtrisé, testé, et il livre de la valeur. Point barre.
