Quand faut-il réécrire votre code legacy ?

Un code legacy n’est pas un échec. Découvrez comment l’auditer, le stabiliser et décider, preuves à l’appui, entre refonte ciblée et continuité utile.

Un code legacy ne se reconnaît pas à son âge, à son langage ou à l’absence de tests. Il se reconnaît au coût du changement. Une correction simple mobilise trois personnes. Un déploiement exige une soirée de surveillance. Personne ne sait précisément quel service dépend de quelle base de données. Et chaque nouvelle fonctionnalité commence par la même phrase : « Attention, on ne sait pas ce que cela va casser. »

Pour une PME, le problème n’est pas esthétique. C’est opérationnel. Le système facture, traite des commandes, alimente des équipes internes ou porte un produit SaaS utilisé par des clients. Le remplacer sur un coup de tête revient souvent à mettre l’activité elle-même en danger. À l’inverse, ne rien faire transforme progressivement chaque incident en urgence coûteuse.

La bonne question n’est donc pas « faut-il moderniser ? ». Elle est plus précise : quel risque le système crée-t-il aujourd’hui, et quelle intervention le réduit avec le moins de perturbation possible ?

Pourquoi un code legacy devient un problème métier

Un ancien code peut continuer à rendre un excellent service. Une application PHP vieillissante, un monolithe Ruby ou une base de données SQL conçue il y a dix ans ne constituent pas, par nature, une dette à rembourser immédiatement. Si l’application est comprise, surveillée, déployable et suffisamment stable, son ancienneté peut même être un avantage : elle a survécu à des cas réels que les réécritures oublient souvent.

Le basculement se produit quand la connaissance devient implicite ou inaccessible. Le développeur d’origine est parti. Les décisions d’architecture n’ont pas été documentées. Les accès de production sont partagés dans des boîtes mail. Les sauvegardes existent peut-être, mais personne n’a vérifié qu’une restauration fonctionne. À ce stade, le code n’est qu’une partie du sujet. L’exploitation, les données, les dépendances externes et les procédures de livraison forment le vrai système.

Les symptômes les plus coûteux sont rarement spectaculaires au départ. Cela commence par un délai de livraison qui s’allonge, des erreurs corrigées deux fois, une mise à jour de serveur repoussée, ou une intégration tierce que personne n’ose modifier. Puis arrive l’incident évitable : expiration d’un certificat, saturation du disque, tâche planifiée silencieusement en échec, paiement non réconcilié ou sauvegarde inutilisable.

Pour un dirigeant, la conséquence est simple : la capacité à décider dépend de la capacité du système à changer sans imprévu majeur. Si chaque évolution paraît risquée, l’entreprise finit par contourner son propre outil. Les équipes recréent des fichiers Excel, doublent les saisies ou renoncent à des améliorations rentables.

Réécrire n’est pas automatiquement la réponse

La réécriture complète est séduisante parce qu’elle promet un nouveau départ. Nouveau framework, nouvelle interface, architecture propre, équipe remotivée. Dans la pratique, elle introduit un risque massif : l’ancien système contient des règles métier que personne n’a formalisées. Elles sont dans des conditions obscures, des scripts nocturnes, des exceptions manuelles et des habitudes d’exploitation.

Une réécriture remplace souvent une complexité visible par une complexité inconnue. Pendant des mois, deux systèmes doivent coexister. Les fonctionnalités « secondaires » se révèlent indispensables. Les données historiques résistent à la migration. Le budget est consommé avant que le nouveau produit couvre réellement les opérations quotidiennes.

Cela ne signifie pas qu’il ne faut jamais refaire. Une refonte devient raisonnable lorsque l’architecture bloque durablement les objectifs de l’entreprise, lorsque les composants ne peuvent plus être sécurisés ou exploités correctement, ou lorsque le coût de maintien dépasse clairement celui d’une transition préparée. Mais cette décision doit reposer sur des faits : dépendances, couverture fonctionnelle, qualité des données, contraintes d’exploitation et coût réel des incidents.

Dans la majorité des cas, une stratégie progressive est plus sûre. On stabilise d’abord. On isole ensuite les zones à risque. Puis on remplace les éléments qui apportent le plus de valeur ou qui portent le plus de risque. C’est moins spectaculaire qu’un grand projet de transformation. C’est aussi beaucoup plus compatible avec une activité qui doit continuer à vendre, servir ses clients et clôturer ses comptes.

Auditer un code legacy avant de le toucher

Un audit utile ne commence pas par une liste de recommandations génériques. Il commence par la lecture du code, l’examen des déploiements et une compréhension de ce qui se passe réellement en production. Un diagramme fourni il y a deux ans ne suffit pas. La réalité est dans les logs, les scripts, les variables d’environnement, les tâches planifiées, les permissions, les bases de données et les comptes de services.

