Le 31 décembre 2026, PHP 8.2 cesse d'être maintenu. Le 1er janvier, votre site continuera de fonctionner exactement comme la veille. Aucune page blanche, aucun message d'alerte, aucun courriel de votre hébergeur. C'est précisément ce qui rend cette échéance facile à ignorer, et coûteuse à ignorer.
PHP est le langage qui fait tourner WordPress sur votre serveur. Chaque fois qu'un visiteur demande une page, c'est un programme PHP qui assemble le contenu depuis la base de données. Quand une version du langage arrive en fin de vie, elle ne s'arrête pas : elle cesse simplement de recevoir des correctifs. Le code déjà en place reste identique, y compris ses défauts.
Nous avons déjà expliqué pourquoi tourner sur une version dépassée est un problème dans notre article sur PHP obsolète. Le présent article ne refait pas cette démonstration : il traite le calendrier et la façon de tenir l'échéance en quatre mois sans casser un site en production.
Le calendrier, sans approximation
Chaque version de PHP suit un cycle en deux temps. Elle reçoit d'abord des corrections de bogues et des correctifs de sécurité, c'est le support actif. Elle passe ensuite en support de sécurité seule, où seules les failles sont traitées. Puis elle sort du support.
Les dates sont publiques et fixées à l'avance. PHP 8.1 est sortie du support le 31 décembre 2025. PHP 8.2 en sort le 31 décembre 2026, et elle est aujourd'hui en support de sécurité seule. PHP 8.3 suivra fin 2027, PHP 8.4 fin 2028, PHP 8.5 fin 2029. À l'heure actuelle, seules 8.4 et 8.5 bénéficient encore du support actif.
Deux conséquences pratiques en découlent. Si votre site tourne encore en 8.1, vous accumulez depuis huit mois des vulnérabilités qui ne seront jamais corrigées, et l'échéance n'est pas dans quatre mois mais déjà derrière vous. Si vous êtes en 8.2, vous disposez d'une fenêtre confortable, à condition de ne pas la consommer entièrement.
Compatible ne veut pas dire supporté
C'est la nuance qui désarme la plupart des vérifications maison, et elle tient à une formule du guide officiel destiné aux hébergeurs.
WordPress annonce sa compatibilité avec des versions de PHP largement sorties du support, en précisant que cette compatibilité est maintenue à titre de rétrocompatibilité uniquement. La version 7.1 recommande PHP 8.4 ou 8.5 pour une nouvelle installation, tout en restant techniquement installable sur des versions bien plus anciennes.
Traduit en clair : WordPress ne vous empêchera pas de tourner sur un interpréteur qui ne reçoit plus de correctifs, et l'outil de santé du site ne poussera pas d'alerte rouge le 1er janvier. Le tableau de bord affichera un site en bonne santé, hébergé sur un composant que plus personne ne répare. C'est une situation que nous rencontrons régulièrement en reprise de site, sujet que nous abordons dans notre article sur la reprise d'un site orphelin.
Viser 8.4 plutôt que 8.5, dans la plupart des cas
La question suivante est celle de la cible, et la réponse la plus courante n'est pas la version la plus récente.
PHP 8.4 est en support actif jusqu'à la fin de 2028, elle a plusieurs versions correctives derrière elle, et l'écosystème d'extensions WordPress la pratique depuis longtemps. C'est le choix par défaut raisonnable pour un site vitrine ou une boutique en production : trois ans de tranquillité et un risque de compatibilité faible.
PHP 8.5 est également un bon choix, avec un horizon repoussé à fin 2029, si deux conditions sont réunies : votre hébergeur la propose, et vos extensions la déclarent compatible. L'usage veut que l'on attende quelques versions correctives avant d'adopter la dernière-née sur un site qui génère du chiffre d'affaires. Sur un site que nous mettons en ligne aujourd'hui, nous partons volontiers en 8.5 ; sur un site existant chargé d'extensions, nous visons 8.4.
À l'inverse, passer de 8.2 à 8.3 est un mauvais calcul. Vous gagnez douze mois et vous refaites le même travail de test l'année prochaine, pour un effort quasi identique. Autant franchir le pas une seule fois.
Ce qui casse en pratique
L'expérience de ces migrations livre toujours le même classement, et il est rassurant sur un point.
Le cœur de WordPress ne pose pas de problème. Il est testé sur toutes les versions supportées avant chaque publication, et un site à jour passe sans incident. Le thème officiel non plus.
Ce qui casse, c'est d'abord une extension abandonnée qui appelle une fonction retirée du langage. Le symptôme est net : une erreur fatale sur une page précise, souvent une page de formulaire, une galerie ou un module de réservation. Ensuite vient le code sur mesure ajouté dans le thème il y a plusieurs années par un prestataire qui n'est plus joignable. Si ce code a été écrit directement dans les fichiers du thème plutôt que dans un thème enfant, il faut le retrouver avant de le corriger, et c'est ce que nous décrivons dans notre article sur le thème enfant.
Ces deux catégories se détectent en une heure de test, alors qu'elles coûtent une journée si on les découvre en production un lundi matin.
Comment tenir l'échéance en quatre mois
Le déroulé que nous appliquons tient en cinq étapes, et la bascule elle-même est la plus courte.
- Relever l'existant. La version de PHP en service figure dans l'outil de santé du site, dans les informations du serveur. Notez-la, ainsi que la liste des extensions actives et la date de leur dernière mise à jour publiée.
- Trier les extensions. Une extension dont la dernière mise à jour a plus de deux ans est un candidat au remplacement, indépendamment de PHP. C'est le bon moment pour faire ce ménage, parce que vous allez de toute façon tester.
- Tester sur une copie de recette. Vous dupliquez le site sur une adresse non publique, vous y basculez la version de PHP, puis vous parcourez les pages qui traitent des données : formulaires, panier, espace client, recherche. La méthode est détaillée dans notre article sur l'environnement de test WordPress.
- Basculer en production. Chez la plupart des hébergeurs, c'est un menu déroulant dans le panneau d'administration. L'opération prend une minute et se défait aussi vite si nécessaire.
- Surveiller le journal d'erreurs. Pendant quelques jours, les erreurs résiduelles apparaissent là avant d'être signalées par un visiteur.
Un mot sur le calendrier : ne visez pas décembre. C'est le mois des congés, des clôtures d'exercice et, pour une boutique, du pic de commandes. Une migration technique se planifie en septembre ou en octobre, quand une régression peut être corrigée sans que la journée entière soit compromise.
Ce que couvre le contrat
Sur les sites que nous suivons, ce suivi de version fait partie de la routine et non d'un projet distinct. Nous tenons l'inventaire des versions en service, nous signalons les échéances avant qu'elles ne tombent, nous menons les tests sur copie et nous programmons la bascule avec vous.
Ce périmètre correspond à la maintenance WordPress à 500 HT / an : supervision, sauvegardes, mises à jour et rapport mensuel. Sur un site dont personne ne connaît plus l'état, nous commençons par un audit, et une base de création vitrine démarre à 1490 HT si la refonte se révèle plus sage que la réparation, arbitrage détaillé dans notre article sur refondre ou corriger son site. Nous intervenons à distance, partout en France et en Suisse. Les dates de support figurent dans le guide officiel des environnements serveur.
À retenir
PHP 8.2 sort du support le 31 décembre 2026 et rien ne se passera ce jour-là, ce qui est exactement le problème. Visez 8.4 pour un site existant, 8.5 pour une mise en ligne récente, sautez 8.3 qui ne vous achète qu'une année. Testez sur une copie avant de basculer, faites-le en automne plutôt qu'en décembre, et profitez du passage pour retirer les extensions que plus personne ne maintient.
Si vous ne savez pas sur quelle version tourne votre site, envoyez-nous son adresse. Nous vous répondrons avec la version en service et les points à traiter avant la fin de l'année.