Monolith vers microservices : quand faut-il vraiment migrer (et quand ne pas le faire) ?

#La réalité des microservices en 2026 : la hype est terminée

En 2015, les microservices étaient la réponse à tout. Netflix scalait sur des centaines de services. Amazon avait décomposé son monolithe en unités autonomes. Les conférences tech ne parlaient que de ça.

Dix ans plus tard, le tableau est plus nuancé — et les retours d'expérience publiés par des ingénieurs de premier plan méritent d'être lus sans idée préconçue.

Amazon Prime Video, en 2023, a publié un article technique reconnaissant avoir re-consolidé plusieurs microservices en un seul processus monolithique pour leur pipeline de surveillance vidéo. Résultat : réduction de 90% des coûts d'infrastructure et amélioration de la scalabilité. Leur conclusion était limpide : la décomposition en services avait atteint ses limites pour ce use case.

Shopify maintient depuis 2019 un monolith Rails modulaire d'environ 3 millions de lignes — l'un des plus grands monolithes Ruby du monde — et le revendique comme un avantage concurrentiel. Leur approche : des frontières de domaine strictes via des «components» internes, sans overhead distribué.

Sam Newman, l'auteur de référence sur le sujet (Building Microservices, O'Reilly), a lui-même nuancé ses positions dans les éditions récentes. Sa recommandation : «Ne passez aux microservices que si vous avez déjà essayé d'améliorer votre monolithe et que ça n'a pas suffi.»

Ce contexte ne signifie pas que les microservices sont une mauvaise idée. Cela signifie que c'est une décision d'architecture — pas une évolution naturelle inévitable.

#Monolith modulaire : l'alternative méconnue qui résout 80% des problèmes

Le terme «monolith» a acquis une connotation péjorative dans les années 2010. Pourtant, un monolith mal structuré (souvent appelé «big ball of mud») et un monolith modulaire sont des architectures radicalement différentes.

Un monolith modulaire est une application déployée en un seul processus, mais organisée en modules internes aux frontières strictes :

• Chaque module possède sa propre API publique (interfaces Go, packages Java, modules TypeScript) et ses propres modèles de données.
• Les modules ne partagent pas de tables de base de données directement — ils communiquent via des interfaces définies, jamais par accès direct à la couche de persistance d'un autre module.
• Les dépendances entre modules sont explicites, vérifiées par des outils d'analyse statique (ArchUnit en Java, Deptrac en PHP, dependency-cruiser en TypeScript).
• Les tests sont organisés par module, ce qui permet de tester chaque domaine métier en isolation.

Cette structure offre les bénéfices principaux réclamés par les microservices — séparation des responsabilités, indépendance des domaines, facilité de compréhension — sans les coûts opérationnels : pas de latence réseau inter-services, pas de gestion de la cohérence distribuée, pas d'infrastructure Kubernetes à opérer, pas d'observabilité distribuée à configurer.

Martin Fowler décrit cette approche sous le terme «Modular Monolith» et en recommande l'exploration systématique avant d'envisager une décomposition en services.

Pour la majorité des équipes de 5 à 20 développeurs, travaillant sur des domaines métier encore en évolution, le monolith modulaire est architecturalement supérieur à une décomposition prématurée.

#Les 5 signaux qui indiquent qu'il faut vraiment migrer

La décision de migrer vers des microservices ne doit pas être prise sur la base de tendances technologiques ou de benchmarks d'entreprises dont le contexte est radicalement différent du vôtre. Elle doit reposer sur des signaux factuels observés dans votre organisation.

#Signal 1 : Contraintes de scalabilité asymétriques et documentées

Vous avez des parties de votre système qui nécessitent une scalabilité radicalement différente des autres, et cette contrainte est documentée par des métriques réelles — pas des projections hypothétiques.

Exemple concret : un système e-commerce où le moteur de recherche produit reçoit 50 000 requêtes/seconde lors des pics promotionnels, alors que le module de gestion des retours traite 200 requêtes/heure. Ces deux composants ont des profils de charge incompatibles qui justifient un déploiement séparé.

