TL;DR — privilégier le monolithe modulaire par défaut
Le débat architectural des années 2016–2020 — "les monolithes sont morts, les microservices sont l'avenir" — a été largement corrigé par une expérience opérationnelle difficile. Voici la version courte :
- Monolithe modulaire par défaut. Des modules propres, des limites de domaine appliquées, une seule pipeline de déploiement. C'est le bon point de départ pour la grande majorité des applications web, y compris les SaaS B2B, les marketplaces et les portails d'entreprise.
- Extraire des services quand vous avez une raison concrète. Des profils de mise à l'échelle différents, des cadences de déploiement indépendantes, ou des limites de propriété d'équipe qu'un monolithe ne peut pas exprimer clairement. Pas avant.
- Les microservices complets ont du sens à grande échelle. Pensez à 20+ ingénieurs, 10 millions+ de requêtes par jour, et des SLA de service genuinement divergents. En dessous de ce seuil, la surcharge est une taxe pure sur la vélocité de votre équipe.
- Un monolithe simple n'est pas honteux. Shopify, Stack Overflow et Basecamp ont généré des milliards de dollars de revenus avec des monolithes bien réglés. L'architecture n'est erronée que si elle vous empêche de faire quelque chose que vous devez faire.
Les trois options définies
Monolithe traditionnel
Une application déployable unique où toute la logique métier, l'accès aux données et la présentation vivent dans une seule base de code et un seul processus. Chaque fonctionnalité est livrée ensemble ; la base de données est partagée ; la mise à l'échelle signifie exécuter plus de copies de l'ensemble de l'application. L'application Rails classique, le projet Django ou le service Spring Boot est un monolithe.
Monolithe modulaire
Toujours un binaire déployable unique, mais le code est partitionné en modules bien définis — chacun possédant sa logique de domaine, son espace de noms de schéma de base de données et son interface publique. Les modules communiquent via des API en cours de processus ou des contrats de messages, pas des appels HTTP. Le résultat est une base de code qui se déploie simplement mais est structurée pour permettre une extraction future. C'est l'architecture que nous utilisons en premier pour les engagements de développement d'applications web pour nos clients aux États-Unis et en Europe.
Microservices
Une collection de services déployables indépendamment, chacun responsable d'un domaine étroit, communiquant via HTTP ou un message broker (Kafka, RabbitMQ, SQS). Chaque service a sa propre base de données, sa propre pipeline CI/CD et son propre footprint opérationnel. Bien fait, cela permet aux grandes organisations de livrer rapidement sans se gêner mutuellement. Fait prématurément, c'est un monolithe distribué avec tous les inconvénients des deux mondes et aucun des avantages de l'un ou de l'autre.
Ce qu'un monolithe moderne peut vraiment faire
Le récit selon lequel "monolithe équivaut à héritage" est un artefact marketing de l'ère Kubernetes. Soyons précis sur ce que les monolithes modernes peuvent et ne peuvent pas faire.
Ils évoluent horizontalement
Exécuter quatre copies d'une application Rails ou Django derrière un répartiteur de charge, c'est de la mise à l'échelle horizontale. Cela fonctionne jusqu'à ce que votre base de données devienne le goulot d'étranglement — à quel moment vous ajoutez des réplicas en lecture et du regroupement de connexions, pas nécessairement un nouveau service. Stack Overflow sert des milliards de pages vues sur neuf serveurs sur site. Le goulot d'étranglement n'était jamais le monolithe ; c'était le manque de cache, d'indexation et de discipline des requêtes.
Ils supportent une itération rapide
Un monolithe a une seule pipeline de déploiement. Un seul ensemble de tests d'intégration. Un seul endroit pour chercher un bug. Pour une équipe de 3 à 15 ingénieurs, c'est un avantage de coordination massif. Chaque système distribué que vous ajoutez multiplie les modes d'échec que vous devez surveiller et les scénarios de rollback que vous devez pratiquer.
Ils supportent les limites de conformité
La résidence des données RGPD, les journaux d'audit HIPAA et les contrôles SOC 2 sont plus faciles à implémenter dans une seule application qu'à appliquer sur un réseau de services. Une seule piste d'audit, un seul store de secrets, un seul point de terminaison TLS. Voir les modèles que nous utilisons dans comment construire un SaaS multi-tenant — la multi-location est pleinement réalisable dans un monolithe modulaire.
Là où les monolithes luttent vraiment
Il y a de vraies limitations. Si votre service de paiement doit gérer 50x le trafic de votre module de reporting, la mise à l'échelle de l'application entière gaspille des ressources. Si votre pipeline d'inférence ML a des exigences d'exécution complètement différentes (GPU, Python, cadence de déploiement différente), le garder dans le même processus est gênant. Ce sont les bonnes raisons d'extraire un service — pas la mode d'ingénierie.
Quand les microservices sont vraiment rentables
Il existe des scénarios où les microservices sont la bonne réponse. Voici comment les reconnaître.
Profils de mise à l'échelle genuinement différents
Si votre moteur de recommandation de produits reçoit 1 000 requêtes par seconde en heure de pointe tandis que votre API de paramètres utilisateur en reçoit 5, il n'a pas de sens de les mettre à l'échelle ensemble. Une fois que vous pouvez quantifier cette divergence en production — pas dans une session de tableau blanc — l'extraction de service s'autofinance. En rapport : voir la pile d'agents IA d'entreprise 2026 pour savoir pourquoi les charges de travail intensives en inférence justifient souvent l'isolation pour exactement cette raison.
Cadences de déploiement indépendantes
Lorsque des équipes produit séparées doivent livrer plusieurs fois par jour sans coordination, une seule pipeline de déploiement devient un goulot d'étranglement. C'est la motivation originelle d'Amazon pour les microservices — non pas la performance, mais la vélocité organisationnelle. Si votre équipe analytics et votre équipe facturation attendent que le code de l'autre soit stable avant une mise en production, l'architecture crée un problème de coordination humaine qu'une limite de service résoudrait.
Domaines de faute isolés
Un bug catastrophique dans un monolithe fait tomber toute l'application. Dans une architecture microservices, un bug dans votre service de notification n'a pas à faire tomber le paiement. Les disjoncteurs, les cloisons et la dégradation gracieuse sont des patterns qui n'ont de sens que lorsque vous avez des limites de service pour les appliquer. Pour les flux à forte valeur — paiements, API principale, authentification — la garantie d'isolation vaut le coût opérationnel.
Limites réglementaires et de résidence des données
Une entreprise américaine servant des clients européens sous le RGPD peut genuinement avoir besoin que les données résidentes en Europe soient traitées dans un service séparément déployé et audité, pas seulement un indicateur de configuration dans une application partagée. Idem pour l'isolation de périmètre PCI DSS — les données de titulaires de carte traitées dans un service séparé avec sa propre limite réseau sont architecturalement plus propres que de réduire la surface d'attaque d'un monolithe.
Coûts, taille d'équipe et charge opérationnelle
Les microservices ne sont pas gratuits. Chaque service que vous ajoutez multiplie le coût d'infrastructure et de personnel. Voici un bilan honnête.
Coût d'infrastructure
Chaque service a besoin de son propre : calcul (conteneur, Lambda ou VM), base de données ou espace de noms de base de données, intégration du gestionnaire de secrets, règle de routage du répartiteur de charge ou de la passerelle API, entrée de pipeline d'agrégation de logs, et moniteur de vérification de l'état. Pour une architecture à dix services, vous en exploitez dix de chaque. Sur AWS ou GCP, un monolithe modulaire coûte souvent 60 à 80 % moins en infrastructure mensuelle qu'un réseau de microservices équivalent gérant le même trafic.
Coût d'observabilité
Un monolithe échoue avec une trace de pile dans un seul flux de logs. Un système distribué échoue avec des traces partielles réparties sur cinq services, deux files d'attente asynchrones et une couche de cache. Le traçage distribué (Jaeger, Tempo, AWS X-Ray), l'agrégation de logs structurés (Loki, Datadog, CloudWatch) et les tableaux de bord de santé des services sont obligatoires, pas optionnels. Prévoyez un ingénieur de plateforme dédié plus 2 000 à 8 000 USD/mois en outillage SaaS pour une équipe exploitant 10+ services.
Exigences en taille d'équipe
La règle des deux pizzas d'Amazon (6 à 10 ingénieurs par service) est le minimum opérationnel pour que chaque service soit maintenu sans changement de contexte constant. En dessous de 20 à 30 ingénieurs au total, les microservices signifient que chaque ingénieur possède plusieurs services — exactement la surcharge de coordination que l'architecture était censée supprimer. Voir aussi le playbook de réduction du taux d'attrition SaaS pour la façon dont les décisions architecturales en amont affectent la fiabilité du produit qui stimule la rétention.
| Dimension | Monolithe | Monolithe modulaire | Microservices |
|---|---|---|---|
| Complexité de déploiement | Faible | Faible | Élevée |
| Coût d'infrastructure (même trafic) | Le plus bas | Le plus bas | 2–5x plus élevé |
| Surcharge d'observabilité | Minimale | Minimale | Significative |
| Évolutivité horizontale | Granularité grossière | Granularité grossière | Granularité fine |
| Déploiements d'équipes indépendants | Non | Partiel | Oui |
| Équipe min. pour bien fonctionner | 3–5 ingénieurs | 5–15 ingénieurs | 20+ ingénieurs |
| Délai avant premier déploiement en production | 1–2 semaines | 1–3 semaines | 4–8 semaines |
Faire évoluer une application web correctement
Avant de choisir une architecture basée sur une échelle future que vous n'avez pas encore, appliquez ces leviers de mise à l'échelle dans l'ordre — la plupart des applications n'ont jamais besoin d'aller au-delà de l'étape trois.
1. Mise à l'échelle verticale et optimisation des requêtes
Doublez la taille de votre instance de base de données. Ajoutez un index à la requête lente. Activez le regroupement de connexions (PgBouncer, RDS Proxy). C'est de l'ingénierie gratuite ou presque gratuite qui achète couramment 5 à 10 fois de marge de capacité. La plupart des applications qui "ont besoin de microservices pour la mise à l'échelle" ont en réalité besoin d'un index de base de données et d'un cache Redis.
2. Mise à l'échelle horizontale de l'application
Exécutez plusieurs instances de votre monolithe derrière un répartiteur de charge. Ajoutez des réplicas en lecture pour les charges de travail intensives en lecture. Utilisez un CDN pour décharger les assets statiques et les réponses API en cache. Un seul processus Rails ou Node.js à 4 vCPU gère ~500 requêtes/seconde. Huit instances derrière un répartiteur de charge en gèrent 4 000. Vous atteignez ce plafond lentement.
3. Cache et file d'attente asynchrone
Redis ou Memcached devant vos chemins de lecture chauds. Une file d'attente de jobs en arrière-plan (Sidekiq, Celery, Bull) pour tout ce qui n'a pas besoin d'être synchrone — e-mails, webhooks, génération de rapports, appels d'API tierces. Le déchargement du travail asynchrone élimine une classe de latence de queue de requête lente qui rend votre p95 terrible sans aucun changement architectural réel.
4. Extraire un service à la fois
Lorsqu'un chemin chaud spécifique est genuinement un goulot d'étranglement et que les étapes ci-dessus sont épuisées, extrayez ce service en utilisant le pattern strangler fig. Routez le nouveau trafic vers le service tandis que le monolithe gère le reste. Migrez incrementalement. N'essayez pas une réécriture big bang du monolithe vers les microservices — le taux d'échec est élevé et le coût est énorme.
Matrice de décision
Utilisez cette matrice lorsque vous prenez la décision architecturale. Notez chaque ligne pour votre situation actuelle — pas pour l'entreprise que vous aspirez à être dans trois ans.
| Critère | Choisir le monolithe modulaire si… | Envisager les microservices si… |
|---|---|---|
| Taille d'équipe | Moins de 20 ingénieurs | 20+ ingénieurs sur plusieurs équipes produit |
| Modèle de trafic | Uniforme ou faible volume aujourd'hui | Charges de pointe mesurées et divergentes par domaine |
| Cadence de déploiement | Une ou deux équipes, mises en production coordonnées | Plusieurs équipes, cadences indépendantes requises |
| Isolation de conformité | RGPD/SOC 2 standard gérable dans une application | Périmètre PCI DSS titulaire de carte ou résidence stricte des données |
| Maturité DevOps | Pas d'ingénieur de plateforme dédié | Équipe Platform/SRE déjà en place |
| Mix technologique | Un langage/runtime principal | Besoin réel de runtimes mixtes (ex. service ML GPU) |
| Exigence de tolérance aux pannes | Interruption totale acceptable pour les incidents rares | Dégradation partielle requise (le paiement doit survivre à une panne analytics) |
FAQ
Une start-up devrait-elle utiliser des microservices ?
Presque jamais au début. Les microservices multiplient la surface opérationnelle — la découverte de services, le traçage distribué, les pipelines CI/CD indépendants et une équipe suffisamment grande pour gérer chaque service. La contrainte d'une start-up est de livrer le produit et d'apprendre rapidement, pas la flexibilité d'infrastructure. Commencez avec un monolithe modulaire ; extrayez des services lorsqu'une limite concrète de mise à l'échelle ou de propriété vous y oblige.
Qu'est-ce qu'un monolithe modulaire ?
Un monolithe modulaire est une application déployable unique, divisée en interne en modules bien définis et faiblement couplés — chacun possédant sa propre logique de domaine, son espace de noms de schéma de base de données et sa surface d'API publique. Il se déploie comme un seul processus mais est structuré pour que les modules individuels puissent être extraits en services séparés plus tard avec un refactoring minimal. C'est le juste milieu pour la plupart des équipes de moins de 50 ingénieurs.
Quand les microservices sont-ils rentables ?
Les microservices sont rentables lorsque : (1) différentes parties du système ont genuinement des profils de mise à l'échelle différents — le paiement gère 10 fois la charge de l'admin ; (2) des équipes indépendantes doivent déployer sans coordonner les mises en production ; (3) un service spécifique nécessite une pile technologique, un SLA ou une limite de conformité différente. Si aucune de ces conditions n'est vraie aujourd'hui, la surcharge des microservices est un coût pur.
Les microservices sont-ils plus évolutifs qu'un monolithe ?
Pas automatiquement. Un monolithe bien réglé sur une infrastructure cloud moderne gère des millions de requêtes par jour avec une mise à l'échelle horizontale, le regroupement de connexions et des réplicas en lecture. Les microservices permettent une mise à l'échelle fine des chemins chauds — mais cet avantage ne se matérialise que lorsque différents services ont genuinement des formes de trafic différentes. De nombreuses équipes ajoutent la complexité des microservices avant d'avoir le trafic qui le justifierait.
Quelle doit être la taille de l'équipe pour faire fonctionner des microservices ?
La règle des deux pizzas d'Amazon est un guide utile : chaque service doit être gérable par une équipe de 6 à 10 ingénieurs. En pratique, vous avez besoin d'au moins un ingénieur DevOps ou plateforme dédié, d'une couverture SRE, d'outils d'observabilité et de suffisamment de développeurs pour maintenir chaque service sans changement de contexte constant. En dessous de 20 à 30 ingénieurs au total, les microservices créent généralement plus de surcharge de coordination qu'ils n'en suppriment.
Puis-je migrer d'un monolithe vers des microservices plus tard ?
Oui — et c'est la voie recommandée. Construisez un monolithe modulaire avec des limites de domaine propres dès le début, et l'extraction d'un service plus tard est un effort contenu : déplacez le code d'un module, divisez ses tables de base de données et ajoutez un contrat d'API. Le pattern strangler fig — routant le trafic incrementalement vers un nouveau service tandis que le monolithe gère le reste — est éprouvé pour cette migration. Ne concevez pas pour les microservices dès le premier jour, sauf si vous avez déjà l'équipe et le trafic qui l'exigent.
Dernière mise à jour le 4 juin 2026. Les recommandations architecturales sont basées sur des engagements en production livrés pour des clients américains et européens entre 2022 et 2026. Les chiffres de coût sont des estimations ; les dépenses d'infrastructure réelles varient selon le fournisseur cloud, la région et la forme du trafic.
