MVP en trois semaines : ce que la promesse cache, et ce qu'on livre vraiment en six à huit semaines

---

title: "MVP en trois semaines : ce que la promesse cache, et ce qu'on livre vraiment en six à huit semaines" seoTitle: "MVP en 3 semaines : la promesse décryptée" description: "Trois semaines pour un MVP : la promesse est partout sur le marché français. Elle est tenable sur un périmètre très précis, et fausse sur presque tout le reste. Voici ce que le chiffre mesure réellement, les quatre postes qu'il ne compte jamais, et le calendrier honnête d'un MVP livré en six à huit semaines." seoDescription: "Pourquoi la promesse d'un MVP en trois semaines tient rarement, ce qu'elle ne compte pas, et le calendrier réel d'un MVP livré en six à huit semaines." date: "2026-09-14" author: "Équipe Raicode" tags: ["mvp", "saas", "gestion de projet", "développement"] category: "SaaS & MVP" keywords: ["MVP en trois semaines", "délai développement MVP", "combien de temps pour un MVP", "livrer un MVP rapidement", "MVP six semaines", "planning MVP SaaS", "agence MVP rapide", "sortir un MVP", "délai réaliste SaaS"]

Un founder nous écrit avec deux propositions sur son bureau. La première annonce un MVP livré en trois semaines, forfait compris. La seconde parle de huit semaines et d'un atelier de cadrage préalable. Les deux prestataires ont vu le même document, les mêmes captures d'écran Figma, la même ambition. Sa question tient en une ligne : est-ce que le second me fait perdre cinq semaines, ou est-ce que le premier me ment ?

Ni l'un ni l'autre, la plupart du temps. Les deux disent la vérité sur des objets différents, et personne ne prend la peine de préciser lequel. La promesse des trois semaines est devenue un argument de vente standard sur le marché français du développement produit : elle est répétée sur les pages d'accueil, dans les études de cas, dans les fils LinkedIn. Elle n'est pas mensongère. Elle est incomplète d'une manière qui coûte cher au founder qui la prend au pied de la lettre, parce qu'elle déplace les cinq semaines manquantes vers l'endroit où il les paiera le plus cher : après la mise en ligne.

Ce que « trois semaines » désigne réellement

Quand un prestataire annonce trois semaines, il ne bluffe presque jamais. Il décrit une durée qu'il a effectivement tenue, sur un objet qu'il connaît bien. Le problème est que cet objet a une définition implicite, et que cette définition n'est pas dans la proposition commerciale.

Le périmètre implicite

Dans l'écrasante majorité des cas, « MVP en trois semaines » signifie : une application web avec authentification, un modèle de données de trois à six entités, des écrans de création, consultation, modification et suppression sur ces entités, un tableau de bord qui agrège quelques compteurs, un abonnement Stripe en mode test, et un déploiement sur une plateforme managée. Le tout construit sur un template que le prestataire réutilise de projet en projet, avec une bibliothèque de composants déjà en place.

C'est un vrai livrable. Pour valider qu'un acheteur clique sur « s'abonner », il suffit largement. Le malentendu naît quand le produit du founder n'est pas cet objet-là : dès qu'il y a un import de fichiers clients au format libre, une règle métier qui dépend d'un référentiel externe, un calcul que le client doit pouvoir auditer, une notion de rôles au-delà de « admin » et « utilisateur », ou le moindre appel à une API tierce dont la documentation ment, le template ne couvre plus le sujet et les trois semaines décrivent une autre application que la sienne.

Ce que le chiffre mesure

Trois semaines mesure du temps de codage, pas du temps de projet. C'est une distinction de vocabulaire qui vaut plusieurs milliers d'euros. Le temps de codage commence quand les décisions sont prises et s'arrête quand la fonctionnalité passe en recette. Le temps de projet commence quand le founder se pose la question et s'arrête quand un utilisateur qui n'est pas lui a fait quelque chose d'utile avec le produit.

Entre les deux, il y a tout ce qu'on ne facture pas à l'heure : les allers-retours sur ce que fait exactement le produit, le temps que met le founder à répondre, la découverte que le partenaire censé fournir les données n'a pas d'API, les deux jours perdus à comprendre pourquoi le paiement échoue en production alors qu'il passait en test. Un prestataire honnête qui annonce trois semaines de développement peut parfaitement voir le projet s'étaler sur dix semaines calendaires sans avoir menti une seule fois.

Les quatre postes que la promesse ne compte pas

Sur les projets que nous reprenons après un premier prestataire, les écarts entre l'annoncé et le réel se logent presque toujours dans les mêmes quatre postes. Aucun n'est spectaculaire. Ensemble, ils représentent régulièrement autant de travail que la construction des écrans.

