WordPress 7.0 et hébergement : les vérifications à faire avant la mise à jour

Avant de mettre à jour vers WordPress 7.0, testez la mise à jour sur une copie fidèle du site et validez qu’une sauvegarde peut être restaurée. Pour un site commercial, vérifiez aussi PHP, la base de données, les extensions, le cache et les services tiers : ils font partie du déploiement.

Confirmez les prérequis définitifs de WordPress 7.0 dans les exigences serveur officielles de WordPress et dans les notes de version disponibles au moment du déploiement. Ne supposez pas qu’un environnement compatible avec une version précédente le restera sans essai.

Vérifications chez l’hébergeur

Relevez la configuration réellement utilisée en production, puis comparez-la aux exigences de WordPress 7.0 et de vos extensions critiques. Utilisez le panneau d’hébergement, l’outil Santé du site ou le support de l’hébergeur, plutôt que les caractéristiques théoriques de votre offre.

PHP : vérifiez la version utilisée, les modules actifs et la possibilité d’employer la même version en préproduction. Assurez-vous que le thème et les extensions stratégiques sont compatibles avec cette version.
MySQL ou MariaDB : identifiez le moteur et sa version. Une base ancienne peut devenir un blocage lors d’une évolution du schéma ou d’une extension.
Mémoire, délais et espace disque : consultez les journaux pour repérer les erreurs de mémoire, de délai ou de taille d’envoi. Prévoyez aussi de l’espace pour la mise à jour, les journaux, les sauvegardes et la préproduction.
Tâches planifiées : si WooCommerce, un outil d’e-mailing ou un connecteur métier utilise WP-Cron ou un cron système, vérifiez leur exécution après l’essai.

Inventoriez toutes les extensions actives, même celles qui semblent secondaires. Une extension inactive ne pèse pas sur l’exécution, mais elle peut présenter un risque de sécurité : mettez-la à jour ou supprimez-la si elle n’est plus utile.

Préproduction et retour arrière

La préproduction doit reproduire autant que possible la production : version de PHP, moteur de base de données, extensions et réglages de cache comparables. Un environnement différent peut masquer un défaut qui n’apparaîtra qu’après la bascule.

Créez une sauvegarde complète des fichiers et de la base de données juste avant l’opération.
Restaurez-la dans un environnement isolé pour vérifier qu’elle est exploitable.
Dupliquez le site en préproduction et empêchez son indexation par les moteurs de recherche.
Mettez à jour WordPress, puis les extensions et le thème selon l’ordre recommandé par leurs éditeurs lorsqu’il existe.
Consultez les journaux PHP, les erreurs WordPress et les alertes de sécurité après chaque étape.
Définissez le responsable du retour arrière et le délai maximal acceptable d’indisponibilité.

Une sauvegarde dans le même compte d’hébergement reste utile, mais peut ne pas suffire. Pour un site à enjeu commercial, conservez aussi une copie hors de l’environnement de production, selon votre politique de continuité et les fonctions de l’hébergeur.

Tests avant et après la mise en ligne

Testez en priorité les parcours qui génèrent des ventes ou des demandes. Pour WooCommerce, vérifiez au minimum la recherche produit, l’ajout au panier, le code promotionnel, le calcul de livraison, le paiement de test, l’e-mail de confirmation et l’accès au compte client.

Contrôlez aussi les formulaires, les connexions, les redirections, la recherche interne, les médias et les intégrations externes. Utilisez les modes de test des prestataires de paiement, CRM ou transporteurs afin d’éviter l’envoi de commandes ou de notifications réelles depuis la préproduction.

Après la mise à jour, videz les couches de cache concernées : extension WordPress, cache serveur, cache objet et CDN. Testez en fenêtre privée, sur mobile, connecté puis déconnecté, et vérifiez que le panier, le compte client, le paiement et l’administration ne sont pas mis en cache.

Comparez les performances des pages clés avant et après avec PageSpeed Insights ou les données de terrain disponibles dans Google Search Console. Une variation isolée ne prouve pas une régression, mais une hausse durable des erreurs, du temps de réponse ou de l’abandon de panier appelle une correction.

Déploiement en production

Déployez seulement après validation de la préproduction et du retour arrière, avec une personne disponible pour surveiller les erreurs. Évitez une période de ventes, de campagne publicitaire ou d’échéance opérationnelle sans possibilité de réaction rapide.

Après la mise en ligne, refaites les parcours critiques et surveillez les journaux, les transactions et les formulaires. Si un défaut touche la conversion, la sécurité ou la disponibilité, restaurez la version validée plutôt que de corriger directement sur le site exposé.