Le monolithe modulaire n'est pas un compromis
Pourquoi je commence presque toujours par là — et quand j'en sors vraiment.
On présente le monolithe modulaire comme un compromis : “on commence simple, on découpera plus tard”. Cette phrase cache une erreur de raisonnement. Le découpage en services n'est pas une promotion ; c'est un coût opérationnel qu'on accepte quand un problème précis l'exige.
Un monolithe bien modularisé — frontières internes nettes, dépendances explicites, domaines isolés — vous donne 90 % des bénéfices d'une architecture distribuée sans la facture : pas d'orchestration, pas de cohérence éventuelle à débugger, un seul déploiement à raisonner.
J'en sors quand une partie du système a un profil de charge, une cadence de livraison ou une équipe radicalement différente du reste. Pas avant. La bonne question n'est pas “est-ce assez moderne ?” mais “quel problème concret le découpage résout-il aujourd'hui ?”.
Si la réponse est “aucun, mais on grandira”, vous payez une assurance pour un sinistre qui n'arrivera peut-être jamais — pendant que vos concurrents livrent.
Le monolithe modulaire n'est pas une étape qu'on subit avant les microservices. C'est souvent la destination.