Mise à jour WordPress : la méthode pour mettre à jour votre site sans rien casser

Une mise à jour WordPress casse forcément quelque chose. Voilà l’idée qui fait repousser le clic de semaine en semaine… jusqu’au jour où c’est le retard lui-même qui devient le problème.

Oui, une mise à jour peut casser un site. Le 19 août 2026, WordPress 7.1 sort, et des sites équipés de WP Rocket tombent sur une erreur fatale dans son intégration Cloudflare. Je ne l’ai pas vécu moi-même : je l’ai entendu, comme tout le monde. L’éditeur a publié le correctif, WP Rocket 3.23.2.2, dès le 20 août.

Le vrai danger est dans l’autre sens. Le 22 septembre 2026, WordPress 7.1.2 corrige une faille critique, déjà visée par des attaques le jour même. Ce jour-là, à 17 h 05, le WordPress de wpformation.com s’est mis à jour tout seul.

Ma règle, aujourd’hui : les mises à jour automatiques de sécurité, je les applique dans tous les cas de figure. C’est directement natif à WordPress, donc c’est pas un sujet pour moi. Et sur la durée ? À mon niveau, clairement, j’ai jamais eu de vrais gros problèmes là-dessus : un plugin qui, parfois, dégradait mon CSS ou faisait planter mon cache, il y a très longtemps, rien de dramatique.

Ce n’est pas de la chance. C’est une méthode : une sauvegarde qu’on sait restaurer, une préproduction, un ordre, une vérification et un plan de retour arrière. La peur de casser le site coûte plus cher que la mise à jour elle-même.

Pourquoi faut-il mettre à jour son site WordPress ?

Mettre à jour WordPress consiste à remplacer le code du cœur, des extensions et du thème par leur dernière version publiée. La première raison est la sécurité : le projet WordPress ne prend officiellement en charge que la toute dernière version, et le report des correctifs sur les anciennes branches reste un geste de courtoisie, "not always possible" selon le guide officiel des hébergeurs.

De 7.0 à 7.1, la montée est majeure : nouvelles fonctions, parfois nouveaux prérequis (7.0 a relevé le minimum à PHP 7.4). De 7.1.1 à 7.1.2, elle est mineure et corrige des bugs et des failles.

WordPress 7.1.2 corrige une faille de sécurité classée critique (CVE-2026-87902) : sous certaines conditions, un attaquant non connecté peut faire inclure un fichier PHP du serveur situé hors des dossiers du thème, jusqu’à exécuter du code à distance. L’annonce officielle recommande de mettre à jour "immediately".

Patchstack voit arriver les premières tentatives d’exploitation le jour même, et l’agence américaine CISA ajoute la faille à son catalogue des failles exploitées le 25 septembre.

Le correctif a été reporté sur toutes les branches encore suivies, jusqu’à 4.7 : un site resté en 6.8 le reçoit sous le nom 6.8.10, un site en 7.0 sous le nom 7.0.6… à condition de laisser faire les mises à jour automatiques.

Et le cœur n’est pas le plus exposé. Selon Patchstack, 91 % des 11 334 failles recensées en 2025 visaient des extensions, et 6 seulement le cœur. J’ai détaillé les failles de sécurité des extensions et la façon de les repérer.

Faut-il attendre avant d’installer une version majeure ? Pour une mineure de sécurité, non. Pour une majeure, quelques jours de patience ne coûtent rien. La 7.0 est sortie le 20 mai 2026 : j’ai attendu la 7.0.1 du 9 juillet et migré le 16. La 7.1 est sortie le 19 août, je suis monté à la main le 22. Le correctif de WP Rocket, lui, datait du 20.

Quelle version de WordPress utilisez-vous ?

La question paraît bête. Elle ne l’est pas : c’est elle qui vous dit si votre site a reçu le dernier correctif. WordPress affiche sa version à plusieurs endroits, sans rien installer :

• en bas à droite de chaque écran d’administration : "Version 7.1.2" quand vous êtes à jour, un lien "Obtenir la version…" quand une nouvelle version vous attend ;
• dans le bloc "D’un coup d’œil" du Tableau de bord, sous la forme "WordPress 7.1.2 avec le thème…" ;
• dans Tableau de bord > Mises à jour : "Vous avez la dernière version de WordPress." ou "Une nouvelle version de WordPress est disponible." ;
• dans Outils > Santé du site > Informations, rubrique WordPress (la rubrique Serveur, plus bas, donne la version de PHP) ;
• en ligne de commande, avec wp core version (et --extra pour les détails).

