Mettre à jour PHP sur WordPress sans risque

WordPress fonctionne grâce à PHP, le langage que le serveur exécute à chaque affichage de page. Une version obsolète ne coûte pas seulement en vitesse : une fois sa fin de vie atteinte, elle ne reçoit plus de correctif, même si une faille est découverte publiquement. Le calendrier a bougé depuis les anciens tutoriels, et il se lit sur une page officielle, pas sur un souvenir : au 08/10/2026, PHP 8.1 est sortie du support (31/12/2025) et PHP 8.2 n'a plus que 84 jours de correctifs de sécurité devant elle.

Les dates de cet article proviennent de php.net (pages Supported Versions et Unsupported Branches, consultées le 08/10/2026) et de la page WordPress.org « update PHP » (modifiée le 29/07/2026). Elles sont complétées par un relevé de recherche DataForSEO pour la France et par un calcul illustratif sur un parc de sites fictif.

Comment lire ce calendrier

PHP applique une règle simple : chaque branche est entièrement prise en charge pendant deux ans à partir de sa première version stable, puis pendant deux années supplémentaires pour les seuls problèmes de sécurité critiques. Une fois ces quatre ans écoulés, la branche atteint sa fin de vie et php.net invite à migrer sans attendre, car des failles non corrigées peuvent exposer le site. Le même jour, une version de test existe déjà pour la suite : PHP 8.6.0 RC3 est proposée aux essais, ce qui ne la destine évidemment pas à un site en production.

Du côté de WordPress, la page officielle de mise à jour indique que la version recommandée est PHP 8.3 ou supérieure, que le logiciel reste compatible avec PHP 7.4 et que les versions inférieures à 8.3 ne bénéficient pas des dernières protections. C'est l'hébergeur qui détermine les versions disponibles pour votre site . Selon la page officielle, de nombreux hébergeurs laissent le choix depuis leur espace client ; sinon, il faut demander le changement à l'hébergeur. WordPress affiche aussi des avertissements de type PHP Update Required ou PHP Update Recommended dans le tableau de bord et dans la Santé du site.

Un calcul illustratif : la marge de sécurité restante

La question utile n'est pas « quelle version est la plus récente ? » mais « combien de temps reste-t-il avant que ma version ne reçoive plus de correctif ? ». Le tableau ci-dessous compte les jours entre le 08/10/2026 et la fin du support de sécurité indiquée par php.net.

Application à un parc fictif de 30 sites tournant encore sous PHP 8.2 : pour tous les migrer avant le 31/12/2026, il reste 84 jours, soit 12 semaines, ce qui représente 2,5 sites par semaine. Avec une hypothèse de 90 minutes de préparation et de tests par site, le total est de 45 heures, soit 3,75 heures par semaine. Ces chiffres sont des hypothèses, mais ils montrent l'essentiel : la migration se planifie plusieurs semaines avant l'échéance, pas la veille.

Vérifier avant de changer quoi que ce soit

La version utilisée par le site se lit dans Outils > Santé du site > Info, section Serveur. Si elle est égale ou supérieure à 8.3, WordPress indique qu'aucune mise à jour n'est nécessaire pour l'instant. Avant de viser une version plus récente, contrôler que le thème et les extensions annoncent leur compatibilité : les auteurs sérieux l'indiquent dans la fiche ou la documentation. La page officielle propose aussi l'extension PHP Compatibility Checker, tout en rappelant qu'elle n'est pas parfaite : elle peut manquer un problème ou signaler une fausse alerte. Elle sert de premier tri, pas de garantie.

Lecture : l'expression la plus proche du sujet, « mettre à jour php wordpress », tombe à 10 recherches par mois depuis mai 2026, alors que « php 7.4 » conserve 140 recherches en moyenne : une partie des internautes cherche encore une version déjà abandonnée. Cet article sert donc deux besoins : repérer la version utilisée et connaître la date de fin du support.

Le plan d'action en quatre temps

• Aujourd'hui : lire la version dans la Santé du site et la comparer à la table ci-dessus.
• Cette semaine : sauvegarder, mettre à jour WordPress, thème et extensions, puis lancer le contrôle de compatibilité.
• Le jour du changement : choisir la version cible dans l'espace de l'hébergeur (8.3 au minimum), puis contrôler les pages clés et l'administration.
• Dans les 30 jours : noter dans votre calendrier la date de fin du support de la version choisie, pour ne pas la découvrir par un message d'alerte.

En cas d'erreur après le changement

Un écran blanc ou une erreur critique juste après le changement pointe, dans les cas courants, vers une extension ou un thème incompatible avec la nouvelle version. D'après la page officielle de WordPress, il suffit de demander à l'hébergeur de remettre la version précédente, puis de restaurer la sauvegarde si nécessaire. L'urgence levée, on identifie le composant fautif avant de retenter le changement.