PHP 8.4 est aujourd’hui la version recommandée pour faire tourner WordPress en production, et le cœur de WordPress s’y comporte bien : l’immense majorité des problèmes rencontrés lors d’une mise à jour vers PHP 8.4 vient des plugins et des thèmes tiers non maintenus, pas de WordPress lui-même.
Comprendre cette distinction évite de paniquer inutilement, tout en sachant précisément où porter son attention avant de migrer.
Pourquoi une montée de version PHP peut casser un site WordPress
PHP évolue régulièrement, et chaque nouvelle version supprime ou modifie certains comportements jugés obsolètes ou risqués dans les versions précédentes. Avec PHP 8.4, un des changements qui pose le plus de problèmes concerne les propriétés dynamiques : du code qui créait des propriétés à la volée sur un objet, sans les avoir déclarées, peut désormais générer des erreurs qu’il ne générait pas avant.
C’est exactement le genre de pratique qu’on retrouve dans du code de plugin ancien, écrit à une époque où PHP tolérait beaucoup plus de raccourcis.
Ce qui casse vraiment : le tiers, pas le cœur
Dans les retours d’expérience disponibles sur le sujet, un même constat revient : les sites qui rencontrent des erreurs fatales après une mise à jour vers PHP 8.4 sont presque toujours ceux qui utilisent des extensions ou des thèmes n’ayant reçu aucune mise à jour depuis un an ou plus. Le cœur de WordPress, lui, est développé en anticipant ces évolutions de PHP, avec des tests de compatibilité réguliers.
Concrètement, avant une migration vers PHP 8.4, les points à vérifier en priorité sont :
- La date de dernière mise à jour de chaque extension active. Un plugin non mis à jour depuis longtemps est le premier suspect en cas de problème.
- Le thème utilisé, surtout s’il s’agit d’un thème premium téléchargé une fois puis jamais réactualisé.
- Les éventuels développements sur mesure, scripts ou fonctions ajoutés directement au thème, qui n’ont pas forcément été pensés pour les dernières versions de PHP.
La bonne méthode pour migrer sans mauvaise surprise
La règle qui revient systématiquement dans les recommandations sur le sujet est simple : ne jamais monter de version PHP directement en production.
Un environnement de test, ou de staging, permet de vérifier que le site fonctionne correctement avec la nouvelle version avant de basculer le site réel, avec la possibilité de repérer et corriger les erreurs sans que les visiteurs ou les clients en subissent les conséquences.
Mon avis sur la question
Ce que je trouve intéressant dans le cas de PHP 8.4, c’est qu’il illustre bien un principe plus général : la majorité des soucis attribués à « WordPress » viennent en réalité de la façon dont le site a été construit et maintenu au fil du temps, pas du logiciel central.
Cela dit, je reste prudent sur les évaluations trop optimistes du type « compatibilité totale, zéro souci » qu’on peut lire ici ou là : ce sont des observations sur un échantillon de sites à un instant donné, pas une garantie universelle, et les versions de PHP continuent d’évoluer rapidement.
Ma recommandation reste constante, quelle que soit la version de PHP concernée : garder ses extensions à jour, supprimer celles qui ne servent plus, et tester chaque montée de version avant de la déployer en production. C’est une hygiène qui évite la grande majorité des mauvaises surprises, PHP 8.4 ou pas.
Si vous voulez savoir si votre site WordPress est prêt pour PHP 8.4, ou identifier les extensions à risque avant une migration, je peux faire ce point via mon audit, indiquez moi juste son url dans le formulaire ci-dessous.
