« MVP » est devenu un mot pour tout : une landing page avec liste d'attente, un prototype exporté d'un outil de design, une plateforme à moitié finie dont le budget s'est épuisé. Demandez un MVP à cinq agences, vous recevrez cinq devis pour cinq choses différentes.
Voici la définition avec laquelle nous travaillons depuis 2017 : un MVP, c'est un parcours clé, entièrement construit, devant de vrais utilisateurs. Pas un peu de tout — tout d'une seule chose.
Ce texte couvre ce que cela coûte, quels raccourcis se paient plus tard, et comment savoir que votre MVP est terminé. Avec les équipes et les semaines telles que nous les planifions, et le chemin vers un prix ferme.
Tout d'une seule chose
L'erreur de MVP la plus courante n'est pas l'excès d'économie — c'est la mauvaise économie. Construire dix fonctionnalités à 60 % plutôt qu'une à 100. Le résultat se présente bien en démo et ne peut être confié à personne.
Un exemple de notre portfolio : HappyBee montre aux parents ce que leurs enfants mangent à l'école — menus de la semaine, nutrition, par enfant. Un but, un groupe d'utilisateurs. L'étude de cas est ici.
C'est la forme dans laquelle la plupart des projets devraient démarrer. À supposer qu'il faille construire — Anjan a fait le calcul de quand un produit sur étagère est le meilleur choix. Un produit qui fait une chose correctement. L'extension vient ensuite, sur une base propre — l'inverse fonctionne aussi, c'est juste plus cher.
Ce que coûte un MVP
Voici un MVP resserré chez nous, en équipe et en semaines :
| Forme de projet | Équipe | Durée |
|---|---|---|
| MVP resserré — un parcours clé, vite devant de vrais utilisateurs | 2–3 ingénieurs | 8–14 semaines |
Tout ce qu'exige une première version prête pour la production s'y trouve : architecture, design, développement, QA, mise en ligne. Pas un prototype cliquable — un produit que de vrais utilisateurs emploient avec de vraies données.
Pourquoi aucun montant ? Parce qu'un MVP relié à un seul ancien système peut prendre bien plus longtemps qu'un MVP sans, et un chiffre qui l'ignore ne vous aide pas. Les clients suisses reçoivent leur devis en francs, à prix ferme — notre guide suisse des coûts donne des fourchettes de marché typiques, et notre calculateur de coûts estime l'équipe et les semaines pour votre cas précis en deux minutes.
Et pour qu'on se comprenne bien : ce sont des repères indicatifs pour 2026, pas un devis. Ce qui fait bouger le chiffre, c'est la complexité — intégrations, conformité, migration de données et le niveau de fiabilité qu'il vous faut dès le premier jour. Après un atelier gratuit de 4 heures, vous recevez sous trois jours ouvrés un périmètre écrit et un devis, à prix ferme quand le périmètre est clairement délimité. Si le périmètre reste ouvert, un court sprint de discovery payant vient d'abord, entièrement déduit du prix du développement, et le prix ferme suit.
Les raccourcis qui se paient plus tard
Un MVP vit de ce qu'on laisse de côté. Mais il y a deux façons de laisser de côté, et la facture arrive avec la mauvaise.
Ce qu'il ne faut jamais couper :
- Connexion, droits, bases de protection des données. « On durcira plus tard » signifie, en pratique, construire deux fois. Nous construisons privacy-first, en tenant compte du RGPD et de la nLPD dès le premier jour — rattraper coûte toujours plus cher qu'intégrer.
- Une interface d'administration. Sans elle, votre développeur répond à chaque question de support par une requête en base. Une version simple suffit — mais elle doit exister.
- Les décisions d'architecture impossibles à rattraper. La multi-location est le classique — pourquoi « on l'ajoutera plus tard » est la phrase la plus chère du SaaS, c'est ici.
- La mesure. Un MVP est une expérience. Une expérience sans métriques est une opinion avec un budget.
Ce que vous pouvez couper sans regret :
- Le design system léché — une interface propre et sobre suffit à la première cohorte.
- Les intégrations deux à dix. Une intégration qui tient vaut mieux que cinq à moitié.
- Des apps natives séparées par plateforme — le cross-platform est la voie par défaut, c'est ainsi que nous construisons les produits mobiles.
- Toute fonctionnalité dont la phrase commence par « Et plus tard, les utilisateurs pourraient aussi… »
Comment savoir que c'est terminé
Un MVP n'est pas terminé quand plus rien ne manque. Il est terminé quand un inconnu parcourt le trajet clé sans votre aide — et que vous pouvez mesurer ce qu'il fait.
C'est pourquoi une phrase doit précéder le premier sprint, et beaucoup de projets ne l'écrivent jamais : « Ce MVP réussit si le chiffre X passe de A à B d'ici la date C. » Quand cette phrase manque, ce n'est pas la technique qui manque. C'est une décision.
Et ensuite ? La version 2 se construit sur les données d'usage, pas sur la liste d'idées d'origine. Le support annuel représente typiquement 15–20 % du coût initial de réalisation — cela figure aussi dès le départ dans notre devis, parce que la seconde facture ne doit pas surprendre.
L'entrée en matière, sobrement
Si vous étudiez sérieusement un MVP : le premier atelier dure quatre heures et ne coûte rien. Sous trois jours ouvrés, vous avez un périmètre écrit, une liste explicite « on ne construira pas » et un devis, à prix ferme quand le périmètre est clairement délimité. Si le périmètre reste ouvert, un court sprint de discovery payant vient d'abord, intégralement crédité. Le document vous appartient, même si vous construisez ensuite avec quelqu'un d'autre.
D'abord savoir ce qu'on construit. Ensuite un chiffre qui tient.
Au passage : ce que l'IA change à la construction elle-même — et ce qui reste humain — nous avons fait le tri ici.
