---
term: 'Microservices vs. Monolithe'
seoTitle: 'Microservices vs. monolithe : quelle architecture et quand ?'
headline: 'Microservices vs. monolithe : quelle architecture, et quand ?'
slug: microservices-vs-monolithe
category: cloud-architecture
shortDefinition: "Un monolithe est une application déployée d'un seul bloc ; les microservices la découpent en petits services déployés indépendamment qui dialoguent via des API."
relatedTerms:
  - decoupled-architecture
  - serverless-architecture
  - api-gateway-architecture
  - event-driven-architecture
  - containerization
contrastsWith:
  - serverless-architecture
aboutTerms:
  - 'Microservices Architecture'
  - 'Monolithic Architecture'
  - 'Modular Monolith'
faq:
  - question: 'Lequel est le meilleur, les microservices ou le monolithe ?'
    answer: "Aucun des deux, universellement — ils optimisent des choses différentes. Le monolithe optimise la simplicité : un seul codebase, un seul déploiement, des appels in-process, de vraies transactions de base de données. Les microservices optimisent l'autonomie des équipes et la mise à l'échelle indépendante — au prix de la complexité des systèmes distribués. Les facteurs décisifs sont la taille de l'équipe, la stabilité du domaine et la maturité opérationnelle, pas la mode architecturale."
  - question: 'Une startup devrait-elle utiliser des microservices ?'
    answer: "Le consensus fort de l'industrie est non — commencez par un monolithe. L'argument canonique, tiré de l'essai MonolithFirst de Martin Fowler, observe que presque toutes les réussites en microservices ont commencé par un monolithe devenu trop gros, tandis que les systèmes conçus en microservices dès le départ peinent : vous finissez par tracer les frontières des services avant de comprendre le domaine, c'est-à-dire précisément au moment où vous allez les tracer de travers."
  - question: "Qu'est-ce qu'un monolithe modulaire ?"
    answer: "La troisième option, délibérément ennuyeuse : une seule application déployable avec des frontières internes de modules strictement appliquées. Elle conserve la simplicité opérationnelle du monolithe tout en construisant les coutures qui rendent un découpage futur possible — et c'est le choix par défaut recommandé par consensus pour la plupart des équipes, parce que des modules bien tracés peuvent être extraits en services plus tard, alors qu'un monolithe enchevêtré ne le peut pas."
  - question: "Qu'est-ce qu'un monolithe distribué ?"
    answer: "L'anti-pattern qui combine le pire des deux mondes : des services physiquement séparés qui doivent être modifiés et déployés ensemble — généralement parce que les frontières ont été mal tracées ou que les services partagent une base de données. Vous payez les coûts opérationnels des microservices (appels réseau, orchestration, observabilité) tout en gardant le couplage du monolithe. C'est le mode d'échec le plus courant du découpage prématuré."
  - question: 'Quand faut-il découper un monolithe en microservices ?'
    answer: "Quand la coordination des déploiements — pas la taille du code — devient le goulot d'étranglement : plusieurs équipes qui font la queue sur un seul train de releases, des composants aux besoins de mise à l'échelle réellement divergents et des frontières de domaine qui ont cessé de bouger. Seuils pratiques issus de l'expérience de l'industrie : en dessous d'une dizaine de développeurs, le monolithe a presque toujours raison ; le découpage commence à se rentabiliser à partir de quinze développeurs et plus répartis en plusieurs équipes."
  - question: 'Comment les microservices gèrent-ils la cohérence des données ?'
    answer: "Difficilement — c'est le coût le moins mis en avant. Chaque service possède sa base de données, si bien que la transaction ACID qui tenait en une ligne dans le monolithe devient une saga : une séquence de transactions locales avec des rollbacks compensatoires, qui converge vers une cohérence à terme. Les workflows qui ont réellement besoin de mises à jour atomiques entre services sont le signe que ces services n'auraient pas dû être séparés."
  - question: 'Quel rapport entre la loi de Conway et ce choix ?'
    answer: "Tout — les systèmes finissent par refléter la structure de communication des organisations qui les construisent. Les microservices fonctionnent quand de petites équipes autonomes possèdent chacune un service de bout en bout ; l'architecture est autant un organigramme qu'un schéma. Une seule petite équipe qui adopte les microservices hérite de la surcharge de coordination de plusieurs équipes sans en avoir plusieurs."
  - question: 'Des entreprises sont-elles revenues des microservices au monolithe ?'
    answer: "Oui, et les études de cas sont instructives. L'équipe monitoring d'une grande plateforme vidéo a, de façon célèbre, refusionné ses microservices serverless en un seul processus et réduit ses coûts d'infrastructure d'environ 90 % — le passage des données entre les briques était la dépense dominante. D'autres équipes d'ingénierie ont consolidé des centaines de microservices en un seul service, en invoquant une surcharge de tests et de dépendances. La leçon n'est pas « les microservices ont tort », mais que le découpage doit payer sa propre surcharge."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Microservices — Martin Fowler & James Lewis'
    url: 'https://martinfowler.com/articles/microservices.html'
  - name: 'MonolithFirst — Martin Fowler'
    url: 'https://martinfowler.com/bliki/MonolithFirst.html'
  - name: 'Microservices (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Microservices'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Dimensionnez votre backend correctement dès le premier jour'
  text: "Back4app fait de la voie médiane pragmatique le choix par défaut : un backend géré pour les fonctionnalités standard, des fonctions Cloud Code pour la logique métier — chaque fonction déployable indépendamment, sans service mesh, sans base de données par service et sans équipe d'ops."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-09'
