7 idées préconçues sur le code legacy (et pourquoi elles vous coûtent cher)
« Le code legacy, c’est du vieux code qu’il faut jeter. » Si vous pensez ça, vous n’êtes pas seul. Mais vous avez tort. Et cette croyance, comme les six autres que je vais décortiquer dans cet article, est probablement en train de vous faire prendre de mauvaises décisions pour votre application.
En 13 ans de développement PHP, j’ai accompagné des dizaines d’entreprises confrontées à leur code legacy. Et à chaque fois, je retrouve les mêmes mythes, les mêmes raccourcis de pensée, les mêmes erreurs stratégiques. Des idées reçues qui semblent logiques en surface, mais qui, dans les faits, ralentissent les projets, gaspillent les budgets et démotivent les équipes.
Il est temps de remettre les pendules à l’heure.
Idée préconçue n°1 : « Le code legacy, c’est du vieux code »
C’est l’idée reçue la plus répandue. Et la plus dangereuse, parce qu’elle endort la vigilance.
Non, le code legacy n’est pas une question d’âge. C’est une question de maintenabilité. Un code PHP écrit en 2015 avec des tests unitaires solides, une documentation à jour et une architecture propre n’est pas du legacy. En revanche, ce code que votre équipe a écrit il y a 18 mois dans l’urgence d’un sprint, sans tests, sans revue, sans documentation… c’en est déjà.
Michael Feathers, auteur de la référence sur le sujet, le résume en une phrase : le code legacy, c’est du code sans tests. Point.
J’ai audité une application Symfony développée en 2021. Quatre ans, ce n’est rien. Pourtant, elle cumulait tous les symptômes : zéro test, des contrôleurs de 800 lignes, des requêtes SQL en dur dans les vues Twig, et un fichier functions.php de 3 000 lignes que l’équipe appelait affectueusement « le monstre ». Cette application avait 4 ans. Elle était déjà du pur legacy.
Ce qu’il faut retenir : le legacy ne se mesure pas en années, mais en dette technique accumulée. Et cette dette commence à s’accumuler dès le premier commit si les bonnes pratiques ne sont pas en place.
Idée préconçue n°2 : « Il faut tout réécrire pour s’en débarrasser »
Celle-ci, je l’entends à quasiment chaque premier rendez-vous. Le CTO, le directeur technique ou le dirigeant arrive avec cette conviction : « On va tout refaire proprement, from scratch. »
C’est séduisant. C’est même grisant. La page blanche, le code tout neuf, les dernières technos… Sauf que dans la réalité, les réécritures complètes échouent dans la majorité des cas.
Pourquoi ? Parce qu’on sous-estime systématiquement trois choses :
Le temps réel nécessaire. Une réécriture, c’est rarement 6 mois comme prévu. C’est 18 mois minimum, souvent 24 à 36.
Les règles métier invisibles. Votre application legacy contient des années de logique métier accumulée. Des cas particuliers, des exceptions, des patchs qui corrigent des bugs signalés par des clients en 2017. Tout ça vit dans le code, et personne ne s’en souvient. Jusqu’au jour où le nouveau système les oublie, et où les tickets support explosent.
Le coût d’opportunité. Pendant que votre équipe réécrit ce qui existe déjà, elle ne développe pas de nouvelles fonctionnalités. Vos concurrents, eux, avancent.
La bonne approche, c’est la modernisation progressive : on rénove pièce par pièce, sans arrêter l’activité. Le pattern Strangler Fig, les tests de caractérisation, le refactoring ciblé. Des techniques éprouvées qui permettent de transformer du legacy en code moderne, sprint après sprint, sans big bang.
Idée préconçue n°3 : « Le legacy, c’est la faute des développeurs »
Celle-ci fait mal. Et elle est profondément injuste.
Quand un dirigeant découvre l’état de son code, la réaction naturelle est de chercher un coupable. « Qui a écrit ça ? Pourquoi c’est dans cet état ? »
La vérité, c’est que le code legacy est presque toujours le résultat de décisions business, pas de mauvais développeurs :
- « Il faut livrer avant vendredi, on fera les tests plus tard. » Plus tard n’arrive jamais.
- « Le budget ne permet pas de refactoriser maintenant. » Mais le budget pour éteindre les incendies, on le trouve toujours.
- « On recrutera un senior plus tard pour nettoyer. » Le senior arrive, voit l’état du code, et repart 6 mois après.
Le code legacy est un problème organisationnel, pas un problème individuel. C’est le résultat d’une pression constante pour livrer vite, au détriment de la qualité. Sprint après sprint, la dette s’accumule. Et un jour, on se retrouve avec un système que personne ne maîtrise.
Blâmer les développeurs, c’est traiter le symptôme au lieu de la maladie. La vraie question n’est pas « qui a fait ça ? » mais « quel processus a permis que ça arrive, et comment on le corrige ? »
Idée préconçue n°4 : « Si ça marche, on n’y touche pas »
Le mantra préféré des entreprises assises sur une bombe à retardement.
Oui, votre application tourne. Oui, elle rend le service attendu. Mais « ça marche » n’est pas un indicateur de santé technique. C’est comme dire qu’une voiture est en bon état parce qu’elle roule, alors que les freins sont usés, l’huile n’a pas été changée depuis 4 ans, et le contrôle technique est expiré.
Les risques du « on n’y touche pas » sont réels et mesurables :
Risque sécuritaire. Une version PHP non maintenue (PHP 7.4 a atteint sa fin de vie en novembre 2022, PHP 8.0 en novembre 2023), c’est des failles de sécurité connues, publiques, et exploitables. Chaque jour qui passe est un jour où votre application est vulnérable.
Risque de compétences. Plus une technologie vieillit, moins il y a de développeurs capables de la maintenir. Trouver un développeur PHP 5.6 / Symfony 2 en 2025, c’est comme chercher un mécanicien spécialisé en Citroën 2CV : il en existe, mais ils sont rares et chers.
Risque business. Votre marché évolue, vos clients ont de nouvelles attentes, vos concurrents livrent plus vite. Si chaque évolution prend 3 mois au lieu de 3 semaines parce que personne n’ose toucher au code, votre application « qui marche » est en réalité en train de vous faire perdre du terrain.
J’ai vu une entreprise perdre un contrat à 400 000 € parce qu’elle n’a pas pu implémenter une fonctionnalité demandée par son client dans les délais. La raison ? Son application legacy ne permettait pas de la développer rapidement. L’application marchait parfaitement. L’entreprise a quand même perdu.
Idée préconçue n°5 : « Moderniser, c’est forcément long et cher »
C’est vrai si vous choisissez la mauvaise approche (réécriture totale, je vous regarde). Mais avec une modernisation progressive et bien priorisée, les résultats arrivent vite et le ROI est mesurable.
Un audit technique sérieux prend 1 à 2 semaines. À l’issue, vous savez exactement où vous en êtes, ce qui est critique, et par quoi commencer.
Les premiers tests de caractérisation sur vos flux métier vitaux ? 2 à 4 semaines. Et immédiatement, votre équipe peut modifier ces flux avec confiance au lieu de les aborder avec terreur.
La montée de version PHP (de 7.x à 8.x) peut apporter des gains de performance de 30 à 40% sur certaines applications, sans réécrire une seule ligne de code métier. C’est du ROI immédiat : serveurs moins sollicités, temps de réponse réduits, utilisateurs plus satisfaits.
La vraie question n’est pas « est-ce que ça coûte cher ? ». C’est « est-ce que ça coûte plus cher que de ne rien faire ? » Et la réponse est systématiquement non. La dette technique, c’est un crédit à taux variable : plus vous attendez, plus les intérêts augmentent.
Idée préconçue n°6 : « On va embaucher un dev senior, il va régler le problème »
Si seulement c’était aussi simple.
Recruter un développeur senior pour « nettoyer le legacy », c’est comme embaucher un chef étoilé pour sauver un restaurant dont la cuisine est infestée et les fournisseurs douteux. Le talent individuel ne suffit pas si le système autour ne suit pas.
Ce développeur senior, aussi bon soit-il, va se retrouver face à :
- Un code qu’il ne connaît pas et que personne ne peut lui expliquer.
- Aucun test pour valider ses modifications.
- Une pression pour livrer des features en plus de « nettoyer » le code.
- Une frustration croissante qui le mènera, dans la plupart des cas, à chercher un autre poste dans les 6 à 12 mois.
Le turnover sur les projets legacy est 2 à 3 fois plus élevé que sur les projets modernes. Et chaque départ, c’est de la connaissance qui s’évapore, un recrutement à relancer (coût moyen : 6 à 9 mois de salaire), et un nouveau développeur qui recommence à zéro face au même code incompréhensible.
La modernisation du legacy, ce n’est pas un problème de recrutement. C’est un projet structuré qui nécessite une méthode, des outils, et idéalement un accompagnement extérieur qui apporte un regard neuf et une expertise spécifique.
Idée préconçue n°7 : « Le legacy, ça n’arrive qu’aux autres »
La plus sournoise de toutes.
Votre application est récente ? Votre équipe est compétente ? Vous utilisez les dernières technos ? Tant mieux. Mais posez-vous ces questions honnêtement :
- Quelle est votre couverture de tests actuelle ?
- Votre documentation est-elle à jour, ou date-t-elle du lancement du projet ?
- Combien de « TODO » et de « FIXME » traînent dans votre codebase ?
- Un nouveau développeur pourrait-il être opérationnel en moins de 2 semaines sur votre projet ?
Si vous avez hésité sur ne serait-ce qu’une seule de ces réponses, le legacy est déjà en train de s’installer. Pas en fanfare, pas d’un coup. Discrètement, commit après commit, sprint après sprint, raccourci après raccourci.
Le code legacy n’est pas un événement. C’est un processus. Et comme tous les processus silencieux, le moment où on le remarque est rarement le moment où il a commencé.
Changer de regard pour mieux agir
Ces 7 idées préconçues ont un point commun : elles conduisent toutes à l’inaction ou à de mauvaises décisions. Penser que le legacy, c’est juste du vieux code, ça empêche de voir qu’il se forme sous vos yeux. Croire qu’il faut tout réécrire, ça paralyse. Blâmer les développeurs, ça démoralise. Attendre que « ça marche encore », ça laisse la dette exploser.
La réalité, c’est que le code legacy est un problème normal, auquel la plupart des entreprises sont confrontées tôt ou tard. Ce qui fait la différence, ce n’est pas d’éviter le legacy (c’est quasi impossible à 100%), c’est la manière dont on le gère quand il arrive.
Et ça commence par le regarder en face, sans mythes, sans illusions, avec méthode.
Vous avez un doute sur l’état de votre application ?
Depuis plus de 13 ans, j’accompagne des entreprises pour auditer, diagnostiquer et moderniser leurs applications PHP legacy. Pas de discours alarmiste, pas de réécriture inutile : une méthode progressive, pragmatique, qui délivre des résultats mesurables dès les premières semaines.
Le premier pas, c’est souvent une simple conversation pour faire le point.
👉 Prenez un RDV découverte gratuit et voyons ensemble si votre code a besoin d’attention — avant qu’il ne soit trop tard.
Joan Drozo — Développeur PHP expérimenté, spécialiste de la modernisation d’applications legacy. +13 ans d’expérience. Basé à Rennes.
Mon linkedin : https://www.linkedin.com/in/joan-drozo-developpeur-php-rennes/
