Après le lancement de ton MVP : les 90 premiers jours

Ton MVP est en ligne. Tu l’as annoncé sur LinkedIn, partagé à tes proches, posté sur deux ou trois forums. Et maintenant : le silence. Pas de signups. Ou pire : des gens viennent, cliquent, et repartent sans rien faire.

C’est normal. La majorité des lancements commencent comme ça. Le problème, ce n’est pas le silence. C’est ce que tu fais après.

La plupart des fondateurs réagissent en ajoutant des features. “Il manque sûrement quelque chose.” Non. Ce qui manque, c’est de la donnée. Après le lancement de ton MVP, les 90 premiers jours sont une phase de mesure, pas de construction. Ce guide te donne les métriques à suivre, les décisions à prendre, et le plan pour passer de l’hypothèse à un vrai produit.

Les 30 premiers jours : mesurer avant de construire

Le silence est normal

Un lancement sur Product Hunt, Reddit ou Hacker News peut générer un pic de trafic. Des milliers de visiteurs en quelques heures. Le problème : ça valide la curiosité, pas le product-market fit.

Un pic de trafic sans rétention ne vaut rien. Ce qui compte, ce sont les 10 à 50 premiers utilisateurs qui reviennent le lendemain. Pas les milliers qui passent et disparaissent.

Ne traite pas le lancement comme un événement unique. C’est un processus continu. Si personne ne vient, cible 10 personnes via des messages directs et des conversations individuelles. Pas 1 000 via des posts génériques.

Les 3 métriques qui comptent (et celles à ignorer)

Rétention D1/D7/D30. C’est la seule métrique qui prédit la survie de ton produit. Andrew Chen (ex-a16z) a analysé des milliers de courbes de rétention et la conclusion est toujours la même : la rétention suit une courbe de décroissance géométrique. Ton D1 est divisé par 2 à D7. Ton D7 est divisé par 2 à D30. Une rétention D30 supérieure à 50% est exceptionnellement rare.

Si ta D30 est sous 10%, aucune feature ne la sauvera. C’est le produit ou le marché qui pose problème.

Le Sean Ellis test. Pose cette question à tes utilisateurs : “Seriez-vous très déçu si ce produit n’existait plus ?” Si moins de 40% répondent “très déçu”, tu n’as pas de product-market fit. C’est le seuil utilisé par la majorité des startups early-stage pour décider s’il faut itérer ou pivoter.

Ce qu’il faut ignorer. Le nombre de téléchargements. Les followers. Les “likes”. Les vanity metrics ne paient pas les serveurs.

L’onboarding avant les features

Le gap entre “inscrit” et “première valeur obtenue” est le vrai tueur de MVPs. Tu perds la majorité de tes utilisateurs avant même qu’ils comprennent ce que fait ton produit.

Améliorer l’onboarding réduit le volume de support de moitié. Sans ajouter une seule feature. Le réflexe de construire plus est un piège. Si tes utilisateurs ne trouvent pas la valeur dans les 30 premières secondes, ce n’est pas un problème de feature. C’est un problème de parcours.

Avant de toucher à ta roadmap : combien de temps faut-il à un nouvel utilisateur pour obtenir son premier résultat ? Si la réponse est “plus de 2 minutes”, commence par là.

Itérer, pivoter ou abandonner

Le diagnostic en 3 catégories

Quand ton MVP ne décolle pas, la raison tombe dans l’une de ces trois catégories :

• Feature problem : le produit ne résout pas bien le problème. Les utilisateurs s’inscrivent mais décrochent vite. Solution : itérer.
• Market problem : personne n’a ce problème, ou pas assez de gens. Faible acquisition malgré un bon produit. Solution : pivoter.
• Message problem : les gens ne comprennent pas ce que tu fais. Le trafic arrive mais le taux de conversion est quasi nul. Solution : changer le positionnement, pas le produit.

La confusion entre les trois coûte des mois. Un fondateur qui ajoute des features pour un message problem perd son temps. Un autre qui change son positionnement pour un market problem aussi.

Quand itérer (et sur quoi)

La boucle lean startup - construire, mesurer, apprendre - fonctionne. Mais avec une règle : ne construis que ce que plusieurs utilisateurs demandent. Une seule demande n’est pas un signal. Trois demandes indépendantes sur le même point, c’en est un.

Le piège classique : accumuler 100 idées de features pendant le développement du MVP et vouloir toutes les implémenter après le lancement. Un fondateur construit 3 features pour sa V1 alors que ses utilisateurs n’en veulent qu’une seule. Se concentrer sur cette feature unique aurait fait gagner 15 jours.

Le framework RICE (Reach, Impact, Confidence, Effort) aide à prioriser. Mais le meilleur filtre reste le feedback direct. Pour aller plus loin sur la priorisation, lis le guide quelles features inclure dans ton MVP.

