"Il nous faut un MVP pour demain." Si vous êtes fondateur, vous avez déjà eu cette conversation. Avec un investisseur qui veut du concret, un prospect qui réclame une démo, ou un associé qui commence à douter. La plupart des agences vous répondent 3 à 6 mois. Nous, on répond 6 jours.

Depuis deux ans, on a livré une trentaine de MVP sur ce format. La grande majorité part en prod, et environ deux tiers finissent par trouver leur Product Market Fit sur les itérations suivantes. Honnêtement, sans l'outillage IA qu'on utilise au quotidien (Cursor, Copilot, ChatGPT), on serait plutôt à 3-4 semaines qu'à 6 jours.

Voici comment ça se passe en pratique, et surtout dans quels cas ça ne marche pas.

Pourquoi 6 jours plutôt que 6 semaines

Quand vous lancez, votre vrai ennemi c'est l'incertitude. Tant que vos hypothèses ne rencontrent pas de vrais utilisateurs, vous dépensez du temps et de l'argent sur des suppositions. Chaque semaine passée à peaufiner en interne est une semaine sans signal du marché.

Les exemples connus vont tous dans ce sens. Slack est né d'un outil de communication interne transformé en produit, mis très tôt entre les mains d'utilisateurs réels plutôt que peaufiné en chambre. Dropbox a validé son idée avec une simple vidéo de démo, qui a déclenché des dizaines de milliers d'inscriptions sur la liste d'attente avant même que le produit existe. Buffer s'est contenté d'une landing page pour mesurer l'intérêt réel avant d'écrire la moindre ligne de code.

Le calcul est simple. Avec un MVP en ligne au jour 7, vous avez vos premiers utilisateurs réels autour du jour 10, du feedback qualitatif vers le jour 15, et une première itération sérieuse au jour 20. Pendant ce temps, l'approche classique en est encore à la phase de specs. C'est là que se joue l'écart : vous apprenez sur le terrain pendant que les autres réfléchissent en chambre.

Notre framework Sprint MVP, jour par jour

Le découpage qui suit n'a rien de magique. C'est surtout une discipline : un livrable concret chaque jour, et aucune journée passée à découvrir un outil.

Jour 1 — Architecture et wireframes

La matinée sert à cadrer. On analyse le besoin business, on tranche sur les trois features qui portent réellement la valeur, et on fige la stack. L'après-midi part sur les user stories prioritaires, des wireframes haute fidélité et la validation de l'architecture technique. À la fin de la journée, on a des specs complètes et des maquettes. Rien de spectaculaire, mais c'est la journée qui évite de tout refaire au jour 4.

Jours 2-3 — Développement du cœur

On attaque le code sur une stack qu'on ne discute pas :

- Next.js 15 (React Server Components)
- TypeScript (0 erreur tolérée)
- Tailwind CSS + shadcn/ui
- Prisma + PostgreSQL (Supabase)
- Authentication (NextAuth ou Clerk)

En deux jours, on monte la landing et l'onboarding, l'authentification, la feature principale et un dashboard basique. À la fin du jour 3, l'application tourne avec environ 80% des fonctionnalités en place. C'est moche par endroits, mais ça marche.

Jours 4-5 — Finitions et intégrations

On passe sur la performance (Core Web Vitals), le SEO technique, le responsive et les tests utilisateur internes. C'est aussi le moment de brancher tout ce qui fait tourner une vraie app : analytics (Google Analytics 4), monitoring d'erreurs (Sentry), support client (Intercom ou Crisp), et les paiements via Stripe si le modèle l'exige. Au jour 5, l'application est production-ready.

Jour 6 — Déploiement et lancement

Le matin, on déploie : hébergement sur Vercel ou Netlify, domaine configuré, SSL, monitoring actif. L'après-midi, c'est le soft launch. On teste en conditions réelles, on forme l'équipe du client, on rédige la doc utilisateur, et on cale la stratégie de lancement pour le jour 7. Vous repartez avec un MVP en ligne et un plan pour le mettre entre les mains de vos premiers utilisateurs.

Cinq Sprint MVP qu'on a vraiment livrés

Une plateforme de matching startup/talents (FinTech)

Le client voulait connecter des startups avec des freelances tech qualifiés. On a construit les profils des deux côtés, un matching par compétences, un chat intégré et un paiement sécurisé via Stripe Connect, le tout en cinq jours sur Next.js + Supabase. Il y a eu 200 inscrits dans les 48 heures et une première transaction au jour 10.

Un SaaS de gestion RH pour PME (B2B)

L'objectif : simplifier la gestion des congés pour les PME réunionnaises. Dashboard RH, calendrier des congés, notifications automatiques et export PDF, livrés en six jours sur Next.js + Prisma + PostgreSQL + Resend. Résultat à 30 jours : 12 PME clientes et 1 200 € de MRR.

Une marketplace de produits locaux (E-commerce)

Vendre les produits péi en ligne. On a monté un catalogue avec filtres, un panier et un checkout Stripe, la gestion des commandes et une interface vendeur en quatre jours (Next.js + WooCommerce API + Stripe). Deux semaines après le lancement, 50 produits étaient en ligne pour environ 1 000 visites par jour.