#Signal 2 : Équipes > 20 développeurs avec des domaines métier distincts

Les bounded contexts du Domain-Driven Design correspondent à des équipes réelles et distinctes. Les conflits de merge quotidiens ralentissent votre vélocité. Les déploiements nécessitent une coordination entre équipes qui ne travaillent pas sur les mêmes fonctionnalités.

C'est le «Two-Pizza Team Rule» d'Amazon : une équipe qui dépasse la taille de ce que deux pizzas peuvent nourrir est peut-être trop grande pour travailler sur la même base de code.

#Signal 3 : Domaines métier stables et bien délimités

Les frontières de vos domaines métier sont stables depuis au moins 12 à 18 mois. Vous n'ajoutez plus de nouvelles fonctionnalités qui traversent plusieurs domaines à la fois. Un event storming révèle des bounded contexts clairs avec peu de couplage.

Si vos domaines sont encore en cours de définition — ce qui est le cas de la plupart des startups et scale-ups en croissance rapide — une migration prématurée vous obligera à découper vos services le long de frontières incorrectes, créant un «distributed monolith» encore plus difficile à refactoriser.

#Signal 4 : Besoin de déploiements indépendants et fréquents par domaine

Des équipes différentes ont besoin de déployer en production plusieurs fois par jour, sur des cycles entièrement indépendants. Le modèle «release train» où toutes les équipes déploient ensemble est devenu un goulet d'étranglement documenté (temps de pipeline CI/CD > 45 minutes, blocages fréquents).

#Signal 5 : Contraintes de sécurité ou de conformité par périmètre

Certains composants traitent des données à sensibilité différente (données de santé, données financières PCI-DSS) qui nécessitent des périmètres de sécurité distincts, des certifications séparées, ou des niveaux d'accès différents. La séparation en services distincts répond à une exigence réglementaire, pas seulement à une préférence architecturale.

#Les 5 raisons de ne PAS migrer

#Raison 1 : Équipe < 20 développeurs

Les microservices sont un modèle organisationnel autant qu'un modèle technique. Avec moins de 20 développeurs, vous n'avez pas les effectifs pour opérer correctement une architecture distribuée : chaque service nécessite sa propre CI/CD, ses propres runbooks, son propre on-call. Le ratio «overhead opérationnel / valeur produite» est défavorable sous ce seuil.

Netflix, à ses débuts, était un monolithe. Airbnb a attendu d'avoir plusieurs centaines d'ingénieurs avant de commencer sa décomposition — et ce processus a duré des années.

#Raison 2 : Domaine métier pas encore stable

Si vous n'êtes pas certain de vos frontières métier, vous allez couper vos services au mauvais endroit. Refactoriser un monolith modulaire pour déplacer une frontière coûte quelques jours. Refactoriser deux microservices pour fusionner ou redécouper leurs responsabilités coûte des semaines — avec des changements d'API, de schémas de base de données, de contrats de service.

Migrer trop tôt produit ce que les praticiens appellent un «distributed monolith» : une architecture distribuée qui conserve tous les couplages du monolithe, avec en plus tous les problèmes de la distribution. C'est le pire des deux mondes.

#Raison 3 : Pas de problème de scalabilité réel et mesuré

Si votre application répond correctement à la charge actuelle avec un monolith, migrer pour «anticiper la scalabilité future» est une optimisation prématurée. Les problèmes de scalabilité que vous n'avez pas encore sont infiniment moins coûteux à résoudre plus tard qu'une architecture distribuée prématurée à opérer maintenant.

La scalabilité horizontale d'un monolith derrière un load balancer résout la grande majorité des problèmes de charge. Avant d'envisager la décomposition, avez-vous optimisé vos requêtes SQL, mis en place du caching applicatif, et évalué le scaling horizontal de votre monolith ?

#Raison 4 : Absence d'infrastructure de plateforme dédiée

