Traitement en cours…
Développement web · Maintenance et sécurité PHP
PHP 8.2 ne sera plus maintenu après le 31 décembre 2026. Versions alternatives, audit de compatibilité et méthode de migration WordPress, WooCommerce ou PHP personnalisé.
Le 31 décembre 2026, PHP 8.2 atteindra officiellement sa fin de vie. À partir du 1er janvier 2027, cette branche ne recevra plus de correctifs de sécurité de l'équipe PHP. Pour un site WordPress, une boutique WooCommerce ou une application métier, la bonne réponse n'est pas de changer aveuglément de version : c'est de préparer une migration vérifiée, avec sauvegarde, préproduction et possibilité de retour arrière.
Le site ne cessera pas automatiquement de fonctionner au passage à 2027. En revanche, conserver une version non maintenue augmente progressivement l'exposition aux vulnérabilités découvertes après cette date, sauf maintenance prolongée spécifique et documentée par un fournisseur. Voici comment identifier la version réellement utilisée, choisir entre PHP 8.3, 8.4 et 8.5, puis migrer sans improviser en production.
PHP 8.2 : fin du support le 31 décembre 2026. Pour de nombreux WordPress récents, PHP 8.4 est une cible raisonnable, tandis que PHP 8.5 peut convenir à un environnement déjà testé. Le choix doit être validé avec les thèmes, extensions, modules serveur et développements personnalisés.
Une version de PHP traverse deux phases principales : une période de support actif, pendant laquelle des corrections de bugs et de sécurité sont publiées, puis une période consacrée aux problèmes critiques de sécurité. À la fin du cycle, elle sort du support communautaire officiel.
Selon le calendrier officiel de PHP, PHP 8.2 ne sera plus maintenu après le 31 décembre 2026. Cela ne signifie ni une désactivation automatique par PHP, ni une incompatibilité instantanée de WordPress. Le risque vient de l'absence de futurs correctifs officiels pour cette branche, avec des conséquences potentielles pour la sécurité, les exigences de conformité et la maintenance de l'application.
Votre hébergeur peut continuer à faire fonctionner PHP 8.2 après l'échéance, ou proposer des correctifs spécifiques dans le cadre d'une offre de maintenance étendue. Vérifiez alors la durée, le périmètre et les conditions de ce support. Ne confondez pas une version encore exécutable avec une version officiellement maintenue par le projet PHP.
Attendre la dernière semaine de décembre rend les tests et les interventions plus difficiles, surtout pour une boutique en ligne ou un logiciel utilisé quotidiennement. Il est préférable de lancer l'inventaire dès novembre, puis de réserver une fenêtre de migration adaptée à votre activité.
Les trois branches constituent des alternatives maintenues à PHP 8.2, mais elles n'offrent pas le même horizon. Voici les dates annoncées par le projet PHP, au 2 novembre 2026.
| Version | Support actif jusqu'au | Support sécurité jusqu'au | Lecture pratique |
|---|---|---|---|
| PHP 8.2 | 31/12/2024 | 31/12/2026 | Migration à planifier |
| PHP 8.3 | 31/12/2025 | 31/12/2027 | Solution transitoire si nécessaire |
| PHP 8.4 | 31/12/2026 | 31/12/2028 | Cible pragmatique pour de nombreux sites récents |
| PHP 8.5 | 31/12/2027 | 31/12/2029 | Horizon plus long, après validation des dépendances |
Pour WordPress, il faut distinguer recommandation générale et compatibilité réelle. La page publique des prérequis WordPress recommande PHP 8.3 ou plus. Le guide technique destiné aux hébergeurs recommande, lui, PHP 8.4 ou plus en production. Le tableau officiel de compatibilité indique que WordPress 7.1 fonctionne avec PHP 8.4 et 8.5. Aucune de ces indications ne garantit cependant que chaque extension, thème ou développement sur mesure est compatible.
La règle de décision est donc simple : préférez PHP 8.4 si votre installation est récente et compatible ; envisagez PHP 8.5 lorsque tous les composants critiques ont été testés ; utilisez PHP 8.3 en solution de transition si une dépendance empêche encore le passage à une branche plus récente. Évitez de choisir une version uniquement parce qu'elle apparaît dans le panneau de l'hébergeur.
Sur un site WordPress, ouvrez Outils > Santé du site > Informations > Serveur : la ligne « Version de PHP » indique la version exécutée par le site. Avec WooCommerce, l'information se trouve aussi dans WooCommerce > État > Environnement serveur.
Vous pouvez également consulter le sélecteur PHP de votre hébergeur, qui peut être présenté dans cPanel, Plesk ou un panneau propriétaire. Pour plusieurs domaines ou sous-domaines, vérifiez chaque environnement : ils n'utilisent pas nécessairement la même version.
Sur une application personnalisée avec accès terminal, ces commandes permettent d'examiner l'environnement PHP en ligne de commande :
php -v
php -mAttention : la version retournée par php -v peut différer de celle utilisée par le serveur web (PHP-FPM, Apache ou configuration par site). C'est la version qui exécute les requêtes HTTP en production qu'il faut identifier. Évitez de laisser publiquement accessible un fichier de diagnostic affichant l'intégralité de la configuration PHP.
Notez la version de WordPress ou du framework, la liste des extensions et des thèmes avec leurs versions, les modules PHP nécessaires, les appels aux API externes, les scripts automatiques et les personnalisations. Un site vitrine simple et une application avec des dizaines de dépendances n'auront pas la même surface de test.
Sauvegardez la base de données et les fichiers, notamment les médias, la configuration et les composants personnalisés. Vérifiez la date, la disponibilité et la restauration effective d'une copie. Le retour à l'ancienne version PHP peut être rapide chez certains hébergeurs, mais il ne corrige pas un problème causé par une modification simultanée de code ou de données.
Utilisez autant que possible la même configuration serveur et les mêmes extensions PHP que la production. Isolez les services sensibles : passerelle de paiement en mode test, mails interceptés, clés d'API adaptées et tâches planifiées contrôlées. Sur un site qui stocke des données personnelles, protégez et limitez l'accès à cette copie.
Avant de basculer PHP, vérifiez les versions compatibles de WordPress, WooCommerce, du thème et des extensions. Certaines mises à jour devront être appliquées et testées dans un ordre précis. Gardez une trace des versions validées afin de reproduire la même combinaison en production, plutôt que de cumuler des changements non testés.
Effectuez le changement depuis le panneau d'hébergement ou la configuration du serveur. Vérifiez les modules utilisés (intl, mbstring, curl, gd, imagick, zip selon les besoins) et les paramètres sensibles. Analysez les erreurs fatales, les avertissements de dépréciation et les logs applicatifs. Les messages de dépréciation ne sont pas toujours bloquants immédiatement, mais peuvent signaler du code à adapter.
Contrôlez la connexion, les formulaires, les uploads, la recherche, les comptes clients, l'administration, les emails, les automatisations, les appels d'API et les traitements en arrière-plan. Ajoutez les parcours propres à votre secteur. Un site qui affiche sa page d'accueil sans erreur n'est pas nécessairement opérationnel.
Planifiez l'intervention en période de faible activité, informez les parties concernées, réalisez une sauvegarde récente puis appliquez le changement validé. Vérifiez immédiatement les transactions et tâches critiques, surveillez les journaux et conservez la procédure de retour arrière à portée de main. Sur une boutique, surveillez aussi les commandes créées pendant la fenêtre d'intervention afin de ne pas écraser de nouvelles données lors d'une éventuelle restauration.
Pour un WordPress récent, le travail commence par un contrôle de compatibilité du thème et des extensions, puis une répétition sur une copie du site. Dans l'administration, relevez la version PHP et celle du cœur WordPress. Mettez à jour les extensions maintenues dans l'environnement de test, contrôlez les personnalisations du thème enfant et les plugins développés spécifiquement pour le site.
Changez ensuite la version PHP de la préproduction vers 8.4. Testez une publication, la modification d'une page, les formulaires de contact, l'authentification, la médiathèque, l'envoi d'emails, la recherche interne et les fonctionnalités propres aux extensions. Si un composant ne fonctionne qu'avec PHP 8.2, cherchez d'abord une version corrigée ou une alternative maintenue, plutôt que de désactiver des contrôles de sécurité.
Pour le passage en production, reproduisez les versions déjà testées et vérifiez une nouvelle fois Outils > Santé du site. Les sites fortement personnalisés peuvent demander un audit de code supplémentaire ; leur migration n'est pas réductible à un simple clic dans le panneau d'hébergement.
Une boutique ne peut pas se contenter de vérifier que les fiches produits s'affichent. Après la migration sur une préproduction, testez avec un moyen de paiement de démonstration : fiche produit, panier, validation de commande, frais de livraison, taxes, création de commande, email transactionnel et changement de statut. Vérifiez les passerelles de paiement, les intégrations ERP/CRM, les abonnements éventuels et les actions planifiées.
WooCommerce recommande PHP 8.3 ou plus et insiste sur les sauvegardes et les tests dans un environnement de préproduction. Pour éviter des commandes perdues, n'écrasez pas automatiquement la base de données de production avec une copie antérieure au lancement des ventes. La stratégie de retour arrière doit tenir compte des commandes et paiements effectués entre-temps.
Pour un logiciel métier, un extranet ou une API, la compatibilité du framework ne suffit pas : examinez également les bibliothèques installées, extensions natives, scripts CLI, workers, intégrations et parties de code historiques. Le fichier composer.lock permet de savoir quelles dépendances sont réellement installées.
Sur une préproduction exécutant la version PHP cible, une vérification utile pour un projet Composer est :
php -v
composer check-platform-reqs --no-devCette commande compare la version PHP et les extensions réellement présentes aux exigences des paquets installés. Elle ne remplace ni les tests automatisés ni les tests métier, et doit s'exécuter avec le bon interpréteur PHP. Ajoutez des tests de non-régression, inspectez les journaux et vérifiez les jobs programmés avant de changer la production.
Les applications anciennes ou les dépendances abandonnées peuvent nécessiter une correction de code, une mise à jour de framework ou le remplacement d'un package. Dans ce cas, la bonne démarche est un audit de compatibilité puis un plan de migration découpé en étapes, pas une estimation sur la seule base du numéro de version.
Lorsque les extensions sont à jour et compatibles, l'essentiel du travail repose sur les sauvegardes, la préproduction, la bascule et la recette fonctionnelle. Le temps dépend du nombre de sites et de leurs fonctionnalités.
Une boutique avec des paiements, un thème personnalisé ou une application dotée d'intégrations spécifiques demande davantage de scénarios de test et parfois des corrections de code.
Il n'existe aucun tarif universel pour cette migration. Avant de chiffrer, il faut connaître la version PHP actuelle, le volume de composants à vérifier, l'existence d'une préproduction, les fonctionnalités critiques, les contraintes de disponibilité et l'effort de correction éventuellement nécessaire. Une simple modification d'hébergement et une migration applicative complète ne correspondent pas à la même prestation.
Pour une entreprise, l'objectif est de réduire le risque opérationnel tout en restant sur une version maintenue. Un diagnostic initial permet de distinguer ce qui peut être mis à jour directement de ce qui exige du développement ou des tests supplémentaires.
Non, pas automatiquement. PHP 8.2 peut continuer à exécuter le code après la fin de support, mais l'équipe PHP ne publiera plus de correctifs officiels pour cette branche. Vérifiez aussi la politique de votre hébergeur.
Oui, si votre hébergement, WordPress ou votre framework, vos extensions et votre code sont compatibles. La préproduction et les tests sont indispensables pour le confirmer.
PHP 8.5 dispose d'un horizon de support plus long, mais certaines dépendances ou extensions peuvent nécessiter des adaptations. La version la plus récente n'est pas toujours la première cible acceptable d'une application existante.
Oui, d'après le tableau de compatibilité du cœur WordPress. Cela ne valide pas automatiquement les thèmes, plugins, modules d'hébergement ou développements personnalisés installés sur votre site.
Généralement non : WordPress permet de consulter la version utilisée, mais le choix de l'interpréteur PHP se fait au niveau de l'hébergement ou du serveur. Demandez les modalités à votre hébergeur.
Elle est indispensable, mais ne remplace pas une restauration testée, une préproduction représentative, une recette des fonctions métiers et un plan de retour arrière adapté aux données créées entre-temps.
Le 31 décembre 2026 est une échéance de sécurité connue, pas une raison de modifier un site à la hâte. Identifiez votre version PHP aujourd'hui, vérifiez la compatibilité des composants, testez une version maintenue en préproduction et planifiez une bascule contrôlée. Pour de nombreux sites WordPress, PHP 8.4 constitue un point de départ pertinent ; pour une application personnalisée, la cible doit découler d'un audit technique.
SDX Development peut accompagner un audit de compatibilité PHP, une migration WordPress ou WooCommerce et l'adaptation d'une application métier avec sauvegarde, tests de non-régression et procédure de déploiement. Pour les évolutions futures du langage, consultez également notre article PHP 8.6 : les tests à mener avant novembre, consacré à un sujet différent de cette fin de support.
DÉVELOPPEMENT WEB
Migration PHP, mise à jour de CMS ou évolution de framework : identifiez les points de compatibilité et validez les parcours essentiels avant la mise en ligne.
Saisissez au moins 2 caractères pour lancer la recherche.