Quelle version de PHP pour WordPress en 2026, et comment changer sans casser le site

Le 21 octobre, la faille PHP2Shell a rappelé que la version de PHP d’un site n’est pas un réglage qu’on oublie : notre article sur PHP2Shell dit quelles branches ont été réparées et comment le vérifier. Celui-ci répond à la question suivante, celle qui reste valable après l’urgence : sur quelle version de PHP faire tourner un WordPress, et comment y passer sans casser le site.

L’essentiel en cinq points

• Le cœur de WordPress n’est pas le frein : il accepte tout PHP de 7.4 à 8.5.
• PHP 8.2 cesse de recevoir des correctifs le 31 décembre 2026. PHP 8.1 n’en reçoit plus depuis fin 2025. Au 3 novembre, plus d’un site WordPress sur deux, parmi ceux qui transmettent leur version, tourne sur l’une de ces branches ou sur une plus ancienne.
• Visez PHP 8.4 aujourd’hui, ou 8.5 si vos extensions l’annoncent. Laissez PHP 8.6 mûrir quelques semaines après sa sortie, prévue le 19 novembre.
• Ce qui casse, ce sont les thèmes et les extensions, surtout ceux que plus personne ne maintient. On le découvre sur une copie, dans le journal d’erreurs, pas sur le site en ligne.
• Le gain de vitesse se mesure, il ne se promet pas. Les essais publiés sur un WordPress nu donnent quelques pour cent ; votre site dira le sien.

Ce que WordPress accepte, et ce qu’il recommande

Deux pages de WordPress.org répondent, et elles ne disent pas la même chose parce qu’elles ne répondent pas à la même question. La page des exigences donne la recommandation : PHP 8.3 ou plus, MySQL 8.0 ou plus ou MariaDB 10.11 ou plus, et HTTPS. Elle ajoute que WordPress fonctionne encore avec PHP 7.4 et MySQL 5.5.5, en prévenant que ces versions ont atteint leur fin de vie et peuvent exposer le site à des failles. La table de compatibilité du manuel des développeurs, mise à jour le 19 août 2026, dit ce que le cœur a été testé pour accepter, version par version.

WordPress et PHP, version par version

Dates de sortie : archive des versions de WordPress. Reports de correctifs : note de la version 7.1.4, qui précise que seule la version la plus récente est activement maintenue et que les branches plus anciennes reçoivent les correctifs « à titre de courtoisie ».

Trois faits se lisent dans cette table. D’abord, WordPress 7.0 a relevé le minimum à PHP 7.4.0 : l’annonce du 9 janvier 2026 explique que les sites restés sur PHP 7.2 ou 7.3 demeurent sur la branche 6.9, et que l’équipe envisage de retirer une version de PHP quand moins de 5 % des installations l’utilisent, sans calendrier fixe. Ensuite, la recommandation (8.3) et le minimum (7.4) sont très éloignés : le cœur garde une large tolérance pour ne laisser personne en route. Enfin, l’étiquette « bêta », qui marquait une version de PHP prise en charge par le cœur mais pas encore adoptée par au moins 10 % des sites, a été retirée en mai 2026. La table expliquait l’étiquette par le fait que WordPress tourne rarement sans thème ni extension ; elle ne dit pas pourquoi elle l’a retirée.

Le guide pour installer WordPress sur un hébergement NovaHoster reprend la même recommandation au moment de créer un site. La suite de cet article concerne un site qui existe déjà, avec son thème et ses extensions.

La prochaine version majeure, WordPress 7.2, est annoncée pour début décembre 2026. Au 3 novembre, ni sa feuille de route ni la table de compatibilité ne parlent de PHP 8.6 ni d’un nouveau minimum.

Le calendrier de PHP : ce qui s’arrête, et quand

Chaque branche de PHP reçoit deux ans de support actif, avec des correctifs de bugs et de sécurité publiés régulièrement, puis deux ans de correctifs de sécurité seulement, publiés au besoin ; la page des versions maintenues parle de quatre ans au total. Après, la branche est en fin de vie : php.net écrit que ses utilisateurs « devraient la quitter dès que possible ».

