Quand faut-il refondre un MVP ?

Définir le déclencheur comme contrainte produit

Écrivez le résultat utilisateur ou opérationnel que le système ne supporte pas fiablement. Joignez incidents, changements échoués, limites mesurées, dépendances non supportées, parcours critiques inaccessibles ou récupération impossible. Séparez douleur présente et échelle future supposée. Un volume hypothétique ou une architecture détestée reste un signal faible sans seuil testé et besoin proche crédible.

Arrêtez une proposition sans objectif produit maintenu, propriétaire des données ou décideur. Une nouvelle implémentation ne corrige ni proposition de valeur floue, ni utilisateurs absents, ni exploitation sans responsable. Si la direction reste non validée, revenez à la découverte ou à une expérience plus petite au lieu de transformer l’incertitude en nouvelle plateforme.

Inventorier ce qui doit survivre

Cartographiez parcours critiques, règles métier, données, intégrations, identités, permissions, analytics, obligations, domaines, stores, déploiement et support. Distinguez comportement volontaire et accidentel dont les utilisateurs dépendent pourtant. Identifiez sources de vérité, conservation et contraintes fournisseur. Ne partez pas seulement de la liste des écrans.

Établissez une base de production: fréquence des pannes, effort de récupération, délai de publication, testabilité, maintenabilité et performance mesurée si pertinente. Notez la qualité et les trous de preuve. Cette base permet de vérifier l’amélioration et empêche qu’une refonte visuellement propre soit appelée succès si fiabilité ou exploitation se dégrade.

Tester réparation, confinement et remplacement

Menez une investigation bornée sur la contrainte la plus dure: mise à jour d’une dépendance, frontière API autour d’un composant fragile, tests de caractérisation, correction des données ou remplacement d’une tranche. Mesurez le risque retiré sans migrer tout le produit et conservez un repli tant que la nouvelle voie n’est pas prouvée.

Si la refonte reste justifiée, séquencez-la par résultats utilisateur et migration de données, pas par reproduction des écrans. Définissez coexistence, validation, rollback, support et décommissionnement. Donnez une date de décision à chaque composant pour éviter deux systèmes indéfinis. Une bascule unique exige des preuves de récupération plus fortes.

Recetter contre la contrainte initiale

Utilisez les mêmes parcours et limites mesurables sur les deux voies. Testez intégrité des données, permissions, erreurs, performance importante, accessibilité, observabilité, déploiement et récupération. Consignez défauts corrigés, limites restantes et changements volontaires. Le nouveau code n’est pas accepté si migration ou exploitation reste non prouvée.

Définissez la recette par des preuves observables, par exemple un parcours testé, un build approuvé, des contrôles reproductibles, un runbook d’incident et une transmission vérifiée. Rien de cela ne prouve rétention, revenu ou adéquation marché. Séparez preuve de livraison, approbation d’un fournisseur externe et résultat business.

Transmettre, observer et retirer volontairement

Placez dépôts, infrastructure et accès sous propriété de l’entreprise et documentez publication et récupération. Observez la nouvelle voie pendant une période ou un trafic défini avant retrait. Préservez données et preuves requises, retirez les accès obsolètes avec précaution et consignez la décision. Une migration technique réussie ne prouve aucun gain d’adoption ou commercial.

Gardez dépôts, domaines, stores, analytics, organisations cloud et identifiants de production sous une propriété explicite de l’entreprise. Accordez des accès limités et révocables, puis répétez la transmission avant la dernière facture. L’étiquette du prestataire compte moins que la capacité d’une autre personne autorisée à inspecter, déployer, reprendre et poursuivre le produit.

Critères de décision

Posez les mêmes questions à chaque option avant de choisir.