Mettre à jour PHP WordPress : méthode sûre en 2026

PHP exécute une grande partie du code qui transforme les contenus et réglages WordPress en pages envoyées au navigateur. Une version obsolète peut ne plus recevoir de correctifs de sécurité ; une version récente peut révéler une extension, un thème ou un développement personnalisé qui dépend d’un comportement ancien. La bonne méthode ne consiste donc ni à ignorer la mise à niveau ni à changer la version directement en production.

Pour mettre à jour PHP WordPress proprement, il faut traiter l’opération comme une petite migration : inventorier, sauvegarder, restaurer un test, reproduire le site dans un environnement de staging, corriger les incompatibilités, tester les parcours réels, préparer un retour arrière, basculer pendant une fenêtre contrôlée et surveiller le résultat.

La réponse courte

En août 2026, la page officielle des versions PHP prises en charge indique que PHP 8.4 et 8.5 sont en support actif, tandis que PHP 8.2 et 8.3 ne reçoivent plus que des correctifs de sécurité. PHP 8.2 atteindra sa fin de vie le 31 décembre 2026. Du côté de WordPress, le guide d’environnement serveur recommande PHP 8.4 ou une version ultérieure pour la production et précise les compatibilités par version de WordPress.

Ces informations définissent une direction, pas une cible universelle. Pour mettre à jour PHP WordPress, la version retenue doit être prise en charge à la fois par le cœur WordPress utilisé, les extensions, le thème, le code personnalisé et la plateforme d’hébergement. Pour certains sites, PHP 8.4 sera le choix prudent ; pour un autre projet entièrement testé avec un WordPress et des dépendances compatibles, PHP 8.5 pourra être approprié.

Ne confondez pas trois notions :

la version minimale sur laquelle WordPress peut encore fonctionner pour des raisons de compatibilité historique ;
la version officiellement prise en charge par le projet PHP ;
la version que l’ensemble de votre site a réellement validée.

Pourquoi ce sujet reste important

En 2021, de nombreux sites préparaient encore leur passage de PHP 7 vers PHP 8. Le problème de fond reste identique, mais les versions concernées ont changé. PHP 7.4 a atteint sa fin de vie en novembre 2022, PHP 8.0 en novembre 2023 et PHP 8.1 à la fin de 2025. Continuer à utiliser une branche ancienne parce qu’elle « fonctionne encore » ne signifie pas qu’elle reçoit les correctifs du projet PHP.

WordPress maintient une compatibilité étendue afin de ne pas casser brutalement les sites anciens. Le tableau officiel PHP Compatibility and WordPress Versions montre cette compatibilité par version. Il faut toutefois lire ce tableau avec le calendrier de support de PHP : une branche peut rester compatible avec WordPress tout en étant déjà abandonnée par son éditeur.

Le deuxième changement est la maturité de l’outillage. Les hébergeurs proposent plus souvent un sélecteur de version, les extensions déclarent mieux leurs exigences et les pipelines de test peuvent couvrir plusieurs branches PHP. Aucun outil ne remplace cependant un test du site réel. Une analyse statique peut repérer une fonction supprimée ; elle ne sait pas toujours si un paiement, un formulaire ou une tâche planifiée fonctionne dans le contexte de production.

Pourquoi une mise à jour peut casser un site

Une version majeure de PHP peut supprimer une fonction obsolète, renforcer le typage, transformer un avertissement en erreur ou modifier le comportement d’une bibliothèque. WordPress Core suit ces évolutions, mais un site WordPress n’exécute presque jamais le cœur seul.

Les causes courantes d’incident sont :

une extension abandonnée ou rarement mise à jour ;
un thème qui contient du code métier ancien ;
un extrait ajouté dans functions.php sans tests ;
une intégration externe qui suppose un format précis ;
une bibliothèque incluse par plusieurs extensions ;
une fonction personnalisée qui masque une erreur en production ;
une tâche planifiée qui n’est pas couverte par les tests visuels ;
une extension disponible dans une interface PHP mais absente dans l’autre.

Le passage peut sembler réussi parce que la page d’accueil s’affiche, puis échouer lors d’un envoi de formulaire, d’un achat, d’une génération d’image ou d’une tâche nocturne. Pour mettre à jour PHP WordPress, les tests doivent couvrir les parcours, pas seulement les pages.

Étape 1 : établir l’inventaire

Relevez les versions de WordPress, PHP, du thème et de chaque extension. Identifiez le code personnalisé, les mu-plugins, les tâches planifiées, les formulaires, les passerelles de paiement, les connexions API, le multilingue, la recherche, les exports et les processus d’image.

Classez chaque composant : maintenu et compatible, maintenu mais à confirmer, non maintenu, personnalisé avec tests, personnalisé sans tests. Un composant non maintenu qui intervient dans un parcours critique devient le premier sujet de réparation.

Consignez aussi les contraintes fonctionnelles : heures d’activité, volume de commandes ou de formulaires, fréquence de publication, fenêtres de maintenance et perte de données acceptable. Cette analyse détermine si un retour à la version précédente suffit ou si une restauration de base de données peut être nécessaire.