Les branches de PHP au 3 novembre 2026

Sources du tableau : branches maintenues, branches en fin de vie et calendrier de PHP 8.6 sur le wiki du projet, qui prévient que des préversions peuvent être ajoutées ou retirées. Les dates de fin de support de PHP 8.6 ne sont pas encore publiées.

Ce calendrier rencontre la réalité du parc. Selon les statistiques de WordPress.org (relevé de leur API le 3 novembre 2026), 32,8 % des sites WordPress qui transmettent leur version tournent sur un PHP antérieur à 8.2, dont 14,7 % sur PHP 7.4, et 22,8 % sur PHP 8.2. Le 1^er janvier 2027, si rien ne bouge, 55,6 % des sites WordPress fonctionneront sur une branche que ses auteurs ne corrigent plus. À l’autre bout, 27,7 % sont sur 8.3, 10,5 % sur 8.4 et 6,2 % sur 8.5.

Une branche en fin de vie ne s’arrête pas de fonctionner le 1^er janvier. Elle cesse de recevoir des correctifs : la prochaine faille y restera ouverte, sauf si le fournisseur du système (la distribution Linux, ou CloudLinux) la répare lui-même. C’est ce qui s’est passé pour PHP 7.4, 8.0 et 8.1 avec PHP2Shell, au prix de reports que rien ne garantit pour la fois suivante ; la méthode de vérification d’un PHP réparé est dans l’article sur la faille.

Quelle version choisir aujourd’hui

Pour un site à jour, la décision tient en trois lignes.

• PHP 8.4, le choix par défaut. Accepté par WordPress depuis la 6.7, il reste en support actif jusqu’à fin 2026 et reçoit des correctifs de sécurité jusqu’au 31 décembre 2028. Les extensions maintenues ont eu près de deux ans pour s’y adapter.
• PHP 8.5, si vos extensions suivent. Accepté depuis WordPress 6.9, corrigé jusqu’en 2029. Il gagne un an de tranquillité, à condition que le thème et chaque extension tournent sans erreur sur la copie.
• PHP 8.3, une étape. C’est le minimum recommandé par WordPress, mais il ne reçoit plus que des correctifs de sécurité, et plus rien après le 31 décembre 2027. Il convient à un site dont une extension bloque sur 8.4, le temps de la remplacer.

PHP 8.2 n’est plus un choix, seulement un point de passage : il lui reste moins de deux mois. Un site encore en 7.4, 8.0 ou 8.1 peut passer par 8.2 ou 8.3 pour séparer les problèmes, puis continuer.

PHP 8.6 sort le 19 novembre, selon son calendrier. Le manuel de WordPress explique que le travail de compatibilité commence quand une version de PHP entre en gel des fonctionnalités et en préversion, et qu’il aboutit le plus souvent dans la version majeure de WordPress publiée vers le mois de novembre. Pour un site qui vend ou qui reçoit des demandes, le bon moment viendra quand la table de compatibilité l’aura ajouté et que vos extensions l’annonceront. Essayer 8.6 sur une copie dès sa sortie est utile ; y mettre le site en ligne en novembre ne l’est pas.

Le cœur suit, les extensions pas toujours

Quand un WordPress casse après un changement de PHP, l’erreur pointe presque toujours un fichier de wp-content/plugins ou de wp-content/themes. Les nouvelles versions de PHP retirent des fonctions anciennes et durcissent des comportements tolérés jusque-là ; un code écrit il y a dix ans et jamais repris tombe sur l’un ou l’autre.

Le passage à PHP 8.0 : le vrai mur

