Un transporteur régional m’appelle l’an dernier : leur back-office de facturation est devenu intouchable, et un cabinet leur a vendu une découpe en microservices comme remède. On ouvre le code. Le module de facturation est déjà un nœud de couplage, mais au moins il tient dans un seul processus. Six mois plus tôt, une équipe l’avait éclaté en six services pour « gagner en agilité ». Résultat le jour de mon arrivée : six fois le même désordre, relié par des appels HTTP, avec des timeouts qui apparaissaient au moment des clôtures mensuelles. La dette de code, qu’ils maîtrisaient, était devenue une dette d’infrastructure que plus personne ne maîtrisait.
C’est le scénario que je vois le plus souvent. On me demande de « passer en microservices », presque jamais pour la bonne raison. La vraie question n’est pas combien de services, mais à quoi ils servent.
Les microservices règlent des problèmes d’organisation et d’échelle, pas un code mal écrit. Découpés trop fin, ils donnent un monolithe distribué : la rigidité d’avant, plus la latence réseau et de nouvelles pannes.
Ce qu’ils règlent, et ce qu’ils ne règlent pas
Les microservices ont deux usages légitimes. Le premier : laisser plusieurs équipes livrer chacune leur morceau sans se marcher dessus. Le second : dimensionner à part un composant qui sature pendant que le reste tourne au ralenti. En dehors de ça, on entre dans la mode.
Or répartir un code sur le réseau ne le répare pas. Si vos modules sont mal séparés au départ, les frontières que vous croyez tracer passent en réalité au milieu d’une logique enchevêtrée. Vous retrouvez exactement les mêmes dépendances, à ceci près qu’elles franchissent désormais le réseau, avec sa lenteur et ses pannes. C’est ce qu’on appelle un monolithe distribué : un système éclaté en morceaux qui restent aussi dépendants les uns des autres qu’avant, sans le moindre des bénéfices attendus. Sur une PME e-commerce, j’ai mesuré une simple validation de panier qui traversait huit services : 400 ms de latence cumulée pour une opération qui prenait 5 ms quand tout vivait dans le même processus.
Les coûts que les slides oublient de chiffrer
Trois factures arrivent après coup, et aucune ne figure dans la présentation qui vous a convaincu.
D’abord les pannes partielles. En réseau, un service appelé répond à moitié, ou pas du tout. Votre code doit apprendre à temporiser, à réessayer, parfois à servir une donnée un peu périmée plutôt que rien. Ces situations n’existaient pas dans le monolithe, et la plupart des équipes les découvrent en production, un vendredi soir.
Ensuite la cohérence des données. Sans base partagée, maintenir des informations alignées entre services devient un chantier à part. Deux options, aussi exigeantes l’une que l’autre : la transaction distribuée (faire valider une opération par tous les services à la fois, tout ou rien), ou la cohérence à terme (chacun se met à jour à son rythme, les données convergent après un court délai). Dans les deux cas il faut prévoir des mécanismes de compensation, c’est-à-dire savoir défaire proprement une étape quand la suivante échoue. Faisable, mais long et subtil.
Enfin l’observabilité, c’est-à-dire votre capacité à savoir ce qui se passe à l’intérieur du système une fois en production. Quand une requête traverse huit services, comprendre où elle a échoué exige des traces distribuées (suivre le parcours complet d’une même requête de service en service) et une agrégation de logs que personne n’avait à installer avant. C’est souvent le poste le plus sous-estimé du projet.
Par où commencer demain matin
Ne partez jamais d’un nombre de services. Partez d’un blocage réel et nommable : une équipe qui attend systématiquement qu’une autre ait livré, ou un composant précis qui ne tient pas la charge aux heures de pointe. Si vous ne savez pas écrire cette phrase noir sur blanc, vous n’avez pas encore le problème que les microservices résolvent. Dans ce cas, rangez d’abord votre monolithe en modules nets : la moitié des migrations que je vois auraient pu s’arrêter là, et le week-end de l’équipe avec.