MVP en 4 semaines : la méthode que nous appliquons projet après projet

Lancer un produit numérique sans y passer six mois ni brûler son budget de démarrage — c’est la promesse du MVP. Mais entre la théorie et la réalité, beaucoup de fondateurs se retrouvent avec un périmètre qui gonfle, des délais qui glissent et une première version qui ressemble davantage à un produit fini qu’à un test. Voici comment nous structurons concrètement un MVP en quatre semaines, ce que ce délai inclut, ce qu’il exclut, et à quoi s’attendre côté budget.

---

Ce que « MVP en 4 semaines » veut vraiment dire

Quatre semaines, c’est un délai réaliste pour livrer une première version fonctionnelle — pas une maquette cliquable, pas un prototype Figma, mais du code qui tourne, que de vrais utilisateurs peuvent tester. Ce délai suppose que le périmètre est verrouillé avant le début du sprint, que les accès et contenus nécessaires arrivent dans les 48 premières heures, et qu’un interlocuteur côté client peut valider les démos hebdomadaires sans passer par trois niveaux de hiérarchie.

Ce que quatre semaines ne couvrent pas : la phase de discovery (définition du problème et des personas), la conception graphique complète, l’intégration de systèmes tiers complexes comme un ERP ou une API bancaire, et la publication dans l’App Store ou Google Play si des comptes développeur n’existent pas encore — Apple peut prendre jusqu’à 48 heures pour approuver un compte, et la review d’une application prend en moyenne 1 à 3 jours ouvrés selon les statistiques publiées par Apple.

---

Les 4 semaines semaine par semaine

Semaine 1 — Cadrage et architecture

Le premier lundi, on gèle le périmètre dans un document court : les fonctionnalités qui entrent dans le MVP, celles qui attendent la V2, et les hypothèses à valider. Ce document devient la référence contractuelle. Toute demande hors périmètre passe par un avenant.

On choisit l’architecture technique en fonction de deux critères : vitesse de déploiement et facilité de reprise par une autre équipe si le client décide de changer de prestataire après le MVP. Pour une application web, Next.js ou Nuxt côté front, Node.js ou Python côté back, PostgreSQL ou Supabase pour la base de données. Pour une application mobile cross-platform, Flutter — un seul code pour iOS et Android, ce qui divise le coût de développement initial.

Livrable de la semaine 1 : périmètre verrouillé, architecture validée, environnements de développement et de staging opérationnels.

Semaine 2 — Développement du cœur fonctionnel

On construit les flux critiques — ceux sans lesquels le produit ne peut pas être testé. Pour une marketplace, c’est l’inscription, la création d’une annonce et la prise de contact. Pour une application SaaS, c’est l’onboarding et l’action principale que l’utilisateur vient accomplir. Tout le reste attend.

La démo de fin de semaine 2 est la plus importante : si le cœur fonctionnel ne convainc pas, il vaut mieux le savoir à J+14 qu’à J+28.

Semaine 3 — Fonctionnalités secondaires et intégrations

On ajoute les fonctionnalités qui rendent le produit utilisable sans être indispensables au test de l’hypothèse principale : notifications, tableau de bord basique, export de données. Si des intégrations tierces sont prévues (paiement en ligne via Stripe ou Mollie, envoi d’e-mails via Brevo, authentification via France Connect pour les services publics), elles entrent ici.

Un point d’attention spécifique pour les produits qui collectent des données personnelles : la conformité RGPD n’est pas optionnelle, même pour un MVP. La CNIL peut contrôler une startup dès son lancement. Concrètement, cela signifie une politique de confidentialité accessible, un registre des traitements, et — si on utilise des cookies non essentiels — un bandeau de consentement conforme. Ces éléments doivent être prêts avant le premier utilisateur réel.

Semaine 4 — Tests, corrections et déploiement

