PHP 8.2 en fin de vie au 31 décembre 2026 : préparez dès maintenant la migration de votre site

Le 31 décembre 2026, PHP 8.2 cessera définitivement de recevoir des correctifs de sécurité. Si votre site vitrine tourne encore sur cette version — ou pire, sur une version déjà expirée —, vous disposez de moins de six mois pour agir. Cet article détaille comment identifier votre situation, choisir la bonne version cible et conduire la migration sans interrompre le service.

PHP 8.2 s'arrête le 31 décembre 2026 : ce que cela change concrètement

PHP 8.2 atteint sa fin de vie officielle le 31 décembre 2026. À partir de cette date, l'équipe PHP ne publiera plus aucun correctif, y compris pour les failles critiques : toute vulnérabilité découverte ensuite restera ouverte indéfiniment sur les serveurs qui n'auront pas migré. C'est une échéance ferme, connue à l'avance, et qui concerne aujourd'hui une part très large du parc de sites vitrines français.

Le cycle de vie de PHP est public et régulier. Chaque version majeure bénéficie de deux ans de support actif (corrections de bugs, correctifs de sécurité, versions correctives régulières), puis de deux ans de support de sécurité pendant lesquels seules les failles critiques sont corrigées. Passé ce délai de quatre ans, la version est abandonnée. PHP 8.2 est entré dans sa dernière phase et arrive au terme de ce parcours.

Concrètement, à l'échelle d'un site vitrine, cette date n'a rien de spectaculaire : le 1^er janvier 2027, votre site continuera de s'afficher normalement. C'est précisément ce qui rend l'échéance dangereuse. Rien ne casse, rien n'alerte, aucune page d'erreur ne prévient le dirigeant ou le responsable communication. Le risque est silencieux et progressif : il se matérialise le jour où une faille est publiée et exploitée massivement, souvent plusieurs mois après la date de fin de support.

Le calendrier des versions encore couvertes à ce jour est simple à retenir : PHP 8.3 est supporté jusqu'à fin 2027, PHP 8.4 jusqu'au 31 décembre 2028 et PHP 8.5 jusqu'au 31 décembre 2029. Toute migration décidée en 2026 doit viser l'une de ces trois versions, et de préférence celle qui vous offrira la plus longue tranquillité compatible avec votre CMS.

Pourquoi une version de PHP « qui marche encore » devient un risque

Un site qui fonctionne sur une version de PHP obsolète accumule des vulnérabilités non corrigées, sans aucun signe visible. PHP fait l'objet d'une activité de failles constante — de l'ordre d'une quinzaine de vulnérabilités publiées chaque année ces dernières années. Chacune de celles qui paraîtront après la fin de support restera exploitable en permanence sur les serveurs non migrés, et les attaquants ciblent en priorité les versions abandonnées, précisément parce qu'elles ne seront jamais corrigées.

Le risque ne se limite pas à la sécurité brute. Trois autres effets se cumulent, souvent sous-estimés :

• Le blocage des mises à jour du CMS. WordPress, Drupal, Joomla et PrestaShop relèvent progressivement leur socle PHP minimal. Rester sur une version ancienne finit par empêcher l'installation des dernières versions du CMS et de ses extensions — c'est-à-dire, ironiquement, des correctifs de sécurité eux-mêmes. Vous vous retrouvez alors bloqué sur deux couches obsolètes à la fois.
• Le refus d'hébergement. Les hébergeurs sérieux retirent les versions PHP expirées de leur offre, parfois avec un préavis court. Une bascule imposée par l'hébergeur, subie et non préparée, est le scénario le plus coûteux : elle se solde souvent par une page blanche un lundi matin.
• La non-conformité. La plupart des référentiels de sécurité et des cadres réglementaires exigent l'usage de composants logiciels maintenus. Un composant en fin de vie est traité comme un risque caractérisé lors d'un audit, d'un appel d'offres ou d'une revue de conformité. Pour une entreprise qui répond à des marchés ou dépend de donneurs d'ordre exigeants, le sujet dépasse la technique.

