# 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.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](https://allaux.fr/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Renommez d’abord wp-content/plugins en plugins-off par FTP : si le site revient, une extension est en cause et vous les réactivez une par une. Si l’écran reste blanc, restaurez la sauvegarde des fichiers seule, sans toucher à la base : les commandes et les contenus enregistrés depuis la mise à jour y sont, et une restauration complète de la base les effacerait. Exportez-les avant si vous devez aussi la restaurer.

## 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

1. **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.
2. **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.
3. **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.
4. **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.

## Le point de non-retour : les commandes passées entre-temps

> Si la boutique WooCommerce a continué de recevoir des commandes entre la sauvegarde et l’incident, restaurer purement et simplement cette sauvegarde écrase ces commandes en base. Avant toute restauration, j’extrais les commandes récentes (export ou copie ciblée des tables concernées) pour les réintégrer après coup. Une fois la restauration lancée sans cette extraction, ces commandes sont perdues.

## Comment je vérifie après restauration

> Affichage du site public et du tableau de bord, connexion administrateur, tunnel de commande complet jusqu’au paiement, et présence des commandes passées avant l’incident, y compris celles réintégrées manuellement si une extraction a été nécessaire.

## 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. ([/wordpress-woocommerce/erreur-critique](/wordpress-woocommerce/erreur-critique))
- **Activer le mode debug WordPress** — Comment activer WP_DEBUG et lire debug.log sans exposer les erreurs aux visiteurs du site. ([/guides/activer-mode-debug-wordpress](/guides/activer-mode-debug-wordpress))
- **Lire les logs d’erreurs WooCommerce** — Où trouver et comment interpréter les journaux spécifiques à WooCommerce, distincts du journal WordPress général. ([/guides/lire-logs-erreurs-woocommerce](/guides/lire-logs-erreurs-woocommerce))
- **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. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))

## FAQ

### Le mode maintenance bloqué peut-il vraiment tout casser ?

Oui. Si une mise à jour est interrompue (coupure réseau, dépassement de temps d’exécution), le fichier .maintenance créé temporairement par WordPress peut rester en place et bloquer tout le site derrière le message « en maintenance ». La solution est souvent aussi simple que de supprimer ce fichier par FTP.

### Comment savoir si c’est le thème ou une extension qui est en cause ?

Le journal debug.log indique généralement le fichier exact à l’origine de l’erreur fatale, ce qui identifie directement le plugin ou le thème responsable. En l’absence de piste claire, je désactive les extensions une par une par renommage FTP jusqu’à ce que le site refonctionne.

### Peut-on éviter de perdre les commandes en cas de restauration complète ?

Oui, en extrayant les commandes passées entre la sauvegarde et l’incident avant de lancer la restauration, puis en les réintégrant dans la base restaurée. C’est une étape manuelle qui doit être faite avant, jamais après.

### Combien de temps prend une restauration après incident ?

Une désactivation ciblée d’extension se règle en quelques minutes. Une restauration complète avec extraction préalable des commandes prend plus de temps, généralement de une à plusieurs heures selon la taille de la base.