Le débat entre monolithe et microservices ressemble souvent à une guerre de religions. En réalité, c’est un arbitrage de contexte, de rythme produit et d’équipe. Le monolithe propose une simplicité précieuse: un seul déploiement, un état partagé, des transactions faciles à raisonner. Les microservices, eux, promettent l’alignement des frontières techniques sur les domaines métier, de meilleures isolations de pannes et une évolution indépendante des modules. En France, nombre de PME démarrent en monolithe, puis extraient des services au fur et à mesure que l’architecture révèle ses «coutures».
Prenons un exemple concret: une plateforme de réservation. En monolithe, l’API, le back‑office et la facturation cohabitent. La cohérence transactionnelle est naturelle: créer une réservation et débiter une carte se modélisent dans la même base, sous une même transaction. Les tests d’intégration sont plus simples, et l’équipe avance vite tant que la complexité reste contenue. Les limites apparaissent avec la montée en charge et l’hétérogénéité des besoins: des temps de build qui s’allongent, des déploiements plus risqués, des équipes qui se gênent sur le même dépôt.
Côté microservices, la même plateforme se décompose en domaines: catalogue, réservation, paiement, notification. Chaque service choisit sa base de données, son langage, et son cycle de déploiement. Les avantages se payent en complexité d’infrastructure: gestion des contrats d’API, traçage distribué, tolérance aux pannes, idempotence des opérations, cohérence éventuelle. La facturation asynchrone exige une modélisation d’événements, et l’expérience utilisateur réclame des mécanismes de compensation en cas de défaillance partielle. Le gain est réel si les frontières sont bien dessinées; sinon, on remplace un gros problème par plusieurs petits mal connectés.
La voie pragmatique consiste à partir d’un monolithe modulaire, avec des limites de contexte explicites. On surveille les points d’étranglement — files d’attente, jobs, endpoints saturés — et l’on extrait des services quand une contrainte récurrente le justifie. L’objectif n’est pas de suivre une mode, mais d’acheter de la flexibilité là où elle rend le plus. Documentation d’API, observabilité, et pipelines de déploiement sont des investissements communs aux deux mondes. Au final, l’architecture n’est pas un totem; c’est une stratégie vivante, qui doit rester réversible autant que possible.