Tests fonctionnels sur les flux critiques, correction des bugs bloquants, déploiement en production. On ne vise pas zéro bug — on vise zéro bug qui empêche un utilisateur de réaliser l’action principale. Les bugs cosmétiques et les cas limites sont documentés et traités en V1.1.

Livrable final : application déployée, documentation technique de base, accès remis au client.

---

Ce que ça coûte : fourchettes réelles avec périmètre

Les prix ci-dessous correspondent à des MVPs développés sur mesure (code réel, pas de no-code), livrés en quatre semaines, avec démos hebdomadaires et prix fixé avant le début des travaux. Ils excluent les frais d’hébergement, de nom de domaine, de services tiers (Stripe, Brevo, etc.) et de publication dans les stores — ces coûts restent à la charge du client.

Ces fourchettes sont des ordres de grandeur pour un marché européen en 2025. Le prix final dépend du périmètre exact, des intégrations et de la complexité des données. Un devis précis nécessite un brief détaillé.

---

Les trois raisons pour lesquelles un MVP dépasse les 4 semaines

Le périmètre bouge en cours de route. C’est la cause numéro un. Un fondateur voit la démo de la semaine 2 et ajoute « juste une fonctionnalité ». Puis une autre. Au bout de quatre semaines, le produit a doublé de volume mais n’est livré qu’à moitié. La solution : tout ce qui entre après la signature du périmètre passe par un avenant écrit, avec un délai et un coût supplémentaires explicites.

Les accès et contenus arrivent en retard. Identifiants de serveur, clés API, textes, logos, données de test — si ces éléments n’arrivent pas en semaine 1, le planning glisse mécaniquement. Un checklist d’onboarding envoyé dès la signature du contrat réduit ce risque.

Les intégrations tierces sont sous-estimées. Une intégration avec un système de caisse, un logiciel de gestion ou une API bancaire peut prendre autant de temps que le développement du produit lui-même. Dans notre expérience sur des projets similaires, l’intégration avec des systèmes legacy (fichiers CSV, API mal documentées, systèmes qui nécessitent des accès VPN) est systématiquement le poste qui dépasse les estimations initiales. Si une intégration complexe est indispensable au MVP, il vaut mieux la traiter comme un projet à part entière avec son propre délai.

---

Ce que le MVP ne remplace pas

Un MVP livre du code fonctionnel — pas une stratégie de lancement, pas une acquisition utilisateurs, pas une analyse de marché. Les quatre semaines de développement doivent s’inscrire dans une démarche plus large : qui sont les dix premiers utilisateurs que vous allez solliciter ? Quel comportement observé dans le produit vous dira que l’hypothèse est validée ? Quelle est la prochaine itération si les retours sont mitigés ?

En France, plusieurs dispositifs peuvent financer tout ou partie d’un MVP : le crédit d’impôt innovation (CII) pour les PME, les aides de Bpifrance (notamment le prêt d’amorçage ou les subventions régionales via les DREETS), et les programmes d’accélération comme Station F ou les incubateurs régionaux. Ces dispositifs ont leurs propres critères d’éligibilité — un expert-comptable familier avec l’innovation peut aider à identifier lesquels s’appliquent à votre situation.

---

Pour résumer

Quatre semaines, c’est suffisant pour tester une hypothèse avec du code réel — à condition de verrouiller le périmètre avant de commencer, de prévoir les accès dès J+1, et de traiter les intégrations complexes séparément. Le budget d’entrée pour un MVP web ou bot tourne autour de €3 000 à €6 000 ; une application mobile ou une marketplace démarre plutôt entre €5 000 et €12 000.

Chez Pazl, le développement d’applications web et de MVP sur mesure se fait en prix fixe, avec un périmètre défini par contrat, des démos chaque semaine et une garantie de six mois sur ce que nous livrons. Si vous avez une idée et que vous voulez savoir ce qu’un MVP réaliste coûterait et prendrait comme temps, écrivez-nous à hello@pazl.ai — on peut généralement donner un premier cadrage en 48 heures.