WordPress 7 et PHP 8 : préparer la migration (fin du support PHP 7.2/7.3)

Votre site tourne encore en PHP 7.4 ? Le 9 janvier 2026, l’équipe WordPress Core a publié une annonce qui concerne chaque propriétaire de site WordPress : PHP 7.2 et 7.3 ne seront plus supportés à partir de WordPress 7.0. Si votre hébergeur fait encore tourner votre site sur une de ces versions… il est temps de bouger.

La bonne nouvelle : cette migration est simple, rapide, et apporte des gains de performance immédiats. La mauvaise : si votre site est encore en PHP 7.2 ou 7.3, WordPress 7, sorti le 20 mai 2026, ne pourra pas s’installer : votre site restera sur la branche 6.9. Pour les nouveautés de WordPress 7 au-delà de PHP (la collaboration en temps réel, elle, a finalement été retirée de la version 7.0), consultez notre guide WordPress 7.0.

En tant que formateur WordPress (organisme certifié Qualiopi) et co-créateur de WPS Hide Login (2 millions d’installations), j’ai migré wpformation.com de PHP 8.0 à PHP 8.1 en 2025 sur O2switch - zéro problème, temps de réponse serveur réduit de 25 %. Comptez 30 minutes sur un site simple, jusqu’à 2 heures sur un WooCommerce bien chargé. Voici le guide complet pour faire la même chose sur votre site, étape par étape.

Ce qui change avec WordPress 7.0 et PHP

WordPress a toujours été conservateur sur les versions PHP supportées. Trop conservateur, selon beaucoup de développeurs. Voici l’état des lieux en octobre 2026.

Les versions PHP et WordPress 7.0

WordPress 7.0, sorti le 20 mai 2026, fixe de nouvelles exigences :

• PHP 7.2 et 7.3 : support abandonné - WordPress 7 ne s’installera pas, votre site reste sur la branche 6.9
• PHP 7.4 : minimum supporté - votre site fonctionnera, mais cette version est en fin de vie depuis novembre 2022
• PHP 8.0 à 8.2 : supportées par WordPress, mais PHP 8.0 et 8.1 ne reçoivent plus de correctifs de sécurité, et PHP 8.2 n’en reçoit plus que jusqu’au 31 décembre 2026
• PHP 8.3 : version minimale recommandée par WordPress - performances et sécurité au rendez-vous
• PHP 8.4 et 8.5 : prises en charge par WordPress 7.0 et 7.1 (8.4 depuis WordPress 6.7, 8.5 depuis la 6.9), sans le label "beta", retiré en mai 2026 ; c’est la compatibilité de vos extensions qui décide

Dit autrement : si vous êtes en PHP 7.2 ou 7.3, la migration est obligatoire. Si vous êtes en PHP 7.4, elle est fortement recommandée. Si vous êtes déjà en PHP 8.x, vous êtes tranquille - mais viser PHP 8.3 reste un bon réflexe.

Pourquoi WordPress abandonne PHP 7.2/7.3

PHP 7.2 a atteint sa fin de vie en novembre 2020. PHP 7.3, en décembre 2021. Ça fait plus de 4 ans que ces versions ne reçoivent plus de correctifs de sécurité. Chaque site qui tourne encore dessus est une faille de sécurité ouverte - et un frein pour sécuriser WordPress correctement. Le Core team ne peut plus maintenir la compatibilité ascendante avec des versions aussi anciennes sans freiner le développement.

Selon les stats WordPress.org publiées avec l’annonce de janvier 2026, moins de 4 % des sites WordPress tournaient encore sur PHP 7.2 ou 7.3 (3,85 %). C’est peu en pourcentage, mais cela représente encore un grand nombre de sites dans le monde.

Vérifier votre version PHP actuelle

Avant toute chose, identifiez sur quelle version PHP tourne votre site. Trois méthodes, de la plus simple à la plus technique.

Méthode 1 : depuis wp-admin

