MVP d’application : comment cadrer et chiffrer votre V1

Un MVP (produit minimum viable) est la première version d’une application qui tient une seule promesse, assez bien pour que de vrais utilisateurs s’en servent et que vous décidiez de la suite sur des faits. Pour une application web ou un SaaS, comptez le plus souvent 15 000 à 40 000 € et 8 à 16 semaines ; pour une application mobile publiée sur l’App Store et Google Play, 15 000 à 40 000 € et 12 à 18 semaines, hors délai de validation d’Apple et de Google. Le plus difficile consiste à décider ce qui n’entre pas dans la V1. Voici la méthode, avec un exemple de découpage.

Qu’est-ce qu’un MVP ?

MVP signifie Minimum Viable Product, produit minimum viable. Le mot qui compte est « viable » : la première version fonctionne en conditions réelles, avec des utilisateurs qui s’en servent pour de bon. « Minimum » porte sur le nombre de fonctionnalités, jamais sur leur finition. Un MVP répond à une question précise : des utilisateurs adoptent-ils ce produit pour l’usage prévu ?

Ce qu’un MVP n’est pas

• Un prototype jetable. Une maquette cliquable simule le produit pour tester un parcours, puis on la range. Le MVP tourne en production, et son code sert de fondation à la V2.
• Une version au rabais. Sécurité, sauvegardes et ergonomie restent au niveau d’un produit fini. Une V1 bancale fait fuir les utilisateurs avant qu’ils aient jugé l’idée.

Comment choisir ce qui entre dans la V1

Une seule promesse

Écrivez en une phrase ce que votre application permet : « tel utilisateur peut faire telle chose sans la difficulté d’aujourd’hui ». Si la phrase a besoin de deux « et », vous décrivez deux produits. Gardez celui qui règle le problème le plus pénible.

Un parcours principal

Tracez le chemin le plus court entre l’arrivée de l’utilisateur et le résultat promis. Tout ce qui se trouve sur ce chemin entre dans la V1, y compris son envers : si un client réserve, un prestataire doit avoir publié ses disponibilités et voir la réservation arriver.

La méthode « doit / devrait / plus tard »

Donnez à chaque fonctionnalité imaginée une seule étiquette :

• Doit : sans elle, la promesse n’est pas tenue. Elle entre dans la V1.
• Devrait : une manipulation manuelle peut la remplacer pendant quelques mois. Elle ouvre la V2.
• Plus tard : personne ne renoncera au produit si elle manque au lancement.

La question qui tranche : « Que se passe-t-il si cette fonctionnalité manque le jour du lancement ? » Si la réponse est « on le fera à la main », elle ne relève pas du « doit ». Et si plus de la moitié de votre liste finit en « doit », le tri n’est pas terminé.

Exemple : une plateforme de réservation pour un réseau de prestataires

Prenons un cas type : un réseau d’une trentaine de diagnostiqueurs immobiliers indépendants reçoit ses demandes par téléphone et veut passer à la réservation en ligne. Promesse retenue : « Un client réserve un rendez-vous auprès d’un prestataire du réseau sans passer un seul appel. »

Le paiement en ligne est l’arbitrage le plus délicat. Tant que les prestataires encaissent sur place, le repousser ne casse pas la promesse. L’application mobile attend aussi : un espace web bien conçu suffit pour consulter ses rendez-vous entre deux interventions. Si les prestataires réclament des notifications push, ce sera un signal pour la V2.

Tout mettre dans la V1 ferait monter le budget et repousserait le lancement, sans mieux répondre à la seule question du départ : les clients réservent-ils en ligne ?

Combien coûte un MVP ?

Un MVP d’application web, de SaaS ou d’application mobile coûte le plus souvent entre 15 000 et 40 000 €. Un outil interne simple peut démarrer autour de 8 000 €. Au-delà de 40 000 €, on parle d’une plateforme complète (40 000 à 120 000 €). Le détail par type de projet figure dans nos guides combien coûte le développement d’une application web et combien coûte une application mobile.

Ce qui fait varier le prix

À nombre d’écrans égal, deux MVP peuvent coûter du simple au double. Ce qui pèse :