C'est exactement le type de risque que la maintenance préventive doit absorber en amont : identifier l'échéance, planifier la migration et l'exécuter sereinement, plutôt que d'attendre l'incident. Notre contrat de maintenance intègre ce suivi du cycle de vie des composants pour cette raison précise.

Comment savoir quelle version de PHP fait tourner votre site aujourd'hui

La version PHP de votre site se lit en quelques minutes, sans compétence technique particulière, depuis l'administration du CMS ou le panneau de votre hébergeur. C'est la première chose à vérifier avant toute décision : beaucoup d'entreprises découvrent à cette occasion qu'elles tournent sur une version expirée depuis plusieurs années, y compris sur des sites récents ou refondus.

Trois chemins d'accès, du plus simple au plus technique :

• Depuis le back-office du CMS. WordPress affiche la version PHP dans Outils > Santé du site > Informations > Serveur. Joomla la donne dans Système > Informations système. Drupal l'indique dans Rapports > Rapport d'état. PrestaShop la présente dans Paramètres avancés > Informations.
• Depuis le panneau de l'hébergeur. La quasi-totalité des hébergeurs mutualisés proposent un sélecteur de version PHP par domaine ou par répertoire. C'est aussi l'endroit où vous constaterez si plusieurs versions cohabitent sur un même compte, cas fréquent et source de confusion.
• Depuis le serveur. Sur un serveur dédié ou virtuel, la commande php -v renvoie la version en ligne de commande — attention, elle peut différer de la version réellement utilisée par le serveur web, qui est la seule qui compte pour votre site.

Une précision utile : la version affichée par le CMS est celle vue par le site, c'est donc la référence à retenir. Si vous gérez plusieurs sites, ne vous fiez jamais à une extrapolation. Nous constatons régulièrement, lors d'un audit de site web, des écarts importants entre sites d'un même parc, y compris chez le même hébergeur : un site migré, deux oubliés, un quatrième figé sur une version que l'hébergeur ne propose officiellement plus.

Vers quelle version migrer : PHP 8.3, 8.4 ou 8.5 ?

PHP 8.4 constitue aujourd'hui le meilleur compromis pour la majorité des sites vitrines : supportée jusqu'au 31 décembre 2028, elle offre près de deux ans et demi de tranquillité tout en étant largement prise en charge par les CMS et les hébergeurs. PHP 8.3 ne fait gagner qu'une année et ne se justifie que par une contrainte de compatibilité avérée. PHP 8.5, la plus récente, allonge l'horizon jusqu'à fin 2029 mais demande de vérifier la maturité de l'écosystème d'extensions.

Le critère décisif : ce que supporte réellement votre CMS

Le choix ne se fait pas dans l'absolu, mais en croisant trois contraintes : la version cible supportée par votre CMS, celles proposées par votre hébergeur, et la compatibilité de vos extensions et de votre thème. Quelques repères pour les quatre CMS que nous maintenons :

• Drupal. Drupal 10 exige PHP 8.1 au minimum, Drupal 11 requiert PHP 8.3 et les versions récentes de la branche 11 recommandent PHP 8.4. C'est l'écosystème le plus explicite sur ses prérequis : la documentation officielle indique clairement la version recommandée pour chaque version mineure.
• WordPress. Le projet recommande désormais PHP 8.3 ou supérieur, mais son minimum technique reste très bas — ce qui permet à WordPress de s'installer sur des versions PHP qui ne reçoivent plus aucun correctif depuis des années. Ne confondez jamais « le site s'installe » et « le socle est sûr ».
• Joomla. Les prérequis techniques sont documentés version par version dans le manuel officiel ; vérifiez-les pour votre version exacte avant de basculer, car ils ont évolué entre les branches 4 et 5.
• PrestaShop. La contrainte vient souvent moins du cœur que des modules commerciaux, dont la compatibilité avec les PHP récents est parfois en retard. Le point de vigilance est le tunnel de commande.

