Le retour du monolithe modulaire

Microservices était la religion de 2015. En 2026, les entreprises reviennent au monolithe — mais modulaire. Pourquoi ?

Le bilan des microservices

Dix ans après le livre de Sam Newman "Building Microservices", le bilan est mitigé. Les microservices ont résolu certains problèmes — déploiement indépendant, scalabilité sélective, équipes autonomes. Mais ils en ont créé d'autres :

• Complexité opérationnelle — 50 services au lieu d'une application. 50 pipelines CI/CD. 50 déploiements à coordonner.
• Latence réseau — Chaque appel entre services ajoute de la latence. Un parcours utilisateur qui faisait 1 appel de fonction en monolithe fait 10 appels réseau en microservices.
• Débugging — Un bug qui traverse 5 services nécessite du distributed tracing. En monolithe, c'est un breakpoint.
• Cohérence des données — Pas de transactions distribuées. Saga pattern, eventual consistency, compensation. Complexité énorme.

Les entreprises qui reviennent

Shopify a gardé son monolithe et a scalé à des milliards de transactions. GitHub est un monolithe. Basecamp est un monolithe. Ces entreprises prouvent qu'un monolithe bien architecturé peut scaler.

À l'inverse, Amazon Prime Video a récemment consolidé des microservices en un monolithe et a réduit les coûts de 90%. Segfault, Segment, et d'autres ont fait de même.

Le monolithe modulaire

Le monolithe modulaire n'est pas le monolithe spaghetti de 2010. C'est un monolithe avec des modules stricts :

• Chaque module a une interface claire.
• Les modules ne peuvent pas accéder aux internals des autres.
• Les dépendances entre modules sont explicites.
• Un module peut être extrait en service si nécessaire.

C'est le meilleur des deux mondes : la simplicité opérationnelle du monolithe, avec la séparation des préoccupations des microservices.

Quand extraire un module en service ?

Tous les modules n'ont pas besoin d'être des services. Extrayez un module en service si :

• Il a un pattern de scalabilité différent (ex : traitement vidéo qui nécessite beaucoup de CPU).
• Il a une équipe dédiée qui veut déployer indépendamment.
• Il a des exigences de disponibilité différentes.

Dans 90% des cas, ces conditions ne sont pas remplies. Gardez le module dans le monolithe.

La bonne nouvelle pour les développeurs

Le monolithe modulaire est une bonne nouvelle pour les développeurs. Fini les appels réseau pour chaque opération. Fini le debugging distribué. Fini les problèmes de cohérence des données. Un seul déploiement. Un seul pipeline. Une seule base de code.

Les microservices ne sont pas morts. Ils ont leur place — pour les très grandes équipes, les très grandes échelles. Mais pour 95% des entreprises, le monolithe modulaire est le bon choix. Et 2026 est l'année où cette vérité est enfin acceptée.