Corriger l’erreur critique WordPress : activer WP_DEBUG et récupérer le site

Ce que signifie réellement l’« erreur critique » de WordPress

Cette bannière est la façon dont WordPress reste poli face à une erreur fatale PHP. Quelque chose a lancé une exception ou rencontré une condition fatale et PHP a arrêté l’exécution. WordPress n’a pas pu rendre la page, il a donc affiché le message de repli « erreur critique ». À une époque plus ancienne, on parlait du « white screen of death » (WSOD). Aujourd’hui vous obtenez un message plus convivial et, parfois, un courriel à l’administrateur avec un lien de récupération.

Sur un système fonctionnel, une erreur fatale laisse quand même une trace : les logs PHP‑FPM, les logs Apache/Nginx, un journal de debug WordPress (si activé), et parfois une trace d’un outil de monitoring de performance applicative. Votre travail est de collecter la première trace utile et ensuite prendre une décision propre : rollback, désactiver, patcher ou restaurer.

Ce que ce n’est pas

• Ce n’est pas une défaillance de connexion à la base de données. Cela affiche généralement « Error establishing a database connection. »
• Ce n’est pas nécessairement une panne du serveur. Votre serveur web peut être sain alors que PHP plante.
• Ce n’est pas la preuve que WordPress est « instable ». C’est la preuve que quelqu’un a livré du code qui ne correspond pas à la réalité (versions, dépendances, hypothèses).

Méthode de diagnostic rapide (première/deuxième/troisième)

Quand un site de production est en panne, vous ne commencez pas à « explorer ». Vous exécutez un court playbook et forcez le système à vous dire ce qui s’est passé.

Première étape : confirmer qu’il s’agit d’une fatale PHP et obtenir la ligne exacte

• Vérifiez le journal d’erreurs du serveur web et le journal PHP‑FPM pour les dernières minutes.
• Si vous voyez une trace de pile mentionnant un chemin de plugin ou de thème, vous avez déjà une cible.
• Si les logs sont vides ou inutiles, activez le logging WordPress vers un fichier seulement et rechargez une fois.

Deuxième étape : isoler le changement qui l’a déclenchée

• Demandez : qu’est‑ce qui a changé ? Mise à jour automatique d’un plugin, mise à jour du thème, montée de version PHP, nouveau plugin MU, durcissement de la sécurité ?
• Restaurez le changement le plus récent en premier. Ne faites pas cinq « corrections » et vous demandez ensuite laquelle a marché.

Troisième étape : restaurer le service avec le contournement le moins risqué

• Désactivez le plugin fautif (renommez le répertoire ou utilisez WP‑CLI) et remettez le site en ligne.
• Basculer vers un thème par défaut si le thème est en cause.
• Si les fichiers core sont corrompus, réinstallez le core (sans toucher wp-content).
• Si rien d’autre : restaurez depuis une sauvegarde connue‑bonne, puis réappliquez les changements prudemment.

Oui, vous pouvez passer une heure à déboguer le bug sous‑jacent. Mais si le PDG surveille le chargement de la page d’accueil sur son téléphone, vous la faites d’abord charger.

Quelques faits et historique utiles (pour arrêter de deviner)

1. WordPress a introduit le « fatal error recovery mode » dans la 5.2 (2019), incluant des e‑mails aux admins et un lien de « récupération » quand un plugin/thème provoque une fatale.
2. Le WSOD classique était souvent « juste » la sortie fatale PHP masquée par display_errors=Off et aucune configuration de log—silence, pas absence.
3. WP_DEBUG est une constante WordPress, pas un réglage PHP. Elle change le comportement de WP (notamment les notices) mais ne remplace pas la journalisation PHP.
4. WP_DEBUG_LOG peut écrire dans wp-content/debug.log même quand les erreurs ne sont pas affichées aux utilisateurs—utile, et aussi risqué pour la confidentialité si mal configuré.
5. Beaucoup d’erreurs critiques viennent d’un décalage de versions. Un plugin requiert PHP 8.1 ; le serveur est en PHP 7.4. Ou un plugin attend des hooks WP apparus dans un core plus récent.
6. La mise en cache d’opcode (OPcache) peut donner l’impression que les rollbacks sont « ignorés ». Vous déployez un correctif, mais l’ancien bytecode reste jusqu’au vidage du cache.
7. Les mises à jour automatiques ont réduit le délai de patch mais augmenté les pannes surprises. Surtout sur des sites dont les plugins « fonctionnent sur mon staging » sans tests d’intégration.
8. Certains hébergeurs interceptent les erreurs PHP et affichent leur propre page conviviale, ce qui peut masquer la vraie défaillance si vous n’inspectez pas les logs serveur.

