Written by:
Last Published:
20 octobre 2026
•
.webp)
La question du choix entre microservices et monolithe est généralement présentée comme un combat. Choisir un camp, le défendre, recruter en conséquence. C'est dans cette approche que naissent la plupart des erreurs coûteuses.
La réponse honnête se situe sur un spectre. À une extrémité, une application déployable unique. À l'autre, de nombreux services déployés indépendamment. Au milieu, le monolithe modulaire, qui reçoit bien moins d'attention qu'il ne le mérite. Votre position dépend d'une poignée de critères, dont la plupart n'ont que peu à voir avec la technologie.
Ce guide vous propose une matrice de décision, les modèles de défaillance qui apparaissent lorsque les équipes font les mauvais choix, une méthode pour passer d'une option à l'autre et un verdict pour les startups, les scale-ups et les grandes entreprises. Si vous avez déjà opté pour les microservices et que vous cherchez le « comment faire », notre guide sur les meilleures pratiques des microservices couvre le sujet. Celui-ci se concentre sur la décision elle-même.
Quelle est la réponse courte à la question microservices vs monolithe ?
Pour la plupart des nouveaux produits, commencez par un monolithe modulaire. N'extrayez un service que lorsque vous pouvez identifier un moteur concret : déploiement indépendant, profil de montée en charge divergent ou besoin d'isolation stricte. Assurez-vous d'être capable d'exploiter un système distribué avant d'en construire un. Évaluez votre propre situation avec la matrice de décision architecturale Imaginary Cloud ci-dessous.
Le débat revient sans cesse car il est coûteux de revenir sur une architecture et la plupart des équipes décident sans méthode structurée. Dans notre enquête auprès de plus de 100 responsables d'ingénierie à la QCon de Londres 2026, 75 % ont déclaré prendre des décisions d'architecture critiques sans cadre financier ou stratégique structuré. Ce chiffre additionne les trois réponses sans approche structurée : fondée sur la capacité (32 %), estimations informelles (29 %) et ad hoc (14 %).
Pour un PDG ou un directeur financier, les enjeux sont clairs. L'architecture détermine la vitesse de livraison, le coût de chaque version et le montant dépensé avant qu'une fonctionnalité ne génère des revenus. La même enquête a révélé que 43 % des répondants considèrent les systèmes monolithiques ou hérités comme le principal frein à leur capacité de mise à l'échelle, ce qui en fait le premier obstacle cité. Notez bien la formulation : il s'agit d'un constat sur des systèmes hérités négligés, et non d'un verdict sur tous les monolithes.
L'intérêt du public n'est pas plus stable. Il a tendance à connaître des pics, probablement lors de lancements, de conférences ou de publications techniques majeures, puis à s'estomper. L'urgence ne vient donc pas de la mode, mais de la décision elle-même, que tout produit en croissance doit prendre, ou revoir. Considérez-la comme une décision que vous serez amené à réévaluer.
Le véritable choix se situe sur un spectre composé de trois points : le monolithe classique (une base de code, un déploiement), le monolithe modulaire (un déploiement, des frontières internes strictes) et les microservices (de nombreux services déployés indépendamment). Chacun arbitre entre simplicité et indépendance. Le bon choix dépend de votre équipe, de la maturité de votre domaine et de vos capacités opérationnelles, et non de ce que font les géants de la technologie.
Imaginez la cuisine d'un restaurant. Un monolithe classique est une grande pièce avec un seul comptoir : tout le monde cuisine ensemble, et c'est merveilleusement rapide jusqu'à ce que la farine à pâtisserie finisse dans le poisson. Un monolithe modulaire est la même pièce avec des postes de travail bien définis (grill, froid, pâtisserie), chacun avec son propre réfrigérateur et une règle : personne ne touche au réfrigérateur d'un autre poste. Les microservices sont des stands de restauration séparés, chacun avec sa propre cuisine, son fournisseur et sa licence.
La rue des stands est-elle toujours préférable à la cuisine ? Non. Martin Fowler a observé que presque toutes les réussites en matière de microservices ont commencé par un monolithe devenu trop volumineux, tandis que les systèmes conçus dès le départ comme des microservices ont souvent rencontré de graves difficultés. Stefan Tilkov a soutenu le contraire: les composants d'un monolithe ont tendance à devenir si étroitement couplés qu'il est très difficile de les séparer par la suite. Tous deux ont raison sur un point, c'est pourquoi la décision nécessite des critères.
Sam Newman, auteur de l'ouvrage de référence sur la transition vers les microservices, a déclaré publiquement que ils ne devraient pas être le choix par défaut. La distribution est un coût que vous payez chaque jour ; vous devez donc avoir une raison concrète de l'assumer.
Évaluez votre situation selon huit critères, chacun favorisant un point différent du spectre. Si la plupart des réponses se situent dans une même colonne, c'est votre architecture de départ. Si elles sont dispersées, commencez par un monolithe modulaire et identifiez les candidats probables à une extraction.
Deux termes reviennent ci-dessous. L'observabilité est la capacité à comprendre ce qu'un système fait à partir des données qu'il émet (journaux, métriques et traces). L'ingénierie de plateforme consiste à créer les outils internes et les parcours standardisés qui permettent aux équipes produit de déployer et d'exécuter des services sans avoir à réinventer l'infrastructure à chaque fois.
| Critère | Monolithe classique | Monolithe modulaire | Microservices |
|---|---|---|---|
| Taille et structure de l'équipe | Une petite équipe partageant le même contexte | Plusieurs équipes capables de coordonner leurs releases | De nombreuses équipes ayant besoin de cadences de livraison distinctes |
| Déploiement indépendant | Inutile | Rarement nécessaire, un seul train de releases suffit | Exigence impérative pour au moins certains composants |
| Profil de montée en charge | Charge uniforme | Globalement uniforme, un ou deux points chauds | Composants aux besoins réellement différents |
| Maturité opérationnelle | Un CI/CD de base suffit | CI/CD solide et rigueur dans les tests | Observabilité poussée, automatisation et équipe plateforme |
| Isolation des pannes et de la conformité | Un seul domaine de défaillance est acceptable | Isolation gérée dans le code | Les pannes ou les données réglementées doivent être séparées physiquement |
| Clarté du domaine | Produit encore en phase de découverte | Frontières émergentes, pas encore éprouvées | Frontières stables et éprouvées en production |
| Délai de création de valeur | Le plus rapide pour une première version | Démarrage un peu plus lent, puis rapide | Démarrage le plus lent : l'outillage et la plateforme passent d'abord |
| Profil de coûts | Coûts de construction, d'exploitation et de personnel les plus bas | Coût d'exploitation faible, coût de discipline modéré | Coûts de construction, d'exploitation et de personnel les plus élevés, amortis là où l'indépendance compte |
Un mot de prudence concernant la taille des équipes. Les règles empiriques varient de moins de dix ingénieurs à moins d'une centaine, et elles se contredisent. Considérez-les comme des heuristiques. Ce qui compte vraiment, c'est de savoir si vos équipes peuvent publier indépendamment sans se gêner mutuellement, et si vous êtes en mesure d'exploiter un système distribué une fois que vous en avez un.
Les preuves sont mitigées, comme il se doit. Une comparaison empirique de 2026 d'une application e-commerce a montré qu'à 100 utilisateurs simultanés, la version microservices offrait un débit supérieur de 5,4 % et une latence p95 inférieure de 39 % à celle du monolithe, les deux étant à peu près équivalents à 50 utilisateurs. Les auteurs soulignent que les microservices introduisent des modes de défaillance propres à chaque service, et que les résultats valent pour ce seul déploiement. L'équipe Prime Video d'Amazon a déplacé une charge de travail de surveillance d'une conception distribuée sans serveur vers une application à processus unique et a rapporté une réduction de 90 % des coûts opérationnels, comme l'a rapporté InfoQ en 2023. Notez la portée : une seule charge de travail, pas une refonte à l'échelle de l'entreprise.
Cette démonstration est un exemple composite, pas une étude de cas client. Imaginez une plateforme B2B avec vingt ingénieurs répartis en trois équipes. Les déploiements sont hebdomadaires et se passent généralement bien. Un composant, une tâche de traitement de documents, connaît des pics importants à la fin du mois alors que tout le reste reste stable. L'équipe dispose d'un CI/CD solide mais d'une surveillance basique, et le domaine est encore en évolution.
Appliquez la matrice. La structure de l'équipe, le déploiement indépendant, la maturité opérationnelle et la clarté du domaine pointent tous vers un monolithe modulaire. Le profil de mise à l'échelle montre un point chaud, candidat à une extraction ultérieure. Le résultat est un monolithe modulaire pour le moment, avec le processeur de documents identifié comme premier candidat à l'extraction et des déclencheurs définis pour son déplacement, tels que des conflits de publication entre les équipes ou des coûts soutenus dus au surdimensionnement de l'ensemble de l'application.
Un monolithe modulaire est une application déployable unique organisée en modules bien définis avec des frontières strictes. Les modules communiquent via des interfaces explicites, jamais via les tables de base de données des autres. Vous conservez la simplicité d'un déploiement unique tout en gagnant une grande partie de la clarté des services, avec en prime une voie claire pour extraire un module plus tard si un besoin réel se présente.
Les frontières font tout le travail. Si les modules accèdent aux données des uns et des autres, vous avez un monolithe avec des noms de dossiers plus élégants, et il finira par se transformer en un enchevêtrement au fil du temps.
Pourquoi est-ce important pour la décision ? Parce que cela vous permet d'apprendre où se situent les jointures avant de payer pour les cimenter dans le réseau. Microservices.io est direct sur ce point : l'architecture monolithique n'est pas un anti-pattern, et si vous la dépassez, vous pouvez refactoriser progressivement en utilisant le pattern « strangler fig » (rediriger le trafic de l'ancien code vers de nouveaux composants petit à petit, jusqu'à ce que l'ancien code puisse être désactivé). Newman est allé plus loin, suggérant que de nombreuses organisations seraient mieux loties avec un monolithe modulaire qu'avec des microservices.
Ce n'est pas gratuit. Une base de code unique peut devenir lente à compiler et à tester, c'est pourquoi le couplage au moment de la construction nécessite une attention particulière lors de la conception à mesure que le système grandit.
Le coût ne se limite pas à la facture du cloud. Il faut prendre en compte cinq axes : l'infrastructure, les outils, les ressources humaines, le coût de coordination du changement et le coût du retard. Les microservices augmentent les trois premiers et peuvent réduire le quatrième. Un monolithe fait l'inverse. Le délai de mise sur le marché suit la même logique : le démarrage est plus rapide avec un monolithe et plus lent avec des microservices.
Seuls 11 % des dirigeants interrogés lors de notre enquête à la QCon de Londres ont cité le coût du cloud ou de l'infrastructure comme leur principal défi architectural. La majeure partie des coûts réside dans la structure : complexité, dette architecturale différée et ralentissement de la livraison. C'est pourquoi un modèle de coûts basé uniquement sur les frais d'hébergement est trompeur.
Le temps calendaire est la question qui préoccupe la direction. Dans notre retour d'expérience Sedna, l'approche par étapes (optimisation, projet pilote, migration) a pris environ six mois avec deux spécialistes intégrés. Planifiez par trimestres, pas par sprints, et prévoyez un point de contrôle « go/no-go » à chaque étape.
Nous avons délibérément évité d'attribuer des montants à cette matrice. Vos chiffres dépendent de votre charge, de votre équipe et de vos contrats fournisseurs. Modélisez-les dès le début, en incluant le service financier dans la discussion.
La plupart des expériences architecturales douloureuses découlent d'une poignée d'erreurs répétées. Les nommer aide à les identifier. Chaque modèle ci-dessous indique qu'une décision, ou son exécution, a dérapé.
Les services qui doivent être déployés ensemble constituent un monolithe avec un réseau au milieu. La règle empirique de Newman est facile à retenir : si vous avez besoin d'un responsable de coordination des mises en production à temps plein, vous en avez probablement un. Vous payez le coût opérationnel des microservices sans bénéficier d'aucune de leurs promesses d'indépendance.
Plusieurs services qui lisent et écrivent dans le même schéma sont couplés au niveau des données, quoi qu'en disent les diagrammes. Une seule migration bloque trois équipes. La solution est la responsabilisation : chaque service doit posséder ses propres données et les exposer via une interface.
Le service A appelle le B, qui appelle le C, qui appelle le D. Si D tombe, tout tombe, exactement comme dans un monolithe, mais en plus lent. Une revue systématique de la résilience dans les microservices énumère les coupables habituels : délais d'attente, pannes de dépendances et tempêtes de tentatives de reconnexion.
Découper par couche technique, avec un service front-end et un service back-end, crée du couplage au lieu de l'éliminer. Les frontières doivent suivre les capacités métier. Le Domain-Driven Design (une approche qui modélise le logiciel autour du domaine métier et définit les limites d'application de chaque modèle via des contextes bornés) est la boîte à outils classique, et les conseils de Microsoft sur définir les limites des microservices est un bon point de départ.
Cinquante micro-services sans traçage, sans automatisation et sans gestion d'astreinte, c'est la recette assurée pour des débogages laborieux et des mises en production encore plus lentes. Les microservices exigent des investissements dans l'observabilité et l'ingénierie de plateforme. Si vous ne pouvez pas financer cela, vous ne pouvez pas vous permettre cette architecture.
Si les limites des modules n'existent que dans une présentation, la base de code redeviendra silencieusement un plat de spaghettis. Appliquez ces limites grâce à des outils et à la revue de code, et traitez toute violation comme un défaut.
Déplacez un module à la fois. Placez une couche de routage devant le système, extrayez un seul module disposant d'un moteur concret, faites fonctionner l'ancien et le nouveau en parallèle, basculez le trafic progressivement et retirez l'ancien code. Considérez chaque étape comme un point de contrôle. Si les résultats ne sont pas probants, arrêtez-vous et laissez le module là où il est.
Les conseils prescriptifs d'AWS décrivent le modèle en trois étapes : transformer, coexister, éliminer. En pratique, cela se traduit comme suit :
La même approche fonctionne dans le sens inverse. Consolider des services trop fragmentés en un monolithe modulaire est une stratégie légitime, comme le montre l'exemple de Prime Video. Pour une vue d'ensemble sur le moment opportun pour migrer, refactoriser ou reconstruire, consultez notre guide sur la modernisation des systèmes existants.
Les conteneurs sont un choix de packaging, pas une architecture. Vous pouvez conteneuriser un monolithe, un monolithe modulaire ou une flotte de services. Ce que les microservices ajoutent, c'est le besoin d'orchestrer de nombreux conteneurs, ce qui nécessite des outils comme Kubernetes et une équipe dédiée à la plateforme. Notre guide sur ce qu'est Kubernetes couvre les différentes options d'orchestration.
Le serverless est une autre option, avec ses limites. Le retour d'expérience Sedna en souligne trois : une limite d'exécution de 15 minutes, les charges de travail à haut volume constant qui peuvent être moins coûteuses sur une infrastructure dédiée, et les processus fortement dépendants de l'état (stateful). Vérifiez votre charge de travail par rapport à ces critères avant de vous engager.
Les systèmes ont tendance à refléter les équipes qui les conçoivent, c'est ce qu'on appelle la loi de Conway. La note de Fowler à ce sujet lie les limites des services à la structure des équipes. Posez-vous donc d'abord la question organisationnelle. Vos équipes peuvent-elles gérer un segment de bout en bout, effectuer des déploiements sans demander d'autorisation et assurer leur propre astreinte ? Si ce n'est pas le cas, les services ne vous apporteront que davantage de réunions à travers le réseau, et non de l'indépendance.
Utilisez ceci comme point de départ, pas comme une règle absolue. La bonne réponse à la question « microservices ou monolithe » évolue avec votre croissance ; réévaluez donc votre position lorsque vos réponses à la matrice changent.
Optez pour un monolithe modulaire, ou un monolithe simple si l'équipe est restreinte et que le produit cherche encore son positionnement. La vitesse d'apprentissage prime sur l'évolutivité théorique. Réévaluez votre choix lorsque les équipes se bloquent mutuellement lors des déploiements, ou quand le profil de charge d'un composant diverge nettement des autres.
Le point de vue de la direction : se tromper coûte quelques trimestres de travail de refactorisation, tandis que des microservices prématurés vous coûtent une plateforme construite avant même d'avoir des clients.
Conservez le monolithe modulaire comme socle et extrayez les services de manière sélective, uniquement lorsqu'il existe un moteur concret : besoin de mise à l'échelle indépendante, autonomie d'une équipe ou cadence de déploiement différente. Extrayez un module, déployez-le en production, évaluez son coût, puis décidez de la suite.
Le point de vue de la direction : demandez systématiquement le moteur, le responsable et le retour sur investissement attendu pour chaque extraction, dans cet ordre.
Envisagez un portefeuille de solutions plutôt qu'une réponse unique. Les domaines aux frontières stables, dotés d'équipes autonomes et nécessitant une isolation forte, sont d'excellents candidats aux microservices. Pour d'autres, un monolithe modulaire ou un système existant bien entretenu reste préférable. Financez la plateforme en priorité.
Le point de vue de la direction : le plus grand risque est rarement l'architecture, mais le processus de décision. Alors que 75 % des organisations décident sans cadre structuré, formalisez la décision et ses déclencheurs.
Aucun de ces projets n'a été présenté comme un duel entre microservices et monolithe, et nous ne prétendons pas le contraire. Nous les citons pour illustrer les critères de notre matrice : coût, propriété, isolation et séquençage.
Sedna. Le retour d'expérience Sedna décrit une entreprise de communications maritimes qui a réduit de 80 % ses dépenses de licences fournisseur et d'infrastructure associée, en remplaçant Tray.io. La méthode importe plus que le chiffre. Des configurations de flux de travail volumineuses, hébergées par un fournisseur, ont été reconstruites sous forme de petites fonctions orchestrées par AWS Step Functions. Ce n'est pas une migration classique vers des microservices (il s'agit de fonctions serverless, et non de services persistants), mais la logique décisionnelle suit notre matrice. L'équipe a d'abord optimisé, testé avant de migrer, et maintenu l'ancienne plateforme en parallèle pendant deux semaines par mesure de sécurité.
TrustPortal. Le retour d'expérience TrustPortal fait état d'une réduction de 40 à 50 % des coûts opérationnels. La leçon la plus utile pour votre prise de décision est celle du refus. Selon ce retour d'expérience, un cœur de métier réglementé a été maintenu sur l'infrastructure existante pour des raisons de conformité et d'audit, environ 70 % du parc a migré vers le cloud, et l'ancien système a coexisté avec le nouveau durant la transition. C'est le spectre des solutions en action : une organisation, des réponses adaptées à chaque périmètre, chacune justifiée par le risque et un moteur concret.
Ce que ces deux exemples ont en commun, c'est l'ordre des opérations. Tous deux ont commencé par chiffrer le coût de l'installation actuelle, et tous deux ont fait fonctionner l'ancien et le nouveau système en parallèle avant de s'engager.
Aucune des deux options n'est meilleure dans l'absolu. Le choix entre microservices et monolithe dépend de la structure de votre équipe, de vos besoins en matière de mise à l'échelle, de votre maturité opérationnelle et de votre compréhension de votre domaine. Pour la plupart des nouveaux produits, il est judicieux de commencer par un monolithe ou un monolithe modulaire, en n'extrayant des services que lorsqu'un besoin concret se présente.
Un monolithe modulaire est une application déployable unique, divisée en modules bien définis avec des frontières strictes et des interfaces explicites. Il conserve un déploiement et une empreinte opérationnelle uniques tout en vous offrant la structure nécessaire pour extraire des services ultérieurement, si et quand un besoin concret apparaît.
Non. Le monolithe est un choix légitime, en particulier pour les produits en phase de démarrage et les petites équipes. Les problèmes surviennent lorsqu'il manque de structure interne, ou lorsque l'organisation se développe au point que le monolithe devient un frein, alourdissant les coûts de coordination. L'architecture n'est pas l'ennemie. C'est la complexité non maîtrisée qui l'est.
Généralement non. Une petite équipe qui partage le même contexte et effectue des déploiements groupés tire peu d'avantages d'un déploiement indépendant, tout en supportant le coût opérationnel complet d'un système distribué. Commencez par un monolithe modulaire, maintenez des frontières propres et n'extrayez un service que lorsque les déploiements commencent à entrer en conflit ou que le profil de charge d'un composant diverge radicalement.
Recherchez des symptômes concrets : des équipes qui bloquent les déploiements des autres, des mises en production nécessitant des réunions de coordination, un composant ayant des besoins de mise à l'échelle très différents des autres, ou des exigences d'isolation pour des raisons de sécurité ou de conformité des données. Un vague sentiment d'inconfort n'est pas un signe. Si vous ne pouvez pas nommer le facteur déclencheur, commencez par renforcer les frontières de vos modules.
Cela dépend de la charge de travail. Les appels en mémoire évitent la latence et les défaillances réseau, ce qui favorise le monolithe pour une logique très interactive. La mise à l'échelle indépendante peut favoriser les services en cas de charge lourde et inégale. Une étude empirique de 2026 a montré que les microservices maintenaient un meilleur débit sous charge, tandis que Prime Video a réduit ses coûts en déplaçant un pipeline vers un processus unique.
Attendez-vous à des coûts plus élevés en termes d'infrastructure, d'outillage et de ressources humaines avec les microservices, compensés uniquement là où la mise à l'échelle ou le déploiement indépendant créent de la valeur. Prenez en compte cinq axes : l'infrastructure, l'outillage, les personnes, le coût de coordination des changements et le coût du retard. Il n'existe pas de chiffre unique honnête, car la réponse dépend de votre charge, de votre équipe et de vos contrats.
Déplacez un module à la fois en utilisant le modèle « strangler fig ». Acheminez le trafic via une façade, extrayez un module avec un facteur déclencheur clair, exécutez l'ancien et le nouveau système en parallèle, basculez le trafic progressivement et retirez l'ancien code. Optimisez d'abord ce que vous avez, et prévoyez une étape de validation après le projet pilote.
Un monolithe distribué est un système déployé sous forme de services séparés qui restent étroitement couplés. Les services doivent être déployés ensemble, partagent des bases de données ou dépendent de longues chaînes d'appels synchrones. Il supporte le coût opérationnel des microservices sans bénéficier de leur indépendance, ce qui explique pourquoi on le qualifie souvent du pire des deux mondes.
La question des microservices face au monolithe n'a jamais vraiment consisté à choisir un camp. Il s'agit de déterminer le niveau d'indépendance dont vous avez besoin, la complexité que vous pouvez gérer et la qualité de votre compréhension de votre propre domaine. Évaluez-vous selon la matrice, commencez là où les réponses vous mènent et gardez la possibilité d'évoluer.
Deux points à retenir. Privilégiez par défaut l'architecture la plus simple qui répond à vos contraintes réelles, et faites en sorte que chaque service supplémentaire justifie sa place par un facteur déclencheur concret. Et si vous avez déjà choisi les microservices, l'étape suivante consiste à bien les mettre en œuvre, ce que notre guide sur les bonnes pratiques en matière de microservices couvre.
Vous devez prendre une décision architecturale ? Notre équipe peut vous aider à appliquer la matrice de décision architecturale d'Imaginary Cloud à votre produit, vos équipes et vos contraintes. Discutons de conseil en architecture.
Alexandra Mendes est Senior Growth Specialist chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction sur le développement logiciel, l'IA et la transformation numérique. Après avoir suivi une formation en développement frontend, Alexandra a acquis des compétences pratiques en programmation et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la manière dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
.webp)
