WordPress 7.1 : contrôles après la mise à jour

Une mise à jour du cœur de WordPress ne s’arrête pas lorsque l’écran d’administration affiche un message de réussite. Sur un site en production, les régressions les plus gênantes peuvent apparaître dans les heures qui suivent : formulaire qui ne transmet plus les demandes, paiement impossible, erreur PHP dans un module peu utilisé, mise en cache qui délivre une page obsolète ou conflit entre une extension et le thème.

Cette checklist post-mise à jour vers WordPress 7.1 a pour objectif de vérifier concrètement que le site fonctionne toujours pour ses visiteurs, ses administrateurs et ses moteurs de recherche. Elle complète la checklist de préparation avant la mise à jour vers WordPress 7.1. L’idée n’est pas d’activer ou de désactiver des extensions au hasard : il s’agit de constater les symptômes, de collecter les informations utiles, puis de corriger ou restaurer dans un ordre maîtrisé.

Commencer par figer la situation : sauvegarde et journaux

Si WordPress 7.1 vient d’être installé et que le site reste accessible, réalisez d’abord une nouvelle sauvegarde complète. Cette sauvegarde correspond à l’état précis du site après mise à jour. Elle peut être utile pour comparer les fichiers, analyser une anomalie ou revenir sur une correction qui aurait aggravé le problème.

Une sauvegarde exploitable comprend au minimum :

les fichiers WordPress, y compris wp-content, les extensions, les thèmes, les médias et les fichiers de configuration nécessaires ;
la base de données, qui contient notamment les contenus, les réglages, les comptes et les commandes d’une boutique ;
une vérification de restauration dans un environnement de préproduction ou local, lorsque cela est possible.

Ne vous contentez pas d’un statut « sauvegarde terminée » dans une interface. Vérifiez l’emplacement de stockage, la date, la taille approximative de l’archive et la possibilité réelle de récupérer la base de données. Les sauvegardes proposées par l’hébergeur sont souvent précieuses, mais leurs délais de rétention et leurs modalités de restauration varient selon l’offre.

Consulter les journaux avant de modifier quoi que ce soit

Les journaux permettent de distinguer un souci nouveau d’un avertissement déjà présent avant la mise à jour. Consultez en priorité les logs PHP accessibles depuis le panneau d’hébergement ou via le support de votre prestataire. Selon la configuration, ils peuvent s’appeler error_log, « PHP errors » ou « journaux d’erreurs ».

WordPress peut aussi écrire un journal de débogage. Sur un environnement de test, le fichier wp-content/debug.log est particulièrement utile pour identifier une extension, un thème ou un fichier impliqué dans une erreur. En production, le débogage doit être paramétré avec prudence : l’affichage d’erreurs à l’écran peut exposer des chemins de fichiers ou des informations techniques aux visiteurs.

Avant toute action corrective, notez l’heure de la mise à jour, la version de PHP utilisée, les messages d’erreur observés et les pages concernées. Ces éléments font gagner du temps au support de l’hébergeur, à l’éditeur d’une extension ou au prestataire de maintenance.

Recherchez notamment les erreurs fatales, les erreurs de mémoire, les problèmes de connexion à la base de données, les références à des fonctions dépréciées et les erreurs qui citent explicitement un répertoire d’extension ou de thème. Une ligne de log isolée n’est pas toujours la cause du dysfonctionnement ; sa répétition et son horodatage sont des indicateurs importants.

Vérifier que le cœur de WordPress est sain

Avant d’attribuer une anomalie à une extension, assurez-vous que l’installation elle-même est cohérente. Dans le tableau de bord, ouvrez la page des mises à jour et vérifiez qu’aucune mise à jour du cœur n’est restée incomplète. Contrôlez aussi que vous êtes bien connecté au bon environnement : un site de production, une préproduction et un site de recette peuvent utiliser des versions différentes.

La section Outils > Santé du site fournit des informations utiles sur PHP, les extensions actives, les tâches planifiées, les requêtes HTTP en boucle et certains réglages de sécurité. Ses recommandations ne sont pas toutes urgentes, mais une erreur critique apparue juste après la mise à jour mérite une investigation immédiate.

