MVP startup : comment lancer un produit en 8 semaines (et à quel prix)

Qu'est-ce qu'un MVP, exactement ?

Trois critères distinguent un MVP d'une maquette. Il est utilisable par de vrais utilisateurs sur leurs vraies données. Il est vendable : quelqu'un peut payer pour s'en servir. Et il résout un seul problème, complètement, plutôt que cinq problèmes à moitié.

Le dernier point est celui qui pose le plus de difficultés. Un produit qui fait à moitié cinq choses ne sert à personne : l'utilisateur doit compléter avec un autre outil pour chaque fonction, donc il n'adopte rien. Un produit qui fait très bien une seule chose trouve ses premiers utilisateurs, même s'il paraît maigre.

Comment définir le périmètre en pratique ?

1. 1
   Décrire l'utilisateur cible en une phrasePas « les PME », mais « le responsable administratif d'un cabinet de 5 à 20 personnes qui gère ses dossiers sur Excel ». Un MVP conçu pour tout le monde n'est adopté par personne.
2. 2
   Décrire le problème en une phraseLe problème, pas la solution. « Il passe deux heures par semaine à recopier des informations entre trois outils » est un problème. « Il a besoin d'un tableau de bord » est déjà une solution, et probablement pas la bonne.
3. 3
   Tracer le parcours minimalDe l'inscription à la première action qui produit de la valeur. Comptez les écrans : au-delà de huit à dix, le périmètre est encore trop large pour un MVP.
4. 4
   Lister tout le reste dans une colonne « plus tard »Écrire ces fonctionnalités quelque part est important : cela rassure et évite qu'elles reviennent à chaque réunion. La colonne « plus tard » est un outil de décision, pas une poubelle.
5. 5
   Chiffrer et arbitrerChaque élément du parcours reçoit une estimation en jours. Si le total dépasse votre budget, vous coupez dans la liste — pas dans la qualité de ce qui reste.

Le calendrier type d'un MVP en 8 à 12 semaines

Les phases se recouvrent volontairement : le développement commence pendant que les maquettes des écrans secondaires se terminent. C'est ce chevauchement qui permet de tenir douze semaines sans mobiliser une équipe surdimensionnée.

La semaine la plus importante est la deuxième. C'est là qu'on teste les maquettes sur de vrais utilisateurs — trois à cinq suffisent pour repérer les blocages majeurs. Un problème de parcours identifié en semaine 2 coûte une journée de correction ; le même problème découvert en semaine 10 coûte deux semaines.

Combien coûte le développement d'un MVP ?

Voici la répartition typique d'un budget de MVP à 18 000 €, telle que nous la chiffrons.

Après le lancement, prévoyez 2 000 à 6 000 € par mois pour faire vivre le produit : corriger ce que les premiers utilisateurs remontent, ajouter ce qu'ils réclament vraiment, et retirer ce dont personne ne se sert. Un MVP qui n'évolue pas pendant six mois après son lancement n'a pas rempli sa fonction, qui est d'apprendre.

Les quatre erreurs qui font dériver un MVP

• Élargir le périmètre en cours de routeC'est la cause d'échec numéro un, très loin devant la technique. Chaque « tant qu'on y est » ajoute des jours et repousse la date de confrontation au marché. Notez la demande dans la colonne « plus tard » et continuez.
• Construire pour un futur hypothétiquePrévoir une architecture pour dix mille utilisateurs quand on en cherche dix coûte des semaines de développement pour un problème qui n'existe pas encore — et qui n'existera peut-être jamais.
• Repousser la facturation« On branchera le paiement plus tard » est tentant, et c'est une erreur : tant que personne n'a payé, vous n'avez validé aucune hypothèse. Un utilisateur enthousiaste qui ne sort pas sa carte ne prouve rien.
• Négliger la sécurité dès le départMulti-tenant, contrôle d'accès côté serveur, gestion des secrets : ces briques se posent au début ou se repaient très cher ensuite. Rattraper une isolation de données défaillante sur un produit en production coûte souvent plus que le MVP lui-même.

Et après le MVP ?

Le MVP n'est pas une étape à franchir mais un instrument de mesure. Trois issues sont possibles, et les trois sont des succès.

• Les utilisateurs adoptent et paient : vous investissez sur ce qui fonctionne, en vous appuyant sur leurs retours plutôt que sur vos hypothèses.
• Les utilisateurs s'inscrivent mais n'utilisent pas : le problème est réel mais votre solution ne l'est pas. Vous pivotez avec 18 000 € dépensés au lieu de 60 000.
• Personne ne s'inscrit : le problème n'existe pas, ou pas pour cette cible. C'est l'issue la plus douloureuse et la plus utile — apprise en trois mois plutôt qu'en deux ans.

Les fourchettes de prix d'une V1 complète et les modalités d'évolution après le lancement sont détaillées dans notre article sur le prix du développement d'un SaaS.

Questions fréquentes