Combien de temps pour développer un MVP ? Les délais réels

Combien de temps faut-il pour développer un MVP ?

Pour un MVP développé sur mesure par une petite équipe senior, comptez en général 2 à 4 mois jusqu'à la mise en production. Le cadrage, qui prend quelques semaines, ouvre le projet et conditionne tout le reste. Cette fourchette couvre la plupart des projets : un SaaS B2B web construit autour d'un parcours principal, une application mobile, une marketplace simple. En dessous de deux mois, on obtient plutôt un prototype, une maquette cliquable ou un outil no-code. C'est utile pour montrer une idée, mais rarement prêt à accueillir de vrais clients. Au-delà de cinq mois, le projet n'est souvent plus un MVP : le périmètre a grossi jusqu'à devenir une plateforme. Le délai bouge surtout avec le nombre de parcours utilisateurs, les intégrations avec d'autres systèmes et les contraintes réglementaires. Enfin, la vitesse de décision côté client pèse presque autant que celle de l'équipe technique.

Quelles sont les phases d'un MVP, et combien dure chacune ?

Un MVP passe par quatre phases. Elles se chevauchent un peu, mais leur ordre ne change pas.

Le cadrage : quelques semaines

C'est la phase la plus courte, et celle qui rapporte le plus. Quelques jours d'atelier, souvent 3 à 5, suffisent pour définir ce que le produit doit prouver, lister les parcours indispensables et couper le reste. Avec les allers-retours et les validations, le cadrage tient en quelques semaines. Il se termine par un périmètre écrit, une estimation et un planning.

La conception : en parallèle

Maquettes des écrans clés, parcours utilisateur, charte graphique minimale. Sur un MVP, on ne dessine pas toute l'application d'avance. On conçoit les premiers écrans, l'équipe technique démarre, et la conception garde une ou deux longueurs d'avance sur le développement.

Le développement : l'essentiel du calendrier

C'est ici que se joue la fourchette de 2 à 4 mois. Le travail avance par sprints courts. Le Scrum Guide limite un sprint à un mois au plus ; sur un MVP, beaucoup d'équipes préfèrent des cycles d'une ou deux semaines, pour montrer souvent quelque chose qui tourne. Chaque démo sert à arbitrer : on garde, on ajuste ou on coupe. Un premier incrément utilisable arrive souvent bien avant la fin.

La recette et la mise en production : à prévoir dès le départ

Tests de bout en bout, corrections, configuration de l'hébergement, des sauvegardes et de la supervision, puis mise en ligne. Pour une application mobile, ajoutez la publication sur l'App Store et Google Play, qui passe par une revue d'Apple et de Google sur laquelle vous n'avez pas la main. C'est souvent la phase que les devis trop optimistes oublient.

Un exemple de planning, semaine par semaine

Voici un exemple pour un SaaS B2B web d'environ trois mois, cadrage compris. Chaque projet a le sien ; celui-ci sert de repère.

• Semaines 1 et 2 : cadrage, périmètre écrit, maquettes des écrans clés.
• Semaines 3 à 6 : comptes utilisateurs, parcours principal, premières démos.
• Semaines 7 à 10 : parcours secondaires, back-office simple, intégrations.
• Semaines 11 et 12 : recette, corrections, mise en production.
• Ensuite : premiers utilisateurs, retours, corrections et nouvelles itérations.

Quel délai selon le type de produit ?

Délais indicatifs pour un développement sur mesure de qualité, les mêmes que dans notre article sur le coût d'un MVP. Pour le budget qui va avec, essayez le simulateur de budget MVP.

Qu'est-ce qui allonge le délai d'un MVP ?

