Un MVP ciblé se développe en 2 à 4 semaines quand son périmètre tient en une routine principale, un ou deux types d'utilisateurs et quasiment aucune intégration. La plupart des estimations publiées parlent de deux à quatre mois. Elles n'ont pas tort. Elles décrivent simplement un produit plus gros. L'écart ne vient pas d'une équipe qui code plus vite. Il vient de ce que vous acceptez, par écrit, de laisser de côté avant que quiconque vous donne une date.
Combien de temps faut-il vraiment pour développer un MVP ?
La réponse du marché, c'est « des mois ». Netguru estime qu'un MVP prend généralement trois à quatre mois. 7L International situe la plupart des MVP entre 8 et 16 semaines, du lancement du projet à une version que les utilisateurs peuvent tester. Mais en regardant de plus près, la fourchette se resserre vite avec le périmètre. Selon Forcoda, un MVP léger avec un seul workflow principal, un seul type d'utilisateur et un minimum d'intégrations peut prendre 4 à 8 semaines. Crework Labs indique que la plupart des MVP réalisés par des équipes expérimentées en 2026 prennent trois à huit semaines. Technijian va plus loin : au-delà de 16 semaines, le MVP est presque certainement surdimensionné.
Notre propre record se situe tout en bas de la fourchette. Une application a été mise en ligne deux jours après le démarrage. Ce n'est pas une promesse que nous faisons à tout le monde. C'est ce qui arrive quand le périmètre se limite à une routine quotidienne pour deux utilisateurs, et rien d'autre.
Pourquoi la vitesse compte-t-elle autant ? Parce que le plus gros risque n'est pas un bug. Une synthèse des recherches de CB Insights montre que 42 % des startups qui échouent le font faute de besoin sur le marché. Chaque mois de développement en plus, c'est un mois de plus avant de savoir si quelqu'un en veut.
Ce qui tient dans une première version de 2 à 4 semaines
Nous aimons la définition de Soonlay : le MVP, c'est le chemin le plus court entre l'ouverture du produit et le résultat obtenu, plus le minimum d'outils d'administration pour le faire tourner. Concrètement, une première version de 2 à 4 semaines comprend :
- Un workflow principal, de bout en bout. Pas trois moitiés de workflow.
- Un ou deux rôles. En général vos utilisateurs, et vous en tant qu'admin.
- La connexion, et les données dont vous aurez besoin pour apprendre.
- Les écrans d'admin nécessaires au quotidien. Simples, pas jolis.
- Une mise en ligne sur votre vrai nom de domaine, pour que de vrais utilisateurs s'en servent dès le premier jour.
Web app ou application native ?
Pour une première version, nous partons par défaut sur une web app que l'on peut installer sur l'écran d'accueil. Pas de validation par les stores, et chaque mise à jour arrive chez les utilisateurs dès que nous la publions. Il y a des compromis, et nous les anticipons. D'après nos propres essais sur iPhone, l'icône et l'écran de démarrage restent ceux du moment de l'installation. Ceux qui ont installé tôt gardent les anciens jusqu'à ce qu'ils réinstallent. Nous verrouillons donc l'identité visuelle avant le lancement, pas pendant. Autre exemple : dans nos essais, une équipe qui scanne des QR codes chaque jour sur iPhone pouvait voir Safari redemander l'accès à la caméra d'un jour à l'autre, tant que le site n'était pas réglé sur « Autoriser ». Nous ajoutons un mode d'emploi unique directement dans l'écran de scan. Des détails, mais ce sont eux qui décident si l'équipe adopte l'outil dès la première semaine.
Ce qui attend la version 2, et ce que l'attente vous coûte
La liste de ce qui attend compte autant que celle de ce qui sort. Pour chaque élément, nous écrivons ce que son report vous coûte. Vous choisissez en connaissance de cause.
Les intégrations tierces deviennent une étape manuelle. Pour une campagne de course caritative, le plan prévoyait une synchronisation avec Strava pour suivre la progression de chaque coureur. Au moment de la faire, notre lecture des conditions de Strava a fait apparaître deux obstacles : un accès développeur qui ne rentrait pas dans le projet, et des règles d'affichage des données qui coinçaient sur une page de campagne publique. Nous avons donc remplacé la synchro par une case à cocher dans l'admin, et la progression se calcule à partir de là. C'est sorti tout de suite. Le coût de l'attente : quelqu'un coche une case quelques fois par semaine.
Les paiements deviennent un lien de paiement ou une facture. Selon Sprout, les produits avec facturation, plusieurs rôles ou des intégrations complexes demandent en réalité huit semaines ou plus. Le coût de l'attente : vous relancez quelques paiements à la main, le temps de savoir si les gens paient vraiment.
Rôles et permissions se réduisent à un seul admin. Le coût : vous gérez le back-office vous-même pendant un temps. Ce n'est pas un mal. Vous verrez précisément ce dont votre future équipe aura besoin.
Tableaux de bord, multilingue, parrainage et fidélité attendent. Le coût : un export tableur une fois par semaine.
Les flux de données collectées par scraping attendent. Écrire un scraper va vite. Le maintenir en vie, non. Les sites changent, bloquent les robots et cassent le flux, souvent sans la moindre erreur visible. Le vrai coût, c'est la maintenance, et elle ne s'arrête jamais.
Certaines choses ne rentrent tout simplement pas. Les produits réglementés en santé ou en fintech demandent environ 6 à 12 mois à cause de la conformité. Des textes et des images livrés en retard peuvent à eux seuls ajouter 1 à 2 semaines. Nous le disons dès le départ, plutôt que de faire semblant.
Comment nous cadrons et menons un MVP avec vous
Chez Pillet Grenié Bureau, la décision qui conditionne tout est celle-ci : nous ne confirmons une date qu'une fois le périmètre validé, risques compris. Une date donnée avant, c'est un chiffre que vous pourriez nous opposer et que nous ne pourrions pas tenir.
Notre garde-fou : lire le brief pour repérer ce qui manque. Les cahiers des charges qui arrivent « prêts à chiffrer » ont souvent été allégés des risques et du planning pour être plus lisibles. Quand nous le remarquons, nous demandons par écrit la version complète. Si elle n'existe pas, nous le disons clairement et construisons la liste des risques avec vous, comme première étape. Le manque devient alors un vrai chantier, pas une taxe cachée dans l'estimation.
Au lancement, nous vérifions aussi ce que vous avez déjà acheté. Il nous est arrivé de voir des fondateurs qui avaient réservé eux-mêmes leur nom de domaine repartir avec un hébergement et des options ajoutés au moment du paiement. Notre stack ne s'en sert pas, et tout se renouvelle chaque année. Nous vous le signalons avant que la deuxième année soit facturée.
De votre côté, il nous faut quatre choses : une personne qui décide, les contenus à une date convenue, l'accès à votre nom de domaine, et un court point hebdomadaire pour passer en revue ensemble la liste « plus tard ».
Le résultat : une date sur laquelle vous pouvez caler un lancement, une première version entre les mains de vos utilisateurs en 2 à 4 semaines, et une liste pour la version 2 où chaque élément a déjà une raison et un coût. Si votre idée tient en une routine, commencez par notre offre MVP : nous tracerons cette ligne avec vous.
