Comment je construirais un MVP - et comment je choisis vraiment la stack

Si on me demandait demain de construire un MVP, je n’ouvrirais pas un tableau de 40 frameworks. Je ne dessinerais pas une carte de microservices. Je ne « pérenniserais » pas un produit qui n’a jamais rencontré un utilisateur payant. J’écrirais une phrase : pour qui c’est, quel travail ça fait, et ce qu’on mesurera en quatre semaines. La stack vient après cette phrase - pas avant.

La plupart des MVP ratés ne sont pas trop petits. Ils sont faussement grands : une « plateforme » à moitié construite avec auth, tableaux de bord, notifications et trois environnements - et personne n’a encore accompli le seul travail qui prouverait l’idée. La techno est souvent l’alibi. Cet article, c’est comment je livrerais vraiment.

1. Ce qu’est un MVP - et ce que je refuse d’appeler ainsi

Un MVP n’est pas « la version 1 avec moins d’écrans ». C’est l’expérience la moins chère qui peut tuer ou renforcer l’hypothèse la plus risquée. Si l’hypothèse est « les gens paieront pour réserver ce service en ligne », le MVP c’est un flux de réservation plus le paiement plus un humain de l’autre côté - pas un CRM, pas un programme de fidélité, pas une app native.

• Viable veut dire : un vrai utilisateur peut finir un vrai travail. Un prototype Figma cliquable, c’est de la recherche, pas un MVP.
• Minimum veut dire : tout ce qui ne sert pas ce travail est un ticket plus tard - même si ça a l’air « facile à ajouter ».
• Product veut dire : la semaine prochaine vous pouvez le répéter sans héroïsme. Un Google Form plus un tableur peut être un MVP. Réécrire l’architecture de Netflix, non.

2. Cinq questions avant qu’un dépôt n’existe

Les débats de stack sont bon marché. Les questions produit sans réponse sont chères. Je ne choisis pas Postgres contre Mongo tant que je ne peux pas répondre à voix haute - avec le fondateur, pas avec un article.

• Qui sont les dix premiers utilisateurs, nommément si possible - pas « tout le monde avec un téléphone ».
• Quel est le seul travail pour lequel ils « embauchent » le produit ce mois-ci ? Un. Pas une plateforme.
• D’où vient l’argent ou le signal - débit carte, contrat signé, créneau réservé, lead qualifié ?
• Quelle contrainte est réelle : quatre semaines, un développeur, un domaine régulé, un CRM existant, une audience Telegram ?
• Qu’est-ce qui nous ferait arrêter ? Si on ne peut pas nommer un critère d’abandon, on construit un hobby, pas une expérience.

3. Cinq filtres pour choisir la technologie

Je ne choisis pas les outils parce qu’ils sont tendance. Je les choisis parce qu’ils survivent au contact d’un développeur solo, d’un petit budget et du premier utilisateur en colère. Chaque techno passe ces filtres.

• Temps jusqu’au premier vrai utilisateur. Si la stack ajoute une semaine avant le premier clic, c’est la mauvaise stack pour un MVP. Les outils ennuyeux que je livre déjà en production valent mieux qu’un outil à la mode que j’apprendrais sous deadline.
• Opérable par une personne. Je dois pouvoir déployer, lire les logs, restaurer une sauvegarde et faire tourner une clé sans équipe plateforme. Kubernetes rate ce test pour presque tous les produits précoces.
• Recrutable et remplaçable. TypeScript, Postgres et React ne sont pas excitants. Ce sont les langages que d’autres bonnes personnes parlent déjà. Un MVP que moi seule peux étendre est un otage, pas un actif.
• Où vivent les données. La source de vérité va dans une vraie base avec des migrations dès le premier jour s’il y a des utilisateurs et de l’argent. Les tableurs sont ok pour l’expérience à côté du produit - pas dans le checkout.
• Issue de secours. J’utiliserai un auth managé, un Postgres hébergé, un prestataire de paiement. Je ne signerai pas un lock-in de cinq ans dont l’export fait mal. Un fournisseur, ça va. Un piège, non.

4. La stack web par défaut avec laquelle je commencerais en 2026

Pour un MVP B2B ou service typique - réservation, capture de leads, petit portail client, calculateur qui devient un devis - je commencerais ici. Pas parce que c’est à la mode. Parce que je peux livrer, faire du SEO, et encore embaucher quelqu’un d’autre dans six mois.

• Next.js + TypeScript + Tailwind : une app pour les pages marketing (SEO, rendu serveur) et l’UI produit. Moins de dépôts, un déploiement, des types partagés. App Router convient si l’équipe le connaît déjà ; je ne réécrirai pas une app Pages qui marche « pour la pureté ».
• Postgres (souvent via Supabase, Neon ou un petit VPS) : données relationnelles, transactions, et du SQL que je peux lire à 2 h du matin. Je prends un store documentaire seulement si la forme est vraiment documentaire - pas parce que « NoSQL est plus rapide ».
• Auth : un prestataire managé (Clerk, Auth.js + un IdP connu, ou Supabase Auth), sauf si le produit c’est l’auth. Des sessions maison en semaine une, c’est comme ça qu’on fuit des tokens et qu’on bloque la vraie fonction.
• Paiements : Stripe (ou l’équivalent local que les premiers utilisateurs utilisent vraiment). Pas de moteur de facturation maison. Les factures peuvent attendre ; un débit qui marche, non.
• Hébergement : Vercel pour l’app Next.js si le trafic est « web » et que l’équipe veut des previews ; Hetzner/VPS + Docker Compose s’il faut un worker long, un coût prévisible ou de la résidence des données. J’ai écrit cet arbitrage ailleurs. Règle MVP : un environnement que vous comprenez, des sauvegardes la nuit, HTTPS, un domaine.
• Email et fichiers : Resend ou une API transactionnelle similaire ; stockage compatible S3. Pas « on va construire un module de pièces jointes ».