Pour les administrateurs qui utilisent WP-CLI, la commande suivante permet de vérifier l’intégrité des fichiers du cœur en les comparant aux sommes de contrôle publiées pour la version installée :

wp core verify-checksums

Cette commande ne remplace pas une analyse de sécurité, et elle ne vérifie pas les fichiers de vos extensions ou de votre thème. Elle aide toutefois à détecter des fichiers du cœur manquants ou modifiés. N’exécutez une commande en production que si vous maîtrisez son effet et disposez d’une sauvegarde récente. Retrouvez d’autres usages en ligne de commande dans notre article sur les commandes WP-CLI indispensables.

Tester les parcours critiques côté visiteurs

Un site peut sembler parfaitement fonctionnel depuis la page d’accueil tout en empêchant une conversion essentielle. Le contrôle post-mise à jour doit donc partir des actions réellement attendues des visiteurs. Préparez une liste courte, adaptée à votre activité, et exécutez-la sans être connecté au tableau de bord.

Utilisez une fenêtre de navigation privée ou un navigateur dans lequel vous n’êtes pas authentifié. Cela évite que votre session administrateur, votre cache personnel ou vos cookies masquent un problème rencontré par le public.

Checklist des pages et actions à contrôler

la page d’accueil, les principales pages de contenu et les modèles d’archives ;
le menu principal, le pied de page, le moteur de recherche interne et le fil d’Ariane s’il est présent ;
les formulaires de contact, de devis, de newsletter ou de réservation ;
la réception effective d’un e-mail de test, dans la boîte de réception et dans les courriers indésirables ;
les contenus intégrés : vidéos, cartes, lecteurs audio, documents ou flux externes ;
l’affichage sur mobile, notamment le menu, les boutons et les champs de formulaire ;
les redirections importantes, par exemple d’anciennes URL vers des pages actuelles.

Pour une boutique WooCommerce, réalisez un scénario de commande complet sur un environnement de test ou avec une procédure compatible avec votre système de paiement. Vérifiez l’ajout au panier, les variations de produit, le calcul de livraison, les codes promotionnels, le passage de commande, l’e-mail transactionnel et la création de la commande dans l’administration. Si un prestataire de paiement est utilisé, ne déduisez pas son bon fonctionnement de la seule présence du bouton : testez le parcours prévu par sa documentation.

Pour un site d’adhésion, de formation ou de contenu privé, testez au moins un compte avec les droits d’un membre ordinaire. Les rôles WordPress peuvent afficher des contenus différents de ceux visibles par un administrateur.

Contrôler l’administration et les fonctions métier

Le front-office ne suffit pas. Une régression peut bloquer l’enregistrement d’un article, l’import de médias, la planification d’une publication ou une tâche automatisée. Connectez-vous avec un compte administrateur, puis vérifiez les écrans utilisés au quotidien.

Créez idéalement un brouillon de test, modifiez un contenu existant non critique et vérifiez que l’enregistrement fonctionne. Ouvrez l’éditeur de blocs, l’écran des médias, la liste des commentaires et les réglages les plus importants pour votre activité. Si le site utilise un constructeur de pages tel qu’Elementor, Divi ou Beaver Builder, ouvrez un modèle et utilisez son aperçu sans publier de modification inutile.

Les symptômes suivants demandent une attention particulière :

page blanche, erreur 500 ou message « Une erreur critique est survenue » ;
éditeur qui charge indéfiniment ou boutons devenus inactifs ;
échec lors de l’envoi d’un média ou de la génération de miniatures ;
tâches planifiées qui ne s’exécutent plus ;
alertes de connexion à une API externe, à un service d’e-mailing ou à un outil de paiement ;
droits inattendus, par exemple un utilisateur qui ne peut plus accéder à une section habituelle.