Opérer des microservices en production requiert une infrastructure significative : orchestration de conteneurs (Kubernetes), service mesh (Istio ou Linkerd), observabilité distribuée (Prometheus, Grafana, Jaeger ou Tempo pour le tracing), pipelines CI/CD par service, gestion des secrets distribuée (Vault ou AWS Secrets Manager), et idéalement une équipe Platform Engineering dédiée.

Sans cette infrastructure, vous opérez des microservices «à la main» — ce qui est exponentiellement plus risqué et coûteux qu'un monolith bien géré.

#Raison 5 : Pas de culture d'ingénierie orientée API et contrats

Les microservices exigent une discipline rigoureuse sur les contrats d'API (versionning, rétrocompatibilité, consumer-driven contract testing avec Pact). Une organisation qui n'a pas encore cette culture produira des services dont les API casseront silencieusement les clients. La migration technique ne suffit pas — elle doit s'accompagner d'une évolution des pratiques d'ingénierie.

#Stratégies de découpage : DDD, bounded contexts, event storming

Si les signaux sont réunis et que la décision de migrer est prise, le découpage des services est l'étape la plus critique — et la plus souvent bâclée.

#Domain-Driven Design comme boussole

Le Domain-Driven Design (DDD), formalisé par Eric Evans, fournit le vocabulaire et les outils pour identifier les frontières naturelles d'un système métier. Les bounded contexts sont les unités de découpage : chaque contexte délimite un sous-domaine avec son propre langage ubiquitaire, ses propres modèles de données et ses propres règles métier.

Un bounded context bien défini se transforme naturellement en un candidat microservice. Un bounded context mal défini produit un service qui doit constamment appeler d'autres services pour compléter ses opérations — signe d'un mauvais découpage.

#Event Storming : visualiser les flux avant de découper

L'event storming est un atelier collaboratif (créé par Alberto Brandolini) qui modélise les flux métier via des événements domaine. En 2 à 4 jours avec les experts métier et l'équipe technique, il permet d'identifier :

• Les domain events clés (ex : «CommandePassée», «PaiementConfirmé», «StockMisÀJour»)
• Les agrégats et leurs invariants
• Les bounded contexts naturels et leurs frontières
• Les points de friction entre domaines (là où les événements traversent plusieurs contextes)

Cet atelier est indispensable avant tout découpage. Des équipes qui ont sauté cette étape se retrouvent systématiquement à redécouper leurs services 12 à 18 mois plus tard.

#Les patterns de découpage à privilégier

Découpage par capacité métier (Business Capability) : chaque service représente une capacité distincte de l'entreprise (gestion des catalogues, traitement des commandes, gestion des livraisons). C'est le découpage recommandé par Sam Newman.

Découpage par sous-domaine DDD : core domain (avantage concurrentiel), supporting domain (nécessaire mais non différenciant), generic domain (commodité, souvent externalisable).

Découpage par volatilité : grouper ensemble les parties qui changent au même rythme. Ne jamais couper un service le long d'une frontière technique (ne pas avoir un service «base de données» ou un service «authentification» transversal).

#Approche progressive : Strangler Fig + API Gateway + event-driven

Une migration monolith → microservices ne doit jamais se faire en big bang. L'approche progressive combine trois mécanismes :

Strangler Fig Pattern : extraire les services un par un depuis le monolith, en routant progressivement le trafic vers les nouveaux services via une API gateway. Le monolith reste en production et opérationnel pendant toute la durée de la migration.