Allez dans wp-admin → Outils → Santé du site → Info → Serveur. La ligne "Version PHP" affiche votre version actuelle. C’est la méthode la plus rapide et elle ne nécessite aucune compétence technique.

Méthode 2 : depuis votre hébergeur

Connectez-vous à votre espace d’hébergement (cPanel, Plesk, panel propriétaire). Cherchez "PHP"ou"Version PHP" dans les paramètres. Chez O2switch par exemple, c’est dans cPanel → MultiPHP Manager.

Méthode 3 : via WP-CLI

Si vous utilisez WP-CLI, une commande suffit :

wp --info | grep "PHP version"

Cette commande donne la version de PHP utilisée en ligne de commande, qui peut différer de celle qui sert votre site : en cas de doute, la méthode 1 (Santé du site) fait foi.

Les gains concrets de la migration vers PHP 8

Le passage à PHP 8, ça change vraiment quelque chose ? Migrer vers PHP 8.x n’est pas juste une obligation technique. C’est un upgrade de performance gratuit. Voici ce que les benchmarks montrent.

Performance

PHP 8.3 exécute le code WordPress jusqu’à 40 % plus vite que PHP 7.4. Le compilateur JIT (Just-In-Time) de PHP 8, lui, est désactivé par défaut et apporte peu à une application web typique comme WordPress : les gains viennent des autres optimisations du moteur. Sur un site WooCommerce avec beaucoup de produits, la différence est nette.

Sur wpformation.com, le passage de PHP 8.0 à 8.1 a réduit le TTFB (Time To First Byte) de 180ms à 135ms en moyenne. Pas aussi marqué que le saut de 7.x à 8.x, mais chaque milliseconde compte pour le SEO : un TTFB plus court accélère l’affichage de l’élément principal de la page (LCP), l’un des trois Core Web Vitals que Google prend en compte. Et avec OPcache activé, les gains montent facilement à 30-50 %. Côté navigateur, WordPress précharge aussi les pages avant le clic depuis la version 6.8 : je montre comment le vérifier et le régler dans mon tutoriel sur la navigation quasi instantanée.

Sécurité

PHP 7.4 ne reçoit plus de correctifs de sécurité depuis novembre 2022. Chaque vulnérabilité PHP découverte depuis reste ouverte sur votre serveur. PHP 8.3 bénéficie de correctifs de sécurité jusqu’en décembre 2027. On l’oublie trop souvent, mais un PHP obsolète est la porte d’entrée la plus simple pour un attaquant. Rester sur une vieille branche de PHP, c’est aussi se priver des correctifs critiques. PHP2Shell l’a montré en octobre 2026 : les versions corrigées sont sorties pour PHP 8.2 à 8.5, et PHP 7.4 à 8.1 n’ont eu que des correctifs minimaux dans le code source, sans nouvelle version.

Nouvelles fonctionnalités PHP

PHP 8 apporte des fonctionnalités que les développeurs de plugins et thèmes commencent à utiliser : les named arguments, les union types, le match expression, les enums (PHP 8.1), les fibres (PHP 8.1), les readonly properties (PHP 8.1), les classes readonly (PHP 8.2). Si un plugin requiert PHP 8.0+ et que vous êtes en 7.4, il ne s’installera tout simplement pas.

En 2026, environ 90 % des plugins et thèmes du répertoire WordPress.org sont compatibles PHP 8+. Le risque d’incompatibilité a considérablement diminué par rapport à 2023-2024…

La méthode d’audit en 8 étapes qu’on a appliquée avant de migrer notre site

Avant de cliquer sur "Mettre à jour WordPress", on prend toujours le temps d’auditer ce qu’on a sous le capot. Cette méthode en 8 étapes, c’est exactement celle qu’on a déroulée le 15 mai 2026 sur notre backend WordPress en préparation de WordPress 7.0. Elle n’est pas réservée aux gros sites. Une boutique de quartier sur WooCommerce gagne autant à la suivre qu’une plateforme avec dix mille articles. La logique est la même : on vérifie ce qu’on a, on teste ailleurs qu’en production, on sauvegarde, on planifie le retour en arrière, et on surveille les heures qui suivent.