Règle pratique : visez la version la plus récente officiellement supportée par la version de CMS que vous exploitez réellement. Si votre CMS lui-même est ancien, le sujet PHP n'est que le symptôme : c'est la montée de version du CMS qu'il faut traiter en premier, sans quoi vous migrerez deux fois.

Ce qui casse réellement lors d'une montée de version PHP

Une migration PHP échoue rarement à cause du cœur du CMS, presque toujours à cause du code périphérique : extensions abandonnées, thème sur mesure ancien, développements spécifiques réalisés il y a plusieurs années. Le symptôme typique n'est pas une panne franche mais une dégradation partielle — un formulaire qui n'envoie plus, un module qui disparaît, une page qui blanchit.

Les causes de rupture les plus fréquentes que nous rencontrons en TMA :

• Fonctions supprimées ou dépréciées. PHP retire progressivement des fonctions anciennes. Un code écrit il y a huit ans peut appeler une fonction qui n'existe plus, ce qui provoque une erreur fatale et une page blanche.
• Durcissement du typage. Les versions récentes de PHP sont beaucoup plus strictes : passer null à une fonction qui attend une chaîne déclenche désormais une alerte, voire une erreur. C'est la source n° 1 des messages d'avertissement qui polluent un site après migration.
• Extensions non maintenues. Un plugin dont le dernier commit date de plusieurs années ne sera jamais rendu compatible. Il faut décider : le remplacer, le reprendre, ou supprimer la fonctionnalité.
• Bibliothèques tierces figées. Sur un site sur mesure, une dépendance non mise à jour depuis longtemps peut bloquer toute la montée de version. Le travail porte alors sur la chaîne de dépendances, pas sur PHP.
• Extensions PHP serveur manquantes. Après bascule, une extension système nécessaire au site peut ne pas avoir été activée sur la nouvelle version, ce qui casse une fonctionnalité précise sans toucher au reste.

Ces ruptures sont toutes détectables avant la mise en production, à condition de tester ailleurs que sur le site en ligne. C'est tout l'objet de la méthode décrite ci-dessous.

Migrer PHP en sept étapes sans couper le service

Une migration PHP maîtrisée se déroule sur un environnement de préproduction, jamais directement en ligne, et se termine par une bascule de quelques minutes réversible à tout instant. Le temps de travail réel se situe le plus souvent entre une demi-journée et deux jours pour un site vitrine standard ; l'essentiel de l'effort porte sur les tests, pas sur le changement de version lui-même.

1. Inventorier. Relever la version PHP actuelle, la version du CMS, la liste des extensions avec leur date de dernière mise à jour, la présence de développements sur mesure et les versions PHP proposées par l'hébergeur. Sans cet inventaire, tout planning est une supposition.
2. Sauvegarder et vérifier la sauvegarde. Fichiers et base de données, avec un test de restauration effectif. Une sauvegarde jamais restaurée n'est pas une sauvegarde : c'est une intention.
3. Cloner en préproduction. Dupliquer le site sur un environnement isolé, à l'identique, et y appliquer la nouvelle version PHP. C'est là que se révèlent 90 % des problèmes.
4. Analyser le code. Passer le code sur un outil de détection de compatibilité pour repérer les appels dépréciés, puis trier les alertes entre « bloquant », « à corriger » et « cosmétique ».
5. Corriger et mettre à jour. Mettre à niveau le CMS et les extensions vers des versions compatibles, corriger le code spécifique, arbitrer sur les extensions abandonnées.
6. Recetter fonctionnellement. Dérouler un scénario de test écrit : pages clés, formulaires de contact, envoi d'e-mails, connexion au back-office, recherche interne, tunnel de commande le cas échéant. Vérifier aussi les journaux d'erreurs, qui révèlent des problèmes invisibles à l'écran.
7. Basculer et surveiller. Appliquer la nouvelle version en production sur un créneau à faible trafic, vider les caches, puis surveiller activement les journaux et le comportement du site pendant les jours suivants. Prévoir le retour arrière : sur la plupart des hébergements, revenir à la version précédente prend quelques secondes.

