Votre site fonctionne, les formulaires arrivent et les commandes passent. Pourtant, une échéance technique mérite votre attention : le support de sécurité de PHP 8.2 par le projet PHP se termine le 31 décembre 2026.
PHP est le langage exécuté côté serveur par WordPress et PrestaShop. Sa maintenance concerne donc directement la sécurité et la pérennité de votre site. Changer de version demande de vérifier l’ensemble de l’application, pas seulement de sélectionner une option dans l’hébergement.
Calendrier vérifié le 12 novembre 2026 auprès du projet PHP.

Que signifie la fin du support PHP 8.2 ?

Le calendrier officiel PHP distingue le support actif du support consacré aux correctifs de sécurité. PHP 8.2 est déjà dans cette seconde phase. Après le 31 décembre 2026, le projet PHP ne prévoit plus de correctifs pour cette branche.
Le site ne s’arrêtera pas automatiquement à minuit. En revanche, continuer à utiliser une branche sans maintenance officielle accroît la dépendance à des solutions particulières si une nouvelle vulnérabilité est découverte.
Certains fournisseurs maintiennent leurs propres correctifs au-delà de l’échéance officielle. Cette couverture doit être vérifiée précisément : fournisseur, paquet installé, durée, périmètre et modalités. Une offre de support du système d’exploitation ne démontre pas à elle seule que tous les interpréteurs PHP ajoutés séparément sont couverts.

Quelle version PHP votre site utilise-t-il vraiment ?

Commencez par le panneau d’hébergement et les informations système du CMS. Sur une installation Plesk, vérifiez le gestionnaire PHP affecté à chaque domaine et sous-domaine. Deux sites du même serveur peuvent utiliser des versions différentes.
Autre point à contrôler : le PHP du site web peut différer du PHP utilisé en ligne de commande. Les tâches planifiées, scripts d’import, commandes WP-CLI et opérations de maintenance doivent être inclus dans l’inventaire.
La commande php -v renseigne sur l’exécutable invoqué dans le terminal. Elle ne prouve pas que PHP-FPM utilise cette même version pour votre domaine. Évitez également de laisser une page publique d’information PHP en ligne après le diagnostic.

Choisir une cible compatible,
plutôt que la version la plus récente à tout prix

Le choix dépend du CMS installé et de ses dépendances. Une version prise en charge par le cœur de WordPress peut encore poser problème à une extension. Pour PrestaShop, la compatibilité doit être vérifiée pour la branche exacte du logiciel, le thème et les modules.
Avant de choisir, relevez :
Les versions du CMS, des extensions et du thème.
Les prérequis PHP documentés par chaque composant critique.
Les développements spécifiques et les bibliothèques embarquées.
Les extensions PHP nécessaires et les paramètres de fonctionnement.
Les contraintes des outils externes : paiement, ERP, transport ou authentification.
Un composant abandonné qui bloque l’évolution doit faire l’objet d’une décision : remplacement, correction maintenue ou retrait. Repousser indéfiniment la migration laisse le problème entier.

Une méthode de migration en cinq étapes

1. Mesurer le fonctionnement actuel

Conservez un état de référence : pages principales, parcours d’achat, temps de réponse représentatifs et erreurs déjà présentes. Vous pourrez distinguer une régression d’un problème antérieur.

2. Sauvegarder et préparer la reprise

Sauvegardez fichiers, base et configuration utile. Vérifiez comment restaurer l’ensemble et qui peut intervenir. Si vous mettez aussi à jour le CMS ou des modules, le retour à l’ancien PHP ne suffira pas nécessairement à annuler leurs changements.

3. Préparer une copie de test

Utilisez un environnement isolé, protégé contre les accès publics. Neutralisez les paiements réels, courriels et synchronisations externes. Réduisez autant que possible les données personnelles copiées pour les essais.

4. Tester les fonctions métier

Pour WordPress, validez l’édition des pages, les formulaires, les comptes et les fonctions des extensions essentielles. Pour PrestaShop, ajoutez les déclinaisons, taxes, transporteurs, promotions, paiements et factures. Contrôlez aussi les imports, exports et tâches planifiées.
Consultez les journaux PHP pendant les tests. Un avertissement de dépréciation n’a pas la même gravité immédiate qu’une erreur fatale, mais révèle parfois une dépendance à faire évoluer.

5. Basculer puis surveiller

Planifiez une plage adaptée à votre activité. Après le changement, vérifiez à nouveau les scénarios essentiels et surveillez les erreurs, les formulaires et les commandes. Comparez les performances dans des conditions comparables ; une migration ne garantit pas à elle seule un gain de vitesse.

Trois erreurs à éviter

Valider seulement l’accueil : les problèmes peuvent se trouver dans une facture, un paiement ou une tâche de nuit.

Tout changer simultanément : multiplier les modifications rend le diagnostic plus difficile en cas de panne.

Prévoir une restauration sans tenir compte des données nouvelles : les commandes et inscriptions reçues après la sauvegarde doivent être préservées.

Mon hébergeur ne s’en charge-t-il pas automatiquement ?

Cela dépend du contrat. Installer un interpréteur PHP disponible sur le serveur et vérifier la compatibilité fonctionnelle de votre site sont deux prestations distinctes.

Peut-on migrer avant décembre ?

Oui, dès que la cible est compatible et les tests concluants. Anticiper laisse davantage de temps pour remplacer un module ou corriger un développement spécifique

Préparer une migration PHP adaptée à votre activité

Mon accompagnement associe l’analyse du CMS à celle du serveur et des dépendances. Pour un site vitrine comme pour une boutique, la priorité est de conserver les fonctions utiles tout en sortant d’une branche en fin de support.
Vous pouvez commencer par un audit technique de votre site. Si vous hésitez entre remise à niveau et refonte, mon article sur la dette technique WordPress présente les critères de décision. Contactez-moi avec votre version de PHP et celle de votre CMS pour préparer la suite.