Microservices vs. monolithe : quelle architecture, et quand ?

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

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é :

// 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 / 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 — Back4app Flutter SDK
final function = ParseCloudFunction('chargeOrder');
final response =
    await function.execute(parameters: {'orderId': 'ord_481'});
if (response.success) {
  print('Charged: ${response.result['status']}');
}

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

// 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

L’article canonique sur les microservices décrit la destination ; MonolithFirst 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

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

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 — 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.