Quelle version de PHP faut-il pour mettre à jour WordPress ?

WordPress 7.0 et 7.1 exigent PHP 7.4 au minimum et sont compatibles jusqu’à PHP 8.5. Le minimum n’est pas une cible : 7.4, 8.0 et 8.1 sont en fin de vie, acceptés "for backward compatibility only". wordpress.org recommande PHP 8.3 ou plus, le guide officiel des hébergeurs PHP 8.4 ou plus en production. Deux sources officielles, deux chiffres : visez 8.4 ou plus.

Version de PHP	Statut au 29/09/2026 (php.net)	Avec WordPress 7.1
7.4, 8.0, 8.1	Fin de vie, plus aucun correctif	Acceptées pour la rétrocompatibilité seulement
8.2	Correctifs de sécurité jusqu’au 31/12/2026	Compatible, à quitter avant la fin de l’année
8.3	Support actif terminé le 31/12/2025, sécurité seulement jusqu’au 31/12/2027	Recommandée par wordpress.org ("8.3 or greater")
8.4	Support actif jusqu’au 31/12/2026, puis sécurité seulement jusqu’au 31/12/2028	Recommandée par le guide des hébergeurs, prise en charge complète depuis WordPress 6.7
8.5	Support actif jusqu’au 31/12/2027, puis sécurité seulement jusqu’au 31/12/2029	Prise en charge complète depuis WordPress 6.9

Pour la base de données, wordpress.org recommande MariaDB 10.11 ou MySQL 8.0 au minimum. Le guide des hébergeurs vise plus haut pour les sites en 6.3 à 7.1 : MySQL 8.4 LTS ou MariaDB 11.4 LTS.

Votre version de PHP s’affiche dans Outils > Santé du site > Informations > Serveur. Quand elle ne reçoit plus de correctifs, l’onglet État le dit sans détour : "Votre site fonctionne sur une version obsolète de PHP".

PHP ne se change pas depuis WordPress mais chez votre hébergeur, et de préférence pas le même jour que la montée du cœur. Tout le détail est dans mon guide pour passer à PHP 8 avec WordPress 7.

Avant de mettre à jour WordPress

Deux filets, et l’un ne va pas sans l’autre : la sauvegarde vous ramène en arrière, la préproduction vous évite d’avoir à le faire.

Une sauvegarde que vous avez déjà restaurée

La procédure officielle tient en une ligne que je trouve parfaite : sauvegardez la base et "ALL your WordPress files", .htaccess compris, puis vérifiez que ces sauvegardes "are there and usable". Une sauvegarde jamais restaurée reste… une hypothèse.

Votre hébergeur sauvegarde peut-être votre site : vérifiez dans le contrat la fréquence, la conservation et le délai de restauration ; aucune règle générale ne l’oblige à sauvegarder chaque jour.

Faites votre sauvegarde juste avant de cliquer. Le jour de ma montée en 7.0.1, la sauvegarde de la base prise à 9 h 21 avait neuf heures de retard au moment de basculer : une nouvelle a été faite à 18 h 29, juste avant. En ligne de commande, wp db export --add-drop-table exporte la base dans un fichier SQL.

Pour les outils, je vous invite à lire mon guide des extensions de sauvegarde et de leur restauration. L’hébergeur Pagely conseille de restaurer chaque mois une sauvegarde prise au hasard sur une préproduction : "A backup you can’t restore is useless."

La préproduction, pour répéter avant de jouer

Une préproduction est une copie de votre site, fichiers et base de données, installée à une autre adresse, sur laquelle vous appliquez une mise à jour avant de la faire sur le site en ligne. Elle reste invisible des moteurs (Réglages > Lecture, case "Demander aux moteurs de recherche de ne pas indexer ce site") et n’envoie ni vrais e-mails ni vrais paiements.

Pour la monter, l’outil de préproduction de votre hébergeur fait l’affaire s’il en propose un ; sinon, restaurez votre sauvegarde dans un sous-domaine protégé par mot de passe. Et décidez avant de commencer ce qui vous fera revenir en arrière : une erreur fatale, un paiement qui ne passe plus.

Sur mon propre site, en vrai, ça ressemble à ça.

Mi-juillet 2026, j’ai monté wpformation.com de WordPress 6.9.4 à 7.0.1. J’avais volontairement laissé passer la 7.0 en attendant le premier correctif, et j’ai demandé un audit complet, avec un retour arrière prouvé, avant de décider quoi que ce soit.

