Le retour discret du monolithe : pourquoi les équipes d'ingénierie les plus performantes font marche arrière sur leurs migrations microservices

La décision d'architecture dont personne ne veut publiquement se repentir

Il existe une forme de regret en ingénierie qui ne se retrouve jamais dans les conférences. Ce n'est pas la panne en production ni le déploiement raté — ceux-là sont des histoires de guerre, portées comme des médailles. Le regret dont je parle est structurel. C'est la prise de conscience progressive, qui survient généralement quelque part entre votre 40e alerte PagerDuty pour des timeouts inter-services et votre troisième tentative de débogage d'une trace distribuée couvrant onze services, que vous avez peut-être construit le mauvais système depuis le début.

Les microservices sont devenus la religion architecturale dominante des années 2010 pour des raisons compréhensibles. Netflix le faisait. Amazon l'imposait. Le circuit des conférences le célébrait. Et ainsi, des milliers d'équipes d'ingénierie — beaucoup d'entre elles composées de 8 ingénieurs, avec un financement Serie A et un produit qui n'avait pas encore trouvé sa forme définitive — ont décomposé leurs systèmes en flottes distribuées de petits services, héritant de toute la complexité opérationnelle que Netflix avait construit des équipes entières d'ingénierie de plateforme pour gérer.

Le retour en arrière est aujourd'hui discret, mais indéniable. Linear fait tourner l'une des expériences produit les plus rapides du SaaS sur un backend rigoureusement structuré. Supabase a toujours été transparent sur le plan architectural en privilégiant la simplicité modulaire à la complexité distribuée. Shopify a parlé franchement du coût de la sur-décomposition. La leçon n'est pas que les microservices sont mauvais. La leçon est bien plus précise — et bien plus utile.

La taxe cachée des microservices : ce que les conférences ont omis

Quand on évangélise les microservices, les bénéfices sont mis en avant : déployabilité indépendante, isolation des pannes, flexibilité technologique, autonomie des équipes. Ce qui est rarement quantifié, c'est la surface opérationnelle que vous héritez dès l'instant où vous franchissez une frontière de processus.

Voici concrètement à quoi ressemble cette taxe :

La surcharge du traçage distribué

Dès que le chemin d'une requête traverse plus de deux ou trois frontières de services, l'observabilité devient un problème d'ingénierie à part entière. Des outils comme Jaeger, Honeycomb et Datadog APM sont véritablement excellents — et ils requièrent un investissement significatif pour être instrumentés, maintenus et interprétés. Pour les équipes sans fonction d'ingénierie de plateforme dédiée, le traçage est souvent implémenté de façon incohérente ou pas du tout, ce qui signifie que le débogage des incidents en production se réduit à de l'archéologie de logs à travers plusieurs services aux timestamps désalignés.

La complexité de l'authentification inter-services

L'authentification service à service semble simple jusqu'au moment où vous gérez des certificats mTLS, faites tourner des clés de signature JWT à travers une douzaine de services, ou déboguez pourquoi votre API gateway interne abandonne silencieusement des requêtes. Chaque frontière de service introduit une surface d'authentification. Pour la plupart des équipes produit, il s'agit d'une complexité sans valeur ajoutée — elle ne rend pas votre produit meilleur, elle maintient simplement les lumières allumées.

La coordination des déploiements

La déployabilité indépendante est la promesse canonique des microservices. En pratique, les déploiements coordonnés sont courants parce que les schémas de base de données partagés, les contrats d'événements partagés et les versions d'API partagées créent un couplage invisible entre les services. Les équipes se retrouvent fréquemment avec des règles informelles d'ordonnancement des déploiements, des matrices de compatibilité de versions et des environnements d'intégration perpétuellement cassés.

L'accumulation de latence

Les appels réseau ne sont pas gratuits. Une chaîne de requêtes synchrones à travers cinq microservices — même sur un réseau interne à faible latence — accumule des dizaines de millisecondes avant qu'une seule ligne de logique métier ne s'exécute. Pour les applications où la performance perçue par l'utilisateur est un différenciateur produit, cette arithmétique compte énormément.

