On migre un site WooCommerce vers un nouvel hébergeur, on lance la recette, et là : erreurs fatales, page blanche, extensions qui refusent de s’activer. Le coupable, neuf fois sur dix, c’est un décalage entre la version PHP du serveur et ce qu’attendent WordPress et ses plugins. Choisir la bonne version PHP pour WordPress, ce n’est pas cocher une case dans cPanel, c’est arbitrer entre compatibilité, sécurité et performance réelle.
Version PHP minimum et version recommandée : deux notions à ne pas confondre
WordPress 7.0 a relevé la version minimale requise de PHP 7.2.24 à PHP 7.4. Les versions 7.2 et 7.3 ont été purement retirées du support, parce que leur part d’usage combinée était tombée sous les 4 % dans l’écosystème surveillé.
Mais « minimum supporté » ne veut pas dire « recommandé ». WordPress recommande PHP 8.3 ou supérieur depuis 2026. Un site qui tourne encore sur PHP 7.4 démarre, fonctionne, mais n’accède ni aux gains de vitesse d’exécution ni aux correctifs de sécurité actifs.
La confusion entre ces deux seuils pousse beaucoup de gestionnaires de sites à rester sur une version intermédiaire (PHP 8.0, 8.1) en pensant être à jour. En réalité, PHP 8.1 et les versions antérieures ne reçoivent plus aucune mise à jour de sécurité depuis novembre 2025.
Compatibilité des plugins et du thème : le vrai point de blocage
On ne choisit pas sa version PHP dans l’absolu. On la choisit en fonction de ce qui tourne sur le site. Un thème premium pas mis à jour depuis deux ans peut planter sur PHP 8.3 à cause de fonctions dépréciées. Un plugin de facturation peut générer des notices d’erreur qui cassent l’affichage.
Vérifier avant de monter en version
Avant tout changement, on passe en revue trois éléments concrets :
- La fiche de chaque plugin actif dans le répertoire WordPress ou chez l’éditeur : la mention « Tested up to » et la version PHP déclarée compatible donnent un premier filtre
- Le thème actif et le thème enfant éventuel : les fonctions obsolètes comme
create_function()oueach()provoquent des erreurs fatales à partir de PHP 8.0 - Les mu-plugins et les snippets personnalisés ajoutés via functions.php : c’est souvent là que se cachent les incompatibilités, parce que personne ne pense aux auditer
WooCommerce, Elementor et les gros plugins suivent généralement le rythme des versions PHP. Les extensions de niche ou abandonnées posent le vrai problème. Un plugin non mis à jour depuis plus d’un an est un risque d’incompatibilité PHP.
Sécurité du serveur et cycle de vie PHP : ce que l’hébergeur ne signale pas toujours
Chaque version PHP suit un calendrier de support défini. Deux ans de corrections de bugs, puis un an de correctifs de sécurité uniquement, puis plus rien. Quand une version sort du cycle, les failles découvertes restent ouvertes.
PHP 8.2 est encore sous support sécurité, mais celui-ci s’arrête le 31 décembre 2026. Si votre site tourne sur cette version, il faut déjà planifier la migration vers PHP 8.3 ou 8.4.
Le problème concret : beaucoup d’hébergeurs mutualisés laissent la version PHP par défaut sur un réglage ancien. Vérifiez la version active dans votre panneau d’hébergement, pas celle affichée sur la page commerciale. On a vu des comptes configurés sur PHP 8.0 alors que l’offre annonçait PHP 8.3 disponible.
Le cas PHP 8.4 et 8.5
PHP 8.4 est disponible chez certains hébergeurs. WordPress Core est compatible, mais les retours varient sur ce point selon les combinaisons de plugins. Monter sur la toute dernière version PHP dès sa sortie n’est pas forcément le bon réflexe sur un site en production avec des dizaines d’extensions.
La version la plus récente n’est pas toujours la plus stable dans un écosystème WordPress donné. PHP 8.3 reste le meilleur compromis stabilité-performance-sécurité en 2026.
Changer de version PHP WordPress sans casser le site
La procédure technique est simple (un menu déroulant chez la plupart des hébergeurs). Le risque, lui, est réel. Un changement de version PHP mal préparé peut rendre le site inaccessible en quelques secondes.
Méthode concrète pour migrer en sécurité
- Faire une sauvegarde complète (fichiers + base de données) juste avant le changement, pas la veille
- Utiliser un environnement de staging si l’hébergeur le propose : on clone le site, on change la version PHP sur le clone, on teste toutes les pages critiques (accueil, panier, formulaire de contact, espace client)
- Désactiver les plugins un par un sur le staging pour isoler celui qui pose problème, puis chercher une mise à jour ou un remplacement
- Appliquer le changement en production uniquement après validation complète du staging
Sans environnement de staging, on peut activer le mode debug de WordPress (WP_DEBUG) temporairement après le changement pour repérer les erreurs PHP. Mais on travaille alors directement sur le site visible, ce qui n’est pas idéal.
Que faire si un plugin bloque la migration
Si une extension critique n’est pas compatible avec PHP 8.3, on a deux options. Trouver une alternative maintenue activement, ou rester temporairement sur PHP 8.2 le temps que l’éditeur publie une mise à jour. Ne jamais sacrifier la sécurité d’un site pour garder un plugin obsolète au-delà de la fin de support de la version PHP concernée.
Performance PHP et temps de réponse WordPress
Passer de PHP 7.4 à PHP 8.3 ne double pas magiquement la vitesse d’un site. Les gains sont réels sur le temps d’exécution du code serveur, mais ils dépendent du type de pages générées.
Un site avec beaucoup de requêtes PHP dynamiques (WooCommerce, BuddyPress, sites membres) bénéficie davantage d’une montée de version qu’un blog statique avec cache agressif. Sur un site e-commerce, on constate une amélioration perceptible du temps de génération des pages produit et du processus de commande.
Le gain de performance seul ne justifie pas la migration. C’est la combinaison sécurité + compatibilité + performance qui tranche. Mais rester sur une version PHP obsolète dégrade progressivement les trois à la fois.
Le choix de la version PHP pour WordPress se résume à un arbitrage simple : monter aussi haut que vos plugins et votre thème le permettent, sans dépasser ce que l’écosystème du site supporte réellement. En 2026, PHP 8.3 coche toutes les cases pour la grande majorité des installations. Vérifiez votre configuration actuelle, testez sur un staging, et appliquez le changement. Le plus gros risque, c’est de ne rien faire.