Une vérité opérationnelle de plus : WordPress est une appli PHP qui tourne dans un écosystème partagé serveur web + gestionnaire PHP + système de fichiers + base de données + cache. La plupart des pannes se produisent aux frontières entre ces éléments, pas « dans WordPress lui‑même ».

Règles de sécurité avant de toucher à WP_DEBUG

Le débogage est l’endroit où les bonnes intentions deviennent des fuites de données. Soyez délibéré.

• N’activez jamais l’affichage public des erreurs en production. C’est‑à‑dire : gardez WP_DEBUG_DISPLAY désactivé, gardez PHP display_errors désactivé.
• Journalisez vers un fichier, pas vers le navigateur. La sortie navigateur peut exposer des secrets, des chemins et des tokens à tout le monde, y compris aux crawlers.
• Considérez que les logs de debug contiennent des données personnelles. E‑mails, cookies, parfois en‑têtes de requête—selon ce que les plugins consignent.
• Limitez le temps. Activez le logging, reproduisez une fois, capturez la trace, puis désactivez ou faites pivoter les logs.
• Ne réglez pas tout en chmod 777. Vous corrigerez l’erreur et en créerez une plus grande.

Blague #1 : Activer WP_DEBUG_DISPLAY en production, c’est comme annoncer vos mots de passe à un micro dans un stade—efficace techniquement, catastrophique socialement.

Activer WP_DEBUG correctement (et capturer l’erreur réelle)

Vous activez trois choses dans wp-config.php : le mode debug, l’écriture vers un fichier, et la non‑affichage. Optionnel : définissez un chemin de log personnalisé hors de la racine web (mieux). Pensez aussi à désactiver la concaténation des scripts, ce qui peut aider pour déboguer les problèmes JS de l’administration, mais ce n’est généralement pas le cas pour une « erreur critique ».

Paramètres recommandés, sûrs pour la production

Placez ces lignes au‑dessus de la ligne qui dit /* That's all, stop editing! */. Si vous ne voyez pas cette ligne, votre wp-config.php peut être personnalisé ; placez‑les quand même avant le chargement de WordPress.

cr0x@server:~$ sudo sed -n '1,180p' /var/www/html/wp-config.php
...output...

Ce que vous voulez ajouter (montré ici comme un modèle mental de patch, pas comme une commande littérale) :

• define('WP_DEBUG', true);
• define('WP_DEBUG_LOG', true); ou un chemin comme /var/log/wordpress/debug.log
• define('WP_DEBUG_DISPLAY', false);
• @ini_set('display_errors', 0); (défense en profondeur ; la configuration PHP devrait déjà le faire)

Opinion : si vous pouvez, journalisez dans /var/log/wordpress/ avec des permissions verrouillées, pas dans wp-content/debug.log. Trop de configurations servent accidentellement des fichiers depuis wp-content si quelqu’un ajoute une règle permissive ou dérègle Nginx.

Après avoir capturé l’erreur, désactivez‑le

Le mode debug n’est pas un mode de vie. C’est un outil de diagnostic. Si vous le laissez activé, vous allez gonfler les logs, divulguer des chemins, et dégrader les performances avec des notices excessives.

Tâches pratiques : commandes, sorties et décisions (12+)

Ci‑dessous figurent des tâches réelles à exécuter en SSH. Chacune inclut : la commande, ce que signifie la sortie, et la décision à prendre. Ajustez les chemins pour votre distribution et la disposition des vhosts. En cas de doute, cherchez dans vos configs plutôt que de vous fier à la mémoire.

Tâche 1 : Vérifier que le site échoue comme les utilisateurs le voient

cr0x@server:~$ curl -I https://example.com/
HTTP/2 500
date: Thu, 26 Dec 2025 12:11:09 GMT
content-type: text/html; charset=UTF-8

Sens : HTTP 500 confirme une défaillance côté serveur (pas seulement un cache navigateur).

Décision : Passez immédiatement aux logs serveur ; ne perdez pas de temps dans les liens wp-admin qui ne se chargeront pas.

Tâche 2 : Vérifier le log d’erreurs Nginx autour de l’heure de l’incident

