Monolithe ou microservices : la décision d’architecture que vous prenez en copiant des boîtes qui n’ont rien à voir avec vous

Un fondateur technique me montre son schéma d’architecture, fier : sept microservices, un message broker, un service mesh, le tout orchestré sous Kubernetes. La startup a onze clients et trois développeurs. Quand je lui demande combien de temps il passe à débugger des problèmes de communication entre services plutôt qu’à livrer des fonctionnalités, il baisse les yeux. La réponse, c’est « la moitié de mes semaines ».

Ce n’est pas un cas isolé. C’est le pattern le plus coûteux que je vois chez les startups tech ambitieuses : découper le produit en microservices non pas parce que le problème l’exige, mais parce que c’est ce que font Netflix, Uber et les articles d’ingénierie qu’on lit le soir. Le problème, c’est que Netflix a résolu un problème d’organisation à plusieurs milliers d’ingénieurs. Vous, vous en avez trois.

Le vrai problème que résolvent les microservices n’est pas technique

On présente souvent les microservices comme une réponse à un problème de scalabilité technique : « il faut pouvoir scaler indépendamment chaque partie du système ». C’est vrai dans certains cas extrêmes. Mais ce n’est presque jamais le vrai moteur de la décision chez une grande entreprise, et ce n’est certainement pas votre contrainte à onze clients.

Le vrai problème que résolvent les microservices, c’est un problème d’organisation humaine. Quand vous avez huit équipes de développeurs qui se marchent dessus dans la même base de code, qui bloquent leurs déploiements mutuels, qui passent des heures en résolution de conflits, découper le système permet à chaque équipe de posséder son périmètre et de déployer sans demander la permission. C’est une solution à la loi de Conway : votre architecture finit par refléter votre structure d’équipe.

Or à trois développeurs, vous n’avez pas ce problème. Vous n’avez pas huit équipes qui se marchent dessus. Vous avez trois personnes qui, idéalement, connaissent tout le système. Découper prématurément revient à payer le prix d’une solution organisationnelle pour un problème d’organisation que vous n’avez pas — tout en héritant de toute la complexité technique qui va avec.

Ce que les microservices vous coûtent vraiment quand vous êtes trois

Le coût des microservices est presque toujours sous-estimé parce qu’il est diffus. Il ne se voit pas sur un schéma. Il se voit dans les semaines qui passent.

D’abord, la complexité opérationnelle. Un monolithe, c’est un déploiement, un log, une base de données à surveiller. Sept services, c’est sept pipelines de déploiement, une observabilité distribuée à mettre en place, du tracing pour comprendre quelle requête est passée par où, et une gestion de la cohérence des données entre services qui devient un sujet à part entière. Une transaction qui, dans un monolithe, tient dans une seule requête SQL, devient une chorégraphie distribuée où il faut gérer les échecs partiels. Vous venez d’inventer les transactions distribuées, un des problèmes les plus difficiles de l’informatique, pour gérer onze clients.

Ensuite, la vitesse de développement. Ajouter une fonctionnalité qui touche deux services, c’est modifier deux dépôts, coordonner deux déploiements, gérer la rétrocompatibilité des APIs entre eux. Ce qui prenait une heure dans un monolithe en prend une demi-journée. Multipliez ça par le nombre de fonctionnalités que vous devez livrer avant d’atteindre le product-market fit, et vous mesurez le coût sur votre runway.

Enfin — et c’est le plus vicieux — le coût du mauvais découpage. Avant le product-market fit, vous ne connaissez pas encore les vraies frontières de votre domaine métier. Vous découpez selon votre compréhension du produit à l’instant T, puis le produit pivote, et vos frontières de services ne collent plus. Déplacer une responsabilité d’un service à un autre est infiniment plus douloureux que déplacer une fonction d’un module à un autre dans un monolithe. Vous vous êtes enfermé dans des choix que vous n’aviez pas encore la maturité de prendre.

Le monolithe n’est pas l’ennemi — le monolithe mal structuré l’est

Ceux qui défendent les microservices confondent souvent le monolithe avec le « big ball of mud » : la base de code spaghetti où tout dépend de tout, où toucher une ligne casse trois fonctionnalités à l’autre bout. Ce cauchemar existe, mais il n’est pas la conséquence du monolithe. Il est la conséquence de l’absence de discipline interne.

