Le 31 décembre 2026, PHP 8.2 sort de la période de correctifs de sécurité. Le site ne s'arrête pas ce jour-là, et c'est ce qui fait qu'on repousse. Mais c'est un des changements qui se préparent le mieux à l'avance, et qui se règlent mal dans l'urgence, un site en erreur et un hébergeur qui a déjà basculé. Voici ce que je vérifie, dans l'ordre, sur un site WordPress.

Le calendrier à retenir

Les dates viennent de la page officielle des versions supportées de PHP :

  • PHP 8.1 : plus de correctifs de sécurité depuis le 31 décembre 2025.
  • PHP 8.2 : correctifs de sécurité jusqu'au 31 décembre 2026.
  • PHP 8.3 : jusqu'au 31 décembre 2027.
  • PHP 8.4 : jusqu'au 31 décembre 2028.
  • PHP 8.5 : sortie en novembre 2025, jusqu'au 31 décembre 2029.

Si votre site tourne encore en 8.1 ou en 7.4, vous êtes déjà hors support : le sujet est plus urgent que la fin 2026.

Pourquoi c'est un risque

PHP est le langage qui exécute WordPress sur le serveur. Quand une version n'est plus maintenue, une faille découverte dans PHP lui-même reste ouverte. Vous n'avez rien à faire pour être exposé : il suffit de ne rien changer.

Il y a aussi le côté hébergeur. Selon les offres, il peut :

  • retirer la version et basculer les sites d'office sur une version plus récente, à une date que vous ne choisissez pas ;
  • laisser la version disponible mais la facturer comme support étendu ;
  • vous envoyer un avertissement que personne ne lit, jusqu'au jour où le site affiche une erreur.

Le pire scénario n'est pas la fin du support, c'est la bascule imposée un vendredi soir sur un site qui n'a jamais été testé.

Connaître sa version de PHP

Deux endroits suffisent :

  • Dans WordPress : Outils > Santé du site, onglet Info, section Serveur. La version de PHP y figure. L'onglet État affiche aussi une alerte quand la version est trop ancienne.
  • Chez l'hébergeur : l'espace client indique la version par site ou par domaine, et permet de la changer. Sur un hébergement mutualisé, elle peut différer d'un site à l'autre du même compte.

Pour une agence qui gère plusieurs dizaines de sites, faites un tableau : site, hébergeur, version de PHP, extensions critiques, qui a les accès. C'est la partie la moins amusante, et celle qui évite les mauvaises surprises.

Ce que WordPress supporte

Côté cœur, il n'y a en général pas de souci : la page de compatibilité de l'équipe WordPress indique les versions récentes de WordPress comme compatibles avec PHP 8.2, 8.3 et 8.4. Si votre WordPress est à jour, ce n'est donc pas lui qui bloquera. Un WordPress en retard de plusieurs versions est un autre sujet : on le met à jour d'abord, dans un chantier séparé.

Le cœur compatible ne dit rien de vos extensions et de votre thème. C'est là que ça se passe.

Ce qui casse en pratique