Pour les tâches récurrentes, la page Santé du site peut signaler des problèmes liés à WP-Cron. Des extensions comme WP Crontrol facilitent l’inspection des événements planifiés, mais leur utilisation doit rester encadrée : supprimer ou déclencher une tâche sans comprendre son rôle peut perturber l’envoi d’e-mails, la synchronisation de stocks ou des sauvegardes.

Auditer les extensions et le thème sans créer de nouvelle panne

Après une évolution du cœur, les extensions et le thème actif constituent les causes les plus fréquentes de comportements anormaux. Commencez par relever les éléments récemment mis à jour, ceux dont une mise à jour est disponible et ceux qui signalent une incompatibilité. Consultez aussi les notes de version et le support officiel de l’éditeur lorsqu’un problème précis est identifié.

Une extension abandonnée ou insuffisamment maintenue augmente le risque de conflit et de faille de sécurité. Notre guide pour détecter les plugins WordPress abandonnés propose une méthode pour faire le tri sans désactiver brutalement des fonctionnalités nécessaires.

Isoler un conflit de manière contrôlée

Sur un site de production, évitez de désactiver toutes les extensions en bloc. Cette pratique peut couper un formulaire, un paiement, un cache, une protection anti-spam ou des fonctions métier. Reproduisez d’abord le problème sur une préproduction, si elle existe.

Lorsque le dysfonctionnement est reproductible, procédez par étapes :

notez l’URL, l’action, le navigateur et le message d’erreur ;
désactivez temporairement une extension suspecte dans un environnement de test ;
reproduisez exactement le même scénario ;
réactivez l’extension et confirmez que le problème réapparaît ;
testez une mise à jour de l’extension ou recherchez une correction documentée par son éditeur.

Le thème doit être vérifié de la même manière. Contrôlez les en-têtes, les modèles de pages, les zones de widgets, les formulaires, les polices et les éléments personnalisés. Si un thème enfant est utilisé, gardez à l’esprit que les personnalisations peuvent contenir du code devenu incompatible avec une évolution de PHP ou une extension, indépendamment de WordPress 7.1.

Les erreurs PHP sont souvent déterminantes. Un message qui pointe vers un fichier dans wp-content/plugins ou wp-content/themes offre une piste plus fiable qu’une intuition. Conservez le message complet, sans publier d’informations sensibles, puis transmettez-le à l’éditeur concerné si nécessaire.

Mesurer les performances après WordPress 7.1

La vitesse perçue ne se limite pas à la page d’accueil chargée depuis votre navigateur habituel. Après une mise à jour, vérifiez que le cache fonctionne encore et que les pages publiques sont délivrées correctement. Purgez le cache de l’extension, du serveur et du CDN uniquement en sachant quelles couches sont utilisées sur votre site.

Des outils comme PageSpeed Insights, WebPageTest ou les outils de développement de votre navigateur permettent d’observer les temps de chargement et les ressources qui échouent. Le résultat varie selon la localisation, le réseau et le moment du test. Comparez surtout les mêmes pages et les mêmes conditions avant et après intervention, plutôt que de viser un score isolé.

Contrôlez les signaux concrets :

pages qui chargent sans erreur de ressource visible ;
images et feuilles de style correctement servies ;
absence de boucles de redirection ;
pages connectées qui restent accessibles après connexion ;
cache qui ne montre pas de contenu privé à des visiteurs non authentifiés ;
temps de réponse anormalement élevé dans les pages les plus visitées.

Une lenteur apparue après la mise à jour peut venir d’un cache vidé, d’une régénération d’images, d’une tâche de maintenance ou d’un appel externe. Avant de modifier wp-config.php ou les réglages serveur, identifiez l’origine. Vous pouvez compléter cette analyse avec notre article consacré à l’optimisation de wp-config.php pour la performance.

Vérifier la sécurité, les e-mails et les accès

Une mise à jour du cœur est aussi le bon moment pour contrôler les protections existantes. Vérifiez que le certificat HTTPS est toujours valide, que les redirections HTTP vers HTTPS se comportent comme prévu et que l’administration reste accessible sans contourner vos mécanismes de sécurité.