Les décisions non prises. Un MVP contient une trentaine de micro-arbitrages que le founder est seul à pouvoir trancher : que se passe-t-il si un utilisateur annule son abonnement en cours de mois, qui peut inviter qui, que voit un compte expiré, comment on gère un doublon d'adresse email. Tant qu'ils ne sont pas tranchés, le développeur devine — et une décision devinée est une fonctionnalité à refaire. Le coût réel n'est pas le temps de la décision, c'est le délai de réponse : trois jours d'attente sur une question bloquante, répétés huit fois dans un projet, c'est un mois.

Les données réelles. Un MVP démontré avec des jeux de données fabriqués fonctionne toujours. Le premier import d'un vrai fichier client casse à peu près tout : encodage, colonnes en trop, dates au format américain, doublons, lignes vides, accents. Ce poste est systématiquement sous-estimé parce qu'il n'est pas visible dans les maquettes. Quand le produit repose sur des données que le founder ne maîtrise pas — un export d'un logiciel métier, un flux partenaire, un historique repris d'un tableur — il faut le compter à part, et généreusement.

L'argent et la conformité. Facturer est une fonctionnalité produit, pas un branchement. Entre l'abonnement en mode test et un encaissement réel, il y a la TVA, les périodes d'essai, les changements de forfait en cours de mois, les échecs de paiement, les relances, les factures à émettre, et la mention légale qui manque. Ajoutez-y le RGPD dès qu'il y a des données personnelles, et vous avez une à deux semaines de travail que personne n'inscrit dans un devis à trois semaines.

La mise en production et l'exploitation. Déployer n'est pas le sujet — les plateformes modernes rendent le premier déploiement trivial. Le sujet, c'est ce qui suit : les sauvegardes et leur restauration effectivement testée, les migrations de base de données sans coupure, la journalisation qui permet de comprendre l'erreur qu'un client vient de signaler, les alertes, les environnements séparés. Un MVP sans ces éléments fonctionne parfaitement jusqu'au jour où il faut réparer quelque chose en urgence, et devient à ce moment-là beaucoup plus cher que ce qu'il a coûté à construire.

Ces quatre postes expliquent aussi la majeure partie des écarts de chiffrage entre prestataires. Nous avons détaillé cette mécanique côté budget dans notre grille de lecture d'un devis de MVP entre 10 et 60 k€ : les mêmes variables qui produisent un facteur cinq sur le prix produisent un facteur trois sur le délai.

Le calendrier réel d'un MVP livré en six à huit semaines

Voici comment se répartit un projet qui sort effectivement en production dans cette fenêtre, avec un founder disponible et un périmètre tenu. Ce découpage est celui que nous appliquons sur nos projets de développement de MVP et de SaaS, et il n'a rien d'original : il est simplement écrit à l'avance plutôt que découvert en cours de route.

Semaine 1 — cadrage et décisions. On écrit la liste des parcours utilisateurs qui doivent fonctionner, et rien d'autre. On tranche les trente micro-arbitrages, on identifie les dépendances externes et on va vérifier qu'elles existent vraiment. On fixe ce qui ne sera pas dans la version 1 et on l'écrit noir sur blanc, parce qu'une liste des exclusions vaut mieux qu'une liste des inclusions. Cette semaine est celle que les offres à trois semaines suppriment ; c'est aussi celle dont la suppression coûte le plus cher.

Semaines 2 et 3 — le cœur fonctionnel. Modèle de données, authentification, le parcours principal de bout en bout. À la fin de la semaine 3, le founder doit pouvoir faire lui-même, sur un environnement en ligne, l'action pour laquelle le produit existe. Pas une démo guidée : l'action réelle. Si ce n'est pas le cas à la fin de la troisième semaine, c'est le signal d'alerte qui compte le plus dans tout le projet.

Semaines 4 et 5 — le second cercle et les données réelles. Les écrans secondaires, les rôles, les notifications, et surtout le premier import de données réelles. C'est la phase qui déborde le plus souvent, et c'est normal : c'est là qu'on découvre ce que le cadrage n'a pas pu anticiper.

Semaine 6 — facturation, conformité, production. Stripe en mode réel, mentions légales, politique de confidentialité, sauvegardes testées, journalisation, environnement de préproduction. Rien de ce qui se passe cette semaine n'est visible pour un utilisateur, et tout y est bloquant.

Semaines 7 et 8 — recette, corrections, premiers utilisateurs. Cinq à dix utilisateurs extérieurs sur le produit, les corrections que leur usage révèle, et la mise en ligne publique. Un MVP qui n'a jamais été manipulé par quelqu'un d'autre que son équipe n'a pas été testé, il a été relu.