Le code des deux versions a été comparé ligne à ligne. Puis un vrai clone de préproduction a été monté en 7.0.1, isolé pour de bon : un témoin écrit dans le clone restait invisible en production, les médias étaient montés en lecture seule, et le clone ne pouvait ni écrire sur le site en ligne ni l’appeler.

C’est le clone qui a trouvé la seule vraie différence, celle que la lecture du code avait laissée passer : une classe wp-block-paragraph ajoutée aux paragraphes. Sur le HTML rendu, 126 articles sortaient différents. Aucune panne, mais sur un site découplé, un HTML qui change arrive tel quel dans le front.

Trois "anomalies" se sont révélées être des artefacts du protocole de test. Un angle mort, assumé : aucune connexion réelle à l’administration n’a été testée sur le clone. Puis j’ai autorisé la bascule, faite le soir juste après une sauvegarde fraîche.

Pour un site vitrine, une copie restaurée et non indexée suffit à répéter une montée majeure.

Dans quel ordre mettre à jour le cœur, les extensions et le thème ?

L’ordre qui limite la casse : une sauvegarde fraîche, le cœur de WordPress, les extensions, le thème, les traductions, et PHP dans une opération séparée. Le cœur passe en premier parce que les extensions suivent ses versions. PHP passe en dernier parce que ce sont les versions récentes de WordPress qui prennent pleinement en charge les PHP récents.

1. La sauvegarde de la base et des fichiers, prise juste avant, et restaurable.
2. Le cœur de WordPress. S’il est en retard, une extension à jour vous le signale : "Une nouvelle version de… est disponible, mais cela ne fonctionnera pas avec votre version de WordPress."
3. Les extensions, par lots : celles à faible risque d’abord, puis les grosses (boutique, paiement, constructeur de pages) une par une.
4. Le thème, ou le thème parent si vous utilisez un thème enfant.
5. Les traductions, avec le bouton "Mettre à jour les traductions" du même écran.
6. PHP, un autre jour, sur la préproduction d’abord : PHP 8.4 n’est pleinement pris en charge que depuis WordPress 6.7, et 8.5 depuis 6.9.

Entre extensions et thème, l’ordre compte moins qu’une règle simple : une chose à la fois. Si le site casse après la troisième extension, vous savez laquelle regarder. Une extension qui publie un correctif de sécurité, elle, passe tout de suite, sans attendre votre prochaine séance.

Sur une boutique WooCommerce cliente, mission du 1er juin 2026 : 14 extensions testées sur la préproduction en deux vagues, les 8 à faible risque déployées en premier, WooCommerce, le module de paiement et le constructeur de pages validés sur la préproduction mais gardés pour un créneau dédié. Sauvegarde de la production avant, purge du cache et contrôle HTTP après : 1 h 30 en tout.

Pour le détail par extension, lisez comment mettre à jour un plugin WordPress. Pour les thèmes enfants et premium, voyez comment mettre à jour son thème WordPress sans perdre ses réglages.

La mise à jour en un clic depuis le tableau de bord

C’est la méthode officielle, et d’après la documentation elle fonctionne "on most servers". Voici comment elle se compare aux autres :

Méthode	Pour qui, pour quoi	Ce qu’il faut	Sa limite
En un clic (Tableau de bord > Mises à jour)	Tout le monde, dans la plupart des cas	Un compte administrateur, des fichiers modifiables par le serveur	Réclame des identifiants FTP si le serveur n’est pas propriétaire des fichiers
Manuelle par FTP ou SFTP	Clic en échec, administration inaccessible, gros retard	Un client comme FileZilla, l’archive officielle	Plus longue, erreurs de manipulation possibles
WP-CLI	Accès SSH, plusieurs sites, gestes répétables	WP-CLI installé sur le serveur	La ligne de commande
Automatique	Correctifs de sécurité, extensions à faible risque	Rien, ou un réglage	Ne teste rien à votre place

En pratique : Tableau de bord > Mises à jour, bouton "Mettre à jour vers la version 7.1.2" (ou "Mettre à jour maintenant"). WordPress télécharge la nouvelle version et remplace les fichiers du cœur. Sur le même écran, cochez vos extensions puis "Mettre à jour les extensions", et faites de même avec les thèmes.

Faut-il désactiver toutes les extensions avant ? La procédure manuelle officielle le demande, la mise à jour en un clic non. Sur un site en ligne, tout désactiver revient à servir aux visiteurs un site sans formulaires, sans boutique et sans cache pendant l’opération. Je ne vous le conseille pas.