La mise en perspective honnête : Les microservices n'éliminent pas la complexité. Ils échangent une classe de complexité (une grande base de code) contre une autre (un système distribué). La seconde est opérationnellement plus difficile et nécessite une infrastructure plus spécialisée pour être gérée en toute sécurité.

Le monolithe modulaire : ce que c'est, ce que ce n'est pas, et pourquoi ça passe à l'échelle

Le monolithe modulaire n'est pas le système spaghetti fortement couplé dont votre équipe s'est éloignée en 2016. Cette distinction est importante, et c'est là que la conversation déraille souvent.

Un monolithe modulaire en 2025 est une unité déployable unique organisée autour de frontières de modules internes explicites. Pensez-y comme une architecture microservices appliquée au niveau du code plutôt qu'au niveau de l'infrastructure. Les modules possèdent leurs modèles de données, exposent des interfaces internes délibérées et ne peuvent pas accéder directement aux internals des autres modules. La différence, c'est que la communication entre eux est un appel de fonction, pas une requête HTTP — ce qui signifie qu'elle est synchrone, rapide, type-safe et trivialement observable.

En pratique, cela ressemble à :

Des répertoires de modules orientés domaine avec des règles d'import strictes appliquées via du linting ou des outils de frontières de modules (Nx, Architecture Unit dans les écosystèmes Java, ou de simples règles ESLint pour les monorepos TypeScript)
Un accès aux données sans partage — chaque module possède ses tables ou schémas de base de données, et les autres modules interrogent via l'interface publique du module
Un découplage par événements à l'intérieur du processus, en utilisant des bus d'événements in-process pour la communication inter-modules nécessitant un couplage lâche
Des feature flags et des déploiements progressifs appliqués au niveau applicatif, permettant des mises en production partielles sécurisées sans coordonner des déploiements multi-services

Cette architecture n'est pas une régression. C'est une maturation — la reconnaissance que l'isolation de déploiement et l'isolation logique sont des problèmes différents, et que vous n'avez pas besoin de résoudre le premier pour atteindre le second.

L'infrastructure moderne qui fait du monolithe un choix de premier plan

L'une des critiques légitimes de l'architecture monolithique vers 2014 était au niveau de l'infrastructure : la mise à l'échelle était tout ou rien, le déploiement était risqué et les options d'hébergement étaient comparativement rigides. Cette critique est largement obsolète en 2025.

Considérez ce que le paysage infrastructurel actuel permet réellement :

Railway et Fly.io rendent le déploiement d'applications conteneurisées avec des déploiements progressifs sans interruption, plusieurs réplicas régionaux et de l'autoscaling genuinement simple. Un monolithe bien structuré tournant dans trois régions Fly.io avec un réplica en lecture par région constitue une architecture de production sérieuse et globalement distribuée — que la plupart des configurations microservices n'égalent pas en fiabilité.
Supabase et PlanetScale offrent du Postgres managé avec connection pooling, branching et mise à l'échelle horizontale en lecture, supprimant l'un des derniers arguments de mise à l'échelle réellement valides pour la décomposition en services (une base de données par service).
Les primitives serverless — Cloudflare Workers, Vercel Edge Functions, AWS Lambda — permettent d'extraire sélectivement des chemins à fort trafic ou isolés computationnellement, sans décomposer l'ensemble du système.
Docker et les outils CI/CD modernes signifient que le cycle de build et de déploiement d'un monolithe peut être rapide, reproductible et sécurisé. Les déploiements blue-green pour un monolithe sont désormais acquis, pas une prouesse.

L'écart infrastructurel qui rendait autrefois les microservices opérationnellement nécessaires s'est largement comblé. Ce qui subsiste est une hypothèse culturelle qui mérite d'être réexaminée.

Quand les microservices ont vraiment du sens : les seuils réels

Ce n'est pas un argument selon lequel les microservices sont toujours mauvais. C'est un argument selon lequel ils sont presque toujours prématurés. Voici les signaux réels qui suggèrent qu'une architecture distribuée est justifiée :