Vérifier les exigences déclarées

Consultez les notes de version, les pages officielles des extensions et les exigences du thème. Une mention « compatible PHP 8 » est trop vague si la cible est 8.4 ou 8.5. Cherchez une version précise, la date du dernier test et les problèmes connus.

L’absence d’avertissement n’est pas une preuve de compatibilité. À l’inverse, un avertissement de dépréciation dans un environnement de test n’entraîne pas toujours une panne immédiate, mais signale une dette à corriger avant qu’une version ultérieure ne rende le comportement bloquant.

Étape 2 : préparer une sauvegarde restaurable

Une sauvegarde doit couvrir la base de données et les fichiers nécessaires : médias, extensions, thèmes et configuration pertinente. La documentation WordPress sur les sauvegardes rappelle que ces éléments sont complémentaires.

Avant de mettre à jour PHP WordPress, vérifiez :

l’heure et l’intégrité apparente de la dernière copie ;
la présence de la base et des fichiers ;
l’emplacement séparé de la copie ;
la durée de conservation ;
les droits nécessaires à une restauration ;
la procédure et le responsable du retour arrière.

Le test de restauration est l’étape décisive. Restaurez une copie dans un environnement isolé, ouvrez le site, reconnectez-vous à l’administration et vérifiez plusieurs médias et permaliens. Une notification « sauvegarde terminée » ne démontre pas que l’ensemble peut être récupéré dans le délai prévu.

Étape 3 : construire un staging représentatif

Pour mettre à jour PHP WordPress sans utiliser les visiteurs comme testeurs, le staging doit reproduire suffisamment la production pour révéler les incompatibilités : même version WordPress, mêmes extensions, même thème et même configuration PHP utile. Il doit rester privé, ne pas être indexable et ne pas envoyer de vrais courriels, commandes ou appels vers des systèmes externes.

Utilisez une copie de données réduite ou correctement protégée lorsque c’est possible. Ne transformez pas le staging en dépôt permanent de données personnelles. Les secrets et intégrations doivent être remplacés par des valeurs de test ou désactivés selon le parcours.

Dans le staging, commencez par mettre à jour WordPress, le thème et les extensions sur la version PHP actuelle. Testez ce premier état. Changez ensuite PHP. Cette séparation aide à attribuer une erreur à la mise à jour applicative ou à la nouvelle version de PHP.

Étape 4 : activer un diagnostic sûr

WordPress peut enregistrer les avertissements et erreurs lorsque le mode de débogage est configuré. Le manuel de débogage WordPress explique notamment WP_DEBUG et la journalisation associée.

Activez ces outils dans le staging ou pendant une fenêtre de diagnostic contrôlée. N’affichez pas les erreurs techniques aux visiteurs d’un site public : elles peuvent révéler des chemins, des noms de fichiers ou d’autres détails inutiles. Limitez l’accès aux journaux, purgez-les selon une politique définie et ne les copiez pas dans un article ou un ticket public sans les nettoyer.

Après le changement de version PHP, recherchez :

erreurs fatales et réponses HTTP 500 ;
fonctions ou signatures obsolètes ;
avertissements répétés qui remplissent les journaux ;
erreurs de connexion à la base ;
tâches planifiées échouées ;
erreurs AJAX ou REST ;
problèmes lors de la génération et de l’édition d’images.

Étape 5 : tester les parcours fonctionnels

Créez une liste courte mais représentative pour mettre à jour PHP WordPress avec des preuves. Pour un blog, elle comprend la connexion, la création d’un brouillon, l’ajout d’une image, la prévisualisation, la planification, la recherche et l’envoi d’un formulaire. Pour une boutique, ajoutez le panier, le paiement de test, les taxes, les coupons, les courriels et le traitement d’une commande.

Testez au minimum :

page d’accueil, article, page, catégorie, recherche et erreur 404 ;
connexion et déconnexion ;
création, modification et prévisualisation d’un contenu ;
téléversement et redimensionnement d’une image ;
formulaires et notifications en mode de test ;
API REST et intégrations critiques ;
tâches WP-Cron attendues ;
purge et régénération du cache ;
parcours mobile et ordinateur ;
sauvegarde puis restauration du staging mis à niveau.

Pour mettre à jour PHP WordPress avec confiance, conservez le résultat attendu, le résultat observé et la personne ou l’équipe responsable de chaque test. Une case cochée sans preuve n’aide pas lors d’un incident.

Étape 6 : mesurer sans promettre un gain universel

Une branche PHP récente peut apporter des améliorations au langage et à son moteur, mais le gain visible dépend du thème, des extensions, du cache, de la base de données, des images et du trafic. Ne promettez pas un pourcentage de vitesse avant d’avoir mesuré le site concerné.

Comparez avant et après dans les mêmes conditions : temps de réponse d’une page non mise en cache, comportement d’une page mise en cache, durée d’une tâche d’administration, taux d’erreur et utilisation de ressources pendant un scénario contrôlé. Répétez plusieurs mesures et séparez les tests de laboratoire des données de vrais visiteurs.

La documentation WordPress sur PHP et la performance rappelle que la version et la configuration influencent l’exécution, mais avertit également que thèmes et extensions peuvent ne pas être compatibles avec une version récente.