translationKey: microservices-vs-monolith
---

**Un monolithe est une application déployée d'un seul bloc ; les microservices la découpent en petits services déployés indépendamment qui dialoguent via des API.** Le débat a l'air architectural, mais il est surtout organisationnel : la vraie question est de savoir si la structure de vos équipes, votre connaissance du domaine et votre maturité opérationnelle peuvent payer le découpage — parce que le découpage envoie toujours la facture.

## Points clés

| Question | Réponse |
| --- | --- |
| Monolithe | Un codebase, un déploiement, des appels in-process, une base de données |
| Microservices | Plusieurs services, des déploiements indépendants, des appels réseau, une base de données par service |
| La troisième option cachée | Le monolithe modulaire — une seule unité de déploiement, des frontières internes appliquées |
| Le choix par défaut consensuel | Commencez monolithique ; découpez quand la coordination des déploiements fait mal, pas avant |
| Le piège | Le monolithe distribué — les coûts des microservices avec le couplage du monolithe |

## La différence en un exemple de code

Dans un monolithe, appeler un autre module est un appel de fonction — rapide, atomique, et incapable d'échouer à moitié :

```javascript
// Monolithe : appel in-process — une transaction, un domaine de panne
const receipt = await billing.chargeOrder(order.id);

// Microservices : le même appel traverse le réseau — et vous héritez
// des timeouts, des retries, des pannes partielles et de la cohérence à terme
const res = await fetch('https://billing.internal/charge', {
  method: 'POST',
  body: JSON.stringify({ orderId: order.id }),
  signal: AbortSignal.timeout(3000),   // et si billing est lent ?
});
if (!res.ok) await compensateOrder(order.id); // et s'il a réussi à moitié ?
```

