Erreur fatale WordPress après une mise à jour : comment récupérer en 2 secondes

Qu’est-ce qu’une erreur fatale PHP dans WordPress ?

Une erreur fatale PHP est une erreur qui arrête complètement l’exécution du script. Dans WordPress, cela se manifeste par le redouté White Screen of Death (WSOD) — une page entièrement blanche, sans message, sans style, sans rien. Les visiteurs voient un site cassé. Vous avez une urgence.

Contrairement aux avertissements ou notices (qui sont enregistrés mais permettent à l’exécution de continuer), une erreur fatale signifie que PHP ne peut pas continuer. WordPress ne peut plus afficher aucune page — pas même le tableau de bord administrateur — jusqu’à résolution.

Les causes les plus fréquentes après une mise à jour de plugin

• Incompatibilité de version PHP — Un plugin mis à jour utilise du PHP 8.1 (propriétés readonly, enums, arguments nommés) sur un serveur PHP 7.4.
• Conflits de classes — Deux plugins définissent une classe avec le même nom sans protection par namespace. PHP refuse deux définitions identiques dans la même requête.
• Appels de fonctions dépréciées — Un plugin appelle une fonction WordPress supprimée dans une version plus récente de WP Core.
• Dépendances manquantes — Un plugin dépend d’un autre plugin désactivé ou d’une librairie absente.

Pourquoi le Recovery Mode de WordPress ne suffit pas

WordPress 5.2 a introduit le Recovery Mode — un mécanisme qui envoie un email avec un lien de récupération quand une erreur fatale est détectée. En théorie, c’est utile. En pratique :

• Il dépend de la livraison d’email — si wp_mail() ne fonctionne pas (configuration courante), le lien n’arrive jamais.
• Il nécessite une action manuelle — quelqu’un doit cliquer sur le lien, se connecter, désactiver le plugin. Comptez 5 à 15 minutes.
• Il désactive le plugin mais ne restaure pas — les fichiers de la version cassée restent en place. Vous devez toujours réinstaller manuellement l’ancienne version.
• Il ne couvre pas les dropins ni les MU-plugins — les erreurs dans ces fichiers lui échappent complètement.

L’architecture de protection SafeCore en 3 couches

Couche 1 : Snapshot pré-mise à jour

Avant chaque mise à jour, SafeCore capture l’état actuel du plugin dans un ZIP. Ce snapshot est immédiatement disponible pour restauration si une erreur survient — c’est la source de vérité de l’état “qui fonctionne”.

Couche 2 : Gestionnaire d’erreurs fatales dropin

SafeCore installe un gestionnaire d’erreurs PHP dans wp-content/fatal-error-handler.php. WordPress charge ce fichier avant tous les plugins, au niveau PHP pur. Quand il intercepte une erreur fatale sur un plugin géré par SafeCore, il écrit un déclencheur de rollback. La requête suivante complète automatiquement la restauration — sans email, sans action manuelle, sans délai.

Couche 3 : Script de récupération standalone

Pour le scénario absolument catastrophique — une erreur fatale si grave que même WordPress ne peut pas s’initialiser — SafeCore déploie un script PHP autonome accessible via une URL secrète. Ce script n’a aucune dépendance WordPress. Il lit le snapshot ZIP et extrait les fichiers directement. Il fonctionne sur n’importe quel serveur capable de servir du PHP.