Si vous voulez le détail de ce qui change concrètement côté moteur, on a publié un guide complet sur WordPress 7.0 et ses nouveautés. Ici, on parle uniquement de la méthode d’audit. Comptez deux heures pour un site classique avec une dizaine de plugins. Comptez une demi-journée si vous avez accumulé du code maison au fil des ans.

1. Faire l’inventaire complet de vos plugins actifs

Ouvrez la page Extensions > Extensions installées dans votre tableau de bord. Pour chaque plugin actif, notez trois choses : la version installée, la date de dernière mise à jour, et la mention "testé jusqu’à WordPress X.Y" affichée par le développeur. Cette mention figure sur la fiche du plugin dans le répertoire officiel WordPress.org, ou dans le fichier readme.txt du plugin.

Trois signaux à surveiller. Un plugin qui n’a pas été mis à jour depuis plus de douze mois, c’est un drapeau rouge. Un plugin dont la mention "testé jusqu’à" est restée plusieurs versions en arrière, c’est un drapeau orange. Un plugin qui n’apparaît plus dans le répertoire officiel (404 sur sa page), c’est un drapeau noir : il a été retiré pour faute de maintenance, faille de sécurité non corrigée, ou rachat suspect. Dans ces trois cas, cherchez une alternative avant de migrer, pas après.

2. Auditer le thème actif, le thème enfant et `functions.php`

Le thème actif et son éventuel thème enfant (la copie modifiable que beaucoup d’agences ajoutent au-dessus du thème parent) contiennent souvent du code PHP que personne ne touche plus depuis deux ans. C’est exactement là que se cachent les fonctions PHP obsolètes qui plantent à la mise à jour. Ouvrez le fichier functions.php du thème actif et du thème enfant, et listez les fonctions WordPress utilisées.

Comparez ensuite cette liste avec les fonctions retirées dans la nouvelle version de WordPress. Le "Field Guide" officiel publié sur make.wordpress.org avant chaque sortie majeure liste exactement ce qui disparaît. Pour WordPress 7.0, on a vérifié six fonctions qui devaient être supprimées : zéro match dans notre code. Si vous trouvez un match, deux options. Soit la fonction a une remplaçante moderne (un appel rapide à la documentation officielle vous le dira), soit elle n’en a pas et il faudra réécrire la logique avant de migrer.

3. Vérifier la version PHP, les extensions et les dépréciations

Allez dans Outils > Santé du site > Informations > Serveur pour voir votre version PHP exacte et la liste des extensions PHP activées (les extensions sont des modules optionnels du langage PHP comme mbstring, curl, mysqli, gd, qui s’activent sur le serveur). Notez la version PHP, la mémoire allouée (memory_limit), le temps d’exécution maximum, et la liste des extensions.

Vérifiez ensuite la liste des dépréciations PHP. Une dépréciation, c’est une fonction qui marche encore aujourd’hui mais que les développeurs du langage ont signalée comme "à supprimer dans une prochaine version". En passant à une version PHP plus récente, ces fonctions disparaissent et votre code casse. Activez temporairement WP_DEBUG et WP_DEBUG_LOG dans wp-config.php (WP_DEBUG_LOG seul n’écrit rien) pendant 24 heures, de préférence en préproduction, et regardez le fichier wp-content/debug.log : si des messages "Deprecated" apparaissent, vous savez exactement ce qu’il faut corriger.