D'après ce que je rencontre sur les sites que je migre, les problèmes viennent presque toujours du même endroit :

  • Une extension ou un thème abandonné. Le code a été écrit pour une ancienne version de PHP et personne ne l'a mis à jour depuis des années. Un thème acheté sur une place de marché et jamais mis à jour en est le cas typique.
  • Des fonctions et des comportements dépréciés. PHP marque des fonctionnalités comme obsolètes version après version, puis les retire. Une fonction dépréciée en 8.2 peut avoir disparu ou changé en 8.3 ou 8.4. Les guides de migration de php.net listent ces changements.
  • Des avertissements qui deviennent des erreurs. Du code qui produisait un simple avertissement (variable non définie, paramètre nul passé à une fonction qui n'en accepte plus) peut, dans une version plus récente, lever une erreur fatale.
  • Des extensions PHP absentes. Une extension serveur (intl, imagick, par exemple) qui n'est pas installée pour la nouvelle version chez l'hébergeur : le site demande un module que la nouvelle version n'a pas.

Le symptôme est toujours le même : un écran blanc, ou le message « Une erreur critique est survenue sur ce site ». WordPress envoie alors un mail à l'adresse d'administration, souvent une boîte que plus personne ne consulte. Le journal d'erreurs PHP de l'hébergeur dit exactement quel fichier et quelle ligne posent problème.

La méthode sûre

1. Sauvegarder

Fichiers et base de données, avec une copie hors du serveur. Vérifiez qu'elle se restaure, une sauvegarde jamais testée n'est qu'une hypothèse.

2. Travailler sur une copie

Créez un environnement de préproduction avec la même version de PHP que la production, puis changez de version sur cette copie uniquement. Beaucoup d'hébergeurs en proposent un en un clic. À défaut, un sous-domaine protégé par mot de passe et une copie du site font l'affaire. Pensez à empêcher l'indexation de la copie et l'envoi de vrais mails depuis elle.

3. Mettre à jour avant de changer de version

Le cœur, les extensions et le thème, dans cet ordre, sur la copie. Une grande partie des incompatibilités disparaît avec la dernière version d'une extension encore maintenue. Notez celles qui n'ont pas été mises à jour depuis longtemps : ce sont vos candidates à la panne.

4. Changer la version de PHP et activer le journal d'erreurs

Passez la copie en 8.3 ou 8.4, avec WP_DEBUG et WP_DEBUG_LOG activés sur la copie. Les avertissements se retrouvent alors dans wp-content/debug.log, avant d'être un problème en production.

5. Tester les parcours qui comptent

La page d'accueil et quelques pages de contenu ne suffisent pas. Testez ce qui rapporte ou ce que le client regarde : formulaires de contact (et réception du mail), connexion, recherche, tunnel de commande et paiement s'il y en a un, espace administrateur, import ou export, tâches planifiées. Passez aussi dans l'administration : un écran cassé côté admin se voit rarement depuis le site public.

6. Basculer, avec un retour arrière prévu

Choisissez un moment calme, pas un vendredi soir. Changez la version de PHP en production, puis revérifiez les mêmes parcours. Sachez à l'avance comment revenir à la version précédente (sélecteur de version chez l'hébergeur, ou restauration de la sauvegarde) et qui le fait. Si ce retour n'est possible que jusqu'à la date d'arrêt de l'ancienne version, cela fixe aussi votre échéance réelle.

7. Vérifier dans les jours qui suivent

Surveillez le journal d'erreurs, la Search Console (erreurs serveur, pages en 5xx) et les mails du site. Les tâches planifiées et les envois de mails ne se voient qu'au bout de quelques jours.

Quand faire appel à quelqu'un

Vous pouvez le faire vous-même sur un site simple, avec peu d'extensions et un thème maintenu. Je recommande de se faire aider dans ces cas :

  • une extension ou un thème sur mesure, ou abandonné et indispensable ;
  • une boutique WooCommerce ou un site qui encaisse de l'argent ;
  • un multisite, ou plusieurs sites sur le même serveur ;
  • aucune préproduction disponible, ou aucun accès au journal d'erreurs ;
  • une agence qui doit traiter un parc de sites avant la fin de l'année.

Je fais ces migrations au forfait de 350 € par site, prix net (TVA non applicable, article 293 B du CGI) : inventaire, essai sur une copie, correction des incompatibilités, bascule à l'heure convenue et vérification ensuite. Le détail est sur la page migration WordPress. Pour les agences qui veulent sous-traiter en marque blanche, la page agences explique le fonctionnement. Un site dont l'extension principale est abandonnée passe sur devis, annoncé avant de commencer.

À retenir

La fin de support de PHP 8.2 laisse encore quelques semaines. Dressez la liste de vos sites et de leur version, passez-les par une copie, et planifiez les bascules avant la fin de l'année plutôt que le jour où l'hébergeur le décide à votre place.