Monolithe, microservices ou monorepo modulaire : choisir une architecture à sa taille

Peu de sujets techniques génèrent autant de décisions par imitation : on découpe en microservices « parce que c'est l'état de l'art », on reste sur un monolithe « parce que ça marche », on adopte un monorepo « parce que les grands le font ». Or l'architecture est un arbitrage économique : chaque option achète quelque chose et le paie ailleurs. Posons les termes de l'arbitrage, sans camp à défendre.

Trois mots pour trois questions différentes

D'abord, dissiper une confusion : ces trois termes ne répondent pas à la même question.

• Monolithe vs microservices : comment le code s'exécute (un processus déployé d'un bloc, ou des services indépendants qui communiquent par le réseau).
• Monorepo vs multi-repos : comment le code est rangé (un dépôt unique ou plusieurs). Un monorepo peut contenir des microservices ; un monolithe peut être éclaté en dix dépôts.
• Les couches et frontières internes (modules, contrats, domaines) : comment le code est structuré, quelle que soit l'exécution.

On peut donc combiner — et c'est souvent la bonne réponse.

Ce que les microservices achètent, et à quel prix

Les microservices résolvent des problèmes organisationnels : des équipes nombreuses qui se marchent dessus, des composants aux besoins de montée en charge très différents, des cycles de déploiement qu'il faut découpler. Si ces problèmes sont les vôtres, le prix se justifie.

Le prix, précisément : chaque frontière devient un appel réseau (latence, pannes partielles, retries), la cohérence des données se complique (transactions distribuées, événements, idempotence), l'observabilité devient un chantier à part entière (tracer une requête à travers six services), et l'infrastructure se multiplie. Une règle d'expérience brutale mais utile : si toute l'équipe tient dans une réunion, les microservices résolvent un problème que vous n'avez pas.

Le monolithe modulaire, choix par défaut sous-coté

Un monolithe bien structuré — des modules aux frontières nettes, des contrats explicites entre domaines, une interdiction outillée d'accéder aux données d'un autre module — offre l'essentiel de la discipline des microservices sans le coût du réseau. Et il garde une porte de sortie : un module aux frontières propres s'extrait en service le jour où un besoin réel l'exige (montée en charge spécifique, équipe dédiée). L'inverse — recoller des microservices mal découpés — est bien plus douloureux.

Le risque du monolithe est connu : sans discipline, il devient le « plat de spaghettis » où tout dépend de tout. La réponse n'est pas le réseau, c'est l'outillage : frontières vérifiées au build, revues d'architecture, contrats versionnés.

Le monorepo : un choix d'outillage, pas d'architecture

Ranger plusieurs applications et bibliothèques partagées dans un dépôt unique apporte des bénéfices concrets : un changement transverse en une seule pull request, des versions de dépendances unifiées, du code partagé sans publication de paquets. C'est notre choix chez PYKEngine — signalons le biais — pour une suite de produits avec un cœur commun et une petite équipe.

Les limites en face : le dépôt exige un orchestrateur de tâches (Turborepo, Nx…) pour ne pas tout rebuilder en permanence, les permissions fines par projet sont plus difficiles, et à très grande échelle l'outillage git lui-même devient un sujet. Pour des projets réellement indépendants (des clients différents, des cycles de vie sans rapport), le multi-repos reste plus simple.

Une grille de décision honnête

Et trois signaux qu'un découpage se justifie maintenant : des déploiements bloqués les uns par les autres, un composant qui exige dix fois plus de ressources que le reste, une frontière de données réglementaire (isolation exigée par un client ou une norme).

Ce qu'il faut retenir

L'architecture se choisit d'après l'équipe et les contraintes réelles, pas d'après les conférences. Le chemin le moins risqué pour la plupart des startups et PME : un monolithe aux frontières internes strictes, dans un monorepo si plusieurs applications partagent du code, avec extraction ciblée en service quand — et seulement quand — un besoin mesurable l'exige. Ce n'est ni conservateur ni audacieux : c'est réversible, et la réversibilité est la propriété la plus précieuse d'une décision d'architecture.