Fin de vie de PHP : le sujet dont personne ne vous parle

En résumé. La version de PHP se lit dans l'administration WordPress, via le menu Outils puis Santé du site, onglet Informations. Le panneau de votre hébergeur donne la même donnée. Une version 7 ou 8.0 n'est plus maintenue et expose le site à des failles.

Dans WordPress, ouvrez Outils puis Santé du site, onglet Informations, section Serveur : le numéro de version de PHP y figure. Le panneau de gestion de l'hébergeur affiche la même information, souvent avec la liste des versions disponibles et un bouton pour en changer.

Chaque branche de PHP suit un calendrier de fin de vie. La 8.1 n'est plus maintenue depuis le 31 décembre 2025, la 8.2 le sera fin 2026, puis la 8.3 en 2027 et la 8.4 en 2028. Une version 7 ou 8.0 ne reçoit plus aucun correctif de sécurité.

Connaître ce numéro est la première étape avant toute migration : il indique si le site tourne sur un moteur encore supporté ou déjà exposé. Sur une version obsolète, les failles découvertes ne sont pas corrigées, ce qui accroît le risque de piratage et d'incompatibilité avec WordPress, WooCommerce et les extensions récentes.

• PHP 8.1 : fin de vie le 31 décembre 2025
• PHP 8.2 : fin de support fin 2026
• PHP 8.3 : support jusqu'en 2027
• PHP 8.4 : support jusqu'en 2028

Questions associées : Que se passe-t-il quand PHP arrive en fin de vie ? · Qu'est-ce qu'une version de WordPress ou de PHP « obsolète » ? · Une version de PHP obsolète rend-elle un site vulnérable ?

En résumé. Si le site a été préparé et testé, le changement de version de PHP est invisible pour le visiteur. Sinon, des pages peuvent s'afficher en blanc ou renvoyer une erreur 500, le temps que les extensions et le code incompatibles soient corrigés.

Un hébergeur fait régulièrement évoluer les versions de PHP qu'il propose et finit par retirer les branches obsolètes. Le site WordPress bascule alors sur un moteur plus récent. S'il a été testé et adapté au préalable, la transition ne se voit pas et le visiteur ne remarque rien.

Dans le cas contraire, certaines pages ou fonctions peuvent s'afficher en écran blanc, renvoyer une erreur 500 ou cesser de répondre. Ces incidents viennent d'un thème daté, d'une extension non maintenue ou de code sur mesure écrit pour une version antérieure de PHP.

La parade consiste à tester la nouvelle version sur une copie du site avant qu'elle ne soit imposée en production. On y repère les extensions et le code à corriger, on applique les ajustements, puis on valide le changement en connaissance de cause. Un suivi de maintenance évite de découvrir le problème après coup, quand le site est déjà en panne.

Questions associées : Pourquoi un site finit-il par afficher un écran blanc ? · Une version de PHP obsolète rend-elle un site vulnérable ? · Que se passe-t-il quand PHP arrive en fin de vie ?

En résumé. Oui. Une montée de version de PHP peut casser un site WordPress si le thème, les extensions ou le code sur mesure emploient des fonctions dépréciées puis supprimées. Le risque se maîtrise en testant la version cible sur un environnement de préproduction avant la production.

Le risque principal vient des composants anciens. Un thème daté, une extension abandonnée ou du code sur mesure peuvent utiliser des fonctions PHP dépréciées, puis retirées dans les versions récentes. Le résultat va de l'avertissement discret dans les journaux à la page en erreur 500 visible du public.

Pour cette raison, une montée de version de PHP se prépare toujours sur un environnement de test, jamais directement en production. On y bascule la version cible, on parcourt le site page par page, on corrige les incompatibilités, puis on applique le changement une fois la compatibilité vérifiée.

Une maintenance suivie évite d'accumuler ce retard : un site tenu à jour progressivement se migre sans heurt, tandis qu'un site figé pendant des années concentre les incompatibilités et rend chaque bascule risquée. Tester avant d'agir reste la seule méthode fiable pour ne pas interrompre le service.

Questions associées : Une version de PHP obsolète rend-elle un site vulnérable ? · Qu'est-ce qu'une version de WordPress ou de PHP « obsolète » ? · Que se passe-t-il quand PHP arrive en fin de vie ?

En résumé. Oui. Le cœur de WordPress prend en charge les versions modernes de PHP, dont la 8.4, dont le support court jusqu'à fin 2028. La difficulté ne vient pas de WordPress lui-même, mais des extensions anciennes et du code sur mesure à vérifier avant de basculer.

Le cœur de WordPress suit de près l'évolution de PHP et prend en charge les versions modernes, y compris PHP 8.4, dont la fin de support est prévue fin 2028. Sur une installation à jour, le moteur ne pose donc aucun problème en soi.

Les points de blocage se trouvent ailleurs : extensions abandonnées, thèmes anciens et développements sur mesure écrits pour PHP 7. Ces éléments doivent être testés un par un et adaptés avant la bascule, car ce sont eux qui emploient des fonctions supprimées dans les versions récentes.

Vérifier la compatibilité de tout l'écosystème, plutôt que le seul cœur de WordPress, est la démarche qui garantit une migration sans coupure. En pratique, on contrôle chaque extension active et chaque bloc de code personnalisé sur une copie du site, on corrige ce qui doit l'être, puis on migre. C'est le décalage entre un WordPress à jour et son écosystème vieillissant qui crée les incidents, pas la version de PHP elle-même.

Questions associées : Que se passe-t-il quand PHP arrive en fin de vie ? · Qu'est-ce qu'une version de WordPress ou de PHP « obsolète » ? · Une version de PHP obsolète rend-elle un site vulnérable ?

En résumé. La responsabilité est partagée. L'hébergeur fournit et fait évoluer les versions de PHP disponibles, mais c'est au propriétaire du site, ou à son prestataire de maintenance, de s'assurer que le thème, les extensions et le code sont prêts pour la version à venir.

L'hébergeur gère l'infrastructure : il propose les versions de PHP, applique les mises à jour et retire les branches obsolètes. Il ne teste toutefois ni votre thème, ni vos extensions, ni votre code sur mesure. Cette part du travail ne relève pas de son périmètre et n'entre pas dans son contrat d'hébergement.

S'assurer que le site est compatible avec la prochaine version de PHP incombe donc au propriétaire ou à son prestataire de maintenance. C'est lui qui vérifie l'écosystème sur une copie, corrige les incompatibilités et planifie la bascule au bon moment.

Sans ce suivi, un changement décidé par l'hébergeur peut prendre le site au dépourvu et provoquer une panne. La répartition est donc claire : l'hébergeur maîtrise le calendrier des versions, le propriétaire maîtrise la préparation du site. C'est la coordination entre les deux qui évite les mauvaises surprises.

Questions associées : Une version de PHP obsolète rend-elle un site vulnérable ? · Que se passe-t-il si mon hébergeur change la version de PHP ? · Que se passe-t-il quand PHP arrive en fin de vie ?