Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

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.

Décrire mon problème Discuter sur WhatsApp

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.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

D’où partez-vous ?
Quelle est la taille du catalogue, s’il y a une boutique ?
Le site utilise-t-il des extensions payantes avec licence à retransférer ? (facultatif)

Certaines licences sont limitées à un domaine ou nécessitent une réactivation auprès de l’éditeur.

Qu’est-ce qui doit impérativement être conservé ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

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.

Pages liées