PHP 8.2 arrive en fin de support complet le 31 décembre 2026. Pour tout site WordPress en production, ce délai impose de trancher maintenant sur la version PHP cible, pas dans six mois. Le choix de la version PHP WordPress conditionne à la fois la sécurité, la vitesse de chargement et la compatibilité avec les extensions installées.
Horizon de support PHP : le critère que la plupart des migrations ignorent
Choisir une version PHP « compatible » avec WordPress ne suffit pas. La compatibilité technique est un minimum. Ce qui détermine la pertinence d’un choix, c’est la durée pendant laquelle cette version recevra encore des correctifs de sécurité.
PHP 8.2 a terminé son support actif (corrections de bugs) au 31 décembre 2024. Depuis, seuls les correctifs de sécurité sont publiés, et cette couverture s’arrête au 31 décembre 2026. Migrer vers PHP 8.2 aujourd’hui revient à choisir une branche dont l’espérance de vie se compte en mois.
PHP 8.3 conserve un support de sécurité jusqu’à fin 2027. PHP 8.4 jusqu’à fin 2028. PHP 8.5, sorti le 20 novembre 2025, bénéficie d’un support sécurité étendu jusqu’en 2029. Pour un site WordPress professionnel qui doit rester stable sur deux à trois ans sans intervention majeure, la version cible logique se situe entre PHP 8.3 et PHP 8.5.
WordPress 7.0 et PHP : ce que le relèvement du minimum implique
WordPress 7.0, sorti le 20 mai 2026, a officiellement relevé la version PHP minimale à 7.4. Les versions PHP 7.2 et 7.3 ne sont plus supportées par le CMS. Cette décision, annoncée le 9 janvier 2026 par l’équipe WordPress Core, signifie qu’une mise à jour automatique vers WordPress 7.0 sur un serveur en PHP 7.2 ou 7.3 peut provoquer des erreurs critiques.
Le minimum requis à 7.4 ne signifie pas que PHP 7.4 soit un choix viable. PHP 7.4 ne reçoit plus aucun correctif depuis longtemps. WordPress 6.9 est officiellement compatible avec PHP 8.5, et WordPress 7.0 poursuit cette trajectoire. Le minimum affiché par WordPress est un filet de sécurité, pas une recommandation.
L’écart entre minimum requis et version adaptée
Un site WordPress qui tourne en PHP 7.4 fonctionne, mais accumule des dépréciations silencieuses. Les notices d’erreur PHP se multiplient dans les logs serveur. Certains plugins cessent de tester leurs mises à jour sur des branches aussi anciennes. Le risque n’est pas l’arrêt brutal du site, mais une dégradation progressive : lenteur accrue, failles non corrigées, incompatibilités avec les extensions majeures.
Performances serveur et version PHP WordPress : mesurer avant de comparer
Les articles qui annoncent des gains de vitesse spectaculaires après une montée de version PHP posent rarement le cadre de mesure. Un benchmark réalisé sur un WordPress nu (thème par défaut, aucune extension) ne reflète pas le comportement d’un site en production avec WooCommerce, un page builder et une dizaine de plugins actifs.
Les gains réels dépendent de trois facteurs :
- La configuration OPcache du serveur, qui met en cache le bytecode PHP compilé. Sans OPcache activé et correctement dimensionné, le passage à PHP 8.x ne produit qu’une fraction du gain attendu.
- Le JIT (Just-In-Time compiler), disponible depuis PHP 8.0, apporte des améliorations mesurables sur les traitements intensifs en calcul, mais WordPress sollicite peu le JIT en conditions réelles car l’essentiel du temps serveur passe en requêtes SQL et appels réseau.
- La qualité du code des extensions installées. Un plugin mal optimisé qui effectue des requêtes SQL redondantes annule le bénéfice d’une version PHP plus rapide.
Un retour terrain documenté mentionne une réduction du temps de réponse serveur d’environ un quart après migration de PHP 8.0 vers PHP 8.1 sur un hébergement O2switch. Les retours terrain divergent sur ce point selon la stack utilisée, et ces résultats ne sont pas généralisables sans mesurer le TTFB (Time To First Byte) avant et après migration sur votre propre configuration.
Compatibilité des plugins WordPress avec PHP 8.3, 8.4 et 8.5
La compatibilité du coeur WordPress avec une version PHP ne garantit pas celle de l’écosystème. Un site WordPress moyen utilise entre cinq et vingt extensions. Chacune doit être testée individuellement.
Les extensions majeures (WooCommerce, Yoast SEO, Elementor) suivent généralement les nouvelles branches PHP dans les semaines qui suivent leur sortie. Les extensions moins maintenues, notamment celles qui n’ont pas été mises à jour depuis plus d’un an, posent le vrai problème. Une fonction PHP dépréciée en 8.3 peut devenir une erreur fatale en 8.5.
Méthode de vérification avant migration
Avant de modifier la version PHP sur votre serveur, une séquence de contrôle s’impose :
- Vérifier la date de dernière mise à jour de chaque plugin actif. Un plugin non mis à jour depuis plus de douze mois est un candidat à l’incompatibilité.
- Utiliser l’outil « Santé du site » intégré à WordPress (Tableau de bord, puis Santé du site, puis Infos) pour identifier la version PHP actuelle et les avertissements liés.
- Réaliser la migration sur un environnement de staging (copie du site) avant toute modification en production. Tester les formulaires, le panier WooCommerce si applicable, et les pages critiques.
- Consulter les changelogs des plugins pour repérer les mentions explicites de compatibilité PHP 8.3, 8.4 ou 8.5.
Cette étape prend entre trente minutes et deux heures selon la complexité du site. Elle évite les pannes en production qui coûtent bien plus cher en temps et en visibilité.
Quelle version PHP choisir pour WordPress selon votre situation en 2026
PHP 8.3 représente le standard de stabilité pour les sites WordPress professionnels en 2026. Son écosystème d’extensions est largement testé, son support sécurité court jusqu’à fin 2027, et la quasi-totalité des hébergeurs mutualisés le proposent.
PHP 8.4 convient aux sites dont les extensions sont toutes à jour et dont l’équipe technique peut intervenir rapidement en cas de régression. PHP 8.5 est le choix logique pour les nouveaux projets WordPress lancés en 2026, grâce à son horizon de support le plus long.
Pour un site existant avec des extensions anciennes ou un thème personnalisé non maintenu, rester en PHP 8.3 le temps d’auditer la compatibilité est plus prudent qu’un saut direct vers PHP 8.5. La version PHP de votre site WordPress n’est pas un concours de modernité : c’est un arbitrage entre sécurité, performance et stabilité de l’ensemble de la stack.
