Que faire d’un site web sur une version PHP obsolète ou sur Node.js ?

La réponse courte est celle-ci : un site qui tourne sur une version PHP obsolète ou une ancienne version de Node.js a trois voies, adapter le code à une publication prise en charge, reconstruire le site à neuf, ou le garder pour un temps sur une plateforme qui fait encore un rétro-portage des correctifs de sécurité vers l’ancien environnement d’exécution, et préparer pendant ce temps le passage sans précipitation. La quatrième voie, tout laisser en l’état parce que le site fonctionne, n’existe pas, parce que la branche PHP 8.1 et les branches plus anciennes ne reçoivent plus de correctifs du projet PHP, que les lignes de versions 18 et 20 de Node.js non plus, et qu’octobre 2026 a montré, dans les deux cas, ce que cela signifie en pratique.

Un site sur une version PHP obsolète n’est d’ordinaire ni une exception ni une négligence particulière. Il a été développé il y a cinq ou huit ans, la personne qui l’a construit travaille depuis longtemps ailleurs, et le site a rendu service toutes ces années sans incident majeur : il a reçu des demandes, affiché des prix et envoyé des factures. D’après les données de W3Techs, en octobre 2026, 26,8 % des sites qui utilisent PHP tournaient sur PHP 7 et 7,7 % encore sur PHP 5, donc plus d’un tiers d’entre eux utilisent un PHP dont la fin de vie remonte à plusieurs années. La question ne se pose d’habitude qu’au moment où l’hébergeur envoie un avertissement, ou lorsqu’une vulnérabilité arrive dans l’actualité.

Quand une version de PHP ou de Node.js devient ancienne

« Ancienne » n’est pas ici une affaire de goût, parce que PHP comme Node.js publient un calendrier qui indique jusqu’à quelle date chaque branche ou chaque ligne de versions reçoit des correctifs. PHP accorde à chaque branche deux ans de support actif et encore deux ans de correctifs de sécurité uniquement, réservés aux failles critiques, puis la branche n’est plus prise en charge d’aucune façon. Les lignes de versions de Node.js en support à long terme se terminent par une phase de maintenance LTS (Maintenance LTS) et, quand elle s’achève, la ligne ne reçoit plus aucune publication, même si une nouvelle vulnérabilité la concerne directement.

Le tableau rassemble les branches et les lignes de versions que l’on rencontre le plus souvent aujourd’hui, et leur situation en octobre 2026. Les dates viennent de la liste des fins de vie de PHP et du calendrier des publications de Node.js, et les deux sources sont à revérifier par la suite, parce que de nouvelles entrées y apparaissent chaque année.

Deux lignes de ce tableau méritent d’être relues. PHP 8.2 arrivera en fin de vie le 31 décembre 2026, si bien qu’un site qui, à l’automne 2026, semble encore d’actualité se trouvera en janvier 2027 dans la même situation qu’un site sur PHP 7.4, et le passage vaut la peine d’être prévu dès maintenant, tant qu’on peut le faire sans urgence. La ligne de versions 20 de Node.js était encore, à l’automne 2024, une ligne en Active LTS, sur laquelle beaucoup de projets nouveaux ont été commencés, mais le 30 avril 2026 elle est arrivée en fin de vie. Le vieillissement n’est pas progressif : un jour précis, l’environnement d’exécution passe de « reçoit des correctifs » à « ne reçoit plus rien », et rien de visible ne change sur le site à cet instant.

Pourquoi un site qui fonctionne est quand même exposé

Une version en fin de vie ne devient pas dangereuse le jour où cette fin de vie arrive, mais le jour où est publiée une vulnérabilité qui la concerne aussi. Le correctif des branches prises en charge sort avec sa description et, dès qu’il est public, des attaquants peuvent comparer le code corrigé au code non corrigé et comprendre où est la faille. Node.js le dit directement sur sa page sur la fin de vie : si une vulnérabilité concerne aussi une ligne de versions en fin de vie, aucune nouvelle publication ne sortira pour elle, et ceux qui restent sur une telle ligne sont immédiatement exposés aux attaques qui exploitent la vulnérabilité divulguée.

