Monolith vs Microservices : comment choisir votre architecture en 2026

Pendant la majeure partie d'une decennie, la sagesse conventionnelle en architecture logicielle etait simple : les microservices sont l'avenir, et les monolithes sont du passe. Si vous demarriez un nouveau projet, vous construisiez des microservices. Si vous aviez un monolithe existant, vous planifiez sa decomposition. La question n'etait pas de savoir s'il fallait adopter les microservices, mais a quelle vitesse vous pouviez y arriver.

Ce consensus est mort. Les trois dernieres annees ont produit une vague de retours d'experience d'equipes qui ont adopte les microservices trop tot, trop agressivement ou pour les mauvaises raisons. L'equipe Amazon Prime Video a publie une etude de cas montrant que le passage des microservices serverless a un monolithe a reduit les couts de 90 %. InnoGames a rapporte avoir reduit de moitie la complexite de l'infrastructure en regroupant les microservices dans un monolithe. Ces histoires ne sont pas des anomalies - elles sont la pointe avancee d'une correction.

Cet article n'est pas un argument pour une architecture plutot qu'une autre. C'est un cadre de decision pour choisir entre elles, ecrit pour 2026, avec le recul d'avoir observe un cycle complet de hype et desillusion. A la fin, vous saurez exactement quelles questions poser avant de choisir votre prochaine architecture.

Le pendule est revenu en arriere

La promesse originale des microservices etait seduisante : deployabilite independante, autonomie des equipes, piles technologiques polyglottes et scalabilite horizontale. Chaque service pouvait etre developpe, teste et deploye par une petite equipe sans se coordonner avec personne. Si un service tombait en panne, il ne ferait pas tomber tout le systeme. Si un service devait monter en charge, vous scaliez uniquement ce service.

Ces avantages sont reels, mais ils ont un prix qui a ete systematiquement sous-estime pendant les annees de hype. Chaque microservice introduit de la latence reseau, de la complexite de systeme distribue, des defis de coherence des donnees et des frais operationnels. Un monolithe a un pipeline de deploiement, une application a surveiller, une base de donnees a gerer et une codebase a naviguer. Dix microservices ont dix de tout, multiplie par les points d'integration entre eux.

L'intuition fondamentale que l'industrie a redécouverte est que les microservices sont un cout, pas un benefice. Ils sont un outil pour gerer des contraintes specifiques - taille de l'equipe, exigences de passage a l'echelle, frequence de deploiement - pas un etat final auquel tout systeme devrait aspirer. Si vous n'avez pas le probleme que les microservices resolvent, ils n'amelioreront pas votre systeme. Ils le rendront plus couteux et plus difficile a modifier.

Les microservices sont une bonne solution a un ensemble specifique de problemes. Si vous n'avez pas ces problemes, vous payez le cout des microservices sans en tirer le benefice. L'architecture la plus couteuse est celle qui resout des problemes que vous n'avez pas.

Le paysage de 2026 reflete cette correction. Les architectures de microservices pures sont desormais concentrees dans les organisations qui en ont reellement besoin - les grandes structures d'ingenierie avec des dizaines d'equipes, les plateformes qui necessitent une mise a l'echelle independante de differents composants, et les produits ou differents services ont des exigences fondamentalement differentes en matiere de fiabilite ou de latence. Partout ailleurs, les equipes choisissent des architectures plus simples et reservent les microservices aux cas specifiques qui les exigent.

Quand le monolithe gagne

Un monolithe est le choix par defaut correct pour la plupart des projets. Ce n'est pas une declaration controversee parmi les architectes experimentes, mais cela contredit le message que de nombreux developpeurs ont absorbe pendant le cycle de hype des microservices. Le monolithe gagne dans plus de scenarios qu'il ne perd, et la cle est de savoir quels sont ces scenarios.

