Legacy dans le développement d’applications — définition, risques et stratégies

Qu’est-ce que le legacy dans le développement d’applications

Legacy — code ou système qui continue de fonctionner en production mais ne répond plus aux normes de qualité modernes. Le legacy peut être écrit dans un langage obsolète (par exemple, Objective-C au lieu de Swift), utiliser des bibliothèques non supportées ou des motifs d’architecture considérés comme des antipatterns.

La caractéristique principale du legacy est l’absence de tests. Selon la définition de Michael Feathers (2004), le code legacy est du code sans tests. Si on ne peut pas modifier le comportement en toute sécurité, le système est en statut legacy quel que soit son âge. Du code frais sans tests unitaires est legacy dès le premier jour.

Le legacy n’est pas nécessairement mauvais. Un système bien conçu en Java 8 peut être plus fiable et compréhensible qu’un code chaotique en Kotlin avec des coroutines. L’âge du code n’est pas un indicateur de qualité — ce qui compte, c’est la facilité avec laquelle le système peut être modifié et étendu.

Pourquoi le code legacy est normal

Tout système réussi devient un legacy avec le temps. C’est un processus naturel : les technologies évoluent plus vite que le code ne peut être réécrit. Une application écrite il y a 5 ans en Swift 2 est legacy aujourd’hui, même si elle était moderne à sa création.

La valeur métier du legacy est souvent sous-estimée. Le système fonctionne de manière fiable, traite des transactions, stocke des données — la réécriture comporte des risques. Selon le Standish Group (2024), 35% des projets de réécriture complète se soldent par un échec. Économiquement, il n’est pas justifié de se débarrasser du legacy, mais d’apprendre à travailler avec.

Les meilleures stratégies sont la migration progressive, l’encapsulation de l’ancien code derrière de nouvelles interfaces et les tests automatisés. Le legacy ne devient un problème que lorsqu’il cesse d’être modifiable à un coût prévisible.

Principaux signes d’un système legacy

Absence de tests automatisés — l’indicateur principal. Si après avoir modifié une seule ligne un développeur ne peut pas exécuter de tests et confirmer que rien n’est cassé — vous avez affaire à du legacy. Un signe supplémentaire : le processus de déploiement prend des heures et nécessite des étapes manuelles.

La documentation ne correspond pas au code — un autre marqueur. Les diagrammes d’architecture sont obsolètes, les commentaires décrivent un comportement qui a déjà changé. Le temps d’adaptation pour un nouveau développeur dépasse un mois — signe d’une complexité élevée et d’une faible maintenabilité.

Signes supplémentaires : architecture monolithique sans limites claires, tests manuels comme méthode de vérification principale, pipeline CI long (plus de 30 minutes), utilisation de bibliothèques sans versions à jour et incapacité à mettre à jour les dépendances sans casser les modules connexes.

Le phénomène du code fragile — une modification à un endroit en casse trois autres. C’est une conséquence du couplage fort, lorsque les modules en savent trop les uns sur les autres. Plus le couplage est élevé, plus le système passe rapidement dans la catégorie legacy.

Risques du travail avec du code obsolète

Ralentissement — le risque principal. Ajouter une fonctionnalité simple nécessite des heures d’étude du code et des jours de test. Selon Stripe (2024), les développeurs consacrent 33% de leur temps à surmonter la dette technique, directement liée à la présence de modules legacy dans le projet.

Fuite d’expertise — les auteurs du code original quittent l’entreprise et la documentation est incomplète. Les nouveaux développeurs craignent de toucher aux modules inconnus, ce qui conduit à l’effet de code gelé : le module n’évolue pas mais continue de fonctionner. Le bus factor de ces systèmes est critique.

Sécurité — les bibliothèques obsolètes contiennent des vulnérabilités connues. Utiliser OpenSSL 1.0.2 ou des versions anciennes de Jackson dans des projets Java est un chemin direct vers des incidents de sécurité qui peuvent coûter réputation et clients à l’entreprise.

Démotivation de l’équipe — travailler avec du legacy sans stratégie d’amélioration réduit la satisfaction des développeurs. L’équipe cesse d’être fière du produit, le turnover augmente, ce qui ralentit encore plus le développement du système.

Stratégies de refactoring legacy

Tests de caractérisation — la première étape avant toute modification de code legacy. Exécutez le code avec des données d’entrée connues et enregistrez la sortie attendue. Ces tests capturent le comportement actuel comme spécification. Golden master testing est une variante où la sortie est comparée à un fichier de référence.

Analyse des seams — trouver les points où le couplage peut être rompu sans modifier le comportement. Michael Feathers identifie plusieurs types de seams : preprocessor seam, object seam, link seam. Object seam est le plus courant : remplacer un objet réel par un stub de test via une interface.

Sprout method et Sprout class — techniques pour ajouter du nouveau code à côté de l’ancien, pas à l’intérieur. Au lieu de modifier une méthode existante, créez une nouvelle méthode avec la logique souhaitée et appelez-la depuis l’ancienne. Cela minimise le risque de casser le code fonctionnel.

Exemple : ajouter du logging au legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 lignes de code legacy qui ne doivent pas être touchées
        logPayment(payment) // méthode sprout
    }
    def logPayment(payment) {
        // nouveau code ajouté à côté du legacy
    }
}

Migration vers une stack technologique moderne

Motif Strangler Fig — l’approche recommandée pour la migration legacy. Un nouveau module est créé en parallèle, le trafic est progressivement redirigé de l’ancien vers le nouveau. L’ancien module meurt naturellement lorsqu’il cesse de recevoir des requêtes. Le motif minimise les risques et permet un rollback en cas de problème.

Branch by Abstraction — technique où une abstraction est créée au-dessus de l’ancienne et de la nouvelle implémentation. Le code client bascule vers l’abstraction et l’ancienne implémentation est progressivement remplacée. Exemple : remplacer la couche réseau d’AFNetworking par Alamofire via un protocole unifié NetworkService.

Migration par étapes — diviser la transition en petites étapes : encapsuler l’ancien module → écrire des tests → créer un nouveau module → exécuter en parallèle → supprimer l’ancien module. Chaque étape se termine par un état stable du système, permettant un déploiement à tout moment.