Un code legacy, c'est un code qui tourne encore, qui génère du chiffre d'affaires, mais que plus personne dans l'entreprise ne comprend vraiment. Pas de documentation à jour, les développeurs qui l'ont écrit sont partis depuis longtemps, les dépendances ne sont plus maintenues. Le problème n'est pas que ce code "marche mal" : il marche. Le problème, c'est qu'on ne sait plus exactement ce qui se passe à l'intérieur, et que chaque évolution devient un pari.
Ce n'est pas une urgence systématique. Un système legacy peut tourner des années sans incident majeur. La vraie question n'est pas "faut-il s'en débarrasser", mais "qu'est-ce qu'on fait avec, concrètement, compte tenu de ce qu'il coûte et de ce qu'il rapporte". Trois options existent : garder, refactorer ou réécrire. Chacune a ses conditions.
Code legacy, application legacy, système legacy : de quoi on parle
Un code legacy n'est pas forcément un vieux code. Une application écrite il y a deux ans par un développeur freelance, sans tests ni documentation, peut déjà être du legacy si plus personne ne peut y toucher sereinement. Ce qui définit le legacy, c'est l'écart entre ce que le code fait et ce qu'on comprend de son fonctionnement interne.
On retrouve ce type de situation sous plusieurs formes : un logiciel métier développé par un prestataire qui a disparu, un site e-commerce rafistolé par plusieurs agences successives, une application mobile dont le code source n'a jamais été transmis au client. Dans tous les cas, le symptôme est le même : personne ne veut y toucher, par peur de casser quelque chose qu'on ne sait pas réparer.
Les signaux qui indiquent que le legacy devient un vrai risque
Certains signes doivent alerter plus que d'autres :
- Une seule personne (interne ou prestataire) sait faire fonctionner le système, et son départ mettrait l'activité en difficulté.
- Les mises à jour de sécurité ne sont plus possibles car les librairies utilisées sont abandonnées.
- Chaque nouvelle fonctionnalité prend trois fois plus de temps que ce qu'elle devrait, parce qu'il faut d'abord comprendre le code existant.
- Le code source n'est même plus accessible, ou personne ne sait où il est hébergé.
- L'hébergeur ou la techno sous-jacente arrive en fin de support.
Un seul de ces signaux justifie qu'on s'y penche. Plusieurs cumulés, et le risque business devient réel : panne non réparable, faille de sécurité non corrigée, ou simplement incapacité à faire évoluer le produit pendant que la concurrence avance.
Garder le code en l'état : quand ça suffit
Toucher à un système qui fonctionne a un coût et un risque. Si l'application legacy répond encore au besoin, que personne ne prévoit de l'étendre significativement, et qu'elle reste surveillée (sauvegardes, monitoring, mises à jour de sécurité a minima), il n'y a souvent aucune raison de se précipiter sur une refonte.
Dans ce cas, l'enjeu est de sécuriser l'existant sans le réécrire : s'assurer qu'on a une copie du code source, documenter au moins les grandes lignes de fonctionnement, et mettre en place une maintenance de site web qui surveille les points de rupture (certificats, versions de langage, dépendances critiques). C'est souvent l'option la plus raisonnable à court terme, même si elle n'est jamais permanente.
Refactorer : nettoyer sans tout casser
Le refactoring consiste à réorganiser le code existant, fonction par fonction, sans changer son comportement visible pour l'utilisateur. On garde la même application, mais on la rend plus lisible, plus testable, plus facile à faire évoluer. C'est l'option la plus adaptée quand le socle technique est encore valable, mais que le code lui-même est devenu difficile à maintenir.
Le refactoring demande de la rigueur : il faut avancer par petites étapes, vérifier à chaque fois que rien n'a été cassé, et accepter que le gain ne soit pas visible immédiatement pour le client. C'est un investissement qui se rentabilise sur les évolutions suivantes, pas sur l'instant présent. Concrètement, c'est le type d'intervention qu'on mène dans le cadre d'une reprise de projet web : on reprend un existant, on le stabilise, puis on l'améliore sans repartir de zéro.
Réécrire : quand c'est la seule option raisonnable
La réécriture complète devient nécessaire quand le socle technique lui-même est en cause : une techno qui n'est plus supportée, une architecture qui ne tient plus la charge, ou un existant si fragile qu'aucune évolution ne peut y être greffée sans risque de tout casser. C'est l'option la plus coûteuse et la plus longue, elle doit donc être justifiée par un vrai blocage, pas par une préférence technique.
Avant de se lancer dans une réécriture, il faut avoir une vision claire de ce que fait réellement le système actuel : y compris les cas particuliers qui ne sont documentés nulle part mais que les utilisateurs considèrent comme acquis. Une réécriture qui oublie ces détails génère souvent plus de frustration que l'ancien système, même s'il est techniquement meilleur.
Comment trancher entre les trois options
La décision dépend de trois critères, pas d'une intuition :
- Le socle technique est-il encore viable : s'il est obsolète ou non sécurisé, garder ou refactorer ne suffira pas.
- Le code est-il compréhensible et testable : si oui, le refactoring est largement suffisant et bien moins risqué qu'une réécriture.
- Quel est le coût de l'inaction : un système qui freine la croissance ou expose à un risque de sécurité justifie d'investir, même si l'urgence n'est pas visible au quotidien.
Dans la pratique, un audit de site est souvent le point de départ le plus utile : il permet de qualifier objectivement l'état du code et de l'infrastructure avant de choisir entre les trois options, plutôt que de décider à l'instinct ou sous la pression d'un incident.
Ce qu'on observe chez les entreprises qui attendent trop longtemps
Le scénario qui revient le plus souvent : une entreprise reporte la décision année après année, jusqu'à ce qu'un événement extérieur force la main (fin de support d'une techno, départ du seul développeur qui connaissait le système, faille de sécurité constatée). À ce moment-là, le choix se réduit souvent à la réécriture en urgence, dans des conditions bien moins favorables qu'une décision anticipée.
Anticiper ne veut pas dire tout réécrire par précaution. Cela veut dire qualifier régulièrement l'état du système, et traiter le sujet quand il est encore gérable plutôt que quand il devient une crise.
Dans quel cas se faire accompagner
Garder un système sous contrôle, refactorer proprement ou réécrire sans perdre les cas d'usage réels : les trois approches demandent de comprendre un existant qu'on n'a pas écrit soi-même, ce qui est un exercice différent de développer un projet neuf. C'est une bonne partie du travail qu'on fait chez HWS sur les projets de reprise : auditer ce qui existe, identifier ce qui peut être conservé, et proposer la trajectoire la plus raisonnable plutôt que la plus spectaculaire.
Si vous avez un système qui fonctionne mais que plus personne ne maîtrise vraiment, le plus simple est d'en discuter avant que la décision ne soit prise à votre place par un incident. Contactez-nous pour en parler.
