+33-9-7266-3068
contact@gdm-pixel.fr
Votre site WordPress tourne peut-être sur une version PHP obsolète
Combien d’entre vous ont déjà reçu ce message dans le tableau de bord WordPress : “Votre serveur utilise PHP 7.4, qui n’est plus maintenu” — et l’ont ignoré pendant six mois ?
C’est humain. On a autre chose à faire. Le site tourne, les clients passent des commandes, le téléphone sonne. Pourquoi toucher à quelque chose qui fonctionne ?
Voici pourquoi : PHP 7.4 est en fin de vie depuis fin 2022. Aucun correctif de sécurité. Aucun patch. Si quelqu’un cherche à exploiter une faille sur votre serveur, il a le champ libre. Et en 2026, les hébergeurs commencent à forcer la migration — parfois sans prévenir, avec des résultats désastreux sur les sites mal préparés.
On a géré plusieurs urgences de ce type chez GDM-Pixel. Un e-commerce PrestaShop planté après une mise à jour forcée par l’hébergeur. Un site WordPress cassé parce qu’un plugin vieux de trois ans ne supportait pas PHP 8.2. Chaque fois, la cause racine : personne n’avait anticipé la migration PHP.
Ce guide est là pour que ça ne vous arrive pas.
Pourquoi la version PHP de votre site WordPress est critique
PHP, c’est le langage qui fait tourner WordPress. Chaque page que vos visiteurs chargent, chaque formulaire soumis, chaque commande passée — c’est PHP qui exécute tout ça côté serveur.
WordPress lui-même est écrit en PHP. Vos thèmes aussi. Vos plugins aussi. Et chaque version de PHP apporte des changements : nouvelles fonctions, suppression d’anciennes syntaxes, optimisations de performances.
Le problème, c’est que l’écosystème WordPress est vaste et inégal. Certains plugins sont maintenus activement. D’autres n’ont pas été mis à jour depuis 2019. Quand vous passez de PHP 7.4 à PHP 8.1, un plugin mal codé peut générer des erreurs fatales — et afficher une page blanche à vos clients.
Performances mesurables. PHP 8.x est significativement plus rapide que PHP 7.x. Des benchmarks réels montrent des gains de 10 à 30 % sur le temps d’exécution selon la complexité du site. Pour un e-commerce avec un catalogue dense, c’est directement visible sur les Core Web Vitals — et donc sur votre positionnement Google.
Compatibilité des extensions. Depuis PHP 8.0, plusieurs fonctions dépréciées ont été supprimées. Les plugins codés avec des raccourcis des années 2015-2018 peuvent planter silencieusement — ou bruyamment, selon la configuration d’affichage des erreurs.
Exigences d’hébergement. En 2026, la plupart des hébergeurs sérieux (OVH, PlanetHoster, Infomaniak, o2switch) ont déprécié PHP 7.x sur leurs interfaces. Certains planifient des migrations automatiques. Mieux vaut contrôler vous-même le timing.
Quelle version PHP choisir en 2026 ?
Pas de mystère ici. En 2026, la recommandation officielle WordPress est PHP 8.2 ou 8.3.
- PHP 8.1 : encore supportée, mais en fin de vie active depuis fin 2025. Acceptable si votre stack n’est pas encore compatible 8.2.
- PHP 8.2 : le sweet spot actuel. Support actif, compatibilité large avec les plugins maintenus, gains de perfs notables.
- PHP 8.3 : la dernière version stable. Recommandée pour les nouveaux projets. Quelques plugins en retard de compatibilité — à vérifier.
- PHP 7.x : à bannir immédiatement. Plus de correctifs de sécurité. Risque réel.
La règle simple : visez PHP 8.2 si votre site a plus de deux ans et un écosystème de plugins fourni. Visez 8.3 si vous partez d’une base propre ou si vous venez de faire un audit de compatibilité complet.
Avant de toucher quoi que ce soit : la checklist de sécurité
C’est là que 80 % des gens font l’erreur. Ils changent la version PHP depuis le panneau d’hébergement, et découvrent le site blanc cinq minutes plus tard.
La migration PHP, ça se prépare. Voici exactement comment on procède chez GDM-Pixel avant chaque mise à jour.
1. Sauvegarde complète, pas partielle
Fichiers + base de données. Les deux. Une sauvegarde des fichiers sans la BDD ne sert à rien si WordPress plante au démarrage. Utilisez UpdraftPlus, BlogVault, ou la sauvegarde native de votre hébergeur — mais vérifiez que la restauration fonctionne. Une sauvegarde qu’on n’a jamais testée, c’est une fausse sécurité.
2. Audit de compatibilité PHP
Installez le plugin PHP Compatibility Checker (WP Engine) sur votre site. Il scanne tous vos plugins, thèmes et fichiers custom et vous signale les incompatibilités avec la version cible. C’est 10 minutes de travail qui vous évitent une heure de débogage.
Ce qu’on cherche : les erreurs fatales potentielles sur PHP 8.x. Les warnings, c’est moins urgent. Les deprecated notices, ça peut attendre. Les fatal errors, ça plante le site.
3. Mettre à jour WordPress, thèmes et plugins d’abord
Avant de changer PHP, mettez à jour tout le reste. Les versions récentes des plugins populaires (WooCommerce, Yoast, ACF, Elementor) sont compatibles PHP 8.2+. Si vous êtes sur WooCommerce 7.x avec PHP 8.2, vous cherchez les ennuis.
4. Tester en environnement de staging
Si votre hébergeur propose un environnement de staging (OVH, WP Engine, Kinsta le font), utilisez-le. Dupliquez le site, changez PHP sur la copie, testez les pages critiques : accueil, catalogue, panier, checkout, formulaires de contact.
Si vous n’avez pas de staging : créez un sous-domaine temporaire, installez une copie du site, testez là. Ce n’est pas optionnel pour un e-commerce actif.
Comment changer la version PHP selon votre hébergeur
La manipulation concrète varie selon votre hébergement. Voici les cas les plus courants en France.
cPanel (o2switch, Hostinger, PlanetHoster) Accédez à cPanel > PHP Selector ou MultiPHP Manager. Sélectionnez votre domaine, choisissez la version cible, sauvegardez. Le changement est immédiat — d’où l’importance de la préparation en amont.
Plesk (OVH mutualisé, certains VPS)
Domaines > votre domaine > Paramètres PHP. Sélectionnez la version dans le menu déroulant. Sur certaines configurations OVH, vous devez aussi modifier le fichier .htaccess pour forcer la version :
AddHandler application/x-httpd-php82 .phpWHM / Serveur dédié Via WHM > EasyApache 4, vous pouvez installer les extensions PHP de chaque version et configurer les defaults. C’est le niveau de contrôle maximum — et le plus risqué si vous ne savez pas ce que vous faites.
Hébergements managés (Kinsta, WP Engine, Flywheel) Interface propriétaire dans le dashboard. Kinsta par exemple : Sites > votre site > Outils > Version PHP. Ces hébergeurs testent la compatibilité en amont et vous alertent si des problèmes sont détectés. Le premium a ses avantages.
Que faire si le site plante après la mise à jour ?
Ça arrive. Même avec une préparation sérieuse, un plugin obscur peut générer une erreur fatale.
Première action : repassez immédiatement à l’ancienne version PHP depuis votre hébergeur. Le site reprend. Vous avez le temps de diagnostiquer sans urgence.
Deuxième action : activez le mode debug WordPress. Dans wp-config.php, ajoutez :
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Le fichier wp-content/debug.log contiendra les erreurs exactes. Cherchez les lignes Fatal error — elles vous donnent le nom du plugin ou du fichier en cause.
Troisième action : désactivez les plugins un par un (via FTP si le tableau de bord est inaccessible — renommez le dossier du plugin dans wp-content/plugins/). Réactivez PHP 8.2, testez. Identifiez le coupable.
La plupart du temps, c’est un plugin abandonné depuis deux ans. La solution : trouver un équivalent maintenu, ou faire corriger le code si c’est un développement custom.
“Une migration PHP mal préparée, c’est souvent deux heures de panique pour résoudre ce qu’une heure de préparation aurait évité.” — Ce qu’on répète à chaque client qui nous appelle en urgence.
Les erreurs qu’on voit systématiquement chez nos clients
Après des dizaines de migrations PHP gérées chez GDM-Pixel, voici ce qui revient le plus souvent.
Plugins de constructeur de page obsolètes. Elementor, Divi, WPBakery — les vieilles versions de ces outils sont des bombes à retardement sur PHP 8.x. Mettez-les à jour avant tout.
Fonctions PHP dépréciées dans les thèmes enfants. Les thèmes enfants créés il y a 4-5 ans contiennent parfois des appels à ereg(), split(), ou mysql_* — supprimés en PHP 8. Ça plante sans préavis.
Extensions PHP manquantes. PHP 8.2 peut nécessiter des extensions spécifiques activées sur le serveur (intl, imagick, sodium). Si votre hébergeur ne les active pas par défaut, certains plugins peuvent dysfonctionner silencieusement.
WooCommerce + extensions tierces. Le cœur de WooCommerce est bien maintenu. Les extensions de paiement ou de livraison de développeurs tiers, beaucoup moins. Vérifiez chacune individuellement.
Ce que ça change concrètement pour votre site
Passons aux bénéfices mesurables, parce que la sécurité c’est bien, mais les chiffres c’est mieux.
Temps de chargement. Sur un site WordPress standard avec WooCommerce, le passage de PHP 7.4 à PHP 8.2 réduit le Time to First Byte (TTFB) de 15 à 25 % selon nos mesures. Ce n’est pas négligeable quand Google considère le TTFB dans ses signaux de performance.
Score PageSpeed. La combinaison PHP 8.2 + OPcache activé + serveur correctement configuré peut faire gagner 8 à 15 points sur le score Performance de PageSpeed Insights. Pour un site qui était à 65, passer à 78 change la donne en termes de conversions mobiles.
Conformité hébergeur. En 2026, certains hébergeurs facturent un surcoût ou limitent les ressources sur PHP 7.x. Rester à jour, c’est aussi éviter des mauvaises surprises sur votre facture d’hébergement.
Trois points à retenir avant de lancer la migration
Avant de fermer cet article et d’ouvrir votre cPanel, voici l’essentiel.
Préparez avant d’agir. Sauvegarde complète, audit de compatibilité, mise à jour de tous les plugins — dans cet ordre. Ne changez jamais PHP en premier.
Testez sur un environnement isolé. Si vous avez un e-commerce actif, une heure de staging vous économise potentiellement une journée de revenus perdus. Ce n’est pas une option, c’est une obligation.
Documentez ce que vous faites. Notez la version PHP actuelle, les plugins qui posent problème, les actions correctives. Si vous devez recommencer dans 18 mois pour PHP 8.4, vous aurez une base de travail.
Vous préférez déléguer plutôt que gérer ça vous-même ?
C’est une question légitime. Votre temps de gérant vaut quelque chose — et le passer à déboguer une migration PHP à 22h n’est pas forcément le meilleur investissement.
Chez GDM-Pixel, on gère ce type d’intervention régulièrement. Audit de compatibilité, migration PHP en staging, tests complets, mise en production propre. On documente tout et on vous remet un rapport clair sur l’état de votre site après intervention.
Si votre site WordPress n’a pas été touché depuis plus de deux ans, c’est probablement le bon moment pour un audit technique complet : version PHP, plugins obsolètes, performances, sécurité. Pas pour vendre une refonte — mais pour vous dire exactement où vous en êtes et ce qui nécessite une action urgente.
Contactez GDM-Pixel pour un audit technique — on vous répond sous 24h avec une estimation claire.
Votre site tourne sur quelle version PHP en ce moment ? Si vous ne savez pas, c’est déjà une réponse.
Réseaux sociaux
Analyser avec l'IA