Ce déroulé n'a rien d'exotique : c'est la trame que nous appliquons en maintenance évolutive pour toute montée de version, PHP comme CMS. Sa valeur tient à la discipline, pas à la complexité.

Le cas des parcs de sites : industrialiser la campagne PHP

Sur un parc de dix, trente ou cent sites, la migration PHP n'est plus une opération technique mais une campagne à piloter. La difficulté n'est pas de migrer un site, c'est de n'en oublier aucun et de séquencer l'ensemble sans mobiliser toutes les équipes en même temps. Un tableau de bord unique et un ordre de passage clair valent mieux que dix migrations improvisées en parallèle.

La méthode qui fonctionne tient en quatre principes :

• Une cartographie exhaustive. Un tableau listant, pour chaque site : version PHP, version de CMS, hébergeur, criticité métier, présence de code sur mesure, date de la dernière sauvegarde restaurée. Cette cartographie est le livrable qui débloque tout le reste — elle transforme une inquiétude diffuse en plan chiffré.
• Un séquencement par risque croissant. Commencer par les sites les plus simples et les moins critiques pour valider la procédure, finir par les sites vitrines à fort trafic et les applications sur mesure. Chaque vague enrichit le mode opératoire de la suivante.
• Des vagues courtes et régulières. Trois à cinq sites par semaine, avec un point d'avancement fixe, tiennent mieux dans la durée qu'un « grand soir » en décembre — période où les gels de production sont fréquents et les équipes indisponibles.
• Un traitement à part des cas durs. Deux ou trois sites concentreront l'essentiel de la difficulté : CMS trop ancien, développement sur mesure orphelin, prestataire d'origine injoignable. Isolez-les tôt et arbitrez explicitement — migration lourde, refonte, ou archivage.

C'est précisément la logique de notre offre de pilotage de parc digital : une vision consolidée de l'état technique de tous vos sites, et des campagnes de mise à niveau planifiées plutôt que subies.

Les erreurs fréquentes à éviter

La faute la plus coûteuse consiste à changer la version PHP directement en production, depuis le panneau de l'hébergeur, « pour voir ». Le clic prend trois secondes, la remise en état peut prendre plusieurs jours si le site tombe et que la sauvegarde s'avère inutilisable. Les autres erreurs récurrentes sont tout aussi évitables.

• Confondre « le site s'affiche » et « le site fonctionne ». Après bascule, la page d'accueil peut être parfaite pendant que le formulaire de contact n'envoie plus rien. Les fonctions les plus fragiles sont invisibles depuis le navigateur : e-mails sortants, tâches planifiées, exports, connexions à des services tiers.
• Ignorer les journaux d'erreurs. Une migration réussie en apparence peut générer des milliers d'alertes de dépréciation, qui saturent le disque et dégradent les performances. Vérifiez toujours les journaux après bascule.
• Migrer PHP sur un CMS obsolète. Si votre CMS n'est plus supporté, la montée de PHP ne résout rien et peut même le casser. L'ordre correct est presque toujours : CMS d'abord, PHP ensuite.
• Attendre décembre. Beaucoup d'entreprises gèlent leurs productions en fin d'année, et les prestataires sont saturés à l'approche des échéances connues. La bonne fenêtre pour une échéance de décembre se situe entre septembre et novembre — l'inventaire, lui, se fait maintenant.
• Oublier les sites secondaires. Landing pages de campagne, mini-sites événementiels, anciens sites conservés « au cas où » : ce sont eux qui restent sur des versions expirées et servent de porte d'entrée. Un site oublié sur le même hébergement peut compromettre les autres.

Checklist actionnable avant le 31 décembre 2026

Six actions suffisent à sécuriser l'échéance, et les deux premières peuvent être menées cette semaine sans budget ni prestataire. L'objectif de cette checklist est de vous permettre de savoir, avant la fin de l'été, si vous êtes concerné et à quel niveau d'effort.

