Une version en fin de vie ne prévient pas. Un site sur une version morte continue de s’afficher normalement, parfois pendant des années. Rien ne change à l’écran, et c’est bien le problème : les failles découvertes après la fin du support ne sont plus corrigées, jamais. Le parc réel est éloquent : PHP 5 équipe encore 7,9 % des sites en PHP et PHP 7 près de 28,8 % (W3Techs, août 2026), alors que la branche 5.6 est éteinte depuis le 31 décembre 2018 et la 8.1 depuis le 31 décembre 2025.
L’hébergeur peut trancher à votre place. Les hébergeurs finissent par couper les versions obsolètes, ce qui est légitime de leur point de vue : ils protègent l’ensemble de leurs serveurs. Nous l’avons vu se produire, et nous l’avions déjà raconté ici : le scénario est toujours le même : un site qui fonctionnait la veille tombe en erreur du jour au lendemain, sans que rien n’ait été modifié dessus. La décision ne vous appartient pas, seule l’anticipation vous appartient.
Le maintien d’une ancienne version est un pont, pas une destination. Nous savons faire tourner et sécuriser des sites restés sur d’anciennes versions, jusqu’à PHP 5.6, là où d’autres se contenteraient de couper. Cette capacité rend un vrai service quand une refonte ne peut pas se faire du jour au lendemain. Mais nous la présentons pour ce qu’elle est : un sursis maîtrisé, isolé et surveillé, qui donne le temps d’organiser la suite. Ce n’est jamais une situation dans laquelle nous conseillons de s’installer durablement.
Confondre le langage et la qualité du site. « PHP, c’est dépassé, il faut tout refaire » est une phrase que nous entendons régulièrement, et elle mène à des refontes coûteuses qui ne règlent rien. Un site lent, difficile à administrer ou vulnérable l’est à cause de sa conception, de son état de sécurité ou de son absence d’entretien, pas à cause du langage qui le fait tourner. Changer de technologie sans avoir identifié le vrai problème revient à déménager pour ne pas ranger.