Pendant ce temps, le mode maintenance

Pendant l’opération, WordPress crée à la racine un fichier .maintenance qui contient l’heure de départ, et le supprime à la fin. Les visiteurs reçoivent un code HTTP 503, l’en-tête Retry-After: 600 et le message "Indisponibilité temporaire pour cause de maintenance. Veuillez revenir dans un instant."

Si le fichier .maintenance reste coincé, WordPress considère la maintenance terminée au bout de 10 minutes, même si le fichier est toujours là. Un fichier wp-content/maintenance.php remplace la page par la vôtre. Pour activer, personnaliser ou débloquer le mode maintenance de WordPress, voyez le guide dédié.

Comment mettre à jour WordPress manuellement par FTP ou SFTP ?

Mettre à jour WordPress manuellement consiste à remplacer vous-même, par FTP ou SFTP, les dossiers wp-admin et wp-includes et les fichiers de la racine par ceux de la nouvelle version, sans supprimer wp-content ni wp-config.php, puis à lancer la mise à jour de la base de données depuis /wp-admin.

La mise à jour manuelle sert quand le clic échoue, quand WordPress réclame des identifiants FTP en boucle, quand l’administration ne répond plus, ou pour rattraper un gros retard. Préférez SFTP quand votre hébergeur le propose : la connexion est chiffrée, mot de passe compris.

1. Sauvegardez la base et tous les fichiers, .htaccess compris, puis vérifiez que la sauvegarde s’ouvre.
2. Téléchargez l’archive sur fr.wordpress.org (la version française) et décompressez-la sur votre ordinateur.
3. Désactivez les extensions, comme le demande la procédure officielle.
4. Sur le serveur, supprimez les anciens dossiers wp-admin et wp-includes.
5. Envoyez les nouveaux wp-admin et wp-includes, puis les fichiers isolés de la racine (index.php, wp-login.php…), qui écrasent les anciens.
6. Copiez le contenu du nouveau wp-content dans le vôtre, en écrasant sans rien supprimer.
7. Comparez wp-config-sample.php avec votre wp-config.php, que l’archive ne remplace pas, et supprimez .maintenance s’il reste d’un échec.
8. Ouvrez /wp-admin : si la base doit être mise à jour, WordPress propose le lien wp-admin/upgrade.php. Puis réactivez les extensions et videz le cache.

La base de données se met à jour en dernier, et le plus tôt possible après le transfert des fichiers, précise la documentation française. En ligne de commande, wp core update-db fait le même travail, et son option --dry-run compare les versions de base sans rien toucher.

J’ai cocréé WPS Cleaner, une extension qui fait le ménage dans la base de données, et contribué à WPS Bidouille. La base est la seule partie qu’aucune archive de WordPress ne vous rendra : exportez-la juste avant chaque montée majeure.

Mettre à jour WordPress en ligne de commande avec WP-CLI

Avec un accès SSH, WP-CLI fait tout ce qui précède en quelques commandes, et de la même façon à chaque fois. Si vous débutez, commencez par installer WP-CLI et apprendre ses commandes de base. Voici l’enchaînement complet, de la sauvegarde à la vérification :

# Où en est le site ?
wp core version --extra
wp core check-update

# Sauvegarde de la base juste avant
wp db export --add-drop-table

# Le cœur, puis la base de données
wp core update
wp core update-db

# Les extensions : aperçu, puis mise à jour (WooCommerce à part)
wp plugin update --all --dry-run
wp plugin update --all --exclude=woocommerce

# Thèmes et traductions
wp theme update --all
wp language core update
wp language plugin update --all
wp language theme update --all

# Vérification d'intégrité
wp core verify-checksums
wp plugin verify-checksums --all

Pour ne prendre que les correctifs, wp core update --minor s’arrête aux versions mineures. Pour viser une version précise, c’est l’option --version. Le 16 juillet, la bascule de wpformation.com s’est jouée ainsi :

wp core update --version=7.0.1 --locale=fr_FR
wp core update-db
wp cache flush

Dernière étape, et pas la moins utile : wp core verify-checksums télécharge les sommes de contrôle officielles de votre version et les compare à vos fichiers, sans charger WordPress, par sécurité. Un fichier du cœur modifié ressort aussitôt. Avec --include-root, WP-CLI signale aussi ce qui n’a rien à faire à la racine.

Sur une installation en français, passez --locale=fr_FR si des fichiers remontent à tort, comme le conseille la documentation. wp plugin verify-checksums --all fait de même pour les extensions (--strict signale jusqu’au readme.txt modifié). Les sommes de contrôle viennent de wordpress.org : une extension achetée ailleurs échappe à ce contrôle.

