Une refonte n'est pas un greenfield. Vous avez des utilisateurs, des données, des habitudes d'usage et une dette technique héritée. Appliquer une logique MVP à une refonte, c'est décider ce qui vaut la peine d'être reconstruit maintenant et ce qui peut attendre — ou disparaître.
C'est souvent plus complexe qu'un développement from scratch car il faut gérer la transition sans interrompre le service.
Audit avant refonte : ce qu'il faut évaluer
Avant de définir le périmètre de refonte, un audit technique permet d'identifier : ce qui fonctionne et doit être conservé, ce qui peut être migré vers une nouvelle stack sans réécriture complète, et ce qui est si dégradé qu'une réécriture est inévitable.
L'audit couvre aussi les données : migration des comptes utilisateurs existants, historique des transactions, contenu généré par les utilisateurs. Ces sujets ont un impact direct sur le périmètre et les délais de la refonte.
Refonte progressive vs refonte totale
La refonte progressive consiste à remplacer les modules un par un en maintenant l'existant en parallèle. Elle réduit le risque mais allonge la durée totale et crée une complexité de coexistence entre l'ancien et le nouveau.
La refonte totale (« big bang ») remplace tout d'un coup. Elle est plus risquée mais plus propre. Elle est justifiée quand la dette technique est trop importante pour être migrée progressivement, ou quand le modèle de données doit changer en profondeur.
Gérer la migration des utilisateurs
La migration des comptes existants est souvent sous-estimée. Elle nécessite : un script de migration des données, une communication proactive auprès des utilisateurs, et une période de transition pendant laquelle les deux versions coexistent.
Si votre base d'utilisateurs est petite (moins de 1 000 comptes), la migration manuelle ou semi-manuelle est souvent plus sûre qu'un script automatisé.
Ce que la refonte MVP ne fait pas
Une refonte MVP ne reconstruit pas tout. Elle identifie les fonctionnalités réellement utilisées (souvent 20 % des fonctionnalités existantes génèrent 80 % de l'usage) et se concentre sur celles-là. Les fonctionnalités peu utilisées sont supprimées ou reportées en v2.
C'est souvent l'occasion de simplifier drastiquement le produit. Des années d'accumulation de fonctionnalités « demandées par quelqu'un » créent des interfaces que personne ne comprend. La refonte est une opportunité de reprendre la main sur la cohérence du produit.