Restaurer un site après une mise à jour ratée
Écran blanc, erreur critique, wp-admin inaccessible après une mise à jour : la méthode pour revenir à un état fonctionnel sans perdre les commandes passées entre-temps.
Ce que je regarde en premier
Une mise à jour ratée ne se manifeste pas toujours de la même façon, et le symptôme oriente directement le diagnostic. Avant de restaurer quoi que ce soit, je détermine précisément ce qui est cassé : le site entier, uniquement l’administration, ou uniquement une fonctionnalité précise comme le tunnel de commande WooCommerce. Restaurer une sauvegarde complète à l’aveugle, sans ce diagnostic, revient souvent à réparer un problème mineur au prix d’une perte de données évitable.
La cause exacte est presque toujours l’une de ces trois choses : un mode maintenance resté bloqué après une interruption, une extension ou un thème incompatible avec la nouvelle version, ou une erreur fatale PHP dans du code qui n’a jamais été testé sur cette configuration. Distinguer ces trois cas avant d’agir évite de restaurer une sauvegarde complète quand une simple désactivation d’extension aurait suffi.
Ce qu’on voit après une mise à jour qui a mal tourné
- Écran blanc (White Screen of Death) : aucune page ne s’affiche, ni sur le site public ni dans l’administration
- Message « Une erreur critique s’est produite sur ce site », avec ou sans détail technique visible
- Administration inaccessible mais le site public semble fonctionner normalement
- Site public en erreur mais l’administration reste accessible, souvent le signe d’un conflit spécifique au thème actif
- Site bloqué en mode maintenance après une mise à jour interrompue, avec le message habituel « en maintenance, revenez bientôt »
Comment je restaure un site après une mise à jour ratée
-
Lecture du journal debug.log
J’active ou je consulte le journal de débogage pour identifier la cause exacte : mode maintenance resté bloqué (fichier .maintenance non supprimé), extension incompatible, ou erreur fatale PHP précise avec le nom du fichier en cause.
-
Isolation par renommage FTP
Si le journal désigne une extension ou un thème précis, je le désactive en renommant son dossier par FTP, sans passer par le tableau de bord s’il est inaccessible. WordPress traite un dossier renommé comme un plugin manquant et le désactive automatiquement.
-
Vérification après isolation
Si le site redevient fonctionnel après cette désactivation ciblée, la cause est confirmée. Je peux alors chercher une version compatible de l’extension ou une alternative, sans avoir touché à la base de données.
-
Restauration complète si la cause reste incertaine
Si le journal ne permet pas d’isoler rapidement la cause, ou si plusieurs éléments semblent en cause à la fois, je restaure la sauvegarde base et fichiers prise avant la mise à jour plutôt que de continuer à chercher à l’aveugle.
Pages liées
-
Erreur critique sur ce site
Le détail des causes possibles derrière ce message générique et la méthode pour les distinguer rapidement.
-
Activer le mode debug WordPress
Comment activer WP_DEBUG et lire debug.log sans exposer les erreurs aux visiteurs du site.
-
Lire les logs d’erreurs WooCommerce
Où trouver et comment interpréter les journaux spécifiques à WooCommerce, distincts du journal WordPress général.
-
Sauvegarder une boutique avant une intervention
Ce qu’une sauvegarde doit couvrir avant toute mise à jour ou intervention risquée, pour qu’elle serve vraiment le jour où on en a besoin.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.