API Gateway : couche de routage centrale qui intercepte toutes les requêtes et les oriente vers le bon service (monolith ou microservice selon l'avancement de la migration). Kong, AWS API Gateway, ou Nginx selon le niveau de sophistication requis.

Architecture event-driven : une fois les services découpés, la communication asynchrone via un bus d'événements (Apache Kafka, RabbitMQ, ou AWS EventBridge) découple définitivement les services. Chaque service publie des événements sur ses changements d'état ; les autres services consomment ces événements sans couplage temporel.

L'ordre recommandé : commencer par les services périphériques (faiblement couplés, non critiques), valider la mécanique de migration, puis progresser vers le cœur métier.

#Infrastructure requise : Kubernetes, service mesh, observabilité

Une architecture microservices en production sans la bonne infrastructure est plus dangereuse qu'un monolith bien géré. Voici les composants non négociables :

Orchestration : Kubernetes est le standard de facto. Il gère le scheduling des conteneurs, la scalabilité automatique (HPA), les rolling deployments et les rollbacks. Sans Kubernetes (ou un équivalent managé comme ECS), opérer plus de 10 microservices devient rapidement ingérable.

Service mesh : Istio (ou Linkerd pour une complexité moindre) ajoute des capacités réseau transparentes à l'infrastructure : mTLS entre services, circuit breaking, retries configurables, canary releases, et observabilité réseau. Critiques pour la sécurité et la résilience en production.

Observabilité distribuée : avec un monolith, un seul stack trace suffit pour diagnostiquer un problème. Avec des microservices, une requête traverse potentiellement 10 services. L'observabilité requiert trois piliers :

• Métriques : Prometheus + Grafana (ou Datadog en SaaS)
• Logs centralisés : OpenSearch ou Loki + Grafana
• Tracing distribué : Jaeger ou Tempo, avec instrumentation OpenTelemetry de chaque service

Sans tracing distribué, déboguer un problème de performance en production peut prendre des jours là où un monolith instrumenté répond en heures.

CI/CD multi-services : chaque service a son propre pipeline. Les tests d'intégration inter-services (contract testing avec Pact) valident que les contrats d'API ne sont pas cassés. Un changement dans le service A ne doit pas silencieusement casser le service B.

#Le piège de la complexité accidentelle

#Le distributed monolith

Le piège le plus fréquent : créer des services qui restent couplés malgré leur séparation physique. Les symptômes d'un distributed monolith :

• Un déploiement d'un service nécessite toujours de déployer d'autres services en même temps
• Les services appellent d'autres services de façon synchrone pour compléter leurs opérations de base
• Un service ne peut pas répondre à une requête si un autre service est indisponible
• Les schémas de base de données sont partagés entre services

Ce n'est pas un problème de technologie — c'est un problème de découpage. La solution est de revenir à la phase de modélisation DDD et de redéfinir les bounded contexts.

#Les chatty microservices

Un anti-pattern courant : des services qui s'appellent mutuellement de façon excessive pour assembler une réponse. Une requête HTTP entrante déclenche 15 appels inter-services synchrones, multipliant la latence et les points de défaillance.

La correction passe par la refonte des frontières de service (regrouper ce qui s'appelle souvent ensemble) et l'adoption de l'architecture event-driven pour les flux non temps-réel.

#La complexité opérationnelle sous-estimée

Ne pas avoir de «Platform Engineering» dédié dans une architecture microservices, c'est demander à chaque équipe produit de gérer sa propre infrastructure. Résultat : des pratiques hétérogènes, des configurations de sécurité divergentes, des pipelines CI/CD maintenus «artisanalement».

Règle pratique : si vous n'avez pas au moins 2 ingénieurs dédiés à la plateforme pour 15 services, votre dette opérationnelle va croître plus vite que votre vélocité produit.

#Alternative sérieuse : majestic monolith + scaling horizontal

Dhh (David Heinemeier Hansson), créateur de Rails et cofondateur de Basecamp/37signals, a promu le concept de «majestic monolith» : une application monolithique bien architecturée, avec des modules internes clairs, déployée sur des serveurs puissants et scalée horizontalement derrière un load balancer.

Cette approche n'est pas réservée aux petites applications. Basecamp gère des millions d'utilisateurs avec un monolith Rails. Stack Overflow a longtemps été construit sur un monolith ASP.NET servi par moins de 10 serveurs. GitHub a opéré son monolith Rails pendant des années avant de décomposer sélectivement certains composants.

Le scaling horizontal d'un monolith stateless répond à la grande majorité des problèmes de charge réels. Avant d'investir dans une migration vers des microservices, avez-vous :

1. Profilé votre application pour identifier les véritables goulots d'étranglement ?
2. Optimisé les requêtes SQL et mis en place un cache Redis ?
3. Évalué le coût d'ajouter 3 instances supplémentaires de votre monolith derrière un load balancer ?
4. Refactorisé votre code pour obtenir un monolith modulaire avec des frontières claires ?

Dans plus de la moitié des cas, ces étapes suffisent à résoudre les problèmes qui motivaient la migration.

#Retour Nehos : 3 migrations et 2 décisions de rester sur monolith

Entre 2024 et 2026, Nehos a accompagné 5 clients ETI dans l'évaluation et la décision d'architecture. Voici les résultats :

#Client A — Plateforme SaaS B2B (85 devs, 12 domaines métier stables)

Décision : migration vers microservices. Les 5 signaux étaient présents. L'event storming a révélé 9 bounded contexts clairement distincts. La migration progressive (Strangler Fig sur 28 mois) a permis à 4 équipes produit d'atteindre l'indépendance de déploiement. Résultat mesuré : temps de déploiement moyen réduit de 52 minutes à 8 minutes par équipe, vélocité +40% sur 18 mois post-migration.

#Client B — ERP industriel (22 devs, domaines stables, scalabilité asymétrique documentée)

Décision : migration sélective (3 services extraits sur 11 modules). Seuls les modules à forte contrainte de charge ont été extraits. Les 8 autres restent dans un monolith modulaire refactorisé. Coût de migration réduit de 65% par rapport à une décomposition totale. L'infrastructure Kubernetes est mutualisée sur les 3 services extraits uniquement.

#Client C — Marketplace e-commerce (45 devs, 6 domaines, pics de charge ×50 en période promotionnelle)

Décision : migration vers microservices. Le moteur de recherche, le catalogue et le panier ont été extraits en priorité — les trois composants soumis aux pics asymétriques. Le backoffice (commandes, facturation, gestion des retours) est resté monolithique jusqu'à la fin de la phase 2. Architecture finale : 5 services + 1 monolith refactorisé.

#Client D — Application métier interne (8 devs, domaine métier en évolution rapide)

Décision : ne pas migrer — refactorisation en monolith modulaire. L'audit a révélé que les problèmes de maintenabilité venaient d'un manque de structure interne, pas d'un besoin de distribution. Un refactoring sur 4 mois (introduction de modules TypeScript stricts, séparation des couches, tests par domaine) a résolu 90% des problèmes signalés. Aucun service distribué nécessaire.

#Client E — Scale-up fintech (18 devs, domaine encore en définition)

Décision : ne pas migrer — attendre la stabilisation du domaine. L'event storming a mis en évidence que les frontières métier changeaient à chaque sprint. Migrer vers des microservices aurait signifié refactoriser les contrats de service toutes les 6 semaines. Recommandation : monolith modulaire pendant 18 mois, réévaluation quand le domaine sera stabilisé.

Observation transversale : dans les deux cas de non-migration, les clients ont obtenu des améliorations de vélocité et de qualité comparables aux clients ayant migré — à une fraction du coût et du risque. La migration vers les microservices n'est pas le seul chemin vers une meilleure architecture.

#Ressources pour approfondir

Cette tribune s'inscrit dans la série Legacy Modernisation du blog Nehos. Les patterns connexes détaillés dans d'autres articles : le Strangler Fig Pattern pour la migration progressive, le pattern Anti-Corruption Layer pour préserver l'intégrité du nouveau domaine, et les architectures event-driven pour le découplage asynchrone.

Sur le plan technique, notre service de modernisation legacy détaille la méthodologie Nehos, de la phase de diagnostic au déploiement en production. Si vous êtes en train d'évaluer cette décision, notre diagnostic architecture gratuit vous aide à qualifier les signaux pertinents pour votre contexte.