Pourquoi reparler du monolithe aujourd’hui ?
Le mot “monolithe” fait souvent peur. On l’associe à une application énorme, lente et impossible à maintenir. À force, beaucoup d’équipes préfèrent se tourner directement vers les microservices, pensant que c’est forcément plus moderne et efficace.
Mais le problème fondamental n’est pas dans le choix entre monolithe et microservice, mais dans la discipline architecturale. Un monolithe peut très bien rester simple et élégant s’il est structuré dès le départ en modules clairs et découplés.
La modularité n’est pas un luxe : c’est ce qui rend votre code maintenable et évolutif malgré la complexité croissante des fonctionnalités et des équipes. C’est ce qui permet de différencier une application robuste, évolutive et maintenable dans le temps d’un legacy lourd, difficile à maintenir et pour lequel chaque nouvelle fonctionnalité à implémenter est un calvaire.
À retenir :
Monolithe ≠ Big Ball of Mud
Un monolithe bien conçu, structuré en modules découplés, peut être aussi maintenable et scalable qu’un système distribué.
Le super-pouvoir de la modularité
Il est important maintenant de comprendre ce que l’on entend par modularité.
Imaginez votre application comme une ville. Sans plan d’urbanisme, chacun construit ce qu’il veut où il veut. Il n’y a pas de réelle cohérence d’ensemble. Aucune règle ne détermine comment construire une route, où placer certains bâtiments stratégiques (Caserne de pompier, commissariat, …).
Si on prend l’exemple de la construction d’une route, la seule règle qui existe consiste à relier deux points le plus rapidement. Ce principe peut fonctionner avec une seule route. Mais lorsque l’on souhaiterait en rajouter des nouvelles, on ne se posera pas la question de si une route existante peut être réutilisé en partie ou non. Ainsi, chaque route ne concernera qu’un seul et unique trajet. Il est donc nécessaire de construire une nouvelle route complète pour chaque destination possible. Très vite, cela devient chaotique et impraticable.
Mais avec des quartiers bien définis, des routes organisées et des règles de construction, la ville grandit harmonieusement.
Un monolithe modulaire suit le même principe : il regroupe le code en modules responsables chacun d’un domaine fonctionnel précis. Chaque module sait ce qu’il expose et ce qu’il cache, et ne dépend pas directement de l’implémentation interne des autres.
Résultat : l’application devient plus lisible, les changements sont localisés, et l’équipe garde confiance dans le projet même lorsque celui-ci évolue et s’agrandit.
À retenir :
Une application modulaire :
- Chaque module possède un rôle et représente un domaine métier précis
- Il cache ses détails internes
- Il expose des interfaces claires
- Il ne dépend pas de l’implémentation des autres
Spring Modulith : Un monolith modulaire by design ?
Dans la plupart des projets Spring Boot, la structure repose sur de simples conventions : on organise le code par packages, on documente, et on espère que tout le monde les respecte. Mais cette approche a ses limites, surtout quand l’équipe grandit ou que le projet dure plusieurs années.
Spring Modulith ajoute des outils pour transformer ces bonnes pratiques en règles vérifiables :
- Vous définissez explicitement vos modules, leurs frontières et leurs dépendances autorisées
- Des tests d’architecture vérifient automatiquement qu’aucun module ne viole ces règles
- La documentation et les diagrammes sont générés automatiquement à partir du code, garantissant qu’ils sont toujours à jour
Spring Modulith permet également la communication par événements entre modules, ce qui réduit le couplage et rend votre architecture plus souple.
L’importance du découplage et des événements
Dans un monolithe traditionnel, il est souvent tentant d’appeler directement la méthode d’un autre module. Si cette pratique semble simple à court terme, elle crée des dépendances invisibles et fragiles entre les modules. Ces liens implicites rendent l’architecture difficile à faire évoluer et mènent souvent à ce qu’on appelle un big ball of mud, un entrelacs de dépendances difficile à maintenir.
Spring Modulith propose une alternative claire à ce piège : un découpage intra-module entre composants internes et composants exposés.
Chaque module est ainsi structuré autour de deux zones distinctes. La partie interne contient la logique métier propre au module, inaccessible de l’extérieur. La partie externe, quant à elle, expose des points d’entrée soigneusement choisis, permettant à d’autres modules d’interagir sans violer l’encapsulation. Ce découpage renforce la modularité et limite les dépendances non maîtrisées.
L’exposition de ces fonctionnalités peut se faire via des interfaces publiques, représentant les services accessibles depuis d’autres modules. Mais Spring Modulith pousse plus loin cette logique en proposant nativement une approche événementielle : au lieu d’invocations directes, un module peut publier un événement signalant qu’une action s’est produite. Les autres modules, intéressés par cet événement, s’y abonnent et réagissent de manière indépendante. Ces événements peuvent être géré directement dans l’application, ou être externalisé dans une base de données, un service de messaging type ActiveMQ ou Kafka.
Cette approche décentralisée favorise le découplage : le module émetteur ignore tous des modules qui l’écoutent, ce qui facilite l’ajout ou la modification de comportements sans impacter l’existant.
Cela dit, une telle architecture demande une gestion rigoureuse des scénarios d’erreur. Les traitements déclenchés par événements sont souvent asynchrones, ce qui peut introduire des états intermédiaires incohérents en cas d’échec. Il est donc essentiel d’anticiper ces cas via des mécanismes de rejeu, de compensation ou de tolérance aux pannes.
À retenir :
Un module n’a pas besoin de connaître ses consommateurs. C’est le principe de l’événementiel, garantissant un monolithe modulaire et flexible.
Un contrat d’architecture vivant
Souvent, les bonnes pratiques d’architecture existent dans la tête des développeurs seniors ou dans une documentation figée qui peut devenir obsolète. De plus, plus l’application contient de fonctionnalités, plus il devient compliqué de maintenir les règles d’une architecture modulaire. Un garde-fou est nécessaire pour valider, à chaque étape, que les toutes ces règles soient respectées. La documentation d’architecture est également coûteuse à maintenir à jour.
Avec Spring Modulith, ces règles deviennent vérifiables : des tests d’architecture s’exécutent à chaque build et échouent dès qu’une dépendance non autorisée est introduite.
Cela change radicalement la dynamique : ce n’est plus une question de vigilance individuelle, mais une garantie automatique qui protège la structure du projet.
Pour les nouveaux développeurs ou les personnes extérieures, la documentation générée automatiquement (diagrammes, descriptions de modules) offre une vision claire et toujours à jour du système.
À retenir :
Plus besoin de documentation obsolète ! L’architecture devient un élément vérifiable et vivant du projet.
Quand utiliser Spring Modulith ?
Spring Modulith est particulièrement utile dès qu’un projet doit durer, évoluer ou impliquer plusieurs développeurs travaillant en parallèle.
- Projets métiers complexes où les fonctionnalités sont nombreuses et interconnectées
- Équipes structurées en feature teams, chacune responsable d’un module fonctionnel
- Nouveaux projets stratégiques où l’on peut réfléchir dès le départ au découpage
Même dans des projets existants, Spring Modulith peut être introduit progressivement pour redonner de la clarté et réduire le couplage entre les parties du système.
Monolithe modulaire ou microservices ?
Les architectures microservices et modulaires partagent une même ambition : structurer l’application par domaines fonctionnels et réduire les dépendances entre composants. Là où elles diffèrent fondamentalement, c’est dans leur mode de déploiement et la complexité technique qui en découle.
Dans une architecture microservices, chaque module devient une application indépendante, avec sa propre base de données, ses API, son infrastructure et ses outils de supervision. Ce découplage physique apporte une grande flexibilité, permettant à chaque service d’évoluer, de monter en charge ou d’être déployé de manière autonome. En contrepartie, il introduit une complexité opérationnelle importante : orchestration des services, résilience réseau, sécurité interservices, monitoring distribué, gestion des erreurs asynchrones, etc.
Au-delà de la technicité, cette complexité a un coût réel. Chaque microservice possède un cycle de vie propre : pipelines CI/CD, gestion de versions, configuration, déploiement, supervision… Multipliez cela par le nombre de services, et la charge opérationnelle peut rapidement devenir difficile à maîtriser. Sans une forte maturité DevOps et une équipe bien structurée, l’architecture microservices peut se transformer en un système fragmenté, coûteux à faire évoluer.
C’est là qu’intervient une alternative pragmatique : le monolithe modulaire. Contrairement au monolithe classique, cette architecture repose sur des modules bien définis, faiblement couplés, chacun avec ses responsabilités claires. Le tout est packagé et déployé comme une seule application. On conserve ainsi la simplicité du déploiement, tout en bénéficiant d’une modularité interne forte, facilitant l’évolutivité, les tests et la maintenance. Et surtout, cette structure prépare naturellement le terrain à une éventuelle extraction progressive vers des microservices.
À retenir :
Commencez simple, structurez bien. Un monolithe modulaire est souvent le meilleur compromis entre simplicité technique et scalabilité.
Les bénéfices d’un monolithe modulaire
Un monolithe modulaire n’est pas un compromis. C’est souvent le meilleur choix pour un grand nombre d’applications métiers :
- Déploiement et supervision moins complexes qu’avec des microservices (1 vs N services à déployer)
- Performances optimales grâce à l’exécution locale sans appels réseau (Il est tout de même possible de passer par des services externes pour stocket et gérer le rejeu des appels entre module : bdd, message queue, …)
- Maintenabilité et clarté du code grâce à la séparation en modules.
Spring Modulith aide à rendre cette modularité explicite et durable, protégeant le projet contre l’érosion architecturale au fil du temps.
À retenir :
- Productivité accrue grâce à une meilleure lisibilité du code
- Déploiement simplifié : un seul artefact à gérer
- Performances optimales : exécution locale, pas d’appel réseau (possible à mettre en place en cas de besoin)
- Architecture robuste et évolutive dans le temps
Conclusion
Spring Modulith n’est pas qu’un outil. C’est une façon de formaliser les bonnes pratiques d’architecture et de s’assurer qu’elles tiennent sur la durée.
En imposant la modularité comme une règle vivante et vérifiable, il permet de construire des monolithes modernes : évolutifs, robustes et compréhensibles.
Pour beaucoup de projets, cela peut être la meilleure manière de concilier simplicité technique et exigence architecturale.
Pour aller plus loin
- Site officiel de Spring Modulith: https://spring.io/projects/spring-modulith
- Documentation Spring Modulith: https://docs.spring.io/spring-modulith/docs/current/reference/html/
- Conférence « Spring Modulith Deep Dive » (YouTube): https://www.youtube.com/watch?v=430YOyMNjhs
À propos de l’auteur
Moussa NEDJARI est consultant fullstack au sein du pôle Engineering de Smartwave.
Diplômé en informatique de l’Université Pierre et Marie Curie, il a contribué à de nombreux projets pour des acteurs majeurs dans les secteurs du tourisme, de la santé, de l’immobilier et de l’énergie.
Passionné par les jeux vidéo, les mangas et le football, Moussa aime combiner rigueur technique et créativité pour concevoir des solutions performantes et évolutives.