La première étape consiste à reconstruire une carte simple du système. Quelles applications sont actives ? Où sont-elles hébergées ? Quels services externes utilisent-elles ? Quelles données sont critiques ? Qui possède les accès ? Comment passe-t-on d’une modification locale à une mise en production ? Cette carte révèle souvent des dépendances absentes de toute documentation.

Ensuite, il faut séparer les risques selon leur nature. Un risque de sécurité ne se traite pas comme une lenteur de requête. Une sauvegarde non testée ne se traite pas comme une dette de framework. Un module impossible à faire évoluer ne mérite pas forcément une intervention immédiate s’il est stable et peu sollicité. La priorisation doit tenir compte de la probabilité, de l’impact métier et de la capacité de récupération après incident.

Un bon livrable d’audit répond à des questions concrètes : ce qui peut casser, ce qui doit être corrigé en premier, ce qui peut attendre, le coût approximatif des options et les décisions qui exigent un arbitrage de direction. Il ne vend pas une réécriture par défaut. Il donne les éléments nécessaires pour éviter une décision prise à l’aveugle.

Stabiliser avant d’ajouter des fonctionnalités

La stabilisation n’est pas une phase abstraite. Elle produit des améliorations visibles dans l’exploitation quotidienne. On commence généralement par rendre les accès maîtrisés, les déploiements répétables et les sauvegardes restaurables. Sans cela, ajouter des fonctionnalités augmente simplement la surface de risque.

La supervision vient ensuite. Il ne s’agit pas de multiplier les tableaux de bord. Il faut détecter les pannes utiles : une application indisponible, un taux d’erreur anormal, une file qui s’accumule, un espace disque critique, une tâche métier qui ne s’exécute plus. Une alerte qui n’appelle aucune action est du bruit. Une alerte qui arrive trop tard est un décor.

Les changements doivent aussi devenir réversibles. Une procédure de déploiement écrite, un mécanisme de retour arrière et des migrations de données prudentes réduisent fortement le coût d’une erreur. Dans certaines organisations, le premier gain n’est pas technique : c’est la fin des déploiements manuels effectués sous pression par une seule personne.

Les tests ont leur place, mais leur mise en œuvre doit rester proportionnée. Couvrir tout un ancien produit avant de livrer quoi que ce soit peut être une impasse. Il est souvent plus pertinent de protéger les flux critiques - authentification, paiement, calcul métier, import ou export - puis d’ajouter des tests au fil des modifications. Le but est de réduire le risque réel, pas de produire un indicateur flatteur.

Moderniser par zones, avec un objectif clair

Une fois le système stabilisé, la modernisation peut devenir sélective. Une API fragile peut être isolée derrière une interface claire. Un traitement asynchrone peut sortir du monolithe. Une base de données lente peut être corrigée par des index, des requêtes revues et une meilleure observabilité avant d’envisager une migration plus lourde.

L’introduction de composants d’IA demande la même discipline. Ajouter un modèle à un processus non fiabilisé ne résout pas le problème de fond. Il faut définir les données accessibles, les limites d’usage, les mécanismes de validation, les coûts et le comportement de repli en cas d’indisponibilité. L’IA peut accélérer une opération ou améliorer une interface. Elle ne remplace ni une architecture comprise ni une exploitation sérieuse.

Chaque chantier doit avoir une finalité mesurable. Réduire les incidents de paiement. Diviser le temps de déploiement. Rendre une intégration modifiable sans intervention d’urgence. Supprimer un serveur non maintenu. Si l’objectif ne peut pas être exprimé simplement, le périmètre mérite probablement d’être rediscuté.

Reprendre le contrôle sans arrêter l’activité

Lorsqu’un projet est abandonné ou qu’une équipe ne parvient plus à avancer, la première responsabilité est de rétablir une lecture honnête de la situation. Ce qui fonctionne doit être préservé. Ce qui est incomplet doit être identifié. Ce qui est dangereux doit être traité sans attendre. Le reste peut faire l’objet d’un plan.

C’est une approche que Rocket Services applique aux environnements existants : lire le code avant d’en écrire, vérifier la production avant de promettre une feuille de route, et livrer des recommandations actionnables plutôt qu’un diagnostic décoratif. Cette méthode demande parfois d’annoncer qu’une fonctionnalité doit attendre. C’est préférable à une promesse qui fragilise encore davantage le système.

Votre code legacy n’a pas besoin d’être admiré. Il doit être compris, exploitable et suffisamment prévisible pour servir les décisions de l’entreprise. Commencez par obtenir cette visibilité. Les choix techniques deviendront alors moins idéologiques et beaucoup plus utiles.