En octobre 2026, c’est exactement ce qui est arrivé aux deux plateformes, presque en même temps. Le 21 octobre, PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques connues sous le nom de PHP2Shell, et seules les branches de 8.2 à 8.5 ont reçu des publications officielles, tandis que, pour les branches 7.4, 8.0 et 8.1, l’équipe de sécurité a préparé à titre exceptionnel de simples correctifs minimaux du code source, pour ceux qui compilent PHP eux-mêmes. Le même jour, Node.js a publié des correctifs pour dix vulnérabilités, et les lignes de versions 18 et 20 n’en ont reçu aucun de la part du projet lui-même. Nous avons décrit les deux cas plus en détail, séparément : dans l’article sur PHP2Shell et dans l’article sur la mise à jour de sécurité de Node.js.

Le second risque est moins visible, mais plus grand sur la durée. Un vieil environnement d’exécution empêche de mettre à jour tout ce qui se trouve au-dessus de lui : les extensions WordPress, les packages Composer et npm, et le framework lui-même cessent peu à peu, dans leurs nouvelles publications, de prendre en charge les anciennes versions de PHP et de Node.js, si bien que le site ne peut pas recevoir leurs correctifs non plus. WordPress recommande lui-même PHP 8.3 ou plus récent et écrit, à propos des branches plus anciennes, que leur fin de vie officielle est atteinte et qu’elles peuvent exposer le site à des vulnérabilités. Le vieil environnement d’exécution n’est alors plus un problème isolé, mais une couche qui empêche de régler tous les autres.

Quand quelque chose arrive, le coût est nettement plus élevé qu’une mise à jour prévue. Un site piraté veut dire un nettoyage, une restauration depuis une sauvegarde, le changement des mots de passe et des clés et, si des données à caractère personnel de clients ont été touchées, aussi une évaluation pour savoir s’il faut notifier une violation de données à caractère personnel à l’autorité de contrôle, le tout dans l’urgence, pendant que le site ne fonctionne pas ou montre aux visiteurs un contenu qui n’est pas le sien. Le passage doit de toute façon être fait dans cette situation, seulement il faut alors le faire après le piratage, et non avant, et sans la possibilité de tout vérifier calmement dans un environnement de test.

Pourquoi on ne peut pas simplement changer une version PHP obsolète dans le panneau d’hébergement

Dans le panneau d’hébergement, le passage à une version de PHP plus récente tient en un clic, et c’est précisément pour cela qu’il est trompeur : si le code n’y est pas prêt, le site s’arrête à la seconde suivante, souvent sur une page blanche ou un message d’erreur. En passant à la publication majeure suivante, PHP retire délibérément des fonctions qui étaient obsolètes depuis de longues années. PHP 7.0 a retiré l’ancienne extension PHP mysql, sur laquelle reposaient beaucoup de sites plus anciens, et PHP 8.0, dans sa liste des changements incompatibles, a retiré entre autres les fonctions each() et create_function(), que l’on rencontre encore dans du code ancien.

Dans le monde Node.js, l’exemple classique est la ligne de versions 17, dans laquelle l’environnement d’exécution est passé à OpenSSL 3.0. Dans l’annonce de la publication, Node.js avertissait qu’une application qui, elle-même ou par ses modules, utilise un algorithme ou une longueur de clé qu’OpenSSL 3.0 n’autorise plus par défaut recevra l’erreur ERR_OSSL_EVP_UNSUPPORTED, et proposait comme solution temporaire le paramètre de lancement --openssl-legacy-provider. L’erreur venait souvent non pas du code du projet lui-même, mais de l’une de ses dépendances, si bien qu’il fallait corriger du code que l’équipe du projet n’avait pas écrit.