cr0x@server:~$ sudo tail -n 80 /var/log/nginx/error.log
2025/12/26 12:10:58 [error] 2211#2211: *184 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91
Stack trace:
#0 /var/www/html/wp-settings.php(526): include_once()
#1 /var/www/html/wp-config.php(102): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php on line 91" while reading response header from upstream, client: 203.0.113.44, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Sens : Vous avez l’arme fumante : le plugin acme-cache appelle une fonction WordPress absente de cette version de core.

Décision : Désactivez d’abord ce plugin pour rétablir le service, puis traitez la compatibilité de versions.

Tâche 3 : Vérifier le journal du pool PHP‑FPM (si Nginx n’apporte pas assez d’infos)

cr0x@server:~$ sudo tail -n 60 /var/log/php8.1-fpm.log
[26-Dec-2025 12:10:58] WARNING: [pool www] child 3112 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91"

Sens : Cela confirme que ce n’est pas un artefact d’analyse Nginx ; PHP meurt réellement.

Décision : Procédez à la désactivation du plugin ; pas besoin d’activer WP_DEBUG si les logs montrent déjà la trace.

Tâche 4 : Activer le logging WP DEBUG (fichier seulement) quand les logs sont silencieux

cr0x@server:~$ sudo grep -n "WP_DEBUG" -n /var/www/html/wp-config.php

Sens : Une sortie vide signifie que les constantes de debug ne sont pas définies.

Décision : Ajoutez des paramètres de debug sûrs pour la production. Si la sortie montre des définitions conflictuelles, corrigez les doublons (la première définition l’emporte d’une manière surprenante).

Tâche 5 : Créer un répertoire de logs plus sûr hors de la racine web

cr0x@server:~$ sudo install -d -o www-data -g www-data -m 0750 /var/log/wordpress

Sens : Le répertoire existe, appartient à l’utilisateur web, lisible uniquement par le propriétaire/groupe.

Décision : Utilisez /var/log/wordpress/debug.log comme cible pour WP_DEBUG_LOG.

Tâche 6 : Éditer wp-config.php en toute sécurité et vérifier la syntaxe

cr0x@server:~$ sudo php -l /var/www/html/wp-config.php
No syntax errors detected in /var/www/html/wp-config.php

Sens : Votre modification n’a pas introduit d’erreur de parsing. Oui, des gens font ça à 2 h du matin.

Décision : Si vous voyez « Parse error », revenez immédiatement en arrière ; une erreur de parse briquera tout, y compris le mode de récupération WP.

Tâche 7 : Déclencher une requête et inspecter le debug log WordPress

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
500

