Deprecated: Implicitly marking parameter as nullable is deprecated. Ce message, la plupart des équipes WordPress l’ont déjà vu défiler dans leurs journaux d’erreurs sous PHP 8.4, sorti fin novembre 2024. Il ne casse rien dans l’immédiat, mais il annonce ce que la version suivante transformera probablement en erreur fatale. Sur un parc mutualisé, ce genre de signal arrive rarement seul, et il révèle surtout un problème plus large : la capacité réelle de l’hébergement à suivre le rythme des versions PHP.
Un mois après la sortie de PHP 8.4, nous avons tenté la bascule sur une quarantaine de sites hébergés en mutualisé chez trois prestataires différents. Six sites ont refusé de fonctionner correctement. Ce texte détaille ce qui bloque, dans quel ordre ces blocages apparaissent, et pourquoi la montée de version PHP sur un mutualisé n’a rien d’un simple changement de case dans un panneau d’administration.
Premier blocage : la version proposée dépend entièrement du panneau d’hébergement
Sur les trois hébergeurs testés, un seul proposait PHP 8.4 en sélection directe dans le panneau de contrôle au moment de nos essais ; les deux autres plafonnaient encore à PHP 8.2 ou 8.3, plusieurs semaines après la sortie officielle. Ce délai n’est pas anodin pour un mutualisé : il dépend de la manière dont l’hébergeur compile ou installe ses modules PHP-FPM, et de sa politique de support des versions plus anciennes pour ne pas casser les sites de clients qui n’ont jamais mis à jour leurs extensions.
Concrètement, avant même de parler de compatibilité applicative, la première question à se poser est administrative : la version est-elle seulement disponible sur l’offre souscrite ? Certains hébergeurs réservent les versions récentes aux offres supérieures, ce qui ajoute une contrainte commerciale à la contrainte technique.
Deuxième blocage : les extensions qui appellent des fonctions dépréciées
Sur les six sites en échec, le point commun n’était pas WordPress lui-même — le cœur gère PHP 8.4 sans difficulté majeure depuis la version 6.6 — mais des extensions tierces peu maintenues. Les erreurs les plus fréquentes rencontrées sur ce parc :
- Appels à
each(), supprimée depuis PHP 8.0 mais encore référencée dans du code copié-collé ancien - Utilisation de propriétés dynamiques non déclarées sur des objets, désormais dépréciée avec un avertissement explicite
- Extensions de galerie photo abandonnées depuis plus de trois ans, sans aucune mise à jour de compatibilité
- Plugins de formulaire personnalisés développés en interne par d’anciens prestataires, jamais retestés depuis leur livraison
Aucune de ces erreurs n’est spécifique à PHP 8.4 : elles s’accumulent depuis plusieurs versions majeures et deviennent simplement visibles au moment où la tolérance de l’interpréteur diminue. PHP 8.4 ne casse pas ces sites brutalement, il révèle une dette accumulée depuis PHP 8.0, voire avant.
Troisième blocage : les thèmes maison jamais retouchés depuis leur livraison
Les thèmes développés sur mesure posent un problème différent des extensions : personne n’est responsable de leur maintenance dans la durée, sauf accord explicite avec le client. Sur ce parc, deux thèmes personnalisés livrés en 2019 utilisaient encore des fonctions de manipulation de tableaux avec des signatures désormais incompatibles, et un troisième reposait sur une bibliothèque de templating tierce elle-même jamais mise à jour.
La bascule vers une nouvelle version de PHP est donc aussi, indirectement, un audit du statut contractuel de maintenance de chaque site. Un site sans contrat de maintenance actif est un site qui restera bloqué sur une version PHP ancienne jusqu’à ce qu’un incident force la main.
Ce qui a permis de tester sans casser la production
Pour éviter de découvrir ces incompatibilités directement en production, nous avons systématisé un clonage complet du site vers un environnement de staging où seule la version PHP diffère. La commande wp cli info couplée à php -v permet de vérifier rapidement l’environnement réel avant tout changement, et un passage en mode débogage avec WP_DEBUG activé fait remonter la quasi-totalité des dépréciations en quelques minutes de navigation.
Une checklist courte mais efficace
- Vérifier la disponibilité de la version cible dans le panneau d’hébergement avant tout autre test
- Cloner le site en staging et activer
WP_DEBUGetWP_DEBUG_LOG - Parcourir les pages critiques : accueil, panier, formulaire de contact, back-office
- Identifier les extensions sans mise à jour depuis plus de dix-huit mois
En résumé
PHP 8.4 en lui-même n’est pas le problème sur un hébergement mutualisé : le vrai frein est la disponibilité inégale de la version chez les hébergeurs et la dette technique accumulée par des extensions et des thèmes jamais retestés. Sur ce parc de quarante sites, six blocages pour un mois de recul reste un score correct, à condition de traiter ces six cas individuellement plutôt que de reporter la montée de version pour tout le monde.