Les sites encore en 7.4 franchissent le changement le plus lourd. Le guide de migration de PHP 8.0 énumère ce qui ne passe plus : create_function() et each() sont supprimées ; plusieurs avertissements deviennent des exceptions, par exemple count() appliqué à une valeur qui n’est pas dénombrable, ou un nombre d’arguments incorrect passé à une fonction de PHP ; les opérateurs arithmétiques lèvent une TypeError sur un tableau ou un objet. La comparaison souple change aussi de sens : 0 == "foo" était vrai, il devient faux. Une extension qui comptait dessus ne plante pas : elle se trompe, sans message. C’est pour cela qu’on teste les fonctions, pas seulement l’affichage.

Les avertissements de dépréciation : un délai, pas une panne

Les versions suivantes annoncent plus qu’elles ne retirent. PHP 8.2 a déprécié la création de propriétés dynamiques, sauf pour les classes qui l’autorisent explicitement, les fonctions utf8_encode() et utf8_decode(), et l’interpolation "${var}". Une dépréciation écrit une ligne dans le journal et le site continue de tourner. Elle dit seulement que ce code cassera le jour où PHP retirera la fonction. Dans le journal, distinguez donc les lignes Deprecated et Warning, à transmettre à l’auteur de l’extension, des lignes Fatal error, qui bloquent la bascule.

Ce que disent les extensions d’elles-mêmes

Chaque extension peut déclarer, dans son fichier principal, la version minimale de PHP qu’elle exige (Requires PHP) et la version minimale de WordPress (Requires at least). Sa fiche sur wordpress.org indique aussi la version de WordPress avec laquelle elle a été testée (Tested up to). Aucun de ces champs ne garantit la compatibilité avec une version de PHP plus récente : ils disent seulement si l’auteur suit. Le journal des modifications de l’extension est plus parlant, quand il mentionne PHP 8.4 ou 8.5.

Thèmes et extensions abandonnés : les repérer, décider

Le cas difficile n’est pas l’extension en retard d’une version : c’est celle dont personne ne s’occupe plus. Elle bloque le site sur un vieux PHP, et souvent elle porte ses propres failles, que les failles de WordPress de ce mois d’octobre ont encore illustrées.

Quatre signes la trahissent : une dernière mise à jour vieille de plusieurs années ; un champ Tested up to resté plusieurs versions majeures derrière ; une fiche fermée sur le répertoire de wordpress.org ; un thème premium acheté autrefois, dont la licence n’est plus renouvelée et qui ne reçoit donc plus de mises à jour. Les thèmes faits sur mesure par une agence disparue entrent dans la même famille.

Face à elle, il y a trois issues, dans cet ordre de préférence :

1. La remplacer par une extension maintenue qui rend le même service. C’est le plus fréquent pour un formulaire, un carrousel, un module de partage ou d’optimisation, où les alternatives ne manquent pas.
2. La faire corriger par un développeur, quand elle porte une fonction propre au site : un calcul, une intégration à un logiciel de gestion. Le journal d’erreurs de la copie lui donne la liste exacte des lignes à reprendre.
3. Garder temporairement l’ancienne branche de PHP, en sachant ce que cela coûte : un site exposé à la prochaine faille non corrigée. Fixez-vous une date de sortie, pas plus de quelques semaines.

Un site sur WordPress 6.x ou plus ancien bloqué par une extension se traite dans le même ordre : d’abord WordPress et les extensions à jour, ensuite PHP. Le guide pour mettre à jour WordPress, ses thèmes et ses extensions détaille l’ordre des mises à jour et le retour arrière ; il ne sert à rien de le refaire ici. Une boutique PrestaShop suit une logique voisine, avec une contrainte de plus : PrestaShop 1.7 et 8 ne tournent sur aucun PHP maintenu.

Changer de version de PHP sans casser le site : la méthode

1. L’inventaire

