Un bouton « Mettre à jour » ne contient pas le plan de retour arrière.
WordPress sait appliquer beaucoup de mises à jour automatiquement. Il peut aussi activer son mode de récupération lorsqu’une erreur PHP fatale est détectée. Ces mécanismes sont précieux, mais ils ne restaurent pas à eux seuls une base modifiée, un thème cassé, un formulaire qui n’envoie plus ou un constructeur de pages incompatible.
Avant une intervention importante, je veux pouvoir expliquer comment revenir à l’état précédent, qui prendra la décision et combien de temps cette restauration peut demander. Tant que ces réponses sont floues, la sauvegarde reste une intention.
La réponse courte
Un plan de retour arrière WordPress contient au minimum :
- l’inventaire des versions avant changement ;
- une sauvegarde cohérente des fichiers et de la base ;
- un emplacement de restauration déjà préparé ;
- des critères d’arrêt mesurables ;
- la procédure exacte de restauration ;
- les tests qui prouvent le retour au service ;
- un délai au-delà duquel on arrête de réparer en direct.
Le meilleur plan ne promet pas qu’aucun problème ne surviendra. Il réduit le temps passé à improviser pendant que le site est indisponible.
Retour arrière, restauration et correction ne sont pas synonymes
Trois actions sont souvent mélangées.
Corriger en avant
On conserve la nouvelle version et on corrige le défaut : réglage, patch, nouvelle version d’une extension ou adaptation du thème.
Cette approche convient lorsqu’on comprend la cause et que la correction est courte, testée et moins risquée que la restauration.
Revenir sur un composant
On réinstalle une version précédente d’une extension, d’un thème ou du cœur. Ce retour peut suffire si le changement n’a pas modifié les données de manière incompatible.
Il faut vérifier la documentation du composant. Remplacer uniquement les fichiers ne remet pas forcément la base dans son état précédent.
Restaurer l’ensemble
On remet les fichiers et la base depuis un même jeu de sauvegarde. C’est la réponse la plus complète lorsque plusieurs couches ont changé ou lorsque l’état produit est incertain.
Elle efface aussi les nouvelles données créées après la sauvegarde : commandes, formulaires, commentaires, inscriptions ou modifications éditoriales. Le plan doit donc annoncer ce risque et prévoir leur récupération si nécessaire.
Inventorier avant de sauvegarder
Je conserve une fiche datée :
- version de WordPress ;
- version de PHP ;
- version de la base de données ;
- serveur web ;
- thème actif et thème parent ;
- extensions actives, inactives et obligatoires ;
- code personnalisé ;
- tâches planifiées importantes ;
- services externes ;
- espace disque disponible ;
- méthode de sauvegarde et de restauration.
Cet inventaire permet de vérifier que l’environnement restauré correspond réellement à l’état attendu.
Avec WP-CLI, wp core version indique la version du cœur et wp core verify-checksums peut comparer les fichiers du cœur aux sommes de contrôle officielles. Ces commandes ne valident ni le thème, ni les extensions, ni les données.
Pour un exemple concret de correction qui doit survivre aux mises à jour, voyez aussi comment afficher les derniers commentaires sans modifier le cœur de WordPress.
Former un jeu de sauvegarde cohérent
La documentation officielle WordPress Backups rappelle qu’un site typique possède deux ensembles distincts : les fichiers et la base de données.
Les fichiers contiennent notamment :
- le cœur ;
- les extensions ;
- les thèmes ;
- les médias ;
wp-config.php;- les règles du serveur ;
- le code personnalisé.
La base contient notamment :
- articles et pages ;
- commentaires ;
- comptes et rôles ;
- réglages ;
- menus ;
- métadonnées ;
- données créées par les extensions.
Je crée les deux sauvegardes dans un intervalle court et je les identifie comme un même jeu. Une base de lundi associée aux fichiers de jeudi peut produire un site techniquement restauré mais incohérent.
Ne pas stocker l’unique copie sur le serveur à modifier
Une archive placée uniquement dans le répertoire du site reste exposée à :
- la panne du disque ;
- une erreur de manipulation ;
- un manque d’espace ;
- un chiffrement malveillant ;
- une suppression lors d’un déploiement ;
- une compromission du même compte.
Je conserve au moins une copie hors de la machine de production et je vérifie que son téléchargement est terminé. Le nom du fichier doit contenir la date, le site et le type de données.
Si la sauvegarde contient des données personnelles ou des secrets, son stockage doit être protégé en conséquence. Publier une archive dans un répertoire web accessible transforme un mécanisme de secours en fuite potentielle.
Tester la restauration avant la mise à jour
Une archive qui s’ouvre n’est pas encore une restauration.
Le test consiste à remettre les fichiers et la base dans un environnement isolé, puis à vérifier :
- page d’accueil ;
- connexion administrateur ;
- articles et médias ;
- menus ;
- formulaires ;
- recherche ;
- permaliens ;
- tâches nécessaires ;
- absence d’appel vers des services de production lorsque le clone ne doit pas en envoyer.
Le clone doit neutraliser les e-mails, paiements, webhooks, statistiques et indexation s’ils risquent d’affecter de vraies personnes ou données.
Je note le temps nécessaire. Une restauration qui demande quatre heures n’est pas adaptée à une interruption maximale de trente minutes.
Préparer la fenêtre de maintenance
Je choisis une période où :
- la fréquentation est faible ;
- la personne capable de restaurer est disponible ;
- les accès au serveur et à la base fonctionnent ;
- la sauvegarde hors site est accessible ;
- les services externes peuvent être contrôlés ;
- un délai de surveillance est prévu après l’intervention.
Je n’empile pas la mise à jour du système, de PHP, de WordPress, du thème et de toutes les extensions dans la même fenêtre. Une couche à la fois permet de relier le symptôme au changement.
Cette séparation est particulièrement importante lorsqu’on choisit d’héberger soi-même son blog WordPress : le système, le serveur web, PHP, la base et le CMS n’ont ni le même cycle ni la même méthode de retour arrière.
Définir les critères d’arrêt
Sans critère, on passe facilement deux heures à « essayer encore un truc » sur la production.
Exemples de critères :
- erreur fatale ou écran blanc persistant après la vérification prévue ;
- administration inaccessible ;
- page d’accueil ou article principal inutilisable ;
- formulaire critique en échec ;
- requêtes ou erreurs serveur dépassant un seuil défini ;
- absence de cause identifiée après quinze minutes ;
- restauration estimée plus courte que la correction.
Ces seuils doivent être adaptés au site. Un blog personnel et une boutique n’ont pas le même impact ni les mêmes données créées pendant l’interruption.
Écrire la procédure avant d’en avoir besoin
Le plan doit pouvoir être suivi sous stress.
Exemple de séquence
- annoncer et noter le début de l’intervention ;
- bloquer les écritures si le site en reçoit beaucoup ;
- créer le dernier jeu de sauvegarde ;
- vérifier taille, date et disponibilité hors production ;
- appliquer un seul changement ;
- exécuter la checklist ;
- surveiller journaux et fonctions ;
- continuer ou déclencher le retour ;
- restaurer fichiers puis base selon la méthode testée ;
- remettre la configuration cohérente ;
- vider les caches nécessaires ;
- exécuter la même checklist ;
- rouvrir les écritures ;
- documenter le résultat.
L’ordre précis dépend de l’infrastructure. Je ne copie pas une procédure générique sur un serveur inconnu sans l’adapter.
Comprendre le mode de récupération WordPress
Le mode de récupération peut s’activer lorsque WordPress détecte une erreur PHP fatale pendant un chargement normal. Un e-mail est envoyé à l’adresse administrateur avec un lien spécial.
Dans cette session, l’extension ou le thème défaillant peut être mis en pause pour permettre la connexion et le diagnostic.
Ce mécanisme possède des limites :
- il dépend de la détection d’une erreur fatale ;
- les erreurs de tâche planifiée ou de fond ne l’activent pas forcément ;
- l’e-mail peut ne pas arriver ;
- une panne de base, de serveur ou de réseau dépasse son périmètre ;
- il ne restaure pas les données ;
- il ne valide pas les fonctions silencieusement cassées.
Je vérifie donc l’adresse administrateur et la délivrabilité, mais je conserve un accès indépendant aux fichiers, à la base et aux journaux.
Tester les fonctions, pas seulement la page d’accueil
Un site peut afficher son accueil tout en étant partiellement cassé.
Ma checklist minimale comprend :
- une page et un article ;
- connexion et déconnexion ;
- création d’un brouillon ;
- média ;
- formulaire de contact ;
- recherche ;
- menu ordinateur et mobile ;
- consentement et scripts conditionnels ;
- flux RSS ;
- tâches planifiées importantes ;
- journaux PHP et serveur ;
- absence d’erreur console bloquante.
Je teste aussi l’action qui motivait la mise à jour. Une version plus récente qui ne corrige pas le problème initial ajoute du risque sans bénéfice vérifié.
Protéger les données créées pendant l’incident
Entre la sauvegarde et le retour arrière, le site peut recevoir de nouvelles données.
Pour BlackFury, cela peut inclure commentaires, formulaires ou nouveaux abonnements. Pour une boutique, commandes et paiements rendent la question beaucoup plus sensible.
Le plan doit décider :
- faut-il mettre le site en lecture seule ?
- quelles tables ou données doivent être exportées avant restauration ?
- comment réconcilier les éléments créés après la sauvegarde ?
- qui vérifie qu’aucune demande n’a disparu ?
Restaurer toute la base sans examiner cet intervalle peut résoudre la panne technique en créant une perte métier.
Conserver un journal de changement
Je note :
- date et heure ;
- personne ;
- version avant et après ;
- sauvegarde utilisée ;
- commandes ou actions ;
- tests ;
- erreurs ;
- décision de continuer ou revenir ;
- durée ;
- travail restant.
Ce journal évite de répéter un échec six mois plus tard et permet de préparer la prochaine fenêtre avec de vraies durées.
La matrice de décision
| Situation | Action probable |
|---|---|
| Cause identifiée, correction courte et testée | Corriger en avant |
| Extension incompatible, données inchangées | Revenir sur le composant après vérification |
| Plusieurs couches modifiées | Restaurer le jeu complet |
| Nouvelles données importantes depuis la sauvegarde | Isoler et réconcilier avant restauration |
| Panne non comprise et délai dépassé | Déclencher le retour prévu |
| Sauvegarde non restaurable | Arrêter la mise à jour avant de commencer |
Le verdict BlackFury
Le retour arrière ne commence pas quand WordPress affiche une erreur critique. Il commence avant la mise à jour, lorsque l’on vérifie la sauvegarde, la restauration, les accès et les critères d’arrêt.
Une procédure courte et testée vaut mieux qu’une liste de vingt commandes copiées depuis un autre serveur. Le but n’est pas d’éviter toute panne. Il est d’empêcher qu’une panne connue devienne une nuit d’improvisation.
Pour BlackFury, la règle restera simple : une couche à la fois, une preuve de restauration et une porte de sortie documentée avant chaque évolution importante.
