Vous avez un MVP à moitié construit. Le développeur est parti, a manqué de temps, ou le projet s’est essoufflé. Il reste sur une branche quelque part, presque fonctionnel, mais personne ne l’a mené jusqu’au bout. Bonne nouvelle : un MVP à 70 % se termine presque toujours. Voici comment.
1. Résistez à l’envie de tout refaire
C’est le premier réflexe, et souvent le mauvais. Reprendre du code qu’on n’a pas écrit est inconfortable, alors la tentation est grande de repartir de zéro. Mais un MVP presque fini contient des semaines de travail déjà payées. On garde ce qui tient, on ne refait que le nécessaire.
2. Redéfinissez la vraie ligne d’arrivée
Un MVP qui traîne, c’est souvent un périmètre qui a enflé. Avant de coder quoi que ce soit, tranchez : quelle est la plus petite version qui peut être mise en ligne et utilisée par de vrais utilisateurs ? Tout le reste attend. C’est la décision qui débloque le plus de projets.
3. Faites l’inventaire de l’existant
Un audit rapide répond à trois questions :
- qu’est-ce qui fonctionne vraiment (pas juste « en local ») ?
- qu’est-ce qui est commencé mais pas terminé ?
- qu’est-ce qui manque pour atteindre la ligne d’arrivée définie à l’étape 2 ?
À la sortie, vous avez une liste claire, pas une impression.
4. Priorisez ce qui bloque la mise en ligne
Tout ce qui empêche de déployer passe en premier : authentification bancale, base de données non déployée, paiement à moitié branché, bugs bloquants. Les améliorations « ce serait bien » viennent après le lancement, jamais avant.
5. Stabilisez avant d’ajouter
Ajouter des fonctionnalités sur une base instable, c’est construire sur du sable. On corrige ce qui casse, on met en place le minimum de tests sur les parcours critiques, puis on avance. C’est plus rapide au final, même si ça semble contre-intuitif.
6. Mettez en production, puis itérez
Un MVP n’a de valeur qu’entre les mains d’utilisateurs. On déploie la version minimale définie plus haut, on regarde ce qui se passe, et on améliore à partir du réel. Le lancement n’est pas la fin, c’est le début des vraies décisions.
C’est exactement la manière dont je reprends un MVP en plan sur une reprise de projet : j’audite, je coupe le superflu, je stabilise, et je le mets en ligne. Prix fixe, et vous gardez le code.
En résumé
Un MVP laissé en plan n’est presque jamais à jeter. Redéfinissez la ligne d’arrivée, gardez ce qui tient, stabilisez, et mettez en ligne une version minimale plutôt que d’attendre le « parfait ». La plupart du temps, il reste moins à faire qu’on ne le croit.
Un MVP bloqué à mi-chemin ? Faites un audit. Je vous dis ce qui est récupérable et combien il reste vraiment à faire.
Questions fréquentes
Combien de temps pour finir un MVP repris ? Souvent quelques semaines une fois le périmètre resserré. Le facteur décisif n’est pas le code restant, c’est la clarté sur la ligne d’arrivée.
Et si le code est de mauvaise qualité ? On garde ce qui permet de livrer vite, on isole ce qui est risqué, et on remplace au fil de l’eau. Réécrire entièrement avant de lancer est rarement le bon calcul pour un MVP.
Faut-il ajouter des tests ? Le minimum sur les parcours critiques, oui. Pas une couverture complète : l’objectif est de livrer et d’apprendre, pas d’atteindre la perfection technique.