Le hype cycle est terminé. Parlons sérieusement.
Pendant dix ans, la question “microservices ou monolithe ?” a déclenché des guerres de religion dans les équipes tech. D’un côté, les évangélistes des microservices promettant l’agilité absolue. De l’autre, les pragmatiques défendant la simplicité du monolithe.
En 2026, le débat a mûri. Les entreprises qui ont migré aveuglément vers les microservices en 2018-2020 ont payé le prix fort. Celles qui ont ignoré le mouvement se retrouvent avec des monolithes ingérables.
La réalité ? Le bon choix dépend de votre contexte, pas d’une tendance technologique.
Quand le monolithe reste le meilleur choix
Contrairement à ce que les conférences tech voudraient vous faire croire, le monolithe est la bonne architecture pour la majorité des projets.
Équipe de moins de 20 développeurs
Avec une équipe réduite, les microservices ajoutent de la complexité sans apporter de valeur proportionnelle. La coordination inter-services, le debugging distribué et la gestion d’infrastructure consomment un temps que vous n’avez pas.
Produit en phase de découverte
Quand le domaine métier évolue rapidement, redessiner les frontières entre services toutes les deux semaines est un cauchemar. Un monolithe bien structuré permet de pivoter vite.
Domaine métier fortement couplé
Si vos entités métier sont intrinsèquement liées — un système de facturation où commande, paiement et inventaire sont indissociables — les séparer crée de la complexité accidentelle sans résoudre la complexité essentielle.
Un monolithe bien conçu vaut infiniment mieux qu’un système distribué mal découpé.
Budget d’infrastructure limité
Les microservices multiplient les coûts : orchestration Kubernetes, observabilité distribuée, service mesh, registre de services. Pour une startup en early stage, chaque euro compte.
Quand les microservices sont justifiés
Les microservices ne sont pas une solution universelle, mais ils résolvent des problèmes réels dans des contextes précis.
Scale asymétrique des composants
Votre module de recherche absorbe 80% du trafic pendant que le module de gestion des comptes tourne à vide. Les microservices permettent de scaler indépendamment chaque composant.
Autonomie d’équipes multiples
Avec 50+ développeurs répartis en 8 squads, un monolithe devient un goulet d’étranglement. Les merge conflicts, les déploiements coordonnés et les régressions croisées ralentissent tout le monde.
Les microservices donnent à chaque équipe la propriété complète de son service : code, données, déploiement, monitoring.
Polyglottisme technologique nécessaire
Un moteur de recommandation en Python, un service de paiement en Java, une API gateway en Go. Si chaque composant a des besoins technologiques distincts, les microservices offrent cette flexibilité.
Exigences de résilience élevées
Dans un monolithe, un bug dans le module de reporting peut faire tomber l’ensemble du système. Avec des microservices bien isolés, la défaillance d’un service non critique n’impacte pas les services essentiels.
Le monolithe modulaire : la voie pragmatique
Entre le monolithe spaghetti et les microservices distribués, il existe une troisième voie que de plus en plus d’équipes adoptent en 2026 : le monolithe modulaire.
Le principe
Un seul déployable, mais une architecture interne strictement modulaire. Chaque module :
- A ses propres frontières clairement définies
- Expose une API interne (interface publique)
- Gère ses propres données (schéma séparé ou préfixé)
- Communique avec les autres modules uniquement via leurs APIs
Les avantages concrets
Simplicité opérationnelle du monolithe — un seul artefact à déployer, une seule base de données à sauvegarder, un seul processus à monitorer.
Modularité des microservices — chaque module peut évoluer indépendamment, les dépendances sont explicites, le code est découplé.
Chemin de migration préparé — si un module doit devenir un service autonome demain, l’extraction est quasi-triviale car les frontières existent déjà.
Mise en pratique
En Java/Kotlin, utilisez les modules Maven ou Gradle avec des dépendances explicites. En TypeScript, un monorepo avec des packages internes (Turborepo, Nx). En .NET, les projets et solutions structurés.
La règle d’or : interdire les imports croisés entre modules. Chaque module ne peut accéder qu’à l’API publique des autres modules.
Le Strangler Fig Pattern : migrer sans tout casser
Vous avez un monolithe existant et vous devez en extraire des services ? Le Strangler Fig Pattern est votre meilleur allié.
Comment ça fonctionne
Comme le figuier étrangleur qui pousse autour d’un arbre existant jusqu’à le remplacer, vous construisez les nouveaux services autour du monolithe existant.
- Identifier un bounded context bien délimité dans le monolithe
- Construire le nouveau service qui réplique cette fonctionnalité
- Router progressivement le trafic vers le nouveau service (feature flags, reverse proxy)
- Valider en production avec du trafic réel (canary deployment)
- Décommissionner le code correspondant dans le monolithe
Les pièges à éviter
- Migrer trop de choses en même temps — commencez par un contexte simple et bien isolé
- Négliger la synchronisation des données — la période de transition nécessite une stratégie de données claire
- Oublier le rollback — chaque étape doit être réversible
Domain-Driven Design : la boussole du découpage
Que vous optiez pour des microservices ou un monolithe modulaire, le Domain-Driven Design (DDD) fournit le cadre intellectuel pour définir les bonnes frontières.
Bounded Contexts
Un bounded context représente une frontière linguistique et fonctionnelle. Dans un e-commerce, “Produit” signifie des choses différentes pour le catalogue (titre, description, images), la logistique (poids, dimensions, fragilité) et la comptabilité (prix, TVA, marge).
Chaque bounded context mérite potentiellement son propre module ou service.
Context Mapping
La cartographie des relations entre contexts révèle les dépendances et les modes de communication. Un contexte upstream fournit des données, un contexte downstream les consomme. Ces relations dictent vos contrats d’API et vos stratégies d’intégration.
Event Storming
Avant de dessiner des boîtes sur un diagramme, réunissez développeurs et experts métier pour un Event Storming. Identifiez les événements domaine, les commandes, les agrégats. Les frontières naturelles émergent d’elles-mêmes.
L’impact de la topologie d’équipe
La loi de Conway n’est pas qu’une boutade : la structure de votre organisation influence directement votre architecture.
Inverse Conway Maneuver
Plutôt que subir la loi de Conway, utilisez-la à votre avantage. Organisez vos équipes en fonction de l’architecture cible. Si vous voulez des services autonomes, créez des équipes autonomes avec toutes les compétences nécessaires (dev, ops, QA, produit).
Stream-aligned teams
Le modèle Team Topologies de Skelton et Pais identifie quatre types d’équipes : stream-aligned (alignées sur un flux de valeur), platform (infrastructure commune), enabling (accélération des autres équipes), complicated subsystem (expertise spécifique).
Un monolithe fonctionne bien avec 2-3 stream-aligned teams. Au-delà, les microservices deviennent nécessaires pour maintenir l’autonomie.
Comparaison des coûts opérationnels
Le coût total de possession (TCO) est souvent le critère le plus sous-estimé.
Monolithe
- Infrastructure : 1 serveur (ou quelques instances), 1 base de données, 1 pipeline CI/CD
- Observabilité : logs centralisés, APM standard, métriques applicatives simples
- Opérations : déploiements simples, rollback trivial, debugging direct
Microservices
- Infrastructure : cluster Kubernetes, service mesh (Istio/Linkerd), registre de services, API gateway
- Observabilité : tracing distribué (Jaeger/Tempo), corrélation de logs, métriques par service, alerting granulaire
- Opérations : déploiements indépendants mais coordination complexe, debugging distribué, gestion des versions d’API
Comptez un facteur 3x à 5x sur les coûts d’infrastructure et d’outillage pour passer d’un monolithe à des microservices.
Le calcul réel
Le surcoût des microservices se justifie quand le coût du couplage dans le monolithe dépasse le coût de la distribution. Ce point de bascule dépend de la taille de l’équipe, du volume de trafic et de la vélocité de delivery requise.
Notre recommandation
Chez Les Artisans du Digital, on accompagne les entreprises dans ces choix d’architecture depuis des années. Notre approche est pragmatique :
- Commencez par un monolithe modulaire — c’est le bon défaut pour 80% des projets
- Investissez dans le DDD — les bonnes frontières sont plus importantes que la technologie
- Extrayez des services quand la douleur est réelle — pas quand elle est imaginée
- Mesurez avant de décider — DORA metrics, temps de cycle, fréquence de déploiement
L’architecture n’est pas une destination, c’est un voyage itératif dicté par vos contraintes réelles.
FAQ
Peut-on commencer par un monolithe et migrer vers les microservices plus tard ?
Absolument, et c’est même l’approche recommandée. La clé est de structurer votre monolithe de manière modulaire dès le départ (bounded contexts, APIs internes, séparation des schémas de données). Le Strangler Fig Pattern permet ensuite d’extraire progressivement les modules qui en ont besoin sans big bang risqué.
Combien de développeurs faut-il avant d’envisager les microservices ?
Il n’y a pas de chiffre magique, mais en dessous de 20 développeurs, les microservices apportent rarement plus de valeur qu’ils ne coûtent en complexité. Au-delà de 40-50 développeurs travaillant sur le même produit, les frictions du monolithe deviennent généralement insoutenables et justifient la distribution.
Le monolithe modulaire est-il juste un microservice déguisé ?
Non. La différence fondamentale est le mode de déploiement et de communication. Un monolithe modulaire est un seul processus avec des appels de fonction en mémoire. Les microservices sont des processus séparés communiquant par le réseau. Cette distinction a des implications majeures sur la latence, la cohérence des données, la gestion des erreurs et les coûts opérationnels.
Comment mesurer si notre monolithe a atteint ses limites ?
Surveillez ces signaux : fréquence de déploiement en baisse, temps de build qui explose (plus de 30 minutes), merge conflicts chroniques, impossibilité de scaler un composant spécifique sans scaler tout le système, et temps de onboarding des nouveaux développeurs qui dépasse plusieurs semaines. Si plusieurs de ces symptômes sont présents, il est temps d’envisager une évolution architecturale.