Si votre hébergeur vous annonce la fin de PHP 7.4, 8.0 ou 8.1, voici l'ordre à suivre : sauvegarder le site, mettre à jour WordPress ou Joomla, le thème et les extensions, tester le site sur une copie en PHP 8.3, puis seulement changer la version chez l'hébergeur et vérifier les formulaires. Comptez une à deux heures pour un site vitrine, une demi-journée pour une boutique. Ces trois branches de PHP n'ont plus de correctif de sécurité : PHP 7.4 depuis le 28 novembre 2022, PHP 8.0 depuis le 26 novembre 2023, PHP 8.1 depuis le 31 décembre 2025. PHP 8.2 suivra le 31 décembre 2026. Dates vérifiées le 9 novembre 2026 sur php.net et les pages d'aide des hébergeurs.
Je fais ces mises à jour à distance depuis octobre 2026, pour des artisans, des cabinets, des associations et des TPE. Le cas type : un site construit entre 2015 et 2019, jamais mis à jour, et un prestataire qui ne répond plus.
Pourquoi votre hébergeur vous écrit maintenant
PHP est le langage qui fait tourner WordPress et Joomla. Chaque version vit quatre ans, dont deux de corrections de sécurité seulement. Ensuite, plus rien. Au 9 novembre 2026, le projet PHP ne suit plus que 8.2 et 8.3, en sécurité seulement, et 8.4 et 8.5. PHP 8.2 s'arrête le 31 décembre 2026 ; j'y ai consacré un article à part.
Deux choses ont accéléré les mails cet automne : la fin de PHP 8.1 le 31 décembre 2025, puis les deux failles critiques du 21 octobre 2026, qui permettent d'exécuter du code à distance. Le projet PHP a publié des correctifs ce jour-là pour 8.2.35, 8.3.36, 8.4.27 et 8.5.12, et pour rien d'autre ; un site en 7.4, 8.0 ou 8.1 n'a rien reçu. J'ai détaillé cet épisode dans mon article sur la faille PHP d'octobre 2026. Les hébergeurs qui ne veulent pas porter ce risque ferment les anciennes branches, ou les font payer.
Comment lire le mail de votre hébergeur
Cherchez trois informations : la version concernée, la date à laquelle elle sera retirée ou facturée, et ce que l'hébergeur fera lui-même. Ce dernier point change tout. Pages d'aide relues le 9 novembre 2026.
Chez OVHcloud, la page « Versions disponibles des langages », mise à jour le 27 octobre 2026, classe PHP 8.1 en fin de vie depuis le 31 décembre 2025 et marque les versions 8.0 à 5.3 « Migration recommandée ». Elles restent listées, sans bascule automatique ni date de retrait annoncée, et la compatibilité du site reste votre responsabilité. Mon guide OVHcloud montre où changer la version.
Chez IONOS, la page d'aide « PHP Extended Support » décrit un service payant qui démarre dès la fin du support communautaire : IONOS corrige lui-même les anciennes versions, de PHP 5.6 à 8.2, et facture un montant mensuel, non indiqué sur la page, après une période de transition gratuite annoncée par mail. On l'arrête en passant sur une version supportée, puis en résiliant l'option. Voir mon guide IONOS.
Chez Hostinger, l'article d'aide indique que les versions 8.1 et antérieures ne sont plus proposées dans le panneau, que les nouveaux sites démarrent en PHP 8.3, et qu'un site en place garde sa version jusqu'à ce que vous la montiez. Le retour arrière n'est pas possible, sauf dans la même session. Voir mon guide Hostinger.
Chez Infomaniak, la FAQ « Modifier la version de PHP d'un site », mise à jour le 2 novembre 2026, indique que les correctifs du 21 octobre ont été déployés de PHP 7.4 à 8.5, numéros de version inchangés. C'est, avec l'option payante d'IONOS, le seul cas de cette liste où une ancienne branche reçoit encore des correctifs. Infomaniak recommande malgré tout une version récente, et prévient qu'il n'y a pas de retour vers une version vulnérable. Voir mon guide Infomaniak.
Chez o2switch, la page « Sélectionner une version de PHP », mise à jour le 23 juin 2026, liste encore PHP 4.4 à 8.5 dans le sélecteur de cPanel, sans rien dire du retrait des anciennes versions ni de correctifs. Voir mon guide o2switch et celui pour PlanetHoster.
Vérifiez la version réellement servie par votre site
Le mail parle de l'offre, pas forcément de votre site. Dans WordPress, allez dans Outils, Santé du site, onglet Informations, section Serveur. Dans Joomla, Système, puis Informations système. Sans accès, mon outil Faille PHP, vérifier mon site lit la version que votre site annonce et reconnaît l'hébergeur, sans rien installer.
Un piège : un fichier .htaccess ou .ovhconfig oublié dans un dossier peut servir une autre version que celle du panneau. La version servie fait foi, et je la vérifie avant de chiffrer.
Ce que WordPress et Joomla attendent au 9 novembre 2026
WordPress.org recommande PHP 8.3 ou plus, et précise que WordPress fonctionne encore avec PHP 7.4, version en fin de vie qui peut exposer le site. « Fonctionne encore » n'est pas « protégé ».
Joomla est plus strict. Joomla 5.4 exige PHP 8.1.0 et recommande 8.3 ; la branche 5 n'a plus que des correctifs de sécurité, jusqu'au 12 octobre 2027. Joomla 6, sorti le 14 octobre 2025, exige PHP 8.3.0 et recommande 8.4. Un Joomla 3 ou 4 est hors support depuis le 14 octobre 2025 au plus tard : il faut le migrer avant de parler de PHP.
Ce qui casse le plus souvent au passage de PHP 7 à PHP 8
Changer de version ne touche ni vos textes ni vos images : cela change les règles que le code du thème et des extensions doit respecter. Trois familles de problèmes reviennent, toutes documentées dans les guides de migration de php.net.
Les fonctions supprimées. PHP 8.0 a retiré create_function(), each() et money_format(), encore présentes dans des thèmes et des extensions anciens. Appeler une fonction qui n'existe plus provoque une erreur fatale : la page blanche. Plus ancien, PHP 7.0 a retiré l'extension mysql, et un site de 2015 avec du code maison tombe dessus en premier.
Les comparaisons. En PHP 8, « 0 == 'texte' » est faux alors qu'il était vrai en PHP 7, et un calcul sur une chaîne non numérique lève une erreur au lieu d'un avertissement.
Les avertissements de dépréciation. PHP 8.1 signale le passage de null à une fonction interne ; PHP 8.2 signale les propriétés dynamiques, l'écriture « ${variable} » dans une chaîne et utf8_encode(). Rien de fatal, mais si l'affichage des erreurs est actif, les messages s'impriment en haut des pages et peuvent casser les redirections. Derrière tout cela, il y a presque toujours une extension abandonnée depuis des années, à remplacer.
Dans quel ordre agir pour ne pas finir sur une page blanche
La page blanche après un changement fait « au cas où », sans sauvegarde ni test, est le dépannage que je vois le plus souvent. L'ordre compte plus que la technique.
D'abord une sauvegarde complète, fichiers et base de données, stockée ailleurs que sur l'hébergement. Ensuite les mises à jour de WordPress ou Joomla, du thème et des extensions, dans la version de PHP actuelle. Puis le tri : une extension désactivée depuis deux ans se supprime. Puis le test sur une copie du site avec la version cible, sous-domaine ou serveur de test : c'est là que les fonctions supprimées se révèlent, pas en production. Seulement après, le changement de version sur le vrai site, puis la vérification des pages clés : accueil, formulaires, paiement, administration. Mon outil Tester mon site fait huit contrôles rapides de la page d'accueil, dont la version de PHP ; il ne remplace pas le test manuel des formulaires.
Le test sur copie n'est pas un luxe : chez Infomaniak, pas de retour vers une version vulnérable ; chez Hostinger, seulement dans la même session.
Faire soi-même, demander à l'hébergeur ou passer par un développeur ?
Faites-le vous-même si le site est un WordPress récent, à jour, avec moins d'une dizaine d'extensions, et si vous savez restaurer votre sauvegarde. Le changement prend quelques minutes dans le panneau de l'hébergeur, et WordPress.org fournit un guide « Mettre à jour PHP » avec un module de vérification de compatibilité, imparfait de leur propre aveu.
Demandez à l'hébergeur quand le blocage est de son côté : version absente du panneau, option payante à résilier. L'hébergeur change la version. Il ne met pas à jour votre thème, ne remplace pas une extension abandonnée et ne corrige pas votre code.
Passez par un développeur si le site date de 2015-2019 et n'a pas bougé depuis, si votre prestataire a disparu, si le thème est sur mesure, si c'est une boutique, ou si vous n'avez pas de sauvegarde dont vous êtes sûr.
Comment je procède, à distance, depuis octobre 2026
Vous m'envoyez l'adresse du site. Sous 24 heures, vous recevez un diagnostic écrit et gratuit : version de PHP réellement servie, plateforme, hébergeur. Ensuite, je récupère les accès, je fais une sauvegarde complète hors serveur et je travaille sur une copie. Je mets à jour WordPress ou Joomla, le thème et les extensions, je passe la copie en PHP 8.3 ou 8.4 et je corrige ce qui remonte. Quand la copie est propre, je change la version sur le site réel, je teste les formulaires, le paiement et les pages principales, et je vous envoie un compte rendu écrit : ce qui a été fait, ce qui reste à surveiller. Rien n'est modifié avant votre accord écrit sur le prix, et le site n'est jamais coupé sans vous prévenir.
Questions fréquentes
Qui peut mettre à jour la version de PHP de mon site ? Vous, depuis le panneau de votre hébergeur, si vous avez les accès et une sauvegarde. Le support de l'hébergeur, pour le seul changement de version. Un développeur web, pour l'ensemble : mises à jour du site, tests, correction de ce qui casse. L'agence ou le freelance qui a créé le site est le premier à appeler ; s'il ne répond plus, n'importe quel développeur PHP peut reprendre un WordPress ou un Joomla à distance.
Mon hébergeur peut-il le faire à ma place ? Il peut changer la version de PHP si vous le lui demandez, ou retirer l'ancienne de son offre. Il ne met pas à jour votre WordPress, votre thème ou vos extensions, et ne répare pas ce qui casse après. OVHcloud écrit que la compatibilité reste à votre charge ; IONOS maintient l'ancienne version contre un abonnement ; Hostinger a retiré 8.1 et antérieures de son panneau.
Mon site fonctionne encore en PHP 7.4, pourquoi changer ? Parce que « fonctionne » et « protégé » sont deux choses différentes. PHP 7.4 n'a reçu aucun correctif de php.net depuis le 28 novembre 2022, et rien pour les failles du 21 octobre 2026. Un site qui s'affiche normalement peut déjà servir à envoyer du spam ou à héberger des pages frauduleuses.
Quelle version de PHP choisir en novembre 2026 ? PHP 8.3 au minimum, 8.4 si votre thème et vos extensions l'acceptent. WordPress.org recommande 8.3 ou plus, Joomla 6 l'exige. PHP 8.2 fonctionne encore, mais ne recevra plus rien après le 31 décembre 2026 : vous referiez l'opération en janvier.
Que faire si mon site affiche une page blanche après le changement ? Repassez à l'ancienne version depuis le panneau si c'est encore possible : le site revient. Puis lisez le journal d'erreurs de l'hébergement : la première ligne nomme le fichier fautif, presque toujours une extension ou le thème. Désactivez-le par FTP en renommant son dossier, puis reprenez l'ordre décrit plus haut. Sans sauvegarde, ne touchez à rien d'autre et demandez de l'aide.
Combien de temps et combien ça coûte ? Une à deux heures pour un site vitrine, une demi-journée pour une boutique, à distance. Mes forfaits publics sont de 190 € pour un site vitrine et de 390 € pour une boutique, diagnostic gratuit compris. Un suivi à 100 € par mois existe pour ceux qui ne veulent plus recevoir ce genre de mail.
Si vous venez de recevoir ce mail, envoyez-moi l'adresse de votre site : le diagnostic est gratuit et arrive par écrit sous 24 heures. Les détails sont sur ma page mise à jour PHP.
