Microservices

Les microservices sont une architecture où une application est découpée en petits services autonomes — chacun avec son code, sa base de données, son cycle de déploiement — qui communiquent entre eux via API REST, GraphQL, ou messages asynchrones (Kafka, RabbitMQ, NATS). C'est l'inverse du monolithe, où tout le code vit dans une seule application déployée d'un bloc. La promesse : équipes autonomes (chaque équipe possède son service), scalabilité ciblée (on scale uniquement ce qui sature), et résilience (un service down n'écroule pas tout). Netflix, Uber, Spotify l'ont popularisé entre 2014 et 2018.

La promesse marketing cache une vérité technique brutale : les microservices sont une complexité opérationnelle énorme. Vous troquez la complexité d'un gros code contre la complexité d'un système distribué — latence réseau, transactions distribuées, observabilité (logs/traces/metrics × N services), versioning d'APIs, déploiements coordonnés, debugging cauchemardesque. Pour une PME ou une startup avec 1-5 devs, c'est presque toujours de la sur-ingénierie. Le bon réflexe est l'inverse de la mode : commencer par un monolithe modulaire bien découpé, et n'extraire un service que quand un vrai besoin émerge (équipe trop grosse, scalabilité hétérogène, contrainte de techno différente).

Quand les microservices sont le bon choix : équipes 30+ devs, charges très hétérogènes (un service à 10 req/s, un autre à 10 000), contraintes techno différentes (Python ML + Node temps-réel), ou découplage métier fort (paiements vs catalogue vs livraison). On les déploie sur Kubernetes ou des PaaS managés (ECS, Cloud Run), avec une couche event-driven et des webhooks pour les intégrations externes. Pour 90 % des SaaS et logiciels métier, un monolithe Next.js + PostgreSQL bien architecturé est plus rapide, plus fiable et beaucoup moins cher à opérer.