Monolithe vs. Microservices : Quelle Architecture Choisir pour votre MVP
Il y a une conversation que j'ai au moins deux fois par mois avec des fondateurs qui viennent demander de l'aide sur leur stack. Ca commence comme ca : "On veut construire le MVP avec des microservices des le depart pour ne pas avoir a tout reecrire apres."
C'est une idee qui semble logique. Et dans la grande majorite des cas, c'est une erreur.
L'obsession des microservices vient d'un endroit comprehensible. Netflix, Spotify, Amazon — les entreprises qu'on admire le plus en technologie evangelisent cette architecture depuis des annees. Les articles de blogs techniques, les talks en conference et les threads sur Twitter repetent le meme message : les monolithes c'est du legacy, les microservices c'est l'avenir.
Ce que ces articles ne disent pas, c'est que Netflix a commence comme un monolithe. Spotify a commence comme un monolithe. Amazon a commence comme un monolithe. Ils ont migre vers les microservices quand ils avaient des centaines d'ingenieurs, des millions d'utilisateurs et des besoins de scalabilite qu'un monolithe ne pouvait pas satisfaire. Pas au stade du MVP.
Pourquoi les monolithes l'emportent pour les MVPs
Un monolithe est une application deployee comme une seule unite. Un repository, un processus, une base de donnees. Et pour un MVP, c'est exactement ce dont vous avez besoin, pour des raisons tres concretes :
Vitesse de developpement. Dans un monolithe, un ingenieur peut implementer une fonctionnalite de bout en bout sans se coordonner avec d'autres services, sans gerer la communication entre processus et sans se soucier de la consistance de donnees distribuees. On appelle une fonction, pas un endpoint HTTP. La difference en vitesse d'iteration est brutale.
Simplicite de deployment. Un pipeline de CI/CD. Un serveur (ou un conteneur). Un deployment. Pas besoin de Kubernetes, de service mesh, de service discovery ni de coordination de versions entre services. Quand votre equipe fait 3 a 5 personnes, cette simplicite n'est pas un luxe — c'est une question de survie.
Debugging direct. Quand quelque chose plante dans un monolithe, vous avez une stack trace. Un chemin clair de l'erreur a la cause. Avec des microservices, une panne peut se propager a travers trois services differents, avec des logs distribues dans differents systemes, des latences reseau qui obscurcissent la cause racine et des defaillances en cascade qui transforment un bug simple en une investigation de plusieurs heures.
Refactoring sans peur. Dans un monolithe, vous pouvez deplacer du code entre modules, renommer des fonctions et modifier des interfaces internes sans casser des contrats d'API entre services. Votre IDE vous montre toutes les references. Vos tests couvrent le flux complet. Avec des microservices, un changement dans le schema d'un evenement peut casser trois services downstream sans que vous le sachiez jusqu'en production.
Un seul modele de donnees. Une base de donnees, un schema, une source de verite. Pas besoin de decider quel service est le "proprietaire" de l'entite utilisateur, pas besoin de synchroniser des donnees entre services, pas besoin d'eventual consistency quand votre produit est encore en train de definir quelles donnees il doit stocker.
Quand les microservices ont reellement du sens
Les microservices resolvent de vrais problemes. Mais ce sont des problemes que la plupart des MVPs n'ont pas :
Plusieurs equipes travaillant en parallele. Si vous avez 30 ingenieurs repartis en 6 equipes, un monolithe devient un goulet d'etranglement. Les conflits de merge sont constants, les deployments necessitent une coordination entre equipes et une erreur d'une equipe peut bloquer la release de toutes les autres. Les microservices permettent a chaque equipe de deployer de facon independante.
Besoins de scalabilite differencies. Votre service de traitement d'images a besoin de GPUs et scale avec le volume d'uploads. Votre API de recherche a besoin de beaucoup de RAM et scale avec le nombre de requetes. Votre service de notifications est intensif en I/O et scale avec les utilisateurs actifs. Si chaque composant a des patterns de scalabilite radicalement differents, les deployer separement permet d'optimiser les ressources.
Exigences technologiques distinctes par service. Votre moteur de recommandation fonctionne mieux en Python avec des librairies ML. Votre API temps reel a besoin de WebSockets en Node.js. Votre systeme de facturation necessite les garanties transactionnelles de Java. Les microservices vous permettent de choisir la technologie optimale pour chaque domaine.
Votre MVP a 30 ingenieurs ? Vous devez scaler des composants independamment ? Vous avez besoin de trois langages de programmation differents ? Probablement pas. Alors vous n'avez pas besoin de microservices.
Le sweet spot : le monolithe modulaire
La meilleure decision pour la plupart des startups n'est ni le monolithe classique (tout couple) ni les microservices (tout separe). C'est le monolithe modulaire.
Un monolithe modulaire se deploie comme une seule unite, mais il est organise en interne en modules avec des limites claires. Chaque module a sa propre logique metier, ses propres modeles de donnees et une interface publique bien definie. Les modules communiquent via des interfaces internes — pas des appels HTTP, mais des contrats de code.
Vous conservez toute la simplicite du monolithe (un deployment, une base de donnees, debugging direct), mais avec la modularite necessaire pour scaler. Quand viendra le moment d'extraire un module en tant que service independant, les limites seront deja definies.
La cle, c'est la discipline. N'appelez pas directement les fonctions internes d'un autre module. Ne partagez pas les modeles de donnees entre modules. Utilisez l'interface publique. La tentation de prendre des raccourcis est constante quand tout est dans le meme repository — et c'est la qu'un ingenieur senior avec de l'experience en architecture fait la difference.
Les couts reels des microservices prematures
Si vous etes encore tente par les microservices pour votre MVP, considerez les couts qui apparaissent rarement dans les articles qui les promeuvent :
Complexite DevOps. Chaque service a besoin de son propre pipeline de CI/CD, de sa propre configuration de deployment, de son propre monitoring. Avec 5 microservices, vous avez 5 pipelines a maintenir. Avec un monolithe, vous en avez un.
Overhead d'infrastructure. Kubernetes, service mesh, logging centralise, tracing distribue, health checks par service. Rien de tout cela n'est gratuit — ni en argent ni en temps d'ingenierie.
Latence reseau. Ce qui etait un appel de fonction en memoire (nanosecondes) est maintenant un appel HTTP ou gRPC (millisecondes). Multipliez par chaque interaction entre services dans une requete utilisateur.
Consistance des donnees. Avec une base de donnees par service, vous perdez les transactions ACID entre services. Vous avez besoin de sagas ou d'eventual consistency. Pour un MVP qui est encore en train de definir son modele de donnees, c'est de la complexite prematuree.
Debugging distribue. Un bug qui dans un monolithe se diagnostique en 15 minutes peut prendre une demi-journee en microservices. L'erreur est nee dans le service A, s'est propagee au B et l'utilisateur l'a vue dans le C. Sans tracing distribue bien configure, vous naviguez a l'aveugle.
Un framework de decision simple
Avant de choisir une architecture, repondez a ces questions :
- Votre equipe fait moins de 8 ingenieurs ? → Monolithe.
- Vous construisez un seul produit ? → Monolithe.
- Vous etes en phase pre-seed, seed ou Serie A initiale ? → Monolithe.
- Votre priorite est la vitesse d'iteration et le time-to-market ? → Monolithe.
- Pouvez-vous assumer le cout d'une equipe DevOps dediee ? → Si non, monolithe.
Si vous avez repondu "monolithe" a tout : construisez un monolithe modulaire avec des limites claires entre modules. Quand vous aurez 20+ ingenieurs, plusieurs equipes et des besoins de scalabilite differencies, vous serez en position d'extraire des services de maniere incrementale — sans tout reecrire depuis zero.
Comment concevoir un monolithe facile a decomposer plus tard
Si vous acceptez que le monolithe est la bonne decision aujourd'hui, la question suivante est comment eviter qu'il devienne une boule de boue impossible a decomposer quand le moment viendra. Voici les pratiques qui fonctionnent :
- Organisez le code par domaine metier, pas par couche technique. Au lieu de dossiers
/controllers,/models,/services, utilisez/billing,/users,/notifications. Chaque domaine contient ses propres controllers, modeles et services. - Definissez des interfaces explicites entre modules. Chaque module expose une API interne (fonctions, classes, interfaces) et masque son implementation. Aucun module n'accede directement a la base de donnees d'un autre.
- Une base de donnees, mais des schemas separes. Utilisez des schemas ou des prefixes de tables pour separer les donnees de chaque module. Cela facilite l'extraction future.
- Evitez les dependances circulaires. Si le module A depend de B et B depend de A, vous avez un probleme de conception qui sera bien pire quand vous essaierez de les separer.
- Des tests par module. Chaque module a ses propres tests unitaires et d'integration. Si vous pouvez tester un module de facon isolee, vous pouvez l'extraire de facon isolee.
Ces pratiques ne demandent pas plus de temps de developpement. Elles demandent plus de discipline de conception. Et cette discipline est ce qui distingue un ingenieur senior d'un junior — pas le framework qu'il utilise, mais comment il structure le code pour que l'equipe qui viendra apres puisse travailler avec.
Chez Conectia, les ingenieurs senior que nous fournissons aux startups europeennes ont construit et decompose des monolithes dans des entreprises de toutes tailles. Ils n'arrivent pas avec une opinion dogmatique sur monolithes vs. microservices — ils arrivent avec l'experience necessaire pour evaluer votre cas concret et prendre la bonne decision. Parce que la bonne architecture n'est pas celle qui est a la mode. C'est celle qui vous permet de livrer de la valeur a l'utilisateur le plus vite possible avec l'equipe que vous avez aujourd'hui.
Vous ne savez pas quelle architecture votre produit necessite ? Parlez a un CTO — nous evaluons votre cas et vous recommandons l'architecture adaptee a votre etape et a votre equipe.
