Microservices vs monolithe

Les microservices souffrent d'un problème d'image : ils sont associés à la culture d'ingénierie de Netflix et d'Amazon, si bien que les équipes ambitieuses les considèrent comme la marque des entreprises sérieuses. Pourtant, ces entreprises y ont eu recours pour résoudre des problèmes d'échelle massive et de très grandes équipes — des problèmes que vous n'avez presque certainement pas encore. Pour la plupart des produits, découper trop tôt est l'une des erreurs les plus coûteuses que vous puissiez commettre. Voici les compromis tels qu'ils sont réellement.

Ce qu'un monolithe vous apporte vraiment

Un monolithe, c'est une seule application déployable. Cette simplicité est une fonctionnalité, pas une limitation — surtout en début de vie :

• Un seul dépôt, un seul déploiement. Pas d'orchestration, pas de service mesh, pas de tracing distribué juste pour comprendre une requête.
• Un débogage simple. Une stack trace couvre l'intégralité de votre requête. Vous ne corrèlez pas les logs de cinq services pour trouver un seul bug.
• Un développement local rapide. Faites tourner l'application entière sur votre machine et itérez.
• Des transactions simples. La cohérence des données repose sur une transaction de base de données, pas sur une saga distribuée à concevoir et à fiabiliser.

La version moderne n'est pas un grand tas de boue. Un monolithe modulaire impose des frontières internes claires — des modules séparés avec des interfaces bien définies — et vous offre une grande partie de l'organisation des microservices, sans aucune surcharge réseau.

Ce que les microservices coûtent vraiment

Découper en services ne supprime pas la complexité : il la déplace de votre code vers le réseau, où elle est plus difficile à voir et à raisonner. Vous héritez d'une longue liste de nouveaux problèmes :

1. Les modes de défaillance des systèmes distribués — pannes partielles, retries, timeouts et cohérence éventuelle deviennent votre quotidien.
2. La cohérence des données entre services — plus de transactions simples ; vous concevez des sagas et des actions compensatoires.
3. La charge opérationnelle — chaque service exige son propre déploiement, sa supervision, sa journalisation et une astreinte.
4. Un développement local et un débogage plus lents — reproduire un bug peut nécessiter de faire tourner la moitié de votre architecture.

Pour une petite équipe, cette surcharge peut consumer exactement la vélocité que vous cherchiez à gagner.

Quand les microservices sont vraiment utiles

Ce ne sont pas une erreur en soi — c'est une réponse à des problèmes spécifiques qui apparaissent à l'échelle :

• Scalabilité indépendante. Un composant (l'encodage vidéo, par exemple) nécessite beaucoup plus de ressources que les autres, et vous voulez le scaler isolément.
• Autonomie des équipes à grande échelle. Plusieurs équipes se marchent dessus dans un seul dépôt ; une ownership claire de chaque service leur permet de déployer indépendamment.
• Des contraintes vraiment différentes. Un composant nécessite un langage, un runtime ou une cadence de release différents du reste.

Le schéma est clair : ce sont des problèmes d'échelle et d'organisation, pas de construction d'un produit. Si vous ne les avez pas encore, vous en payez le prix sans en tirer le bénéfice.

La voie pragmatique

Commencez par un monolithe modulaire. Maintenez des frontières de modules propres pour que le code soit bien organisé et, surtout, pour qu'il soit découpable plus tard. Lorsqu'un besoin réel et mesuré se manifeste — un composant qui doit scaler indépendamment, une équipe qui doit déployer à sa propre cadence —, extrayez ce seul service le long d'une frontière de module existante. Laissez l'architecture évoluer sous la pression réelle, plutôt qu'anticipée.

Cette trajectoire incrémentale vous donne le meilleur des deux mondes : la rapidité d'un monolithe maintenant, et une voie propre vers les services si et quand vous en avez vraiment besoin. La plupart des produits qui réussissent font tourner un monolithe bien structuré bien plus longtemps que l'internet ne voudrait vous le faire croire.

Si vous envisagez un découpage et souhaitez un avis extérieur avant de vous engager, parlons-en.