Un MVP web ciblé se construit en six semaines environ : le cadrage en semaine 1, le design cliquable en semaine 2, le développement des semaines 3 à 5 et le lancement en semaine 6. Le calendrier et le prix sont fixés avant le début du travail. Les apps mobiles, les intégrations lourdes, les changements de périmètre et les retours lents peuvent rallonger le délai.
Quand vous payez pour faire construire un produit, le plus difficile n'est souvent pas le prix. C'est de ne pas savoir ce qui se passe, ni quand vous verrez quelque chose de concret. Cet article détaille, semaine par semaine, comment nous menons un MVP web ciblé du lancement du projet à la mise en ligne en six semaines environ. Il suit les quatre étapes de la méthode de notre MVP sprint pour fondateurs : cadrage, design, développement, puis lancement et itération.
Une précision honnête d'abord. La répartition exacte entre les étapes dépend de votre produit. Ce qui suit est le déroulé habituel d'un MVP web ciblé. Le vrai calendrier de votre projet est fixé dès le départ, avant le début du travail, et nous nous y tenons.
Avant la semaine 1 : ce qui est fixé dès le départ
Avant que les six semaines commencent, deux choses sont claires : le calendrier et le prix. Nous donnons un prix fixe pour le périmètre, pas un tarif horaire, donc vous connaissez le coût avant tout travail. Pour comparer avec les autres options, notre guide sur le coût d'un MVP en 2026 donne les fourchettes du marché.
Si vous arrivez avec un prototype construit avec un outil d'IA ou du no-code, il devient le cahier des charges. Nous gardons ce qui marche et construisons la version production autour. Si le prototype est brouillon, nous commençons par un audit de sauvetage pour trouver le chemin le plus rapide et le plus sûr. Nous expliquons pourquoi un prototype n'est pas encore un produit dans du prototype IA au produit réel sur ce blog.
Semaine 1 : le cadrage
Ce que nous faisons. Nous cernons le problème, les utilisateurs et le parcours clé : le seul chemin dans votre produit qui doit parfaitement fonctionner. Nous décidons ce qui attendra la version deux. Puis nous figeons le plus petit périmètre qui prouve l'idée.
Ce que vous faites. Répondre à beaucoup de questions, et trancher. Le plus utile cette semaine : dire « pas maintenant » à de bonnes idées dont vous n'avez pas besoin le premier jour.
Ce que vous avez à la fin. Un périmètre clair et écrit. Tout le monde sait ce qui sera construit, et ce qui ne le sera pas.
Semaine 2 : le design
Ce que nous faisons. Nous concevons les écrans et les parcours clés, cliquables avant la première ligne de code. Vous les parcourez, nous affinons, et nous recommençons jusqu'à ce que ce soit juste.
Ce que vous faites. Tout parcourir, comme un nouvel utilisateur. Si possible, montrez-le à quelques personnes de votre cible. Changer un écran maintenant prend quelques minutes. Le changer une fois développé prend des jours.
Ce que vous avez à la fin. Un design cliquable de votre produit, que vous pouvez déjà montrer autour de vous.
Semaines 3 à 5 : le développement
Ce que nous faisons. Nous construisons par cycles courts sur Next.js, Vercel et Supabase, avec des versions à tester au fil de l'eau. C'est là que les fondations que les prototypes laissent de côté sont faites dans les règles :
- Des comptes sécurisés. Connexions, rôles et données de chaque utilisateur bien séparés, vérifiés avant le lancement.
- Des données qui tiennent. Un modèle pensé pour dix mille utilisateurs, pas seulement pour les dix premiers.
- Des paiements de bout en bout. Paiement, abonnements, échecs de prélèvement et reçus gérés proprement.
- Rapide sur de vrais appareils. Testé sur de vrais téléphones et des connexions lentes, pas seulement sur un ordinateur.
Le développement assisté par l'IA explique en grande partie pourquoi tout cela tient en quelques semaines. Nous l'utilisons comme un outil, pas comme un raccourci : tout ce qui est mis en ligne est testé et construit sur une stack que nous maîtrisons.
Ce que vous faites. Tester chaque version et donner vos retours vite. Préparer ce que vous seul pouvez fournir : les textes, les prix, les pages légales. Il est aussi utile d'avoir vos propres comptes prêts, par exemple pour les paiements et le nom de domaine, car le code, les comptes et les données sont à vous dès le premier jour.
Ce que vous avez à la fin. Un produit qui fonctionne et remplit sa fonction principale, avec de vrais comptes, de vraies données et de vrais paiements.
Semaine 6 : le lancement
Ce que nous faisons. Nous préparons le produit pour de vraies personnes. Nom de domaine, analytics, e-mails transactionnels (confirmation d'inscription, reçus, mot de passe oublié) et suivi des erreurs sont en place avant votre premier inscrit. Puis nous le mettons entre les mains de vrais utilisateurs.
Ce que vous faites. Inviter vos premiers utilisateurs. Leur dire à quoi sert le produit, et leur demander de l'utiliser pour de vrai.
Ce que vous avez à la fin. Un produit en ligne, et un suivi des erreurs qui nous alerte d'un problème avant que vos utilisateurs aient à vous écrire.
Un MVP est petit par son périmètre, pas par sa qualité. Six semaines, c'est possible parce que le périmètre est petit, pas parce qu'on saute des étapes.
Après la semaine 6 : lancement et itération
Le lancement est le début de l'apprentissage, pas la fin du projet. Nous observons comment les gens utilisent le produit et l'améliorons à partir de ce que nous apprenons. Après le lancement, un plan de maintenance le garde en bonne santé, et un partenariat produit le fait évoluer selon les retours de vos utilisateurs. Une fois l'idée validée, les apps iOS et Android peuvent partir du même code et être publiées sur l'App Store et Google Play.
Ce qui peut rallonger le calendrier
- Des apps mobiles dès le départ. Les apps iOS et Android ajoutent du temps. C'est pourquoi nous commençons en général par le web : c'est le moyen le plus rapide de toucher des utilisateurs et d'apprendre.
- Des intégrations lourdes. Se connecter à de nombreux systèmes externes ajoute du travail, et c'est prévu dans le calendrier dès le départ.
- Changer le périmètre après l'avoir figé. Ajouter des fonctionnalités en plein développement repousse tout. Notez-les plutôt pour la version deux.
- Des retours lents ou des contenus manquants. Si une version attend une semaine votre avis, le lancement attend une semaine aussi.
Comment vous préparer
- Écrivez la seule chose que votre produit doit faire. Une phrase suffit.
- Connaissez vos premiers utilisateurs. Qui l'essaiera en semaine 6, et comment allez-vous les toucher ?
- Gardez du temps pour décider. Des réponses rapides gardent les six semaines sur les rails.
- Apportez ce que vous avez. Notes, croquis, prototype. Même un prototype brouillon est un cahier des charges clair.
En résumé
Six semaines, ce n'est pas de la magie. C'est un petit périmètre, un plan fixe, et quelque chose à voir et à tester à chaque étape. Pour savoir à quoi cela ressemblerait pour votre idée, découvrez comment fonctionne notre MVP sprint et dites-nous où vous en êtes. Nous fixerons un calendrier et un prix fixe avant tout travail.