cr0x@server:~$ sudo tail -n 80 /var/log/wordpress/debug.log
[26-Dec-2025 12:12:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/acme-cache/acme-cache.php:91

Sens : Le debug log confirme le fichier/ligne en échec.

Décision : Désactivez ce plugin ; ne continuez pas à rafraîchir et générer du bruit.

Tâche 8 : Désactiver un plugin sans wp-admin en renommant son répertoire

cr0x@server:~$ cd /var/www/html/wp-content/plugins
cr0x@server:~$ sudo mv acme-cache acme-cache.disabled

Sens : WordPress ne peut plus charger le plugin ; il le marquera inactif.

Décision : Rechargez le site. S’il retourne 200, vous avez rétabli le service ; ensuite investiguez la compatibilité et la stratégie de mise à jour.

Tâche 9 : Utiliser WP‑CLI pour lister les plugins et désactiver proprement (préféré si possible)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+-------------------+----------+--------+---------+
| name              | status   | update | version |
+-------------------+----------+--------+---------+
| woocommerce       | active   | none   | 8.2.1   |
| acme-cache        | active   | none   | 3.4.0   |
+-------------------+----------+--------+---------+

cr0x@server:~$ sudo -u www-data wp plugin deactivate acme-cache
Plugin 'acme-cache' deactivated.

Sens : WP‑CLI peut communiquer avec votre installation WordPress ; c’est un bon signe que la base est atteignable et que le core se charge au moins partiellement.

Décision : Préférez la désactivation via WP‑CLI plutôt que le renommage de répertoire pour un état plus propre—sauf si la fatale empêche WP‑CLI de démarrer.

Tâche 10 : Vérifier la version actuelle du core WordPress et la comparer aux exigences du plugin

cr0x@server:~$ sudo -u www-data wp core version
5.6.14

Sens : Le core est ancien. Beaucoup de plugins modernes supposent des fonctions plus récentes.

Décision : Planifiez une mise à jour contrôlée du core en staging, pas une mise à jour paniquée en production—sauf si la sécurité l’exige.

Tâche 11 : Basculer vers un thème par défaut pour exclure une fatale liée au thème

cr0x@server:~$ sudo -u www-data wp theme list
+------------------+----------+--------+---------+
| name             | status   | update | version |
+------------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| custom-corp      | active   | none   | 9.7     |
+------------------+----------+--------+---------+

cr0x@server:~$ sudo -u www-data wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Sens : Si le site revient, le thème est en cause (souvent functions.php ou un include personnalisé).

Décision : Gardez le thème par défaut temporairement pour rétablir le service, puis corrigez le code du thème dans un déploiement contrôlé.

Tâche 12 : Confirmer la version de PHP et les modules (piège de compatibilité fréquent)

cr0x@server:~$ php -v
PHP 8.1.2 (cli) (built: Jan 15 2025 10:22:01) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2, Copyright (c), by Zend Technologies

Sens : La version CLI PHP est 8.1. Ce n’est pas toujours la même que la version FPM, mais c’est un indice.

Décision : Vérifiez aussi quel PHP‑FPM est utilisé dans la config Nginx/Apache. Un décalage entre CLI et FPM mène à des sessions de débogage absurdes.

Tâche 13 : Identifier le backend PHP‑FPM utilisé par le site

cr0x@server:~$ sudo grep -R "fastcgi_pass" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42: fastcgi_pass unix:/run/php/php8.1-fpm.sock;

Sens : Nginx utilise explicitement php8.1-fpm.

Décision : Si le socket pointe vers un PHP plus ancien/plus récent que prévu, alignez‑les. Beaucoup d’« erreurs critiques » ne sont que « mauvais PHP ».

Tâche 14 : Vérifier les problèmes de limite mémoire (fatales qui paraissent aléatoires)

cr0x@server:~$ sudo -u www-data wp eval 'echo ini_get("memory_limit"), PHP_EOL;'
128M

Sens : La limite mémoire est de 128M. Pour WooCommerce moderne + constructeurs de pages, c’est parfois trop juste.

Décision : Si les logs indiquent « Allowed memory size exhausted », augmentez la mémoire dans le pool PHP‑FPM ou php.ini et retestez. Ne la réglez pas aveuglément à 2G ; corrigez aussi le composant gourmand.

Tâche 15 : Vérifier l’espace disque et l’épuisement d’inodes (oui, ça casse WordPress)

cr0x@server:~$ df -h /var/www /var/log
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  1.2G  97% /

cr0x@server:~$ df -i /var/www
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2620000   1440  100% /

Sens : Les inodes sont pratiquement épuisés. PHP peut échouer à écrire les sessions, caches, uploads, logs. Les erreurs se propagent.

Décision : Nettoyez les explosions de petits fichiers (répertoires de cache, anciennes sauvegardes, logs de debug), puis envisagez de déplacer uploads/cache vers un stockage séparé.

Tâche 16 : Vérifier la connectivité à la base via WP‑CLI

cr0x@server:~$ sudo -u www-data wp db check
Success: Database checked.

Sens : La base est joignable et les tables sont correctes à un niveau basique.

Décision : Si cela échoue, arrêtez de blâmer les plugins ; corrigez d’abord les identifiants DB, la disponibilité MySQL ou les permissions.

Tâche 17 : Vider l’OPcache (lorsque vous êtes sûr que le déploiement est correct mais que le comportement ne correspond pas)

cr0x@server:~$ sudo systemctl reload php8.1-fpm

Sens : Un reload vide généralement OPcache et redémarre les workers en douceur (dépend de la config).

Décision : Utilisez reload après des changements de code quand les symptômes ne correspondent pas au système de fichiers. Si vous avez besoin d’un reset complet, redémarrez—mais faites‑attention à la concurrence et au trafic.

Voies de récupération : plugins, thèmes, core, PHP

Voie A : Une mise à jour de plugin a cassé le site

C’est le cas le plus courant. Le mode d’échec : le plugin suppose qu’une fonction/classe existe, ou il a introduit une erreur de syntaxe, ou il requiert une version PHP plus récente.

Faites ceci :

• Désactivez le plugin (WP‑CLI deactivate, ou renommez le répertoire).
• Remettez le site en ligne.
• Puis décidez : mettez à jour le core/PHP pour satisfaire les exigences, ou revenez à une version du plugin compatible.

Évitez ceci : laisser le plugin désactivé sans comprendre ce qu’il faisait. S’il gérait le cache, la sécurité, les paiements ou les formulaires, vous avez peut‑être rétabli la page d’accueil tout en cassant silencieusement le revenu.

Voie B : Le thème provoque des fatales (functions.php est une scène de crime)

Les thèmes intègrent souvent des « mini frameworks ». Les thèmes personnalisés aiment appeler des fonctions de plugins qu’ils supposent actifs. Ensuite quelqu’un désactive le plugin, et le thème s’effondre.

• Basculez sur un thème par défaut via WP‑CLI.
• Si WP‑CLI ne peut pas se charger, renommez wp-content/themes/custom-theme et WordPress tombera sur le thème par défaut.
• Une fois stable, corrigez le thème pour qu’il gère gracieusement les dépendances manquantes.

Voie C : Incompatibilité ou corruption du core

Parfois l’« erreur critique » vient parce que des fichiers core manquent (mauvais déploiement) ou sont modifiés (compromission, ou un plugin a écrit où il ne fallait pas).

Correction : réinstallez le core WordPress sans toucher wp-content et wp-config.php.

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp core verify-checksums
Warning: File should not exist: wp-includes/some-stray-file.php
Error: Checksum verification failed.

Décision : Si les checksums échouent, réinstallez le core (wp core download --force) puis revérifiez. Si des fichiers inattendus existent, traitez‑la comme un incident de sécurité jusqu’à preuve du contraire.

Voie D : Une montée de version PHP a cassé un plugin (ou l’a corrigé et exposé d’anciens bugs)

Les montées de version PHP sont excellentes jusqu’à ce qu’elles ne le soient plus. Les fonctionnalités dépréciées deviennent fatales, le typage strict se durcit, et les bibliothèques se comportent différemment.

Stratégie :

• Confirmez quelle version PHP est utilisée par le gestionnaire web (FPM) et comparez‑la à ce que WordPress et les plugins supportent.
• Si vous devez rétrograder temporairement, faites‑le proprement (changez le socket FPM, rechargez le serveur web), pas en éditant des symlinks au hasard.
• À long terme : mettez à jour plugins/thèmes pour qu’ils soient compatibles ; ne figez pas PHP pour toujours. Vous finirez par gérer un musée accessible depuis Internet.

Voie E : Épuisement des ressources (mémoire, disque, CPU) provoquant des pannes en cascade

L’« erreur critique » WordPress peut être le symptôme visible d’un serveur déjà en train de mourir. Quand la machine manque d’espace disque ou de mémoire, écrire les fichiers de session échoue, les répertoires de cache ne peuvent pas être mis à jour, et les workers PHP plantent.

Réparez d’abord la plateforme : libérez de l’espace, faites pivoter les logs, corrigez les limites mémoire, ajoutez du swap si nécessaire (comme béquille à court terme), et réduisez le nombre de workers PHP‑FPM si la machine est en thrash.

Blague #2 : La seule chose qui grandit plus vite que les plugins WordPress, c’est le log de debug que vous avez oublié de faire pivoter.

Trois micro‑récits d’entreprise depuis le terrain

Micro‑récit 1 : La panne causée par une fausse hypothèse

Une entreprise de taille moyenne utilisait WordPress pour les pages marketing et une plateforme séparée pour le checkout. Quelqu’un a ajouté un plugin de performance qui « requérait WordPress 5.8+ » alors que le site était figé sur 5.6 pour compatibilité avec un ancien page builder. Personne n’a remarqué la ligne de requirement parce que le plugin s’est installé correctement et que l’environnement de staging était plus récent que la production.

Un lundi matin, les mises à jour automatiques ont lancé une version majeure du plugin. Le plugin a commencé à appeler une fonction core introduite après 5.6. Résultat : une erreur fatale immédiate sur chaque requête. Le monitoring uptime a hurlé, l’équipe marketing a crié plus fort, et l’équipe infra a été blâmée pour des « problèmes serveurs » parce que le site renvoyait HTTP 500.

La correction fut simple : désactiver le plugin par renommage de répertoire, restaurer le service, puis aligner les environnements. La leçon réelle était plus laide : le staging avait discrètement dérivé. Tout le monde supposait « staging = production », parce que ça fait pro. Ce n’était pas vrai.

Après l’incident, ils ont mis en place une garde ennuyeuse : un job nocturne qui compare la version core WordPress, la version PHP‑FPM et les versions des plugins actifs entre staging et production. La fois suivante qu’un plugin a requis un core plus récent, ils ont vu le décalage avant les utilisateurs.

Micro‑récit 2 : L’optimisation qui s’est retournée contre eux

Un grand site de communications interne était lent dans l’admin. Un ingénieur a activé un cache d’objets agressif et déplacé les sessions sur le système de fichiers pour « simplifier ». Ils ont aussi ajusté PHP‑FPM pour exécuter plus de workers, parce que le graphique CPU avait l’air « pas trop haut ». C’était le mouvement classique : optimiser la métrique que vous voyez et ignorer celle que vous ne mesurez pas.

En quelques jours, le serveur a commencé à montrer des erreurs critiques intermittentes. Pas constantes—pire. Les utilisateurs rafraîchissaient et parfois ça fonctionnait. Les logs montraient un mélange : « Allowed memory size exhausted », « failed to open stream », et des timeouts de base de données occasionnels. La réaction immédiate a été de blâmer WordPress, puis MySQL, puis le réseau, parce que ce sont des cibles émotionnellement satisfaisantes.

La cause racine : épuisement d’inodes et contention disque dû à une implémentation de cache qui écrivait des milliers de petits fichiers combinée à trop de workers PHP‑FPM menaçant le disque. Quand le système de fichiers ne pouvait pas créer de nouveaux fichiers de cache/session, les appels PHP échouaient à des endroits inattendus, et les plugins géraient mal ces échecs, menant à des fatales.

Ils ont annulé le cache basé sur fichiers, migré vers un service de cache en mémoire approprié, et réduit les workers PHP‑FPM pour correspondre à la capacité IO. Les performances se sont améliorées et les erreurs critiques « aléatoires » ont disparu. Morale : le goulet que vous ignorez choisira son propre moment pour vous instruire.

Micro‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers exécutait WordPress dans un environnement strictement contrôlé : pas de mises à jour automatiques en production, changements déployés via CI, et une fenêtre de maintenance hebdomadaire. Ce n’était pas sexy, mais c’était prévisible. Ils avaient aussi une procédure de restauration testée : pas « on a des backups », mais « on a restauré hier et ça a marché ».

Un soir, un éditeur a installé un plugin en staging pour prévisualiser une fonctionnalité. OK. Sauf que la routine de désinstallation du vendeur du plugin était buguée et a laissé un fichier de must‑use plugin dans wp-content/mu-plugins. Ce fichier a été inclus dans l’artefact de release et déployé en production pendant la fenêtre de maintenance.

Le site a immédiatement pris une erreur critique due à une dépendance manquante que le MU plugin supposait existante. L’ingénieur de garde a suivi le runbook : confirmer la fatale dans les logs, désactiver le MU plugin en déplaçant le fichier, recharger PHP‑FPM, vérifier les 200. Le service a été rétabli rapidement.

Puis la pratique ennuyeuse a compté : ils ont déployé une release corrigée et utilisé leurs outils de diff pour prouver exactement ce qui avait changé. Pas de mystère. Pas de « peut‑être c’était la base ». Le rapport d’incident fut court, factuel et utile—ce qui est le meilleur type.

Erreurs courantes : symptôme → cause racine → correction

Cette section existe parce que les gens répètent les mêmes erreurs, et j’aime ne pas répéter la même panne deux fois.

1) Symptom : « Erreur critique » seulement sur certaines pages

