Quand un monolithe suffit, quand séparer. Loi de Conway, topologies d'équipe — et pourquoi la réponse n'est pas « microservices ».
Catégorie · DevOps & Infra
Deux architectures, un arbitrage.
Un monolithe maintient toute l'application dans une seule base de code et un seul déploiement. Les microservices la décomposent en de nombreux services autonomes, développés, livrés et mis à l'échelle séparément.
Les deux approches sont légitimes. La séparation coûte de la complexité — réseau, cohérence des données, exploitation — et ce prix doit être justifié par un bénéfice réel.
Quand on sépare.
La loi de Conway veut que les systèmes reflètent la structure de communication de leur organisation. Les microservices ont du sens lorsque plusieurs équipes autonomes doivent livrer indépendamment, sans se bloquer mutuellement.
Jusque-là, nous construisons le plus souvent un monolithe proprement structuré — plus rapide à développer, plus simple à exploiter, plus facile à comprendre. On peut séparer plus tard, de façon ciblée, le long de la couture qui fait réellement mal.
Pourquoi la réponse n'est pas « microservices ».
Choisir les microservices par défaut mène à des monolithes distribués : tous les inconvénients de la distribution, aucun de ses avantages. C'est l'erreur coûteuse la plus fréquente dans ce domaine.
La bonne question n'est pas « monolithe ou microservices », mais « où passe la frontière à partir de laquelle une livraison autonome crée une vraie valeur ». C'est cette frontière, et elle seule, qui justifie la découpe.