La taille de l'équipe dépasse ~50 ingénieurs travaillant sur la même surface produit, créant de véritables problèmes de conflits de merge et de coordination que la séparation architecturale résoudrait
Des sous-systèmes spécifiques ont des profils de mise à l'échelle radicalement différents — un pipeline de transcodage vidéo et un service d'authentification utilisateur n'ont presque rien en commun opérationnellement et ne devraient pas partager le même destin de déploiement
Des exigences de conformité ou de résidence des données contraignent certains traitements à être physiquement isolés
Vous disposez d'une équipe d'ingénierie de plateforme dédiée — au minimum 3 à 5 personnes — qui possède l'infrastructure distribuée comme responsabilité principale

Si votre organisation d'ingénierie ne coche pas au moins deux de ces cases, les microservices sont un pari sur la croissance future, payé au prix d'une complexité opérationnelle au quotidien. La plupart des startups en phase de croissance font ce pari par conviction, non par preuve.

Revenir en arrière architecturalement sans déclencher une crise politique

Si vous avez identifié que votre architecture microservices coûte plus qu'elle ne rapporte, le chemin du retour est autant un défi culturel que technique. Les décisions architecturales forgent une identité. Les ingénieurs qui ont porté la décomposition se sentiront mis en cause par le retour en arrière si celui-ci est présenté comme un échec.

Les équipes qui ont navigué cette transition avec succès ont tendance à suivre un même manuel :

Présentez-le comme une évolution, pas une correction

La migration vers les microservices avait du sens compte tenu de ce que vous saviez, de la taille d'équipe que vous aviez et de l'infrastructure disponible à l'époque. Le retour en arrière consiste à appliquer de nouvelles informations. Ce cadrage est à la fois juste et politiquement tenable.

Consolidez progressivement, pas tout à la fois

Commencez par deux ou trois services qui ont le plus fort overhead de coordination et la justification de mise à l'échelle indépendante la plus faible. Consolidez-les, mesurez concrètement l'amélioration opérationnelle (fréquence de déploiement, taux d'incidents, latence p95), et laissez les résultats plaider pour les phases suivantes.

Préservez les frontières de modules dans la base de code consolidée

La discipline de l'architecture monolithe modulaire donne aux ingénieurs le bénéfice cognitif de travailler dans des domaines isolés, ce qui préserve une partie de l'argument d'autonomie des équipes qui rendait les microservices séduisants. Les ingénieurs attachés à la séparation des préoccupations peuvent s'y attacher tout autant au sein d'un monolithe bien structuré.

Rendez les gains opérationnels visibles

Suivez et partagez les métriques avant et après : temps moyen de déploiement, temps moyen de détection, nombre de services nécessitant une coordination pour une release de fonctionnalité typique. Les chiffres dépolitisent les débats architecturaux plus efficacement que n'importe quel argument.

Choisissez une architecture ennuyeuse jusqu'à ce que les preuves vous forcent à faire autrement

Les organisations d'ingénierie les plus sophistiquées que j'ai observées partagent une confiance tranquille dans leurs choix d'infrastructure. Elles ne courent pas après ce qui est à la mode architecturalement — elles résolvent les problèmes spécifiques qui se posent à elles avec le système le plus simple qui puisse fonctionner, et reportent la complexité jusqu'à ce que les preuves l'exigent.

Le monolithe modulaire n'est pas un recul. C'est l'application d'un jugement durement acquis à une question que l'industrie a répondu prématurément avec les microservices : comment devrions-nous organiser le logiciel pour que les équipes produit puissent avancer vite, que les systèmes restent fiables et que la complexité opérationnelle reste proportionnelle à l'échelle réelle ?

Pour la plupart des équipes d'ingénierie à la plupart des stades de croissance, la réponse en 2025 est la même qu'avant que les systèmes distribués ne deviennent un symbole de statut : livrez une application unique, bien structurée et soigneusement modularisée. Optez pour la distribution lorsque vous pouvez articuler le problème spécifique et fondé sur des preuves qu'elle résout — pas avant.

Votre future rotation d'astreinte vous en sera reconnaissante.