Étape 7 : préparer la bascule en production

Pour mettre à jour PHP WordPress en production, choisissez une fenêtre où le trafic et les opérations critiques sont prévisibles. Annoncez l’impact attendu aux personnes concernées, figez les changements non essentiels et confirmez que la sauvegarde vient d’être réalisée. Notez la version actuelle, la cible et la procédure exacte permettant de revenir à l’état précédent.

Une séquence prudente est :

vérifier les sauvegardes et la restauration testée ;
confirmer que la production correspond au staging validé ;
suspendre brièvement les changements si le site le nécessite ;
changer la version PHP par le mécanisme prévu par la plateforme ;
vider uniquement les caches nécessaires ;
exécuter les tests de fumée ;
rouvrir les parcours ;
surveiller erreurs, disponibilité et fonctions critiques.

Ne modifiez pas simultanément PHP, la base de données, le thème et dix extensions si ces changements peuvent être séparés. Plus le lot est large, plus le diagnostic et le retour arrière deviennent difficiles.

Étape 8 : définir un vrai retour arrière

Revenir à l’ancienne version PHP peut rétablir un code incompatible, mais ce geste ne remet pas automatiquement la base de données et les fichiers dans leur état précédent. Une extension mise à jour peut avoir exécuté une migration de données ; une commande ou un formulaire peut avoir créé de nouvelles écritures pendant la fenêtre.

Le plan doit donc préciser :

le seuil qui déclenche le retour ;
qui prend la décision ;
comment restaurer la version PHP ;
quand restaurer les fichiers ;
quand restaurer la base de données ;
comment préserver les nouvelles transactions si elles existent ;
quels contrôles confirmeront la récupération.

Pour un site transactionnel, la restauration de base exige une stratégie particulière afin de ne pas effacer des commandes récentes. Faites valider ce point avant la bascule, pas après l’incident.

Cas particuliers à ne pas oublier

WooCommerce et autres écritures fréquentes

Les boutiques, espaces membres et plateformes de réservation modifient continuellement la base. Réduisez la fenêtre, utilisez des transactions de test et prévoyez la conservation des nouvelles données. Vérifiez les extensions de paiement, d’expédition, de facturation et d’export.

Multisite

Un réseau WordPress peut contenir des thèmes et extensions activés différemment selon les sites. L’inventaire doit couvrir les usages réels du réseau, et les tests doivent inclure plusieurs sites représentatifs ainsi que l’administration du réseau.

Code personnalisé

Ajoutez des tests automatisés lorsque le code soutient une fonction critique. Exécutez l’analyse statique avec des règles adaptées à la cible PHP, puis complétez par des tests d’intégration. Une recherche textuelle de fonctions obsolètes ne suffit pas.

Tâches en ligne de commande et planifiées

Le PHP utilisé par le site web et celui utilisé par une tâche en ligne de commande peuvent différer. Vérifiez le mécanisme prévu par votre plateforme sans publier de chemins ou de configuration interne. Confirmez que les sauvegardes, imports, exports et traitements nocturnes utilisent la version attendue.

Checklist pour mettre à jour PHP WordPress

[ ] Version WordPress et cible PHP compatibles selon les tableaux officiels.
[ ] Toutes les branches PHP obsolètes identifiées.
[ ] Thème, extensions et code personnalisé inventoriés.
[ ] Dépendances abandonnées remplacées ou isolées.
[ ] Base de données et fichiers sauvegardés.
[ ] Restauration testée dans un environnement isolé.
[ ] Staging privé et représentatif.
[ ] WordPress, thème et extensions actualisés avant le changement PHP.
[ ] Journaux activés sans affichage public d’erreurs.
[ ] Pages, administration, médias, formulaires, API et tâches planifiées testés.
[ ] Mesures avant et après réalisées dans des conditions comparables.
[ ] Fenêtre de bascule et responsables définis.
[ ] Retour à la version précédente et restauration documentés.
[ ] Surveillance renforcée après la mise en production.
[ ] Date de la prochaine revue de version inscrite au calendrier.

Points clés à retenir

Le conseil durable est simple : ne laissez pas PHP devenir une dépendance invisible. Son cycle de support continue d’avancer, même lorsque le site semble stable. En 2026, les branches activement prises en charge sont différentes de celles de 2021, mais la discipline reste la même.

Pour mettre à jour PHP WordPress, choisissez une cible encore maintenue, compatible avec la version WordPress et réellement testée avec toutes les dépendances du site. Protégez l’opération par une sauvegarde restaurable, un staging fidèle, des tests de parcours et un retour arrière adapté aux données.

Pour replacer ce chantier dans un choix d’infrastructure plus large, consultez notre guide pour choisir un hébergement WordPress en 2026. Si le site doit être déplacé en même temps, séparez autant que possible le changement d’hébergement, la migration PHP et les mises à jour applicatives, puis préparez une analyse de migration fondée sur l’inventaire plutôt que sur une promesse générale.

Pour poursuivre cette série éditoriale, consultez également WordPress headless et React, ce qui a changé.