La taille de l'equipe est le predicteur le plus fort du succes architectural. Si votre equipe a moins de dix developpeurs, un monolithe est presque certainement le bon choix. Avec une petite equipe, la charge de coordination des microservices - aligner les limites des services, gerer les contrats inter-services, maintenir de multiples pipelines de deploiement - consomme une fraction significative de votre capacite d'ingenierie disponible. Chaque limite de service que vous creez est un contrat que vous devez maintenir, et la maintenance de contrats est un travail qui ne livre pas de fonctionnalites.

Le stade de la startup est un autre signal clair. Si votre produit a moins de deux ans ou si votre modele economique est encore en evolution, un monolithe preserve votre capacite a changer de direction rapidement. Les microservices verrouillent des hypotheses sur les limites du domaine que vous aurez presque certainement tort de faire la premiere annee. Un monolithe vous permet de refactoriser librement. Quand votre application entiere est une seule codebase, deplacer une fonctionnalite d'un module a un autre est une operation de refactoring. Quand votre application est dix services, deplacer une fonctionnalite necessite de modifier les interfaces de service, de mettre a jour les consommateurs, de coordonner les deploiements et de migrer les donnees.

# A quoi ressemble un deploiement monolithe simple en 2026
# Un seul Dockerfile, un seul service, zero orchestration

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/server.js"]

# Un seul docker-compose.yml pour toute la pile
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
  db:
    image: postgres:17
    volumes:
      - pgdata:/var/lib/postgresql/data

La simplicite operationnelle de cette configuration est difficile a surestimer. Un service a surveiller, un ensemble de logs a verifier, un deploiement a annuler. Un developpeur junior peut comprendre l'ensemble du pipeline de deploiement en un apres-midi. Quand quelque chose casse, il y a exactement un endroit ou chercher la cause. Cette simplicite n'est pas un luxe - c'est un avantage strategique qui se cumule avec le temps.

La complexite du domaine est un autre facteur qui pousse vers les monolithes. Paradoxalement, plus votre domaine est complexe, plus la decomposition prematuree en services est dangereuse. Si vous divisez un domaine complexe en services avant d'en comprendre les limites naturelles, vous creerez des services qui sont fortement couples de toutes les mauvaises manieres - des services qui ne peuvent pas etre deployes independamment car modifier l'un necessite de modifier l'autre, des services qui partagent des bases de donnees car les donnees ne se divisent pas proprement, des services qui doivent etre deployes de maniere synchrone car leurs contrats changent constamment.

Le monolithe modulaire : l'architecture que la plupart des equipes ne considerent jamais

Le choix binaire entre monolithe et microservices est une fausse dichotomie. Le monolithe modulaire occupe le terrain du milieu et est la bonne reponse pour plus d'equipes que l'un ou l'autre extreme. Un monolithe modulaire est une unite de deploiement unique avec des modules internes clairement definis qui suivent les memes regles de limite que les microservices, mais sans le reseau.

La difference cle entre un monolithe modulaire et un monolithe typique est la discipline. Dans un monolithe typique, les modules ne sont pas imposes - tout code peut importer tout autre code, et avec le temps les limites s'erodent en une boule de boue. Dans un monolithe modulaire, les modules ont des API publiques explicites et des implementations privees. Le module A ne peut interagir avec le module B que par l'interface definie de B. L'acces direct a la base de donnees entre modules est interdit. Les memes regles qui regissent la communication entre microservices s'appliquent, mais la communication se fait par appels de fonctions au lieu de requetes HTTP.

Cette approche vous donne la plupart des avantages des microservices - limites imposees, developpement independant dans les modules, contrats clairs - sans les couts operationnels. Vous obtenez un pipeline de deploiement, une application a surveiller et une codebase a naviguer. Mais vous obtenez aussi des limites de module qui empechent le probleme de la boule de boue et rendent l'extraction future vers des microservices simple.

// Une limite de monolithe modulaire en TypeScript
// Chaque module n'expose que son API publique

// modules/orders/public-api.ts
export {
  createOrder,
  getOrderById,
  getOrdersByUser,
  OrderService,
} from "./order-service";

// modules/orders/internal/  ← tout ici est prive
//   order-repository.ts
//   order-validator.ts
//   order-pricing.ts