• Les rôles. Client, prestataire et administrateur représentent trois espaces, chacun avec ses droits.
• Le paiement. Un paiement unique par Stripe reste simple. Un abonnement avec essais, changements de formule et relances est un chantier à part entière : nous le savons pour avoir conçu et mis en production notre propre produit à abonnement (authentification par code à usage unique, PostgreSQL, facturation Stripe).
• Les intégrations et les règles métier. Se brancher sur un CRM ou un ERP coûte parfois plus que la fonctionnalité elle-même, et chaque exception (tarif variable, condition d’annulation) est du code à tester.
• La plateforme. Le mobile ajoute les tests sur appareils réels, la publication sur deux stores et des frais hors prestation : compte Apple Developer (environ 100 € par an), inscription à Google Play (environ 25 €, une fois), hébergement du back-end. Sur les achats intégrés, les stores prélèvent une commission de l’ordre de 15 à 30 % selon les cas.

Pourquoi un forfait sur un périmètre figé

À l’issue du cadrage, le périmètre de la V1 est écrit noir sur blanc (parcours, écrans, règles, ce qui est repoussé) et chiffré au forfait avant la première ligne de code. C’est ainsi que nous travaillons chez Milann : vous connaissez le budget avant d’engager le développement.

Un périmètre figé reste arbitrable : une idée qui surgit en cours de sprint rejoint la liste « devrait », ou remplace une fonctionnalité d’effort comparable. Ni le périmètre ni la facture ne gonflent en silence.

Combien de temps pour lancer un MVP ?

Pour une application web sur-mesure ou un SaaS, ces semaines couvrent cadrage, design et développement par sprints, avec des livraisons régulières sur un environnement de test.

Pour une application mobile, comptez 1 à 2 semaines de cadrage, 2 à 3 de design, 7 à 10 de développement, puis 2 à 3 de recette sur appareils réels et de préparation de la soumission. La validation par Apple et Google s’y ajoute, et aucun prestataire n’en maîtrise le délai : gardez de la marge.

Chez Milann, les applications mobiles sont développées en React Native avec Expo, soit une seule base de code pour iOS et Android. Après le lancement, les correctifs JavaScript se déploient sans nouvelle soumission (Expo Updates) ; seuls les changements natifs repassent par la revue des stores.

Les signaux qu’il faut passer à la V2

Un MVP sert à décider. Mesurez dès la V1 l’usage du parcours principal, puis surveillez ces signaux :

• Les utilisateurs reviennent sans relance, d’une semaine à l’autre.
• Un contournement manuel coûte plus cher que la fonctionnalité. Quand la tête de réseau passe une journée par mois à facturer les commissions, le « devrait » devient un « doit ».
• Plusieurs utilisateurs réclament la même chose. Une demande répétée par des profils différents pèse plus que l’insistance d’un seul client.
• Quelqu’un paie, ou demande à payer : des abonnés qui restent après l’essai, des prestataires qui veulent rejoindre le réseau.

À l’inverse, si le parcours principal reste peu utilisé, ajouter des fonctionnalités ne réglera rien. Revenez à la promesse : elle vise peut-être le mauvais utilisateur, ou le parcours bloque à une étape précise.

En résumé

• Un MVP tient une seule promesse, en production, avec de vrais utilisateurs. Il réduit les fonctionnalités, jamais la qualité.
• Pour cadrer la V1 : une promesse en une phrase, un parcours principal, puis la méthode « doit / devrait / plus tard ».
• Un MVP d’application web, de SaaS ou d’application mobile coûte le plus souvent 15 000 à 40 000 € ; un outil interne simple démarre vers 8 000 €.
• Comptez 8 à 16 semaines pour une application web ou un SaaS, 12 à 18 semaines pour une application mobile publiée, hors validation des stores.
• Un forfait sur périmètre figé fixe le budget avant le développement.
• Passez à la V2 quand l’usage le justifie, pas avant.

Un projet d’application web, de SaaS ou d’application mobile à cadrer ? Parlons-en : premier échange sous 48 h, puis un cadrage qui fixe le périmètre et le prix de votre V1.