WordPress 7.0 : votre hébergement est-il prêt ?

Une mise à jour majeure de WordPress ne se limite jamais au remplacement de quelques fichiers du cœur. Elle sollicite aussi PHP, la base de données, le stockage, les mécanismes de cache, les certificats HTTPS, les tâches planifiées et les extensions installées. À l’approche d’un nouveau cycle majeur tel que WordPress 7.0, la bonne question n’est donc pas seulement « puis-je cliquer sur Mettre à jour ? », mais « mon hébergement et mon processus de déploiement sont-ils prêts ? ».

Les prérequis définitifs de WordPress 7.0 devront être confirmés au moment de sa publication dans la documentation officielle des prérequis WordPress et dans les notes de version. En revanche, il est possible d’auditer dès maintenant l’essentiel de son infrastructure. Cette démarche préventive évite qu’une mise à jour du CMS révèle, en production, un PHP obsolète, une extension incompatible, une base de données saturée ou un cache mal purgé.

Pourquoi une mise à jour majeure WordPress concerne aussi l’hébergement

WordPress s’exécute sur une pile technique complète. Quand le cœur évolue, il peut faire appel à des fonctions PHP plus récentes, modifier des requêtes SQL, adapter la structure de certaines données, renforcer des contrôles de sécurité ou changer des comportements côté administration. Ces évolutions sont généralement conçues pour préserver la compatibilité, mais aucun site ne repose sur le cœur seul.

Un site WordPress réel associe souvent un thème, un constructeur de pages, un plugin de cache, une extension SEO, un formulaire, un système de sauvegarde, parfois WooCommerce et des connecteurs vers des services externes. Chacun de ces composants dépend à son tour du serveur. Un conflit peut donc apparaître entre :

la version de WordPress et la version active de PHP ;
un plugin ancien et une évolution du cœur ou de l’éditeur ;
un cache serveur qui conserve des fichiers ou des pages devenus obsolètes ;
une base MySQL ou MariaDB trop ancienne, mal dimensionnée ou proche de ses limites ;
une tâche cron qui ne s’exécute plus correctement ;
un CDN qui diffuse encore une ancienne version des ressources CSS ou JavaScript.

Sur un hébergement mutualisé, vous ne maîtrisez pas tous les réglages système. Vous dépendez notamment des versions PHP proposées, des modules activés, des limites de mémoire, du nombre de processus simultanés et de la politique de mise à jour de l’hébergeur. Sur un VPS ou un serveur dédié, le contrôle est plus large, mais la responsabilité de maintenir la pile logicielle est aussi plus importante.

Cette réalité explique pourquoi une mise à jour réussie ne doit pas être jugée uniquement sur l’absence d’erreur immédiate. Un site peut sembler fonctionner après la mise à niveau, puis rencontrer quelques heures plus tard un échec de sauvegarde, des e-mails transactionnels non envoyés, un tunnel de commande instable ou une zone d’administration anormalement lente.

Avant d’envisager WordPress 7.0, prenez donc l’habitude de documenter votre environnement. Notez l’offre d’hébergement, la version PHP, le moteur de base de données, le thème actif, les extensions critiques, le mécanisme de cache, le CDN éventuel et la solution de sauvegarde. Cette simple fiche accélère énormément le diagnostic si un problème survient.

Vérifier PHP avant toute mise à niveau

PHP est le langage qui exécute WordPress. Une version prise en charge par l’hébergeur n’est pas nécessairement une version adaptée à votre site, et une version techniquement disponible n’est pas forcément compatible avec toutes vos extensions. L’objectif est de trouver un équilibre : utiliser une version PHP maintenue et compatible avec les exigences officielles de WordPress, tout en validant le comportement du thème et des plugins sur une copie du site.

Depuis l’administration WordPress, l’outil Santé du site, accessible dans le menu Outils, signale les problèmes de configuration importants. Il permet notamment d’identifier la version de PHP et certains modules disponibles. Vous pouvez également consulter la section « Informations » pour retrouver des éléments utiles sur le serveur, la base de données et les constantes WordPress.

Avant une mise à jour majeure, contrôlez au minimum les points suivants :

