PHP 7.4, sorti fin 2019, reste encore aujourd’hui la version la plus utilisée sur une bonne partie de notre parc de clients hébergés, souvent parce qu’elle avait fini par se stabiliser sans incident après la mise à niveau depuis PHP 7.2 ou 7.3. Mais son cycle de support officiel touche à sa fin le 28 novembre 2022 : au-delà de cette date, plus aucun correctif de sécurité ne sera publié pour cette version, même en cas de faille critique découverte dans l’interpréteur lui-même.
Faire tourner un site en production sur une version de PHP non maintenue n’est pas seulement une question de conformité théorique : c’est un risque de sécurité réel et grandissant, puisque toute vulnérabilité découverte après cette date restera ouverte indéfiniment. Voici la démarche que nous suivons pour migrer un parc de sites sans provoquer d’incident au passage.
Étape 1 : cartographier le parc existant
Avant toute action, il faut savoir précisément quels sites tournent encore sur quelle version. Sur un serveur qui héberge plusieurs clients, WP-CLI permet de vérifier rapidement, site par site, la version PHP effectivement utilisée :
wp eval 'echo PHP_VERSION;' --path=/var/www/site-client
Sur un parc plus large, un script bash simple qui boucle sur chaque dossier de site et exécute cette commande donne en quelques minutes une vue complète, bien plus fiable qu’une supposition basée sur la date de création du site.
Étape 2 : auditer la compatibilité des extensions
La majorité des extensions maintenues activement fonctionnent sans problème sur des versions récentes de PHP, mais certains plugins abandonnés ou des extensions métier développées sur mesure peuvent utiliser des fonctions dépréciées, voire supprimées, entre PHP 7.4 et PHP 8. L’outil PHP Compatibility Checker, ou une simple activation de WP_DEBUG en environnement de test, permet de repérer les avertissements avant qu’ils ne deviennent des erreurs fatales en production.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Cette configuration journalise les erreurs et avertissements dans un fichier dédié sans les afficher aux visiteurs, ce qui permet un audit silencieux sur un environnement de préproduction avant la moindre migration en production.
Étape 3 : tester sur un environnement isolé
Grâce à la cohabitation de plusieurs versions de PHP-FPM sur un même serveur, il est possible de créer un pool temporaire sur la nouvelle version pour un site donné, accessible via un sous-domaine de test, sans toucher au pool de production. Cette étape permet de valider concrètement le comportement du site avant toute bascule définitive.
- Vérifier l’affichage de toutes les pages principales du site.
- Tester le tunnel de commande complet sur un site e-commerce, jusqu’au paiement en mode test.
- Vérifier les formulaires de contact et les notifications par e-mail associées.
Étape 4 : planifier la bascule
La bascule elle-même, une fois validée en préproduction, ne devrait consister qu’à changer une ligne dans le bloc serveur nginx du site (la directive fastcgi_pass vers le nouveau socket), ou dans le fichier .htaccess sous Apache. Prévoir la bascule en dehors des heures de forte affluence, et conserver l’ancien pool actif quelques jours en cas de retour arrière nécessaire, limite le risque en cas d’imprévu non détecté en test.
Communiquer avec le client
Prévenir un client d’une migration technique invisible peut sembler inutile, mais c’est ce qui évite qu’il attribue à tort un incident sans rapport à « la mise à jour que le prestataire a faite la semaine dernière ». La transparence protège la relation autant que le serveur.
En résumé
La fin de vie de PHP 7.4 n’est pas une urgence à traiter dans la panique, mais un rendez-vous à anticiper méthodiquement : cartographie du parc, audit de compatibilité, test en environnement isolé, puis bascule planifiée. Suivie dans cet ordre, la migration se fait sans incident visible pour les visiteurs des sites concernés, et referme une fenêtre de sécurité qui resterait sinon ouverte indéfiniment.