Le passage est donc un travail de développement, pas un réglage. Il faut vérifier le code contre le nouvel environnement d’exécution, remplacer les fonctions obsolètes, mettre les dépendances à jour jusqu’à des publications qui le prennent en charge, et tout essayer dans un environnement de test avant que les clients ne le voient. Pour un petit site sur une plateforme maintenue, cela peut être le travail de quelques heures, mais pour un système dont le framework est en fin de vie depuis plusieurs années, le passage signifie souvent aussi le remplacement du framework, et c’est alors un projet avec son budget et son calendrier, pas une tâche que l’on glisse entre d’autres travaux.

Trois voies : mettre à jour, reconstruire ou garder le site protégé

La voie se décide sur deux choses : de combien le code a pris de retard sur une version prise en charge, et combien de temps le site doit encore servir. Si le site doit de toute façon être remplacé par un nouveau dans un an, un grand passage dans l’ancien code n’en vaut pas la peine, mais si c’est l’outil de travail quotidien de l’entreprise, que l’on utilisera encore au moins cinq ans, une solution temporaire ne fait que repousser l’inévitable et le rendre plus cher. Le tableau présente les trois voies qui existent réellement, et ce que chacune règle et ne règle pas.

La mise à jour est le bon choix si le site repose sur une plateforme maintenue, par exemple WordPress ou Laravel, et si une ou deux grandes étapes le séparent d’une branche prise en charge. Le travail est alors prévisible : il faut mettre à jour le framework et les extensions, corriger ce que les outils de vérification trouvent, et basculer PHP. La reconstruction est la voie la plus honnête si le framework lui-même n’est plus pris en charge, si le site est écrit en PHP 5.x sans aucun framework, ou si plus personne ne comprend le code, parce que le coût de la mise à jour se rapproche alors vite de celui d’un site nouveau, alors que le résultat reste du vieux code.

La troisième voie est discutée plus rarement. On peut garder un ancien site sur une plateforme qui fait encore un rétro-portage des correctifs de sécurité vers son environnement d’exécution, qui l’isole des autres sites et qui bloque des schémas d’attaque connus avant même le correctif. Ce n’est pas un substitut au passage, et Node.js lui-même appelle un tel support une solution temporaire, mais c’est une façon honnête de gagner du temps : le passage peut se faire au rythme prévu, et non dans la semaine qui suit le prochain avis de sécurité. Le mot le plus important ici est « échéance », parce que, sans elle, la solution temporaire devient permanente.

Ce qu’est un correctif de sécurité issu d’un rétro-portage, et pourquoi le numéro de version n’en dit rien

Un rétro-portage signifie qu’un correctif de sécurité, développé pour une publication plus récente, est adapté et intégré par quelqu’un dans une publication plus ancienne, que l’utilisateur utilise déjà. Red Hat, qui entretient ainsi les paquetages de ses distributions Linux, écrit que le seul numéro de version ne permet pas au client de savoir si son système est vulnérable, parce que le correctif modifie le paquetage, mais pas le numéro de version. C’est précisément pour cela que les scanners de vulnérabilités qui ne regardent que le numéro signalent à tort, sur ces systèmes, des problèmes déjà corrigés.

Dans le cas de PHP et de Node.js, plusieurs fournisseurs le font. Les distributions Linux rétro-portent les correctifs vers leurs paquetages PHP et Node.js pendant toute la durée où la distribution est prise en charge. CloudLinux rétro-porte les correctifs vers ses paquetages alt-php, que les serveurs d’hébergement sous CloudLinux utilisent, y compris pour des branches dont la fin de vie chez PHP est ancienne : dans le cas de PHP2Shell, sa page de statut a annoncé le 21 octobre qu’elle préparait des paquetages corrigés pour toutes les branches alt-php de 5.2 à 8.5, et ils étaient disponibles au cours de la nuit suivante. Ces paquetages font maintenant partie du support étendu de TuxCare, dont les conditions indiquent, comme objectif pour les vulnérabilités de gravité haute et critique, un correctif dans les 14 jours qui suivent la publication.