la version PHP actuellement utilisée en production ;
la disponibilité d’une version PHP compatible avec les futures exigences officielles ;
la compatibilité déclarée de votre thème et de vos extensions critiques ;
les erreurs PHP consignées dans les journaux de l’hébergeur ;
la limite de mémoire PHP réellement disponible ;
la possibilité de modifier la version PHP séparément sur l’environnement de test.

Il est préférable de ne pas changer PHP et WordPress au même moment sur le site public sans tests préalables. Si votre hébergeur propose un staging, clonez le site, modifiez d’abord PHP sur cette copie, puis mettez à jour les extensions, le thème et WordPress. Vous saurez ainsi quelle modification est responsable si une erreur apparaît.

Les journaux sont particulièrement utiles. Une erreur fatale PHP, un avertissement répété ou une fonction dépréciée n’empêche pas toujours l’affichage d’une page, mais peut révéler une extension qui ne suivra pas correctement le prochain cycle majeur. Chez de nombreux hébergeurs, les logs sont disponibles depuis cPanel, Plesk, un tableau de bord propriétaire ou via SSH. Sur un serveur administré, demandez au support où consulter les erreurs applicatives.

Pour un site e-commerce, un espace membre ou un média fréquenté, observez aussi la consommation de ressources aux heures de pointe. Une mise à jour peut coïncider avec une régénération du cache, des tâches de maintenance ou des opérations en base. Une limite de mémoire trop basse ou un nombre de workers PHP insuffisant peut alors transformer un changement banal en lenteurs visibles.

Base de données, HTTPS et stockage : les fondations à contrôler

WordPress utilise MySQL ou MariaDB pour stocker les contenus, les réglages, les utilisateurs, les commandes et une grande partie des données générées par les extensions. Les versions minimales et recommandées applicables à WordPress 7.0 devront être consultées dans la documentation officielle. Ne présumez pas que la configuration d’un vieux serveur restera compatible simplement parce qu’elle fonctionne aujourd’hui.

Dans l’intervalle, vérifiez la version réellement fournie par l’hébergement, le type de moteur utilisé et l’accès à un outil d’administration comme phpMyAdmin. Sur un serveur administré, vous pouvez aussi interroger le service via la ligne de commande, mais cette opération n’est pas nécessaire pour un audit de base : l’interface d’hébergement ou Santé du site suffit souvent.

La qualité de la base ne se résume pas à son numéro de version. Un site peut rencontrer des problèmes lors d’une mise à jour si :

l’espace disque est presque saturé ;
la base est anormalement volumineuse à cause de révisions, transients, logs ou tables laissées par d’anciennes extensions ;
des tables importantes sont absentes, corrompues ou très lentes ;
une sauvegarde SQL existe, mais n’a jamais été restaurée ni vérifiée ;
des tâches automatiques écrivent en masse dans la base sans supervision.

Évitez cependant les « nettoyages » agressifs juste avant une mise à jour. Supprimer des données de manière irréversible sans savoir quelle extension les utilise peut créer davantage de risques que la mise à niveau elle-même. Si vous utilisez un outil tel que WP-Optimize, faites d’abord une sauvegarde complète et réalisez toute optimisation sur l’environnement de test.

HTTPS est un autre prérequis pratique incontournable. WordPress recommande l’usage du protocole HTTPS, et l’administration, les formulaires, les connexions utilisateurs ou les paiements ne doivent pas dépendre de redirections fragiles. Vérifiez que le certificat TLS est valide, que l’URL définie dans WordPress utilise bien https, et qu’aucune ressource essentielle n’est chargée en HTTP. Un certificat Let’s Encrypt renouvelé automatiquement est courant, mais le renouvellement doit rester contrôlé dans votre tableau de bord.

Enfin, surveillez l’espace de stockage avant l’opération. Une mise à jour nécessite de télécharger et décompresser des fichiers ; une sauvegarde complète peut aussi consommer un volume temporaire significatif. Un disque presque plein peut empêcher la création de fichiers, interrompre une sauvegarde ou provoquer des erreurs difficiles à interpréter. Gardez une marge suffisante et vérifiez les quotas propres aux fichiers, aux bases de données et aux sauvegardes selon les règles de votre hébergeur.

