Presque tout fondateur face à un MVP cassé demande s'il faut le réécrire. Presque à chaque fois, la réponse est non — et la raison est arithmétique, pas sentimentale.
Un MVP cassé se manifeste généralement de trois façons : il s'effondre sous l'usage réel, chaque changement en casse un autre, ou les développeurs d'origine sont partis et personne ne le comprend. L'instinct dit de recommencer. Cet instinct coûte cher et se trompe le plus souvent.
Pourquoi la réécriture est un piège
La réécriture séduit parce que le nouveau système est imaginaire, et les systèmes imaginaires n'ont pas de bugs. En réalité :
- Le code existant encode des années de cas limites que personne n'a documentés — on les redécouvrira sous forme d'incidents en production
- Vous gelez le développement de fonctionnalités pendant des mois, pas vos concurrents
- La réécriture rencontre la même complexité, parce que la complexité est dans le domaine, pas dans le code
- Les estimations de réécriture sont fausses avec une large marge, systématiquement, dans toutes les organisations
Étape 1 : arrêter l'hémorragie
Avant d'améliorer quoi que ce soit, rendez le système observable et récupérable. On ne corrige pas ce qu'on ne voit pas, et on n'expérimente pas sans chemin de retour.
- Suivi des erreurs, pour que les défaillances soient connues plutôt que signalées par les clients
- Supervision de la disponibilité et des transactions clés — paiement, inscription, encaissement
- Un rollback qui fonctionne et a été testé
- Des sauvegardes, et une restauration réellement effectuée au moins une fois
Étape 2 : trier, pas inventorier
Résistez à l'envie de lister tout ce qui ne va pas. Classez les problèmes par conséquence :
| Catégorie | Définition | Action |
|---|---|---|
| Hémorragique | Perd de l'argent, des données ou des clients maintenant | Corriger cette semaine |
| Bloquant | Empêche de livrer la roadmap du trimestre | Corriger ce trimestre |
| Cumulatif | Ralentit chaque changement | Planifier délibérément |
| Cosmétique | Heurte le goût, ne coûte rien | Jamais |
La plupart des missions de sauvetage trouvent deux ou trois éléments dans la première catégorie et une poignée dans la deuxième. C'est un programme de travail gérable — bien différent de l'impression écrasante qu'avait l'équipe avant le tri.
Étape 3 : corriger dans l'ordre qui compose
- L'intégrité des données d'abord — des données corrompues ou perdues sont irrécupérables d'une manière que l'indisponibilité n'est pas
- Puis le chemin de déploiement — tant que livrer n'est pas sûr et fréquent, chaque autre correctif part lentement et risque
- Puis la principale source de pannes — généralement un ou deux endpoints ou requêtes causent l'essentiel des incidents
- Puis le bloqueur de changement — le couplage ou l'absence de tests qui fait que l'équipe a peur de toucher
- Seulement ensuite, la performance et la finition
Étape 4 : prévenir la rechute
- Des tests sur les chemins qui font mal — argent, authentification, et précisément ce qui a cassé
- Un journal de décisions écrit, pour que le prochain ingénieur hérite du raisonnement et pas seulement du code
- Un processus de déploiement que n'importe qui dans l'équipe peut exécuter
- Une règle explicite : la roadmap inclut de la capacité de maintenance — sinon la dette revient
Un sauvetage n'est pas un nettoyage. C'est un petit nombre de changements ciblés qui font passer le système de dangereux à ennuyeux — et c'est l'ennui qui permet à une équipe de livrer à nouveau.
Délimiter une réparation avant de réécrire
Démontrer qu'un parcours défaillant peut être stabilisé. Utiliser ce résultat pour estimer la suite et comparer un remplacement.
- Écrire un test reproduisant le défaut constaté.
- Réparer une zone limitée et vérifier les comportements voisins.
- Comparer réparation et remplacement avec migration et exploitation parallèle.
Questions fréquentes
Faut-il réécrire notre MVP ou le réparer ?
Le réparer, sauf si la plateforme est insupportable, si le produit a fondamentalement changé, ou si tout le système peut être reconstruit en quelques semaines. Les réécritures gèlent le travail produit pendant des mois, redécouvrent les cas limites oubliés sous forme d'incidents, et dépassent systématiquement leurs estimations.
Combien de temps prend un sauvetage de MVP ?
Le tri prend des jours. Stabiliser les points critiques prend typiquement deux à six semaines selon la gravité. La remédiation complète de la dette cumulative demande un trimestre ou plus — mais elle se fait en parallèle du travail produit, pas à sa place.
Nos développeurs d'origine sont partis. Le code est-il encore récupérable ?
Presque toujours. Perdre les auteurs rend le travail plus lent, pas impossible : la première tâche est de reconstituer le comportement réel du système — par la lecture, l'instrumentation et des tests de caractérisation — avant de changer quoi que ce soit.
Comment savoir si notre MVP est vraiment cassé ou seulement imparfait ?
Demandez s'il perd de l'argent ou des données, s'il empêche de livrer la roadmap, et si l'équipe a peur de déployer. Si rien de tout cela n'est vrai, vous avez un MVP imparfait — ce qui est normal et ne justifie aucune intervention.
Quand suspendre le développement de fonctionnalités ?
Lorsque les changements empêchent le diagnostic ou augmentent les risques importants pour les données et la disponibilité. Définir périmètre de pause et conditions de reprise.
MVP en difficulté ?
Nous trions en quelques jours et vous disons honnêtement s'il faut un sauvetage, une réécriture, ou rien du tout.
Pour aller plus loin
Audit technique de MVP : ce que nous vérifions dans les 48 premières heures
La plupart des audits de MVP produisent un document. Un audit utile produit des décisions : ce qui brûle, ce qui peut attendre, et ce que coûte la correction.
Dette technique en startup : à partir de quand est-ce trop ?
Toute startup a de la dette technique, et l'essentiel était le bon choix. La question n'est pas comment l'éliminer — c'est quelles parties facturent des intérêts que vous ne pouvez plus payer.