Cause racine : Un plugin déclenche une fatale seulement quand un shortcode, un template ou une route WooCommerce particulière se charge.

Correction : Tirez l’URL défaillante tout en suivant les logs. Désactivez le composant plugin/thème qui hooke cette route. Si c’est lié au contenu (shortcode), éditez le post dans la base ou via WP‑CLI pour retirer temporairement le shortcode.

2) Symptom : Site indisponible, wp-admin aussi indisponible, WP‑CLI échoue avec une fatale

Cause racine : Un must‑use plugin ou un fichier chargé très tôt provoque une fatale avant que WP ne puisse bootstrapper.

Correction : Vérifiez wp-content/mu-plugins. Déplacez les fichiers un par un. Vérifiez aussi advanced-cache.php et object-cache.php dans wp-content (drop‑in plugins).

3) Symptom : Vous avez activé WP_DEBUG et maintenant les visiteurs voient des erreurs brutes

Cause racine : WP_DEBUG_DISPLAY ou PHP display_errors est activé.

Correction : Définissez define('WP_DEBUG_DISPLAY', false); et assurez‑vous que la config PHP a display_errors=Off. Rechargez PHP‑FPM. Contrôlez avec une requête de test ; les erreurs doivent aller dans le log seulement.

4) Symptom : Vous avez « corrigé » le plugin mais l’erreur persiste

