Pour choisir la version PHP de votre site WordPress, vérifiez trois choses : son support de sécurité, sa compatibilité avec votre installation et sa disponibilité chez l’hébergeur. Le changement se fait côté hébergement, pas dans le bouton « Mettre à jour WordPress ». Préparez une copie de test et un retour arrière avant de basculer le site en ligne.
Deux couches, deux mises à jour
Ce guide concerne le choix et le changement de PHP. Pour installer une nouvelle version du cœur, d’un thème ou d’une extension, suivez plutôt la méthode pour mettre à jour WordPress et vérifier son site. Les deux opérations peuvent être liées, mais elles ne se confondent pas.
Où trouver la version PHP utilisée par WordPress ?
Connectez-vous à l’administration, puis ouvrez Outils → Santé du site → Informations → Serveur. Relevez la ligne « Version de PHP ». Elle indique l’environnement utilisé par cette installation lors de la consultation.
Repère d’interface — illustration pédagogique
- Version de PHP
- 8.x.y ← la ligne à relever
- Limite de mémoire PHP
- Autre réglage, pas une version
Si vous gérez plusieurs sites, contrôlez chacun d’eux. Une valeur par défaut dans le compte d’hébergement ne prouve pas que tous les domaines utilisent cette même version. Une règle propre à un site peut modifier le comportement.
Pas d’accès à l’administration ?
Consultez le réglage PHP du domaine dans l’espace d’hébergement ou demandez sa vérification au support. Précisez le site concerné, pas seulement le nom du compte. Il n’est pas nécessaire de créer un fichier public phpinfo() : il peut exposer des informations techniques sur le serveur.
Quelle version PHP choisir pour WordPress ?
La bonne version n’est ni la plus ancienne qui fonctionne, ni automatiquement la plus récente proposée. Retenez une branche encore maintenue, compatible avec le cœur et les composants de votre site. Les prérequis actuels de WordPress recommandent PHP 8.3 ou supérieur ; cette recommandation ne valide pas toutes vos extensions.
| Branche | Support de sécurité jusqu’au | Ce que cela change pour votre choix |
|---|---|---|
| PHP 8.2 | 31 décembre 2026 | Échéance proche : prévoir la transition plutôt qu’en faire une cible durable. |
| PHP 8.3 | 31 décembre 2027 | Correspond au niveau recommandé par WordPress ; vérifier aussi les composants. |
| PHP 8.4 | 31 décembre 2028 | Candidat possible si la version de WordPress, le thème et les extensions le permettent. |
| PHP 8.5 | 31 décembre 2029 | À examiner avec la matrice de compatibilité et un test du site, pas à activer par défaut. |
| PHP 8.1 et antérieur | Support communautaire terminé | Organiser une sortie de ces branches ; un support commercial éventuel est distinct. |
Repères vérifiés le 23 octobre 2026 sur le calendrier officiel de support PHP. Utilisez aussi les correctifs disponibles dans la branche retenue. Ces dates ne garantissent ni la compatibilité ni l’absence de vulnérabilité.
Compatible, recommandé et maintenu : trois questions différentes
Un site peut encore s’ouvrir sur une branche qui ne reçoit plus de correctifs. À l’inverse, une branche récente peut être maintenue sans convenir à une ancienne extension. Avant de choisir, croisez ces trois contrôles :
- Le langage : la branche reçoit-elle encore des correctifs de sécurité ?
- Le cœur WordPress : que dit la matrice officielle de compatibilité WordPress/PHP pour votre version précise ?
- Le site complet : thème, extensions et code personnalisé sont-ils compatibles et testés ?
Exemple pédagogique : si une extension essentielle ne fonctionne pas avec la branche envisagée, l’activation en production n’est pas le bon test. Vérifiez sa documentation, recherchez une version compatible ou préparez son remplacement sur une copie. Le simple fait que le cœur accepte PHP ne suffit pas.
Que préparer avant de changer PHP ?
Le changement est parfois rapide dans l’interface ; ses conséquences peuvent toucher tout le site. Préparez l’état de départ, les accès et la possibilité de revenir. Le guide de sauvegarde et de restauration WordPress détaille les copies des fichiers et de la base, sans remplacer la conservation des réglages d’hébergement.
- Noter la configuration actuelle : version PHP complète, modules chargés et réglages particuliers utiles au site.
- Identifier la portée du réglage : un domaine, un dossier ou l’ensemble du compte d’hébergement.
- Vérifier le retour arrière : ancienne version encore disponible, procédure connue et accès fonctionnel même si WordPress ne démarre plus.
- Vérifier les compatibilités : cœur, thème, extensions et code ajouté au site ; traiter les composants abandonnés avant la bascule.
- Choisir un créneau adapté : interlocuteur disponible, fonctions sensibles identifiées et données nouvelles à préserver.
Si le site doit d’abord recevoir des mises à jour, séparez les changements et leurs vérifications. Modifier PHP, remplacer le thème et mettre à jour toutes les extensions en même temps rend un incident plus difficile à isoler.
Une sauvegarde WordPress ne sauvegarde pas forcément PHP. Restaurer les fichiers et la base ne remet pas automatiquement l’environnement serveur dans son état précédent. Le plan de reprise doit couvrir les deux.
Comment vérifier la compatibilité avant la bascule ?
Préparez une copie protégée du site, puis faites-lui utiliser la branche PHP envisagée. Reprenez les modules et réglages nécessaires avec l’hébergeur. Un outil de détection de compatibilité peut fournir des pistes ; il ne remplace pas l’essai des fonctions réellement utilisées.
Le test doit suivre votre activité
Une version représentative du site, à accès protégé.
La version PHP cible et ses dépendances.
Les pages et actions importantes pour votre activité.
Avant les essais, empêchez la copie de déclencher de vrais e-mails, paiements ou échanges métier. Utilisez les modes de test prévus et contrôlez les connexions aux services externes. Une copie qui renvoie vers les données du site réel n’est pas un terrain d’essai isolé.
Les vérifications à adapter au site
- Affichage : pages principales, menu mobile, gabarits et contenus dynamiques.
- Administration : connexion, ouverture de l’éditeur et enregistrement d’un contenu de test.
- Contact : soumission du formulaire et réception réelle de sa notification dans le scénario prévu.
- Fonctions métier : recherche, espace connecté, réservation ou panier en environnement de test.
- Traces : journaux correspondants aux essais, sans afficher les erreurs aux visiteurs.
Un test bloquant doit être compris avant de passer en ligne. Gardez l’observation précise : action effectuée, heure, message et composant cité. N’en déduisez pas automatiquement que toutes les extensions doivent être désactivées.
Comment changer la version PHP chez l’hébergeur ?
Ouvrez l’espace de gestion de l’hébergement et repérez les réglages PHP. Les menus et la portée de la modification dépendent de l’offre : un sélecteur par domaine n’a pas le même effet qu’une version globale pour plusieurs sites. Vérifiez ce point avant de valider.
- Sélectionner le bon périmètre : compte, domaine ou dossier concerné, selon la documentation de l’hébergeur.
- Choisir la branche déjà testée : pas une autre version simplement parce qu’elle apparaît en tête de liste.
- Contrôler les modules PHP et options : ne pas désactiver des modules inconnus ni réinitialiser les réglages au hasard.
- Enregistrer le changement : suivre le bouton et le délai de prise en compte indiqués par l’offre.
- Retourner dans Santé du site : vérifier la version réellement utilisée, puis effectuer la recette du site en ligne.
Les modules PHP ne sont pas les extensions WordPress. Ils font partie de l’environnement d’exécution ; leur présence peut conditionner une connexion à la base, le traitement d’images ou une intégration. Changer de branche peut nécessiter de vérifier leur disponibilité.
Exemple : le sélecteur PHP d’o2switch
La documentation du sélecteur PHP d’o2switch présente le choix de version, le bouton « Apply », les modules et les options. Ce n’est pas une procédure universelle : cet outil peut concerner plusieurs sites du compte, avec des règles particulières par dossier. Faites confirmer la portée si vous hébergez plusieurs installations.
Les versions visibles dans une ancienne capture de documentation ne constituent pas une recommandation. Le choix doit rester celui validé pour votre site, en tenant compte du support actuel de PHP.
Le réglage n’existe pas dans votre interface ou la version souhaitée n’est pas proposée ? Demandez au support quelles versions sont disponibles pour ce domaine et comment revenir à la précédente. Ne remplacez pas la procédure par une ligne .htaccess trouvée pour un autre hébergeur.
Que vérifier après le changement, et si le site casse ?
Commencez par confirmer la version dans WordPress, puis rejouez les fonctions testées sur la copie. L’accueil qui s’ouvre ne valide pas l’envoi d’un formulaire, un enregistrement ou un paiement. Conservez les observations avant et après l’intervention.
La décision suit le contrôle
Version, configuration, date et parcours vérifiés.
Retour temporaire si possible, puis analyse de compatibilité.
Si un problème apparaît juste après la bascule, relevez son heure et son message. Un code HTTP 500 ne désigne pas à lui seul la cause. Le guide sur l’erreur critique WordPress explique comment rapprocher le message et les journaux sans accuser trop vite un composant.
Revenir sans perdre les nouvelles données
Si l’ancienne version reste disponible et que le plan de reprise le prévoit, réactivez temporairement la version et la configuration précédentes, puis retestez le parcours. Si l’administration est inaccessible, le changement se fait toujours chez l’hébergeur.
Ne restaurez pas automatiquement une ancienne base de données : des commandes ou messages ont pu être enregistrés depuis. Si une restauration devient nécessaire, il faut traiter ces données récentes. Un retour sur une branche non maintenue reste une mesure transitoire, pas la fin de la correction.
Si la version affichée n’a pas changé, vérifiez le domaine sélectionné et l’enregistrement du réglage avec le support. Des règles propres au site ou un environnement distinct pour les tâches planifiées peuvent intervenir. Ne supprimez pas de fichiers de configuration pour essayer.
Quand déléguer le changement de PHP ?
Demandez une aide ciblée si vous n’avez pas de copie de test, si le retour arrière est incertain ou si une fonction essentielle n’est plus compatible. Une assistance WordPress ponctuelle permet de cadrer cette intervention. Si le site est déjà en panne, présentez plutôt la situation pour un dépannage du site internet.
- À transmettre : l’adresse du site, la version PHP relevée et le changement envisagé.
- À préciser : l’hébergeur, les autres sites potentiellement concernés et les fonctions à préserver.
- À signaler : les essais effectués, les incompatibilités connues et les possibilités de reprise.
Le suivi des versions peut aussi s’inscrire dans une maintenance WordPress, selon le périmètre convenu : surveillance des échéances, préparation des évolutions et contrôles. Une montée de version qui demande de remplacer du code ou un composant peut nécessiter un travail distinct. Présentez-moi votre site et le besoin à vérifier.
Questions fréquentes sur la version PHP de WordPress
Une mise à jour PHP va-t-elle forcément accélérer mon site ?
Non. L’effet dépend des versions comparées, du code exécuté et de l’environnement. Une lenteur peut aussi venir des images, des scripts ou d’un service distant. Mesurez le parcours concerné avant et après ; le guide WordPress lent aide à distinguer ces pistes.
« Mise à jour de PHP nécessaire » veut-il dire que le site est piraté ?
Non. L’alerte concerne l’environnement utilisé ; elle ne prouve pas un piratage. Relevez la version exacte et son support, puis préparez une transition compatible. Une anomalie de contenu ou un compte inconnu demande une investigation distincte.
Puis-je changer PHP directement dans WordPress ?
Le changement relève de l’hébergement. WordPress permet de consulter la version utilisée, mais son écran de mises à jour ne remplace pas le réglage serveur. Certaines offres proposent une intégration : confirmez quand même le domaine concerné, la portée et le retour arrière.
Pourquoi mon site fonctionne-t-il mais pas une tâche planifiée ?
Une tâche lancée en ligne de commande peut utiliser un autre exécutable PHP que celui du site web. Faites vérifier sa commande, sa version et ses dépendances par l’hébergeur ou le prestataire. La valeur affichée dans Santé du site ne valide pas tous les processus du compte.
Sources et documentation
Les versions et interfaces évoluent. Ces sources servent à vérifier le choix au moment de l’intervention, en complément des exigences des composants installés.
