La plupart des fondateurs croient savoir ce qu'est un MVP. Et pourtant, ils construisent quand même la mauvaise chose. Ils sortent une version allégée de leur produit rêvé, collent l'étiquette MVP dessus, et passent six semaines à coder des fonctionnalités que personne n'a demandées. Ce n'est pas à ça que sert un produit minimum viable.
Un MVP, ce n'est pas un prototype — un prototype prouve juste qu'une idée tient techniquement la route. Un MVP, lui, prouve que des gens vont réellement s'en servir, et si possible payer pour ça. Ce n'est pas une bêta non plus, qui sous-entend un produit presque fini avec quelques bugs à nettoyer. Et surtout, oubliez "la v1 avec moins de fonctionnalités". Un vrai MVP tourne autour d'une seule question : est-ce que ce job précis, fait de cette manière précise, crée assez de valeur pour qu'un vrai utilisateur revienne ?
Ce cadrage change la façon de planifier le travail. Vous ne construisez pas une entreprise en modèle réduit. Vous menez une expérience structurée, et le produit fonctionnel n'est que l'instrument de mesure. La règle des 80/20 s'applique ici encore plus durement qu'ailleurs dans votre activité : 20 % de votre idée produit crée 80 % de la valeur pour vos premiers utilisateurs. Votre seul travail pendant six semaines, c'est de trouver ces 20 % et de les livrer.
Ce guide détaille un processus réaliste en 6 semaines pour construire un MVP, du cadrage au lancement. C'est le processus qu'on utilise avec les fondateurs dans nos missions de développement MVP, adapté pour que vous puissiez le mener vous-même ou en briefer une équipe.
Semaine 1 : définir le périmètre du MVP
La semaine 1, ce n'est pas construire quoi que ce soit. C'est décider, noir sur blanc, ce que vous n'allez pas construire.
Commencez par une réflexion jobs-to-be-done. Au lieu de lister des fonctionnalités, décrivez le job unique pour lequel un utilisateur "embauche" votre produit. Pas "gérer des tâches" — plutôt "savoir exactement quoi faire ensuite sans ouvrir cinq outils". Pas "se connecter à d'autres personnes" — plutôt "trouver un colocataire compatible avant le début de mon bail". Plus cette description est précise, plus chaque décision qui suit devient simple : vous pouvez demander de chaque fonctionnalité si elle aide à accomplir ce job, ou si c'est du scope creep déguisé en ambition.
Une fois le job défini, cartographiez le parcours utilisateur critique — le chemin unique qu'un utilisateur emprunte depuis son arrivée avec le problème jusqu'à l'expérience de la valeur. On appelle souvent ça le "happy path". Dessinez-le comme une vraie séquence d'écrans ou d'étapes : inscription, saisie de X, affichage du résultat Y, action Z. Tout ce qui est sur ce chemin, c'est la v1. Tout le reste, aussi séduisant soit-il, attend la v2.
C'est précisément là que la plupart des périmètres de MVP dérapent. Les fondateurs construisent le happy path, d'accord, mais aussi la page de paramètres, le tableau de bord admin, le système de parrainage, trois méthodes de connexion — parce que chaque brique semble anodine prise isolément. Appliquez un filtre sans pitié : si un utilisateur peut accomplir le job principal sans une fonctionnalité donnée, cette fonctionnalité n'a rien à faire en semaine un. Écrivez vos listes v1 et v2 côte à côte. La liste v2 est une promesse à tenir plus tard, pas une excuse pour caser "encore un petit truc" maintenant.
À la fin de la semaine 1, vous voulez un document de cadrage d'une page : le job, le happy path, la liste v1, et un parking v2 explicite.
Semaine 2 : concevoir le chemin le plus rapide vers la valeur
Le périmètre est fixé. La semaine 2, c'est concevoir le trajet le plus court entre "l'utilisateur arrive" et "l'utilisateur touche la valeur principale" — sans toucher au code.
Commencez par des wireframes basse fidélité : des boîtes, des libellés, rien de léché. Un design haute fidélité trop tôt donne un faux sentiment d'achèvement, et les gens s'attachent émotionnellement à des détails qui devraient rester négociables. Esquissez le happy path écran par écran. Concentrez-vous sur l'enchaînement des décisions de l'utilisateur, pas sur le rendu visuel.
Avant que quoi que ce soit ne parte définitivement dans un outil de design, testez-le avec cinq utilisateurs cibles. Montrez-leur les wireframes, parcourez le flux, regardez où ils hésitent ou posent une question que vous n'aviez pas vue venir. Cinq, ce n'est pas un chiffre pris au hasard — la recherche en ergonomie montre sans arrêt que les cinq premiers utilisateurs font remonter l'essentiel des points de friction évidents, et qu'au-delà, les retours deviennent marginaux tant que l'échantillon ne grossit pas nettement. Rien n'est encore construit, donc c'est la boucle de feedback la moins chère que vous obtiendrez jamais.
Une fois le flux validé, posez les bases minimales d'un design system : quelques tokens de couleur, une échelle d'espacement, des composants réutilisables — boutons, champs, cartes. Pas besoin d'un design system complet. Ce qu'il vous faut, c'est assez de cohérence pour que l'interface ressemble à un seul produit, pas à cinq écrans recollés à la hâte. Cet investissement se rentabilise dès que le développement démarre : les développeurs arrêtent de deviner les espacements et les états.
Semaines 3 et 4 : construire le produit central
L'essentiel du calendrier passe ici. C'est aussi là que la discipline sur le périmètre compte le plus, parce qu'une fois que les choses tournent visiblement, la tentation d'ajouter "encore un petit truc" devient la plus forte.
Pour la plupart des MVP, on part par défaut sur une stack Next.js, Supabase et Vercel. Next.js donne une seule base de code pour le frontend et les routes API. Supabase gère l'authentification, la base de données et le stockage sans que vous ayez à monter votre propre infrastructure backend. Vercel s'occupe du déploiement et des environnements de prévisualisation sans charge DevOps. Ce n'est pas la seule combinaison valable, mais elle évacue une quantité énorme de décisions d'infrastructure qui n'ont rien à voir avec le test de votre hypothèse produit. Notre page services détaille les autres options de stack qu'on utilise selon le produit.
Côté ordre de construction : privilégiez le frontend d'abord pour la plupart des produits SaaS grand public ou B2B. Câblez une vraie interface sur un backend léger au fur et à mesure, plutôt que de bâtir une couche API complète avant qu'un seul écran existe. Le frontend d'abord vous force à rester honnête sur ce que l'utilisateur voit vraiment, et ça oblige les décisions backend à suivre les besoins réels de l'interface plutôt que des modélisations de données spéculatives. L'API d'abord a plus de sens quand plusieurs clients — web, mobile, intégrations partenaires — ont besoin du même backend dès le premier jour, ou quand la valeur principale, c'est le traitement des données lui-même plutôt que l'interface.
Quelques intégrations sont incontournables même dans un MVP. L'authentification, pour avoir des utilisateurs identifiables dont on peut apprendre. Un prestataire de paiement, si vous comptez facturer quelqu'un pendant le test. Et l'analytics sur la poignée d'événements qui définissent vraiment le succès. Faire l'impasse sur l'analytics pour gagner une journée de travail, c'est le regret le plus fréquent qu'on entend chez les fondateurs après le lancement — sans ça, la semaine 5 devient de la devinette au lieu d'être de la mesure.
Ce qu'il ne faut pas construire en semaines 3 et 4 : les outils d'administration au-delà de ce dont vous avez personnellement besoin pour faire tourner le produit, la gestion des cas d'erreur marginaux peu probables dans une petite bêta, l'internationalisation, et toute fonctionnalité qui ne compte qu'à une échelle que vous n'avez pas encore atteinte. Tout ça, c'est du travail légitime, un jour. Rien de tout ça ne vous apprend quelque chose en semaine 5.
Semaine 5 : tester avec de vrais utilisateurs
Recrutez vos dix premiers bêta-testeurs exprès, pas au petit bonheur. Les amis et la famille, c'est pratique, mais ils ont tendance à être polis plutôt qu'honnêtes. Cherchez plutôt des gens qui ont réellement le problème que résout votre produit — communautés, listes d'attente, votre propre réseau de personnes qui collent au profil cible. Dix, ça suffit pour voir des tendances sans se noyer dans le bruit.
Récoltez du feedback qualitatif et quantitatif. Les signaux quantitatifs — taux de complétion, points d'abandon, temps jusqu'à la première valeur — indiquent où se situe la friction. Le feedback qualitatif, un appel de 15 minutes ou un court sondage ou une invite dans l'app, explique pourquoi. Aucun des deux ne suffit seul. Les chiffres sans contexte mènent à des suppositions. Les opinions sans chiffres mènent à construire pour la voix la plus forte dans la pièce.
Quelques signaux indiquent qu'il est temps de lancer : les utilisateurs accomplissent le parcours principal sans que vous ayez besoin d'expliquer quoi que ce soit, plusieurs demandent quand ils pourront continuer à l'utiliser ou payer pour ça, et le feedback porte désormais sur des raffinements — rendre X plus rapide, étoffer Y un peu — plutôt que sur la confusion face à ce que fait le produit.
À l'inverse, ces signaux disent qu'il faut pivoter le périmètre : les utilisateurs se bloquent systématiquement à la même étape, plusieurs décrivent le produit de travers (signe que la proposition de valeur ne passe pas), ou tout le monde est poli mais personne ne demande à continuer. Ce dernier point est le tueur silencieux. Un enthousiasme exprimé en feedback, ce n'est pas la même chose qu'une personne qui rouvre votre produit d'elle-même.
Semaine 6 : lancer et mesurer
La mécanique de lancement ne devrait pas vous surprendre en semaine 6. Verrouillez votre checklist de déploiement en amont : environnement de production sur Vercel, domaine personnalisé bien configuré, SSL actif par défaut, et un environnement de staging où vous pouvez encore pousser des modifications de test sans toucher à la production.
La configuration de l'analytics mérite plus d'attention que ce que la plupart des fondateurs lui accordent. Décidez des 5 à 10 événements qui indiquent réellement l'usage du produit — inscription complétée, action principale réalisée, retour dans les 7 jours — et instrumentez-les avant le jour du lancement, pas après. Un outil comme PostHog, câblé sur des événements nommés précisément plutôt que sur de simples vues de page, vous donne une base pour construire des funnels et des courbes de rétention plus tard.
Le jour un, surveillez trois chiffres de près. Le taux d'activation : le pourcentage d'inscrits qui accomplissent le parcours principal au moins une fois. La rétention précoce : qui revient dans les jours suivants sans y être invité. Et tout signal d'erreur ou de support qui laisse penser que quelque chose est cassé, pas juste imparfait. Ne réagissez pas de façon excessive à un premier jour calme. Réagissez vite si le parcours principal est cassé.
La discipline la plus difficile en semaine 6 et après, c'est de résister au scope creep déguisé en itération. Chaque retour utilisateur vous tentera d'ajouter quelque chose. Passez chaque demande dans le même filtre qu'en semaine 1 : est-ce que ça aide plus d'utilisateurs à accomplir le job principal, ou c'est un job entièrement nouveau ? Si c'est un nouveau job, direction la roadmap future, pas le sprint de cette semaine. Les fondateurs qui passent par notre checklist de lancement pour fondateurs avant de passer en production repèrent en général ces trous opérationnels — analytics, comportement mobile, hygiène SEO de base — avant qu'ils ne deviennent des urgences en semaine 7.
Notre point de vue
La plupart des conseils sur le MVP traitent la vitesse comme la seule variable qui compte. On pense que c'est une erreur. La vitesse compte, oui, mais seulement au service d'une question plus précise : quel est le moyen le plus rapide de découvrir que vous avez tort ?
Les fondateurs qui tirent le plus d'un MVP ne sont pas ceux qui livrent le plus de fonctionnalités en six semaines. Ce sont ceux qui livrent la plus petite chose capable de prouver ou d'infirmer leur hypothèse centrale, et qui traitent chaque semaine comme une occasion de réduire le périmètre plutôt que de l'étendre. On a vu une équipe passer huit semaines à peaufiner un onboarding pour un produit qui, une fois testé, avait besoin d'un parcours principal complètement différent. Tout ce poli d'onboarding, perdu. Le délai de six semaines n'est pas un chiffre magique non plus — c'est une contrainte, assez serrée pour rendre les décisions de cadrage impitoyables incontournables plutôt qu'optionnelles.
S'il y a une seule habitude à retenir au-delà de ce guide : traitez votre roadmap MVP comme une liste d'hypothèses classées par risque, pas comme une liste de fonctionnalités classées par enthousiasme. Construisez pour tester l'hypothèse la plus risquée en premier. Le reste attend.
Un MVP est un outil d'apprentissage, pas un produit fini. Son rôle, c'est de répondre à une question rapidement et honnêtement — pas d'impressionner par sa complétude. Construisez-le petit, testez-le avec de vraies personnes, et laissez ce que vous apprenez en semaine 5 décider de ce à quoi ressemblera la semaine 7. Ça vaut largement mieux comme base qu'une planification en amont, aussi poussée soit-elle.