Combien de temps faut-il pour développer un MVP ? Délais réels par type de produit

La complexité est le meilleur indicateur du délai d’un MVP. Nous utilisons trois niveaux pour chiffrer les projets.

Les mêmes niveaux fixent le budget. Notre analyse du coût d’un MVP SaaS indique la fourchette de prix de chacun.

Les types de produits se rangent dans ces niveaux de façon assez prévisible. Ce tableau montre où tombent en général les MVP courants ; le vôtre peut monter ou descendre d’un niveau selon ses détails.

Une Mini App Telegram se situe en général au niveau simple ou moyen. Elle s’ouvre dans Telegram : pas de publication sur les stores, et le compte de l’utilisateur vient de Telegram lui-même.

Tout MVP passe par les mêmes phases, même si elles se chevauchent davantage qu’une simple liste ne le laisse penser.

• Chiffrage. Votre brief devient une proposition avec périmètre, délai et prix. Chez Sakura, la plupart des propositions partent sous 2–3 jours ouvrés après un brief complet.
• Design. D’abord les parcours utilisateur, puis des écrans construits à partir d’un système de composants réutilisables, puis un prototype cliquable.
• Développement. Front-end, back-end et intégrations, avec chaque semaine une version fonctionnelle que vous pouvez parcourir.
• Tests. Chaque parcours sur les navigateurs et appareils convenus, plus la performance et l’accessibilité de base.
• Lancement. Mise en production, analytics, soumission aux stores s’il y a une application mobile, et premières corrections à l’arrivée des vrais utilisateurs.

Le design et le développement se chevauchent volontairement. Dès que les premiers parcours sont validés, leur développement commence pendant que les autres sont encore en conception.

Le design commence en général avant le développement et se termine avant lui, mais les deux ne doivent pas s’enchaîner strictement. Quand le design livre un fichier fini et s’en va, le développement découvre souvent des écrans coûteux à réaliser, et des semaines partent en reprises.

La solution consiste à concevoir avec les mêmes composants que ceux que les développeurs vont construire. Un écran validé est alors presque déjà construit, et les questions se règlent tant qu’elles coûtent peu.

Par exemple, AutoIntel, un outil B2B pour le marché allemand de la voiture d’occasion, a commencé par le design produit et un prototype interactif sur des annonces d’exemple. Le client a fait parcourir le prototype à son équipe et a décidé quels champs et filtres comptaient avant que la collecte de données soit chiffrée. Cet ordre garde la partie la plus coûteuse du développement centrée sur ce dont l’interface a réellement besoin.

Vous préparez une date de lancement ? Envoyez-nous un brief court et nous vous dirons dans quel niveau tombe votre produit et quel délai est réaliste.

Certaines fonctionnalités paraissent petites dans un brief et ajoutent des semaines au développement. Voici celles à surveiller :

• Les intégrations. Paiements, services de connexion, CRM et API tierces ajoutent chacun de la configuration, de la gestion d’erreurs et des tests.
• Les rôles et permissions. Chaque rôle supplémentaire multiplie les états que chaque écran doit gérer.
• Une application mobile native. Elle ajoute un second front-end et une validation sur les stores. L’App Review d’Apple traite au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures, mais un refus remet le compteur à zéro.
• Plusieurs langues. Chaque texte, message d’erreur et aide doit exister dans chaque langue, et la mise en page doit accueillir la version la plus longue.
• Les contenus tardifs. Les textes, prix, mentions juridiques et données réelles qui arrivent la dernière semaine bloquent les tests.
• Les décisions lentes. Une question qui attend sa réponse pendant une semaine retarde tout ce qui se construit dessus.

On raccourcit le délai d’un MVP en faisant moins, pas en faisant moins bien. Ces décisions font gagner le plus de temps :

• Coupez des parcours entiers, pas la finition. Reportez les parcours secondaires à une version ultérieure au lieu de construire chaque parcours à moitié.
• Lancez d’abord sur le web. Une application web responsive touche les utilisateurs sur mobile et sur ordinateur, sans validation des stores.
• Utilisez des services éprouvés. Une page de paiement hébergée, des services de connexion et d’e-mail existants sont plus rapides et plus sûrs que des versions maison.
• Décidez vite. Désignez une personne capable de valider les maquettes et de répondre aux questions dans la journée.
• Testez tôt avec quelques utilisateurs. Les travaux de Jakob Nielsen ont montré que tester avec 5 utilisateurs révèle la plupart des problèmes d’utilisabilité : plusieurs petits tours valent mieux qu’un grand.

CarPixly, un studio photo à base d’IA pour les annonces automobiles, a publié sa version Android sous forme d’APK sur sa propre page de téléchargement, pendant que la version iOS était encore en préparation. Lancer là où c’est possible et ajouter les plateformes ensuite est souvent le chemin le plus rapide vers de vrais utilisateurs.

Les premières semaines vont plus vite si quelques éléments sont prêts avant le démarrage. Aucun ne demande de bagage technique :

• Une courte liste de parcours principaux. Les une à trois tâches que les utilisateurs doivent pouvoir accomplir au lancement, en mots simples.
• Une personne qui décide. Quelqu’un qui peut valider les maquettes et répondre aux questions dans la journée.
• L’accès aux comptes existants. Domaine, hébergement, analytics, prestataire de paiement et toutes les API que vous utilisez déjà.
• Des contenus réels, ou une date pour les avoir. Textes, prix, pages juridiques et données d’exemple que le produit affichera.
• Votre contrainte de lancement. L’événement, le rendez-vous investisseurs ou la saison qui rendent la date importante.

Avec ces éléments en main, le chiffrage prend des jours plutôt que des semaines, et le design peut démarrer sur des contenus réels plutôt que sur des textes de remplissage.

Les délais dérapent rarement parce que les développeurs tapent lentement. Ils dérapent à cause des décisions prises, ou non prises, autour du développement :

• Un périmètre qui grossit en cours de projet sans procédure de changement écrite.
• Des allers-retours qui prennent une semaine au lieu d’une journée.
• Une définition de « terminé » que personne n’a écrite, si bien que les dernières semaines tournent au débat.
• Des intégrations prévues en une ligne du périmètre au lieu de leurs vrais cas limites.

Un périmètre fixe avec une procédure de changement garde l’essentiel sous contrôle. Nous expliquons comment dans forfait ou régie.

Le lancement démarre un second compteur, il n’arrête pas le premier. Les premières semaines après la mise en ligne sont en général les plus chargées de tout le projet.

Les vrais utilisateurs trouvent des bugs que les tests ont manqués, demandent de petits changements et utilisent le produit d’une façon que personne n’avait prévue. Prévoyez juste après le lancement une courte période de corrections et d’améliorations rapides, avant toute nouvelle fonctionnalité.

Ensuite, le travail prend un rythme régulier : un plan mensuel d’améliorations fondé sur l’usage réel. Chaque projet Sakura comprend une période de garantie définie pour les corrections, et le travail suivant peut continuer avec un plan mensuel ou passer à votre propre équipe.

Le moins possible, tant qu’il teste encore votre hypothèse principale. L’intérêt d’un MVP, selon la formule du Lean Startup, est de « commencer à apprendre le plus vite possible ».

Si votre planning dépasse largement le niveau complexe, demandez-vous ce que vous voulez apprendre et si un produit plus petit pourrait vous l’apprendre aussi. Souvent, un seul parcours lancé plus tôt répond à la question qui compte le plus.

Quand vous serez prêt à planifier le vôtre, parlez-nous de votre produit. Vous recevrez une proposition avec périmètre, délai et prix ferme, et chaque semaine une version pour le voir prendre forme.