• Le périmètre qui grossit en route. Chaque fonctionnalité ajoutée « en passant » demande du design, du développement et des tests, et le planning s'allonge d'autant.
• Les intégrations : paiement, ERP, authentification unique (SSO), API tierces. Chaque système externe arrive avec sa documentation, ses accès et ses propres délais.
• Le mode hors ligne. Une application qui doit fonctionner sans réseau a besoin d'une base locale et d'une synchronisation fiable. Nous l'avons fait en renfort d'équipe pour une application de contrôles réglementaires sur le terrain : c'est un vrai chantier, à prévoir dès le cadrage.
• La conformité. En santé, en finance ou dans le secteur public, la sécurité, la traçabilité et les validations prennent du temps.
• Les décisions qui traînent. Une démo restée sans retour pendant deux semaines, ce sont deux semaines perdues. Désignez une personne qui tranche, et réservez-lui du temps pour ça.
• Les contenus et les données. Textes, tarifs, données de test, accès aux environnements : s'ils arrivent tard, l'équipe attend.

Le simulateur de notre article sur le coût d'un MVP en tient compte : un périmètre riche, ou des contraintes qui s'additionnent comme le mode hors ligne, placent le délai en haut de la fourchette.

Comment raccourcir le délai sans bâcler le produit ?

• Coupez au moment du cadrage. Pour chaque fonctionnalité, demandez-vous si l'hypothèse reste testable sans elle. Souvent, oui.
• Soignez un parcours plutôt que d'en ébaucher cinq. Un parcours principal solide vous en apprendra plus que cinq parcours à moitié finis.
• Branchez des briques existantes. Pour le paiement, l'envoi d'e-mails ou l'authentification, des services éprouvés existent : inutile de les redévelopper.
• Prévoyez une démo par sprint et une personne qui tranche, avec des retours en quelques jours.
• Partez de l'existant. Un prototype fait avec Lovable ou Bolt peut servir de cahier des charges vivant, voire de base de code après un audit. Nous expliquons comment reprendre un prototype Lovable ou Bolt.

Ajouter des développeurs accélère-t-il un MVP ?

Ajouter des développeurs accélère un MVP moins qu'on ne l'espère. Le périmètre d'un MVP est petit : au-delà de quelques développeurs, chaque personne en plus ajoute des échanges, des revues de code et des conflits entre les modifications des uns et des autres. Fred Brooks l'a formulé en 1975 dans The Mythical Man-Month : ajouter des personnes à un projet logiciel en retard le retarde encore (c'est la loi de Brooks). Un nouvel arrivant doit d'abord découvrir le code, les choix déjà faits et les habitudes de l'équipe, et ce sont les autres qui le forment pendant ce temps. Le levier le plus efficace reste donc le périmètre. Retirer une fonctionnalité fait gagner du temps tout de suite, alors qu'un développeur de plus en fait souvent perdre les premières semaines. Si la date est vraiment contrainte, découpez plutôt la livraison en deux versions : une première sortie avec le parcours principal, puis le reste dans la foulée.

Quels pièges faussent l'estimation d'un délai ?

Quand on estime le délai d'un MVP, le piège le plus courant est le devis trop court. Un planning de quatre semaines pour un produit avec comptes utilisateurs, paiement et back-office oublie souvent quelque chose : la recette, la mise en production, la publication sur les stores ou le temps de décision du client. Deuxième piège, confondre prototype et MVP. Un prototype montre une idée, alors qu'un MVP accueille de vrais utilisateurs, avec leurs données, leurs erreurs et leurs demandes de support. Troisième piège, l'effet tunnel : une équipe qui ne montre rien pendant deux mois, puis livre tout d'un coup. Demandez une démo à chaque sprint et l'accès au code dès le premier jour. Enfin, un délai n'a de sens qu'avec un périmètre écrit. Sans la liste précise de ce qui sera livré, « trois mois » ne veut rien dire, ni pour vous ni pour le prestataire.

Et chez Neodev ?

Notre offre de développement de MVP s'adresse aux startups et aux PME. Nous commençons presque toujours par un cadrage court pour réduire le périmètre à ce qui compte, puis nous livrons par sprints, avec une démo à chaque étape. Le délai exact se fixe une fois le périmètre clair, en général entre 2 et 4 mois. S'il y a un existant à reprendre, un audit court de 3 à 5 jours permet de savoir ce qui se garde. Vous recevez un devis détaillé sous 48 h, et le code vous appartient.