# Microservices : les vérités qu'on ne vous dit pas avant de migrer

> Microservices : coûts cachés, latence, cohérence éventuelle, patterns de survie et checklist de maturité 2026 pour choisir entre monolithe et distribué.

- Date : 2025-09-20
- Lecture : 8 min
- Catégorie : devsecops
- Tags : Microservices, Monolithe modulaire, Architecture distribuée, Saga, Circuit Breaker, Service mesh, Kubernetes, Migration
- URL : https://www.adservio.fr/insights/articles/microservices-les-verites-qu-on-ne-vous-dit-pas

## L'essentiel

- La majorité des équipes n'ont pas besoin de microservices : en dessous de 15 développeurs, d'un déploiement par semaine ou de 1000 RPS, un monolithe bien fait reste supérieur.
- En 2026, l'industrie est sortie de l'ère du « micro-everything » : le monolithe modulaire est redevenu une architecture de référence assumée.
- Les microservices apportent des coûts cachés bien réels : complexité opérationnelle multipliée, latence réseau à chaque appel et cohérence éventuelle à la place des transactions ACID.
- Des patterns éprouvés, Saga, Circuit Breaker, API Gateway, Database per Service, et le service mesh sans sidecar rendent cette complexité gérable, à condition d'une vraie maturité.
- La migration doit être incrémentale, service par service en commençant par le plus indépendant, jamais un big bang qui découpe tout le monolithe d'un coup.

## La vérité inconfortable : vous n'avez probablement pas besoin de microservices

Les microservices sont vendus comme LA solution à tous les problèmes de scalabilité et d'organisation. La réalité ? Ils créent autant de problèmes qu'ils en résolvent, et l'industrie a mis dix ans à l'admettre publiquement. En 2026, le consensus a changé : l'ère du « micro-everything » est derrière nous, le monolithe modulaire est redevenu une architecture de référence parfaitement assumée, et la vraie question n'est plus « comment découper » mais « faut-il découper ».

### Les signaux qui plaident pour le monolithe

Plusieurs signaux indiquent que vous devriez rester monolithe : une équipe de moins de 15 développeurs, moins d'un déploiement par semaine, un trafic inférieur à 1000 requêtes par seconde, un budget infrastructure limité ou l'absence d'expertise DevOps/SRE en interne. Dans ces contextes, la règle empirique reste implacable : un monolithe bien structuré, modulaire et testé bat systématiquement des microservices mal faits, avec une fraction du coût d'exploitation et de la charge cognitive.

Ce recadrage n'est pas un retour en arrière : c'est la reconnaissance que le coût d'exploitation d'un système distribué, astreintes, observabilité, orchestration, sécurité inter-services, se paie chaque mois, que la valeur soit au rendez-vous ou non. Les équipes qui ont découpé trop tôt passent leur temps à opérer de la plomberie distribuée au lieu de livrer du produit ; celles qui ont structuré un monolithe modulaire gardent l'option d'extraire plus tard, au moment où un besoin réel le justifie.

## Quand les microservices ont réellement du sens

Il existe pourtant des contextes où le découpage est le bon choix, à condition qu'il réponde à un problème constaté, pas à une mode. Deux patterns dominent les cas légitimes : le scaling différencié et l'autonomie des équipes.

### Scaling différencié par profil de charge

Quand les composants d'une application ont des profils de charge très différents, un monolithe force à scaler l'ensemble pour satisfaire le composant le plus sollicité. Exemple type en e-commerce : Search capte 80 % du trafic, la recommandation 14 %, le checkout 5 % et le paiement 1 %, mais le monolithe doit être répliqué en bloc, tout ou rien. En microservices, chaque service scale indépendamment : 50 pods pour Search, 5 pour la recommandation, 10 pour le checkout, 2 pour le paiement, avec un gain direct en efficacité d'infrastructure.

### Autonomie des équipes et cadences de déploiement

Quand des équipes ont des cadences radicalement différentes, les microservices leur donnent l'autonomie nécessaire : une équipe Finance qui déploie son service de facturation en Python une fois par semaine, une équipe Logistique qui déploie son service d'expédition en Go cinq fois par jour, une équipe Data qui livre ses pipelines analytiques une fois par mois. Chacune avance à son rythme, avec sa stack, sans bloquer les autres, c'est là que l'architecture distribuée apporte une vraie valeur organisationnelle, alignée sur la loi de Conway.

## Les coûts cachés : complexité opérationnelle, latence et cohérence

Un monolithe, c'est une application à déployer, une base de données à monitorer, un flux de logs et un debugging relativement simple. Vingt microservices, c'est vingt applications à déployer, quinze bases ou plus à surveiller, vingt flux de logs à corréler et un debugging qui exige du tracing distribué, aujourd'hui standardisé autour d'OpenTelemetry, pour reconstituer le parcours d'une requête à travers les services.

### De la latence mémoire à la latence réseau

