Combien de temps prend un MVP, semaine par semaine
Huit semaines pour un produit en production, à condition que le périmètre tienne sur une page et que quelqu'un puisse décider chaque semaine. Le calendrier ne dérape presque jamais pour des raisons techniques. Voici où passent réellement les soixante jours, et ce qui les allonge.
Par John-Guy Park · · 10 min de lecture
L'essentiel
- Un MVP en production se livre en soixante jours, soit huit à neuf semaines calendaires : deux semaines de cadrage, quatre à cinq de construction, une à deux de mise en production.
- Chez Workfutur, le forfait démarre à 29 000 € et la propriété du code vous est transférée dès le premier euro facturé, pas à la livraison.
- Les trois variables qui décident du délai ne sont pas techniques : la disponibilité de décision du fondateur, le nombre d'intégrations tierces, et l'état réel des données.
- Allonger le calendrier n'achète pas de la sécurité. Sur 5 400 projets informatiques étudiés, chaque année supplémentaire de durée augmente le dépassement de budget de 15 % (donnée tierce : McKinsey et université d'Oxford, 2012).
- Le risque dominant n'est pas de mal construire, c'est de construire quelque chose dont personne ne veut : 42 % des post-mortem de startups citent l'absence de besoin marché comme cause première (donnée tierce : CB Insights).
- Sur Blueboard, le MVP a été livré en onze semaines et le produit comptait 4 000 utilisateurs au troisième mois. Onze, pas huit : le périmètre initial était trop large, et je le dis.
Où passent réellement les soixante jours
Quand j'annonce soixante jours, je parle de jours calendaires entre la signature et un produit qui tourne en production avec de vrais utilisateurs dessus. Pas une maquette cliquable, pas une démonstration sur mon ordinateur portable. Cela représente huit à neuf semaines, et le découpage est toujours à peu près le même.
Les deux premières semaines ne produisent aucune ligne de code visible, et ce sont pourtant les plus rentables. On y écrit le périmètre sur une page, on choisit les deux ou trois parcours utilisateur que le produit doit servir, et on tranche tout le reste. On y règle aussi les questions qui bloquent silencieusement les projets plus tard : où vivront les données, quelles intégrations sont réellement nécessaires, qui a le pouvoir de dire oui. Un fondateur me demande à peu près une fois sur deux si on ne peut pas raccourcir cette phase. La réponse est non, et c'est la seule chose sur laquelle je ne négocie pas.
Les semaines trois à six sont la construction proprement dite. Le produit se déploie en continu dès le premier jour de développement, sur un environnement que vous pouvez ouvrir quand vous voulez. Vous ne découvrez pas le résultat à la fin, vous le voyez se former, et un désaccord sur une fonctionnalité se règle en trois jours au lieu d'apparaître au moment de la recette.
Les semaines sept et huit servent à la mise en production réelle : authentification, sauvegardes, journalisation, gestion des erreurs, conformité aux traitements de données que vous avez déclarés, et la transmission complète. Cette phase paraît administrative et elle est celle que les devis les moins chers oublient le plus souvent. Un produit qui fonctionne en démonstration mais qui perd les données d'un utilisateur sur cent n'est pas un MVP, c'est un prototype qu'on a mis en ligne trop vite. Le détail de ce qui est inclus figure sur la page développement de MVP, avec les prix.
Les trois variables qui décident du délai, et aucune n'est technique
Sur la dizaine de projets que je livre chaque année, l'écart entre un MVP en huit semaines et un MVP en quatorze ne vient presque jamais de la difficulté technique. Il vient de trois choses, dans cet ordre.
La première est votre disponibilité de décision. Un MVP demande environ trois heures par semaine de la part du fondateur : une revue hebdomadaire d'une heure, et deux heures de réponses à des questions qui bloquent. Ce n'est pas beaucoup en volume, mais c'est non compressible et non délégable. Quand un arbitrage attend une semaine, le calendrier prend une semaine, mécaniquement. Sur les projets qui glissent, je peux presque toujours pointer trois ou quatre décisions restées en attente.
La deuxième est le nombre d'intégrations avec des systèmes que vous ne contrôlez pas. Un paiement, une signature électronique, un référentiel métier, un logiciel de gestion déjà en place chez vos clients. Chacune ajoute une à deux semaines, non pas pour l'écrire, ce qui prend souvent deux jours, mais pour obtenir les accès, comprendre le comportement réel de l'interface par rapport à sa documentation, et gérer les cas d'erreur. Deux intégrations tiennent dans soixante jours. Cinq, non, et il faut le dire avant de signer plutôt qu'en semaine six.
La troisième est l'état de vos données, et c'est celle qui surprend le plus. Si le produit doit s'appuyer sur un existant, un export client, un historique de transactions, un catalogue, le délai dépend entièrement de la propreté de cet existant. Sur un prototype Data ou IA, cette variable domine tout le reste : la qualité du jeu de données décide du calendrier bien avant le choix du modèle. Un jeu de données incohérent ne se nettoie pas en trois jours, et aucune méthode ne raccourcit cette étape.
Allonger le calendrier n'achète pas de la sécurité
L'intuition dominante chez les dirigeants non techniques est qu'un projet plus long est un projet mieux fait. Les données publiques disponibles disent l'inverse, assez nettement.
L'étude conduite par McKinsey avec le centre BT de l'université d'Oxford, sur plus de 5 400 projets informatiques dont le budget initial dépassait 15 millions de dollars, mesure un dépassement moyen de 45 % sur le budget et de 7 % sur les délais, pour une valeur livrée inférieure de 56 % à ce qui était prévu. Le résultat le plus utile pour notre sujet est ailleurs : chaque année supplémentaire de durée prévue augmente le dépassement de coût de 15 %. La durée n'est pas seulement une conséquence du risque, elle en est une cause. Ces chiffres datent de 2012 et portent sur de très grands projets, très loin d'un MVP de startup : je les cite pour la relation qu'ils établissent entre durée et dérapage, pas parce que les pourcentages s'appliqueraient tels quels à votre situation.
L'autre raison de raccourcir tient à la nature du risque que vous portez réellement. En analysant 101 post-mortem de startups, CB Insights trouve que la cause la plus fréquemment citée, dans 42 % des cas, est l'absence de besoin marché. Pas un problème d'exécution technique : un produit correctement construit pour un besoin qui n'existait pas. Chaque mois passé à construire avant d'avoir un utilisateur réel est un mois pendant lequel cette question reste ouverte, et pendant lequel vous payez pour maintenir l'incertitude en vie. C'est toute la logique du format à soixante jours : obtenir la réponse qui décide de la suite avant d'avoir dépensé le budget qui vous aurait permis d'agir dessus.
Les quatre causes de dérapage que je vois le plus souvent
La première est le périmètre qui grossit par petites additions raisonnables. Personne ne demande jamais une fonctionnalité énorme. On demande un export, puis un filtre, puis un second rôle utilisateur, et chacune de ces demandes est défendable. Trois semaines plus tard, le produit a doublé sans qu'aucune décision n'ait été prise. Le remède est ennuyeux mais il fonctionne : chaque ajout doit retirer autre chose, ou décaler explicitement la date.
La deuxième est l'intégration tierce dont personne n'a lu la documentation avant de s'engager. Je consacre systématiquement une demi-journée de la première semaine à ouvrir chaque interface prévue et à faire un appel réel. C'est là qu'on découvre qu'un environnement de test n'existe pas, qu'une validation prend trois semaines chez le fournisseur, ou que la fonctionnalité annoncée sur la page commerciale n'existe que sur un forfait supérieur.
La troisième est l'attente d'une décision. Elle ne ressemble pas à un problème sur le moment, parce que l'équipe continue de travailler sur autre chose. Elle apparaît à la fin, quand il faut rattraper trois semaines cumulées d'arbitrages différés. Je publie donc chaque semaine l'état des décisions en attente, avec la date à laquelle chacune commence à coûter du calendrier.
La quatrième est plus rare mais plus lourde : la découverte tardive que les données existantes ne permettent pas de faire ce que le produit promet. Sur Coddect, la structuration en amont a permis de diviser les délais de traitement par quatorze et les coûts par trente, pour soixante dossiers analysés par mois. Ce résultat vient d'un cadrage sérieux des données avant la construction, pas d'une prouesse d'ingénierie. Sautée, cette étape ne disparaît pas : elle se paye plus tard et plus cher. D'autres exemples chiffrés figurent sur la page réalisations.
Comment vérifier qu'un délai annoncé est crédible
Quand un prestataire vous annonce une durée, quatre questions suffisent à savoir si le chiffre repose sur quelque chose.
Demandez d'abord ce que contient la dernière semaine du planning. Si la réponse ne mentionne ni sauvegardes, ni gestion des erreurs, ni transmission des accès, la mise en production n'est pas dans le devis et le délai annoncé n'est pas celui d'un produit utilisable. Demandez ensuite à quelle fréquence vous verrez le produit tourner. Une équipe qui ne déploie qu'une fois par mois ne tiendra pas un calendrier de huit semaines, quel que soit son talent : le rapport DORA de Google Cloud situe les équipes les moins performantes entre un déploiement par mois et un tous les six mois, avec un délai d'un à six mois entre l'écriture d'une modification et sa mise en production, quand les équipes les plus performantes déploient à la demande en moins d'une journée.
Demandez ensuite ce qui se passe si vous réclamez un changement en semaine cinq. Une réponse honnête ressemble à « on décale la date ou on retire autre chose », pas à « on absorbe ». Un prestataire qui absorbe tout absorbe en réalité sur la dernière semaine, celle de la mise en production, et vous le découvrez au moment le plus coûteux.
Demandez enfin à qui appartient le code pendant le projet. Chez Workfutur la propriété intellectuelle vous est transférée dès le premier euro facturé, ce qui veut dire que vous pouvez partir à n'importe quel moment avec ce qui a été produit. Cette question a l'air juridique, elle est en fait une question de calendrier : quand le code ne vous appartient qu'à la livraison, un retard vous laisse sans rien et sans levier. La grille tarifaire et les conditions sont publiées, ce qui permet de comparer sur des bases identiques.
Un dernier mot sur l'honnêteté des chiffres. Sur Blueboard, le MVP a été livré en onze semaines et non en huit, pour 4 000 utilisateurs au troisième mois. Le dépassement venait d'un périmètre initial trop large que j'aurais dû réduire davantage au cadrage. Un prestataire qui affirme que tous ses projets sortent à la date prévue vous dit soit qu'il ne prend que des projets triviaux, soit qu'il coupe dans la qualité en fin de parcours.
Les soixante jours, semaine par semaine
| Période | Ce qui se passe | Ce que vous devez fournir |
|---|---|---|
| Semaines 1 à 2 | Cadrage : périmètre écrit sur une page, deux ou trois parcours retenus, architecture arrêtée, accès aux systèmes tiers testés | Trois à quatre heures d'entretien, les accès, et un décideur unique |
| Semaines 3 à 4 | Construction du socle : modèle de données, authentification, premier parcours utilisateur déployé en continu | Une revue hebdomadaire d'une heure |
| Semaines 5 à 6 | Construction du reste du périmètre, intégrations tierces, corrections issues des revues | Une revue hebdomadaire, et les arbitrages sous 48 heures |
| Semaine 7 | Mise en production : sauvegardes, journalisation, gestion des erreurs, tests de charge raisonnables | La validation des textes et des conditions d'utilisation |
| Semaine 8 | Transmission : documentation, accès, passation, premiers utilisateurs réels | Vos premiers utilisateurs, ou la liste pour les inviter |
| Après | Itérations mensuelles à la demande, ou reprise en interne : le code et les accès sont déjà les vôtres | Rien d'obligatoire |
Calendrier type d'un forfait à partir de 29 000 €, pour un périmètre à deux ou trois parcours et au plus deux intégrations tierces. Un audit et cadrage à 4 900 € permet de vérifier, avant de s'engager, que votre périmètre tient dans ce format. Devis sous 5 jours ouvrés.
Questions fréquentes
Combien de temps faut-il pour développer un MVP ?
Soixante jours calendaires, soit huit à neuf semaines, pour un produit réellement en production avec de vrais utilisateurs. Le découpage habituel est de deux semaines de cadrage, quatre à cinq semaines de construction et une à deux semaines de mise en production et de transmission. Ce délai suppose un périmètre limité à deux ou trois parcours utilisateur, au plus deux intégrations avec des systèmes tiers, et un décideur disponible environ trois heures par semaine. Au-delà de ces limites, le délai s'allonge, et il vaut mieux l'annoncer avant la signature.
Peut-on développer un MVP en un mois ?
Oui, mais ce n'est alors pas un MVP au sens d'un produit en production. En quatre semaines on peut livrer un prototype fonctionnel qui prouve une hypothèse précise devant des utilisateurs choisis, sans les garanties d'exploitation qu'un produit ouvert au public exige : reprise après incident, sauvegardes vérifiées, gestion complète des erreurs. Le format est légitime quand la question à trancher est étroite, par exemple la faisabilité d'un traitement de données. Il devient un piège quand on le présente ensuite comme une première version, parce que la dette accumulée se paie au prix fort.
Qu'est-ce qui allonge le plus souvent le délai d'un MVP ?
Dans l'ordre de fréquence sur les projets que je livre : les décisions restées en attente du côté du client, le périmètre qui grossit par ajouts successifs jugés petits, les intégrations avec des systèmes tiers dont le comportement réel diffère de la documentation, et l'état des données existantes quand le produit doit s'appuyer dessus. Aucune de ces quatre causes n'est technique. C'est pourquoi les deux premières semaines de cadrage, qui ne produisent rien de visible, sont celles qui protègent le mieux le calendrier.
Un MVP livré en soixante jours est-il un vrai produit ou une maquette ?
Un vrai produit, sinon le délai n'aurait aucun sens à annoncer. Cela signifie une authentification réelle, des données persistées et sauvegardées, une gestion des erreurs, une journalisation permettant de comprendre un incident, et un déploiement automatisé. Ce que le format ne contient pas, c'est la profondeur fonctionnelle : deux ou trois parcours servis correctement plutôt que dix parcours à moitié. La différence entre un MVP et une maquette cliquable ne se voit pas à la démonstration, elle se voit au centième utilisateur.
Combien de temps le fondateur doit-il y consacrer ?
Environ trois heures par semaine, avec une pointe à trois ou quatre heures d'entretien pendant la phase de cadrage. Cela comprend une revue hebdomadaire d'une heure sur le produit tel qu'il tourne, et le temps de répondre aux questions qui bloquent. Ce temps n'est ni compressible ni délégable à quelqu'un qui n'a pas le pouvoir de trancher. C'est la contrepartie de la vitesse : un calendrier de huit semaines n'absorbe pas un arbitrage qui attend dix jours.
Pourquoi ne pas prendre plus de temps pour mieux faire ?
Parce que la durée est elle-même un facteur de risque, et pas seulement une conséquence de l'ambition. L'étude McKinsey et Oxford portant sur plus de 5 400 projets informatiques mesure que chaque année supplémentaire de durée prévue augmente le dépassement de coût de 15 %. Et le risque dominant pour une jeune entreprise n'est pas de mal construire : CB Insights trouve que 42 % des post-mortem de startups citent l'absence de besoin marché comme cause première. Un calendrier long retarde le moment où vous saurez si ce besoin existe, tout en consommant les moyens qui vous permettraient de réagir.
Que se passe-t-il après les soixante jours ?
Trois suites sont possibles, et aucune ne vous engage. Vous pouvez itérer avec moi au mois, en général sur un rythme de deux semaines par lot. Vous pouvez reprendre le produit en interne : le code, la documentation, les accès à l'infrastructure et les schémas d'architecture vous appartiennent déjà, puisque la propriété intellectuelle est transférée dès le premier euro facturé. Vous pouvez aussi arrêter, si le MVP a répondu par la négative à la question posée, ce qui reste le meilleur usage possible de soixante jours et de 29 000 €.
Combien coûte un MVP livré en soixante jours ?
Le forfait démarre à 29 000 € pour un périmètre de deux ou trois parcours utilisateur et au plus deux intégrations tierces. Le devis est remis sous 5 jours ouvrés après le premier entretien. Si le périmètre est encore incertain, un audit et cadrage à 4 900 € permet de le fixer et de vérifier qu'il tient dans le format avant tout engagement sur le développement, et son montant est connu d'avance. L'ensemble de la grille est publié sur la page des tarifs, sans formulaire à remplir.
Sources citées
- McKinsey & université d'Oxford — Delivering large-scale IT projects on time, on budget, and on value — plus de 5 400 projets informatiques, 45 % de dépassement de budget, 7 % de dépassement de délai, 56 % de valeur en moins, et 15 % de dépassement supplémentaire par année de durée ajoutée — publication d'octobre 2012, sur des projets de plus de 15 M$
- CB Insights — The Top 20 Reasons Startups Fail — analyse de 101 post-mortem de startups : l'absence de besoin marché est citée dans 42 % des cas, un produit mal calé dans le temps dans 13 %
- DORA / Google Cloud — Rapport Accelerate sur l'état du DevOps 2024, version française — clusters de performance : les équipes les moins performantes déploient d'une fois par mois à une fois tous les six mois avec un délai de livraison des modifications d'un à six mois, les plus performantes déploient à la demande en moins d'une journée
Un projet à transformer en produit ?
Réservez 30 minutes, ou présentez votre idée en quelques lignes. Nous répondons sous 5 jours ouvrés avec un cadrage gratuit — périmètre, risques, planning et barème d'engagement.