Trois axes orthogonaux : déploiement, versioning, architecture

Une confusion persistante dans l’industrie consiste à mélanger trois dimensions fondamentalement indépendantes :

• La stratégie de déploiement (monolithe vs microservices)
• La stratégie de versioning (monorepo vs multirepo)
• L’architecture logicielle (big ball of mud vs modularisation)

Ces trois axes sont orthogonaux : chaque combinaison est théoriquement possible et parfois souhaitable.

Confondre ces dimensions mène à des solutions qui adressent le mauvais problème.

Trois préoccupations distinctes

La stratégie de déploiement concerne la granularité des unités déployables. Un monolithe se déploie comme une seule unité ; des microservices se déploient indépendamment les uns des autres. Cette dimension impacte l’infrastructure, le scaling, l’isolation des pannes, la latence réseau.

La stratégie de versioning concerne l’organisation du code source : un seul repository pour tout le code, ou plusieurs repositories distincts. Cette dimension impacte les workflows Git, la visibilité du code, les outils de build, la gestion des dépendances.

L’architecture logicielle concerne la structure interne du code : des modules aux frontières claires avec des dépendances explicites, ou un enchevêtrement où tout dépend de tout.

Ces trois préoccupations opèrent à des niveaux différents et répondent à des questions différentes.

L’erreur classique : microservices comme solution architecturale

L’erreur classique consiste à chercher dans un axe la solution à un problème situé dans un autre.

Une équipe souffre d’un monolithe big ball of mud : le code est incompréhensible, les modifications ont des effets de bord imprévisibles, les tests sont lents et fragiles. La conclusion hâtive : « passons aux microservices, ça nous forcera à découpler ».

Mais distribuer un système mal conçu ne le rend pas mieux conçu ; cela transforme un monolithe ingérable en un système distribué ingérable, avec en prime la complexité réseau, la cohérence éventuelle, et le debugging distribué.

Le problème était architectural ; la solution proposée était infrastructurelle. On a changé d’axe sans adresser la cause racine. Le coût de cette confusion se compte en mois d’ingénierie : six mois à redécouper en services, des problèmes de couplage toujours présents, et de nouveaux problèmes créés (debugging distribué, gestion des transactions, latence).

Multirepo ne découple rien

La même logique s’applique au versioning.

Éclater un monorepo en multirepo parce que le code est trop couplé ne découple rien : cela rend simplement le couplage moins visible et plus douloureux à gérer. Les dépendances circulaires qui étaient des imports deviennent des versions à synchroniser laborieusement.

Le vrai travail (établir des frontières de modules claires, définir des interfaces stables, inverser les dépendances problématiques) reste à faire, mais maintenant dans un environnement où les refactorings cross-module sont devenus des coordinations multi-équipes.

Le multirepo peut être un choix valide pour d’autres raisons (confidentialité du code avec git, parfois autonomie d’équipes et isolation de builds), mais il ne résout pas les problèmes d’architecture.

La trajectoire saine : modulariser d’abord

La trajectoire saine face à un monolithe big ball of mud est d’abord de modulariser :

• Identifier les bounded contexts
• Tracer les frontières
• Expliciter les dépendances
• Inverser celles qui pointent dans la mauvaise direction

Un monolithe modulaire conserve la simplicité de déploiement et de debugging d’un monolithe tout en gagnant la clarté structurelle qu’on attribue à tort aux microservices.

Ensuite, si des besoins réels l’exigent, tels que qu’un scaling différencié, des équipes autonomes, des technologies hétérogènes, alors on peut extraire certains modules en services indépendants.

La modularité est le prérequis ; le découpage en microservices est une option. Confondre les axes, c’est refaire toute la plomberie pour résoudre un problème d’électricité : beaucoup d’efforts, mais sur le mauvais système.

Cette clarification des axes permet aussi de cadrer les investissements. « Nous investissons dans la modularisation (architecture), pas dans l’infrastructure (déploiement). Le retour sur investissement visé est la maintenabilité, pas le scaling. » Une telle formulation aide à justifier les budgets et à aligner les attentes.