En bref : pour désactiver d'anciennes versions de PHP, le plus sûr est de procéder en trois phases : déterminer l'usage, bloquer la version et observer, ne désinstaller qu'ensuite. Dans Plesk, un handler peut d'abord être désactivé, de sorte qu'il ne puisse plus être choisi, puis supprimé plus tard sous Updates et composants. Chaque version supprimée est une version de moins à corriger et à redémarrer lors de la prochaine faille comme PHP2Shell.
Pourquoi faire le ménage justement maintenant ?
La semaine qui a suivi PHP2Shell a montré à bien des administrateurs combien de versions de PHP étaient installées sur leurs serveurs. Chacune a dû être vérifiée, chacune a demandé une mise à jour ou des mesures transitoires, chaque service un redémarrage. Pour PHP 8.1 et antérieur, il n'existe que des rétroportages minimaux du code source, et pour PHP 8.2, le support prend fin le 31/12/2026.
Avec cette expérience encore fraîche en mémoire, c'est le bon moment pour faire le ménage. La façon de trouver toutes les installations est décrite dans l'article Plusieurs versions de PHP sur un serveur. Il s'agit ici de l'étape suivante : l'arrêt contrôlé.
Phase 1 : déterminer l'usage
Avant de désactiver quoi que ce soit, vous devez savoir qui utilise une version. Les sites web en sont la partie évidente. Moins visibles : les sous-domaines, les installations de test, les tâches cron, les scripts et les composants du panneau.
Dans Plesk, la commande plesk bin php_handler --list énumère tous les handlers enregistrés. Avec --get-usage, Plesk montre, selon la documentation, quels domaines utilisent un handler donné. Aucune des deux commandes ne modifie quoi que ce soit.
# Plesk : tous les handlers et les domaines qui utilisent un handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# En général : tâches cron qui appellent une version précise de PHP
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Vérifiez en outre les journaux d'accès des sites concernés : une installation de test qui n'a pas reçu de requête depuis des mois est candidate à la suppression, non à la migration. Notez pour chaque ancienne version qui l'utilise et pourquoi.
Interrogez aussi les personnes qui travaillent avec les sites. Les rédactions, les agences et les services métiers connaissent souvent des traitements qui ne figurent dans aucune liste : l'exportation annuelle pour la comptabilité, le formulaire d'un salon, l'interface avec le système de gestion commerciale. Ce qui dépend là d'une ancienne version ne se remarque autrement que lorsque cela manque.
Phase 2 : bloquer et observer
L'étape intermédiaire empêche qu'une version soit réattribuée sans la supprimer immédiatement. Plesk permet pour cela de désactiver des handlers individuels. Selon la documentation de Plesk, un handler désactivé ne peut plus être sélectionné dans les paramètres PHP d'un site ; la version reste installée. En ligne de commande, cela se fait avec plesk bin php_handler --disable -id <handler-id>.
Les domaines qui utilisent encore l'ancienne version, vous les basculez au préalable, en accord avec les responsables, vers une version prise en charge. À quoi cela ressemble du point de vue de l'exploitant du site, l'article Changer la version de PHP dans l'espace client de l'hébergeur le décrit. Le choix du bon handler est expliqué dans l'article Plesk : comprendre les handlers PHP.
Pendant la période d'observation, surveillez les messages d'erreur dans les journaux, les résultats de tâches cron qui n'arrivent plus et les retours des utilisateurs. Dans d'autres panneaux, les fonctions portent d'autres noms ; consultez-y la documentation de l'éditeur.
Fixez la fin de la période d'observation comme une date et nommez la personne qui validera ensuite la désinstallation. Sinon, l'étape intermédiaire devient un état permanent, et l'ancienne version reste malgré tout sur le serveur.
Phase 3 : désinstaller
Ce n'est qu'une fois la période d'observation écoulée sans anomalie que vous supprimez entièrement la version. Dans Plesk, selon la documentation, cela se fait sous Tools & Settings, Updates, Add/Remove Components, dans la section Web hosting, aux versions de l'interpréteur PHP. Les versions installées y sont marquées et peuvent être sélectionnées pour suppression.
Sur les serveurs sans panneau, la gestion des paquets se charge de cette tâche. Sauvegardez au préalable la configuration de la version, par exemple /etc/php/7.4/ sous Debian et Ubuntu, afin de pouvoir, en cas d'urgence, retrouver quels réglages s'appliquaient.
# Sauvegarder la configuration, puis supprimer les paquets d'une branche (exemple Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Après la suppression, un contrôle s'impose. Dans Plesk, la documentation recommande plesk bin php_handler --reread pour relire les informations des handlers après des modifications des binaires PHP. Vérifiez en outre si des plans de service renvoient encore à la version supprimée.
Obstacles typiques
| Obstacle | Comment le reconnaître | Ce qui aide |
|---|---|---|
| Un composant du panneau dépend de la version | Le panneau signale une dépendance lors de la suppression | Basculer d'abord le composant ou conserver la version |
| Un plan de service renvoie à l'ancienne version | Les nouveaux sites reçoivent l'ancienne version ou un message d'erreur | Adapter le plan, puis supprimer la version |
| Une tâche cron appelle un chemin fixe | Le script échoue après la suppression | Changer le chemin vers une version prise en charge |
| Une application ne tourne pas sur la nouvelle version | Erreur dans le journal d'erreurs après la bascule | Mettre à jour ou migrer l'application |
Si une application ne peut pas être portée vers une version prise en charge, la désactivation de l'ancienne version n'est plus une question de configuration, mais un projet de migration. Les risques des branches obsolètes sont décrits dans le guide Fin de vie de PHP : risques des versions obsolètes.
Le prochain candidat est déjà connu
Le ménage n'est pas une action ponctuelle. Dès le 31/12/2026, PHP 8.2 sortira du support du projet PHP. Qui supprime maintenant les versions jusqu'à 8.1 devrait fixer dans le même temps ce qu'il adviendra de 8.2. Sinon, le même jeu recommence dans quelques semaines.
Une règle simple a fait ses preuves pour le serveur : on ne propose que des branches prises en charge par le projet PHP. À la mise en place, chaque branche reçoit une date à laquelle elle sera réexaminée, en fonction de la fin du support sur php.net. Le contexte de ce cycle est expliqué sur la page Versions de PHP et cycle de publication.
Qui, comme hébergeur ou agence, a des clients sur le serveur devrait les informer tôt. Une annonce avec une date, la demande de basculer et une offre d'assistance évitent que des sites tombent en panne à la date butoir. Les clients dont l'application ne suit pas voient ainsi à temps qu'une mise à jour ou une migration s'impose, et peuvent la planifier.
Comment PHP SOS aide-t-il concrètement ?
- Nous déterminons quels sites, tâches cron et composants du panneau utilisent quelle version de PHP.
- Nous basculons les domaines, en concertation, vers des versions prises en charge et bloquons les anciens handlers.
- Après la période d'observation, nous supprimons les anciennes versions de façon contrôlée et vérifions le résultat.
- Là où les applications ne suivent pas, nous planifions la migration de PHP 8.1 et antérieur.
Questions fréquentes
Pourquoi supprimer les versions de PHP inutilisées ?
Chaque version installée doit être vérifiée, mise à jour et redémarrée à chaque faille. Les anciennes branches comme PHP 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP. Les versions inutilisées n'apportent que risque et travail.
Quelle est la différence entre désactiver et désinstaller ?
En désactivant, la version reste installée mais ne peut plus être sélectionnée à nouveau. En désinstallant, elle est retirée du serveur. Désactiver est l'étape intermédiaire sûre pour voir si quelque chose manque.
La suppression d'une version de PHP peut-elle perturber des fonctions du panneau ?
Oui. Certains composants d'un panneau, par exemple le webmail ou des outils d'administration, dépendent d'une version précise de PHP. Clarifiez de telles dépendances avant la suppression ; le panneau les signale en règle générale.
Combien de temps la période d'observation doit-elle durer ?
Assez longtemps pour que tous les traitements réguliers se soient exécutés au moins une fois, donc aussi les tâches cron et exportations mensuelles. Fixez la durée avec les services métiers.