Toute la douleur des microservices tient dans ces trois dernières lignes. La voie médiane gérée garde la logique sur mesure déployable indépendamment *sans* vous refiler la gestion des pannes — une fonction s'appelle comme un service, mais s'exécute sur une infrastructure gérée par la plateforme :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One deployable unit of business logic, no service mesh required
const receipt = await Parse.Cloud.run('chargeOrder', { orderId: 'ord_481' });
console.log(`Charged: ${receipt.status}`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('chargeOrder');
final response =
    await function.execute(parameters: {'orderId': 'ord_481'});
if (response.success) {
  print('Charged: ${response.result['status']}');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("chargeOrder",
                        parameters: ["orderId": "ord_481"]) { result in
  if case .success(let receipt) = result {
    print("Charged: \(receipt)")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("orderId" to "ord_481")
ParseCloud.callFunctionInBackground<Map<String, Any>>("chargeOrder", params) { receipt, e ->
  if (e == null) Log.d("Billing", "Charged: ${receipt["status"]}")
}
```

## Trois formes, pas deux

```mermaid
flowchart LR
  accTitle: Monolithe, monolithe modulaire et microservices
  accDescr: Un monolithe est une application dont le code est enchevêtré ; un monolithe modulaire est une seule unité de déploiement avec des frontières internes de modules appliquées ; les microservices sont des unités de déploiement séparées qui communiquent via un réseau.
  subgraph M["Monolithe"]
    m1["Une app<br/>modules enchevêtrés"]
  end
  subgraph MM["Monolithe modulaire"]
    mm1["Une unité de déploiement<br/>frontières strictes entre modules"]
  end
  subgraph MS["Microservices"]
    s1["Service A"] <-->|réseau| s2["Service B"]
    s2 <-->|réseau| s3["Service C"]
  end
  M --> MM --> MS
```

L'[article canonique sur les microservices](https://martinfowler.com/articles/microservices.html) décrit la destination ; [MonolithFirst](https://martinfowler.com/bliki/MonolithFirst.html) décrit la route : presque tous les systèmes de microservices réussis ont commencé par un monolithe devenu trop gros, et le monolithe modulaire est la façon de garder l'option ouverte — les frontières d'abord, le réseau ensuite, et seulement là où il est mérité.

## Microservices vs. monolithe : les différences pratiques

| Dimension | Monolithe | Microservices |
| --- | --- | --- |
| Déploiement | Une unité, un train de releases | Indépendant, par service |
| Mise à l'échelle | Toute l'app monte en charge ensemble | Par service, là où la charge se trouve vraiment |
| Appels entre les parties | In-process, nanosecondes | Réseau, millisecondes + modes de panne |
| Cohérence des données | Transactions ACID | Sagas et cohérence à terme |
| Isolation des pannes | Un bug peut tout faire tomber | Pannes contenues — si l'architecture le prévoit |
| Où vit la complexité | Dans le code | Dans l'exploitation |
| Taille d'équipe adaptée | Une équipe, jusqu'à ~10 devs | Plusieurs équipes autonomes |
| Débugging | Une stack trace | Tracing distribué entre services |
| Profil de coût | Un runtime, bon marché | Infra par service + observabilité + équipe plateforme |

La ligne la plus tranchante de ce tableau est *où vit la complexité* : découper un système ne supprime pas la complexité — il la déplace du codebase vers le réseau, le pipeline de déploiement et le dashboard de 3 h du matin.

## Les deux sens de l'histoire des migrations

Le sens célèbre : une grande plateforme de streaming vidéo a passé des années à découper son monolithe en plus d'un millier de services, pour résoudre un problème de mise à l'échelle qu'elle avait réellement. Le sens inverse est plus récent et tout aussi instructif : la même industrie a produit un service de monitoring qui a refusionné ses microservices serverless en un seul processus et **réduit ses coûts d'infrastructure d'environ 90 %** — déplacer les données entre les briques était la dépense dominante — et des équipes d'ingénierie qui ont consolidé plus d'une centaine de services en un seul, en invoquant des suites de tests et une gestion des dépendances devenues ingérables. Les deux sens étaient rationnels : la constante, c'est que l'architecture a suivi le problème *mesuré*, pas la tendance.

## Cas d'usage courants

- **Monolithe :** nouveaux produits, petites équipes, domaines encore flous — partout où la vitesse d'apprentissage l'emporte sur la théorie de la mise à l'échelle.
- **Monolithe modulaire :** produits en croissance qui veulent des options futures sans surcharge présente ; le choix par défaut qui mérite d'être défendu.
- **Microservices :** de nombreuses équipes qui livrent indépendamment, des composants aux mises à l'échelle divergentes (feed vs. checkout), des organisations qui pratiquent déjà le provisioning rapide, le monitoring et l'astreinte.
- **Hybride avec un backend géré :** les fonctionnalités standard (auth, données, stockage) consommées en tant que service, la logique sur mesure sous forme de fonctions déployées indépendamment — l'autonomie de niveau service au coût d'ops d'un monolithe.

## Devriez-vous découper ? Matrice de décision

| Restez monolithique quand… | Découpez quand… |
| --- | --- |
| L'équipe tient dans une pièce (< ~10 devs) | 15–20+ devs répartis en plusieurs équipes font la queue sur une seule release |
| Les frontières du domaine bougent encore chaque mois | Les frontières sont stables depuis des trimestres |
| Les transactions traversent vos workflows centraux | Les composants ont des données réellement indépendantes |
| Maturité ops = « on déploie de temps en temps » | Le provisioning, le tracing et l'astreinte sont déjà solides |
| La douleur, c'est la qualité du code | La douleur, c'est la coordination des déploiements |

Si la colonne de gauche vous décrit mais que celle de droite vous tente, le monolithe modulaire est le compromis honnête — et si vous découpez pour découvrir que chaque changement touche trois services, vous avez construit le monolithe distribué et devriez refusionner sans honte.

## Limites et trade-offs

- **Monolithe :** le train de releases ralentit à mesure que les équipes se multiplient ; une fuite mémoire devient la panne de tout le monde ; les enchevêtrements anciens résistent à l'extraction si la discipline des modules se relâche.
- **Microservices :** la « MicroservicePremium » — transactions distribuées, gestion des pannes réseau, API versionnées entre vos propres équipes, et un stack d'observabilité qui devient sa propre ligne budgétaire.
- **Les deux :** aucun ne répare un domaine mal modélisé. Des frontières de services tracées sur un mauvais modèle produisent une version distribuée du même désordre, avec de la latence en plus.
- **La contrainte organisationnelle est réelle :** selon la loi de Conway, vous livrez votre structure de communication. Restructurer l'architecture sans restructurer les équipes produit l'anti-pattern à coup sûr.

## Microservices vs. monolithe sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Elle change les termes du débat : les 80 % standard du backend n'ont même plus à être architecturés par vous, et les 20 % sur mesure s'exécutent sous forme de [fonctions Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) — chacune déployable indépendamment comme un microservice, aucune ne traînant un service mesh, une base de données par service ou une rotation d'astreinte. Les équipes qui dépassent même ce cadre gardent la sortie : le stack est open source, si bien qu'extraire un vrai service plus tard part de frontières qui fonctionnent, pas d'une réécriture.