- Inventorier les versions utilisées par le site, les tâches et les applications voisines.
- Vérifier la couverture des correctifs actuels auprès de l’hébergeur.
- Choisir une branche cible et tester le changement sur une copie représentative.
Pourquoi agir avant la fin décembre
PHP exécute une grande partie de WordPress côté serveur. Il intervient quand une page est générée, quand un formulaire est traité ou quand une tâche produit un fichier. D’après le calendrier officiel de PHP, la branche 8.2 reçoit des correctifs de sécurité jusqu’au 31 décembre 2026. Cette échéance concerne le support du projet PHP. Si votre prestataire annonce une couverture prolongée, demandez un écrit qui précise la durée, les composants couverts et le moyen de vérifier les correctifs. Un site peut continuer à fonctionner après l’échéance tout en étant plus difficile à maintenir.
Le projet PHP annonce la fin du support officiel de PHP 8.2 au 31 décembre 2026. Si votre site WordPress tourne sur cette branche, demandez dès maintenant quelle version sert réellement vos pages et quels correctifs sont appliqués. Deux décisions se prennent séparément : corriger l’installation actuelle et organiser le passage vers une branche encore maintenue, avec une recette des fonctions qui comptent pour votre activité.
Il y a aussi une raison immédiate de vérifier votre version. Le projet a publié PHP 8.2.35 le 21 octobre 2026 pour corriger deux vulnérabilités critiques susceptibles de permettre l’exécution de code à distance dans les conditions précisées par le bulletin. Si votre hébergement affiche une version plus ancienne, faites confirmer sans attendre si les correctifs correspondants ont été appliqués. Une distribution peut conserver un numéro apparent différent et intégrer des correctifs dans son paquet. Demandez une référence vérifiable plutôt que de déduire la couverture du seul numéro affiché. Consultez les notes officielles des versions PHP 8.
Identifier les environnements qui utilisent PHP
Dans WordPress, ouvrez Outils → Santé du site → Informations et consultez la partie Serveur. Comparez l’information avec le panneau d’hébergement du domaine public. Demandez à la personne qui administre le site de vérifier séparément la version utilisée en ligne de commande si des scripts de maintenance ou des tâches planifiées y tournent. Une commande de diagnostic exécutée dans le terminal peut indiquer une autre version que celle qui traite les requêtes du navigateur.
Faites une ligne par environnement : site public, copie de test, domaine secondaire et processus indépendant. Prenez l’exemple d’une entreprise qui gère sa vitrine et son extranet sous le même compte. Changer le réglage global peut déplacer les deux applications d’un seul coup. Demandez si le réglage s’applique par domaine, par dossier ou à tout le compte. Notez également où se déclenchent les imports de catalogue et les exports envoyés par courriel. Ils sont faciles à oublier parce qu’ils ne répondent pas directement à la visite d’une page.
Choisir une branche en fonction de votre installation
Commencez par demander à l’hébergeur les branches maintenues disponibles et la durée de prise en charge qu’il propose. Vérifiez ensuite les prérequis du cœur WordPress, du thème, des extensions essentielles et du code métier. Un plugin de paiement, un import sur mesure et un générateur de PDF peuvent avoir des contraintes différentes. Le choix se fait sur la combinaison installée, avec des versions précises et des scénarios observables. Pour préparer une intervention avec plusieurs responsables, utilisez les repères de la maintenance WordPress.
Pour une extension indispensable sans version compatible, contactez l’éditeur ou estimez le remplacement avant la bascule. Si le site contient un développement spécifique, prévoyez du temps pour corriger et retester le code. Les dépréciations dans les journaux n’ont pas toutes le même effet qu’une erreur fatale, mais elles signalent des points à classer. Faites la différence entre un message déjà présent avant le changement et un nouveau symptôme observé uniquement sur la branche cible.
Préparer la recette et le retour arrière
| Point à tester | Vérification utile |
|---|---|
| Contact | Envoyer un message de test et confirmer sa réception. |
| Administration | Ouvrir l’éditeur, enregistrer un brouillon et traiter un média. |
| Tâches et intégrations | Lancer un import ou une tâche représentative et lire ses journaux. |
| Paiement | Tester sur une passerelle de test et comparer les statuts. |
| Retour | Identifier le réglage précédent, le responsable et les données à réconcilier. |
Préparez une copie qui ressemble au site public, avec les mêmes extensions et réglages nécessaires aux essais. Protégez-la des visiteurs et de l’indexation, et écartez les données clients inutiles. Débranchez les services d’envoi ou de paiement réels avant de lancer les tests qui pourraient envoyer des messages ou créer des transactions. Utilisez un point de sauvegarde connu, avec accès aux fichiers et à la base. Les repères sur les sauvegardes et la sécurité aident à préparer cette étape.
Testez les fonctions avant et après le changement sur la copie, avec le même jeu d’exemples. Si un import cesse de fonctionner, conservez le fichier de test, l’heure et le message. Un contrôle limité à l’accueil peut passer alors que la création de devis échoue. Convenez d’une décision explicite pour chaque anomalie : correction préalable, nouvel essai ou report motivé avec protection confirmée par le prestataire.
Après la bascule, contrôler ce que la copie ne reproduit pas
Programmez le changement lorsque le mainteneur et une personne métier peuvent vérifier le service. Contrôlez la version effective, puis les quelques parcours qui doivent impérativement fonctionner. Les règles de cache, les expéditeurs de courriel, les clés d’intégration et les tâches planifiées peuvent se comporter différemment en production. Confirmez le traitement des nouvelles demandes dans votre boîte ou dans l’outil de suivi. Si le site utilise des formulaires, la page Form Monitor présente un outil de suivi des demandes.
Documentez la bascule, le réglage appliqué et les résultats. Prévoyez un contrôle au prochain cycle des tâches automatiques et notez la personne qui traite les alertes. Si vous devez revenir temporairement au réglage précédent, fixez une nouvelle échéance en tenant compte des correctifs effectivement disponibles. Le guide de suivi après mise en ligne fournit une trame de vérification qui s’adapte à cette intervention. Vous pourrez la reprendre pour la prochaine évolution de l’hébergement.
Nicolas Tissot
Gérant de Blue Strat. WordPress, développement web et référencement pour les artisans, TPE et PME.
Découvrir Nicolas Tissot