// modules/payments/public-api.ts
export {
  processPayment,
  getPaymentStatus,
  refundPayment,
} from "./payment-service";

// La dependance inter-modules est explicite et verifiable
// payments/payment-service.ts importe depuis orders/public-api
import { getOrderById } from "../../orders/public-api";

Le monolithe modulaire est aussi la meilleure couverture contre un avenir incertain. Si vous construisez un monolithe modulaire et decouvrez plus tard qu'un module doit devenir un service independant, l'extraction est mecanique : vous copiez le code du module dans un nouveau service, exposez son API publique via HTTP ou une file d'attente de messages, et connectez l'appelant. Les limites du module existent deja. Les interfaces sont deja definies. Le travail difficile - comprendre les limites du domaine - est deja fait.

Si vous construisez un monolithe traditionnel sans limites de module et voulez plus tard extraire des services, vous faites face a un probleme bien plus difficile. Vous devez d'abord decouvrir ou les limites devraient etre, puis refactoriser le code pour les respecter, et seulement ensuite extraire. C'est pourquoi la plupart des migrations monolithe-vers-microservices echouent - les equipes sous-estiment le travail de decouverte des limites et se retrouvent avec des microservices couples d'une maniere qui contredit leur objectif.

• Monolithe modulaire : unite deployable unique, appels reseau remplaces par appels de fonctions, limites enforcees, chemin d'extraction facile.
• Monolithe traditionnel : unite deployable unique, aucune limite enforcee, liberte maximale dans les premieres etapes, chemin d'extraction penible.
• Microservices : nombreuses unites deployables, appels reseau pour la communication, limites de service enforcees, cout operationnel eleve.
• Le monolithe modulaire est generalement le meilleur point de depart car il preserve les options sans s'engager dans la complexite des systemes distribues.

Quand les microservices ont reellement du sens

Les microservices ne sont pas mauvais. Ils sont mauvais pour la plupart des equipes, mais il y a des scenarios ou le cout est justifie par le benefice. La cle est d'etre honnete sur le fait que votre scenario correspond reellement.

La mise a l'echelle independante est la raison la plus defendable pour les microservices. Si differentes parties de votre systeme ont des profils de mise a l'echelle radicalement differents - votre passerelle API doit gerer 100 000 requetes par seconde tandis que votre service de reporting gere 100 requetes par heure - les mettre dans la meme unite de deploiement gaspille des ressources. Le materiel du service de reporting reste inactif, et la mise a l'echelle automatique de la passerelle API est contrainte par le temps de demarrage a froid du service de reporting. Des services separes peuvent etre mis a l'echelle independamment, et les economies realisees par l'utilisation efficace des ressources peuvent compenser les frais operationnels.

L'autonomie des equipes est la deuxieme raison legitime. Quand vous avez plusieurs equipes travaillant sur le meme systeme, et que chaque equipe doit deployer independamment a son propre rythme, les microservices suppriment le goulot d'etranglement de la coordination. L'equipe A peut deployer son service trois fois par jour sans attendre que l'equipe B termine sa revue. Mais notez le seuil : cet argument ne s'applique que quand vous avez plusieurs equipes. Si votre organisation a dix developpeurs au total, vous n'avez pas de probleme de coordination que les microservices resoudraient. Vous avez un probleme de communication qu'un canal Slack partage peut resoudre.

Des exigences differentes de fiabilite ou de latence justifient aussi les microservices. Si votre service de traitement des paiements necessite 99,999 % de disponibilite tandis que votre service d'analytique peut tolerer des indisponibilites occasionnelles, les separer garantit qu'un bug dans le reporting analytique n'empeche pas les clients de finaliser leurs achats. De meme, si une partie de votre systeme necessite une latence extremement faible et une autre peut tolerer une latence plus elevee, les separer vous permet d'optimiser chacune independamment.