Pour les lignes de versions de Node.js en fin de vie, le même service est proposé par des partenaires commerciaux que Node.js nomme lui-même sur sa page sur la fin de vie : HeroDevs, NodeSource et TuxCare. Node.js ajoute tout de suite qu’un tel support est à considérer comme une solution temporaire, et que l’objectif doit toujours être le passage à une version prise en charge. Lors de la publication Node.js d’octobre 2026, CloudLinux a aussi rétro-porté les correctifs vers ses paquetages des lignes 16, 18 et 20, que les clients d’hébergement choisissent dans la section cPanel Setup Node.js App.

On ne peut pas le vérifier d’après le numéro de version. La commande php -v ou node -v montre, après un rétro-portage, exactement la même chose qu’avant, et CloudLinux l’écrit ouvertement dans son annonce Node.js : pour les lignes en fin de vie, le numéro ne change pas après la mise à jour. Ce qui change, c’est le release number du paquetage, que seul l’administrateur du serveur voit, si bien que, sur un hébergement mutualisé, seul l’hébergeur peut donner la réponse.

La limite doit être dite avec la même clarté. Un rétro-portage protège PHP ou Node.js lui-même, mais il ne protège pas une extension WordPress dont l’auteur a cessé les mises à jour, ni du code écrit pour le site et porteur d’une injection SQL, ni un package npm dont les publications les plus récentes ne prennent plus en charge l’ancien Node.js. Les fournisseurs font en outre le rétro-portage ligne par ligne, si bien qu’il faut vérifier, pour chacune, si elle figure dans la liste, et TuxCare se réserve dans ses conditions le droit de proposer une mesure d’atténuation à la place d’un correctif.

Quand ce n’est pas l’environnement d’exécution qui est ancien, mais la plateforme elle-même

Parfois le problème n’est pas dans l’environnement d’exécution, mais dans la plateforme sur laquelle le site est construit, et les correctifs PHP issus d’un rétro-portage n’aident alors qu’en partie. Le meilleur exemple est Drupal 7 : son support de sécurité s’est terminé le 5 janvier 2025, et depuis le projet Drupal lui-même ne publie plus pour lui ni mises à jour de sécurité ni mises à jour de compatibilité. Un site sous Drupal 7 peut tourner sur un PHP entièrement corrigé, mais son cœur, ses modules et son thème restent avec toutes les vulnérabilités qui y seront encore trouvées, parce que plus personne ne les corrige gratuitement.

Ici aussi, une solution temporaire payante existe : la Drupal Association a mis en place un programme de support de sécurité étendu, dans lequel des fournisseurs vérifiés proposent un support payant, par exemple HeroDevs et Tag1 Consulting. C’est le même principe que le rétro-portage des correctifs PHP, une couche plus haut, et avec les mêmes limites : cela repousse le passage, mais ne le règle pas, et chaque année passée sur une ancienne plateforme rend le passage plus cher, parce que la distance jusqu’à la publication actuelle grandit et que le nombre de personnes qui connaissent encore l’ancienne plateforme diminue.

Avant toute décision, il vaut donc la peine de vérifier toutes les couches, et pas seulement PHP : l’environnement d’exécution, la plateforme ou le framework, les extensions ou les modules, et le code écrit pour le site. Si seul PHP est ancien, et que WordPress, Laravel ou une autre plateforme est maintenue, le passage est d’ordinaire un travail prévisible. Si c’est la plateforme elle-même qui est ancienne, la question n’est plus celle de la branche PHP, mais de savoir s’il faut déplacer le site vers la nouvelle publication de la plateforme ou le construire à neuf, et c’est précisément là que le rôle d’un correctif issu d’un rétro-portage est de donner le temps de prendre cette décision sans urgence.

Comment nous gardons d’anciennes versions de PHP et de Node.js sur notre serveur