Quand pivoter

Les signaux sont clairs :

• Rétention D30 sous 10% après 2-3 itérations sérieuses
• Sean Ellis test sous 40% malgré des améliorations produit
• Tu dépenses plus en acquisition qu’en valeur générée

Pivoter ne veut pas dire tout jeter. Souvent, c’est le business model qui change, pas le produit. Slopes, une app de ski, a lancé à 4.99$ avec 600 téléchargements la première saison. Le fondateur a pivoté vers un modèle freemium avec abonnement saisonnier. Résultat : 1M$ de revenu annuel récurrent, 9 ans plus tard, avec moins de 40 000$ de dépenses publicitaires sur toute la vie du produit.

Le scope creep est l’ennemi du pivot. Si tu décides de changer de direction, change vite et proprement.

La dette technique : ce qu’il faut corriger (et ce qu’il faut garder)

Dette stratégique vs dette accidentelle

Ton MVP a de la dette technique. C’est voulu. Tu as hardcodé des valeurs au lieu de créer un panneau d’administration. Tu as sauté les tests automatisés. Tu as copié-collé du code au lieu de factoriser. C’est du pragmatisme.

Mais après le lancement, les signaux d’alerte apparaissent vite. Une feature simple prend deux fois plus longtemps que prévu. Corriger un bug en crée deux nouveaux. L’équipe passe plus de temps à se battre contre le code qu’à construire.

La distinction qui compte :

• Dette stratégique (à garder) : les raccourcis intentionnels qui marchent. Hardcoder une configuration au lieu de créer une interface d’admin, utiliser un script manuel au lieu d’automatiser un process rare.
• Dette accidentelle (à corriger) : le code spaghetti, les dépendances non documentées, les failles de sécurité connues. Ce qui ralentit chaque intervention future.

La règle des 20% : alloue 10 à 20% de chaque cycle de développement à la maintenance et au remboursement de dette. C’est un investissement, pas une perte de temps.

Rebuild vs refactor

Ne reconstruit pas tout. La majorité des cas ne le justifient pas.

80% des bugs viennent de 20% du code. Identifie ces fichiers et concentre tes efforts dessus. Le reste peut attendre.

Après le lancement, environ 40% du temps d’ingénierie part sur des edge cases sans rapport avec le produit principal. Données inconsistantes, problèmes d’encodage, formats inattendus. C’est normal. Les processus manuels qui fonctionnaient avec 5 utilisateurs cassent avec 50.

Le rebuild complet ne se justifie que si l’hypothèse est validée et que l’architecture initiale bloque le passage à l’échelle. Le prototype a prouvé que le marché existe. Maintenant il faut du code production. C’est la transition classique après un MVP vibe-codé - les limites du vibe coding sont documentées.

Le passage à la V1

MVP ≠ V1

Le MVP valide une hypothèse. La V1 est un produit stable pour les premiers clients payants. Ce n’est pas le même objet.

Le Minimum Marketable Product (MMP) est le seuil intermédiaire : le point où tu peux commencer à facturer. Pas encore parfait, mais suffisamment fiable pour qu’un client accepte de payer.

Le SaaS n’est pas un revenu passif. Après le lancement, le “vrai travail” commence : support client, correction de bugs, onboarding, prévention du churn, marketing continu. Les fondateurs qui pensent que “lancer = finir” se retrouvent à court de cash en 6 mois.

Ce que la V1 ajoute au MVP

Le MVP avait zéro test, zéro monitoring, un onboarding manuel. La V1 corrige ça :

• Monitoring et alerting : savoir quand ton app plante avant que tes utilisateurs te le disent
• Tests automatisés : le MVP n’en avait pas, c’est le moment d’en ajouter sur les parcours critiques
• Onboarding automatisé : tu ne peux plus guider chaque utilisateur à la main quand ils sont 200
• Sécurité renforcée : le code généré par IA contient 1,7 fois plus de bugs que le code humain (CodeRabbit, 470 projets). Le MVP a des failles connues - la V1 les corrige

Le budget réaliste

15 à 20% du coût de développement initial par an en maintenance. C’est la fourchette standard. Un MVP à 5 000 EUR coûte 750 à 1 000 EUR par an à maintenir.

La maintenance corrective seule peut coûter 500 à 5 000 EUR par mois selon la complexité. Un logiciel non maintenu pendant 2 ans coûte 2 à 3 fois plus cher à remettre à niveau qu’un logiciel entretenu régulièrement. Et les applications non maintenues perdent la majorité de leur audience en moins d’un an.

Pour les chiffres détaillés par poste (hébergement, monitoring, mises à jour), lis le guide coût de maintenance d’une application.

