Aller au contenu principal
Les AI Overviews sont déployés en France depuis le 22 juillet 2026
Maintenance WordPress Lecture 6 min

Fin de vie de PHP

La fin de vie d'une version de PHP est la date à partir de laquelle elle ne reçoit plus aucun correctif, pas même de sécurité.

Définition

La fin de vie d’une version de PHP est la date à partir de laquelle elle ne reçoit plus aucun correctif, pas même de sécurité. Elle est publiée des années à l’avance. Ce qui se décide n’est donc pas la date, mais le moment de monter de version avant elle.

01Une branche de PHP traverse trois états, pas deux.
02Figurer parmi les versions supportées ne veut pas dire être encore maintenue.
03Le site ne tombe pas le jour de la fin de vie, et c’est ce qui la rend facile à manquer.

Les trois états d’une version de PHP

Entre la sortie et la fin de vie, il y a une étape intermédiaire que presque personne ne connaît.

PHP est le langage installé sur le serveur qui exécute WordPress à chaque page demandée, et il est publié par branches. Une branche, par exemple 8.3, vit d’abord deux ans en support actif : elle reçoit des corrections de bogues et des correctifs de sécurité. Elle passe ensuite deux ans en correctifs de sécurité seulement : plus aucune correction de bogue, uniquement ce qui touche à la sécurité, et seulement quand c’est nécessaire. Au bout de ces quatre années, elle entre en fin de vie et ne reçoit plus rien.

C’est l’état intermédiaire qui piège. La branche figure toujours dans la liste des versions supportées de php.net, un tableau de bord d’hébergeur la présente comme valide, et rien n’indique qu’elle a déjà quitté la maintenance complète.

BrancheÉtatSupport actifCorrectifs de sécurité
8.5support actifjusqu’au 31/12/2027jusqu’au 31/12/2029
8.4support actifjusqu’au 31/12/2026jusqu’au 31/12/2028
8.3sécurité seulementterminé le 31/12/2025jusqu’au 31/12/2027
8.2sécurité seulementterminé le 31/12/2024jusqu’au 31/12/2026
8.1fin de vieterminéterminé le 31/12/2025
8.0fin de vieterminéterminé le 26/11/2023
7.4fin de vieterminéterminé le 28/11/2022

Une branche en fin de vie garde sa dernière version publiée, et n’en recevra plus d’autre : 8.1.34 pour la branche 8.1, 8.0.30 pour la 8.0, 7.4.33 pour la 7.4. Un serveur qui affiche l’un de ces numéros est arrêté à la date du tableau, quelle que soit sa date de mise en service.

Tableau relevé le 18 septembre 2026 sur php.net. Ces dates changent quand une branche avance dans son cycle et quand une nouvelle sort : les deux pages officielles citées en fin de fiche font foi à tout moment.

Ce que la fin de vie change pour votre site

Rien de visible, et c’est exactement le problème.

Le jour de la fin de vie, le site continue de fonctionner à l’identique. Aucune page blanche, aucun message, aucune alerte. Ce qui s’arrête est invisible : lorsqu’une faille est découverte dans PHP les mois suivants, elle est corrigée dans les branches maintenues et ne l’est pas dans la vôtre. L’écart se creuse ensuite à chaque faille publiée, sans jamais produire de symptôme.

Trois conséquences pratiques suivent, dans cet ordre. Les extensions et les thèmes finissent par exiger une version plus récente, et leurs mises à jour cessent de s’installer. Les hébergeurs programment la bascule de leurs serveurs vers une branche maintenue, à leur propre calendrier. Et la migration, repoussée, se fait alors dans l’urgence, au moment choisi par quelqu’un d’autre.

Deux choses à ne pas confondre. La fin de vie d’une version de PHP est un fait technique décidé par le projet PHP, pas une obligation légale. Un hébergeur qui impose une date de bascule applique sa propre politique commerciale, qui peut être plus tôt ou plus tard. Les deux calendriers existent, ils ne coïncident pas, et c’est celui de l’hébergeur qui arrive en premier dans la boîte mail.

Relevé du 18 septembre 2026 sur vingt et un sites WordPress, en lecture seule. Les vingt installations d’un même compte mutualisé tournent sur PHP 8.3.33, sans exception, et le vingt et unième site, hébergé sur un autre compte, sur la même version au chiffre près. Aucun de ces sites n’est en retard au sens habituel du terme : ils sont tous sur la branche que wordpress.org recommande, « PHP 8.3 ou plus ». Et pourtant, d’après php.net relevé le même jour, la branche 8.3 a quitté le support actif le 31 décembre 2025, il y a 261 jours. Le plancher recommandé par WordPress est donc déjà une branche qui ne reçoit plus que des correctifs de sécurité. Suivre la recommandation officielle ne suffit pas à être sur une version pleinement maintenue, et c’est mesurable sans quitter son propre parc.

Savoir où vous en êtes, et quand agir

Une seule date compte vraiment, et elle se lit à l’avance.

01

Relever la version en place

L’écran de santé du site, dans l’administration de WordPress, affiche la version de PHP utilisée. C’est la même information que celle du tableau de bord de l’hébergeur, prise du côté du site.

02

Situer cette version dans le cycle

Le tableau ci-dessus, ou les pages de php.net, disent si la branche est en support actif, en correctifs de sécurité seulement, ou en fin de vie.

03

Retenir la date de fin des correctifs

C’est la seule échéance qui engage quelque chose. Prévoir la montée de version avant, plutôt que de la subir après.

04

Vérifier ce qui pourrait bloquer

Ce sont presque toujours un thème ou des extensions anciennes qui empêchent de monter, jamais WordPress lui-même. La fiche sur la compatibilité PHP traite ce point en détail.

Questions fréquentes

Mon site est-il en danger le jour même de la fin de vie ?

Non. Le risque n’apparaît pas à cette date, il commence à s’accumuler après, au rythme des failles découvertes dans PHP et corrigées uniquement dans les branches maintenues. C’est un risque qui croît avec le temps, sans aucun signe visible.

Une version en correctifs de sécurité seulement est-elle acceptable ?

Pour un temps, oui, c’est même la situation des vingt et un sites du relevé ci-dessus, tous sur la branche 8.3. Elle devient inconfortable quand un bogue qui n’est pas de sécurité vous touche, puisqu’il ne sera pas corrigé, et quand la date de fin des correctifs approche.

Qui décide de monter la version, moi ou mon hébergeur ?

Les deux, et pas au même moment. Vous pouvez généralement choisir la version depuis le panneau d’hébergement. L’hébergeur, lui, retire les anciennes versions selon son propre calendrier, en prévenant à l’avance. Agir avant cet avis laisse le choix de la date et du moment de vérifier le site.

Où trouver les dates officielles ?

Sur php.net, deux pages complémentaires : les versions supportées avec leurs échéances, et la liste des versions en fin de vie avec leur date de retrait. Les deux sont citées ci-dessous.

Sources

Et sur votre site ?

Une définition ne dit pas si vous êtes concerné.

L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.