Architecture : quand choisir un monolithe plutôt qu’une organisation par domaines ?
Pendant des années, l’architecture logicielle a été présentée comme une trajectoire quasi obligatoire :
monolithe au début, microservices ensuite, organisation par domaines à la fin.
Dans la réalité, ce chemin linéaire n’existe pas.
De nombreuses équipes se retrouvent aujourd’hui avec :
- une organisation par domaines prématurée,
- une complexité inutile,
- une perte de lisibilité,
- et parfois une vélocité plus faible qu’avant.
La question n’est donc pas “monolithe ou organisation par domaines ?”
La vraie question est : à quel moment, et dans quel contexte, l’un devient préférable à l’autre ?
Le monolithe : une architecture injustement caricaturée
Le monolithe souffre d’une mauvaise réputation.
On l’associe à :
- une base de code ingérable,
- des déploiements risqués,
- une dépendance forte entre les équipes.
En réalité, ces problèmes ne viennent pas du monolithe lui-même, mais :
- d’un manque de discipline,
- d’une mauvaise modularisation,
- ou d’une croissance non maîtrisée.
Un monolithe bien conçu peut être :
- modulaire,
- testable,
- performant,
- et extrêmement efficace pour délivrer rapidement.
L’organisation par domaines : un coût souvent sous-estimé
À l’inverse, l’architecture par domaines (ou microservices) est souvent perçue comme une solution “mature”.
Elle apporte effectivement :
- une meilleure séparation des responsabilités,
- une autonomie accrue des équipes,
- une scalabilité organisationnelle.
Mais elle a un coût réel :
- multiplication des pipelines CI/CD,
- complexité des flux inter-domaines,
- observabilité plus exigeante,
- besoin de standards très solides,
- maturité DevOps et SRE indispensable.
Sans cette maturité, l’organisation par domaines devient une source de friction plus qu’un levier.
Quand le monolithe est le meilleur choix
Il existe de nombreux contextes où le monolithe est non seulement acceptable, mais souhaitable.
1. Équipe réduite ou peu spécialisée
Quand une même équipe porte plusieurs responsabilités, un monolithe réduit :
- les coûts cognitifs,
- la coordination,
- les frictions de delivery.
2. Produit encore en forte exploration
Quand le périmètre fonctionnel évolue rapidement, figer des frontières de domaines trop tôt est risqué.
Un monolithe permet de faire évoluer le produit sans renégocier l’architecture à chaque itération.
3. Faible volumétrie ou contraintes de performance maîtrisées
Si la charge est prévisible et maîtrisée, la scalabilité horizontale offerte par les microservices est souvent inutile.
4. Maturité DevOps limitée
Sans automatisation solide, observabilité et culture SRE, une architecture distribuée expose davantage aux incidents qu’elle n’en résout.
5. Besoin de simplicité opérationnelle
Un monolithe bien outillé est souvent plus simple à opérer, déployer et surveiller.
Quand l’organisation par domaines devient pertinente
À l’inverse, certains signaux indiquent qu’un monolithe atteint ses limites.
1. Multiplication des équipes
Quand plusieurs équipes travaillent en parallèle sur des périmètres distincts, l’autonomie devient un enjeu clé.
2. Domaines métier clairement stabilisés
Lorsque les frontières métier sont comprises, stables et partagées, une organisation par domaines prend tout son sens.
3. Contraintes fortes de scalabilité différenciée
Si certains sous-systèmes doivent évoluer indépendamment en charge ou en disponibilité, la séparation devient pertinente.
4. Organisation prête à absorber la complexité
L’architecture par domaines est avant tout un choix organisationnel, pas seulement technique.
Le faux dilemme : monolithe ou microservices
Dans la pratique, le choix n’est pas binaire.
Beaucoup de systèmes efficaces reposent sur :
- un monolithe modulaire,
- des frontières internes claires,
- une capacité à extraire progressivement des domaines lorsque cela devient nécessaire.
Cette approche permet :
- de conserver la simplicité tant qu’elle est utile,
- de préparer l’avenir sans sur-architecturer,
- d’éviter les migrations brutales.
Ce qui doit guider le choix
Le bon choix architectural dépend rarement de la technologie à la mode.
Il dépend :
- du niveau de maturité des équipes,
- de la stabilité du produit,
- de la capacité à opérer la complexité,
- des objectifs business à court et moyen terme.
Une architecture est un moyen, pas une finalité.
En conclusion
Choisir un monolithe plutôt qu’une organisation par domaines n’est pas un aveu de faiblesse.
C’est parfois le choix le plus rationnel.
La vraie erreur n’est pas de rester sur un monolithe.
La vraie erreur est de complexifier trop tôt, sans être prêt à en assumer le coût.
L’architecture doit servir le produit et l’organisation, pas l’inverse.
Vous avez un
produit en tête ?
Construisons-le ensemble.