Monolithe ou microservices : la question qui coûte cher quand on y répond trop tôt

Pourquoi cette question arrive-t-elle presque toujours trop tôt ?

La question « monolithe ou microservices » se pose souvent avant même que le produit ait trouvé son marché. C'est une erreur de calendrier. Les microservices répondent à un problème précis : plusieurs équipes qui doivent livrer en parallèle sans se bloquer. Tant que vous êtes une, deux ou trois personnes sur le code, ce problème n'existe pas.

Ce que je vois sur le terrain, c'est une confusion entre trois choses différentes :

• La qualité du code — un monolithe peut être propre ou spaghetti, comme des microservices.

• La modularité — séparer proprement ses domaines métier ne nécessite pas de découper en services réseau.

• Le déploiement indépendant — le seul vrai bénéfice des microservices, et le plus coûteux à obtenir.

Beaucoup adoptent les microservices pour la modularité, alors qu'un monolithe bien découpé l'offre sans la facture réseau.

Que coûtent vraiment les microservices à une PME ?

Le coût n'est pas dans le code : il est dans tout ce qu'il y a autour. Un système distribué transforme des appels de fonction — instantanés et fiables — en appels réseau, lents et faillibles. Vous héritez alors de problèmes que le monolithe vous épargnait :

• Observabilité : suivre une requête à travers cinq services demande du tracing distribué. Sans lui, un bug devient une enquête.

• Cohérence des données : plus de transaction unique. Il faut gérer les échecs partiels, les compensations, l'eventual consistency.

• Déploiement et infrastructure : orchestration, réseau interne, gestion des versions d'API entre services.

• Charge cognitive : un développeur doit comprendre les frontières et les contrats entre services avant de livrer.

Pour une équipe réduite, cette complexité se paie en semaines de travail qui ne produisent aucune valeur métier. C'est du budget qui ne va ni au produit, ni aux clients.

Comment construire un monolithe qu'on ne regrettera pas ?

Le vrai piège n'est pas le monolithe : c'est le monolithe mal découpé, où tout dépend de tout. La solution s'appelle le monolithe modulaire. L'idée : des frontières nettes à l'intérieur d'un seul déploiement.

• Séparez par domaine métier, pas par couche technique. Un module « facturation », un module « commandes » — pas un dossier « controllers » géant.

• Interdisez les dépendances croisées sauvages : chaque module expose une interface claire, le reste est privé.

• Gardez une seule base de données, mais des schémas ou des espaces logiques distincts par domaine.

• Écrivez des tests aux frontières des modules : ils deviendront vos futurs contrats d'API si vous découpez un jour.

Fait ainsi, le monolithe reste rapide à faire évoluer et prêt à être découpé le jour où un besoin réel l'exige. Vous ne vous enfermez pas ; vous reportez la complexité au bon moment.

Quand faut-il vraiment passer aux microservices ?

Il existe des signaux concrets. Ce ne sont pas des impressions, ce sont des points de douleur mesurables :

• Le déploiement est devenu un goulot d'étranglement : plusieurs équipes attendent l'une l'autre pour livrer.

• Des parties du système ont des besoins de charge radicalement différents : un module traite des millions d'événements pendant que le reste dort.

• Le monolithe est trop gros pour tenir dans la tête d'un développeur, malgré une bonne modularité.

• Vous avez l'organisation pour : équipes autonomes, culture DevOps, budget d'infrastructure et d'astreinte.

Le bon déclencheur est organisationnel avant d'être technique. Si vous découpez un système que trois personnes maintiennent, vous ajoutez de la friction sans jamais toucher le bénéfice.

Comment décider concrètement pour votre PME ?

Ma règle est simple : commencez par le monolithe modulaire, découpez quand la douleur devient réelle et localisée. Vous extrayez alors un service précis — celui qui souffre — et vous gardez le reste. Cette approche progressive vaut mieux que le grand découpage initial.

Posez-vous trois questions avant d'arbitrer :

• Le découpage résout-il un problème que j'ai aujourd'hui, ou un problème imaginé ?

• Ai-je l'équipe et le budget pour opérer un système distribué en production ?

• Quel bénéfice métier concret le client verra-t-il ?

Si les réponses sont floues, restez sur le monolithe. C'est le choix qui préserve votre vitesse et votre budget. Architecture, développement, mise en production : sur ce type d'arbitrage, je porte la décision de bout en bout, avec un seul responsable qui assume le choix dans le temps.