Sur un site en ligne, coupez l’affichage des erreurs pour que vos visiteurs ne voient rien : placez ces lignes avant la ligne qui commence par /* That's all, stop editing!, en remplaçant la ligne define( 'WP_DEBUG', false ); si elle existe déjà.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Le fichier wp-content/debug.log peut être téléchargé par n’importe qui : remplacez le true de WP_DEBUG_LOG par le chemin d’un fichier situé hors de la racine web, dans un dossier existant (par exemple '/home/votre-compte/logs/debug.log'), ou, sur un serveur Apache 2.4, bloquez son accès avec ces lignes dans le fichier .htaccess à la racine du site. Supprimez le journal après analyse et remettez WP_DEBUG à false à la fin.

<Files debug.log>
Require all denied
</Files>

4. Tester en préproduction, jamais directement en production

La préproduction, c’est une copie complète de votre site (base de données + fichiers) installée sur un sous-domaine séparé, par exemple staging.monsite.fr, ou sur un serveur de test. C’est là qu’on teste la mise à jour, à l’abri de vos visiteurs. Beaucoup d’hébergeurs proposent ce clonage en un clic : O2switch, OVH, Kinsta, Infomaniak, LWS le font.

Sur cette préproduction, vous appliquez la mise à jour WordPress comme vous le feriez en production. Vous parcourez ensuite chaque page importante du site, vous naviguez dans le tableau de bord, vous éditez un article, vous regardez le journal d’erreurs PHP. Si quelque chose casse, vous le savez avant que vos visiteurs le découvrent. Comptez deux heures pour faire un tour de site sérieux sur un site moyen.

5. Tester les fonctionnalités critiques métier

L’erreur classique, c’est de tester l’admin et la page d’accueil, puis de déclarer "tout va bien". Or les choses qui rapportent de l’argent à votre site sont rarement sur la page d’accueil. Faites la liste de tout ce qui doit absolument fonctionner : formulaire de contact qui envoie bien un email, panier WooCommerce qui passe la commande jusqu’au paiement, connexion utilisateur, formulaire d’inscription newsletter, moteur de recherche interne, page de signature électronique le cas échéant, intégrations tierces (CRM, ERP, outils d’emailing).

Sur chaque fonctionnalité, faites un test complet, pas un coup d’œil. Pour un formulaire, soumettez-le vraiment et vérifiez que l’email arrive. Pour un panier, allez jusqu’au paiement test (les passerelles comme Stripe ou PayPal ont un mode "sandbox" gratuit). Pour la recherche, tapez trois mots-clés différents et vérifiez les résultats. C’est fastidieux, c’est la partie la moins glamour de l’audit, c’est aussi celle qui évite les catastrophes.

6. Sauvegarder, puis tester votre sauvegarde

Avant de toucher au site de production, sauvegarde complète. Base de données ET fichiers. Une sauvegarde de la base seule ne suffit pas : si un thème a été modifié ou un plugin remplacé, vous perdrez ces changements. Une sauvegarde des fichiers seule ne suffit pas non plus : c’est la base qui contient vos articles, vos commentaires, vos commandes, vos utilisateurs. Les deux ensemble. Stockez-les dans deux endroits différents (pas seulement sur le serveur d’origine), par exemple chez votre hébergeur via JetBackup, plus une copie sur un cloud externe comme pCloud ou Google Drive.

Et surtout, testez la restauration. C’est l’étape que tout le monde saute. Prenez votre sauvegarde, et restaurez-la dans la préproduction en repartant de zéro. Si la restauration échoue, mieux vaut le découvrir maintenant qu’au moment où votre site est cassé. Une sauvegarde qu’on n’a jamais testée, c’est une sauvegarde dont on ignore si elle marche.

7. Documenter votre plan de retour en arrière

Si tout casse une heure après la mise à jour, vous n’aurez ni le temps ni la sérénité d’inventer la procédure de retour en arrière sur le moment. Écrivez-la avant. Une page A4 suffit. Quels critères déclenchent le retour en arrière (erreur fatale PHP visible, formulaire de paiement KO, login admin impossible, temps de chargement multiplié par deux). Quelles commandes exactes exécuter pour restaurer la sauvegarde. Combien de temps ça prend (chronométrez-le en préproduction). Qui notifier si on doit basculer en mode maintenance.

Mettez cette page A4 dans un endroit accessible sans connexion à votre site (sur votre ordinateur, dans un cloud, imprimée). Quand le site est planté, vous n’avez pas envie de chercher où vous aviez bien pu ranger les identifiants FTP ou le mot de passe de votre tableau d’hébergement. Préparer ce plan prend trente minutes une fois, vous évite trois heures de panique le jour J.

8. Surveiller le site les jours suivant la migration

La migration s’est bien passée, le site répond, vous fermez l’ordinateur. Erreur classique. Pendant les 48 heures qui suivent, surveillez trois choses. Premièrement, le journal d’erreurs PHP dans wp-content/debug.log : une erreur qui apparaît seulement quand un visiteur déclenche un comportement particulier (panier abandonné, recherche avec accents, formulaire en plusieurs étapes) ne sera visible qu’en conditions réelles.

Deuxièmement, les performances : mesurez vos pages clés avec un test ponctuel (PageSpeed Insights ou Lighthouse), avant et après la migration. Le rapport Core Web Vitals de Google Search Console confirmera la tendance, mais il agrège 28 jours de données : il ne révélera pas une régression dans les 48 heures. Une dégradation du LCP (le temps qu’il faut pour afficher l’élément principal d’une page) ou du TTFB (le temps que met le serveur à répondre) après une mise à jour, c’est un signal qu’un plugin réagit mal à la nouvelle version. Troisièmement, l’indexation : vérifiez que vos pages clés sont toujours indexées par Google ("Pages" dans Search Console), qu’aucune n’est passée en "Découverte non indexée" ou en erreur 5xx. Un pic d’erreurs serveur visibles côté Google est l’alerte la plus rapide qu’un visiteur tombe sur un site cassé pendant que vous regardez ailleurs.

Mettre à jour PHP sur WordPress : la procédure étape par étape

La migration PHP est une opération qui prend 30 minutes à 2 heures selon la complexité de votre site. Voici la procédure que j’applique systématiquement chez mes clients en formation.

Étape 1 - Faire une sauvegarde complète

Avant toute manipulation PHP, la première chose à faire est de sécuriser votre site. Voici pourquoi c’est non négociable.

Utilisez votre plugin de sauvegarde habituel (UpdraftPlus, BackWPup, Duplicator) ou la sauvegarde automatique de votre hébergeur. Sur O2switch, JetBackup crée des snapshots quotidiens accessibles depuis cPanel.

Vérifiez que votre sauvegarde est bien complète et téléchargeable. Ne vous contentez pas de "la sauvegarde a été créée" - vérifiez que vous pouvez la restaurer.

Étape 2 - Mettre à jour WordPress, plugins et thèmes

Mettez à jour WordPress, tous vos plugins et votre thème à leurs dernières versions AVANT de changer la version PHP. Les mises à jour récentes incluent souvent des corrections de compatibilité PHP 8. Si vous changez PHP avant de mettre à jour, vous risquez de cumuler deux sources d’incompatibilité.

Étape 3 - Vérifier la compatibilité des plugins

C’est l’étape la plus importante. Tous les plugins ne sont pas compatibles PHP 8. Voici comment vérifier :

• Sur wordpress.org, chaque page plugin indique la version PHP testée (colonne de droite)
• Le plugin PHP Compatibility Checker, longtemps conseillé, n’est plus suivi (testé jusqu’à WordPress 6.4, il ne contrôle que jusqu’à PHP 8.0) : ne vous fiez pas à son verdict. Extensions, thème enfant, functions.php et mu-plugins se testent en préproduction, journal d’erreurs activé

Les plugins qui posent le plus souvent problème : ceux qui n’ont pas été mis à jour depuis plus de 2 ans, les plugins "maison" avec du code personnalisé, et les thèmes qui utilisent des fonctions PHP dépréciées.

Étape 4 - Tester sur un environnement de staging

Le staging, c’est votre filet de sécurité. On teste d’abord, on migre ensuite.

• O2switch : utilisez le sous-domaine gratuit inclus
• OVH : clonez votre hébergement sur un sous-domaine
• Local WP : importez votre site en local et changez la version PHP dans les paramètres du site

Sur le staging, changez la version PHP et naviguez sur le site. Testez le front, le back-office, les formulaires, le panier WooCommerce si applicable. Consultez le fichier debug.log (activez WP_DEBUG et WP_DEBUG_LOG) pour repérer les warnings et erreurs PHP.

Étape 5 - Basculer en production

Tests validés ? Basculez en production. La procédure varie selon votre hébergeur :

• O2switch (cPanel) : cPanel → MultiPHP Manager → sélectionnez votre domaine → choisissez PHP 8.3 → Appliquer
• OVH : Espace client → Hébergement → Configuration PHP → Modifier la version
• Infomaniak : Manager → Hébergement web → PHP/CGI → Version PHP
• Autre hébergeur : cherchez "PHP version" dans votre panel d’administration

Le changement est instantané. Vérifiez immédiatement que votre site fonctionne correctement après la bascule.

Les incompatibilités PHP 8 les plus fréquentes

Si votre site affiche une erreur après la migration, c’est presque toujours l’un de ces problèmes.

Les fonctions dépréciées

PHP 8 a supprimé ou déprécié plusieurs fonctions que le vieux code WordPress utilisait couramment. Les plus fréquentes :

• create_function() → remplacée par les fonctions anonymes (closures)
• each() → remplacée par foreach
• mysql_* fonctions (supprimées dès PHP 7.0) → remplacées par mysqli_* ou PDO (déjà fait dans le core WordPress, mais pas dans tous les plugins)

Le typage strict

PHP 8 est beaucoup plus strict sur les types. Depuis PHP 8.1, passer null à une fonction native de PHP qui attend un string déclenche une dépréciation au lieu d’être silencieusement converti : ce n’est pas encore une erreur, mais c’est la source numéro un des "Deprecated" dans les logs après migration.

Le core WordPress a corrigé la plupart de ces cas. Mais les plugins et thèmes tiers n’ont pas tous fait le ménage. Si vous voyez des messages Passing null to parameter #1 ($string) of type string is deprecated (le numéro et le nom du paramètre varient) dans votre debug.log, contactez le développeur du plugin concerné ou cherchez une alternative.

Les named arguments

Certains plugins utilisent les noms internes des paramètres de fonctions WordPress (comme wp_mail( to: $email )). Si WordPress renomme un paramètre interne, le plugin casse. Ce n’est pas courant, mais ça arrive - surtout avec du code qui essaie d’être "trop malin".

Cas particulier : WooCommerce et PHP 8

WooCommerce mérite une section dédiée parce que c’est le plugin le plus complexe de l’écosystème WordPress - et le plus sensible aux changements PHP.

WooCommerce (version 11.2 en octobre 2026) recommande PHP 8.3 ou plus et n’est testé que jusqu’à PHP 8.4 : pour une boutique, attendez avant de passer en PHP 8.5. Si vous êtes à jour, la migration PHP devrait se passer sans accroc pour le plugin lui-même. Le risque vient des extensions WooCommerce tierces (passerelles de paiement, plugins d’expédition, intégrations ERP) qui n’ont pas toujours suivi.

Ma recommandation : si vous avez une boutique WooCommerce en production, testez chaque extension sur le staging. Passez une commande test complète - de l’ajout au panier au paiement - avant de basculer en production. Un plugin de paiement cassé, c’est des ventes perdues.

Quelle version de PHP choisir pour WordPress en 2026 ?

WordPress recommande PHP 8.3 ou plus. Si vos plugins posent problème sur 8.3, descendre d’un cran ne vous dépannera plus longtemps : PHP 8.2 perd ses correctifs de sécurité le 31 décembre 2026.

• PHP 8.5 : prise en charge par WordPress 7.0 et 7.1, support actif jusqu’en décembre 2027 et correctifs de sécurité jusqu’en décembre 2029, mais WooCommerce n’est testé que jusqu’à PHP 8.4
• PHP 8.4 : support actif jusqu’au 31 décembre 2026, puis correctifs de sécurité jusqu’en décembre 2028
• PHP 8.3 : version minimale recommandée par WordPress, correctifs de sécurité jusqu’en décembre 2027 (support actif terminé fin 2025)
• PHP 8.2 : correctifs de sécurité jusqu’au 31 décembre 2026 seulement, à quitter avant cette date
• PHP 8.1 : stable et largement compatible, support sécurité terminé en décembre 2025 - à éviter désormais
• PHP 8.0 : fin de vie depuis novembre 2023 - évitez
• PHP 7.4 : minimum pour WP 7, mais fin de vie depuis novembre 2022 - uniquement si rien d’autre ne fonctionne

Je vous conseille de viser PHP 8.3 ou 8.4 d’emblée. Si un plugin bloque, PHP 8.2 ne vous dépannera que jusqu’au 31 décembre 2026 : remplacez plutôt ce plugin. Ne restez pas sur PHP 7.4 "par sécurité" - c’est l’inverse de la sécurité.

Après la migration : optimisations PHP

Une fois en PHP 8.3, quelques réglages supplémentaires maximisent les performances.

OPcache

Vérifiez que OPcache est activé. C’est le cas par défaut chez la plupart des hébergeurs, mais ça vaut le coup de vérifier. OPcache compile le code PHP et le met en cache - le gain est de 30 à 50 % sur le temps de génération des pages.

Memory limit

WordPress recommande 256 Mo de mémoire PHP. Si vous êtes encore à 128 Mo, augmentez dans wp-config.php :

define( 'WP_MEMORY_LIMIT', '256M' );

Ajoutez cette ligne avant la ligne qui commence par /* That's all, stop editing!. Elle n’a d’effet que si votre hébergeur autorise ce réglage : vérifiez ensuite la ligne "Limite de mémoire PHP" dans Outils > Santé du site > Informations > Serveur (pas celle réservée aux écrans d’administration) et, si elle reste en dessous de 256M, demandez à votre hébergeur d’augmenter memory_limit.

Max execution time

Certaines opérations WordPress (import, mise à jour de masse, regénération de miniatures) nécessitent plus de 30 secondes. Si votre hébergeur le permet, passez à 120 secondes depuis son panneau, via php.ini ou, en PHP-FPM, via un fichier .user.ini (max_execution_time = 120) ; la directive php_value du fichier .htaccess ne fonctionne qu’avec PHP en module Apache.

Questions fréquentes

Que se passe-t-il si je mets à jour WordPress 7.0 sans changer de version PHP ?

Si vous êtes en PHP 7.2 ou 7.3, WordPress ne vous laisse pas installer la version 7 : l’écran des mises à jour indique qu’elle exige PHP 7.4. Votre site reste alors sur la branche 6.9, qui reçoit encore des correctifs de sécurité quand c’est possible. Pour passer en 7.x, montez d’abord PHP en 7.4 au minimum, idéalement 8.3. En PHP 7.4, WordPress 7 fonctionnera normalement.

Mon hébergeur ne propose pas PHP 8.3, que faire ?

Vérifiez les versions disponibles dans votre panel. La plupart des hébergeurs majeurs (O2switch, OVH, Infomaniak, Hostinger) proposent PHP 8.3 depuis fin 2024, et PHP 8.4 est devenu le choix par défaut chez beaucoup d’entre eux en 2026. Si votre hébergeur ne propose même pas PHP 8.3, c’est un signal d’alarme : il est peut-être temps de changer d’hébergeur. Un prestataire qui ne suit pas les versions PHP met en danger la sécurité de votre site.

Puis-je revenir à PHP 7.4 après avoir migré vers PHP 8 ?

Techniquement oui, le changement de version PHP est réversible instantanément depuis le panel de votre hébergeur. Mais je le déconseille, même quelques heures : PHP 7.4 ne reçoit plus de correctifs officiels depuis novembre 2022, et les failles PHP2Shell d’octobre 2026 n’y sont bouchées que si votre hébergeur a appliqué lui-même un rétroportage. Si votre site casse après la migration, revenez plutôt à une version 8.x encore maintenue ou restaurez votre sauvegarde, identifiez le plugin ou thème incompatible, puis retentez. C’est pour ça que le test sur staging est important.

Le passage à PHP 8 améliore-t-il le score PageSpeed ?

Indirectement, oui. PHP 8 réduit le TTFB (Time To First Byte), ce qui améliore le Largest Contentful Paint (LCP) - un des trois Core Web Vitals. L’amélioration dépend de la complexité de votre site : un blog simple gagnera 50-100ms, un WooCommerce lourd peut gagner 200-400ms. Ce n’est pas spectaculaire sur un test isolé, mais l’effet cumulé sur l’expérience utilisateur et le SEO est réel.

Mes fichiers functions.php et mu-plugins sont-ils concernés ?

Oui. Tout code PHP personnalisé est concerné. Vérifiez que votre functions.php n’utilise pas de fonctions dépréciées (create_function(), each(), etc.) et que vos mu-plugins sont compatibles PHP 8. Le PHP Compatibility Checker, lui, n’analyse pas ces fichiers (seulement les extensions et thèmes publiés sur wordpress.org) : testez-les en préproduction avec le journal d’erreurs activé.

WordPress 7.0 exigera-t-il PHP 8 dans le futur ?

Probablement un jour, mais aucune date n’est fixée. L’équipe Core n’a planifié aucune nouvelle hausse du minimum : elle suit l’usage des versions PHP, et une version n’est envisagée pour l’abandon qu’une fois tombée sous 5 % des sites. Autant anticiper maintenant plutôt que de revivre la même migration plus tard. PHP 8.3 vous donne de la marge jusqu’en 2027.

La migration PHP casse-t-elle mon thème enfant ?

Ça dépend du code dans votre functions.php enfant. Si vous avez copié des fonctions du thème parent il y a plusieurs années, elles utilisent peut-être des syntaxes PHP dépréciées. Vérifiez en priorité les appels à create_function() et les passages de null à des fonctions string. Le PHP Compatibility Checker ne les détecte pas : il n’analyse que les extensions et thèmes publiés sur wordpress.org, sans exécuter leur code. Testez votre thème enfant en préproduction avec le journal d’erreurs activé. Si votre thème enfant ne contient que du CSS, aucun risque.

PHP 8.4 et 8.5 sont-ils compatibles avec WordPress ?

Oui. PHP 8.4, disponible depuis novembre 2024, est pris en charge depuis WordPress 6.7, et PHP 8.5, sorti en novembre 2025, depuis WordPress 6.9 ; WordPress a retiré en mai 2026 le label "beta" qui accompagnait ces versions. La compatibilité des plugins tiers est moins garantie, et WooCommerce n’est testé que jusqu’à PHP 8.4. Pour un site en production, PHP 8.3 ou 8.4 reste le choix le plus sûr en octobre 2026.

Et après ? Une fois la migration PHP terminée, le prochain chantier est souvent la performance globale. Un PHP à jour combiné à un bon plugin de cache (LiteSpeed Cache, WP Super Cache) et un CDN transforme radicalement l’expérience de vos visiteurs. Si vous n’avez pas encore audité la sécurité de votre installation, c’est aussi le bon moment - un PHP à jour, c’est la base, mais ce n’est pas tout…