De 2015 à 2022, « Microservices » était le mot à la mode préféré pour embellir les CV. Des startups avec 5 utilisateurs déployaient 20 services via Kubernetes. C'était de la complexité pour la complexité. En 2026, le pendule est revenu.
Le Piège du « Monolithe Distribué »
La plupart des entreprises n'ont pas construit des microservices ; elles ont construit un monolithe distribué. Elles ont pris des appels de fonction (qui prennent des nanosecondes) et les ont transformés en requêtes HTTP (qui prennent des millisecondes) sur un réseau instable.
Le Moment « Oups »
« Nous avons passé plus de temps à déboguer le traçage distribué et à gérer les fichiers d'état Terraform qu'à construire des fonctionnalités produit. » — Tous les CTO en 2024.
Voici le Monolithe Modulaire
Chez elitics.io, nous optons par défaut pour le Monolithe Modulaire.
Unité de Déploiement Unique
Un seul pipeline CI/CD. Une seule base de données (séparée logiquement). Des commits atomiques.
Frontières Strictes
Le code est organisé en modules (Facturation, Utilisateurs, Inventaire) qui interagissent via des interfaces publiques, pas des jointures SQL détournées. Cela impose la discipline sans la latence réseau.
Quand vraiment découper ?
Nous n'extrayons un service que lorsqu'il a un profil de mise à l'échelle radicalement différent.
// Bonne raison de découper :
« Le module de Transcodage Vidéo consomme 100% du CPU et fait crasher le serveur API. » -> Déplacer vers un Worker Service.
// Mauvaise raison de découper :
« On veut que l'équipe Profil Utilisateur ait son propre repo. » -> Utilisez un Monorepo.
La simplicité se met mieux à l'échelle que la complexité. Ne construisez pas l'infrastructure de Google à moins d'avoir les problèmes (et le budget) de Google.
Cette perspective vous a plu ? Partagez-la avec votre équipe.