Combien de temps faut-il pour construire un MVP ? Un plan réaliste sur 3 à 5 semaines
Un MVP ciblé prend 3 à 5 semaines lorsqu'il teste un workflow avec une auth standard, un modèle de données et une métrique de succès. Voici le calendrier honnête.
Combien de temps faut-il pour construire un MVP ? Un MVP web ciblé prend 3 à 5 semaines lorsqu'il teste un workflow avec une auth standard, un modèle de données et une métrique de succès. Il prend 6 à 12 semaines ou plus lorsque le brief inclut plusieurs rôles, des intégrations lourdes ou une validation par comité.
La partie inconfortable est simple : le calendrier est souvent une décision de scope, pas une vérité d'ingénierie.
Si vous comparez des devis en ce moment, l'écart est probablement déroutant pour une raison valable. Certaines équipes chiffrent un premier test, tandis que d'autres chiffrent une petite version du produit final. Ce guide vous donne le calendrier que nous utilisons chez webvise, les blocages qui l'allongent, et les règles de coupe qui empêchent un MVP de se faire passer pour un build complet.
3 à 5 semaines sont réalistes pour un workflow central. Cela veut dire un utilisateur principal, une tâche, une forme de base de données, une métrique de lancement et des décisions rapides.
6 à 12 semaines sont normales lorsque le scope contient plusieurs rôles ou des intégrations profondes. Ce n'est pas un échec. C'est une première version plus grande.
La première semaine décide du calendrier. Les accès lents, les critères d'acceptation flous et les décisions API tardives coûtent plus de temps que le code.
webvise construit des MVP à partir de 5 000 € en 3 à 5 semaines lorsque le scope correspond à cette forme. La fiche service est ici : MVP development.
Le MVP le plus sûr n'est pas la plus petite liste de fonctionnalités. C'est le plus petit produit capable de produire une décision dans les 30 jours après le lancement.
La réponse courte selon le scope
Les guides publics sur les calendriers MVP se situent généralement entre 4 et 12 semaines. Cette plage n'est pas fausse, mais elle cache la vraie question utile : de quel type de MVP parlons-nous ?
Chez webvise, nous séparons la réponse selon la forme du scope. La promesse de 3 à 5 semaines s'applique à un MVP web avec un workflow clair, un stack technique fixé et un responsable capable de couper des fonctionnalités pendant le build.
| Forme du scope | Calendrier typique | Ce que cela prouve |
|---|---|---|
| Prototype cliquable | 2 à 5 jours | Quelqu'un comprend-il l'offre et le flux ? |
| Test No-code | 1 à 2 semaines | Les gens cliquent-ils, s'inscrivent-ils ou paient-ils avant que le logiciel existe ? |
| MVP web ciblé | 3 à 5 semaines | Un utilisateur peut-il terminer le workflow central avec de vraies données ? |
| MVP produit standard | 6 à 12 semaines | Plusieurs rôles peuvent-ils utiliser le produit avec de vraies intégrations ? |
| MVP réglementé ou marketplace | 12+ semaines | Le produit peut-il gérer le risque, les droits, la conformité ou une demande à deux côtés ? |
Si votre idée a d'abord besoin d'une landing page, d'une liste d'attente et d'un suivi manuel, ne payez pas encore pour un MVP. Si elle a besoin d'auth, d'un workflow, d'une base de données, d'un déploiement et d'analytics, elle correspond à la voie MVP development de webvise.
La version semaine par semaine
Un MVP en 3 à 5 semaines n'est pas un produit complet compressé. C'est un build où les décisions risquées sont prises avant le kickoff et où la première version reste assez étroite pour être testée vite.
| Phase | Ce qui se passe | Décision nécessaire |
|---|---|---|
| Avant le kickoff | Objectif d'apprentissage, utilisateur, workflow, métrique de lancement, comptes et coupes fermes sont nommés | Un responsable accepte les limites du scope |
| Semaine 1 | Flux UX, modèle de données, auth, déploiement et premier chemin cliquable | Aucun nouveau rôle utilisateur sans retirer autre chose |
| Semaine 2 | Workflow central, écritures en base, chemin email ou paiement, besoin admin de base | Les intégrations restent standard sauf si elles prouvent le produit |
| Semaine 3 | Données réelles, analytics, gestion des erreurs, contrôles mobile, premier test interne | Seuls les défauts et blocages de lancement entrent dans le scope |
| Semaine 4 | Finition côté utilisateur, copy, passation, tracking, déploiement production | Lancer vaut mieux qu'un nouveau cycle de préférences |
| Semaine 5 | Marge pour retours, cas de paiement, problèmes d'API partenaire ou nettoyage de données | Tout ce qui n'est pas lié au lancement passe après la sortie |
Le stack n'est pas le tour de magie. webvise construit généralement ce niveau avec Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel et des analytics de base. La vitesse vient de pièces connues et du refus d'inventer de l'infrastructure avant que le produit ait des preuves.
Ce qui transforme 3 semaines en 3 mois
La plupart des retards MVP ne viennent pas d'une ingénierie difficile. Ils viennent de décisions laissées molles parce que personne ne voulait couper le travail agréable mais non essentiel.
| Source de retard | Ce que cela donne | Comment garder le calendrier |
|---|---|---|
| Rôles utilisateur | 'Admin, acheteur, vendeur, partenaire et support ont tous besoin de dashboards' | Choisir un utilisateur principal et un opérateur interne |
| Intégrations | 'Nous avons besoin de CRM, billing, analytics, Slack et l'ancienne base dès le premier jour' | Garder uniquement le système nécessaire pour prouver le workflow |
| Boucles de validation | 'L'équipe relira quand tout le monde aura du temps' | Nommer un responsable de coupe avec réponse en 24 heures |
| Scope design | 'Finissons tous les écrans dans Figma avant de construire' | Designer d'abord le chemin central et polir après qu'il fonctionne |
| Claims conformité | 'Nous aurons peut-être besoin d'audit logs plus tard' | Construire seulement les contrôles juridiques et de sécurité nécessaires aux premiers utilisateurs |
C'est pourquoi un brief MVP court compte plus qu'une longue liste de fonctionnalités. Le modèle dans notre guide du MVP requirements document est la version que nous voulons voir avant un build au forfait.
Mini-histoire : OHYP avait besoin de 6 semaines pour les bonnes raisons
Le 2026-02-20, nous avons publié la case study OHYP GmbH, un service immobilier berlinois qui avait besoin de certificats de financement pour des acheteurs en Allemagne. La promesse business était précise : un acheteur devait recevoir un certificat contraignant en moins de 24 heures, sans demande SCHUFA, pendant que le système comparait plus de 550 banques partenaires.
Ce n'était pas un MVP de 3 semaines, et l'appeler ainsi aurait été malhonnête. La première version avait besoin d'un formulaire de financement en 10 étapes, d'une génération automatique de certificats PDF et d'un dashboard admin pour gérer le cycle de vie des demandes.
Le résultat est resté lean : 6 semaines, 96 de performance Lighthouse, moins de 1,2 s de chargement, et une délivrance de certificat en moins de 24 heures. Le calendrier a dépassé 5 semaines parce que le workflow portait de vraies données financières et une vraie passation opérationnelle, pas parce que l'équipe ajoutait des fonctionnalités décoratives.
Mini-histoire : les MVP vibe-coded gagnent des jours, puis perdent des semaines
Le 2026-05-18, nous avons écrit sur les MVP Lovable, Bolt et v0. Ces outils sont utiles pour les prototypes parce qu'ils rendent visible l'idée d'un fondateur en quelques heures. Le problème commence quand un prototype est traité comme la fondation du produit.
Le pattern est assez constant pour que nous ayons écrit une règle : lorsqu'une app vibe-coded a de vrais utilisateurs, nous la reconstruisons au lieu de la rafistoler. Un build propre sur notre stack prend généralement 3 à 6 semaines. Le sauvetage peut prendre 8 à 12 semaines parce que chaque correction doit respecter un schéma, une structure de routes et un modèle de données live que personne n'a conçus.
C'est la réponse la moins spectaculaire, mais elle est plus juste pour le budget. Utilisez les AI app builders pour apprendre ce que le produit doit faire. Utilisez un build MVP lorsque la prochaine chose dont vous avez besoin est une donnée fiable issue de vrais utilisateurs.
Le test de calendrier en 30 minutes
Avant de demander un calendrier à une agence, faites passer le scope par ce test. Si vous ne pouvez pas y répondre en 30 minutes, le projet n'est pas encore prêt pour un calendrier fixe.
Une phrase : quelle hypothèse risquée la version un doit-elle prouver ?
Un utilisateur : qui utilise la première version avant tous les autres ?
Un workflow : quelles étapes mènent cet utilisateur de l'entrée à la valeur ?
Une métrique : quel nombre vous dit en 30 jours si vous devez continuer ?
Un responsable : qui peut couper ou accepter le scope en 24 heures ?
Comptes connus : quels comptes auth, paiement, email, analytics, hébergement et base de données sont prêts ?
Coupes fermes : qu'est-ce qui ne sortira pas avant le lancement, même si quelqu'un le demande ?
Si les réponses tiennent sur une page, un MVP en 3 à 5 semaines peut être réaliste. Si les réponses demandent un workshop, commencez par le brief. La version coût de la même décision se trouve dans notre guide des coûts de développement MVP.
Quand un MVP plus long est la réponse honnête
Certaines premières versions ne devraient pas être comprimées en 5 semaines. Les données réglementées, les claims médicaux, les décisions financières, les marketplaces, les app stores mobiles et les API partenaires complexes peuvent tous justifier un build plus long.
Le test est simple : le temps en plus protège-t-il un vrai utilisateur, une vraie transaction ou une vraie obligation légale ? Si oui, gardez-le. Si ce temps rend seulement le produit plus complet en apparence, coupez-le.
webvise aide les fondateurs à prendre cette décision avant le code. Si votre MVP doit être assez étroit pour 3 à 5 semaines, notre service MVP development est la bonne voie. Si c'est déjà une plateforme de production, nous le dirons et nous cadrerons autrement.
Un bon calendrier MVP n'est pas une posture. C'est la conséquence d'un scope clair, de décisions rapides et d'une première version faite pour répondre à une question business. Si vous voulez que webvise challenge votre brief avant de construire, envoyez-le-nous.