MVPPrototypeBudgetSaaSMéthode
MVP : quoi développer en premier, et pour quel budget
7 min de lecture
Un MVP (produit minimum viable) est la plus petite version d'une application qui permet de vérifier, avec de vrais utilisateurs, l'hypothèse la plus risquée de votre projet. Ce n'est ni une maquette ni une version au rabais : c'est un produit qui fonctionne, réduit à un seul parcours complet. Son budget dépend donc moins d'une grille tarifaire que du nombre de fonctions que vous acceptez de laisser pour plus tard.
La question utile n'est pas « combien coûte un MVP ? », mais « qu'est-ce qui doit absolument être dedans ? ». Voici comment trancher, ce que disent les données d'usage, et les erreurs qui transforment une première version en projet sans fin.
Ce qu'est vraiment un MVP
Le terme a été popularisé par Eric Ries dans The Lean Startup (2011). Il y décrit le MVP comme la version d'un produit qui permet d'apprendre le plus possible sur ses clients avec le moins d'effort possible. Trois conséquences découlent de cette définition, et elles sont souvent oubliées.
Le MVP est un outil d'apprentissage. Il existe pour répondre à une question précise : les clients paieront-ils pour ce service ? Les équipes abandonneront-elles leur tableur pour cet outil ? Sans question écrite, il n'y a pas de MVP, seulement une application incomplète.
Le MVP est utilisé pour de vrai. Une démonstration ou un prototype montre le produit ; le MVP le met entre les mains d'utilisateurs, sur leurs vraies données, dans leur vrai travail. C'est ce qui le distingue des autres livrables d'amont, détaillés dans notre article sur les différences entre prototype, maquette, MVP et POC.
Le périmètre découle de l'hypothèse. On ne réduit pas une liste de fonctions au hasard : on garde ce qui permet de vérifier l'hypothèse, et rien d'autre.
Pourquoi couper autant : ce que disent les données d'usage
L'intuition pousse à ajouter des fonctions « au cas où ». Les données d'usage disent l'inverse. En 2019, l'éditeur Pendo a analysé les données anonymisées de 615 de ses abonnements clients dans son Feature Adoption Report : 80 % des fonctions d'un logiciel moyen y sont rarement ou jamais utilisées, et 12 % des fonctions concentrent 80 % de l'usage quotidien.
Deux précautions de lecture : c'est une étude d'éditeur, menée sur des logiciels déjà commercialisés, et ce qu'on appelle « fonction » y dépend de la façon dont chaque client a configuré l'outil de mesure. L'ordre de grandeur reste parlant : la plupart des fonctions qu'on imagine indispensables avant le lancement ne servent presque pas. Dans un MVP, chaque fonction évitée est du budget et du délai économisés, et une source de complexité en moins à maintenir.
La méthode pour choisir ce qui entre dans le MVP
- Écrire l'hypothèse en une phrase. « Les techniciens acceptent de saisir leurs interventions sur tablette plutôt que sur papier. » « Des cabinets comptables paient un abonnement pour ce tableau de suivi. » Tout le reste en découle.
- Dessiner le parcours unique, de bout en bout. De l'arrivée de l'utilisateur jusqu'au résultat qu'il est venu chercher. Un MVP qui couvre la moitié de trois parcours ne prouve rien ; un MVP qui couvre un parcours entier prouve quelque chose.
- Trier chaque fonction avec un seul test. Sans elle, l'utilisateur peut-il quand même aller au bout ? Si oui, elle attend.
- Remplacer par du manuel ce qui peut l'être. Une facture émise à la main par l'équipe pendant trois mois coûte moins cher qu'un module de facturation automatique développé avant de savoir si quelqu'un paiera.
- Fixer le critère de réussite avant de développer. Un nombre d'utilisateurs actifs, un taux de saisie, un premier client payant. Sans critère, le MVP ne se termine jamais : il grossit.
Appliqué à un cas type, une plateforme de réservation de matériel entre les agences d'un réseau, le tri ressemble à ceci :
| Fonction envisagée | Dans le MVP ? | Pendant ce temps |
|---|---|---|
| Réserver un matériel et voir sa disponibilité | Oui, c'est le parcours | - |
| Comptes utilisateurs et connexion sécurisée | Oui, non négociable | - |
| Droits différenciés par agence | Non | Un seul rôle, liste d'agences fermée |
| Tableau de bord de consolidation | Non | Export tableur hebdomadaire |
| Notifications automatiques | Non | Un e-mail envoyé par l'équipe |
| Application mobile publiée sur les stores | Non | Application web utilisable sur mobile |
| Interface multilingue | Non | Une langue, celle des premiers utilisateurs |
MVP marché et MVP interne : deux logiques
Un MVP de SaaS vérifie une hypothèse de marché : des clients qui ne vous connaissent pas trouveront-ils assez de valeur pour payer ? Le critère de réussite est commercial (inscriptions, conversions, premiers abonnements), et la question du paiement en ligne arrive tôt. Les postes propres à un SaaS (comptes séparés par client, abonnements, exploitation continue) sont détaillés dans notre article sur le coût de développement d'un SaaS.
Un MVP d'application interne vérifie une hypothèse d'adoption : les équipes l'utiliseront-elles à la place de leur outil actuel ? Il couvre un seul processus, un seul service, parfois un seul site. C'est souvent le bon chemin pour sortir d'un fichier partagé devenu ingérable, comme nous l'expliquons dans notre article sur le remplacement d'Excel par une application métier.
Ce qui fait le budget d'un MVP
Il n'existe pas de prix standard pour un MVP, pour la même raison qu'il n'existe pas de prix standard pour une application : deux projets décrits avec les mêmes mots peuvent n'avoir rien de comparable. Les facteurs qui pèsent sont connus :
- le nombre de parcours retenus (idéalement un seul) ;
- les intégrations indispensables dès le départ (outil comptable, ERP, paiement) ;
- la reprise de données existantes ;
- le nombre de profils d'utilisateurs et de droits ;
- l'exploitation : hébergement, sauvegardes, supervision.
Le détail de ces facteurs est dans notre article sur le prix d'une application métier, et leur effet sur le planning dans notre article sur le délai de développement.
Un point ne se négocie pas : un MVP réduit les fonctions, pas la qualité. Il traite de vraies données, donc il doit être sécurisé, sauvegardé et conforme, comme n'importe quelle application en production. Un MVP fragile ne vérifie pas votre hypothèse : il la fausse, parce que les utilisateurs rejettent les pannes, pas l'idée.
Reste la façon de le payer. Au forfait, le prix est fixé avant la première ligne de code. En abonnement, vous ne payez pas le développement, seulement un abonnement mensuel qui couvre hébergement, maintenance et évolutions ; LPR Studio reste alors éditeur et exploitant de l'application, et les droits de chacun sont définis au cas par cas dans le contrat. Les trois formules sont décrites sur la page des offres.
Les erreurs qui transforment un MVP en projet sans fin
Le MVP qui est en réalité une V1 complète. Toutes les fonctions y sont, « mais en version simple ». Le résultat coûte presque autant qu'une V1 et n'apprend rien de plus.
L'absence de critère de réussite. Sans seuil défini à l'avance, chaque retour d'utilisateur devient une demande de fonction, et le MVP grossit sans jamais conclure.
Construire pour un futur hypothétique. Prévoir une architecture capable de servir dix pays avant d'avoir un premier client consomme le budget du MVP. L'inverse est aussi une erreur : un code bâclé, qu'il faudra réécrire dès que l'hypothèse est validée. La bonne mesure est un code propre, standard et reprenable, sur un périmètre étroit.
Sauter l'étape où l'on voit. Découvrir en cours de développement qu'un écran ne correspond pas au travail réel coûte cher. Le voir sur un prototype avant d'écrire le code ne coûte presque rien : c'est tout l'objet de notre article sur le prototype avant le paiement.
Par où commencer
Le moment le moins coûteux pour couper dans un périmètre, c'est avant le développement, quand les écrans existent seulement à l'état de démonstration. Chez LPR Studio, ce prototype visuel est gratuit et présenté en visio sous 5 jours ouvrés : écrans, parcours et données réalistes. C'est sur lui que se décide ce qui entre dans le MVP et ce qui attend, et le prototype validé devient le cahier des charges du forfait. Nous éditons et exploitons nous-mêmes nos logiciels, Izi-Devis et Tubissime : arbitrer entre « maintenant » et « plus tard » fait partie de notre travail quotidien.