Mis à jour le 9 novembre 2026 : après le 31 décembre 2026, PHP 8.2 ne reçoit plus aucune mise à jour de sécurité : la version devient obsolète, le site continue de tourner, mais plus personne ne le répare. Il reste sept semaines pour passer en PHP 8.3, 8.4 ou 8.5, après une sauvegarde et un test sur une copie. WordPress accepte PHP 8.4 depuis la version 6.7, Joomla 6 exige PHP 8.3 au minimum, et PrestaShop 8 reste bloqué en PHP 8.1 tant que la boutique n'est pas passée en PrestaShop 9.
Le 31 décembre 2026, PHP 8.2 cesse de recevoir des correctifs de sécurité. Ce n'est ni un bug ni une panne : c'est le calendrier du projet PHP, publié depuis des années sur php.net. Mais après la faille PHP d'octobre 2026, cette date prend un autre relief : on a vu ce qui arrive aux versions qui ne sont plus suivies. Rien. Pas de correctif, et un site qui reste ouvert.
Si vous ne lisez qu'un paragraphe : si votre site, votre boutique ou votre logiciel tourne en PHP 8.2 ou plus ancien, prévoyez le passage en PHP 8.3, 8.4 ou 8.5 avant la fin de l'année, après une sauvegarde et un test sur une copie. Commencez par vérifier la version PHP de votre site, la suite vous dit quoi faire chez votre hébergeur.
Ce que « fin de vie » veut dire, concrètement
Chaque version de PHP suit le même cycle, décrit sur la page des versions supportées : deux ans de support complet, où bugs et failles sont corrigés, puis deux ans de support de sécurité, où seules les failles critiques reçoivent un correctif. Après quatre ans, la version n'est plus suivie.
Le 21 octobre 2026, deux failles critiques ont été corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1, en fin de vie depuis le 31 décembre 2025, n'a pas eu de version corrigée : le projet a publié des rustines dans son code source, à charge pour chaque hébergeur de les appliquer ou non. À partir du 1er janvier 2027, PHP 8.2 sera dans cette situation.
Le piège, c'est qu'une fin de vie ne se voit pas. Le site ne s'arrête pas, aucun message ne s'affiche, les commandes continuent d'arriver. Un site en PHP 8.2 fonctionnera le 2 janvier 2027 comme la veille, simplement sans filet.
Selon les sources, on lira que PHP 8.2 est « obsolète », « plus maintenue », « plus supportée » ou « en fin de support ». Ces mots désignent la même chose : la fin des mises à jour de sécurité, le 31 décembre 2026. Une version obsolète n'est pas une version cassée, c'est une version que plus personne ne répare.
Êtes-vous concerné ? Comment connaître votre version
L'outil que j'ai publié lors de la faille d'octobre lit l'en-tête de votre page d'accueil et vous dit quelle version votre serveur annonce : vérifier la version PHP de votre site. Il ne voit rien si votre hébergeur masque cette information, mais c'est la première chose à essayer.
Si vous avez WordPress, ouvrez Outils, puis Santé du site, onglet Informations, section Serveur : la ligne « Version de PHP » donne la version réellement utilisée par votre site, pas celle affichée par l'hébergeur pour l'ensemble du compte. Enfin, l'espace client de votre hébergeur affiche la version active par domaine ; les guides pas à pas sont plus bas.
Le calendrier des versions, vérifié le 28 octobre 2026
Dates lues le 28 octobre 2026 sur la page des versions supportées de php.net et sa page des fins de vie.
PHP 8.1 et plus ancien : fin de vie. PHP 8.1 n'est plus suivi depuis le 31 décembre 2025 (dernière version 8.1.34), PHP 8.0 depuis le 26 novembre 2023, PHP 7.4 depuis le 28 novembre 2022. Si votre site tourne dans l'une de ces versions, vous n'anticipez pas une échéance : vous êtes déjà sans correctif.
PHP 8.2 : support de sécurité jusqu'au 31 décembre 2026. Sortie le 8 décembre 2022, hors support complet depuis le 31 décembre 2024. Elle a reçu le correctif d'octobre ; ce sera l'un des derniers.
PHP 8.3 : support de sécurité jusqu'au 31 décembre 2027. Sortie le 23 novembre 2023, support complet terminé le 31 décembre 2025. Passer en 8.3 donne un an de tranquillité, pas plus.
PHP 8.4 : support complet jusqu'au 31 décembre 2026, puis sécurité jusqu'au 31 décembre 2028. Sortie le 21 novembre 2024. WordPress recommande 8.3 ou plus, PrestaShop 9.0 et Joomla 6 recommandent 8.4 : le bon compromis entre compatibilité des extensions et durée restante.
PHP 8.5 : support complet jusqu'au 31 décembre 2027, puis sécurité jusqu'au 31 décembre 2029. Sortie le 20 novembre 2025. La plus durable, mais aussi celle avec laquelle le moins d'extensions et de thèmes ont été testés. PrestaShop 9.1 la recommande ; WordPress la prend en charge depuis la version 6.9.
Au 1er janvier 2027, il ne restera donc que trois versions suivies : 8.3, 8.4 et 8.5.
Ce que proposent les hébergeurs
J'ai relu le 28 octobre 2026 la documentation publique de huit hébergeurs. Voici ce qu'elle dit, et ce qu'elle ne dit pas.
OVHcloud. Le guide des versions disponibles, mis à jour le 27 octobre 2026, liste PHP 5.3 à 8.5 avec ses propres dates de retrait : 30 juin 2029 pour PHP 8.4, 30 juin 2030 pour PHP 8.5, « à déterminer » pour 8.2 et 8.3, « migration recommandée » pour 8.1 et plus ancien. Aucun frais n'est mentionné. Voir le guide OVHcloud.
o2switch. La page du sélecteur de version PHP, datée du 23 juin 2026, liste PHP 4.4 à 8.5 ; la version « native », appliquée par défaut, y est PHP 8.1. Pas de frais ni de retrait mentionnés. Voir le guide o2switch.
IONOS. C'est le cas particulier. Les versions récentes sont gratuites et la page du changement de version recommande PHP 8.4. Mais les versions abandonnées par le projet PHP, de 5.6 à 8.1, passent sous « Support Prolongé PHP », facturé chaque mois après une période de transition gratuite ; le montant n'est pas publié. PHP 8.1 y est entrée le 31 décembre 2025 ; sauf changement de politique, PHP 8.2 suivra le 31 décembre 2026. Après migration, l'option doit être résiliée explicitement. Voir le guide IONOS.
Hostinger. L'article d'aide, mis à jour le 27 octobre 2026, ne propose plus que PHP 8.2 à 8.5 ; 8.1 et plus ancien ont disparu du sélecteur, et 8.3 est la version par défaut. Voir le guide Hostinger.
Infomaniak. La FAQ sur le changement de version, mise à jour le 27 octobre 2026, indique que les correctifs d'octobre ont été déployés pour PHP 7.4 à 8.5, sans changement de numéro : Infomaniak a appliqué le correctif aux anciennes versions. Liste par offre et frais : non publiés. Voir le guide Infomaniak.
PlanetHoster. La base de connaissances explique comment choisir la version dans une liste déroulante de N0C, mais ne publie ni la liste des versions, ni date de retrait, ni frais. Le guide PlanetHoster montre où cliquer.
Gandi. La documentation PHP indique seulement que l'installation automatique de WordPress fonctionne en PHP 8.1, 8.2 et 8.3 ; la liste complète n'est pas publiée.
LWS. L'article d'aide sur cPanel, daté du 30 décembre 2025, liste PHP 5.6 à 8.5 comme « actuellement disponibles ». Pas de frais ni de retrait annoncés.
En résumé : seul IONOS facture le maintien d'une version en fin de vie, Hostinger a retiré les anciennes versions du choix, les autres les laissent accessibles sans s'engager à les corriger. Garder PHP 8.2 après le 31 décembre reste votre décision, et votre risque.
Quoi faire avant le 31 décembre : quatre étapes
1. Sauvegarder
Fichiers et base de données, les deux, dans une sauvegarde que vous savez restaurer. Celle de l'hébergeur compte, si vous savez où elle est et comment la restaurer.
2. Tester sur une copie
Chez la plupart des hébergeurs, on peut créer un sous-domaine, y copier le site et lui attribuer une autre version de PHP sans toucher au site principal. Sur la copie, passez en PHP 8.4, puis parcourez les pages qui comptent : accueil, formulaire de contact, fiche produit, panier, paiement, espace client, export comptable. Notez ce qui casse.
3. Changer de version
Une fois la copie validée, changez la version sur le site réel, dans l'espace client de l'hébergeur, à un moment creux. Si vous venez de PHP 7, ne sautez pas directement en 8.5 : c'est entre 7.4 et 8.0 que se trouvent la plupart des ruptures, traitez cette marche à part.
4. Vérifier
Refaites le tour des pages clés, vérifiez que les commandes de test, les e-mails et les tâches planifiées passent, et surveillez le journal des erreurs PHP quelques jours. Si le site ne répond plus du tout, revenez à la version précédente, et assurez-vous que le problème vient bien de chez vous : votre hébergeur est-il en panne ? La page affiche en direct l'état des principaux hébergeurs : regardez-la avant d'appeler le support.
Ce qui casse souvent
Une extension ou un thème abandonné. Une extension WordPress sans mise à jour depuis deux ans a rarement été testée en PHP 8.4. Regardez la date de dernière mise à jour de chaque extension active ; celles qui datent sont à remplacer, pas à espérer.
Le passage de PHP 7 à PHP 8. PHP 8 est plus strict : des opérations tolérées en 7.4 lèvent une erreur fatale, et plusieurs fonctions anciennes ont disparu. Un logiciel métier écrit en 2018 et jamais retouché a presque toujours quelques lignes à corriger. Ça se fait, mais sur une copie.
Le logiciel lui-même a une version maximale. PrestaShop 8 s'arrête à PHP 8.1 : une boutique PrestaShop 8 ne peut pas passer en 8.2 ou plus sans migrer vers PrestaShop 9, qui accepte 8.1 à 8.4 et recommande 8.5 dans sa version 9.1. Joomla 6 exige PHP 8.3 au minimum, Laravel 12 demande PHP 8.2 ou plus. Vérifiez la version de votre application avant celle de PHP.
Et si votre site tourne sous Joomla ?
Après WordPress, Joomla est le cas que je rencontre le plus souvent, et le plus daté : beaucoup de sites Joomla ont été construits entre 2012 et 2018 et affichent aujourd'hui, dans leur administration, l'avertissement qui demande de prévoir une mise à niveau de PHP. Les règles sont simples. Joomla 4 n'est plus suivi depuis octobre 2025. Joomla 5 reçoit des correctifs jusqu'en octobre 2027 et tourne très bien en PHP 8.3. Joomla 6, la version actuelle, exige PHP 8.3 au minimum et refuse de s'installer en PHP 8.2.
L'ordre qui marche, celui que j'ai suivi début novembre 2026 sur un site Joomla de 750 pages : sauvegarde complète, copie de test en PHP 8.3, dernière version de Joomla 5 et mises à jour des extensions, puis PHP 8.3 sur le site en ligne, puis Joomla 6 le même jour, toutes les pages comparées avant et après. Deux points méritent un vrai test sur la copie : le modèle graphique, surtout s'il a été créé pour Joomla 2.5 ou 3, et les extensions de formulaire. Un modèle de 2015 est passé avec sept lignes modifiées ; ChronoForms 7 fonctionne sous Joomla 6 avec un correctif d'une ligne, même si son éditeur ne l'annonce que pour la version 8.
Ce que je propose pour un site Joomla, prix compris, est sur la page de mise à jour de votre site Joomla.
Questions fréquentes
Mon site marche encore, pourquoi changer ?
Parce qu'il marchera aussi le jour où une faille sera publiée, et que personne ne la corrigera. En octobre, les sites en PHP 8.1 ont attendu un correctif que seuls certains hébergeurs ont appliqué ; après le 31 décembre, PHP 8.2 est dans ce cas. Un site qui fonctionne et un site protégé sont deux choses différentes.
PHP 8.3, 8.4 ou 8.5 ?
Pour un site ou une boutique classique, PHP 8.4 : suivie jusqu'au 31 décembre 2028, acceptée par WordPress, PrestaShop 9 et Joomla 6, avec deux ans de recul sur les extensions. PHP 8.3 est un choix de transition quand une extension bloque, à refaire fin 2027. PHP 8.5 se justifie quand vous maîtrisez le code de l'application, ou quand votre logiciel la recommande, comme PrestaShop 9.1.
Mon hébergeur ne propose pas PHP 8.4
Parmi les hébergeurs dont j'ai pu lire la liste, OVHcloud, o2switch, Hostinger, Infomaniak et LWS proposent PHP 8.4 et 8.5, et IONOS recommande 8.4 ; PlanetHoster et Gandi ne publient pas leur liste. Si la version manque dans votre espace client, demandez par écrit au support si elle est prévue et quand. Si la réponse est non ou floue, un hébergeur sans PHP 8.4 fin 2026 ne vous suivra pas sur les prochaines échéances : un déménagement se prépare mieux maintenant qu'en urgence.
Combien ça coûte ?
Vous-même : une demi-journée pour un site vitrine sans surprise, sauvegarde et vérifications comprises. Si vous préférez déléguer, mes prix sont sur la page de mise à jour PHP de votre site, boutique ou logiciel : diagnostic gratuit, 190 € pour un site vitrine WordPress, 390 € pour une boutique ou un site chargé en extensions, à partir de 690 € pour un logiciel métier qui demande des corrections dans le code, et 100 € par mois pour que je suive les versions à votre place. Prix nets.
WordPress et PHP 8.4 sont-ils compatibles ?
Oui. La page des prérequis de WordPress recommande « PHP 8.3 ou supérieur », et le tableau de compatibilité de l'équipe WordPress, mis à jour le 19 août 2026, indique PHP 8.4 pris en charge depuis WordPress 6.7 et PHP 8.5 depuis WordPress 6.9. La question n'est donc pas WordPress, mais vos extensions et votre thème.
Que se passe-t-il le 1er janvier 2027 si je ne fais rien ?
Rien de visible, et c'est le problème. Le site s'affiche, les formulaires partent, la boutique encaisse. Mais PHP 8.2 est devenue obsolète : la prochaine faille, et il y en a chaque année, ne sera corrigée que dans les versions 8.3, 8.4 et 8.5. Vous découvrirez le problème le jour où un robot l'exploitera, ou quand votre hébergeur coupera les anciennes versions, comme Hostinger l'a déjà fait pour PHP 8.1.
Je ne suis pas technicien : que faire avant le 31 décembre ?
Trois choses, dans l'ordre. Vérifier la version de votre site : une minute, sans compte. Demander à la personne qui s'occupe de votre site, ou à votre hébergeur, quelle version elle recommande et si une copie de test est possible. Puis faire faire le changement avant la fin de l'année, avec une sauvegarde que vous savez restaurer. Si personne ne s'en occupe, c'est exactement ce que je fais, à prix fixe et avec un compte rendu.
Joomla et PHP 8.3 : faut-il passer à Joomla 6 en même temps ?
Oui, si votre site est en Joomla 5 : Joomla 6 exige PHP 8.3, les deux changements se testent sur la même copie et se font le même jour. Si votre site est encore en Joomla 4, qui n'est plus suivi depuis octobre 2025, passez d'abord en Joomla 5, puis en 6. Dans les deux cas, le modèle graphique et les extensions de formulaire se vérifient avant, sur la copie, pas après.
Avant la fin de l'année
Le 31 décembre 2026 n'est pas une surprise : la date est publiée sur php.net depuis la sortie de PHP 8.2. Ce que la faille d'octobre a changé, c'est la compréhension de ce qu'elle implique. Deux mois suffisent pour sauvegarder, tester sur une copie, changer de version et vérifier, sans se presser.
Commencez par vérifier la version PHP de votre site. Et si vous préférez que quelqu'un s'en charge, de la sauvegarde au compte rendu, la mise à jour PHP de votre site, boutique ou logiciel commence par un diagnostic gratuit : envoyez-moi l'adresse de votre site, je vous dis ce que je vois et ce que je propose.
