Le monolithe a longtemps eu mauvaise presse, et c’est une injustice : pour la majorité des projets qui démarrent, un monolithe bien structuré reste le bon choix. Le découpage en microservices n’est pas un objectif, c’est une réponse à une douleur très spécifique. Quand l’équipe grossit à plus de douze développeurs sur le même code, quand les cycles de release deviennent des réunions de coordination de quarante minutes, quand un incident dans un coin du système paralyse tout le reste, alors le découpage devient défendable. Cet article couvre les critères pour décider, les techniques pour découper proprement, les pièges classiques, et l’outillage minimal qui rend l’architecture viable.
Quand le monolithe atteint vraiment sa limite
Trois symptômes signalent qu’un découpage mérite d’être étudié. Le premier est le temps de démarrage et de test : si la suite de tests prend trente minutes, si redémarrer l’application en local prend cinq minutes, le rythme de développement chute. Le second est le couplage inter-équipes : deux équipes qui ne peuvent pas livrer chacune sans coordonner avec l’autre paient un coût permanent en synchronisation. Le troisième est la gestion de la charge : un service interne qui consomme beaucoup de CPU oblige à scaler tout le monolithe, ce qui est cher et inefficace.
Si aucun des trois ne s’applique, le monolithe est probablement encore le bon choix. Découper coûte en complexité opérationnelle, en latence réseau, en debugging distribué. Aucune de ces dettes ne disparaît : on les paie avec discipline. C’est exactement pour cela que beaucoup d’entreprises qui ont migré vers les microservices il y a sept ans reviennent vers des modulith ou des architectures cell-based plus pragmatiques. La règle saine reste celle énoncée par Martin Fowler : monolith first, ne découper que sous pression éprouvée.
Trouver les frontières avec le Domain-Driven Design
Découper un système au hasard produit du chaos distribué. La technique de référence pour identifier les bons axes de coupure est le Domain-Driven Design (DDD), introduite par Eric Evans en 2003 et toujours pertinente. L’idée centrale est de cartographier les bounded contexts du métier : des zones cohésives où un même terme a un même sens, et au-delà desquelles le sens change. Dans une plateforme e-commerce, le mot « client » ne signifie pas la même chose pour le marketing (un prospect), pour le commerce (un acheteur), pour la facturation (un débiteur) et pour le support (un dossier). Chaque contexte mérite son propre service, son propre modèle, ses propres tables.
L’exercice concret consiste à réunir l’équipe et à faire un event storming : poster les événements métier sur un mur, regrouper ceux qui appartiennent au même processus, dessiner les frontières. Cette session de quelques heures donne une carte des services candidats. La règle à vérifier ensuite : un service doit pouvoir évoluer sans concertation avec les autres pendant la majorité de ses changements. Si chaque modification de service A oblige à modifier service B, ils ne sont pas indépendants — c’est un seul service déguisé en deux.
REST synchrone ou messaging asynchrone
Une fois les services identifiés, il faut choisir comment ils communiquent. Deux familles s’opposent. La communication synchrone (REST, gRPC) est simple à comprendre : on appelle, on attend la réponse, on continue. La communication asynchrone (RabbitMQ, Kafka, NATS) découple plus fort : un service publie un événement, les autres le consomment à leur rythme. La première convient aux interactions transactionnelles immédiates. La seconde convient aux cascades d’effets et aux intégrations résilientes.
Le piège classique est de tout faire en synchrone. Un service A appelle B, qui appelle C, qui appelle D. Le moindre ralentissement dans D fait casser toute la chaîne en domino. Les SLA se multiplient : si chaque appel a 99,9 % de disponibilité, une chaîne de quatre tombe à 99,6 %. La règle pratique : tout ce qui est acte déclenché par un humain qui attend la réponse est synchrone. Tout ce qui est conséquence en arrière-plan est asynchrone. Une commande validée retourne 201 immédiatement (synchrone), l’envoi du mail de confirmation et la mise à jour du stock sont des conséquences (asynchrones via un broker).
Choisir un broker de messages
Trois brokers dominent le marché en 2026. RabbitMQ reste la référence pour les patterns classiques (queues, exchanges, routing keys) — il est mature, léger, parfait pour les workloads transactionnels jusqu’à quelques dizaines de milliers de messages par seconde. Apache Kafka est le standard pour le streaming à haut débit et la replay de logs d’événements ; il consomme plus de ressources mais devient inévitable au-delà d’un certain volume. NATS, plus jeune et plus léger, gagne du terrain dans les architectures cloud-native pour sa simplicité et ses performances en pub/sub.
Pour une plateforme qui démarre, RabbitMQ est généralement le meilleur compromis : courbe d’apprentissage douce, documentation abondante, écosystème client riche dans tous les langages. On migre vers Kafka uniquement quand on a besoin de replay (rejouer les événements pour reconstruire un état) ou de rétention longue. NATS est un bon choix pour des architectures edge ou IoT où la légèreté prime.
Une base par service, ou pas
Le principe officiel des microservices dit qu’un service doit posséder ses données : sa propre base, son propre schéma, aucun accès direct par les autres services. Cette règle est saine en théorie mais coûte cher en pratique. Si chaque service a sa base Postgres, il faut gérer N instances, N sauvegardes, N upgrades, N stratégies de scaling. Et les requêtes qui croisent plusieurs services deviennent des compositions côté application, plus lentes et plus fragiles.
Une approche pragmatique répandue consiste à partager une instance physique mais à isoler les schémas : chaque service a son propre schéma dans la même base PostgreSQL, et il est interdit par convention (et par les permissions SQL) d’accéder aux schémas voisins. On garde l’isolation logique sans la complexité opérationnelle. Ce n’est pas l’état final idéal mais c’est un bon point de départ, qu’on peut faire évoluer vers des bases physiquement séparées au moment où la charge le justifie.
Pour les services qui doivent partager une vue de données, deux patterns dominent. La base de lecture dédiée, alimentée par des événements (CQRS-light) : le service A publie des événements quand il modifie son état, le service B consomme ces événements et maintient une projection adaptée à ses besoins. Et la fédération API : un service A expose une API que les autres consomment quand ils ont besoin d’une partie de ses données, en mettant en cache côté consommateur si la latence le justifie.
API Gateway et service mesh
Quand on a vingt services, exposer chacun directement est ingérable. L’API Gateway est la façade unique : un seul point d’entrée pour les clients (web, mobile), qui route les requêtes vers le bon service interne, gère l’authentification, le rate limiting, le caching, la transformation de requêtes. Les options sérieuses en 2026 sont Kong (open-source, basé sur OpenResty), Traefik (excellent en environnement Kubernetes), Envoy (plus bas niveau, fondation de nombreux service meshes), et les solutions managées AWS API Gateway, Azure API Management, GCP API Gateway si on est dans un cloud public.
Pour la communication interne entre services, le service mesh ajoute une couche : Istio, Linkerd, Cilium injectent un proxy à côté de chaque service (pattern sidecar) qui gère mTLS, retry, circuit breaker, observabilité, sans toucher au code applicatif. Le service mesh est un investissement qui se justifie au-delà d’une trentaine de services. En dessous, on peut s’en passer en gérant ces préoccupations dans des bibliothèques partagées ou directement dans la passerelle.
Observabilité : la condition de survie
Un monolithe en production qui crashe laisse une seule stack trace. Vingt microservices qui dialoguent peuvent crasher de cinquante manières différentes, et reproduire le bug exige souvent de reconstruire la chronologie cross-services. Sans observabilité sérieuse, l’architecture devient ingérable au premier incident sévère. Les trois piliers à couvrir sont les logs structurés, les métriques, et le tracing distribué.
Pour les logs, la convention OpenTelemetry est devenue le standard. Chaque service émet des logs JSON enrichis d’un trace_id commun à une requête utilisateur, ce qui permet d’isoler dans Loki ou Elasticsearch tous les logs liés à une transaction. Pour les métriques, Prometheus est le defacto standard, avec Grafana en visualisation. Pour le tracing, Jaeger et Tempo dominent, alimentés par des SDK OpenTelemetry dans chaque service. La courbe d’adoption est progressive : on commence par les logs structurés (gain immédiat), on ajoute Prometheus quand les SLO se formalisent, on intègre le tracing quand les bugs deviennent transversaux.
Conteneurisation et orchestration
Docker reste l’unité de packaging par défaut pour les microservices. Chaque service a son Dockerfile, son image versionnée, son tag immuable. Pour orchestrer plusieurs services en développement local, docker-compose reste le plus simple : un fichier YAML décrit les services, leurs ports, leurs dépendances, et un docker compose up démarre tout le système. C’est l’outil idéal pour qu’un nouveau développeur puisse cloner le repo et tourner l’ensemble en cinq minutes.
En production, l’orchestration se fait avec Kubernetes pour la majorité des cas sérieux. Pour des déploiements plus modestes, des alternatives plus légères existent : k3s (distribution Kubernetes minimaliste qui tourne sur un VPS 4 Go), Nomad (HashiCorp, plus simple que Kubernetes), ou des PaaS managées comme Render, Fly.io, Railway ou Cloud Run qui abstraient toute la complexité. Le choix dépend du volume et de l’envie de gérer l’infrastructure : pour une équipe de moins de cinq développeurs sans expertise infra, une PaaS reste préférable.
Patterns essentiels à connaître
Cinq patterns reviennent dans la littérature et dans les architectures qui survivent. Le circuit breaker protège contre les cascades de pannes : si un service dépasse un seuil d’erreurs, on coupe les appels vers lui pendant un délai. Hystrix et Resilience4j (Java) ou Polly (.NET) implémentent ce pattern. Le retry avec backoff exponentiel rejoue les requêtes échouées avec un délai croissant — souvent intégré dans les bibliothèques HTTP modernes (axios-retry, ky, fetch-retry).
Le saga orchestre une transaction longue qui touche plusieurs services : si une étape échoue, on déclenche les compensations correspondantes pour annuler les précédentes. C’est la réponse aux transactions distribuées, qui sont impossibles à faire correctement de façon ACID en pratique. Le CQRS sépare les chemins écriture (Command) et lecture (Query), ce qui permet de scaler chaque côté indépendamment et d’optimiser les représentations. Enfin, l’event sourcing stocke les changements comme une séquence d’événements plutôt que comme un état courant — puissant mais lourd, à réserver aux domaines qui justifient l’effort (audit, finance, rétroactif).
CI/CD pour une architecture distribuée
Avec un monolithe, on a un pipeline CI : un build, des tests, un déploiement. Avec quinze services, on en a quinze, ou un seul pipeline qui orchestre. La pratique mainstream est intermédiaire : un pipeline par service (déclenché uniquement quand le service change), plus un pipeline intégration qui lance des tests cross-services après tout déploiement majeur. GitHub Actions, GitLab CI, CircleCI et Jenkins le supportent tous nativement.
Les patterns avancés qui font gagner du temps : le monorepo avec build incrémental (Turborepo, Nx, Bazel) détecte quels services sont impactés par un changement et ne reconstruit que ceux-là. Le déploiement progressif (canary, blue-green) réduit le risque en déployant d’abord sur un sous-ensemble du trafic. Les feature flags (LaunchDarkly, GrowthBook, Unleash) découplent la livraison technique de l’activation métier, ce qui permet de merger en main sans casser les utilisateurs.
Erreurs fréquentes à éviter
La première et plus coûteuse est de découper trop tôt. Trois services pour une équipe de quatre développeurs n’a aucun sens : on a triplé les préoccupations opérationnelles sans gain. Si l’équipe tient en deux pizzas, le monolithe modulaire reste supérieur. La deuxième est le mauvais découpage : choisir des services qui doivent toujours communiquer entre eux. Si A appelle B à chaque requête, ce sont deux services qui auraient dû n’en faire qu’un.
La troisième est de partager les contrats sans les versionner. Quand le service A change la structure de son événement, tous les consommateurs doivent être prévenus. Sans versionnement explicite (champ version dans l’événement, schema registry comme Confluent Schema Registry), une évolution casse la moitié de la plateforme en silence. La quatrième est de mettre la base de données du monolithe en commun : on garde tous les inconvénients (couplage), on perd les avantages (pas d’isolation réelle). La cinquième est de négliger l’observabilité jusqu’au premier incident sévère — c’est trop tard à ce moment-là.
Sécurité et secrets dans une architecture distribuée
Multiplier les services multiplie la surface d’attaque. Trois sujets sont à traiter en priorité. Le premier est la gestion des secrets : credentials de base, clés d’API, tokens de signature. Les stocker dans des variables d’environnement plain-text est tentant mais expose à tous les développeurs et à tous les logs accidentels. La pratique mainstream est un coffre-fort dédié : HashiCorp Vault pour le self-hosted, AWS Secrets Manager / GCP Secret Manager / Azure Key Vault pour le managé. Les secrets sont injectés au démarrage du conteneur via un sidecar ou un init-container, jamais écrits dans l’image.
Le deuxième est l’authentification entre services. Sans précaution, n’importe quel service compromis peut appeler n’importe quel autre. La parade est mTLS : chaque service présente un certificat client, le serveur le vérifie. Implémentation manuelle complexe, mais transparente avec un service mesh (Istio, Linkerd) qui injecte les certificats automatiquement. Le troisième est la séparation réseau : par défaut, un service ne devrait pas pouvoir joindre un autre s’il n’y a pas de raison fonctionnelle. Les NetworkPolicies Kubernetes ou les VPC peerings explicites réalisent cette segmentation.
Le vrai coût opérationnel
Le calcul de coût d’une architecture microservices est rarement honnête. Au-delà du coût d’infrastructure (qui peut être comparable au monolithe), il faut compter le coût humain : un ingénieur SRE à temps plein dès qu’on dépasse une dizaine de services, des heures supplémentaires de développement pour gérer la complexité distribuée, et la dette d’expertise sur des outils qu’une équipe doit apprendre. Sur un projet de taille moyenne, le coût total annuel d’une architecture microservices est typiquement 30 à 50 % supérieur à celui d’un monolithe équivalent en débit.
Ce surcoût n’est pas nécessairement un problème : il achète une vitesse de livraison, une résilience et une scalabilité que le monolithe ne pourrait pas atteindre. Mais c’est un investissement, pas une optimisation. La conversation à avoir avec la direction est explicite : microservices = +30 à +50 % de coût total contre +X % de vélocité et +Y % de disponibilité. Si X et Y sont insuffisants pour justifier le surcoût, le monolithe reste la bonne réponse.
Migrer progressivement, jamais d’un coup
La pire approche pour passer aux microservices est le big-bang : freezer le monolithe pendant six mois, le réécrire en N services, basculer un samedi soir. Cette voie a coulé plus de projets qu’elle n’en a sauvé. La voie qui marche est l’étranglement progressif formalisé par Martin Fowler comme Strangler Fig pattern : on identifie un module candidat (typiquement un domaine fonctionnel cohésif), on l’extrait en service distinct derrière un proxy qui route une partie du trafic, on vérifie en production que le nouveau service tient, puis on bascule complètement avant de retirer le code du monolithe.
Cette approche permet de continuer à livrer pendant la migration, de mesurer les gains à chaque étape, et de revenir en arrière si un service extrait s’avère une mauvaise idée. Le rythme réaliste est d’un service extrait par trimestre par équipe, ce qui veut dire qu’une migration complète prend deux à trois ans pour un système moyen. C’est aussi pour cela que beaucoup de projets s’arrêtent à une dizaine de services et restent en hybride monolithe-plus-quelques-services pendant longtemps.
Ressources officielles à consulter
- Microservices Resource Guide — articles fondateurs de Martin Fowler.
- Microsoft Azure Architecture Center — patterns et anti-patterns documentés.
- Documentation RabbitMQ
- Documentation Apache Kafka
- Documentation Kubernetes
- Documentation OpenTelemetry — standard de l’observabilité.
- Microservices.io — catalogue des patterns par Chris Richardson.
Questions fréquentes
À partir de quelle taille d’équipe les microservices ont-ils du sens ?
Pas avant douze développeurs sur le même code, idéalement quinze. En dessous, le coût de coordination du monolithe reste inférieur au coût opérationnel des microservices. Cette taille n’est pas une règle stricte mais un seuil où les frictions du monolithe deviennent visibles.
Microservices ou modulith ?
Le modulith est un monolithe avec des modules nettement séparés en interne (couplage faible, contrats explicites). Pour beaucoup de projets, c’est l’étape intermédiaire optimale : on garde la simplicité d’un seul déploiement tout en isolant le code suffisamment pour pouvoir extraire un service plus tard sans tout réécrire. Si on n’est pas sûr, modulith d’abord.
Faut-il un service mesh dès le début ?
Non. Pour moins de quinze services, gérer mTLS, retry et circuit breaker dans une bibliothèque partagée est plus simple et plus rapide. Un service mesh (Istio, Linkerd) devient utile au-delà, quand l’effort de maintenir cette bibliothèque dépasse l’effort de configurer le mesh.
Comment gérer les transactions qui touchent plusieurs services ?
Pas avec du 2PC distribué (qui ne marche pas en pratique). Avec des sagas : découper la transaction en étapes, chaque étape avec sa compensation. Si l’étape 4 échoue, on déclenche les compensations 3, 2, 1 dans l’ordre inverse. Les frameworks comme Temporal, Camunda ou Conductor implémentent ce pattern.
Quelle est la latence supplémentaire typique ?
5 à 20 ms par hop réseau interne en condition normale. Quatre services en série ajoutent 20 à 80 ms par requête. Pour les flux critiques en perf (panier, paiement), éviter les chaînes longues : préférer la composition côté API Gateway ou la matérialisation locale des données nécessaires.
Doit-on choisir un seul langage pour tous les services ?
Non, c’est même l’un des avantages avancés des microservices : chaque service peut choisir le langage adapté à son problème. En pratique, limiter à deux ou trois langages dans le portefeuille d’équipe — au-delà, le coût de maintenance des outils, des SDK et des images docker l’emporte sur les bénéfices.
Comment tester une architecture microservices ?
Trois niveaux. Tests unitaires sur chaque service (Vitest, Jest, JUnit selon le langage). Tests de contrat (Pact ou OpenAPI-driven) pour s’assurer qu’un service respecte le contrat attendu par ses consommateurs. Tests bout-en-bout limités aux parcours critiques, déclenchant la chaîne réelle dans un environnement reproduit avec docker-compose ou Kubernetes en namespace dédié.
Sur un angle proche
Si l’architecture distribuée est nouvelle pour vous, le bon ordre d’apprentissage est : maîtriser un monolithe modulaire bien testé avant de découper. Lire Building Microservices de Sam Newman pour la vue d’ensemble. Mettre en place l’observabilité avant le premier service extrait. Choisir une PaaS managée tant que l’équipe n’a pas l’expertise SRE en interne. Et enfin, mesurer régulièrement si la complexité opérationnelle introduite paie réellement les gains attendus — si la réponse est non au bout d’un an, le retour vers le modulith reste tout à fait honorable et plus fréquent qu’on ne le pense.