« Combien ça va coûter ? » : c’est la première question de presque tous les fondateurs, et la réponse honnête — « ça dépend » — ne sert à rien en elle-même. Cet article la remplace par quelque chose d’exploitable : les quelques facteurs qui font vraiment varier le prix, une méthode pour estimer votre MVP en heures, et les décisions qui le rendent moins cher sans le rendre moins bon.
Ce qu’est un MVP (et ce qu’il n’est pas)
Un produit minimum viable, c’est la plus petite chose qui apporte une vraie valeur à de vrais utilisateurs, pour vérifier si l’idée tient. Ce n’est pas une version 1.0 avec moins de couleurs. Le test de chaque fonctionnalité est simple : si on l’enlève, peut-on encore apprendre ce qu’on a besoin d’apprendre ?
Cette définition compte pour le coût, car la plupart des dépassements de budget viennent de fonctionnalités qui ne répondent à aucune question.
Les cinq facteurs de coût
1. Le nombre de parcours utilisateur distincts
Le prix suit les parcours, pas les pages. « S’inscrire, créer un projet, inviter un collègue, payer », ce sont quatre parcours. Chacun demande du design, du front-end, du back-end, la gestion des cas limites et des tests. Un site vitrine de dix pages sans connexion peut coûter moins cher qu’une application de trois écrans avec des comptes.
2. Qui sont les utilisateurs
Un seul type d’utilisateur, c’est le cas le moins cher. Deux faces — acheteurs et vendeurs, élèves et professeurs, clients et administrateur — doublent à peu près le périmètre : tableaux de bord, droits, notifications et onboarding séparés pour chacun.
3. Les intégrations
Paiements, e-mail, cartes, agendas, CRM, modèles d’IA. Chaque intégration est souvent simple au départ et coûteuse à fiabiliser : webhooks, nouvelles tentatives, états d’échec, comptes de test, et le jour où le fournisseur change son API. Budgétez chaque intégration séparément.
4. Le contenu et les données
Qui rédige les textes ? Y a-t-il des données à importer ? Quelqu’un aura-t-il besoin d’une interface d’administration après le lancement ? « On verra le contenu plus tard » est de loin la raison la plus fréquente des lancements repoussés.
5. La plateforme
Une application web responsive touche tout le monde avec un seul code. Des applications natives iOS et Android doublent le développement et ajoutent la validation des stores. Pour la plupart des MVP, une application web rapide (éventuellement installable en PWA) est le bon premier pas.
L’estimer vous-même, en heures
Les heures sont plus utiles que les prix : les tarifs varient énormément selon le pays et l’expérience, le travail, lui, ne change pas. Voici des fourchettes typiques pour une personne expérimentée qui assure à la fois le développement full-stack et le design ; multipliez par le taux horaire qu’on vous propose.
| Lot de travail | Heures typiques |
|---|---|
| Cadrage, périmètre et parcours utilisateur | 8–20 |
| Design UI/UX des écrans principaux | 20–60 |
| Page d’atterrissage / site vitrine | 20–50 |
| Comptes : inscription, connexion, mot de passe oublié | 10–25 |
| Chaque parcours principal (CRUD + interface) | 15–40 |
| Paiements (abonnements ou paiement unique) | 15–35 |
| Interface d’administration du contenu ou des utilisateurs | 15–40 |
| Chaque intégration tierce | 8–30 |
| Notifications par e-mail | 6–15 |
| Recette, corrections et mise en ligne | 15–30 |
Un MVP SaaS classique à une seule face — page d’atterrissage, comptes, deux ou trois parcours principaux, paiements, une administration simple — se situe autour de 150 à 350 heures. Une marketplace avec deux types d’utilisateurs atteint souvent 300 à 600.
Ces fourchettes sont volontairement larges. Le bas suppose des décisions claires et un contenu prêt ; le haut, un périmètre qui bouge pendant le développement.
Là où part vraiment l’argent
- Changer d’avis en cours de route. Pas un problème en soi — apprendre, c’est tout l’intérêt — mais modifier ce qui est déjà développé coûte plusieurs fois plus cher qu’une modification sur papier. Passez plus de temps sur les parcours et les wireframes : le développement en sera moins cher.
- Tout faire sur mesure. Un design system maison, une authentification maison et un CMS maison font rarement le succès d’un MVP. Des briques éprouvées (un service d’authentification hébergé, Stripe, un CMS headless ou du simple Markdown) sont plus rapides et plus fiables.
- Des cas limites que personne ne rencontrera encore. Multidevise, dix rôles utilisateurs, mode hors ligne. Notez-les pour plus tard.
- Pas de décideur côté client. Quand personne ne peut trancher dans la journée, le projet attend, et l’attente se facture aussi.
Le rendre moins cher sans le rendre moins bon
- Écrivez une phrase qui définit le succès. Par exemple : « Dix équipes payantes l’utilisent chaque semaine d’ici la fin du deuxième mois. » Chaque fonctionnalité se mesure à cette aune.
- Limitez-vous à un seul type d’utilisateur. Lancez la face vendeurs en gérant les acheteurs à la main, ou l’inverse.
- Bricolez le back-office. Pendant les premiers mois, une interface d’administration peut se résumer à un tableur et quelques scripts.
- Soignez le design des écrans principaux, et seulement ceux-là. Une bonne UX sur les trois écrans utilisés tous les jours compte bien plus qu’une page de réglages léchée.
- Choisissez une stack avec laquelle le prochain développeur pourra travailler. TypeScript, React ou Next.js, une base de données managée et un hébergeur standard vous laissent toutes les portes ouvertes.
Forfait ou au temps passé ?
Un forfait fonctionne quand le périmètre est vraiment figé : un brief clair, des maquettes terminées, aucune intégration inconnue. Une facturation en régie ou un forfait hebdomadaire convient mieux quand vous comptez apprendre et ajuster en chemin — ce qui, pour un MVP, est presque toujours le cas. Compromis courant : une phase de cadrage et de design au forfait, suivie d’un développement estimé avec un plafond hebdomadaire.
Petite check-list avant de demander des devis
- Une phrase qui décrit l’utilisateur et le problème
- L’indicateur de succès des trois premiers mois
- La liste des parcours utilisateur, classés par importance
- Les intégrations dont vous savez avoir besoin
- Qui fournit le contenu, et quand
- Votre fourchette de budget et votre date de lancement
Avec ces six points par écrit, les devis deviennent comparables — et bien plus justes. Pour un modèle de ce document, voir le brief de site web qui obtient des devis précis.
En résumé
Le coût d’un MVP dépend des parcours, des types d’utilisateurs, des intégrations, du contenu et de la plateforme, pas du nombre de pages. Estimez en heures, limitez-vous à un type d’utilisateur et à un indicateur de succès, appuyez-vous sur des briques éprouvées, et décidez vite. C’est ainsi qu’un petit budget devient quelque chose que les gens utilisent vraiment.
Envie d’un deuxième avis sur votre périmètre ? Contactez-moi, j’y jetterai volontiers un œil.