Cache, CDN et extensions : préparer un environnement de test fiable

Le cache est indispensable à la performance, mais il peut compliquer la validation d’une mise à jour. Un cache de page peut masquer un défaut qui apparaît uniquement pour les utilisateurs connectés. Un cache d’objets peut conserver des données inattendues. Un CDN peut servir une ancienne feuille de style après le déploiement. Le défi n’est pas de désactiver systématiquement tous les caches en production : il consiste à savoir les purger et à vérifier ce que voit réellement un visiteur.

Identifiez les couches actives sur votre site. Elles peuvent inclure un plugin tel que WP Rocket, LiteSpeed Cache ou W3 Total Cache, un cache intégré chez l’hébergeur, Redis pour le cache objet, Varnish devant le serveur web, ainsi qu’un CDN comme Cloudflare. Ces outils sont compatibles avec de nombreux sites WordPress, mais leurs réglages et leurs procédures de purge diffèrent.

Après la mise à jour sur une préproduction, purgez les caches de l’application, du serveur et du CDN, puis testez le site dans une fenêtre privée. Vérifiez à la fois les pages publiques et les zones dynamiques : connexion, recherche, formulaire, panier, paiement, compte client et administration. Pour un site WooCommerce, ajoutez un produit au panier, modifiez une quantité, passez jusqu’à l’étape de paiement sans forcément finaliser la transaction, puis contrôlez les e-mails et le tableau de bord de commande selon votre procédure de test.

Le staging doit être une copie aussi proche que possible de la production. Idéalement, il utilise la même version de PHP, les mêmes extensions, le même thème et une configuration de cache comparable. En revanche, évitez qu’il envoie des e-mails réels, appelle des passerelles de paiement en production, ou soit indexé par les moteurs de recherche. Le réglage « Demander aux moteurs de recherche de ne pas indexer ce site » est utile dans WordPress, mais il ne remplace pas à lui seul une protection d’accès lorsque le contenu est sensible.

Les extensions constituent la première source de dépendances. Avant WordPress 7.0, faites l’inventaire de celles qui sont réellement indispensables. Consultez leur page officielle, leur historique de mises à jour, la compatibilité annoncée par l’éditeur et les tickets de support ouverts. Une extension abandonnée, un thème enfant reposant sur des fonctions anciennes ou un plugin téléchargé hors de son canal officiel mérite une attention particulière.

Ne désactivez pas au hasard une extension critique sur le site en ligne pour « voir si cela règle le problème ». Reproduisez plutôt le défaut en staging, consultez les logs et désactivez les composants un à un sur la copie. Cette méthode est plus sûre pour les visiteurs et fournit des informations exploitables à l’éditeur du plugin ou au support de l’hébergeur.

Sauvegardes : la restauration est le vrai test

Une sauvegarde n’est utile que si elle peut être restaurée. Avant une mise à jour majeure, vous devez disposer d’un point de retour comprenant au minimum les fichiers WordPress et la base de données. Une sauvegarde partielle peut être insuffisante : les médias, les réglages du thème, les extensions et les tables personnalisées peuvent tous être nécessaires pour remettre le site dans son état initial.

De nombreux hébergeurs incluent des sauvegardes automatiques, mais leurs durées de rétention, leur fréquence et les modalités de restauration varient selon les offres. Lisez les conditions exactes de votre contrat. Vérifiez notamment si la sauvegarde couvre les fichiers et la base, s’il est possible de restaurer un seul élément, si une restauration est facturée et si les données sont conservées sur une infrastructure distincte.

Une stratégie prudente repose souvent sur deux niveaux : la sauvegarde proposée par l’hébergeur et une copie indépendante. Des extensions comme UpdraftPlus peuvent envoyer des sauvegardes vers des services tels que Google Drive, Dropbox, Amazon S3 ou Backblaze B2, selon votre configuration. Le choix de l’outil importe moins que la capacité à récupérer les données dans un délai acceptable.

Programmez une restauration de test avant le jour de la mise à jour. Vous pouvez restaurer la sauvegarde sur un environnement isolé, puis vérifier que le site démarre, que les médias sont présents, que l’administration est accessible et que les éléments clés fonctionnent. Cette étape révèle les archives incomplètes, les accès cloud expirés ou les procédures de restauration mal comprises.