Notre hébergement infogéré est un emplacement sur notre propre serveur, qui tourne sous CloudLinux, et la version de PHP de chaque site se choisit séparément dans le panneau d’hébergement. On y trouve aujourd’hui PHP de 5.4 à 8.4 et, pour les applications Node.js, aussi bien les lignes de versions 22 et 24, qui sont prises en charge, que les anciennes lignes 16, 18 et 20. Cela veut dire qu’un ancien site peut être déplacé chez nous avec le même PHP ou le même Node.js que celui sur lequel il tourne maintenant, et d’abord être stabilisé, plutôt que de changer en même temps le code le jour du déplacement, ce qui est la façon la plus sûre de ne rien casser pendant le transfert.

Nous avons pu mesurer nous-mêmes comment cela se passe en pratique, en octobre 2026. Les correctifs PHP2Shell sont sortis l’après-midi du 21 octobre, et sur notre serveur toutes les anciennes branches PHP de 5.4 à 8.1 tournent maintenant avec des paquetages que CloudLinux a reconstruits dans la nuit du même jour, moins d’une journée après la publication PHP, et dans lesquels le correctif a été rétro-porté. Les branches de 8.2 à 8.4 sont passées aux publications officielles corrigées 8.2.35, 8.3.36 et 8.4.27, et les lignes de versions 16, 18 et 20 de Node.js ont reçu le 22 octobre des paquetages CloudLinux avec des correctifs rétro-portés, bien que le projet Node.js lui-même n’en ait pas publié pour elles. Pour les anciennes branches, le numéro n’a pas changé, si bien que nous l’avons vérifié non pas d’après le numéro, mais d’après le moment où les fichiers exécutables ont été reconstruits.

Ce n’est pas tout ce que la plateforme fait. CloudLinux place chaque compte d’hébergement dans un environnement isolé distinct, appelé CageFS, dans lequel les utilisateurs ne voient pas les autres utilisateurs du serveur, ni même leurs noms d’utilisateur, ce qui rend plus difficile la propagation d’un piratage d’un compte vers les autres. Le pare-feu applicatif (WAF) d’Imunify360 a commencé, dans le cas de PHP2Shell, à bloquer les schémas d’attaque connus le 21 octobre, plusieurs heures avant la publication du PHP corrigé. Aucune de ces couches ne rend un ancien site invulnérable, mais ensemble elles réduisent le temps pendant lequel une vulnérabilité connue est exploitable, et elles limitent la distance jusqu’où les conséquences d’un piratage peuvent s’étendre.

C’est pourquoi nous recommandons de voir le déplacement d’un ancien site chez nous comme une solution temporaire avec une échéance, et non comme une destination. Nous déplaçons le site avec le même environnement d’exécution, nous vérifions que tout fonctionne comme avant, puis nous convenons avec vous jusqu’à quelle date et dans quel ordre il passera à une version prise en charge, pour que la solution temporaire ne devienne pas permanente. Notre hébergement infogéré commence à 45 € par mois, et les environnements d’exécution maintenus, l’account isolation et le pare-feu font partie de ce que cette somme paie. Si vous avez un site avec une ancienne version de PHP ou de Node.js, envoyez-nous son adresse, et nous vous dirons laquelle des trois voies lui convient et par où commencer.

Comment savoir quelle version de PHP ou de Node.js sert votre site

Le chemin le plus rapide est le panneau d’hébergement. Sur un hébergement cPanel avec CloudLinux, la section Select PHP Version montre la version choisie pour tout le compte, tandis que MultiPHP Manager montre la version de chaque domaine, et si un domaine y a sa propre version, c’est elle qui l’emporte. Pour les applications Node.js, la section Setup Node.js App montre la même chose, chaque application ayant sa propre ligne. Il vaut la peine de regarder chaque site, et pas seulement le principal, parce qu’un même compte réunit souvent plusieurs sites sur des branches PHP différentes, et qu’une copie de test oubliée ou une ancienne page de campagne reste souvent accessible depuis internet.

