Attention au faux repère « PHP 8.1 minimum »
Pourquoi un site WordPress ne passe pas tout seul à une version récente de PHP ?
Le vrai point faible, ce sont vos extensions et vos thèmes WordPress
Les développements sur mesure, le poste qui coûte cher
Combien coûte réellement cette mise à niveau depuis mon site WordPress en PHP 7 ?
Ce qu’il faut demander à votre webmaster dès maintenant concernant votre site WordPress en PHP 7
Questions fréquentes sur la fin du support PHP 7 sur WordPress
Si votre site WordPress tourne depuis quelques années sans que personne n’ait touché au code, il y a de bonnes chances qu’il repose sur PHP 7, une version qui ne reçoit plus le moindre correctif de sécurité. Le sujet paraît technique et lointain. Il ne l’est pas. La fin de vie de PHP 7 sur WordPress est une échéance serveur bien réelle, qui va bientôt forcer la main à des milliers de sites. Et ceux qui n’auront pas été audités avant risquent la panne, la page blanche, ou pire, la faille non corrigée.
Voici ce qui se passe, pourquoi cela concerne directement votre site WordPress sous PHP 7, et ce que vous devez demander à votre webmaster sans attendre.
Ce qui change côté serveur
La plupart des sites français sont hébergés sur des serveurs Linux, très souvent sous Debian. Or Debian 11 « Bullseye », encore massivement utilisé, cesse d’être maintenu le 31 août 2026. Passé cette date, aucun correctif de sécurité n’est publié pour ce système, quelle que soit la gravité de la faille découverte. Un serveur resté sous Bullseye devient une surface d’attaque figée, que les robots d’attaque scannent en permanence.
La cible de migration logique est Debian 13 « Trixie », la version stable actuelle, sortie en août 2025 et maintenue jusqu’en 2030. Et c’est là que le sujet remonte jusqu’à votre site : chaque version de Debian embarque sa propre version de PHP. Bullseye livrait PHP 7.4. Bookworm (Debian 12) livre PHP 8.2. Trixie livre PHP 8.4. Autrement dit, quand votre hébergeur ou votre prestataire migre le serveur, la version de PHP de votre site WordPress saute plusieurs crans d’un coup.
Un code écrit pour PHP 7.4 ou 8.0 n’a aucune garantie de fonctionner sous PHP 8.4. Certaines fonctions ont été retirées, d’autres se comportent différemment, et des syntaxes autrefois tolérées provoquent désormais des erreurs fatales.
Attention au faux repère « PHP 8.1 minimum »
Beaucoup de communications d’hébergeurs évoquent encore « PHP 8.1 au minimum ». Ce repère est déjà dépassé. PHP 8.1 a atteint sa fin de vie le 31 décembre 2025. Il ne reçoit plus aucun correctif de sécurité depuis cette date, exactement comme PHP 7.4 et 8.0.
Concrètement, en 2026, seules quatre branches de PHP sont encore maintenues : 8.2, 8.3, 8.4 et 8.5. PHP 8.2 s’arrêtera d’ailleurs le 31 décembre 2026. Viser PHP 8.1 aujourd’hui, c’est migrer vers une version qui est déjà morte le jour de la mise en ligne. La bonne cible pour un site WordPress est PHP 8.3 ou PHP 8.4, qui offrent la meilleure compatibilité avec l’écosystème d’extensions tout en restant couvertes plusieurs années. D’ailleurs, si votre site WordPress est en PHP 7, vous aurez ce type d’encart dans votre tableau de bord, recommandant PHP 8.3 à minima pour les sites sous WordPress 7.
Information de mise à jour de la version PHP 7 dans le tableau de bord de WordPress
Ce détail change tout dans la façon d’auditer votre site. Il ne s’agit pas de rendre le code « compatible 8.1 » mais de le rendre solide sur une version encore vivante.
Pourquoi un site WordPress ne passe pas tout seul à une version récente de PHP ?
Le cœur de WordPress est bien tenu. Les versions récentes du CMS gèrent proprement les montées de PHP. Le problème n’est presque jamais WordPress lui-même. Le problème, ce sont les couches que vous avez empilées par-dessus au fil des ans.
Un site WordPress typique, c’est un thème, souvent un thème enfant posé sur un thème parent, plus une dizaine ou une trentaine d’extensions, plus parfois quelques développements réalisés spécialement pour vous. Chacun de ces morceaux contient du code PHP écrit par des gens différents, à des époques différentes, avec des niveaux de maintenance très inégaux. C’est cet ensemble qu’il faut passer au crible, ligne par ligne quand c’est nécessaire.
Le vrai point faible, ce sont vos extensions et vos thèmes WordPress
Quand on ouvre le capot d’un site qui n’a pas été audité, on retrouve presque toujours les mêmes familles d’extensions WordPress, avec des niveaux de risque très variables.
Les extensions du dépôt officiel WordPress.org, encore activement maintenues, sont en général les moins problématiques. Leurs auteurs publient des mises à jour de compatibilité. Encore faut-il vérifier que la dernière version installée déclare bien supporter PHP 8.3 ou 8.4, et pas seulement une version ancienne.
Les extensions et thèmes premium achetés sur des places de marché (ThemeForest, CodeCanyon et autres) demandent une vigilance supplémentaire. Beaucoup exigent une licence à jour pour recevoir les correctifs. Si la licence a expiré, ou si l’auteur a cessé de vendre le produit, vous êtes bloqué sur une version figée, potentiellement incompatible.
Les extensions tierces installées à la main, récupérées hors des circuits officiels, sont une zone grise. Personne ne les met à jour automatiquement, et leur origine est parfois impossible à retracer.
Le cas le plus dangereux reste l’extension abandonnée. Un plugin de galerie, de formulaire, de slider ou de cache qui n’a pas reçu de mise à jour depuis trois ou quatre ans est une bombe à retardement. Son auteur a disparu, le code n’évolue plus, et rien ne le rendra compatible sans intervention humaine. Sur un site un peu ancien, il n’est pas rare d’en compter plusieurs.
Le thème parent et le thème enfant méritent le même examen. Un thème enfant contient souvent du code métier ajouté au fil du temps, dans le fichier functions.php notamment, et ce code n’a jamais été pensé pour PHP 8.4.
Les développements sur mesure, le poste qui coûte cher
C’est le point sur lequel je veux insister, parce que c’est celui qu’on découvre trop tard.
Beaucoup de sites contiennent du code écrit spécialement pour eux : un connecteur vers un logiciel de gestion, un tunnel de réservation, un calculateur de devis, une synchronisation de stock, un import de catalogue, une passerelle vers un CRM ou un ERP. Ces développements sur-mesure ne bénéficient d’aucune mise à jour de compatibilité, par définition. Personne ne va publier un correctif pour un code qui n’existe que chez vous.
Quand ce code a été écrit il y a cinq ou sept ans, pour votre site WordPress sous PHP 7, le faire fonctionner sous PHP 8.4 n’est pas une simple mise à jour. C’est une reprise, parfois une réécriture partielle. Il faut relire les sources, identifier chaque fonction obsolète, tester, corriger, revalider en environnement de préproduction avant de toucher au site en ligne. Et si le prestataire d’origine n’est plus joignable ou si le code n’est pas documenté, il faut d’abord le comprendre avant de le réparer, ce qui allonge encore le travail.
Combien coûte réellement cette mise à niveau depuis mon site WordPress en PHP 7 ?
Les montants dépendent entièrement de ce qu’on trouve sous le capot. Les fourchettes ci-dessous sont indicatives et reflètent ce qu’on observe sur le marché français, pas un tarif fixe.
Un audit de compatibilité seul, qui recense les composants et signale les incompatibilités, se situe souvent entre quelques centaines et un à deux milliers d’euros selon la taille du site. C’est l’investissement le plus rentable, parce qu’il vous dit exactement à quoi vous vous exposez avant de dépenser quoi que ce soit d’autre.
Un site vitrine standard, bâti sur un thème maintenu et des extensions courantes à jour, s’en tire généralement pour un budget modéré : quelques mises à jour, quelques ajustements, des tests. On reste dans l’ordre de grandeur de la journée ou de la poignée de jours de travail.
Un site avec des extensions abandonnées à remplacer, des thèmes anciens à reprendre, ou surtout des développements sur mesure à réécrire, change complètement d’échelle. Là, les budgets se comptent en plusieurs milliers d’euros, et pour les sites les plus complexes, e-commerce lourds, plateformes métier, connecteurs multiples, en dizaines de milliers d’euros. Ce n’est pas une exagération commerciale, c’est le coût réel du temps d’ingénierie nécessaire pour reprendre du code qui n’a pas été conçu pour durer aussi longtemps.
Le message à retenir : un site peut coûter presque rien à faire migrer, ou représenter un chantier significatif. La seule façon de le savoir est l’audit. Découvrir le problème le jour où le serveur bascule et où la page devient blanche est la pire des situations, et la plus chère.
Le calendrier serré
Récapitulons les dates qui comptent. PHP 8.1 est en fin de vie depuis le 31 décembre 2025. Debian 11 s’arrête le 31 août 2026. PHP 8.2 s’arrête le 31 décembre 2026. Debian 13, la cible de migration, impose PHP 8.4.
Ces échéances ne déclenchent pas une panne brutale à la seconde près. Un site sous PHP ancien continue de fonctionner un temps. Le danger est double. D’abord la sécurité : chaque faille découverte après la fin de vie reste ouverte pour toujours, et les attaquants le savent. Une vulnérabilité PHP majeure de 2024, activement exploitée depuis, a servi à déposer des webshells et des mineurs de cryptomonnaie sur des serveurs restés sur d’anciennes versions. Ensuite la bascule serveur : le jour où votre hébergeur migre l’infrastructure vers Debian 13, votre site se retrouve du jour au lendemain sous PHP 8.4, sans préavis technique de votre côté. Si le code n’a pas été préparé, c’est à ce moment que ça casse.
Repousser à l’automne 2026, c’est prendre le risque de se retrouver dans une file d’attente avec tous les autres retardataires, au moment précis où les prestataires seront le plus sollicités.
Ce qu’il faut demander à votre webmaster dès maintenant concernant votre site WordPress en PHP 7 :
Une démarche simple, dans l’ordre :
- Sur quelle version de PHP tourne actuellement le site, et sur quelle version de Debian ou de système est hébergé le serveur.
- Un audit complet des extensions et des thèmes, avec pour chacun sa version, son état de maintenance, et sa compatibilité déclarée avec PHP 8.3 et 8.4.
- La liste des extensions abandonnées ou non maintenues, avec pour chacune une décision : mise à jour, remplacement par un équivalent maintenu, ou suppression.
- L’inventaire des développements sur mesure présents sur le site, thème enfant compris, et pour chacun une évaluation du travail de reprise nécessaire.
- Un chiffrage clair distinguant l’audit, les mises à jour simples, et les reprises de code lourdes.
- Une mise en œuvre et des tests en environnement de préproduction, jamais directement sur le site en ligne.
Si votre prestataire ne peut pas répondre à la première question en quelques minutes, c’est déjà un signal qu’il faut lancer l’audit maintenant.
Questions fréquentes sur la fin du support PHP 7 sur WordPress
Mon site fonctionne très bien aujourd’hui, pourquoi anticiper ?
Parce qu’il fonctionne sur une version de PHP qui ne reçoit plus de correctifs de sécurité et sur un serveur qui va être migré. Tant que rien ne bouge, le site tourne. La panne, ou la faille, arrive au moment de la bascule, sans prévenir.
Est-ce que WordPress lui-même pose problème ?
Rarement. Les versions récentes de WordPress gèrent bien les montées de PHP. WordPress 7 est d’ailleurs compatible avec PHP 8.3 et supérieur. Le risque vient presque toujours des extensions, des thèmes et des développements spécifiques posés par-dessus.
Faut-il viser PHP 8.1 comme le suggèrent certains hébergeurs ?
Non. PHP 8.1 est en fin de vie depuis fin 2025. La cible raisonnable pour un site WordPress en 2026 est PHP 8.3 ou 8.4.
Combien de temps prend un audit ?
De quelques heures à quelques jours selon la taille et l’ancienneté du site. C’est court comparé au temps de remise en état si le problème est découvert après la panne. Dans près de 90% des cas nous rendons nos conclusions sous 24 heures ouvrées.
Combien coûte le portage de mon site WordPress vers PHP 8.3 et plus ?
C’est tout l’objet de l’audit. Nous ne pouvons présager de rien. Si votre webmaster n’a pu le migrer au cours de votre contrat annuel de maintenance, c’est que votre site internet créé avec le CSM WordPress, à été monté à un moment ou un autre avec un ou plusieurs éléments non maintenus par leurs auteurs respectifs. Aussi reprendre le code source à la main, de tel ou tel extension est susceptible de prendre quelques minutes pour les cas les plus simple à quelques jours pour les plus complexes.
Et si mon développeur d’origine a disparu ?
C’est fréquent, et c’est justement pour cela que l’audit compte. Un code sur mesure non documenté et sans auteur joignable doit d’abord être compris avant d’être réparé, ce qui pèse sur le budget. Le savoir à l’avance permet d’anticiper au lieu de subir.