Testez les fonctions qui dépendent d’e-mails : réinitialisation de mot de passe, notification de formulaire, confirmation de commande ou invitation utilisateur. Si vous utilisez un service SMTP tel que Brevo, Mailgun, SendGrid ou un serveur SMTP fourni par votre hébergeur, consultez ses journaux de livraison en cas d’absence de message. Une erreur d’envoi peut être visible côté WordPress alors que le message est ensuite rejeté ou classé comme indésirable par le destinataire.

Examinez également les comptes administrateurs. Supprimez ou rétrogradez les accès qui ne sont plus justifiés, imposez des mots de passe robustes et activez l’authentification multifacteur lorsque votre solution le permet. Les passkeys constituent également une option intéressante lorsque l’environnement et l’extension d’authentification les prennent en charge ; consultez notre dossier sur les passkeys pour sécuriser les accès administrateurs WordPress.

Enfin, assurez-vous que votre extension de sécurité, votre pare-feu applicatif ou les règles de votre CDN ne bloquent pas des actions légitimes. Un code 403 lors de l’enregistrement d’un formulaire ou dans l’éditeur peut provenir d’une règle de sécurité, pas nécessairement de WordPress.

Contrôler l’indexation et les signaux SEO

Une mise à jour technique ne devrait pas modifier l’indexation, mais une mauvaise configuration de cache, de redirection ou d’environnement peut avoir des conséquences sur la visibilité. Vérifiez quelques URL stratégiques : accueil, page de service, article récent, catégorie et page produit si le site est une boutique.

Dans Google Search Console, surveillez les problèmes d’indexation signalés, l’état des sitemaps et les éventuelles erreurs d’exploration. Utilisez l’outil d’inspection d’URL pour demander une vérification ponctuelle d’une page importante, sans chercher à réindexer l’ensemble du site après chaque opération de maintenance.

Les contrôles essentiels sont les suivants :

les pages publiques ne contiennent pas accidentellement de directive noindex ;
le fichier robots.txt est accessible et cohérent avec vos choix habituels ;
le sitemap XML reste accessible si vous en utilisez un ;
les balises canoniques de quelques pages importantes pointent vers les bonnes URL ;
les redirections existantes répondent avec le comportement attendu ;
aucune page de préproduction n’est devenue accessible ou indexable par erreur.

Un changement temporaire d’apparence dans les résultats de recherche n’est pas, à lui seul, une preuve de problème technique. En revanche, une augmentation d’erreurs serveur, des URL soudainement exclues ou un blocage général des robots doivent être traités rapidement.

Documenter les résultats et planifier le suivi

Terminez la checklist en documentant ce qui a été vérifié, les anomalies observées, les corrections appliquées et les actions restantes. Un simple tableau peut suffire : date, personne responsable, URL ou fonction testée, résultat, lien vers le journal d’erreur et décision prise.

Conservez également une liste des versions du cœur, de PHP, du thème et des extensions critiques. Cette traçabilité facilite les diagnostics futurs, notamment si un souci n’apparaît qu’après une mise à jour complémentaire ou une modification de configuration chez l’hébergeur.

Si le site présente une erreur critique, une perte de données, un problème de paiement ou une indisponibilité prolongée, privilégiez la restauration de la dernière sauvegarde validée plutôt qu’une succession de corrections non testées. Pour les contrôles récurrents, appuyez-vous sur une routine de maintenance hebdomadaire WordPress et sur un plan de maintenance mensuel.

Conclusion : valider la mise à jour par des preuves

Après WordPress 7.1, la bonne démarche consiste à vérifier plutôt qu’à supposer. Une sauvegarde récente, des journaux consultés, des parcours visiteurs testés, un contrôle des extensions et du thème, puis une surveillance de la performance, de la sécurité et de l’indexation apportent une validation solide de la mise à jour.

Intégrez cette checklist à votre processus de maintenance et adaptez-la aux fonctions réellement critiques de votre site. Une procédure courte, répétable et documentée est souvent le moyen le plus fiable de détecter une régression avant qu’elle ne touche vos visiteurs ou votre activité.