1. Relever la version PHP de chacun de vos sites (back-office du CMS ou panneau hébergeur) et la consigner dans un tableau. Inclure les sites secondaires et les environnements de test.
2. Relever la version de votre CMS et vérifier si elle est encore supportée. Si elle ne l'est pas, c'est la priorité n° 1, avant PHP.
3. Vérifier quelles versions PHP votre hébergeur propose et jusqu'à quand il maintiendra celle que vous utilisez.
4. Tester une restauration de sauvegarde sur au moins un site, avant toute opération. C'est le filet de sécurité de toute la campagne.
5. Planifier la migration entre septembre et novembre 2026, en préproduction, avec un scénario de recette écrit.
6. Documenter le résultat : version cible, date de bascule, extensions abandonnées, points restés en suspens. Cette trace vous évitera de refaire l'inventaire à la prochaine échéance — car il y en aura une : PHP 8.3 s'arrêtera fin 2027.

Si l'un de ces points vous bloque, un audit de site web apporte l'état des lieux complet et le plan de migration chiffré. En cas d'incident déjà survenu après une bascule PHP, notre offre de dépannage ponctuel permet une intervention immédiate.

Questions fréquentes sur la fin de vie de PHP 8.2

Mon site va-t-il s'arrêter le 1^er janvier 2027 ?

Non. Votre site continuera de fonctionner normalement : la fin de support ne désactive rien. Ce qui cesse, c'est la publication de correctifs de sécurité. Le risque est donc différé et silencieux — il se matérialise lors de la première faille publiée non corrigée, ou le jour où votre hébergeur retire la version de son offre.

Combien de temps prend une migration PHP ?

Pour un site vitrine standard, à jour et sans développement spécifique, comptez généralement une demi-journée à deux jours de travail, tests compris. Un site ancien, très personnalisé ou reposant sur des extensions abandonnées demande davantage : le facteur déterminant est le volume de code sur mesure, pas la taille du site.

Puis-je revenir en arrière si la migration se passe mal ?

Oui, dans la quasi-totalité des cas. Sur un hébergement mutualisé ou infogéré, revenir à la version PHP précédente prend quelques secondes depuis le panneau d'administration. C'est pour cela que la bascule doit s'accompagner d'une surveillance active des premières heures, et d'une sauvegarde testée en amont.

Faut-il migrer vers PHP 8.5 directement pour être tranquille plus longtemps ?

Seulement si votre CMS et vos extensions la supportent officiellement. Viser la version la plus récente allonge l'horizon de tranquillité jusqu'à fin 2029, mais expose à des incompatibilités d'extensions dont l'écosystème n'a pas encore rattrapé la version. PHP 8.4 reste le choix le plus sûr pour la majorité des sites vitrines en 2026.

Qui est responsable de la version PHP : moi, mon hébergeur ou mon agence ?

L'hébergeur met des versions à disposition et annonce leur retrait, mais il ne migre pas votre site à votre place et n'assume pas la compatibilité de votre code. La responsabilité du choix, des tests et de la bascule revient au propriétaire du site, généralement déléguée à son prestataire de maintenance. En l'absence de contrat, elle reste entièrement à votre charge.

Ne subissez pas l'échéance : anticipez-la

Une échéance annoncée trois ans à l'avance ne devrait jamais devenir une urgence. La fin de vie de PHP 8.2 est un cas d'école de ce que la maintenance préventive traite en amont : une date connue, un impact mesurable, une procédure éprouvée. Le seul vrai risque est de ne rien faire jusqu'à ce que l'hébergeur ou un attaquant décide à votre place.

Depuis 2005, Pulsar Agency assure l'infogérance et la maintenance de sites vitrines sous WordPress, Joomla, Drupal et PrestaShop, pour des PME comme pour de grands comptes. Le suivi du cycle de vie des composants — PHP, CMS, extensions, certificats — fait partie intégrante de notre offre de maintenance. Si vous ignorez sur quelle version PHP tournent vos sites, c'est précisément le moment de le savoir : parlons-en.