Reboot Germany

Microservices contre monolithe : quand la refonte vaut le coup

Par Tobias Massow 31 mars 2026 8 min de lecture

42 pour cent des entreprises ayant adopté les microservices regroupent à nouveau leurs services en unités plus vastes. Amazon Prime Video a réduit de 90 pour cent ses coûts d’infrastructure en revenant au monolithe. L’adoption des service mesh est passée de 18 à 8 pour cent en deux ans. Les microservices ne sont pas un échec. Mais la recommandation générale d’atomiser systématiquement toute application en microservices, si. En 2026, c’est l’année de la décision différenciée : monolithe, monolithe modulaire ou microservices – selon la taille des équipes, les besoins de montée en charge et la maturité opérationnelle.

L’essentiel

42 pour cent regroupent à nouveau leurs services : Selon l’enquête CNCF 2025, 42 pour cent des utilisateurs de microservices ont regroupé leurs services. Principales raisons : complexité du débogage, surcharge opérationnelle et latence réseau.
Amazon Prime Video : une réduction de 90 pour cent des coûts d’infrastructure grâce à la migration depuis une architecture distribuée de microservices vers un monolithe mono-processus pour le service d’analyse de qualité vidéo.
Coûts d’infrastructure 3,75 à 6 fois plus élevés pour les microservices qu’un monolithe équivalent en fonctionnalités. Monolithe entreprise : environ 15 000 euros par mois contre 40 000 à 65 000 euros pour une architecture microservices.
Le monolithe modulaire comme voie intermédiaire : les modules communiquent via des interfaces définies, utilisent des schémas de base de données séparés et peuvent être extraits en services autonomes si nécessaire. Une rigueur architecturale sans surcharge opérationnelle.
Règle de décision : moins de 100 développeurs = monolithe modulaire. Plus de 100 développeurs avec des besoins de montée en charge indépendants = microservices. Moins de 10 = monolithe classique.

La désillusion microservices : ce que révèlent les données

La vague microservices des années 2010 reposait sur une promesse simple : découpez votre application en petits services indépendants et gagnez en rapidité, en évolutivité et en autonomie des équipes. Netflix, Amazon et Google en avaient donné l’exemple. Des milliers d’entreprises les ont suivis.

Dix ans plus tard, les faits montrent que cette promesse tient – mais uniquement dans certaines conditions. L’enquête CNCF 2025 documente ce mouvement inverse : 42 pour cent des organisations ayant adopté les microservices regroupent à nouveau leurs services. Pas un retour au monolithe des années 2000, mais vers des unités de déploiement plus vastes et mieux délimitées.

Les symptômes qui conduisent à ce regroupement sont les suivants : le débogage à travers les frontières de services est exponentiellement plus difficile qu’au sein d’un seul processus. Chaque appel réseau entre services constitue un point de défaillance potentiel. Et la surcharge opérationnelle liée à des dizaines, voire à des centaines de services exige une équipe Platform Engineering, dont beaucoup de PME ne disposent pas.

CNCF Survey 2025

42 %

des utilisateurs de microservices regroupent à nouveau leurs services

Source : Enquête Cloud Native de la CNCF, 2025

Amazon Prime Video : l’étude de cas qui a tout changé

En mai 2023, l’équipe d’Amazon Prime Video a publié une analyse architecturale qui a secoué la communauté cloud. Le service d’analyse de qualité vidéo était conçu comme une architecture distribuée de microservices reposant sur AWS Step Functions et Lambda. Les coûts étaient prohibitifs, la montée en charge limitée.

La solution ? Une migration vers un monolithe mono-processus. Le résultat : une réduction de 90 pour cent des coûts d’infrastructure et une meilleure capacité à monter en charge. La raison ? Ce service n’avait aucun besoin réel de montée en charge indépendante de ses composants. Toutes ses parties traitaient le même flux vidéo. L’architecture microservices engendrait un surcoût réseau et une complexité d’orchestration sans valeur ajoutée.

La leçon n’est pas que les microservices sont mauvais. La leçon est que les microservices résolvent un problème spécifique (montée en charge et déploiement indépendants par des équipes autonomes). Si ce problème n’existe pas, ils ne font que générer des coûts.

La vérité des coûts : monolithe contre microservices

Les chiffres sont sans équivoque. Les infrastructures microservices coûtent de 3,75 à 6 fois plus cher qu’un monolithe équivalent. À l’échelle entreprise, cela signifie : un monolithe à environ 15 000 euros par mois, contre une architecture microservices équivalente à 40 000 à 65 000 euros, une fois inclus les coûts d’infrastructure, d’exploitation, des équipes Platform et de la surcharge de coordination.

L’effort humain amplifie encore cette différence. Un monolithe modulaire nécessite 1 à 2 ingénieurs opérationnels. Une architecture microservices équivalente requiert 2 à 4 ingénieurs Platform, auxquels s’ajoute une surcharge opérationnelle répartie sur les équipes produit. Avec des salaires annuels de 140 000 à 180 000 euros pour les ingénieurs Platform (rapports salariaux DevOps 2025), les coûts humains représentent une part plus importante de la différence que les coûts d’infrastructure.

Pour les entreprises DACH comptant de 10 à 50 développeurs, le calcul est clair : un monolithe modulaire offre 90 pour cent des avantages architecturaux à une fraction des coûts. Les microservices ne deviennent rentables que lorsque la loi de Conway impose l’architecture : lorsque la structure organisationnelle est si grande et fragmentée que les équipes doivent déployer de façon autonome.

// Propos

90 pour cent des architectures microservices sont encore déployées comme des monolithes. Les organisations ont découpé les services, mais pas leur pipeline de déploiement.