La diversite technologique est l'argument le plus faible pour les microservices. Oui, les microservices vous permettent d'utiliser differents langages et bases de donnees pour differents services. Mais en pratique, la plupart des organisations convergent de toute facon vers un petit ensemble de technologies, et le cout operationnel de la maintenance de plusieurs environnements d'execution depasse generalement le benefice. Si toute votre equipe connait TypeScript et PostgreSQL, construire un service en Rust et un autre en Go juste pour utiliser une technologie differente est un luxe que la plupart des organisations ne peuvent pas se permettre.

Le modele commencer par un monolithe, extraire les services

Le modele le plus fiable pour construire des systemes logiciels en 2026 est aussi le plus simple : commencer par un monolithe modulaire, puis extraire les services quand vous avez la preuve que vous en avez besoin. On l'appelle parfois le modele monolithe-d'abord ou extraction-de-microservices, et il est devenu la recommandation par defaut des organisations qui ont traverse le cycle de hype des microservices et y ont survecu.

Le modele fonctionne en quatre phases. La phase un est le monolithe modulaire. Vous construisez votre application entiere comme une seule unite deployable avec des limites de module strictes. Chaque module possede ses donnees, expose une API publique et garde son implementation privee. Vous utilisez la meme discipline que vous utiliseriez pour les microservices - contrats clairs, propriete des donnees separee, dependances explicites - mais tout s'execute dans un seul processus.

La phase deux est la mesure. Vous surveillez quels modules changent le plus frequemment, quelles equipes travaillent sur quels modules, et quels modules ont des exigences differentes de mise a l'echelle ou de fiabilite. Vous n'extrayez pas de services sur la base de l'intuition ou de la speculation. Vous les extrayez sur la base de donnees - des preuves reelles que le monolithe cree un goulot d'etranglement qu'une limite de service resoudrait.

La phase trois est l'extraction. Vous prenez un module qui a prouve qu'il doit etre un service - parce que sa frequence de changement provoque trop de deploiements du monolithe, ou parce que ses exigences de mise a l'echelle sont differentes du reste du systeme - et vous l'extrayez. Comme le module a deja des limites propres, l'extraction est mecanique. Vous creez un nouveau service avec son propre pipeline de deploiement, exposez l'API publique du module via HTTP ou une file d'attente de messages, et mettez a jour le monolithe pour appeler le nouveau service au lieu du module directement.

// Etape 1 : Definir le candidat a l'extraction comme module
// monolith/src/modules/reports/public-api.ts
export async function generateReport(
  reportId: string
): Promise<ReportResult> {
  // Detail d'implementation : interroge une replica read-only separee,
  // prend 30 secondes, ne devrait pas bloquer l'application principale
}

// Etape 2 : Quand la preuve montre que cela doit etre un service :
// 1. Creer un nouveau service a partir du code du module
// 2. Exposer la meme API via HTTP
// 3. Remplacer l'appel direct par un client de service

// monolith/src/clients/reporting-service.ts
const client = new ServiceClient({
  name: "reporting",
  baseUrl: process.env.REPORTING_SERVICE_URL,
  timeout: 60000, // Ce service est lent
});

export async function generateReport(reportId: string) {
  return client.post("/reports", { reportId });
}

// Le monolithe n'a pas besoin d'etre re-deploye — le client gere
// les tentatives, les timeouts et le circuit breaking en interne.

La phase quatre est la repetition. Au fur et a mesure que le systeme grandit, vous repetez le cycle - mesurer, extraire, mesurer a nouveau. Certains services que vous extrayez peuvent necessiter d'etre extraits davantage en services plus petits. Certains peuvent devoir etre reintegres dans le monolithe si l'extraction n'a pas apporte de valeur. La cle est que chaque extraction est motivee par des preuves, pas par un dogme architectural.

Ce modele a un avantage critique sur l'approche microservices-d'abord : il reporte les decisions irreversibles. Chaque limite de service que vous creez est un engagement irreversible envers la complexite des systemes distribues. Une fois qu'un service existe, vous ne pouvez pas facilement modifier ses limites sans casser les clients. En commencant par un monolithe et en extrayant seulement quand necessaire, vous vous assurez que chaque limite de service est justifiee par des exigences reelles plutot que par des speculations sur les besoins futurs.

