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 vous ne la faites pas avant le 9 avril 2026, la mise à jour automatique vers WordPress 7 pourrait casser votre site. Pour les nouveautés de WordPress 7 au-delà de PHP (notamment la collaboration en temps réel, désormais optionnelle), consultez notre guide WordPress 7.0.

En tant que formateur WordPress 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 mars 2026.

Les versions PHP et WordPress 7.0

WordPress 7.0, prévu pour le 9 avril 2026, fixe de nouvelles exigences :

• PHP 7.2 et 7.3 : support abandonné – votre site ne fonctionnera plus correctement
• 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 et stables
• PHP 8.3 : version recommandée par WordPress – performances et sécurité au rendez-vous
• PHP 8.4/8.5 : supportées en beta depuis WordPress 6.9 – à surveiller

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, environ 5 % des sites WordPress tournent encore sur PHP 7.2 ou 7.3 en mars 2026. C’est peu en pourcentage, mais ça représente des dizaines de millions 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"

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 compile le bytecode en code machine natif, ce qui accélère les opérations lourdes comme la génération de pages complexes. 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 – Google utilise le TTFB comme signal de classement. Et avec OPcache activé, les gains montent facilement à 30-50 %.

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 actifs jusqu’en décembre 2027. Trois ans de tranquillité supplémentaire. On l’oublie trop souvent, mais un PHP obsolète est la porte d’entrée la plus simple pour un attaquant…

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.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_LOG dans wp-config.php pendant 24 heures, et regardez le fichier wp-content/debug.log : si des messages "Deprecated" apparaissent, vous savez exactement ce qu’il faut corriger.

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, pas sur le site que voient vos visiteurs. Beaucoup d’hébergeurs proposent ce clonage en un clic : O2switch, OVH, Kinsta, Infomaniak, LWS le font. Si le vôtre ne le fait pas, le plugin gratuit WP Staging crée une copie en cinq minutes.

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 : ouvrez Google Search Console (rubrique "Performances", "Expérience sur la page") et regardez les "Signaux Web essentiels" (Core Web Vitals). 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.

Procédure de migration é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 Developer inclut un vérificateur de compatibilité PHP
• Le plugin PHP Compatibility Checker scanne votre site et signale les incompatibilités

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 → 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. Passer null à une fonction qui attend un string génère désormais un warning au lieu d’être silencieusement converti. C’est la source numéro un des "Deprecated"et"Warning" 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 warnings null to string conversion 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 8.x supporte PHP 8.3. 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.

PHP 8.3, 8.2 ou 8.1 : quelle version choisir ?

WordPress recommande PHP 8.3. Mais si vos plugins posent problème sur 8.3, descendre d’un cran est acceptable.

• PHP 8.3 : version recommandée, support actif jusqu’en décembre 2027, meilleure performance
• PHP 8.2 : excellente option, support sécurité jusqu’en décembre 2026
• 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

Mon conseil : visez PHP 8.3 d’emblée. Si un plugin bloque, testez PHP 8.2. 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' );

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 via .htaccess ou php.ini.

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 7 affichera un avertissement et certaines fonctionnalités pourraient ne pas fonctionner. WordPress ne bloque pas la mise à jour, mais des erreurs fatales peuvent se produire sur des fonctions qui utilisent du code PHP 7.4+. 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 ?

Oui, le changement de version PHP est réversible instantanément depuis le panel de votre hébergeur. Si votre site casse après la migration, revenez à la version précédente, 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 scanne aussi ces fichiers.

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

Probablement. L’équipe Core a annoncé que le minimum passerait progressivement de PHP 7.4 à PHP 8.0 dans une prochaine version majeure. Autant anticiper maintenant plutôt que de revivre la même migration dans 12 mois. 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 détecte ces cas automatiquement. Si votre thème enfant ne contient que du CSS, aucun risque.

PHP 8.4 et 8.5 sont-ils compatibles avec WordPress ?

PHP 8.4 est disponible depuis novembre 2024 et fonctionne bien avec WordPress 6.8+. PHP 8.5, sorti en 2026, bénéficie d’un support beta depuis WordPress 6.9. Les deux versions offrent des gains de performance supplémentaires par rapport à PHP 8.3, mais la compatibilité des plugins tiers est moins garantie. Pour un site en production, PHP 8.3 reste le choix le plus sûr en mars 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…