L'hébergeur envoie un message au printemps : la version de PHP utilisée par votre site n'est plus maintenue, une montée de version est nécessaire, et une bascule automatique interviendra à une date donnée. Le message part dans un dossier, personne ne le rouvre. Le site continue de s'afficher normalement pendant des mois, ce qui confirme le dirigeant dans l'idée qu'il n'y avait pas urgence. Puis un jour une extension refuse de s'installer parce qu'elle exige une version plus récente, ou le site tombe brutalement le matin où l'hébergeur applique la bascule annoncée.
Cette situation n'a rien d'exceptionnel, et elle ne relève pas de la négligence. Le socle d'exécution d'un site est invisible depuis l'interface d'administration : rien dans le tableau de bord ne signale qu'il repose sur une fondation abandonnée par son éditeur.
Ce que PHP fait exactement dans votre site
PHP est le langage dans lequel WordPress est écrit. À chaque visite non mise en cache, le serveur lance un interpréteur PHP, qui exécute le code de WordPress, de votre thème et de vos extensions, interroge la base de données, puis assemble la page renvoyée au navigateur. Sans lui, votre site ne produit rien.
Ce langage évolue par branches numérotées, et chaque branche suit un calendrier public. Elle reçoit d'abord des corrections de bogues, puis uniquement des correctifs de sécurité, et enfin plus rien du tout. Une fois cette dernière étape franchie, une vulnérabilité découverte dans l'interpréteur ne sera plus corrigée pour cette branche : il faudra changer de version. La branche 7.4, encore très répandue sur les hébergements de PME, n'est plus suivie depuis plusieurs années.
Pourquoi un site qui fonctionne peut quand même poser problème
Le fait qu'une page s'affiche ne dit rien de la solidité de ce qui l'exécute. Nous distinguons quatre conséquences concrètes, du plus discret au plus visible.
- Les vulnérabilités de l'interpréteur ne sont plus corrigées. Une faille de plugin qui aurait été contenue devient exploitable plus profondément, parce que la couche en dessous n'oppose plus de résistance à jour. C'est le prolongement direct du sujet que nous traitons dans WordPress accumule les failles.
- Le catalogue d'extensions se ferme progressivement. Les éditeurs sérieux relèvent leur version minimale requise, et vous vous retrouvez bloqué au moment précis où vous avez besoin d'ajouter une fonction, un module de paiement ou un connecteur.
- La performance stagne. Les branches récentes exécutent le même code sensiblement plus vite, avec une empreinte mémoire plus faible. Sur un hébergement mutualisé, ce gain se lit directement dans le temps de réponse du serveur, c'est-à-dire dans le délai avant que le navigateur ne reçoive le premier octet de la page.
- La compatibilité future se dégrade. WordPress relève lui aussi ses prérequis au fil de ses versions majeures. Rester en arrière finit par vous obliger à figer WordPress, donc à cumuler deux retards au lieu d'un.
Ce qui casse réellement lors d'une montée de version
La montée de version elle-même prend quelques minutes dans l'interface de l'hébergeur. Le travail se situe ailleurs : dans la vérification de ce qui va s'exécuter différemment.
Les ruptures que nous rencontrons viennent presque toujours du même endroit. Un thème ancien, en particulier un thème acheté sur une place de marché et jamais mis à jour, utilise des fonctions supprimées dans les branches récentes, et la page blanche apparaît immédiatement. Une extension abandonnée par son auteur produit le même effet. Du code ajouté dans le fichier de fonctions du thème par un prestataire précédent, souvent pour une petite personnalisation, déclenche une erreur fatale. Enfin, une passerelle de paiement ou un connecteur de comptabilité peut cesser de dialoguer avec son service distant.
C'est aussi la raison pour laquelle nous insistons sur le thème enfant, qui isole vos retouches du thème parent et leur permet de survivre aux mises à jour, comme nous l'expliquons dans le thème enfant WordPress. Un site dont les modifications ont été écrites directement dans le thème parent est toujours plus coûteux à faire monter de version.
Notre méthode pour monter de version sans coupure de service
Nous ne basculons jamais une version directement en production, et jamais un vendredi en fin de journée. La séquence que nous appliquons est la suivante.
- Nous relevons l'état des lieux : version actuelle, version cible disponible chez l'hébergeur, version de WordPress, liste des extensions avec leur date de dernière mise à jour, et présence éventuelle de code personnalisé.
- Nous dupliquons le site sur un environnement de recette, séparé et non indexé, selon la démarche décrite dans notre article sur le staging WordPress.
- Nous mettons à jour sur cette copie ce qui doit l'être avant la bascule, car une extension à jour supporte souvent déjà la version cible.
- Nous basculons la version sur la copie, puis nous relevons les erreurs dans les journaux du serveur plutôt que de nous fier au seul affichage de la page d'accueil.
- Nous testons les parcours qui comptent réellement : l'affichage des principaux gabarits, l'édition d'une page dans le constructeur, l'envoi du formulaire de contact, et le passage de commande complet si le site vend.
- Nous appliquons la bascule en production après avoir pris une sauvegarde hors du serveur d'hébergement, nous vidons le cache, et nous repassons les mêmes tests.
Le cache mérite une mention particulière : après une bascule, il conserve des pages générées par l'ancienne version, ce qui peut masquer une anomalie pendant plusieurs heures. Nous le purgeons systématiquement, selon le réglage décrit dans notre article sur le cache WordPress. Nous prenons également soin de vérifier que la sauvegarde existe ailleurs que sur la machine que nous modifions, car une copie stockée sur le serveur en cours de bascule ne protège de rien.
Quand la montée de version n'est pas la bonne réponse
Il arrive que le blocage soit structurel. Un thème dont l'éditeur a disparu, un empilement de vingt-cinq extensions dont plusieurs ne sont plus maintenues, un site construit sur un constructeur de pages abandonné : dans ces cas, faire tenir la version récente demande plus de travail que de reconstruire proprement.
Nous le disons alors franchement, avec les deux chiffres en face. Un site refait dès 900 HT repart sur un socle supporté, avec un thème enfant, des images préparées et un cache réglé. Un raccommodage répété sur un thème mort coûte davantage à l'année et laisse le problème entier. Nous détaillons les critères de cet arbitrage dans notre article sur refondre le site ou le corriger. À l'inverse, rester volontairement sur une branche abandonnée au motif que le site fonctionne encore n'est pas une décision, c'est un report d'incident.
Ce suivi fait partie de la maintenance WordPress à 500 HT / an : nous surveillons la version en service chez votre hébergeur, quel qu'il soit, nous anticipons les bascules annoncées, et nous programmons la montée de version au moment qui vous convient plutôt qu'au moment où la plateforme l'impose. Nous intervenons à distance dans toute la France et en Suisse, avec le même montant hors taxes en euros et en francs.
Si l'interface de votre hébergeur affiche encore une version 7, envoyez-nous une capture de cette page, sans aucun mot de passe. Nous vous dirons si la montée se fait dans la semaine, ou si votre thème doit être traité d'abord.