Mises à jour automatiques : que laisser faire à WordPress ?

Par défaut, WordPress installe seul ses versions mineures et de sécurité depuis 3.7, ainsi que les traductions. Les versions majeures ne sont automatiques par défaut que sur les installations créées depuis WordPress 5.6. Extensions et thèmes restent manuels, sauf si vous activez leurs mises à jour automatiques (depuis 5.5).

La mise à jour automatique

Type de mise à jour	Automatique par défaut ?	Ce que je conseille
Mineures et sécurité du cœur (7.1.1 vers 7.1.2)	Oui depuis 3.7, sur les sites qui se mettent à jour en un clic sans identifiants FTP	Toujours actives
Majeures du cœur (7.0 vers 7.1)	Oui pour les installations créées depuis 5.6, hors site sous contrôle de version. Non pour les installations plus anciennes	Manuelles, après la préproduction
Extensions	Non, sauf cas particuliers décidés par l’équipe de sécurité de WordPress. Activables une par une depuis 5.5	Actives pour les extensions du répertoire à faible risque, manuelles pour boutique, paiement et constructeur
Thèmes	Non, mêmes cas particuliers. Activables depuis 5.5	Manuels : le retour arrière automatique ne couvre pas les thèmes
Traductions	Oui, par défaut	Laissées actives

L’ancienne version de cette page affirmait que WordPress 5.6 active les majeures automatiques pour tout le monde. C’était faux. Seules les nouvelles installations y ont droit ; un site installé avant garde le comportement d’avant, "unless major core auto-updates are enabled by a site administrator, constant, or filter".

Si Tableau de bord > Mises à jour propose "Activer les mises à jour automatiques pour toutes les nouvelles versions de WordPress.", vous êtes en mineures seules. Pour les extensions : lien "Activer les mises à jour auto" sur chaque ligne de l’écran Extensions > Extensions installées.

Sur wpformation.com, les mineures s’installent seules (7.1.2 l’a montré le 22 septembre), les extensions du répertoire aussi, et les majeures passent par moi. Le retour arrière de WordPress 6.6, détaillé plus bas, rend ce choix raisonnable pour les extensions.

Laisser faire les mises à jour de sécurité ne dispense pas de vérifier qu’elles passent. Sur une boutique cliente, le rapport de maintenance de septembre 2026 note que les correctifs 6.9.6 à 6.9.8 n’avaient jamais été appliqués : WP_AUTO_UPDATE_CORE valait false. La constante vaut désormais 'minor'.

En juillet déjà, sur la même boutique, la mise à jour forcée n’était pas passée. Le suivi l’attribuait au cron de WordPress, désactivé côté serveur et géré en WP-CLI. Selon le code du cœur, la constante suffisait à la bloquer, cron ou pas. À noter : les mises à jour automatiques partent d’une tâche planifiée de WordPress, wp_version_check, lancée deux fois par jour.

Cron coupé ou mal relayé, et plus rien ne s’installe seul… avec pour seul signal une ligne "Un évènement planifié est en retard" dans Santé du site. Les réglages qui décident de tout cela :

Réglage	Où	Effet
WP_AUTO_UPDATE_CORE	wp-config.php	true : toutes les versions du cœur, développement comprises. 'minor' : mineures seules. false : aucune. Écrase le réglage de l’écran Mises à jour
AUTOMATIC_UPDATER_DISABLED	wp-config.php	Coupe toutes les mises à jour automatiques, sécurité comprise. "strongly discouraged" selon la documentation
allow_major_auto_core_updates, allow_minor_auto_core_updates	Filtre, extension must-use	Autorise ou bloque les majeures, les mineures
auto_update_plugin, auto_update_theme	Filtre, extension must-use	Force ou bloque les extensions, les thèmes, en écrasant l’interface sans le montrer

Une extension must-use est un fichier PHP déposé dans wp-content/mu-plugins, chargé d’office. La documentation interdit add_filter() dans wp-config.php, où WordPress n’est pas encore chargé (conflits possibles avec WP-CLI). Le code complet est dans mon guide pour désactiver ou régler les mises à jour automatiques.

Comment revenir en arrière après une mise à jour ratée ?

Revenir en arrière dépend de ce qui a cassé. Une extension se remet facilement à sa version précédente, parfois sans vous : WordPress le fait seul dans certains cas depuis 6.3 et 6.6. Le cœur, lui, ne se rétrograde proprement qu’avec la sauvegarde complète des fichiers et de la base faite juste avant la mise à jour.