Un projet bien cadré sur un périmètre restreint tient en six semaines. Un projet avec une dépendance externe sérieuse ou un modèle de données non trivial tient en huit. Au-delà de dix, ce n'est plus un MVP, et le risque devient celui du périmètre qui gonfle mois après mois sans que personne ait le mandat de le réduire.

Quand trois semaines est vrai

La promesse n'est pas toujours creuse, et il serait malhonnête de la disqualifier en bloc. Elle tient dans trois cas précis.

Le premier : le produit est effectivement une déclinaison du template. Une application de réservation, un annuaire payant, un outil de suivi interne avec cinq écrans. Si un prestataire a livré quatre fois la même architecture, il la livrera une cinquième fois en trois semaines, et c'est un excellent achat.

Le deuxième : le périmètre a déjà été cadré par quelqu'un d'autre. Un founder qui arrive avec des maquettes finalisées, un modèle de données validé et les trente arbitrages tranchés a déjà payé la semaine 1 — ailleurs, ou avec son propre temps. Les trois semaines annoncées sont alors sincères, elles ne comptent simplement pas ce qui a déjà été fait.

Le troisième : l'objectif n'est pas un produit mais une preuve. Valider qu'une audience s'inscrit, qu'un acheteur paie, qu'un flux tient debout. Là, trois semaines est même généreux, et la question du no-code mérite d'être posée avant celle du sur-mesure — nous avons comparé les deux approches dans ce comparatif low-code, no-code et sur-mesure. Construire en sur-mesure ce qu'un outil assemblé en quatre jours démontrerait aussi bien est une erreur de séquencement, pas de prestataire.

Les questions qui font parler un devis

Face à une proposition annonçant trois semaines, quatre questions suffisent à savoir de quel cas on relève. Elles ne sont pas agressives : un bon prestataire y répond volontiers, et la qualité de sa réponse vaut plus que le chiffre affiché.

La première : les trois semaines démarrent à quelle condition ? Si la réponse est « à la signature », le cadrage n'est pas compté. Si c'est « une fois les parcours validés », le prestataire sait de quoi il parle.

La deuxième : qu'est-ce qui n'est pas dans le périmètre ? Une proposition sérieuse contient une liste d'exclusions. Une proposition qui n'en contient aucune n'a pas été chiffrée, elle a été estimée.

La troisième : qui encaisse le premier paiement réel, et quand ? Cette question sort du cadre technique et révèle immédiatement si la facturation est traitée comme une fonctionnalité ou comme un branchement.

La quatrième : que se passe-t-il en semaine 4 ? C'est la plus utile. Un MVP livré en trois semaines a besoin d'être corrigé, hébergé, supervisé et modifié après sa mise en ligne. Si la proposition s'arrête à la livraison, le founder se retrouve propriétaire d'un code qu'il ne connaît pas, sans personne pour le faire évoluer — et c'est précisément la situation dans laquelle on nous appelle pour reprendre un projet.

Ce que coûte le fait de tenir les trois semaines quand même

Un dernier scénario mérite d'être nommé, parce qu'il est le plus fréquent : le projet n'était pas un cas à trois semaines, mais l'engagement a été pris, et il est tenu. Quelque chose est bien livré à la date annoncée.

Ce qui a sauté, dans l'ordre, est presque toujours identique : les tests d'abord, la gestion des erreurs ensuite, puis les migrations de base de données propres, puis la journalisation, enfin la documentation. Le produit fonctionne sur le parcours nominal et se comporte de façon imprévisible partout ailleurs. Le founder l'apprend au premier utilisateur qui fait une chose que personne n'avait anticipée.

Le coût de cet arbitrage n'apparaît pas en semaine 3. Il apparaît en mois 4, quand la moindre évolution demande de comprendre un code sans filet, et que chaque correction en casse une autre. À ce stade, la reprise coûte régulièrement plus cher que ce que la construction initiale a économisé. Trois semaines gagnées sur le calendrier, six mois perdus sur la trajectoire : c'est un mauvais échange, et il est irréversible une fois que les premiers clients sont dessus.

La bonne question à poser

La question n'est pas « combien de temps pour un MVP », mais « quelle est la plus petite chose qui prouve que ce produit intéresse quelqu'un, et combien de temps pour celle-là ». Posée dans ce sens, elle donne parfois trois semaines, souvent six, rarement plus — et surtout, elle donne un chiffre qui correspond à quelque chose.

Concrètement, avant de comparer deux propositions, écrivez en une page les trois parcours utilisateurs sans lesquels le produit n'a aucun intérêt, et la liste de ce que vous acceptez explicitement de ne pas avoir en version 1. Transmettez ce document aux prestataires que vous consultez. Les délais qu'ils annonceront ensuite seront comparables entre eux, ce qui n'était pas le cas avant — et vous saurez enfin si les cinq semaines d'écart sont du travail ou du vocabulaire.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.