Le pricing post-MVP

Comment passer du gratuit au payant ? Commence par identifier les utilisateurs qui tirent le plus de valeur de ton produit. Ce sont eux qui paieront en premier.

Teste plusieurs modèles : freemium, essai gratuit de 14 jours, paiement à l’usage. Fixer un prix arbitraire sans recherche est une erreur fréquente. Le pricing n’est pas une science exacte au stade post-MVP. C’est une série d’expériences.

Les 90 jours en résumé

Semaines 1-4 : mesurer. Ne touche pas au code. Parle à tes utilisateurs et collecte du feedback méthodiquement. Regarde comment ils utilisent ton produit. Passe le Sean Ellis test. Si tu n’as pas 10 conversations réelles à la fin du premier mois, tu avances à l’aveugle.

Semaines 5-8 : décider. Les données sont là. Soit la rétention tient et tu itères sur le feedback. Soit elle ne tient pas et tu dois pivoter. La pire décision à ce stade : ne rien décider et continuer à construire dans le vide.

Semaines 9-12 : stabiliser. Si le product-market fit se confirme, c’est le moment de rembourser la dette technique critique, de poser les bases de la V1, et de tracer la suite après le MVP startup.

Si tu veux que je t’accompagne sur cette transition MVP vers V1, c’est exactement ce que fait mon agence vibe coding à Paris.

Foire aux questions

Que faire après avoir lancé un MVP ?

Mesurer avant de construire. Les 30 premiers jours doivent servir à collecter du feedback utilisateur, suivre la rétention D1/D7/D30, et passer le Sean Ellis test. L’erreur la plus courante est d’ajouter des features au lieu d’écouter les premiers utilisateurs.

Comment savoir si mon MVP a du product-market fit ?

Pose cette question à tes utilisateurs : “Seriez-vous très déçu si ce produit n’existait plus ?” Si moins de 40% répondent oui, tu n’as pas de product-market fit. C’est le Sean Ellis test, utilisé par la majorité des startups en phase early-stage.

Quand faut-il pivoter après un MVP ?

Si ta rétention D30 reste sous 10% après 2-3 itérations sérieuses, ou si ton Sean Ellis score reste sous 40% malgré des améliorations produit, c’est le signal. Le pivot ne veut pas dire tout reconstruire. Souvent, c’est le business model ou le positionnement qui change, pas le produit.

Combien coûte la maintenance d’un MVP par mois ?

Entre 500 et 5 000 EUR par mois selon la complexité. En règle générale, 15 à 20% du coût de développement initial par an. Ne pas maintenir son application coûte 2 à 3 fois plus cher à rattraper ensuite. Le guide coût de maintenance d’une application détaille les postes de dépenses.

C’est quoi la différence entre un MVP et une V1 ?

Le MVP valide une hypothèse de marché. La V1 est un produit stable pour les premiers clients payants. La V1 ajoute ce que le MVP n’a pas : monitoring, tests automatisés, onboarding automatisé, sécurité renforcée. C’est le moment où tu passes de l’expérimentation à l’exploitation.

Comment prioriser les features après le MVP ?

Ne construis que ce que plusieurs utilisateurs demandent. Une seule demande n’est pas un signal. Le framework RICE (Reach, Impact, Confidence, Effort) est un bon point de départ. Et le meilleur levier post-MVP est rarement une nouvelle feature - c’est l’amélioration de l’onboarding.

Faut-il tout reconstruire après le MVP ?

Non. Refactorer les parties critiques suffit dans la majorité des cas. 80% des bugs viennent de 20% du code. Concentre-toi sur ces fichiers. Le rebuild complet ne se justifie que si l’architecture initiale bloque totalement le passage à l’échelle.

Combien de temps dure la phase post-MVP ?

90 jours minimum. Les 30 premiers jours pour mesurer, les 30 suivants pour décider (itérer ou pivoter), les 30 derniers pour stabiliser et préparer la V1. Certaines startups restent en phase d’itération post-MVP pendant 6 à 12 mois avant de trouver le bon modèle.

Comment passer du MVP gratuit au payant ?

Identifie les utilisateurs qui tirent le plus de valeur de ton produit. Ce sont eux qui paieront en premier. Teste plusieurs modèles : freemium, essai gratuit de 14 jours, paiement à l’usage. Le pricing au stade post-MVP n’est pas une science exacte - c’est une série d’expériences.

Comment collecter les retours utilisateurs après le lancement ?

Parle à tes utilisateurs directement. 10 conversations valent plus que 1 000 réponses à un formulaire. Utilise des outils comme Hotjar pour observer les comportements réels. Et passe le Sean Ellis test à chaque nouvelle cohorte pour suivre l’évolution du product-market fit dans le temps.