5. Quand je quitte le défaut

Un défaut est un pari de départ, pas une religion. Je le change quand la contrainte est le produit.

• Le public vit déjà dans Telegram : un bot ou une Mini App peut être tout le MVP. Un site qu’ils n’ouvriront pas n’est pas « plus professionnel ». C’est une deuxième pièce vide.
• Le travail est sur le terrain avec un mauvais signal : je regarde du local-first ou une PWA, pas une réécriture native en semaine une. Le native est une décision de distribution, pas un badge.
• Le cœur est le langage (support, devis, extraction de documents) : j’ajoute une API LLM derrière un schéma strict et une étape de relecture humaine. Je n’emballe pas un widget de chat pour l’appeler produit.
• Le fondateur est l’opérateur et le contenu est le produit : un site rapide plus un CMS qu’ils utiliseront vraiment peut l’emporter sur un admin sur mesure. WordPress est encore permis si le travail est de publier, pas de construire une application.
• Place de marché à deux faces : je livre quand même un côté d’abord. Offre ou demande - ce qui est le plus dur à obtenir. Une « plateforme » avec des chaises vides des deux côtés est une landing avec des tables en trop.

6. Ce que je refuse d’ajouter avant les premiers utilisateurs

La façon la plus rapide de rater l’expérience, c’est de construire l’entreprise autour de l’expérience. Cette liste reste à côté du backlog.

• Microservices, bus de messages et Kubernetes. Un process, une base, un déploiement. On découpe quand un vrai goulot ou une vraie frontière d’équipe apparaît - pas quand un diagramme a l’air senior.
• Un design system avec 80 tokens et zéro écran. Livrer les trois écrans qui collectent l’argent. Extraire les composants quand le troisième copier-coller fait mal.
• Rôles, permissions, journaux d’audit et SSO - sauf si un acheteur B2B payant a bloqué le contrat là-dessus. Alors c’est le MVP, pas une quête secondaire.
• Une deuxième app mobile. Le web responsive ou une Mini App couvre les cent premiers utilisateurs dans la plupart des métiers de service que je vois.
• Une couverture de tests parfaite du code-colle. Je veux des tests sur l’argent, l’auth et le travail central. Pas une semaine de mocks pour un formulaire de landing.

7. À quoi ressembleraient vraiment les quatre premières semaines

Je traite le calendrier comme une décision produit. Si on ne peut pas décrire les semaines, on n’a pas de plan - on a un souhait.

• Semaine 0 (deux jours, pas deux semaines) : la page unique. Utilisateur, travail, critère d’abandon, non-objectifs. Esquisser les trois écrans. Se mettre d’accord sur « fini » : un inconnu peut finir le travail sans notre Zoom.
• Semaine 1 : tranche verticale. Domaine, déploiement, base, layout vide, un parcours heureux en production (même moche). Si on ne peut pas déployer au jour trois, la stack ment déjà.
• Semaine 2 : le travail. Réservation, devis, envoi, paiement - ce qu’on a nommé en semaine 0. Les opérations manuelles derrière l’UI sont permises : un ping Telegram au propriétaire est une fonction s’il ferme la boucle.
• Semaine 3 : les bords moches. États vides, erreurs, mobile, emails, analytics de base (où ils décrochent). Pas un entrepôt de données. Un tunnel qu’on peut lire.
• Semaine 4 : le mettre devant les dix personnes nommées. Regarder. Ne pas ajouter de fonction pendant les appels. Noter ce qu’ils ont fait, pas ce qu’ils disaient vouloir.

8. Après le lancement : garder, extraire ou réécrire

Un bon MVP a le droit d’être un peu gênant. Il n’a pas le droit d’être un piège. La stack ci-dessus est ennuyeuse exprès : on peut grandir dedans. On a rarement besoin d’en sortir la première année.

• Garder : le langage, la base, les noms de domaine dans le code. Pas cher à vivre avec, cher à jeter.
• Extraire : un worker, un second service, une vraie file - quand un travail est lent, dangereux, ou appartient à une autre équipe. Pas avant.
• Ne réécrire que la partie qui a appris la mauvaise leçon. Checkout faux - réécrire le checkout. Toute l’app est un labyrinthe vibe-codé : d’abord un problème de gens. Quelqu’un doit pouvoir l’expliquer à 2 h du matin.

Conclusion : choisissez la stack qui survit au premier non

Je construirais un MVP sans glamour : un travail, une base, un déploiement, des outils que je peux opérer seule, et une date où l’on décide de continuer ou d’arrêter. La « meilleure » techno est celle qui ne nous distrait pas de cette décision. Next.js, TypeScript, Postgres, un auth managé et un prestataire de paiement ne sont pas une personnalité. C’est une façon de dépenser les semaines rares sur le produit, pas sur la plateforme.

Si vous avez une idée, une deadline et la peur de choisir la « mauvaise » stack - écrivez via la section contacts. On peut cadrer le seul travail, nommer les non-objectifs, et livrer une tranche à montrer à de vraies personnes sans construire d’abord une fausse plateforme.