Micro-frontends

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, pas assez de service

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é. Et ce qui valait pour leur backend valait aussi pour le frontend.

Shopify : le choix assumé du monolithe propre

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é après les douleurs de la décomposition

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, avec modularité interne et contrôle renforcé sur l’expérience utilisateur.

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.

• Coût cognitif : l’onboarding devient un casse-tête. Un nouveau développeur met plus de temps à comprendre l’archi qu’à coder.

• Coût infra : shells (conteneur principal qui orchestre les modules), import maps , runtime loader, plugin Vite custom… ça en fait du code pour faire tourner du code.

• Coût humain : 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 :

• Modularité interne avec lazy loading

• Design system réutilisable

• Feature toggles pour livrer progressivement

• Mono-repo avec gouvernance claire

Prenez Shopify : leur monolithe frontend n’a rien de ringard. Il est maîtrisé, testé, et il livre de la valeur. Point barre.