Cause racine : OPcache sert un ancien bytecode, ou vous avez édité le mauvais serveur (multi‑nœud, mauvais container, mauvais volume).

Correction : Rechargez/restart PHP‑FPM, confirmez le contenu du fichier sur l’hôte servant le trafic, et vérifiez les cibles du load balancer en amont. Ne faites pas confiance à votre prompt SSH ; vérifiez.

5) Symptom : Erreur critique après migration d’hébergement

Cause racine : Extensions PHP manquantes (mbstring, intl), permissions/ownership incorrects, ou version PHP incompatible.

Correction : Comparez la liste des modules et la version PHP ; corrigez l’ownership pour l’utilisateur web ; assurez‑vous que WordPress peut lire/écrire où il faut (wp-content/uploads, répertoires de cache).

6) Symptom : « Allowed memory size exhausted » dans les logs

Cause racine : Limite PHP trop basse, plugin incontrôlable, ou options autoload massives en base.

Correction : Augmentez la mémoire à un niveau raisonnable (256M est souvent raisonnable), puis profilez. Utilisez WP‑CLI pour inspecter les options autoload et réduire les coupables.

7) Symptom : debug.log grossit rapidement et remplit le disque

Cause racine : WP_DEBUG laissé activé ; plugin émettant des notices/warnings en boucle ; pas de logrotate.