Ce que WordPress annule tout seul

Le cœur est protégé par un retour arrière automatique depuis WordPress 3.7, quand sa propre mise à jour échoue en route. Depuis 6.3, même filet pour une extension ou un thème que vous mettez à jour à la main : si le processus échoue, l’ancienne version, mise de côté dans wp-content/upgrade-temp-backup/, est remise en place.

Depuis WordPress 6.3, une extension mise à jour à la main qui provoque une erreur fatale PHP n’est pas réactivée, et Santé du site vérifie que le dossier de sauvegarde est accessible en écriture, avec assez d’espace disque.

Depuis 6.6, les mises à jour automatiques d’extensions sont surveillées. WordPress interroge sa propre page d’accueil ; s’il y trouve une erreur fatale PHP, il remet la version précédente et prévient l’adresse e-mail d’administration. Il retentera la mise à jour au passage suivant, et garde le site en maintenance pendant toute la série.

Attention aux limites. Le retour arrière automatique de 6.6 ne concerne que les extensions (les thèmes en sont exclus) et ne cherche qu’une erreur fatale sur la page d’accueil : un tunnel de commande cassé ou une mise en page en vrac passent au travers.

Revenir à la version précédente d’une extension

Le dossier upgrade-temp-backup ne sert pas à revenir en arrière après une mise à jour réussie : pour ça, la note de WordPress 6.3 renvoie elle-même aux extensions de retour arrière. Par exemple :

WP Rollback remet une extension ou un thème de wordpress.org dans une version antérieure (les extensions premium relèvent de sa version payante). En ligne de commande, --version va chercher l’ancienne version sur wordpress.org et --force écrase celle en place :

wp plugin install votre-extension --version=X.Y.Z --force

Revenir à une ancienne version de WordPress

La documentation officielle est nette : c’est possible, mais "usually not recommended", parce que les nouvelles versions embarquent souvent des correctifs de sécurité. Sans sauvegarde de tout le site et de la base faite avant la mise à jour, un retour arrière réussi est même "near impossible".

La procédure officielle : supprimer tous les fichiers de WordPress sauf wp-config.php, renvoyer ceux de la sauvegarde, puis restaurer la base. Remettre d’anciens fichiers en espérant que WordPress "mette la base à jour" au retour dans l’administration ne marche pas.

WP-CLI réinstalle bien d’anciens fichiers (--version et --force), mais wp core update-db ne fait que monter de version. La base, elle, se restaure depuis la sauvegarde, avec wp db import ou votre extension de sauvegarde.

Après la mise à jour : tests, caches et site découplé

Une mise à jour n’est finie qu’une fois le site regardé avec les yeux d’un visiteur, en navigation privée. La liste de contrôle que je vous conseille :

• la page d’accueil et une page de chaque type (article, page, fiche produit) ;
• un vrai envoi du formulaire de contact, reçu dans la bonne boîte ;
• le tunnel de commande jusqu’au paiement, en mode test sur la préproduction ;
• la connexion à l’administration et l’ouverture de l’éditeur de blocs ;
• le code source d’une page : balise title, balise canonique, données structurées ;
• le journal d’erreurs PHP, qui ne doit pas s’être rempli ;
• la boîte mail de l’administrateur, où WordPress envoie ses alertes (retour arrière d’une extension, mode de récupération).

Le 16 juillet, trois articles ont été contrôlés un par un : code 200, titre H1, données structurées, FAQ, images, tableaux, zéro lien cassé.

Viennent ensuite les caches : pages, cache objet, CDN. Tant qu’ils ne sont pas vidés, rappelle la documentation, vos visiteurs, vous compris, continuent de voir l’ancienne version.

Sur un site découplé comme wpformation.com

Le site wpformation.com est découplé : WordPress sert le contenu, un front Next.js l’affiche. La mise à jour du cœur ne touche que le côté WordPress, mais c’est le front qui montre le résultat, d’où le contrôle des pages rendues plutôt que de l’administration. Côté WordPress, le site tourne avec un cache objet persistant :

Redis Object Cache branche WordPress sur Redis : les résultats des requêtes à la base restent en mémoire d’une page à l’autre, au lieu d’être recalculés à chaque visite.

WordPress vide déjà ce cache à la fin de la mise à jour du cœur : la fonction update_core() appelle wp_cache_flush(), et la mise à jour de la base le vide encore deux fois.