La réponse pour 95 % des startups n’est pas de découper en microservices. C’est de construire un monolithe modulaire : une seule application déployable, mais organisée en modules clairement séparés en interne, avec des frontières explicites entre eux. Le module « facturation » ne va pas fouiller directement dans les tables du module « utilisateurs » ; il passe par une interface. Vous obtenez la clarté conceptuelle des microservices sans la complexité opérationnelle du réseau.

Le bénéfice caché de cette approche, c’est qu’elle vous prépare à découper plus tard, si nécessaire. Un monolithe modulaire bien découpé en interne peut voir un de ses modules extrait en service séparé le jour où un vrai besoin apparaît — parce que ce module reçoit une charge disproportionnée, ou parce qu’une équipe dédiée doit le posséder. Vous prenez la décision de découpage quand vous avez l’information pour bien la prendre, pas avant.

Quand découper devient légitime — et selon quel stade

La question n’est jamais « monolithe ou microservices » dans l’absolu. C’est « qu’est-ce qui est adapté à mon stade ».

En pre-seed et seed, la réponse est presque toujours le monolithe modulaire. Votre priorité absolue est la vitesse d’itération pour trouver le product-market fit. Chaque heure passée à gérer de la plomberie distribuée est une heure volée à cette recherche. Un fondateur qui me dit « mais je veux être prêt à scaler » commet une erreur de priorité : vous n’avez pas de problème de scale, vous avez un problème de validation. Résolvez celui que vous avez.

À l’approche de la série A, avec une équipe qui grossit vers dix, quinze, vingt ingénieurs, les vrais signaux d’un découpage apparaissent. Les déploiements deviennent des goulots d’étranglement parce que trop de monde touche le même code. Une partie précise du système a des besoins de scalabilité radicalement différents du reste — par exemple un moteur de traitement asynchrone lourd qui n’a rien à voir avec votre API principale. Une équipe se forme autour d’un domaine métier suffisamment stable pour mériter son propre périmètre. C’est là qu’on extrait un service, un seul, celui qui pose problème — pas qu’on refait tout en microservices d’un coup.

Le bon réflexe, c’est le découpage incrémental et guidé par la douleur. Vous extrayez un service parce qu’un problème concret le justifie, mesuré, pas parce qu’un article de blog vous a convaincu. Chaque extraction doit avoir un coupable identifié et un bénéfice attendu.

Ce que ça change pour votre business, pas seulement pour votre code

Cette décision n’est pas qu’affaire d’ingénieurs. Elle engage directement votre runway et votre capacité à lever.

Un investisseur qui fait sa due diligence technique ne sera pas impressionné par un schéma de microservices sophistiqué chez une startup pré-PMF. Au contraire : il y verra un signal de mauvaise allocation des ressources, un fondateur technique qui optimise pour l’élégance plutôt que pour la traction. Ce qui rassure en série A, ce n’est pas la complexité de l’architecture, c’est la démonstration que vous avez fait des choix proportionnés à votre stade — et que votre stack peut évoluer sans réécriture totale.

À l’inverse, un monolithe modulaire propre raconte une bonne histoire : « nous avons livré vite pour valider le marché, notre code est structuré pour évoluer, et nous savons exactement quel module extraire quand la charge le justifiera ». C’est un discours de fondateur qui maîtrise l’arbitrage entre vitesse et dette, pas de fondateur qui a copié une architecture sans comprendre le problème qu’elle résout.

Ce qu’il faut vraiment faire

Commencez par un monolithe modulaire, quel que soit votre stade early. Investissez la discipline non pas dans le découpage réseau, mais dans les frontières internes : des modules clairs, des interfaces explicites entre eux, une base de code où chaque partie a un propriétaire conceptuel. C’est cette discipline, pas la technologie de déploiement, qui vous évitera le big ball of mud.

Résistez à l’envie de découper « pour être prêt ». Vous n’êtes jamais prêt pour un problème que vous n’avez pas encore. Le jour où vous l’aurez, vous aurez aussi l’information pour le résoudre correctement — et bien plus de moyens qu’aujourd’hui.

Et si vous devez découper, faites-le à l’unité, guidé par une douleur mesurée : un service extrait à la fois, avec une raison précise. La bonne architecture n’est pas celle qui anticipe tous les futurs possibles. C’est celle qui reste facile à modifier quand le futur arrive vraiment.

La vraie question à vous poser n’est donc pas « est-ce que mon architecture pourra scaler ». C’est : « est-ce que mon architecture me permet de changer d’avis vite ? » Parce qu’avant le product-market fit, changer d’avis, c’est exactement ce que vous allez faire — souvent.