De l'idée au MVP en 6 semaines : ce que j'ai appris

Six semaines pour passer d'une idée à un produit en production : c'est la contrainte la plus fréquente sur laquelle j'interviens. Et celle qui apprend le plus sur ce qui compte vraiment dans un produit — parce qu'elle force à choisir.

Ce n'est pas une méthode universelle. C'est ce qui fonctionne sur des projets SaaS B2B avec une équipe de 1 à 3 personnes. Si votre contexte est différent, ajustez — mais les principes tiennent.

Semaine 1 — décider ce qu'on ne fait pas

La première semaine ne produit aucun code. On passe 80 % du temps à couper des fonctionnalités. Un backlog de 40 items devient un périmètre de 8. La règle de sélection est simple : si la fonctionnalité ne touche pas directement le problème principal, elle est hors scope.

On documente le problème en une phrase : « [type d'utilisateur] perd [temps ou argent] à cause de [problème précis]. » Si on ne peut pas écrire cette phrase sans ambiguïté, le cadrage n'est pas terminé. C'est inconfortable. C'est nécessaire.

Semaines 2-3 — choix de stack et setup

Sur un SaaS B2B en 2026, la stack qui minimise le time-to-production sans accumuler de dette technique précoce :

• Next.js App Router — SSR natif, API routes, déploiement zero-config sur Vercel ou Netlify.
• Supabase — Postgres managé, authentification en une demi-journée, row-level security dès le départ.
• Stripe — intégration de paiement en une journée, webhooks bien documentés.
• Resend ou Postmark — emails transactionnels fiables sans configuration de serveur SMTP.

Ces choix ne sont pas les seuls bons. Ils sont les plus rapides à assembler de façon cohérente. Le setup initial — CI/CD, environnements staging et production, monitoring basique avec Sentry — prend deux jours. C'est du temps « improductif » en apparence. En pratique, il évite une semaine de dettes à mi-parcours.

Semaines 4-5 — build

Deux sprints d'une semaine avec une démo en fin de chaque. Pas de réunion quotidienne — un message asynchrone chaque soir : qu'est-ce qui est livré, qu'est-ce qui bloque, qu'est-ce qui est prévu demain. Court, factuel, traçable.

Règle d'arbitrage : si une fonctionnalité prend plus de deux jours, on la coupe ou on la simplifie. Les estimations à ce stade sont rarement justes — la règle protège le planning sans avoir à débattre de chaque dérive.

Un MVP est une question, pas un produit fini. La question : est-ce que ce problème vaut d'être résolu, avec cette solution, pour cet utilisateur ?

Semaine 6 — mise en production et premiers retours

La livraison n'est pas la fin — c'est le début du retour terrain. On met en production, on organise une session guidée avec les premiers utilisateurs, et on identifie les trois irritants les plus fréquents. Ces irritants deviennent le backlog de la version 1.1.

Ce que je surveille à ce stade : est-ce que les utilisateurs reviennent sans qu'on les relance ? Si oui, le problème est réel et la solution est suffisante. Si non, la semaine 7 est une semaine de diagnostic, pas de développement.

Ce que j'aurais fait différemment

Documenter les décisions d'architecture dès le départ. Pas un document formel — une note de 5 lignes par décision structurante, avec le contexte et les alternatives écartées. Trois mois plus tard, quand quelqu'un demande pourquoi on a choisi X, la réponse ne dépend plus de la mémoire de qui était là.

Et commencer les tests d'intégration sur les chemins critiques dès la semaine 3, pas en fin de projet. Un MVP livré avec des tests sur le parcours de paiement et d'authentification est infiniment plus solide qu'un MVP couvert à 90 % de tests unitaires sur des utilitaires.