Par précaution, la règle est quand même écrite noir sur blanc dans mes notes d’exploitation : wp cache flush après chaque montée du cœur. La documentation de WP-CLI prévient d’ailleurs : "Beware of the performance impact when flushing the object cache in production."

Le front garde aussi sa propre copie des pages : tant qu’il ne les a pas régénérées, le visiteur reçoit l’ancien HTML, même avec un WordPress à jour. C’est ce cache-là qu’on purge en dernier.

Mise à jour bloquée, écran blanc, erreur critique : le dépannage

Voici les messages que vous risquez de croiser, et quoi faire.

"Une autre mise à jour est actuellement en cours" : que faire ? WordPress pose un verrou pendant la mise à jour du cœur ; ce verrou expire de lui-même au bout de 15 minutes. Si une mise à jour interrompue l’a laissé en place, vérifiez qu’aucune mise à jour ne tourne vraiment, puis supprimez-le avec wp option delete core_updater.lock, comme l’indique la documentation de WP-CLI.

Le site affiche "Indisponibilité temporaire pour cause de maintenance" ? Le fichier .maintenance est resté à la racine. Attendez 10 minutes, ou supprimez-le par FTP ; c’est aussi ce que la documentation française prescrit quand l’administration affiche "échec de la mise à jour". Les autres façons de retrouver l’accès à votre wp-admin sont dans mon guide dédié.

Écran blanc ou "Il y a eu une erreur critique sur ce site" ? Depuis WordPress 5.2, une erreur fatale déclenche un e-mail à l’adresse d’administration, avec un lien secret vers le mode de récupération. Ce mode met en pause, pour vous seul, l’extension ou le thème fautif : vous vous connectez, vous le désactivez, le site repart.

Pas d’e-mail ? Renommez par FTP le dossier de l’extension suspecte. C’est la marche à suivre que donnait WP Rocket pour le bug de 7.1 : /wp-content/plugins/wp-rocket/ devenait /wp-content/plugins/wp-rocket-off/, le temps de retrouver l’administration. Pour les autres causes d’écran blanc, voyez les erreurs WordPress les plus fréquentes et leurs solutions.

WordPress vous demande des identifiants FTP ? Question de propriétaire des fichiers : s’ils appartiennent à l’utilisateur du serveur web, WordPress les modifie seul ; sinon, il réclame les identifiants du compte FTP propriétaire. Renseignez-les, ou demandez à votre hébergeur d’ajuster les droits.

Votre site a plusieurs versions de retard ?

Au-delà de deux versions majeures de retard, la documentation officielle conseille de monter par étapes, pour limiter les conflits et les risques pour la base de données. Depuis WordPress 3.7, le bouton de mise à jour sait pourtant vous emmener d’un seul saut à la dernière version, et la documentation juge ce saut sûr.

Le guide des hébergeurs préfère malgré tout les paliers ci-dessous, parce que PHP et la base de données doivent suivre à chaque étape. Sous PHP 5.6.20, où WP-CLI ne fonctionne pas, tout se fait à la main.

Votre version	Étape suivante	PHP visé	Base de données visée
0.7 à 3.6	Migration du contenu vers un WordPress 6.2 neuf	7.4	MySQL 8.0 ou MariaDB 10.11
3.7 à 4.0	4.1	5.6.20 ou plus	MySQL 5.6 ou MariaDB 10.0
4.1 à 4.8	4.9	7.2	MySQL 5.6 ou MariaDB 10.0
4.9 à 5.2	5.3	7.4	MySQL 8.0 ou MariaDB 10.3
5.3 à 6.2	6.2	7.4	MySQL 8.0 LTS ou MariaDB 10.11 LTS
6.3 à 7.1	7.1	8.4	MySQL 8.4 LTS ou MariaDB 11.4 LTS

À chaque étape, prenez la dernière mineure de la branche (4.9.x plutôt que 4.9), précise le guide des hébergeurs. Pour les plus anciennes, il prévoit un ménage avant chaque saut : thèmes inutilisés supprimés, Twenty Ten activé, extensions désactivées. Et une nouvelle sauvegarde à chaque palier réussi.

Quand un site a pris des années de retard, le problème dépasse les mises à jour : il lui manque un plan de maintenance WordPress complet.

Déléguer, ou garder la main

Reste le temps. Honnêtement, comme aujourd’hui quasiment tout est automatisé par l’IA avec une préprod, tout se fait en préprod. C’est testé, tout est vérifié. Ça vérifie que ça fonctionne, et une fois que tout est OK, ça publie en prod. Ça prend moins d’une heure, j’ai envie de dire même pas une heure par semaine en cas de mise à jour.