Sur un site WordPress, on peut aussi le voir dans l’administration : dans Outils → Santé du site, onglet Informations, section Serveur, la version de PHP sur laquelle le site tourne est indiquée. S’il n’y a pas de panneau, on peut créer un fichier avec la fonction phpinfo() et l’ouvrir dans le navigateur, mais le fichier doit ensuite être supprimé, parce qu’il montre la configuration du serveur à n’importe quel visiteur. La commande php -v aide ici moins qu’il n’y paraît, parce qu’elle montre le PHP de la ligne de commande, alors que les requêtes web sont souvent servies par une autre branche, choisie dans le panneau d’hébergement. Dans un projet Node.js, la ligne souhaitée est souvent indiquée par le champ engines de package.json ou par le fichier .nvmrc, mais ce n’est qu’un souhait, et le Node.js qui fait réellement tourner l’application se voit là où le processus est lancé.

S’il n’y a aucun accès, la question doit être posée à l’hébergeur ou à la personne qui maintient le site. La formulation qui épargne une correspondance : « Quelle version de PHP ou de Node.js sert notre site ? Si elle est en fin de vie, reçoit-elle des correctifs de sécurité issus d’un rétro-portage, d’où viennent-ils, et quand le paquetage a-t-il été mis à jour pour la dernière fois ? Jusqu’à quelle date recommandez-vous le passage ? » La réponse à la dernière question en dit aussi long sur le fournisseur lui-même, parce que, s’il n’y a pas de date, il n’y a d’ordinaire pas de plan non plus.

Passer à une version prise en charge : comment le faire sans surprise

Le passage commence par un inventaire, pas par un basculement. Il faut noter quelle branche PHP et quelles extensions PHP le site exige, quelles tâches planifiées le font tourner en arrière-plan, avec quels systèmes extérieurs il communique, et quelles parties sont critiques pour l’activité, par exemple le formulaire de commande, les paiements ou l’envoi des factures. La version cible vaut la peine d’être choisie avec de la marge : PHP 8.4 recevra des correctifs de sécurité jusqu’au 31 décembre 2028, PHP 8.3 jusqu’à la fin de 2027, tandis qu’un passage à PHP 8.2, dont la prise en charge se termine déjà fin 2026, signifierait un autre passage très bientôt. Pour Node.js, la cible est dans la plupart des cas la ligne de versions 24.

La deuxième étape est la vérification du code, et pour le code PHP on peut l’automatiser en grande partie. PHPCompatibility est un jeu de règles PHP_CodeSniffer qui vérifie si le code est compatible avec une version précise de PHP, et Rector peut effectuer automatiquement une partie des changements nécessaires. Aucun des deux ne remplace une vérification humaine, mais ils montrent vite si le volume de travail se mesure en heures ou en semaines, et c’est exactement ce qu’il faut pour choisir entre la mise à jour et la reconstruction. Pour un site WordPress, il faut d’abord mettre à jour les extensions et le thème, et seulement ensuite basculer PHP.

La troisième étape est un environnement de test, c’est-à-dire une copie du site avec le nouveau PHP ou le nouveau Node.js, dans laquelle on essaie toutes les actions critiques : formulaires, paiements, envoi d’e-mails, import et export. Le journal des erreurs, à ce stade, compte plus que le contrôle visuel, parce que les avertissements sur les fonctions obsolètes y apparaissent longtemps avant que quelque chose ne s’arrête. La quatrième étape est le basculement pendant une période de faible charge, avec la possibilité de revenir en arrière : sur un hébergement où l’on choisit la version, le retour est le même clic que celui du basculement, si bien que le risque est faible pourvu que la sauvegarde soit récente et que quelqu’un suive le journal des erreurs pendant la première semaine.

Pour une application Node.js, la logique est la même, seuls les outils changent. Le passage d’une grande ligne de versions à la suivante vaut la peine d’être fait une ligne à la fois, en lançant les tests de l’application après chacune, et une attention particulière doit aller aux packages au code compilé, parce qu’ils sont construits pour une ligne de versions précise de Node.js et qu’il faut les reconstruire après le passage. Il faut d’abord mettre à jour les dépendances qui ne prennent pas encore en charge la nouvelle ligne, et seulement ensuite changer l’environnement d’exécution lui-même, sinon les erreurs des deux côtés se mélangent et il est difficile de comprendre laquelle a causé quoi.