Monolithe ou microservices? Le contexte métier compte plus que la mode

Trois modèles qu’il faut distinguer

Un monolithe sans structure mélange les responsabilités et rend chaque changement risqué. Un monolithe modulaire reste un seul système déployable, mais sépare le domaine en modules avec interfaces et règles de dépendance. Les microservices sont des services exécutés et déployés séparément, souvent propriétaires de leurs données et reliés par le réseau.

Le débat utile n’oppose donc pas ancien et moderne. Il compare le coût de coordination dans le code au coût de coordination entre systèmes et équipes. Déplacer une frontière hors processus ne supprime pas la complexité. Il la transforme en contrats d’API, files, versions, latence, échecs partiels et observabilité.

La matrice de décision

Aucune ligne ne décide seule. Si un seul module connaît une croissance particulière, il peut être extrait sans décomposer tout le produit. Si plusieurs équipes se bloquent constamment sur un déploiement commun et que le domaine est stable, le coût des services indépendants peut devenir justifié.

Le coût caché du distribué

Un appel de fonction devient un appel réseau susceptible de ralentir, échouer ou être rejoué. Une transaction locale devient une coordination entre états. Le débogage exige des identifiants de corrélation, des journaux centralisés, des métriques et des traces. La sécurité doit couvrir davantage d’identités, de secrets et de surfaces exposées.

Les équipes doivent aussi gérer le versionnage d’API, les déploiements compatibles, la découverte de services, les files d’attente, les reprises, les limites de débit et les pannes partielles. Si ces capacités ne servent pas un besoin important, elles consomment du temps qui pourrait améliorer le produit.

Comment construire un monolithe qui garde des options

Cette discipline réduit le coût d’un futur découpage. Elle apporte aussi une valeur immédiate: compréhension, tests ciblés et responsabilité claire. Un monolithe modulaire n’est pas une étape honteuse. Il peut rester la bonne architecture pendant toute la vie d’un produit.

• Découper par capacités métier et non par couches techniques seulement.
• Définir les interfaces publiques de chaque module et empêcher les accès directs non autorisés.
• Rendre les dépendances visibles par tests d’architecture ou règles de build.
• Isoler les traitements asynchrones et les intégrations derrière des adaptateurs.
• Mesurer les modules qui créent lenteur, risque ou contention avant toute extraction.
• Conserver un pipeline de déploiement fiable, des migrations réversibles et une observabilité commune.

Exemple anonymisé: plateforme de vente B2B

Une plateforme gère catalogue, prix clients, commandes, stock et facturation. Une petite équipe prévoit huit services dès la première version. Pourtant, les règles de prix et d’approbation changent chaque semaine et les mêmes développeurs interviennent partout. La séparation créerait des contrats instables et un coût opérationnel disproportionné.

Le choix retient un monolithe modulaire avec modules Catalogue, Tarification, Commande, Stock et Facturation. Les événements internes sont explicites et les intégrations passent par des adaptateurs. Plus tard, le calcul de prix pourra être extrait si sa charge, son cycle de changement ou son équipe deviennent réellement indépendants.

Quand refuser une migration vers les microservices

Refusez ou reportez si l’objectif est seulement de moderniser l’image technique, si le domaine n’est pas compris, si les équipes ne possèdent pas les services en production, si le déploiement actuel n’est pas automatisé ou si aucun problème mesuré ne nécessite une séparation.

Une migration peut rester pertinente pour isoler une charge, répondre à une contrainte réglementaire, permettre une autonomie d’équipe ou réduire le rayon d’impact. Dans ce cas, commencez par le service dont la frontière est la plus claire et mesurez le coût réel avant de généraliser.