Correction : Désactivez WP_DEBUG après capture. Ajoutez logrotate pour le chemin de log. Corrigez le code du plugin/thème qui spamme.

8) Symptom : L’erreur critique apparaît, puis disparaît, puis revient

Cause racine : Un nœud du cluster a un jeu de plugins différent, un système de fichiers différent, ou une version PHP différente.

Correction : Comparez les nœuds : répertoires de plugins, checksums, versions PHP‑FPM, volumes montés. Rendez les déploiements immuables et cohérents.

Listes de contrôle / plan étape par étape

Checklist de restauration immédiate (objectif : moins de 15 minutes)

1. Confirmez le code d’état et l’étendue : une URL, toutes les URL, l’admin aussi.
2. Suivez le log Nginx/Apache et le log PHP‑FPM pour le message fatal exact.
3. Si les logs sont silencieux : activez WP_DEBUG avec WP_DEBUG_LOG et WP_DEBUG_DISPLAY=false.
4. Identifiez si la fatale référence un chemin de plugin ou de thème.
5. Désactivez le plugin/thème suspect (WP‑CLI préféré ; renommez le répertoire/fichier si nécessaire).
6. Rechargez PHP‑FPM pour vider OPcache si le comportement ne correspond pas au système de fichiers.
7. Retestez : curl pour un 200, puis chargez la page d’accueil dans un navigateur, puis vérifiez quelques routes clés (login, checkout, formulaire de contact).
8. Capturez la trace de pile et notez le changement qui a déclenché l’incident.
9. Désactivez WP_DEBUG (ou au moins stoppez le logging verbeux) après avoir obtenu les preuves.

Checklist d’analyse racine et prévention de répétition (objectif : même jour)

1. Comparez les versions : core WordPress, PHP‑FPM, plugins actifs, thème.
2. Revoyez les changements récents : mises à jour automatiques, déploiements, changements de config, migrations d’hôte.
3. Reproduisez en staging avec des versions correspondantes.
4. Décidez de la stratégie : mettre à jour core/PHP, pinner les versions de plugin, ou remplacer le plugin.
5. Ajoutez une garde‑fou : désactivez les mises à jour automatiques pour les plugins risqués, ou n’autorisez les mises à jour qu via CI.
6. Implémentez la rotation des logs pour les debug logs WordPress et les logs web/PHP.
7. Ajoutez un test smoke : récupérer la page d’accueil + quelques routes clés après chaque déploiement.

Checklist minimale et sûre pour WP_DEBUG

• WP_DEBUG true uniquement pendant le diagnostic.
• WP_DEBUG_LOG vers un chemin protégé.
• WP_DEBUG_DISPLAY false.
• PHP display_errors off.
• Contrôles d’accès pour que les fichiers de log ne soient pas accessibles via le web.

Une citation opérationnelle à garder en poche

Idée paraphrasée (attribuée à W. Edwards Deming) : Sans données, vous n’êtes qu’une autre personne avec une opinion.

