Monolithe vs Microservices en early stage

Tout le monde parle des microservices comme s'il fallait en faire par défaut. Conférences tech, articles de blog, threads Twitter... l'architecture distribuée est présentée comme la voie évidente vers la modernité technique. Mais après avoir accompagné des dizaines de startups en tant que lead développeur ou CTO Part-time, je peux vous affirmer que ce n'est généralement pas le modèle que je recommande à une petite équipe qui démarre.

Les microservices, pour qui ?

L'architecture en microservices fonctionne bien chez Google, Amazon ou Netflix. Avec des milliers d'ingénieurs sur un même produit, isoler les domaines fonctionnels a du sens. Chaque équipe peut développer, déployer et maintenir son service de manière autonome. Chaque composant peut être dimensionné indépendamment.

Mais votre startup n'est pas Google. Avec une équipe de 2 à 5 personnes, cette architecture devient vite un poids. J'ai vu plusieurs startups se perdre dans la complexité d'une architecture distribuée prématurée : points de défaillance multiples, débogage difficile entre services, synchronisation coûteuse. Les coûts opérationnels grimpent aussi vite que la frustration.

Un exemple : une startup fintech avait choisi d'emblée les microservices pour "faire comme les meilleurs". Six mois plus tard, l'équipe passait 50% de son temps à gérer l'infrastructure et la communication entre services, au lieu de développer les fonctionnalités. Le time-to-market en a souffert, et les nouveaux développeurs avaient du mal à monter en compétence.

Le monolithe bien structuré

David Heinemeier Hansson (créateur de Ruby on Rails) parle de "Majestic Monolith" : un monolithe assumé, bien organisé. Pas un bloc de code spaghetti, mais une application unifiée avec une architecture interne soignée.

En pratique, une seule base de code simplifie la compréhension du système pour toute l'équipe. Les nouveaux développeurs deviennent productifs rapidement, sans avoir à naviguer entre une dizaine de services interconnectés.

Un monolithe élimine aussi les frictions entre services. Pas besoin de gérer des API internes, de synchroniser des déploiements ou de déboguer des problèmes réseau. Tout vit dans le même environnement d'exécution, ce qui accélère le développement et les tests.

Basecamp et Shopify ont construit des produits utilisés par des millions de personnes avec cette approche. Dans mon cas, j'ai appliqué ce modèle sur Republike (réseau social orienté liberté d'expression) et Sappy (mise en relation auxiliaires de vie et personnes agées), permettant à ces startups d'itérer vite sur leurs fonctionnalités.

Quand distribuer, quand ne pas le faire

Je ne suis pas opposé aux microservices. Je suis opposé à leur adoption par mimétisme. L'architecture technique doit répondre à des problèmes concrets, pas à une mode.

La bonne question n'est pas "Comment découper mon application en microservices ?", mais "Ai-je vraiment besoin de distribuer ce composant ?".

Pour la plupart des startups, un monolithe bien conçu évolue avec le produit pendant plusieurs années. L'idée : le garder modulaire grâce au Domain-Driven Design, une organisation claire des dossiers, et des services internes qui pourraient devenir des microservices plus tard.

Concrètement, vous pouvez adopter une architecture hexagonale ou en oignon au sein de votre monolithe, en séparant la logique métier des détails techniques. Vous pouvez aussi identifier des bounded contexts qui délimitent des sous-domaines cohérents. Ces pratiques facilitent une extraction en microservices le jour où ce sera nécessaire.

Ce qu'il faut retenir

• Les microservices conviennent aux grandes équipes (centaines d'ingénieurs). Pour une startup de 2-5 développeurs, ils ajoutent de la complexité opérationnelle sans bénéfice proportionnel.
• Un monolithe bien structuré (architecture hexagonale, DDD, bounded contexts) permet d'itérer vite et d'intégrer de nouveaux développeurs facilement.
• Gardez votre monolithe modulaire pour faciliter une extraction future en microservices quand des problèmes concrets le justifieront.

Questions fréquentes

Quand faut-il passer aux microservices ?

Quand vous avez des problèmes concrets de scalabilité que le monolithe ne peut plus résoudre, typiquement avec des équipes de plus de 15-20 développeurs. Tant que votre monolithe est bien structuré et que votre équipe est petite, les microservices ajoutent de la complexité sans bénéfice réel.

Un monolithe peut-il scaler ?

Oui. Des entreprises comme Basecamp et Shopify ont construit des produits utilisés par des millions d'utilisateurs avec un monolithe bien conçu. L'astuce : garder une architecture interne modulaire avec des bounded contexts clairs qui pourront être extraits si nécessaire.

Comment structurer un monolithe pour éviter le code spaghetti ?

Adoptez le Domain-Driven Design avec des bounded contexts, une architecture hexagonale ou en oignon, et des services internes bien découplés. Ces pratiques maintiennent la clarté architecturale tout en gardant la simplicité d'une base de code unique.

Conclusion

Commencez avec un monolithe bien structuré. Évoluez vers une architecture distribuée quand des problèmes concrets le justifient, pas avant. Votre énergie est mieux investie dans le produit que dans l'infrastructure.