Système hérité : tout réécrire ou refactoriser par étapes ?

Dans la plupart des cas, remplacez par morceaux. La réécriture complète ne se justifie que si la plateforme sous-jacente n’est plus maintenue en sécurité, ou si le modèle de données d’origine empêche l’activité de croître. En dehors de cela, vous passerez deux ans à reconstruire des fonctionnalités qui marchaient déjà.

La demande arrive toujours avec la même phrase : « ce système est un désastre, autant tout refaire ». Parfois c’est vrai. La plupart du temps, c’est la réaction naturelle de quelqu’un qui découvre du code qu’il n’a pas écrit, et la réécriture complète est la décision la plus coûteuse que l’on puisse prendre sur un système en production.

Ce que coûte réellement une réécriture

Le budget prévoit toujours de reconstruire ce que l’on voit. Il ne prévoit jamais les cinq années de correctifs invisibles incorporés au système actuel.

Ce if bizarre dans le calcul des frais de port n’est pas du mauvais code. C’est l’exception du contrat avec ce gros client, réglée un vendredi après-midi de 2019. Le nouveau système, propre et bien architecturé, n’aura pas ce if. Il aura le même problème dont ce client s’est plaint en 2019.

Ajoutez le détail qui tue les plannings : pendant la réécriture, l’ancien système ne peut pas cesser d’évoluer. L’activité continue de demander des choses. Soit vous gelez le produit pendant deux ans, ce qu’aucune entreprise ne supporte, soit vous implémentez tout en double.

Quand la réécriture se justifie vraiment

Il existe des cas légitimes, et ils sont reconnaissables :

• La plateforme n’est plus maintenue en sécurité. Une version de langage ou de framework sans correctifs de vulnérabilité n’est pas une dette technique. C’est un risque juridique et opérationnel.
• Le modèle de données bloque l’activité. Le système a été conçu pour une entité et une devise, et il y a désormais cinq filiales dans trois pays. Si chaque nouvelle exigence bute sur la même limite structurelle, le problème est dans les fondations.
• Plus personne ne peut y toucher. Non parce que c’est laid, mais parce que la technologie ne se trouve plus sur le marché et qu’aucun test ne donne à quiconque la confiance nécessaire pour modifier quoi que ce soit.

Notez que « le code est laid » et « nous n’aimons pas ce langage » ne figurent pas dans cette liste.

L’alternative : étrangler l’existant progressivement

L’approche qui fonctionne porte le nom de figuier étrangleur, en référence à l’arbre qui pousse autour de son hôte jusqu’à le remplacer entièrement. En pratique :

1. Placez un routeur devant l’ancien système. Tout continue de fonctionner comme avant.
2. Choisissez une fonctionnalité à frontière nette et à forte valeur. Reconstruisez-la seule, dans le nouvel environnement.
3. Redirigez les requêtes de cette fonctionnalité vers le nouveau système. En cas de problème, redirigez-les en arrière en une minute.
4. Recommencez. À chaque cycle, l’existant rétrécit.

L’avantage ici n’est même pas technique, il est politique. Le projet livre de la valeur visible chaque mois au lieu de demander deux ans de confiance. Cela change le regard de la direction sur l’investissement et, en pratique, c’est ce qui permet au projet d’aller au bout.

Avant de choisir, placez un filet sous l’existant

Quelle que soit la décision, faites ceci d’abord, car cela sert les deux stratégies :

• Une sauvegarde restaurée. Pas « les sauvegardes sont configurées ». Restaurée, dans un autre environnement, avec une date consignée.
• Des tests sur les parcours qui génèrent du chiffre. Ne visez pas une couverture large. Couvrez les cinq chemins qui ne doivent pas casser.
• De la journalisation et de la supervision. Il faut savoir ce que fait le système avant de le modifier. Beaucoup d’équipes découvrent à ce stade que la moitié des écrans ne sert jamais, ce qui réduit de moitié le périmètre de la réécriture.
• Un environnement de test fidèle. Sans lui, chaque modification est un pari.

Ce travail prend trois à six semaines et change fréquemment la conclusion. J’ai vu plusieurs systèmes qui « devaient être refaits » devenir parfaitement acceptables une fois dotés de supervision, d’index et débarrassés de ce que personne n’utilisait.

La question qui tranche

Une seule : le système actuel empêche-t-il l’entreprise de faire quelque chose dont elle a besoin pour croître ?

Si la réponse est non, il est pénible, il est lent, il est laid, mais l’activité tourne, alors améliorez-le par morceaux. Si la réponse est oui et que vous pouvez nommer précisément ce qui est bloqué, il existe un dossier concret. Et même dans ce cas, le remplacement progressif arrive généralement plus vite.