Votre équipe veut réécrire un système legacy. Comment tranchez-vous ?

Par défaut, préférez le remplacement incrémental à la réécriture complète. Les réécritures sous-estiment le comportement encodé dans l'ancien système et vous forcent à maintenir deux choses sans rien livrer de neuf. Préférez étrangler le système morceau par morceau derrière une interface stable, chaque étape apportant de la valeur par elle-même. N'envisagez une réécriture complète que si la plateforme est vraiment intenable et que vous pouvez protéger le calendrier de la pression fonctionnalités.

Mon réflexe est non, puis j'essaie de comprendre ce qu'ils veulent vraiment, parce que réécrire est en général un symptôme. Parfois la plateforme est vraiment morte, et parfois c'est que la suite de tests prend quarante minutes et que chaque changement est terrifiant, ce qui est un problème beaucoup moins cher à corriger. Quand le remplacement est justifié, je le veux incrémental : poser une interface devant l'ancien système, déplacer une capacité à la fois derrière elle, et s'assurer que chaque tranche est livrable et apporte quelque chose seule. Comme ça, le projet survit à une repriorisation, ce qu'une réécriture big bang sur deux ans ne fait jamais. Dans ma dernière équipe, on a remplacé comme ça un pipeline de commandes legacy en neuf mois environ, et on l'a mis en pause deux fois pour des raisons business sans rien perdre. Le cas où je ferais une vraie réécriture, c'est quand le runtime ou le framework est hors support sans chemin incrémental, et même là je veux une conversation écrite explicite avec la direction sur le gel des fonctionnalités, parce que l'échec classique c'est une réécriture plus une roadmap complète.