Aller au contenu
Récent

Faire développer un MVP : un premier vrai produit en 8–14 semaines

Ce qu'est vraiment un MVP, ce qu'il coûte et quels raccourcis se paient — le guide honnête d'une équipe qui livre des premières versions depuis 2017.

Hariom Kumar
Hariom Kumar
Publié
Lecture5 min
Faire développer un MVP : un premier vrai produit en 8–14 semaines

« 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 mêmes chiffres que ceux de notre grille tarifaire publique.

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. Aujourd'hui : 84 % d'activation des parents dans 120+ écoles, 71 % de questions d'allergènes en moins. L'étude de cas est ici.

C'est la forme dans laquelle la plupart des projets devraient démarrer. 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

De notre grille tarifaire, sans retouche :

Forme de projetÉquipeDuréeFourchette indicative
MVP resserré — un parcours clé, vite devant de vrais utilisateurs2–3 ingénieurs8–14 semaines$30,000–55,000

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 des dollars américains ? Parce qu'un taux de change figé il y a des mois ment. Les clients suisses reçoivent leur devis en francs, tiré de la même grille — notre guide suisse des coûts donne le cadrage en CHF, et notre calculateur de coûts chiffre votre cas précis en deux minutes.

Et pour qu'on se comprenne bien : ce sont des fourchettes indicatives 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. Chaque projet est chiffré de manière ferme et par écrit après un sprint de discovery payant, et ce sprint est intégralement crédité sur la réalisation.

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 — c'est aussi dans la grille publique, 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 et une estimation de principe ne coûtent rien, et reviennent en général sous trois jours ouvrés. Vient ensuite le sprint de discovery payant — il en sort un périmètre écrit, une architecture, une feuille de route chiffrée et une liste explicite « on ne construira pas ». 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.

Dites-nous ce que votre MVP doit savoir faire.

Un projet en tête ?

Parlez-nous-en — nous vous répondrons sous un jour ouvré avec une lecture honnête de la faisabilité et du périmètre.