Une app de covoiturage inter-îles (Mobilité)

Connecter La Réunion et Maurice pour les voyageurs. Recherche de trajets en temps réel, chat conducteur/passager, paiement intégré et notifications push, le tout en PWA (Next.js + Socket.io + MapBox), livré en six jours. La première semaine a généré 300 téléchargements.

Une plateforme e-learning créole (EdTech)

Apprendre le créole réunionnais en ligne. Cours vidéo interactifs, exercices et quiz, progression gamifiée et mode hors-ligne (Next.js + Cloudinary + Stripe, en PWA), en cinq jours. Trois semaines plus tard, 500 utilisateurs s'étaient inscrits, avec un taux de complétion qui tournait autour de 89%.

Ce qui rend ces sprints possibles

Tenir six jours ne tient pas à une recette secrète. Ça tient à trois choix qu'on s'impose.

D'abord, une seule stack, maîtrisée à fond : Next.js 15 pour la performance et le SEO, TypeScript strict, Tailwind avec shadcn/ui pour un design cohérent, Prisma et PostgreSQL côté données. On connaît chaque composant par cœur, donc on ne perd jamais de temps à découvrir un outil ou à déboguer une config exotique.

Ensuite, une librairie interne déjà prête : 47 composants UI, 12 templates de pages courantes, 8 intégrations business pré-câblées (auth, paiements, analytics). Concrètement, on démarre chaque projet avec environ 40% du code déjà écrit et testé.

Enfin, une règle qui fait mal mais qui sauve les délais : trois features, pas une de plus. La valeur unique du produit, la gestion des utilisateurs (inscription, connexion, profil), et une feature business (paiement, analytics ou growth). Tout le reste attend la v2. Sans exception.

Pourquoi ces MVP trouvent leur marché

La vitesse de mise en ligne n'est pas une fin en soi. Ce qu'elle débloque, c'est un cycle de feedback court. MVP en ligne la première semaine, 50 à 100 premiers utilisateurs la deuxième, feedback qualitatif structuré la troisième, première itération majeure la quatrième. Vous ajustez le tir avant même que vos concurrents aient écrit leur première ligne de code.

Au passage, on valide quatre choses : la faisabilité technique avec une architecture qui tient, l'UX avec une interface utilisable, le business avec des métriques de conversion trackées, et le marché avec du vrai feedback utilisateur. Et comme l'architecture est pensée pour grandir dès le départ (base de données dimensionnée pour la montée en charge, code modulaire, infra cloud auto-scalante, monitoring intégré), il n'y a pas de refonte technique à prévoir au bout de six mois. Le produit grandit sans tout réécrire.

Quand un Sprint MVP n'est pas adapté

Le format ne convient pas à tout le monde, et autant le dire avant de perdre du temps tous les deux.

Il ne marche pas sur les projets intrinsèquement complexes : une marketplace avec quinze types d'utilisateurs, un SaaS enterprise à cinquante features, une app mobile native lourde, ou un produit qui repose sur de l'IA custom. Ces sujets demandent une autre temporalité, point.

Il ne marche pas non plus quand l'équipe n'est pas prête : pas de validation business en amont, indisponibilité pendant les six jours, aucun budget pour les itérations, ou un scope irréaliste qu'on n'arrivera pas à tenir.

En revanche, il colle bien à un SaaS B2B avec un workflow simple, une marketplace deux faces basique, une web app progressive, ou un projet e-commerce/contenu. Si vous vous reconnaissez là, c'est jouable.

Démarrer votre Sprint MVP

Pour que les six jours soient utiles, il faut arriver préparé. Côté business : un problem/solution fit déjà validé, des personas définis, un business model clair, et un budget pour les itérations post-MVP (le MVP n'est pas la ligne d'arrivée). Côté technique : les trois features prioritaires listées, des wireframes ou des références visuelles, un nom de domaine disponible et les accès aux services tiers (analytics, hosting, etc.).

Concrètement, on travaille en trois temps. Une qualification d'une heure, gratuite, pour auditer le projet, vérifier la faisabilité en six jours et poser le budget et le planning. Puis le Sprint MVP lui-même sur six jours, avec un daily à 9h, des livraisons quotidiennes, des tests utilisateur en continu et la formation de l'équipe. Et enfin 30 jours de support post-launch : monitoring, support technique illimité, une itération majeure incluse et des conseils growth.

Côté budget, le Sprint MVP est à 8 000 € : six jours de développement, une stack moderne et scalable, la formation de l'équipe et le mois de support. Pour comparer, le même périmètre développé en interne (un dev sur 3 à 6 mois) revient plutôt à 25-40 k€, et surtout vous fait perdre les semaines qui comptent le plus, celles où vous pourriez déjà apprendre de vos utilisateurs.

Si vous voulez tester

Le format ne convient pas à tout le monde. Si votre idée n'est pas encore validée côté business, on perdra du temps tous les deux. Si elle l'est, 30 minutes suffisent pour voir si c'est jouable en 6 jours, sur quelle stack, et où il faudra couper.

Créneau : calendly.com/contact-techsprint

Fabrice Payet — TechSprint, basé à La Réunion.

Développer un MVP en 6 jours : Notre méthode Sprint MVP