WP_DEBUG, utilisé correctement, est la façon de transformer une panne d’« opinions » en « voici la ligne exacte qui a cassé ».

FAQ

1) Pourquoi WordPress affiche « There has been a critical error » au lieu de l’erreur réelle ?

Parce qu’afficher des erreurs PHP brutes aux utilisateurs est un risque de sécurité et de confidentialité. WordPress cache les détails et s’attend à ce que vous consultiez les logs côté serveur ou activiez un debug sûr.

2) Activer WP_DEBUG va‑t‑il ralentir mon site ?

Oui potentiellement. Ça augmente le logging et met en évidence des notices que certains plugins déclenchent constamment. Utilisez‑le brièvement, loggez vers un fichier, puis désactivez. Pour une observabilité durable, utilisez du logging structuré et du monitoring approprié.

3) Est‑ce que wp-content/debug.log est sûr ?

Parfois. Cela dépend des règles de votre serveur web. Si votre serveur peut servir des fichiers depuis wp-content directement (courant), vous risquez d’exposer le log. Un chemin protégé comme /var/log/wordpress est plus sûr.

4) Je ne peux pas accéder à wp‑admin. Comment désactiver des plugins ?

Utilisez WP‑CLI si il démarre. Sinon renommez le répertoire du plugin sous wp-content/plugins ou déplacez le fichier du plugin hors de mu-plugins. WordPress ignorera ce qu’il ne trouve pas.

5) Et si désactiver tous les plugins ne résout rien ?

Regardez alors le thème, les MU plugins et les drop‑ins (object-cache.php, advanced-cache.php). Si aucun ne bloque, vérifiez les checksums du core et examinez la version/modules PHP et la santé du système de fichiers (disque/inodes).

6) Comment savoir si c’est un problème de mémoire PHP ?

Vos logs indiqueront « Allowed memory size exhausted ». Ne devinez pas. Confirmez la limite mémoire via WP‑CLI ou phpinfo (de façon sûre), augmentez‑la modérément, puis traquez le plugin/thème cause du pic.

7) Pourquoi l’erreur n’arrive‑t‑elle que parfois ?

Les défaillances intermittentes signifient généralement qu’un nœud du cluster diffère, ou que l’épuisement des ressources est périodique (cron, backups, rebuilds de cache), ou que OPcache sert du code obsolète sur certains workers.

8) Dois‑je restaurer depuis une sauvegarde immédiatement ?

Si vous ne pouvez pas identifier rapidement le composant en échec et que l’impact business est élevé, oui—la restauration est une réponse d’incident valide. Mais capturez d’abord les logs, sinon vous répéterez la panne au prochain update.

9) Puis‑je « corriger » cela en réinstallant WordPress ?

Vous pouvez réinstaller le core en toute sécurité, mais cela règle rarement les bugs de compatibilité plugin/thème. Réinstaller tout est souvent une manière dramatique d’éviter de lire la trace de pile.

10) Comment prévenir cette catégorie de panne ?

Arrêtez de considérer la production comme votre environnement d’intégration : pinner les versions, tester les mises à jour en staging qui correspond à la production, déployer via CI, et garder une procédure de rollback/restore que vous avez réellement exercée.

Conclusion : prochaines étapes pour éviter les récurrences

« There has been a critical error » est WordPress qui vous dit : « PHP est mort, allez lire les reçus. » Votre chemin le plus rapide est cohérent : vérifiez les logs serveur, activez le logging WP_DEBUG en sécurité si nécessaire, isolez le plugin/thème en faute, restaurez le service, puis corrigez le décalage de versions ou le bug de façon contrôlée.

Faites ces actions ensuite :

• Désactivez WP_DEBUG si vous l’avez activé, ou au moins arrêtez le logging verbeux une fois que vous avez la trace de pile.
• Notez le déclencheur : quelle mise à jour, quel déploiement, quel changement de config.
• Faites correspondre staging et production (versions, handler PHP, plugins). La dérive est la cause des débogages fictifs.
• Ajoutez un test smoke automatisé après les mises à jour : page d’accueil + login + une route métier clé. Peu coûteux, efficace.
• Pivotez les logs et surveillez disque/inodes. Les pannes causées par disque plein ne sont pas « mystérieuses », juste embarrassantes.

Si vous ne faites rien d’autre, faites ceci : traitez les mises à jour WordPress comme des releases logicielles, pas comme du bruit de fond. La production a déjà assez de surprises.