Comment choisir : un cadre de decision

Quand vous concevez un nouveau systeme ou evaluez votre architecture actuelle, parcourez ces questions dans l'ordre. Les reponses vous orienteront vers la bonne architecture sans vous obliger a predire l'avenir.

Premiere question : combien de developpeurs travaillent sur ce systeme ? Si la reponse est moins de dix, commencez par un monolithe - de preference modulaire. Vous n'avez pas de probleme de coordination que les microservices resoudraient, et vous ne pouvez pas vous permettre les frais operationnels. Si la reponse est plus de dix, la reponse depend de leur organisation. S'ils travaillent en une seule equipe, un monolithe fonctionne toujours. S'ils sont organises en plusieurs equipes autonomes, les microservices peuvent meriter d'etre consideres.

Deuxieme question : votre systeme a-t-il des composants avec des profils de mise a l'echelle fondamentalement differents ? Si chaque partie de votre systeme doit monter en charge approximativement au meme rythme, il n'y a aucun avantage a les separer. Si un composant doit gerer dix mille requetes par seconde tandis qu'un autre en gere dix, separez-les - mais commencez par separer uniquement le composant a haute echelle dans son propre service, pas tout le systeme.

Troisieme question : pouvez-vous deployer toutes les parties de votre systeme selon le meme calendrier ? Si oui, un monolithe simplifie votre pipeline de deploiement et reduit le cout de coordination. Si non - parce que differentes parties du systeme ont des cycles de publication, des exigences reglementaires ou des profils de risque differents - les microservices permettent a chaque partie de suivre son propre rythme de deploiement.

Quatrieme question : que se passerait-il si chaque partie de votre systeme tombait en panne en meme temps ? Si la reponse est que votre entreprise s'arrete completement, vous ne gagnez pas en resilience avec les microservices - vous en payez juste le cout. La veritable resilience necessite non seulement des services separes, mais des infrastructures separees, des stockages de donnees separes et une degradation gracieuse entre les services. La plupart des equipes ne construisent pas cela. Elles construisent des services qui sont fortement couples dans le deploiement et faiblement couples en theorie, ce qui est le pire des deux mondes.

La meilleure architecture est celle que votre equipe peut deployer en toute confiance, deboguer rapidement et modifier sans crainte. Quelle qu'elle soit pour votre organisation specifique - monolithe, monolithe modulaire ou microservices - c'est la bonne reponse. Tout le reste est de la mode architecturale deguisee en principe d'ingenierie.

Cinquieme question : a quel point etes-vous certain de vos limites de domaine ? Si vous construisez dans un domaine bien compris avec des modèles etablis - commerce electronique, gestion de contenu, facturation - vos limites de domaine sont relativement stables, et les microservices sont moins risques. Si vous construisez dans un domaine nouveau ou les limites emergent encore, un monolithe preserve votre capacite a refactoriser a mesure que votre comprehension evolue. Des limites de service prematures deviennent des contraintes qui ralentissent exactement le processus d'apprentissage que vous devez mener.

La reponse honnete pour la plupart des equipes en 2026 est un monolithe modulaire. Il vous donne la discipline des microservices sans le cout operationnel. Il preserve l'option d'extraire des services plus tard sans vous obliger a vous engager dans la complexite des systemes distribues aujourd'hui. Il est deployable par un seul developpeur, debuggable avec un seul flux de logs, et modifiable avec une seule pull request. Et si votre systeme grandit au point ou un monolithe ne fonctionne plus, les limites modulaires que vous avez construites rendront la transition vers les microservices plus fluide que vous ne l'imaginez.

Le pendule de l'architecture est revenu vers la simplicite. Ce n'est pas une regression. C'est l'industrie qui apprend de l'experience. Les equipes qui ont ignore le hype - ou qui s'en sont remises rapidement - sont celles qui livrent des fonctionnalites, pas celles qui migrent des services. Choisissez l'architecture qui vous permet de livrer, et changez-la seulement quand votre systeme vous dit qu'elle doit changer.