Votre MVP n'a pas besoin de microservices : guide d'un directeur technique pour choisir une architecture adaptée
Kubernetes, microservices, event sourcing, CQRS. Votre MVP n'a besoin d'aucun de ces éléments. Voici comment choisir l'architecture adaptée à votre stade de développement, éviter la suringénierie et parvenir à livrer votre produit.
L'épidémie de surconception
Au cours des trois dernières années, nous avons analysé les bases de code de plus de 30 start-ups. La tendance numéro un : une architecture conçue pour 10 millions d'utilisateurs, mais qui n'en dessert que 500.
Une start-up qui n'a pas encore généré de revenus, disposant d'un cluster Kubernetes, de 12 microservices, d'une file d'attente de messages, d'un maillage de services et d'une facture d'infrastructure de 3 000 $ par mois. Son concurrent ? Une application monolithique Django hébergée sur un serveur à 50 $ par mois, qui déploie ses fonctionnalités quatre fois plus vite.
La surconception ne se contente pas de gaspiller de l'argent. Elle gaspille la seule ressource que les start-ups ne peuvent pas acheter : le temps.
L'architecture par étapes : ce dont vous avez réellement besoin
| Scène | Utilisateurs | Architecture | Coût mensuel des infrastructures |
|---|---|---|---|
| MVP / Validation | 0 à 1 000 | Monolith + base de données gérée | 20 à 100 $ |
| Croissance après le PMF | 1 000 à 50 000 | Monolith + cache + CDN | 100 à 500 $ |
| Mise à l'échelle | 50 000 à 500 000 | Monolithe modulaire + workers asynchrones | 500 à 3 000 dollars |
| À l'échelle de l'entreprise | Plus de 500 000 | Microservices sélectifs | 3 000 $ et plus |
Le monolithe qui en fait plus que vous ne le pensez
Instagram dessert 300 millions d'utilisateurs grâce à une architecture monolithique Django. Shopify fonctionne sur une architecture monolithique Rails. Stack Overflow accueille 100 millions de visiteurs par mois grâce à une architecture monolithique .NET répartie sur 9 serveurs web.
Une architecture monolithique bien conçue, s'appuyant sur PostgreSQL et Redis, est capable de gérer un trafic bien supérieur à celui que 99 % des start-ups ne connaîtront jamais. Le goulot d'étranglement ne réside pas dans votre architecture, mais dans vos requêtes de base de données, vos problèmes N+1 et l'absence d'une couche de mise en cache.
Le moment idéal pour briser le monolithe
Ne séparez un service que lorsque vous en ressentez le besoin, pas avant :
1. Les difficultés liées à la croissance de l'équipe. Si plus de dix développeurs se marchent sur les pieds au sein d'une même base de code, il est judicieux de la scinder en deux ou trois services dont la responsabilité est clairement définie.
2. Couplage au niveau du déploiement. Si le déploiement du système de notification nécessite de déployer l'application dans son intégralité et d'exécuter tous les tests, extrayez les notifications pour en faire un service.
3. Des besoins de mise à l'échelle différents. Si votre traitement d'images nécessite 10 fois plus de puissance de calcul que votre API, le fait de les séparer vous permet de les faire évoluer indépendamment.
4. Des cadences de livraison différentes. Si l'équipe chargée de la facturation effectue des livraisons hebdomadaires tandis que l'équipe chargée du produit principal en effectue quotidiennement, le recours à des services distincts permet à chaque équipe d'avancer à son propre rythme.
Si aucun de ces cas ne s'applique à vous aujourd'hui, vous n'avez pas besoin de microservices. Point final.
La pile technologique MVP que nous recommandons en 2026
Après avoir développé plus de 65 produits, voici ce que nous recommandons par défaut pour un MVP :
| Couche | Choix | Pourquoi |
|---|---|---|
| Back-end | Django ou Node.js | Développement rapide, vaste écosystème, éprouvé sur le terrain |
| Interface utilisateur | Next.js (React) | Référencement naturel (SEO), SSR, excellente expérience développeur |
| Base de données | PostgreSQL | Prend en charge le format JSON, la recherche en texte intégral et les données relationnelles dans une seule base de données |
| Mémoire cache | Redis (à ajouter si nécessaire) | Sessions, limitation du débit, mise en cache des requêtes coûteuses |
| Hébergement | VPS simple ou chemin de fer/rendu | 20 à 50 $ par mois, déploiement en quelques minutes |
| Stockage de fichiers | S3 ou équivalent | Ne stockez pas de fichiers sur le serveur |
| CI/CD | GitHub Actions | Gratuit pour la plupart des start-ups |
Cette pile prend en charge 100 000 utilisateurs par mois, coûte moins de 100 $ par mois et peut être gérée par un seul développeur. Lorsque vous devez évoluer, chaque composant peut être mis à niveau sans réécriture.
Ce que recherchent réellement les investisseurs (indice : ce n'est pas Kubernetes)
Au cours des plus de 50 entretiens de due diligence auxquels nous avons participé, les investisseurs n'ont jamais demandé : « Utilisez-vous des microservices ? » Ils ont plutôt demandé :
1. À quelle vitesse pouvez-vous mettre en place une nouvelle fonctionnalité ? (Vitesse)
2. Que se passe-t-il si votre développeur principal démissionne ? (Facteur de risque lié à une seule personne)
3. L'architecture est-elle capable de supporter une charge 10 fois supérieure à votre charge actuelle ? (Pas 1 000 fois, juste 10 fois)
4. Disposez-vous de tests automatisés et d'un système de CI/CD ? (Qualité)
Une architecture monolithique rigoureusement testée, intégrant des processus de CI/CD, obtient de meilleurs résultats à tous les égards qu'une architecture en microservices insuffisamment testée que seule une personne comprend.
L'optimisation prématurée est la source de tous les maux en programmation. Une architecture prématurée est la source de tous les maux dans les start-ups.
— alokknight Engineering, d'après Donald Knuth
