# Que faire quand une version de WordPress ou de PHP arrive en fin de prise en charge

> PHP 7.4 ne reçoit plus aucun correctif de sécurité depuis fin novembre 2022. Ça ne signifie pas qu’un site tournant encore dessus s’arrête de fonctionner du jour au lendemain, mais que toute faille découverte depuis ne sera jamais corrigée par l’éditeur. Le risque augmente avec le temps, silencieusement, sans alerte visible.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/mise-a-jour/fin-de-support-version](https://allaux.fr/wordpress-woocommerce/mise-a-jour/fin-de-support-version)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez Outils, Santé du site : l’onglet Informations donne les versions exactes de PHP, de MySQL et du cœur WordPress, et l’onglet État signale une version de PHP qui ne reçoit plus de correctifs. Relevez ces trois numéros, puis comparez-les aux dates de fin de prise en charge publiées par php.net et par WordPress. Rien ne s’arrête le jour de la fin de vie : c’est le délai avant la prochaine faille qui fixe la priorité.

## Ce que « fin de prise en charge » veut dire concrètement

Une version de PHP ou de WordPress qui atteint sa fin de vie continue de fonctionner exactement comme avant : le code s’exécute, les pages s’affichent, les commandes se passent. Rien ne change visiblement le jour où le support s’arrête. Ce qui change, c’est qu’à partir de cette date, l’éditeur cesse de publier des correctifs de sécurité pour cette version. Toute vulnérabilité découverte après cette date reste ouverte indéfiniment sur les installations qui n’ont pas migré.

PHP 7.4 illustre bien ce mécanisme : plus aucun correctif de sécurité n’est publié pour cette version depuis fin novembre 2022. WordPress continue techniquement de fonctionner avec PHP 7.4, mais la recommandation officielle de WordPress.org est de tourner sur PHP 8.3 ou une version supérieure. Le cœur WordPress lui-même reste utilisable au-delà de la version minimale techniquement supportée, mais rester sur une version ancienne prive le site des correctifs de sécurité publiés pour les versions plus récentes.

Le danger de cette situation est justement son absence de signal. Un site en fin de vie ne plante pas, n’affiche pas d’avertissement, ne ralentit pas. Il continue de fonctionner jusqu’au jour où une faille non corrigée est exploitée, moment où le coût de l’intervention est sans commune mesure avec celui d’une migration planifiée en amont.

## Comment reconnaître une fin de vie qui approche ou déjà dépassée

- Version PHP affichée dans le tableau de bord ou chez l’hébergeur inférieure à la version recommandée par WordPress.org
- Extensions ou thèmes signalant une incompatibilité avec les versions récentes de PHP dans leur documentation
- Notification de l’hébergeur annonçant la fin de la disponibilité d’une version de PHP sur son infrastructure
- Absence de mise à jour de sécurité récente sur une version de WordPress ou de PHP toujours en place
- Aucun incident visible à ce jour, ce qui est précisément le signe qu’aucune vérification n’a encore eu lieu

## Planifier une sortie sans attendre l’incident

1. **Auditer la version réellement utilisée** — Je vérifie la version de PHP effectivement active chez l’hébergeur, pas celle indiquée dans une documentation générale : les deux peuvent diverger, notamment sur des hébergements mutualisés anciens.
2. **Lister ce qui bloque une montée de version** — Je recense les extensions et le thème dont la compatibilité avec une version plus récente de PHP n’est pas confirmée, pour savoir ce qui doit être mis à jour ou remplacé avant de migrer.
3. **Planifier une fenêtre de test** — Je teste la montée de version sur un clone du site avant toute bascule en production, avec suffisamment de marge pour corriger ce qui casse sans pression de délai.
4. **Programmer la migration avant l’urgence** — Je fixe une date de bascule en dehors de toute contrainte de panne, plutôt que d’attendre qu’un incident de sécurité ou une coupure côté hébergeur impose une migration précipitée.
5. **Basculer et surveiller** — Le point de bascule effective vers la nouvelle version est le moment à surveiller de près : une fois le site en production sur la nouvelle version PHP, revenir à l’ancienne demande une intervention à part entière plutôt qu’un simple réglage.

## Fin de vie n’est pas synonyme de panne immédiate

> Un site sur PHP 7.4 continue de fonctionner aujourd’hui. Le risque n’est pas un arrêt brutal mais l’absence de correctif pour toute faille découverte après novembre 2022, un risque qui s’accumule silencieusement tant que rien n’est fait.

## Pour aller plus loin

- **Mettre à jour PHP sous WordPress** — Le détail technique de la montée de version : fonctions dépréciées, extensions incompatibles, méthode de test avant bascule. ([/wordpress-woocommerce/mise-a-jour/php-wordpress](/wordpress-woocommerce/mise-a-jour/php-wordpress))
- **Vérifier la compatibilité des extensions avant une mise à jour** — Comment savoir ce qui bloque la migration avant de démarrer. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **Dupliquer un site WordPress en préproduction** — La méthode pour tester une montée de version PHP sur une copie avant la production. ([/wordpress-woocommerce/migration/dupliquer-en-preproduction](/wordpress-woocommerce/migration/dupliquer-en-preproduction))
- **Choisir un hébergement e-commerce** — Ce qui différencie un hébergeur qui maintient ses versions PHP à jour d’un autre qui ne le fait pas. ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce))

## FAQ

### Mon site tourne encore sur PHP 7.4 et fonctionne normalement, dois-je vraiment migrer ?

Oui, même si rien ne casse aujourd’hui. Depuis fin novembre 2022, aucune faille découverte sur PHP 7.4 n’est plus corrigée. Le fonctionnement actuel ne dit rien du niveau de risque de sécurité accumulé.

### Quelle version de PHP WordPress recommande-t-il aujourd’hui ?

WordPress.org recommande officiellement PHP 8.3 ou une version supérieure, même si le cœur WordPress reste techniquement compatible avec des versions plus anciennes.

### Comment savoir si mon hébergeur propose déjà une version de PHP récente ?

Je vérifie la version active dans le panneau d’administration de l’hébergement ou via une extension de diagnostic WordPress, plutôt que de me fier à la documentation générale de l’offre souscrite, qui peut être différente de la version réellement provisionnée.

### Faut-il attendre qu’une extension signale une incompatibilité pour agir ?

Non, c’est justement l’inverse de l’objectif : attendre l’incident revient à perdre la marge de manœuvre qu’une planification en amont permet. L’audit se fait avant que le problème ne se pose.

### La fin de vie de WordPress lui-même fonctionne-t-elle comme celle de PHP ?

Le principe est similaire : au-delà d’une version, les correctifs de sécurité s’arrêtent. La différence est que WordPress publie des mises à jour de sécurité même sur d’anciennes branches majeures plus longtemps que ne le fait PHP sur ses versions dépassées, ce qui ne dispense pas de planifier une montée de version régulière.