Le bon indicateur n’est pas « une sauvegarde a été créée », mais « je sais où elle se trouve, ce qu’elle contient et comment restaurer mon site ».

Planifier la mise à jour sans perturber les visiteurs

Une mise à jour majeure mérite un créneau planifié. Évitez les périodes de forte activité, les lancements commerciaux, les campagnes publicitaires, les opérations de maintenance du serveur ou les moments où votre équipe ne peut pas intervenir. Pour une boutique, ne planifiez pas l’opération pendant une période promotionnelle ou lorsque les commandes sont nombreuses.

Prévenez les personnes concernées : responsable marketing, rédacteur, équipe support, prestataire e-commerce ou développeur. Une personne qui publie un article, modifie une page ou reçoit une commande pendant une restauration peut compliquer le retour arrière. Définissez qui décide du passage en production, qui surveille le site et qui contacte l’hébergeur si nécessaire.

La procédure doit être ordonnée. Commencez par mettre à jour les extensions et le thème sur l’environnement de test, puis le cœur WordPress. Vérifiez les fonctions importantes, examinez les journaux et mesurez les pages critiques. Si le résultat est satisfaisant, reproduisez la procédure en production en commençant par une sauvegarde fraîche. Gardez une trace des heures et des actions effectuées : elle sera précieuse en cas d’incident.

Pour les sites à fort trafic, une surveillance après déploiement est essentielle. Utilisez par exemple UptimeRobot pour détecter une indisponibilité, Google Search Console pour suivre d’éventuels problèmes d’exploration, et les outils de logs de l’hébergeur pour repérer les erreurs serveur. Ces services ne remplacent pas un test fonctionnel, mais ils aident à identifier rapidement un problème qui n’apparaîtrait pas sur votre propre poste.

La checklist d’hébergement avant WordPress 7.0

Voici une liste de contrôle à utiliser avant toute mise à jour majeure. Elle est volontairement centrée sur l’infrastructure et doit être complétée par les prérequis officiels publiés pour WordPress 7.0.

Consulter les notes de version et les prérequis officiels de WordPress avant de planifier la mise à niveau.
Vérifier dans Santé du site la version PHP, les informations serveur et les alertes actives.
Confirmer auprès de l’hébergeur la disponibilité d’une version PHP compatible et maintenue.
Contrôler la version de MySQL ou MariaDB et l’espace disponible pour les fichiers, la base et les sauvegardes.
Mettre à jour ou remplacer les extensions et thèmes dont la maintenance est insuffisante.
Créer un environnement de staging représentatif de la production.
Empêcher l’indexation et les interactions réelles depuis l’environnement de test.
Tester le site avec les caches purgés, y compris le cache CDN s’il existe.
Vérifier HTTPS, le renouvellement du certificat et l’absence de contenu mixte sur les pages importantes.
Créer une sauvegarde complète juste avant l’opération.
Restaurer au moins une sauvegarde sur un environnement isolé pour valider la procédure.
Prévoir un créneau calme, un plan de retour arrière et les accès au support de l’hébergeur.
Tester les parcours métiers : formulaire, connexion, recherche, paiement, e-mails et administration selon votre site.
Surveiller les logs, les performances et la disponibilité après la mise en production.

Conclusion : faire de la mise à jour un processus maîtrisé

WordPress 7.0 devra être abordé avec les exigences exactes qui seront alors publiées, mais l’essentiel du travail peut commencer bien avant : mettre à niveau la pile PHP lorsque cela est validé, assainir les extensions, vérifier la base de données, tester les caches et prouver qu’une restauration fonctionne. Cette préparation transforme une mise à jour potentiellement anxiogène en opération contrôlée.

Si votre hébergement ne propose ni staging, ni sauvegarde exploitable, ni accès clair aux versions PHP et aux journaux, c’est peut-être le bon moment de revoir votre infrastructure. Consultez aussi notre guide pour vérifier un hébergement WordPress avant de le choisir et notre méthode pour migrer WordPress sans interruption de service. Une base technique saine facilitera WordPress 7.0, mais aussi toutes les mises à jour qui suivront.