Dans un monolithe, les appels entre composants se font en mémoire, quasiment gratuits : récupérer l'utilisateur, vérifier le stock et traiter le paiement prend de l'ordre de 10 ms au total. En microservices, chaque appel devient un appel réseau, 5 ms pour le service utilisateur, 8 ms pour l'inventaire, 12 ms pour le paiement, soit environ 30 ms, sans compter la variance de latence et les pannes réseau intermittentes qu'il faut désormais traiter comme des cas normaux.

Le troisième coût est le plus structurant : la perte des transactions ACID. Dans un monolithe, création de commande, mise à jour de stock et paiement tiennent dans une seule transaction, tout réussit ou tout est annulé. En microservices, la cohérence devient éventuelle : le service Order crée la commande, Inventory confirme le stock, mais Payment peut échouer, et il faut orchestrer soi-même le rollback entre plusieurs services indépendants.

S'y ajoute un coût rarement budgété : la charge cognitive. Chaque service supplémentaire apporte son dépôt, son pipeline, ses dashboards, ses versions de dépendances et ses conventions, et chaque développeur doit garder en tête une carte de plus en plus grande du système. C'est précisément ce que les plateformes internes cherchent à réduire, en standardisant les templates de services et en masquant l'infrastructure derrière des golden paths.

> À lire aussi : [Anti-patterns microservices : les pièges qui font échouer les migrations](https://www.adservio.fr/insights/articles/anti-patterns-microservices): Anti-patterns microservices : monolithe distribué, migration big bang, nano-services, timeouts, reporting direct, les pièges à détecter et les parades.

## Patterns de survie : Saga, Circuit Breaker et API Gateway

Le pattern Saga gère les transactions distribuées : une saga orchestrée exécute les étapes séquentiellement, créer la commande, réserver le stock, débiter le paiement, confirmer, et déclenche des transactions compensatoires en cas d'échec. Si le paiement échoue, on relâche le stock réservé et on annule la commande ; chaque étape a sa contrepartie qui défait ce qui a déjà été fait, rendant l'échec partiel gérable plutôt que catastrophique.

Le Circuit Breaker empêche les pannes de se propager : après un nombre défini d'échecs consécutifs, le circuit s'ouvre et les appels échouent immédiatement sans solliciter le service en difficulté, lui laissant le temps de récupérer. Après un délai, le circuit passe en mode semi-ouvert pour tester prudemment le retour à la normale. Sans ce pattern, la défaillance d'un seul service peut entraîner toute la chaîne d'appels dans une panne en cascade.

L'API Gateway fournit le point d'entrée unique : toutes les requêtes clientes transitent par une gateway qui gère l'authentification, le rate limiting et le load balancing avant de router vers le bon service, évitant que chaque client n'ait à connaître l'adresse et les règles de chaque service individuellement.

> À lire aussi : [Patterns microservices : bonnes pratiques d'architecture distribuée](https://www.adservio.fr/insights/articles/patterns-microservices-bonnes-pratiques): Patterns microservices éprouvés : découpage DDD, API contract-first, propriété des données, saga et outbox, observabilité OpenTelemetry, platform engineering.

## Communication entre services et service mesh sans sidecar

Trois options de communication dominent. REST/HTTP synchrone : simple et debuggable, mais source de couplage, de latence et de pannes en cascade. Message queue asynchrone : un service publie un événement, « commande créée »,sans savoir qui le consomme, ce qui apporte découplage et résilience au prix de la cohérence éventuelle. gRPC enfin : des contrats protobuf fortement typés, du code client et serveur généré, et des performances plusieurs fois supérieures à REST sur les appels internes à fort volume.

Le bon réflexe est de choisir l'asynchrone par défaut pour les flux métier qui tolèrent un délai, notifications, facturation, analytics, et de réserver le synchrone aux parcours où l'utilisateur attend une réponse immédiate. Ce simple arbitrage élimine une grande partie des pannes en cascade avant même d'avoir besoin d'un circuit breaker.

### Le service mesh en 2026 : ambient et eBPF

Le service mesh a changé de visage : le mode ambient d'Istio, sans sidecar, est devenu le modèle de déploiement recommandé, mTLS assuré au niveau L4 par un ztunnel par nœud, proxies waypoint L7 uniquement là où c'est nécessaire, pour une réduction de 60 à 70 % de la consommation de ressources par rapport aux sidecars classiques. En parallèle, Cilium et eBPF se sont imposés comme le standard du réseau cloud-native. Le mesh reste néanmoins un investissement sérieux : ne l'adoptez que lorsque le nombre de services le justifie.

## Données distribuées : Database per Service et ses conséquences

L'anti-pattern le plus répandu reste la base de données partagée : quand plusieurs services lisent et écrivent dans la même base, le schéma devient un couplage caché, impossible de scaler ou de déployer indépendamment, et les tables subissent la contention de services concurrents. C'est un monolithe distribué : tous les inconvénients des deux mondes, aucun des bénéfices.

Le pattern Database per Service donne à chaque service sa propre base, ce qui supprime le couplage par le schéma mais soulève de nouvelles questions : comment requêter à travers plusieurs services, gérer la duplication de données, garantir la cohérence entre bases ? Ces questions se répondent avec la composition d'API, les événements de domaine, le CQRS et les sagas, jamais avec des jointures SQL directes entre les bases des autres services.

Le pattern transactional outbox complète l'ensemble : plutôt que de publier un événement et d'écrire en base en deux opérations séparées, avec le risque qu'une seule des deux réussisse, le service écrit l'événement dans une table outbox au sein de la même transaction locale, et un relais le publie ensuite vers le broker. On obtient une publication fiable sans transaction distribuée, brique indispensable pour que sagas et projections restent cohérentes.

## Migrer sans big bang et vérifier votre maturité avant de sauter

« On découpe le monolithe en 20 microservices ce week-end » est la promesse la plus risquée qui soit : elle concentre tout le risque sur quelques jours, sans marge pour ajuster. La bonne approche est incrémentale, façon strangler fig : extraire un service à la fois en commençant par le plus indépendant. Séquencement réaliste, semaines 1 à 4, l'authentification (frontière claire, risque faible) ; semaines 5 à 8, les notifications (asynchrones, sans couplage fort) ; semaines 9 à 16, la facturation ; puis service par service en capitalisant sur chaque extraction.

### Checklist de maturité technique et organisationnelle

Avant de migrer, vérifiez vos capacités techniques : Kubernetes et conteneurs maîtrisés, CI/CD automatisé, observabilité distribuée basée sur OpenTelemetry avec un backend comme Grafana ou Datadog, service mesh ou équivalent, infrastructure as code. Et vos capacités organisationnelles : équipes autonomes cross-fonctionnelles, culture DevOps/SRE, astreinte établie, réponse à incident mature. Si moins de 70 % de ces cases sont cochées, restez monolithe ou investissez d'abord dans ces fondations.

La règle d'or n'a pas changé, et chez Adservio nous la défendons projet après projet : commencez monolithe, modulaire, bien découpé en domaines, et ne migrez vers les microservices que lorsque la douleur du monolithe dépasse durablement la complexité des microservices. Les microservices ne sont ni une solution magique ni un passage obligé pour scaler : ce sont un trade-off entre complexité et autonomie, rentable uniquement dans les contextes qui le justifient.

> À lire aussi : [Du monolithe aux microservices](https://www.adservio.fr/insights/articles/du-monolithe-aux-microservices): Monolithe ou microservices ? Comparatif des deux architectures, leurs forces, leurs pièges (dépendances circulaires, latence, tests) et les critères pour choisir sa trajectoire de modernisation.

## FAQ

### Comment savoir si mon organisation a réellement besoin de microservices ?

Plusieurs signaux indiquent qu'il vaut mieux rester monolithe : une équipe de moins de 15 développeurs, moins d'un déploiement par semaine, un trafic inférieur à 1000 RPS, un budget infrastructure limité ou l'absence d'expertise DevOps/SRE. La checklist de maturité recommande de rester monolithe si moins de 70 % des capacités techniques et organisationnelles requises sont en place.

### Quels sont les principaux coûts cachés des microservices ?

Trois coûts reviennent systématiquement : la complexité opérationnelle (des dizaines de services à déployer et monitorer, du tracing distribué indispensable au debugging), la latence réseau (chaque appel en mémoire devient un appel réseau de plusieurs millisecondes), et la perte de la cohérence ACID au profit d'une cohérence éventuelle qui impose de gérer soi-même les rollbacks entre services.

### Qu'est-ce que le monolithe modulaire et pourquoi revient-il en force ?

C'est un monolithe structuré en modules aux frontières explicites, alignés sur les domaines métier, déployé comme une seule unité. Il offre l'essentiel des bénéfices de découplage sans les coûts opérationnels du distribué, et sert de tremplin idéal : ses frontières internes deviennent les futures frontières de services si une extraction devient un jour nécessaire.

### Quel rôle joue le service mesh dans une architecture microservices en 2026 ?

Il prend en charge le mTLS, le routage, la résilience et l'observabilité du trafic inter-services. Le mode ambient d'Istio, sans sidecar, est devenu le modèle recommandé, avec une réduction de 60 à 70 % de la consommation de ressources, tandis que Cilium et eBPF se sont imposés pour le réseau cloud-native. Il ne se justifie toutefois qu'au-delà d'un certain nombre de services.

### Quelle est la bonne façon de migrer un monolithe vers les microservices ?

De façon incrémentale, jamais en big bang. On extrait un service à la fois selon le pattern strangler fig, en commençant par le plus indépendant et le mieux délimité (l'authentification, par exemple), puis on avance vers des services plus couplés sur plusieurs mois, en capitalisant sur l'expérience de chaque extraction.