La stack que j'utilise pour livrer un MVP SaaS en semaines, pas en mois

La plupart des MVP sont en retard pour la même raison : l'équipe passe le premier mois sur des décisions qui ne déterminent pas si quelqu'un veut le produit.

Stratégie d'authentification. Organisation du monorepo. Quel gestionnaire d'état. Faut-il des microservices « pour que ça passe à l'échelle plus tard ». Rien de tout cela ne compte si le produit que personne n'a demandé sort en novembre au lieu de septembre.

Mon approche est inverse. J'utilise une stack ennuyeuse et assumée pour presque tous les MVP, et j'investis le temps gagné là où se joue vraiment le résultat : le produit lui-même.

La stack

Next.js (App Router) pour toute l'application — pages marketing, tableau de bord et API dans une seule unité déployable. Les composants serveur permettent à la plupart des pages de récupérer leurs données elles-mêmes : aucun état de chargement à concevoir, aucune couche API à maintenir, aucun sur-chargement à déboguer.

Supabase pour Postgres, l'authentification, le stockage et la sécurité au niveau des lignes (RLS). C'est le plus gros gain de temps. Une authentification qui prendrait une semaine se règle en une après-midi, et la RLS place les règles d'autorisation à côté des données plutôt qu'éparpillées dans des handlers où elles pourrissent.

TypeScript partout, avec des types générés depuis le schéma de la base. Quand une colonne change, c'est le compilateur qui me le dit, pas un utilisateur trois semaines plus tard.

Tailwind pour le style, avec des tokens de design définis une fois en variables CSS. Le thème et le mode sombre deviennent de la configuration au lieu d'un refactor.

Vercel pour les déploiements, les previews et les analytics. Chaque pull request obtient une URL réelle que le client peut cliquer : la revue passe de « voici une capture » à « tenez, essayez ».

Pourquoi l'ennuyeux gagne

Chaque technologie inédite dans un MVP est un pari : vous passerez du temps à l'apprendre plutôt qu'à construire. Parfois le pari paie. Le plus souvent, non.

Une stack ennuyeuse, cela signifie : le message d'erreur est sur Stack Overflow depuis 2023, l'assistant IA de mon éditeur l'a vu des milliers de fois, et le prochain développeur du client saura reprendre le projet. Ce dernier point compte plus qu'on ne l'admet. Livrer un code que personne d'autre ne peut maintenir n'est pas un cadeau.

Où l'IA mérite vraiment sa place

J'utilise beaucoup l'IA pendant la construction — et presque jamais comme proposition de valeur centrale du produit, sauf si le problème du client l'exige réellement.

Là où elle paie pendant le développement :

• L'échafaudage, pas l'architecture. Générer des formulaires, des tableaux et des handlers CRUD est rapide et peu risqué. Concevoir le modèle de données, non — c'est là qu'une erreur coûte des semaines.
• Les travaux de migration et de traduction. Convertir une maquette en balisage, ou toute une interface vers une deuxième langue, correspond exactement au travail volumineux et peu ambigu où les modèles excellent.
• Le premier jet d'une suite de tests. Les modèles énumèrent bien les cas qu'on oublierait, et les tests passent ou ne passent pas : le retour est honnête.

Là où elle ne paie pas :

• Tout ce qui touche à la sécurité. Flux d'authentification, vérifications de permissions et paiements sont écrits et relus par un humain, à chaque fois.
• Les décisions sans marche arrière. Conception du schéma, dépendance à un prestataire, modèle tarifaire. Le code généré affiche sur ces sujets une assurance qu'il n'a pas méritée.

La séquence qui tient les délais

1. Semaine 1 — la colonne vertébrale. Authentification, schéma de base, pipeline de déploiement et un vrai parcours de bout en bout. Rien de joli. L'objectif : une URL en ligne où l'on peut s'inscrire et réaliser l'action la plus importante.
2. Semaines 2–3 — la boucle centrale. Ne construire que les actions que les utilisateurs doivent répéter pour que le produit ait du sens. Résister à chaque « tant qu'on y est ».
3. Semaine 4 — les bords. Facturation, e-mails, états vides, états d'erreur, mobile. C'est là que les MVP paraissent inachevés, et c'est presque toujours sous-estimé.
4. Ensuite — polir face à l'usage réel. Pas avant. Les décisions de design prises sans regarder quelqu'un utiliser le produit sont des suppositions.

Ce que je saute volontairement

Pas de panneau d'administration tant que personne n'en a besoin ; l'interface de la base suffit. Pas de design system sur mesure ; une librairie de composants plus des tokens couvrent 90 % du besoin. Pas d'objectif de couverture de tests ; les tests vont sur les chemins qui touchent à l'argent et sur la logique réellement difficile, pas sur l'affichage d'un bouton.

Et aucun travail de mise à l'échelle. Un Postgres managé vous portera bien au-delà du point où vous aurez prouvé que le produit mérite de grandir. Optimiser pour le trafic qu'on espère est la forme de procrastination la plus coûteuse du métier.

Ma définition de « terminé » pour un MVP

« Terminé » est le mot le plus flou du métier, alors je le rends concret avant la première semaine. Un MVP est livrable quand tout ceci est vrai — et notez qu'aucun de ces points n'est une fonctionnalité :

Domaine	Le critère
Inscription	Un inconnu crée un compte et atteint l'action principale sans moi
Boucle centrale	L'action principale fonctionne de bout en bout, sur mobile, en mauvaise connexion
Paiement	Si le produit facture, une vraie carte passe et une carte refusée échoue proprement
États vides	Chaque liste explique quoi faire quand elle est vide
Erreurs	Aucune trace technique brute ; chaque échec propose une suite
E-mails	Inscription, réinitialisation et reçus arrivent vraiment, hors spam
Données	Je peux répondre à « combien d'utilisateurs ont fait X ? » sans écrire de migration
Restauration	Les sauvegardes existent et j'en ai restauré une au moins une fois

C'est la dernière ligne que les équipes sautent. Une sauvegarde jamais testée est une rumeur, pas une sauvegarde.

Tout ce qui n'est pas dans cette liste appartient à la version deux. L'écrire dès le départ, c'est ce qui transforme « on pourrait juste ajouter… » en discussion sur la prochaine version plutôt qu'en retard sur celle-ci.

La vérité inconfortable

Ce n'est pas la stack qui fait réussir un MVP. C'est de le livrer pendant que l'idée est encore pertinente.

Choisissez des outils dans lesquels vous allez vite, coupez le périmètre plus fort que ce qui est confortable, et mettez-le entre les mains des utilisateurs. Vous pourrez tout reconstruire plus tard avec l'argent que la version qui fonctionne aura rapporté.