Dans l’administration de WordPress, Outils, puis Santé du site, onglet Infos : la version de WordPress, celle de PHP, le thème actif et son thème parent, chaque extension avec sa version. Copiez cette liste, c’est votre point de comparaison. Notez à côté de chaque extension son champ Requires PHP et la date de sa dernière mise à jour, puis marquez les fonctions vitales du site : formulaire de contact, panier et paiement, espace membre, envoi des e-mails, tâches planifiées. Un développeur peut aussi passer le code du thème et des extensions au contrôleur PHPCompatibilityWP (des règles pour PHP_CodeSniffer), qui signale les fonctions retirées sans rien exécuter.

2. La copie

Une copie du site, fichiers et base, sur une autre adresse : c’est là qu’on change PHP en premier. Dans Plesk, le WP Toolkit la crée avec le bouton Cloner de la carte du site, par défaut sur un sous-domaine préfixé staging. Sur nos offres, ce staging est compris dans WP BUSINESS et WP ULTIMATE ; le clonage crée une base de données pour la copie, il ne tient donc pas sur une formule à base unique. Le guide sauvegarder, accélérer et protéger un site WordPress dans Plesk montre aussi comment vérifier qu’une sauvegarde se restaure sur ce clone.

Sans copie possible, faites une sauvegarde complète juste avant, depuis Plesk ou le WP Toolkit, et téléchargez-la hors du serveur. Changez ensuite PHP à une heure creuse : la bascule se défait en quelques secondes, mais le temps qu’on s’en aperçoive, des visiteurs auront vu l’erreur.

3. L’essai sur la copie

La version de PHP se règle par domaine et par sous-domaine : dans Plesk, Sites Web & Domaines, puis Paramètres PHP, choisissez le sous-domaine de la copie, puis la version voulue dans le menu. La documentation de Plesk prévient elle-même que deux versions de PHP ne sont pas compatibles à 100 %. Parcourez ensuite la copie comme un client : page d’accueil, une page de chaque modèle, une recherche, le formulaire, un passage par le panier si le site vend, l’administration, l’éditeur. Vérifiez aussi la version de PHP affichée dans Santé du site sur la copie : c’est elle qui fait foi.

4. Le journal d’erreurs

Une page qui s’affiche ne prouve pas que tout va bien. Ouvrez Logs dans Plesk pour le sous-domaine de la copie : le journal error_log reçoit le plus souvent les erreurs de PHP, avec le fichier et la ligne en cause. Le guide pour lire les journaux et diagnostiquer une erreur explique comment lire une ligne. Si le journal reste muet, activez le débogage sur la copie seulement, WP_DEBUG et WP_DEBUG_LOG à vrai, WP_DEBUG_DISPLAY à faux : les messages s’écrivent dans wp-content/debug.log. Laissez la copie tourner un jour ou deux, le temps que les tâches planifiées passent. Une erreur fatale bloque la bascule ; une dépréciation se note et se transmet.

5. La bascule, puis le retour arrière s’il le faut

Quand la copie passe sans erreur fatale, faites le même changement sur le domaine principal, au même endroit de Plesk, à une heure creuse, puis refaites le parcours et relisez le journal. Gardez la copie quelques jours : elle sert de point de comparaison, puis supprimez-la, car elle expose un second exemplaire du site.

Si quelque chose casse quand même, le retour arrière est le même geste à l’envers : remettre la version précédente dans Paramètres PHP. Les fichiers et la base n’ont pas changé, puisqu’un changement de version de PHP n’y touche pas. Depuis WordPress 5.2, une erreur fatale déclenche le mode de récupération : l’adresse e-mail d’administration reçoit un lien qui ouvre l’administration en mettant en pause l’extension ou le thème fautif. Les visiteurs, eux, voient toujours le site en panne : le lien sert à diagnostiquer, pas à attendre.

Le gain de vitesse : à mesurer, pas à promettre

