Combien de temps faut-il pour construire un MVP ? Un MVP web ciblé prend 3 à 5 semaines lorsqu'il teste un seul flux avec une authentification standard, un modèle de données et une métrique de succès. Il faut 6 à 12 semaines ou plus quand le cahier des charges inclut plusieurs rôles utilisateurs, des intégrations lourdes ou un cycle d'approbation en comité.
Ce qui est inconfortable, c'est que le calendrier est généralement une décision de périmètre, pas un fait d'ingénierie.
Si vous comparez des devis en ce moment, l'écart est probablement déroutant pour une bonne raison. Certaines équipes chiffrent un premier test, d'autres chiffrent une version réduite du produit final. Ce guide présente le calendrier utilisé chez webvise, les obstacles qui l'allongent et les règles de réduction qui empêchent un MVP de se prendre pour un produit complet.
- 3 à 5 semaines est réaliste pour un flux principal. Cela suppose un utilisateur principal, une tâche, un schéma de base de données, une métrique de lancement et des décisions rapides.
- 6 à 12 semaines est normal quand le périmètre comporte plusieurs rôles ou des intégrations profondes. Cela correspond à une première version plus large.
- La première semaine détermine le calendrier. Un accès tardif aux comptes, des règles d'acceptation floues et des décisions d'API reportées coûtent plus de temps que le code lui-même.
- webvise cadre les builds MVP autour d'un objectif d'apprentissage principal et peut livrer des premières versions ciblées en 3 à 5 semaines sur Next.js, PostgreSQL et Vercel, avec authentification, paiements et un environnement de démo prêt pour les investisseurs si nécessaire. Voir la fiche de service.
- Le MVP le plus sûr est le produit minimal capable de produire une décision dans les 30 jours suivant le lancement.
La réponse courte selon le périmètre
Les guides de calendrier MVP publics se situent généralement entre 4 et 12 semaines. Cette fourchette masque la vraie question utile : quel type de MVP est sur la table ?
Chez webvise, la réponse se divise selon la forme du périmètre. La promesse de 3 à 5 semaines correspond à un MVP web avec un flux clairement défini, une stack technique fixée et un décideur capable de réduire les fonctionnalités pendant le build.
| Forme du périmètre | Calendrier typique | Ce que cela prouve |
|---|---|---|
| Prototype cliquable | 2 à 5 jours | Un utilisateur comprend-il l'offre et le parcours ? |
| Test sans code | 1 à 2 semaines | Des personnes cliquent-elles, s'inscrivent-elles ou paient-elles avant que le logiciel existe ? |
| MVP web ciblé | 3 à 5 semaines | Un utilisateur peut-il compléter le flux principal avec des données réelles ? |
| MVP produit standard | 6 à 12 semaines | Plusieurs rôles peuvent-ils utiliser le produit avec de vraies intégrations ? |
| MVP réglementé ou place de marché | 12 semaines ou plus | Le produit gère-t-il les risques, les permissions, la conformité ou la demande bilatérale ? |
Si votre idée nécessite d'abord une page d'atterrissage, une liste d'attente et un suivi manuel, ne payez pas encore pour un MVP. Si elle nécessite une authentification, un flux, une base de données, un déploiement et des analyses, elle entre dans le périmètre du développement MVP webvise.
La version semaine par semaine
Un MVP en 3 à 5 semaines fonctionne quand les décisions risquées sont prises avant le lancement et que la première version est suffisamment restreinte pour être testée rapidement.
| Phase | Ce qui se passe | Décision requise |
|---|---|---|
| Avant le lancement | Objectif d'apprentissage, utilisateur, flux, métrique de lancement, comptes et réductions fermes sont définis | Un responsable accepte les limites du périmètre |
| Semaine 1 | Flux UX, modèle de données, authentification, déploiement et premier parcours cliquable | Aucun nouveau rôle utilisateur sans supprimer quelque chose |
| Semaine 2 | Flux principal, écritures en base, parcours email ou paiement, besoin d'administration basique | Les intégrations restent standard sauf si elles prouvent le produit |
| Semaine 3 | Données réelles, analyses, gestion des erreurs, vérifications mobile, premier test interne | Seuls les défauts et les bloquants de lancement entrent dans le périmètre |
| Semaine 4 | Finitions côté utilisateur, copie, transmission, suivi, déploiement en production | Le lancement prime sur un autre cycle de modifications préférentielles |
| Semaine 5 | Marge pour les retours, cas limites de paiement, problèmes d'API partenaire ou nettoyage de données | Tout ce qui n'est pas lié au lancement est reporté après la mise en ligne |
La stack n'est pas le secret. webvise construit généralement ce niveau avec Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel et des analyses basiques. La rapidité vient de l'utilisation de composants éprouvés et du refus d'inventer une infrastructure avant que le produit ait des preuves.
Ce qui transforme 3 semaines en 3 mois
La plupart des retards de MVP ne viennent pas de l'ingénierie. Ils viennent de décisions restées floues parce que l'équipe a évité de supprimer des fonctionnalités accessoires.
| Source du retard | Comment ça se présente | Comment tenir le calendrier |
|---|---|---|
| Rôles utilisateurs | "L'administrateur, l'acheteur, le vendeur, le partenaire et le support ont tous besoin de tableaux de bord" | Choisir un utilisateur principal et un opérateur interne |
| Intégrations | "Il nous faut le CRM, la facturation, les analyses, Slack et l'ancienne base de données dès le premier jour" | Garder uniquement le système nécessaire pour prouver le flux |
| Cycles d'approbation | "L'équipe examinera quand tout le monde aura le temps" | Nommer un seul décideur avec un délai de réponse de 24 heures |
| Périmètre de design | "Terminons tous les écrans dans Figma avant de développer" | Designer le parcours principal d'abord et peaufiner après que cela fonctionne |
| Exigences de conformité | "Nous aurons peut-être besoin de journaux d'audit plus tard" | Construire uniquement les contrôles légaux et de sécurité nécessaires pour les premiers utilisateurs |
C'est pourquoi un brief MVP court compte plus qu'une longue liste de fonctionnalités. Le modèle présenté dans le guide du document d'exigences MVP est la version souhaitée avant de démarrer un build cadré.
Mini-récit : le périmètre était juste pour une raison
Dans un MVP immobilier, la date limite n'était pas arbitraire. La promesse commerciale était précise : un acheteur devait recevoir un certificat de financement contraignant sans consultation du bureau de crédit, pendant que le système comparait les offres des banques partenaires en arrière-plan. Ce type de produit peut avancer rapidement quand la première version protège un seul flux au lieu de vouloir devenir une plateforme financière complète.
Ce n'était pas un petit MVP, et l'appeler ainsi aurait été malhonnête. La première version nécessitait un flux de financement complet, une génération automatisée de certificats PDF et un tableau de bord d'administration pour le cycle de vie des demandes.
Le résultat est resté sobre : un build ciblé, de fortes performances Lighthouse, des chargements de page rapides et une remise des certificats dans la fenêtre de service promise. Le calendrier s'est allongé parce que le flux impliquait des données financières réelles et une transmission opérationnelle réelle, pas parce que l'équipe ajoutait des fonctionnalités décoratives.
Mini-récit : les MVP vibe-codés économisent des jours, puis perdent des semaines
Le 2026-05-18, j'ai écrit sur les MVP Lovable, Bolt et v0. Ces outils sont utiles pour les prototypes parce qu'ils rendent l'idée d'un fondateur visible en quelques heures. Le problème commence quand un prototype est traité comme la fondation du produit.
Le schéma est suffisamment constant pour que j'aie formulé une règle : quand une application vibe-codée a de vrais utilisateurs, je la reconstruis plutôt que de la patcher. Un build propre sur ma stack prend généralement 3 à 6 semaines. Le travail de récupération 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 en production qui n'ont jamais été conçus délibérément.
C'est la réponse moins spectaculaire, mais elle est plus respectueuse du budget. Utilisez les constructeurs d'applications IA pour comprendre ce que le produit doit faire. Utilisez un build MVP quand ce dont vous avez besoin est de données fiables provenant d'utilisateurs réels.
Le test de calendrier en 30 minutes
Avant de demander un calendrier à une agence, faites passer votre périmètre 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 tout le monde ?
- Un flux : quelles étapes amènent cet utilisateur de l'entrée à la valeur ?
- Une métrique : quel chiffre vous indique dans les 30 jours si vous devez continuer ?
- Un responsable : qui peut réduire ou accepter le périmètre dans les 24 heures ?
- Comptes prêts : les comptes d'authentification, de paiement, d'email, d'analyses, d'hébergement et de base de données sont-ils disponibles ?
- Réductions fermes : qu'est-ce qui ne sera pas livré avant le lancement, même si quelqu'un le demande ?
Si les réponses tiennent sur une page, un MVP de 3 à 5 semaines peut être réaliste. Si les réponses nécessitent un atelier, commencez par le brief. La version coût de la même décision se trouve dans le guide du coût de développement MVP.
Quand un MVP plus long est la réponse honnête
Certaines premières versions ne doivent pas être comprimées en 5 semaines. Les données réglementées, les déclarations médicales, les décisions financières, les places de marché, les boutiques d'applications mobiles et les API partenaires complexes peuvent toutes justifier un build plus long.
Le test est simple : le temps supplémentaire protège-t-il un utilisateur réel, une transaction réelle ou une obligation légale réelle ? Si oui, gardez-le. Si le temps supplémentaire rend uniquement le produit plus complet en apparence, supprimez-le.
webvise aide les fondateurs à trancher avant que le code démarre. Si votre MVP doit être suffisamment restreint pour 3 à 5 semaines, le service de développement MVP est la bonne option. Si c'est déjà une plateforme de production, vous l'entendrez clairement, et le cadrage sera différent.
Un bon calendrier MVP vient d'un périmètre clair, de décisions rapides et d'une première version qui existe pour répondre à une question commerciale. Pour que webvise passe votre brief en revue avant de construire, envoyez-le.