Pour choisir la version PHP de WordPress, partez de ce que votre site sait exécuter. WordPress recommande PHP 8.3 ou supérieur ; cela ne signifie ni que PHP 8.3 est obligatoire, ni que PHP 8.5 convient à toutes les extensions. Pour un site existant sans validation de PHP 8.5, notre recommandation est de tester PHP 8.4 en premier. Pour un site neuf dont les composants sont validés, PHP 8.5 offre une durée de maintenance plus longue. Un site déjà sous PHP 8.3 peut préparer cette transition sans être traité comme un site en fin de support. Le choix se tranche avec trois éléments : le calendrier officiel, les dépendances installées et les fonctions métier réellement testées.
À retenir
- Le minimum recommandé par WordPress et la meilleure cible pour votre site sont deux décisions différentes.
- La compatibilité du cœur ne certifie pas celle des extensions.
- Une copie de préproduction sert à tester les formulaires, les commandes et les traitements différés.
- Le retour à l'ancienne version PHP et la restauration d'une sauvegarde sont deux opérations distinctes.
Sommaire
- Quelle version choisir
- Dates de fin de support
- Compatibilité du cœur et des extensions
- Version réellement utilisée
- Fonctions à tester
- Bascule et retour arrière
- Gains de performance
- Réglages et périmètre Tomco
- Questions fréquentes
En un coup d'œil — choix conseillé au 7 septembre 2026
| Situation du site WordPress | Choix conseillé | Condition déterminante |
|---|---|---|
| Site existant, compatibilité PHP 8.5 non établie | Tester PHP 8.4 | Valider le thème, les extensions et les fonctions métier |
| Site neuf ou pile entièrement validée sous PHP 8.5 | Choisir PHP 8.5 | Cœur WordPress compatible et essais concluants |
| Site fonctionnel sous PHP 8.3 | Préparer la montée de version | Prévoir les tests, sans bascule précipitée |
| Boutique WooCommerce sans validation spécifique de PHP 8.5 | Tester PHP 8.4 | Vérifier le paiement, la livraison et les tâches différées |
| Site sous PHP 8.2 | Planifier la migration avant sa fin de support | Corriger les dépendances bloquantes avant l'échéance |
| Site sous PHP 8.1, 8.0 ou 7.4 | Sortir de la branche obsolète | Ne pas confondre disponibilité chez l'hébergeur et maintenance officielle |
Quelle version PHP choisir pour WordPress ?
La version PHP à choisir pour WordPress est une branche encore maintenue, prise en charge par le cœur utilisé et compatible avec l'ensemble du site. La recommandation officielle de WordPress fixe PHP 8.3 ou supérieur comme base. Cette recommandation décrit un environnement d'hébergement ; elle ne constitue pas une certification de vos extensions.
Notre préférence pour PHP 8.4 sur un site existant non encore validé sous PHP 8.5 est un choix de préparation, pas une affirmation selon laquelle PHP 8.5 serait instable. Il s'agit d'obtenir une cible documentée par les composants du site et de tester une modification à la fois. Si tous ces composants déclarent la prise en charge de PHP 8.5 et que les essais passent, conserver artificiellement PHP 8.4 n'apporte pas d'avantage établi.
À l'inverse, une extension abandonnée ne devient pas sûre parce qu'elle fonctionne encore sous PHP 8.4. Si elle bloque la migration, la décision porte sur sa correction ou son remplacement. Repousser chaque année le changement d'interpréteur ne résout pas la dépendance qui impose ce retard.
Pour un portefeuille de sites, la bonne unité de décision est le site, pas l'ensemble du compte client. Une boutique avec abonnements et un site de présentation ne présentent pas les mêmes dépendances. Documentez le choix par projet : version actuelle, version cible, composant bloquant éventuel et responsable de sa résolution.
Les dates de fin de support PHP à connaître
Le support de PHP distingue la maintenance active et la période de correctifs de sécurité. Une branche sortie de maintenance active n'est donc pas nécessairement en fin de vie. Les dates ci-dessous proviennent du calendrier officiel PHP, vérifié le 7 septembre 2026.
| Branche PHP | Maintenance active jusqu'au | Correctifs de sécurité jusqu'au |
|---|---|---|
| PHP 8.2 | 31 décembre 2024, terminée | 31 décembre 2026 |
| PHP 8.3 | 31 décembre 2025, terminée | 31 décembre 2027 |
| PHP 8.4 | 31 décembre 2026 | 31 décembre 2028 |
| PHP 8.5 | 31 décembre 2027 | 31 décembre 2029 |
PHP 8.2 demande un calendrier de migration rapproché. PHP 8.3 laisse davantage de temps pour préparer les tests. PHP 8.4 et PHP 8.5 disposent encore d'une maintenance active à la date de ce guide. Dans tous les cas, le numéro de branche ne suffit pas : les versions correctives publiées au sein de cette branche doivent aussi être appliquées.
Une ancienne version peut rester proposée pour faire fonctionner un logiciel historique. Cette disponibilité ne signifie pas que le projet PHP continue à la corriger. Un éventuel support prolongé fourni par un tiers doit être évalué comme un service distinct, avec son propre périmètre.
Cette distinction complète la sécurité de l'infrastructure Tomco : un pare-feu applicatif ou un blocage automatique d'IP ne remplace pas la maintenance de l'interpréteur, du thème ou des extensions.
Compatibilité WordPress : le cœur ne suffit pas
La compatibilité PHP de WordPress porte d'abord sur le cœur du CMS. La matrice officielle WordPress/PHP documente PHP 8.5 à partir de WordPress 6.9, tandis que WordPress 6.8 est documenté jusqu'à PHP 8.4. Vérifiez la ligne de votre version ; ne transposez pas celle d'une version plus récente.
Un site assemble ensuite ce cœur, un thème, des extensions et parfois du code spécifique. Une extension qui ajoute des champs à une commande peut être compatible sur sa page d'administration et échouer au moment d'un remboursement. Une date de mise à jour récente est un indice de maintenance, pas une preuve de compatibilité avec toutes les branches PHP.
Le cas WooCommerce mérite une vérification séparée. Au 7 septembre 2026, ses prérequis serveur pour WooCommerce 10.8 et versions suivantes recommandent PHP 8.3 ou supérieur et précisent des tests jusqu'à PHP 8.4. Cette mention ne démontre pas que PHP 8.5 échoue ; elle interdit d'affirmer que la documentation valide automatiquement cette cible pour toute boutique.
Pour chaque composant critique, cherchez une déclaration de compatibilité portant sur la version installée, les notes de version et les incidents connus. Un outil d'analyse statique peut aider à repérer du code incompatible, mais il n'exécute ni une commande client ni un renouvellement d'abonnement. La vérification documentaire et le test fonctionnel répondent à deux questions différentes.
Vérifier la version PHP réellement utilisée
La version PHP qui compte pour les visiteurs est celle qui exécute les requêtes du site. Dans l'administration WordPress, ouvrez Outils > Santé du site > Informations > Serveur et relevez la version affichée. Notez également la version de WordPress, le thème actif et les composants qui portent une fonction commerciale.
Avec un accès SSH et WP-CLI disponible, ces commandes donnent deux informations complémentaires :
php -v
wp --infoLa première affiche la version du binaire PHP appelé dans le terminal ; la seconde renseigne l'environnement utilisé par WP-CLI. Elles ne prouvent pas que le serveur web emploie le même interpréteur. Un site peut utiliser PHP 8.4 pour ses pages et un autre binaire pour une tâche planifiée. Après un changement, contrôlez donc aussi les commandes cron et les traitements lancés hors du navigateur.
Pour établir l'inventaire, placez-vous dans le répertoire du site, puis utilisez la commande officielle de liste des extensions WP-CLI :
wp plugin list --fields=name,status,version,update,requires_phpLe champ requires_php indique une exigence minimale déclarée, pas la version maximale testée. Une valeur ancienne ou absente n'autorise aucune conclusion sur PHP 8.5. Conservez les extensions obligatoires, les extensions réseau et les composants de cache dans l'inventaire ; ils peuvent intervenir même si vous ne les activez pas depuis l'écran habituel.
Si vous gérez plusieurs domaines, rattachez chaque relevé au domaine concerné. Une capture du sélecteur PHP du compte ne remplace pas la vérification de la valeur réellement vue par chaque installation WordPress.
Tester les fonctions qui font vivre le site
Une préproduction est une copie sur laquelle vous pouvez exécuter le site avec la version PHP cible avant de modifier la production. Sa valeur dépend de sa fidélité : même code, mêmes extensions nécessaires, réglages comparables et données adaptées aux tests. Une copie trop ancienne valide un autre site que celui que vous allez basculer.
Protégez cette copie contre les accès publics et l'indexation. Neutralisez les effets réels : paiements en mode test, messages sortants contrôlés, connecteurs commerciaux et webhooks dirigés vers leurs environnements de test. Cloner une boutique avec ses automatismes actifs peut déclencher des actions indésirables avant même de commencer les essais.
La page d'accueil ne constitue qu'un premier contrôle. Faites porter la validation sur les parcours qui rendent le site utile :
| Fonction | Vérification attendue |
|---|---|
| Connexion et administration | Connexion réussie, droits conservés, édition puis enregistrement d'une page |
| Formulaire | Envoi traité, confirmation affichée et réception contrôlée |
| Médias | Téléversement d'une image et génération des formats utilisés |
| Commerce | Panier, livraison, paiement de test, état de commande et confirmation |
| Traitements différés | Exécution d'une tâche représentative, sans erreur dans les journaux |
| Intégrations | Échange contrôlé avec les services externes indispensables |
Comparez les journaux avant et après le changement pour ne pas attribuer à PHP un défaut déjà présent. Distinguez les avertissements de dépréciation, les erreurs qui interrompent une requête et les résultats fonctionnels incorrects sans erreur visible.
Le critère de validation doit être écrit : par exemple, une commande de test atteint l'état attendu et sa confirmation arrive. « Le site s'affiche » est trop vague pour décider du passage en production. Conservez le résultat, la version testée et la date avec le dossier du site.
Changer de version PHP et prévoir le retour arrière
Changer de version PHP consiste à modifier l'interpréteur affecté au site depuis l'hébergement. Avant la bascule, relevez le réglage précédent, confirmez qu'il reste sélectionnable et préparez une sauvegarde récente des fichiers et de la base, dont vous savez vérifier la restauration. Choisissez un créneau où vous pouvez contrôler les fonctions critiques immédiatement après.
Évitez de cumuler dans la même intervention changement PHP, mise à jour majeure du thème et remplacement d'une extension. Préparez les mises à jour nécessaires, validez-les séparément, puis changez PHP sur l'ensemble stabilisé. Vous pourrez ainsi attribuer une régression à une modification précise au lieu de comparer deux environnements entièrement différents.
Si seule la version de PHP a changé et qu'une erreur apparaît, revenir à l'interpréteur précédent est le premier essai de rétablissement. Relevez l'heure, le message d'erreur et le composant concerné. Reproduisez ensuite le défaut en préproduction avant une nouvelle tentative.
Une restauration complète de sauvegarde répond à un autre problème : des fichiers ou des données ont été modifiés. Sur une boutique active, restaurer une ancienne base peut effacer des commandes ou des comptes créés depuis la sauvegarde. Ne confondez donc pas « revenir à PHP 8.4 » et « remettre toute la base d'hier ».
Après une bascule réussie, vérifiez la version affichée dans Santé du site, rejouez les parcours critiques et contrôlez les tâches différées. Un défaut peut ne se manifester qu'au prochain export ou à la prochaine exécution d'un abonnement. Le changement de sélecteur marque le début de cette vérification, pas sa fin.
PHP plus récent : quels gains de performance attendre
Une nouvelle version PHP peut modifier le temps d'exécution du code, mais son numéro ne permet pas de promettre un gain précis pour WordPress. Le résultat dépend des extensions, des requêtes à la base, du cache et des fonctions sollicitées. Un benchmark portant sur une autre configuration ne mesure pas votre site.
Pour comparer deux branches, gardez les mêmes données, extensions, réglages et conditions de charge. Mesurez plusieurs passages et comparez les médianes. Distinguez une page servie par le cache d'une requête qui exécute effectivement WordPress : administration, recherche, panier ou page personnalisée pour un utilisateur connecté.
Un bon résultat doit aussi tenir compte des erreurs et de la consommation mémoire. Une baisse de quelques millisecondes n'a aucune valeur si une tâche métier échoue. Inversement, un écart de vitesse imperceptible ne retire pas l'intérêt de rester sur une branche maintenue.
La version PHP est un levier parmi ceux de l'optimisation des performances WordPress. Si le problème vient d'une extension qui multiplie les requêtes ou d'un appel externe lent, changer d'interpréteur ne supprime pas cette cause. Les nouveautés du langage et leur portée sont détaillées dans notre point sur PHP 8.5 et WordPress ; elles ne constituent pas à elles seules un motif de migration immédiate.
Ce que Tomco fournit pour choisir votre version
Chez Tomco, la page des technologies disponibles documente PHP 5.6 à 8.5 et le choix de version depuis Enhance Panel. PHP 8.3 y est annoncé comme défaut recommandé pour les nouvelles installations. C'est le réglage de départ de l'hébergement ; le choix d'une cible PHP 8.4 ou 8.5 reste à établir pour le site concerné.
La présence de branches historiques dans le sélecteur permet de traiter des besoins de compatibilité. Elle ne signifie pas que ces branches ont retrouvé un support officiel. Pour un projet neuf, partez d'une branche maintenue et de composants compatibles, plutôt que de recréer une dépendance à une ancienne version.
Les offres d'hébergement WordPress de Tomco annoncent une préproduction WordPress à partir de Pro et des sauvegardes quotidiennes conservées 90 jours. Le premier dispositif fournit un cadre pour les essais ; le second apporte un historique. Avant une intervention, vérifiez néanmoins le contenu et la date de votre copie de sécurité : une sauvegarde quotidienne peut précéder les dernières modifications importantes.
L'accès à ces outils ne constitue pas une validation automatique des extensions. La préparation des tests, la maintenance applicative et le contrôle après bascule dépendent de qui administre le site et du périmètre de prestation convenu. Pour préparer une demande technique exploitable, indiquez le domaine, les versions actuelle et cible, le composant bloquant et le résultat obtenu sur la copie de test.
