Sur les sites qui arrivent chez nous en dépannage, la version PHP est un des premiers réglages que nous vérifions. Elle est obsolète bien plus souvent qu’on ne l’imagine. PHP 7.4 n’a reçu aucun correctif de sécurité depuis fin 2022, et son propriétaire ne le sait presque jamais. Passer à PHP 8.x change deux choses en même temps, la vitesse du site et son niveau de risque.
Pourquoi la version PHP de votre site compte
Ce que PHP fait tourner sur votre site
PHP est le langage qui exécute WordPress côté serveur. Chaque page que votre site génère passe par lui avant d’atteindre le navigateur du visiteur. Un thème dépend de cette couche invisible. Un plugin aussi. L’interface d’administration également.
L’hébergeur installe une version par défaut au moment de la création du compte. Cette version ne change plus d’elle-même ensuite. Un site créé en 2020 peut tourner sur PHP 7.4 aujourd’hui encore, sans qu’aucune alerte ne prévienne son propriétaire.
Une date de fin de vie que peu de propriétaires connaissent
Chaque version de PHP suit un cycle précis. Deux ans de support actif, puis une période de correctifs de sécurité uniquement, puis plus rien. PHP 7.4 est sorti de ce cycle en novembre 2022. PHP 8.0 a suivi en novembre 2023.
Un site qui tourne sur l’une de ces versions ne reçoit plus aucune correction, même si une faille grave est découverte demain. Vérifier sa version PHP prend une minute, dans la section outils de santé du site sous WordPress, ou directement auprès de l’hébergeur.
Ce que change PHP 8.x concrètement
Des gains de vitesse mesurables
Les tests publiés par le projet PHP montrent un écart net entre PHP 7.4 et PHP 8.1 sur les opérations que WordPress exécute en boucle, les appels de fonctions, le traitement des tableaux, les requêtes à la base de données.
Sur un site avec beaucoup de contenu dynamique, la différence apparaît dans le temps de réponse serveur. Le gain varie d’un site à l’autre. Certains gagnent 200 à 300 millisecondes, d’autres presque rien, parce que leur lenteur venait d’ailleurs : un plugin gourmand, une requête SQL mal écrite. PHP 8 accélère le moteur, pas les pièces défectueuses.
Une meilleure gestion de la mémoire serveur
PHP 8.x consomme moins de mémoire pour exécuter le même code que PHP 7.4. Sur un hébergement mutualisé aux ressources limitées, cet écart évite certains dépassements qui provoquent une erreur critique WordPress en pleine charge de trafic.
Un site qui frôlait la limite de mémoire avec l’ancienne version repasse sous le seuil sans changer d’offre d’hébergement. Un gain silencieux, mais réel.
Les risques d’une version PHP obsolète
Des failles de sécurité qui restent ouvertes
Une version PHP hors support ne reçoit plus de correctif, même en cas de faille critique découverte publiquement. Les attaquants ciblent en priorité les sites qui tournent sur ces versions anciennes, car les portes d’entrée connues y restent ouvertes.
Nous avons nettoyé des sites piratés dont le cœur WordPress et tous les plugins étaient à jour. Le propriétaire avait tout fait correctement, sauf une chose qu’aucune alerte ne lui montrait : la couche PHP, restée en 7.4 depuis la création du compte d’hébergement.
Des plugins qui refusent de fonctionner
Les développeurs de plugins laissent tomber la compatibilité avec les anciennes versions de PHP, plugin après plugin. Une extension mise à jour pour profiter de fonctionnalités récentes peut refuser de s’activer sur un serveur resté en PHP 7.4, avec un message d’erreur peu clair pour qui n’est pas développeur.
Ce blocage touche aussi les thèmes premium et les extensions de sécurité. Rester sur une ancienne version PHP finit par réduire les choix disponibles pour faire évoluer le site.
Comment migrer sans casser votre site
Vérifier la compatibilité avant de basculer
Chaque plugin et chaque thème actif doit être vérifié avant le changement de version. Installez PHP Compatibility Checker et lancez un scan. L’outil a ses limites, il laisse passer certains cas et génère de faux positifs, mais il repère l’essentiel : les fonctions supprimées de PHP 8 encore présentes dans votre code. Pour le reste, seul un test sur copie du site fait foi.
Un plugin abandonné depuis plusieurs années, sans mise à jour récente, constitue le risque principal. C’est souvent lui qui casse en premier après une migration PHP, bien avant le thème ou le cœur de WordPress. Notre article sur le choix des plugins WordPress détaille les signaux d’alerte à surveiller.
Tester sur un environnement de staging
La bascule ne doit jamais se faire directement sur le site en production. Un environnement de staging, copie exacte du site, permet de tester la nouvelle version PHP sans risque pour les visiteurs. Chaque page importante mérite une vérification visuelle, formulaires, panier d’achat, espace membre.
Si le test révèle un plugin incompatible, mieux vaut le remplacer avant la bascule que découvrir le problème une fois le site en ligne. Une sauvegarde complète avant chaque étape reste la meilleure protection contre un imprévu.
Si votre site est un blog ou un site vitrine, avec un thème récent et une poignée de plugins maintenus, faites cette migration vous-même. Sauvegarde, scan, bascule, vérification : une heure de travail, sans risque majeur. Le recours à un prestataire se justifie quand l’inventaire fait peur : un plugin abandonné dont dépend le site, un thème modifié à la main il y a cinq ans, une boutique WooCommerce qui ne peut pas se permettre une heure d’arrêt. C’est ce diagnostic que pose notre audit WordPress avant toute bascule, et c’est ce type de migration que notre service de maintenance WordPress exécute de façon planifiée et réversible.