C’est vrai pour la 7.0.1, passée par un vrai clone le 16 juillet, et pour la boutique cliente du 1er juin. La 7.1, je l’ai lancée à la main depuis le tableau de bord le 22 août, et sur mon site correctifs de sécurité et extensions du répertoire passent tout seuls. Et c’est clairement quelque chose dont je ne m’occupe quasiment plus.

Si vous ne voulez pas y consacrer cette heure, déléguez, mais à quelqu’un qui teste avant de publier. Ce qu’un contrat de maintenance WordPress doit contenir vous aidera à comparer les offres. La mienne démarre à 590 € HT par mois.

Mon conseil pour ce mois-ci tient en un geste : restaurez votre dernière sauvegarde sur une copie du site. Le jour où une mise à jour tournera mal, vous saurez déjà que le retour arrière marche… et la suivante, vous la lancerez sans trembler.

Questions fréquentes

Faut-il faire une sauvegarde avant chaque mise à jour de WordPress ?

Oui, juste avant, base de données et fichiers compris, et une sauvegarde déjà restaurée une fois. Celle du matin peut avoir des heures de retard : pour ma montée en 7.0.1, celle de 9 h 21 en avait neuf.

Dans quel ordre mettre à jour WordPress, les extensions et le thème ?

Sauvegarde, cœur de WordPress, extensions (les plus sensibles une par une), thème, traductions. PHP se change à part, un autre jour, une fois WordPress à jour : PHP 8.4 n’est pleinement pris en charge que depuis WordPress 6.7, et 8.5 depuis 6.9.

Les mises à jour majeures de WordPress sont-elles automatiques ?

Seulement sur les installations créées depuis WordPress 5.6, hors site sous contrôle de version. Les plus anciennes restent en mineures seules, sauf activation dans Tableau de bord > Mises à jour, par WP_AUTO_UPDATE_CORE ou par un filtre.

Comment revenir à la version précédente de WordPress ?

En restaurant la sauvegarde complète faite avant la mise à jour, fichiers et base de données : la documentation officielle juge le retour arrière presque impossible sans elle. Pour une extension, WP Rollback ou wp plugin install avec --version et --force suffisent.

Que faire si le site reste bloqué en maintenance après une mise à jour ?

Supprimez le fichier .maintenance à la racine du site par FTP, ou attendez : WordPress considère la maintenance terminée au bout de 10 minutes, même si le fichier est encore là. Si le message "Une autre mise à jour est actuellement en cours" persiste au-delà de 15 minutes, il s’agit d’un verrou en base, que supprime wp option delete core_updater.lock.

Sources

Sources primaires lues le 29 septembre 2026. Documentation officielle de WordPress :

• Upgrading WordPress, Advanced Administration Handbook, developer.wordpress.org (mis à jour le 01/07/2026)
• Comment mettre à jour WordPress, fr.wordpress.org (traduction du 05/03/2020)
• Upgrading WordPress (16/08/2026) et Server Environment (10/09/2026), Hosting Handbook
• Requirements, wordpress.org, et versions de PHP maintenues, php.net
• Notes de développement : mises à jour automatiques en 5.5, majeures automatiques en 5.6, mode de récupération en 5.2
• Retour arrière : nouveauté de 6.3, proposition de fusion et guide de WordPress 6.6
• Commandes WP-CLI : core update, core update-db, core verify-checksums, plugin verify-checksums, plugin install, cache flush, language plugin update
• Code source de WordPress, dépôt wordpress-develop, branches 7.1 et trunk (class-wp-upgrader.php, class-core-upgrader.php, update-core.php, upgrade.php, load.php, update.php, class-wp-site-health.php), et paquet de langue fr_FR 7.1.2

Versions, failles et incidents :

• WordPress 7.1.2 Security Release (22/09/2026) et historique des versions, wordpress.org
• CVE-2026-87902 : premières tentatives d’exploitation, Patchstack (22/09/2026)
• Known Exploited Vulnerabilities Catalog, CISA (ajout du 25/09/2026), et State of WordPress Security in 2026, Patchstack (25/02/2026)
• Fatal error on WordPress 7.1, documentation de WP Rocket (mise à jour le 14/09/2026)
• Best practices for WordPress updates, Pagely (10/07/2026)
• Fiches wordpress.org et API du répertoire pour WP Rollback et Redis Object Cache

Article original sur WPFormation