Changer de PHP est souvent présenté comme un accélérateur. Les mesures publiées sont plus modestes. Les essais de Kinsta, mis à jour le 13 décembre 2025, sur WordPress 6.8.0 sans extension ni cache, avec OPcache actif, donnent 139,06 requêtes par seconde en PHP 7.4, 146,09 en 8.2, 142,75 en 8.3, 148,22 en 8.4 et 148,30 en 8.5 : environ 6,6 % de mieux entre 7.4 et 8.5, et un écart presque nul entre 8.4 et 8.5. Tideways, le 19 novembre 2025, avec WordPress 6.8.3, trouve des chiffres proches d’une version à l’autre, PHP 7.4 restant environ 5 % en dessous, et conclut que passer à la dernière version de PHP n’est pas un raccourci magique vers la performance.

Ces essais portent sur un WordPress nu. Sur un vrai site, le gain dépend des extensions, du thème et surtout du cache : une page servie depuis le cache ne passe plus par PHP du tout. Mesurez donc vous-même, sur la copie, le temps de réponse du serveur avant et après, sur les mêmes pages, à la même heure. Si le site reste lent, la cause est ailleurs, et notre guide pour un WordPress plus rapide passe en revue les autres pistes : cache, images, extensions trop lourdes.

La vraie raison de changer reste la sécurité : une branche qui reçoit encore des correctifs. La vitesse, quand elle vient, est un bonus.

Ce que nous faisons, et ce qui reste à vous

Sur nos packs, toutes les versions de PHP sont disponibles, de la plus ancienne à la plus récente, et chaque domaine ou sous-domaine a la sienne, choisie dans Paramètres PHP. C’est ce qui permet d’essayer une version sur une copie sans toucher au site, ou de faire tourner côte à côte un site neuf et un site plus ancien. C’est ce qu’il faut attendre d’un hébergeur qui laisse choisir la version de PHP de chaque site : pouvoir faire ce passage à son rythme.

Une version disponible n’est pas pour autant une version conseillée : les branches 7.4 à 8.1 restent proposées pour les sites qui en ont encore besoin, mais elles sont en fin de vie et la prochaine faille de PHP pourrait y rester ouverte. Notre équipe tient à jour le PHP des serveurs mutualisés ; le choix de la branche, lui, est le vôtre, parce que c’est vous qui savez ce que vos extensions supportent.

Sur nos packs WordPress, OPcache est actif par défaut et le staging est compris à partir de WP BUSINESS. Les sauvegardes de nos serveurs servent à reprendre le service après un incident chez nous : avant de changer PHP, faites la vôtre depuis Plesk, ou souscrivez la sauvegarde externalisée quotidienne. Et si vous arrivez d’un autre hébergeur, notre migration gratuite déménage le site tel quel, avec sa version de WordPress et ses extensions : la montée de version de PHP vient après, sur la copie, avec la méthode ci-dessus.

Sources

Pages consultées le 3 novembre 2026.

• WordPress.org — exigences de WordPress (modifiée le 7 mai 2026) ; compatibilité de PHP et versions de WordPress (modifiée le 19 août 2026) ; Dropping support for PHP 7.2 and 7.3 (9 janvier 2026) ; Roadmap to 7.2 (18 septembre 2026).
• WordPress.org — archive des versions ; WordPress 7.1.4 (28 octobre 2026) ; statistiques et API des versions de PHP, relevée le 3 novembre 2026.
• WordPress, manuel des extensions — en-têtes Requires PHP et Requires at least ; fonctionnement du fichier readme.txt ; Fatal Error Recovery Mode in 5.2 (16 avril 2019).
• PHP — branches maintenues ; branches en fin de vie ; calendrier de PHP 8.6 ; guides de migration vers PHP 8.0 (incompatibilités) et vers PHP 8.2 (dépréciations).
• Plesk Obsidian, guide du client — paramètres PHP ; WP Toolkit ; fichiers de log.
• PHPCompatibility — PHPCompatibilityWP, règles pour PHP_CodeSniffer adaptées à WordPress.
• Mesures de performance — Kinsta, PHP benchmarks (mis à jour le 13 décembre 2025) ; Tideways, PHP Benchmarks: 8.5 vs 8.4, 8.3 and 7.4 (19 novembre 2025).