The New Stack · Why 90% of Microservices Still Ship Like Monoliths, 2025

Le monolithe modulaire : la réponse pragmatique

Le monolithe modulaire n’est pas un compromis. C’est une décision architecturale autonome. Dans un monolithe modulaire bien conçu, les modules communiquent via des interfaces définies, utilisent des schémas de base de données séparés au sein d’une même base de données, et peuvent être extraits en services autonomes si nécessaire.

La clé réside dans le « si nécessaire ». Plutôt que de tout découper prophylactiquement en services (et payer immédiatement la surcharge), le monolithe modulaire intègre dès le départ les limites entre modules, sans générer de surcharge réseau ni de complexité de déploiement. Si un module doit effectivement être mis à l’échelle de façon indépendante, il peut être extrait. Sinon, il reste intégré au monolithe.

Une revue systématique de la littérature présentée lors de la conférence ACM sur les tendances en architecture logicielle (2024) confirme : le monolithe modulaire n’est plus une niche, mais une architecture reconnue, située entre le monolithe classique et les microservices distribués. La combinaison d’une simplicité opérationnelle, d’une modularité et d’une maintenabilité correspond exactement au « sweet spot » pour les entreprises comptant de 10 à 100 développeurs.

La matrice décisionnelle : quelle architecture quand ?

Monolithe classique : moins de 10 développeurs. MVP, prototype ou première version produit. La vitesse prime sur l’architecture. C’est la voie la plus rapide vers le product-market fit. Le refactoring viendra plus tard, une fois identifié ce qui fonctionne.

Monolithe modulaire : de 10 à 100 développeurs. De plusieurs milliers à plusieurs millions d’utilisateurs (pas des milliards). Moins de 5 ingénieurs Platform. Priorité : efficacité économique et rapidité de développement. L’architecture de référence pour le moyen secteur DACH.

Microservices : plus de 100 développeurs confrontés à des problèmes liés à la loi de Conway. Montée en charge indépendante véritablement nécessaire (le service de paiement nécessite 50 fois plus de puissance de calcul que les autres services). Exigences polyglottes (modèles ML en Python, cœur métier en Java). L’isolement réglementaire impose une séparation physique (conformité PCI pour le traitement des paiements).

La décision la plus fréquemment erronée : des entreprises de 20 développeurs adoptent les microservices parce que Netflix le fait. Netflix emploie 10 000 développeurs. La complexité organisationnelle que les microservices résolvent n’existe pas chez 20 développeurs. Le résultat ? Un « monolithe distribué ». Tous les inconvénients des deux mondes, aucun avantage.

Fazit

Le débat monolithe contre microservices n’est plus, en 2026, une question idéologique. C’est une décision pragmatique fondée sur la taille des équipes, les besoins de montée en charge et la maturité opérationnelle. 42 pour cent regroupent à nouveau leurs services. Amazon économise 90 pour cent avec un monolithe. Les coûts des microservices sont de 3,75 à 6 fois supérieurs à ceux d’un monolithe. Pour le moyen secteur DACH, le monolithe modulaire est l’architecture adaptée dans 90 pour cent des cas : une rigueur architecturale sans la surcharge opérationnelle des systèmes distribués. La question n’est pas « monolithe ou microservices ». La question est : quel problème précis cette architecture résout-elle ? Si la réponse est « autonomie des équipes avec 200 développeurs », les microservices sont pertinents. Si la réponse est « nous voulons paraître modernes », cela coûtera cher.

Questions fréquentes

Les microservices ont-ils échoué ?

Non. Les microservices résolvent un problème réel : la montée en charge et le déploiement indépendants au sein de grandes équipes autonomes. Ce qui a échoué, c’est la recommandation générale d’atomiser systématiquement chaque application en microservices. 42 pour cent regroupent leurs services parce qu’ils ont compris que la surcharge dépasse les avantages dès lors que le problème sous-jacent n’existe pas.

Qu’est-ce qu’un monolithe distribué ?

Une architecture qui ressemble aux microservices (de nombreux services, communication réseau), mais fonctionne comme un monolithe : tous les services doivent être déployés ensemble, partagent des données et ne peuvent pas être mis à l’échelle de façon indépendante. C’est le scénario du pire cas d’une migration microservices mal planifiée : plus de complexité, sans l’autonomie promise.

Comment savoir si mon monolithe devient trop volumineux ?

Trois signaux d’alerte : premièrement, des conflits de déploiement – les équipes se bloquent mutuellement lors des mises en production. Deuxièmement, des temps de construction dépassant 15 minutes. Troisièmement, une modification dans le module A fait échouer les tests du module B, alors que ces modules devraient théoriquement être indépendants. Ce sont des signaux d’absence de limites claires entre modules, pas nécessairement un impératif de basculer vers les microservices.

Comment migrer des microservices vers un monolithe modulaire ?

Progressivement, pas en mode « Big Bang ». Identifiez les services qui sont toujours déployés ensemble et qui n’ont pas besoin de montée en charge indépendante. Ces services sont regroupés en modules au sein d’une base de code commune. La communication passe de HTTP/gRPC à des appels intra-processus. Les bases de données sont consolidées, mais conservent des schémas séparés. Trois à cinq services sont consolidés par trimestre.

Quel langage convient le mieux à un monolithe modulaire ?

Java (avec Spring Modulith), .NET (avec les principes du Domain-Driven Design) et Go (avec une structure de packages claire) bénéficient du meilleur soutien outillé. Depuis 2024, Spring Modulith propose des vérifications explicites des limites entre modules et une communication inter-modules basée sur les événements. Dans .NET, l’approche Vertical Slice Architecture est privilégiée. Node.js/TypeScript est possible, mais l’isolement des modules exige davantage de discipline.