Un monolithe bien conçu bat un microservices mal pensé

Un monolithe bien conçu bat un microservices mal pensé à tous les coups. 💪

On m'a vendu la complexité comme une preuve de maturité technique pendant des années. J'ai fini par comprendre que c'était l'inverse.

Le vrai problème que les microservices résolvent

Les microservices ne résolvent pas un problème technique. Ils résolvent un problème d'organisation.

Ils existent pour permettre à plusieurs équipes de travailler en parallèle sans se marcher dessus. Si tu es 3 devs, tu n'as pas ce problème. Si vous êtes 5, peut-être pas encore. Si vous êtes 50, tu en as vraiment besoin.

Mais la plupart des startups les adoptent à J1, avant d'avoir ce problème. C'est comme acheter un ERP quand tu as trois clients.

C'est une solution d'échelle qu'on applique à des organisations qui ne l'ont pas encore. C'est du premature scaling - la version infra du premature optimization.

La complexité infra ne se voit pas en démo

Je l'ai vu encore la semaine dernière : une équipe qui me montre fièrement leur système avec Kubernetes, trois bases de données différentes, et un message broker en queue. Ça donne l'impression de sophistication technique. Ça impressionne les investors.

Sauf qu'après le démo, quelqu'un doit :

• Orchestrer les services en prod. Kubernetes, c'est pas trivial.
• Déboguer quand un service appelle un autre qui appelle un tiers. Les traces distribuées ne suffisent pas.
• Gérer la latence réseau. Un appel inter-services, c'est 10-100ms de plus qu'un appel in-process.
• Maintenir l'observabilité. Quand un incident pète à 3h du matin, tu dois trouver où. Avec 12 services, c'est pas une demi-heure de debug.
• Gérer la synchronisation des déploiements. Deux services doivent rester alignés sur une donnée partagée.

Tout ce coût-là devient ton quotidien. Ce n'est pas un détail d'implémentation. Et personne ne te facture ce coût au moment où tu décides l'architecture.

Les startup font ce choix en se disant "on sera plus rapide à scaler". Spoiler alert : vous passerez 6 mois à déboguer des race conditions distribuées avant d'en tirer le moindre bénéfice.

Un monolithe bien structuré scale bien plus loin qu'on le pense

J'ai vu des monolithes en Node.js encaisser 50k requêtes par seconde. Des monolithes Rails traiter des millions de transactions. Des monolithes Django servir 500 millions d'utilisateurs mensuels.

Pas avec du voodoo. Juste avec :

• Une séparation claire des responsabilités en interne
• Des boundaries bien dessinées entre les modules
• Un schéma de données orthogonal (pas 50 tables avec des dépendances circulaires)
• Du caching stratégique (Redis, même si tout est local)
• Une indexation réfléchie (une index bien pensée vaut mieux qu'un service dédié)

Ce pattern, ce n'est pas nouveau. C'est ce que les gros systèmes faisaient avant que microservices soit un mot à la mode.

Le moment où tu as vraiment besoin de te fragmenter en services, ça se voit. Tu ne le devines pas en théorie à J1.

Tu observes : une partie de l'équipe attend que l'autre finisse son déploiement. Les dépendances deviennent un goulot. Tu as besoin de trois mois pour changer une donnée qui traverse trois domaines métier. Là, oui, tu fragmentes.

Mais ce moment arrive beaucoup plus tard qu'on le croit.

La vraie maturité, c'est savoir défendre la simplicité en réunion

Proposer une architecture simple - un monolithe bien structuré, une base de données relationnelle classique, pas de cache distributed complexity - ça peut donner l'impression de manquer d'ambition technique.

C'est là qu'il faut être solide.

Choisir le plus simple qui marche, et assumer ce choix face à une équipe qui veut du complexe pour le plaisir - c'est ça la compétence rare. C'est plus difficile que de dire "on va faire du Kubernetes" en pointant du doigt sur un schéma compliqué.

J'ai vu des CTO cédé à la pression des engineers qui voulaient du "vrai distributed system". Deux ans plus tard, l'équipe passait 40% de son temps à gérer l'infra au lieu de livrer de la valeur métier.

J'ai aussi vu des équipes qui avaient la discipline de dire non à la complexité jusqu'à ce qu'elle soit vraiment nécessaire. Ces équipes étaient 10x plus efficaces.

Ce qui rend un système réellement robuste

Un système robuste, c'est pas la technologie. C'est :

• Une compréhension claire du métier et de ce qu'on doit construire
• Une capacité à identifier rapidement les vrais problèmes (vs les faux problèmes d'ego technique)
• Des tests qui couvrent les chemins critiques (pas 95% de coverage sur du boilerplate)
• Un plan de monitoring simple et efficace (que quelqu'un peut comprendre à 3h du matin)
• La discipline de ne pas rajouter de couches avant que ce soit nécessaire

Aucune de ces choses n'exige des microservices.

Le pattern que j'applique en mission

Quand j'arrive avec une équipe technique, voici comment je pense l'architecture :

1. D'abord : comprendre la contrainte réelle. Vous êtes 5 ou vous êtes 500 ? Vous faites 1k requête par jour ou 1M ? Les contraintes réelles dessinent l'architecture, pas la vision du founder ou l'envie technique de l'équipe.

2. Monolithe bien structuré par défaut. C'est le choix le plus honnête pour 90% des cas.

3. Surveiller les vrais signaux de complexité : attente entre équipes, déploiement verrouillé, impossible de changer un détail sans cascade de modifications.

4. Quand c'est vraiment le moment : fragmenter progressivement. Pas une réécriture complète. Un service ici, un autre là. On teste si ça résout réellement le problème avant d'aller plus loin.

5. Jamais, jamais de microservices "just in case". C'est le meilleur moyen de se transformer en équipe d'infra avec un hobby métier.

En conclusion : la complexité ne prouve rien

La complexité coûte cher. En temps, en argent, en vélocité d'équipe, en santé mentale des engineers qui passent le week-end à déboguer des messages chronométrés.

Le bon architecte n'est pas celui qui construit le système le plus sophistiqué. C'est celui qui résiste à la tentation de le faire quand ce n'est pas nécessaire.

Et franchement ? Ça m'étonne que ce soit encore une question qu'on doit se poser en 2026.

---

P.S. : Si vous êtes en train de construire une startup et quelqu'un vous recommande les microservices avant que vous ayez 20 engineers, changez d'advisor. C'est pas un signal de maturité, c'est un signal qu'il cherche à vendre de la complexité.