Refaire un produit sans interrompre le travail
Protégez ce qui fonctionne déjà
Un code ancien n’est pas forcément un mauvais code. Certaines parties peuvent être pénibles à maintenir tout en servant les clients chaque jour. Notez les parcours, les intégrations et les habitudes de travail qui ne doivent pas casser pendant la refonte. Le nouvel ensemble devra les préserver, même si son implémentation change entièrement.
Chiffrez le coût du système actuel
Dire que le code est désordonné ne suffit pas à justifier une refonte. Cherchez son coût. Une mise en production peut prendre plusieurs jours de trop. La même zone peut provoquer des incidents réguliers, ou une fonctionnalité attendue peut rester bloquée parce que personne ne peut modifier cette partie sans risque.
Utilisez les données dont vous disposez déjà. Les heures perdues, les sorties retardées et les pannes récurrentes permettent de choisir entre un remplacement ciblé et un chantier plus large.
Choisissez une première limite claire
Commencez par une partie avec un début et une fin identifiables, comme une page, un service ou une tâche interne. Elle doit pouvoir être mise en production pendant que le reste du produit continue sur le système actuel. Cette limite permet d’apprendre au contact de l’usage sans engager immédiatement tout le produit.
Traitez la première livraison comme un test de cette limite précise. La partie remplacée doit mieux fonctionner et pouvoir cohabiter avec le reste.
Rendez chaque livraison réversible
Choisissez le chemin de retour avant de commencer l’implémentation. Vous pouvez utiliser un feature flag, faire tourner les deux versions en parallèle ou garder l’ancienne version prête à être redéployée. La méthode dépend de la partie concernée, mais l’équipe doit savoir revenir en arrière avant d’en avoir besoin.
Définissez la fin avant de commencer
Écrivez les conditions d’acceptation de chaque partie et nommez la personne qui les valide. La refonte n’absorbera ainsi pas toutes les améliorations découvertes en chemin. Une nouvelle idée peut être utile, mais elle doit devenir un travail distinct au lieu d’allonger discrètement la partie en cours.
Devloop