Forex Calendar Pro, un SaaS que j'ai créé pour mon compte, est passé de l'idée à une version en ligne avec abonnements en un mois, entre décembre 2025 et janvier 2026. C'était un MVP informatique : un produit en production, que des inconnus peuvent utiliser et payer, avec le strict nécessaire dedans.
La phrase que j'entends chez les porteurs de projet ressemble toujours à celle-ci : « J'ai une idée de SaaS, je veux la mettre en ligne. » Le piège, c'est de vouloir tout construire avant de la montrer. Des mois de développement, des dizaines de fonctions, et le jour du lancement, personne ne paie. Le produit minimum viable sert à éviter ça : mettre en ligne vite ce qui prouve (ou infirme) que l'idée tient. Vous trouverez ici la définition, ce qu'on met dans un MVP et ce qu'on laisse, le coût compté en jours plutôt qu'en grille, et la méthode que j'applique.
En bref
- Un MVP (produit minimum viable) est la plus petite version d'un logiciel qui permet à de vrais utilisateurs de s'en servir et de dire, par leurs actes, si l'idée vaut la peine d'aller plus loin.
- Le terme a été introduit par Frank Robinson en 2001 et popularisé par Eric Ries, qui le définit en 2009 comme la version qui apporte le maximum d'apprentissage sur les clients avec le moins d'effort.
- Chez Web du Léon, un MVP va en production en 6 à 10 semaines en général, soit 30 à 50 jours ouvrés de calendrier ; le nombre de jours réellement facturés sort du cadrage, et le coût d'un MVP, c'est ce nombre de jours multiplié par un tarif journalier, plus des coûts fixes faibles.
- Coûts fixes au démarrage : hébergement de 0 à environ 45 $ par mois (Vercel et Supabase), paiement Stripe à 1,5 % + 0,25 € par carte européenne standard, sans abonnement.
- Forex Calendar Pro, un SaaS avec API, trois plans et alertes Telegram, est passé de l'idée à la mise en ligne en un mois.
MVP informatique : la définition, et d'où vient le terme
En informatique, un MVP (minimum viable product, ou produit minimum viable) est la première version d'un logiciel qui contient seulement ce qu'il faut pour que de vrais utilisateurs l'utilisent, et pour mesurer s'ils y trouvent assez de valeur pour revenir ou payer. Le mot important est « viable » : le produit doit fonctionner en conditions réelles, pas en démonstration.
Le terme a été introduit en 2001 par Frank Robinson, du cabinet SyncDev, qui le décrivait comme le produit qui maximise le rapport entre le retour et le risque, pour celui qui le vend comme pour celui qui l'achète. Il a été popularisé ensuite par Steve Blank et Eric Ries, dans le mouvement lean startup. Dans un billet du 3 août 2009, Eric Ries en donne la définition la plus citée : la version d'un nouveau produit qui permet à une équipe de recueillir le maximum d'apprentissage validé sur ses clients avec le moins d'effort possible.
Traduit en langage de développeur : un MVP est une expérience, plus qu'une petite version du produit final. On construit juste assez pour répondre à une question précise, du type « des indépendants paieront-ils un abonnement pour ne plus faire leurs relances à la main ? ». Tout ce qui ne sert pas à répondre à cette question attend.
Ce qu'un MVP n'est pas : prototype, POC, version bâclée
Un MVP se distingue du prototype et de la preuve de concept par une chose : il est utilisé par de vrais clients, en production. Les trois se confondent souvent dans les devis, et la confusion coûte cher, parce qu'on ne paie pas le même travail.
| Livrable | Question à laquelle il répond | Qui l'utilise | Ce qu'on en garde |
|---|---|---|---|
| Maquette cliquable (prototype) | Est-ce que le parcours est compris ? | Vous, quelques testeurs | Les écrans validés, pas le code |
| POC (preuve de concept) | Est-ce techniquement faisable ? | L'équipe technique | La réponse, rarement le code |
| MVP | Est-ce que des gens s'en servent, et paient ? | De vrais utilisateurs, en production | Le socle du produit : comptes, données, paiement |
| Version complète | Comment gagner et garder plus de clients ? | Tout le marché visé | Tout |
Minimum ne veut pas dire bâclé. Ce qui est dans un MVP doit être solide : un paiement qui échoue, une donnée perdue ou un compte piraté tuent l'expérience avant qu'elle ait rendu son verdict. On réduit le nombre de fonctions, jamais la qualité de celles qui restent.
Que mettre dans un MVP, et quoi laisser de côté
Un MVP contient la fonction qui justifie le produit, ce qu'il faut pour qu'un inconnu puisse s'inscrire et s'en servir seul, et un moyen de mesurer ce qu'il fait. Le reste est reporté, même quand c'est tentant.
| Dans le MVP | Plus tard |
|---|---|
| La fonction principale, celle pour laquelle on paierait | Les fonctions « tant qu'on y est » |
| Inscription, connexion, mot de passe oublié | Connexion par cinq fournisseurs différents |
| Paiement, si l'hypothèse porte sur le prix | Codes promo, parrainage, facturation multi-devises |
| Un tableau de bord minimal pour vous (qui s'inscrit, qui utilise, qui paie) | Un back-office complet avec statistiques et exports |
| Les e-mails indispensables (confirmation, reçu) | Séquences d'e-mails automatiques |
| Sécurité, sauvegardes, conformité de base | Rien : cette ligne ne se reporte pas |
La question du paiement mérite une ligne à part. Un MVP qui ne fait pas payer mesure l'intérêt, pas la valeur : des gens qui s'inscrivent gratuitement ne vous disent pas qu'ils paieraient. Quand l'hypothèse de départ porte sur un modèle payant, le paiement fait partie du minimum. C'est pour ça que les MVP que je livre sont payants dès la première version.
Le tri se fait avant la première ligne de code, sur une maquette. Chaque fonction candidate passe un test simple : si elle manque, est-ce que l'expérience échoue ? Si la réponse est non, elle attend la version suivante.
Combien coûte un MVP ? Le compte en jours
Le coût d'un MVP se calcule comme celui de n'importe quel logiciel : nombre de jours de développement multiplié par le tarif journalier du développeur, plus des coûts fixes d'exploitation. Ce qui change, c'est que le périmètre réduit fait baisser le nombre de jours, et c'est tout l'intérêt de l'exercice.
Chez Web du Léon, un MVP est en ligne en 6 à 10 semaines en général, soit 30 à 50 jours ouvrés de calendrier ; le nombre de jours réellement facturés sort du cadrage. La page de préinscription de l'étape 2, c'est le prix d'une landing, dès 500 € chez Web du Léon. Pour comparaison, une première version d'application métier (outil interne, plusieurs rôles, intégrations) demande 4 à 12 semaines. Le chiffre précis se fixe une fois la maquette validée. J'ai détaillé la formule et les curseurs qui font varier les jours dans l'article sur le prix d'une application mobile : ils valent pour un MVP web.
Les coûts fixes, eux, sont faibles au démarrage. Voici ceux d'un MVP web sur la stack que j'utilise, au tarif public du 18 septembre 2026 :
| Poste | Tarif public | Remarque |
|---|---|---|
| Hébergement de l'application (Vercel) | Hobby 0 $, Pro 20 $ par mois | Le plan gratuit est réservé à un usage personnel, non commercial |
| Base de données et comptes (Supabase) | Free à partir de 0 $, Pro à partir de 25 $ par mois | Le plan Pro dès qu'il y a des clients qui paient |
| Paiement par carte (Stripe, France) | 1,5 % + 0,25 € par carte européenne standard | Ni frais d'installation ni frais mensuels : vous payez quand vous encaissez |
Le budget d'un MVP dérape surtout quand le périmètre grossit pendant le développement. Une fonction ajoutée « parce qu'elle est rapide » coûte ses jours, puis ses tests, puis sa maintenance.
Créer un MVP : la méthode en cinq étapes
Créer un MVP se fait en cinq temps : cadrer l'hypothèse, tester la demande avec une page, développer le minimum payant, mesurer, puis itérer. C'est la démarche décrite sur ma page micro-SaaS et MVP.
- Cadrer l'hypothèse (semaine 1). Une phrase : qui, quel problème, combien il paierait. Puis la fonction clé qui y répond. Le cadrage est gratuit chez moi, et il sert aussi à dire quand un projet ne vaut pas le coup.
- Tester la demande avant le code (semaine 1). Une page d'atterrissage qui décrit le produit et propose une préinscription. Si personne ne laisse son e-mail, vous venez d'économiser des semaines de développement.
- Développer le MVP (6 à 10 semaines en général). Maquette validée, puis comptes, fonction principale, paiement, tableau de bord minimal. Mise en production réelle, pas une démo.
- Mesurer. Fixer avant le lancement ce qui comptera comme un succès : un nombre d'inscrits actifs, un premier abonnement payé, un usage qui revient chaque semaine. Sans seuil écrit à l'avance, on trouve toujours une raison de continuer.
- Itérer, pivoter ou arrêter. Ajouter ce que les utilisateurs réclament vraiment, changer d'angle si l'usage réel diffère de l'hypothèse, ou arrêter proprement. Les trois sont des résultats.
Dans une startup comme dans une PME qui lance un nouveau produit, l'étape qu'on saute facilement est la quatrième. Un MVP startup sans critère de succès devient un produit qu'on développe indéfiniment sans savoir s'il marche.
Cette méthode sert à valider une idée. Si la validation est faite et que vous voulez construire le produit lui-même, le guide pour créer un micro-SaaS prend le relais.
Forex Calendar Pro : ce que contenait la première version payante
Forex Calendar Pro est un calendrier économique pour traders, que j'ai conçu, développé et mis en ligne en un mois, de décembre 2025 à janvier 2026. C'est un MVP au sens où l'entend cet article : un produit ouvert au public, payant dès le lancement, limité à ce qui répond au manque constaté (des calendriers soit trop basiques, soit non automatisables).
Ce que contient la première version : une API REST avec clé d'accès, plus de 50 indicateurs économiques, 10 fuseaux horaires, 5 langues, des briefings quotidiens générés par IA, des alertes Telegram filtrables par impact, et un modèle freemium à trois plans (Free, Basic, Pro) avec quotas et tableau de bord. La liste complète est sur la fiche Forex Calendar Pro.
La première version s'appuie sur des outils standard : Next.js, Supabase et Vercel pour le socle, l'API Telegram pour les alertes, un modèle de langage hébergé (via Groq) pour les briefings. Des services existants plutôt que du code maison : c'est le principe qui permet de tenir un périmètre court. Le déroulé complet, étape par étape, est raconté dans mon retour d'expérience sur la création d'un SaaS.
Quand le MVP n'est pas la bonne approche
Le MVP sert à tester une idée sur un marché. Si vous n'avez pas de question de marché à trancher, ce n'est pas le bon outil.
- Un outil interne (planning, suivi de chantier, remplacement d'un tableur) : vos utilisateurs sont connus, le besoin aussi. On parle alors d'une première version d'application métier, cadrée sur votre process, pas d'une expérience de marché.
- Un domaine réglementé (santé, finance, jeux d'argent) : le minimum légal fait partie du minimum viable, et il peut être lourd. Le cadre se vérifie avant de chiffrer.
- Un marché où le client compare fonction par fonction avec des outils installés : une version trop mince sera jugée incomplète, pas prometteuse. Mieux vaut alors viser une niche précise que le marché entier.
Si vous avez une idée de produit et que vous voulez savoir ce que serait son MVP, en jours et en fonctions, le cadrage est gratuit : écrivez-moi, depuis Morlaix ou en visio. Je vous dirai aussi ce que je laisserais de côté.
Questions fréquentes sur le MVP en informatique
Que signifie MVP en informatique ?
MVP signifie minimum viable product, en français produit minimum viable. C'est la première version d'un logiciel qui contient juste ce qu'il faut pour être utilisée par de vrais clients et mesurer si l'idée tient. Rien à voir avec le « most valuable player » du sport, qui partage le même sigle.
Quelle différence entre un MVP, un POC et un prototype ?
Le prototype vérifie qu'un parcours est compris, souvent sous forme de maquette cliquable. Le POC vérifie qu'une solution est techniquement faisable. Le MVP vérifie que de vrais utilisateurs s'en servent et paient : c'est le seul des trois qui tourne en production.
Combien de temps faut-il pour développer un MVP ?
Chez Web du Léon, un MVP est en ligne en 6 à 10 semaines en général. Forex Calendar Pro, un SaaS avec API, trois plans et alertes Telegram, est passé de l'idée à la mise en ligne en un mois. La durée dépend surtout du nombre de fonctions retenues, d'où l'intérêt de trier avant de coder.
Combien coûte le développement d'un MVP ?
Le coût d'un MVP est le nombre de jours de développement multiplié par le tarif journalier, plus les coûts fixes. Avec 6 à 10 semaines en général, soit 30 à 50 jours ouvrés de calendrier ; le nombre de jours réellement facturés sort du cadrage. Les coûts fixes au démarrage sont faibles : hébergement de 0 à environ 45 $ par mois (Vercel et Supabase) et 1,5 % + 0,25 € par paiement carte européenne standard chez Stripe.
Peut-on faire un MVP en no-code ?
Oui, pour tester une demande très simple, un outil no-code peut suffire. La limite arrive quand la règle métier sort de ce que l'outil prévoit, ou quand vous voulez récupérer votre code et vos données. Un MVP développé sur une stack standard devient directement le socle de la version suivante.
