« Ça ? C'est du legacy. » La phrase tombe dans une réunion, sur un thread LinkedIn, dans un appel d'offres, et tout le monde hoche la tête. Personne ne demande ce que le mot veut dire. Dans la bouche de la plupart des gens, « legacy » est devenu un synonyme paresseux de « vieux », et « vieux » un synonyme de « mort ». Les trois ne sont pas la même chose, et confondre les deux derniers fait prendre de très mauvaises décisions techniques.
Je le sais parce que je l'ai fait.
Une techno n'est pas legacy parce qu'elle est vieille
Le vrai critère n'a rien à voir avec l'âge. Une techno est legacy quand elle coche ces cases :
- on n'y démarre plus de nouveaux projets, il n'y a que de la maintenance ;
- le recrutement se fait par pénurie subie, pas par envie ;
- l'outillage et le langage sont figés, les versions qui sortent ne changent rien de fond ;
- la communauté ne grandit plus, elle vieillit avec le code.
Regardez cette liste et appliquez-la honnêtement à Java ou à PHP. Elles cochent l'inverse de chaque case. Ce ne sont pas des technos mortes, ce sont des technos matures, ce qui est presque le contraire. Le piège, c'est qu'à l'œil nu, mature et legacy se ressemblent : dans les deux cas, c'est « ancien ». La différence se voit seulement quand on regarde si ça bouge encore.
Mon erreur : Java
J'avais rangé Java dans la case « fini » quelque part autour des débuts d'Android. Pour moi, c'était le langage des applis lourdes d'entreprise et des cours de fac, un truc qu'on traînait sans plaisir. Verbeux, lent à démarrer, dépassé par Node et Go sur tout ce qui comptait.
Puis je suis allé regarder, vraiment, ce qui était sorti récemment. Java 25, livré en septembre 2025, est une version LTS qui embarque dix-huit JEP. Les virtual threads (finalisés en Java 21) cassent l'argument principal qu'on opposait à Java sur la concurrence : tu écris du code séquentiel lisible et la JVM gère des millions de threads légers sans bloquer les threads système. Ajoute les scoped values, la structured concurrency, des temps de démarrage qui chutent. Personne ne maintient ça par obligation : le langage se réinvente sous le capot tout en gardant sa compatibilité.
Mon avis datait. Pas Java. Et c'est exactement le sujet de cet article : j'avais figé une opinion en 2010 et je ne l'avais jamais rafraîchie.
PHP, le mort-vivant qui refuse de mourir
PHP est enterré au moins une fois tous les deux ans depuis vingt ans. À chaque fois, le PHP que les gens ont en tête est celui de PHP 5 : du code spaghetti, pas de typage, des failles partout. Ce PHP existe encore, dans de vieux projets, et c'est lui qu'on montre du doigt.
Le PHP de 2024 et 2025 n'a presque plus rien à voir. PHP 8.4 (novembre 2024) apporte les property hooks (getters et setters déclarés directement sur la propriété, sans boilerplate), la visibilité asymétrique (lecture publique, écriture privée, en une ligne), une nouvelle API DOM. Avant ça, PHP 8 avait amené le typage strict, les enums, le JIT, les fibers. Le langage comble méthodiquement ses manques historiques, version après version. Laravel et Symfony tirent un écosystème vivant. WordPress fait toujours tourner une énorme part du web, dont ce blog.
Tu peux ne pas aimer PHP. C'est un avis esthétique légitime. Mais « PHP c'est mort » est une affirmation factuelle, et elle est fausse.
Le vrai legacy, vu de l'intérieur : Delphi
J'ai fait du Delphi VCL pendant des années, des applis Windows pour de vrai, en production. Donc je le classe dans le vrai legacy en connaissance de cause, avec le respect de quelqu'un qui l'a pratiqué.
La nuance est importante, parce que Delphi reçoit aussi des mises à jour. RAD Studio 12.3 Athens existe, il supporte iOS 18, Android 15, Windows 11. Sur le papier, ça bouge. Mais regardez leur nature : de la compatibilité d'OS. Le langage lui-même, sous le capot, ne se réinvente pas comme la JVM. Ce sont des MAJ de maintenance pour que l'existant continue de compiler. Rien qui donne envie de démarrer un projet neuf.
Et il y a le code lui-même. Delphi est passé à l'Unicode en 2009. Tout ce qui a été écrit avant est resté en encodage ANSI, et une bonne partie n'a jamais migré, parce que migrer du string ANSI vers UnicodeString sur une grosse base, ça casse des choses partout. Résultat : il tourne en 2026 des applis Delphi coincées en ANSI, qui ne peuvent pas évoluer sans une réécriture que personne ne financera. Ça, c'est le vrai legacy : pas « vieux », mais bloqué. Le code ne peut plus avancer, et personne ne démarre de remplaçant dans la même techno.
C'est la distinction que la phrase « tout le monde y revient » écrase. Java et PHP, on y revient par choix, parce que c'est redevenu un bon outil. Le legacy, on y reste par contrainte, parce qu'on est coincé dedans. Les deux « durent », mais ça n'a rien à voir.
Le contre-exemple qui démolit le critère de l'âge : C
Si l'âge faisait le legacy, le C serait le plus mort de tous. Il a plus de cinquante ans. Et pourtant : le noyau Linux, l'embarqué, les moteurs de bases de données, les runtimes de langages plus récents, tout repose dessus. C++ continue d'évoluer activement (C++20, C++23). On démarre des projets neufs en C tous les jours, par choix technique, parce que rien d'autre ne fait le travail au même endroit.
Le C prouve qu'une techno vieille peut être tout sauf legacy, le meilleur antidote au réflexe « ancien donc fini ». Ce qui compte, c'est l'énergie qu'une communauté investit encore dedans, et il y en a un monde.
La note COBOL : même le cas d'école bouge
COBOL est l'exemple qu'on cite toujours pour « le truc mort qui survit dans les banques par pénurie de devs ». C'était vrai, et ça reste largement vrai : on n'apprend pas COBOL par envie, on l'apprend parce qu'un mainframe paie bien et que plus personne ne sait le lire.
Mais même là, quelque chose bouge, et dans une direction inattendue. IBM pousse watsonx Code Assistant for Z, un outil qui traduit le COBOL en Java avec des modèles d'IA (version 2.6 en juin 2025, des fonctions « agentiques » derrière). L'effet est ambivalent : soit l'IA prolonge la vie de COBOL en le rendant à nouveau lisible et maintenable, soit elle accélère sa sortie en automatisant la migration vers autre chose. Dans les deux cas, le dossier qu'on croyait clos se rouvre. Même pour le cas d'école du legacy, l'avis figé « c'est mort, n'y touche pas » mérite d'être réexaminé.
La vraie leçon : ne garde pas d'avis, fais ta veille
Avoir tort sur une techno à un instant donné, ce n'est rien. Le problème commence quand on fige cette observation en opinion permanente et qu'on décide dessus pendant dix ans sans jamais la revérifier. J'ai fait exactement ça avec Java.
Une techno se lit comme une trajectoire, pas comme une photo. La bonne question n'est jamais « est-ce que c'est vieux », c'est « est-ce que ça bouge encore, et dans quel sens ». Java bouge fort. PHP comble ses trous. C est intemporel. Delphi maintient sans évoluer. COBOL rouvre un dossier qu'on croyait fermé. Aucune de ces réponses ne tient juste parce qu'on l'a entendue une fois.
Avant de coller l'étiquette « legacy » sur quelque chose, va lire les notes de version des deux dernières années. Pas l'avis d'un influenceur, les notes de version. Tu seras surpris de ce qui est encore bien vivant, et de ce qui est mort sans faire de bruit.