Bug WordPress en urgence : que faire avant d'appeler un expert

Le site tombe un vendredi soir, ou pire, en pleine campagne. Réponse directe : avant d'appeler qui que ce soit, une panne WordPress se trie en cinq minutes en trois familles — erreur qui bloque tout le site (écran blanc, « erreur critique », 500), wp-admin inaccessible alors que le site public répond, ou comportement anormal (redirections, contenu spam, fichiers inconnus) qui sent la compromission. Chaque famille a son premier réflexe, et surtout ses gestes à ne pas faire — c'est souvent le bricolage mal ordonné, pas la panne elle-même, qui transforme 20 minutes de diagnostic en une soirée perdue.

Quel type de panne est-ce, en fait ?

Avant tout diagnostic technique, une seule question tranche l'urgence réelle : le site répond-il encore aux visiteurs, ou pas du tout ? Un blocage total (page blanche, erreur 500, panier qui ne se valide plus) coûte du chiffre d'affaires à chaque minute. Un dysfonctionnement partiel (une page lente, un formulaire capricieux) peut attendre un créneau normal. Cette distinction détermine tout ce qui suit : elle décide si vous avez le temps de lire un log tranquillement ou si vous devez couper au plus vite vers une prise en charge accélérée.

Comment rendre l'erreur visible avant de toucher à quoi que ce soit ?

Depuis WordPress 5.2, l'écran blanc classique a largement cédé la place à un message plus parlant : *« Il y a eu une erreur critique sur ce site. »* WordPress intercepte la plupart des erreurs fatales et peut même envoyer un e-mail avec un lien de connexion à usage unique en « mode de récupération », utile quand wp-admin lui-même refuse de charger. Mais ce message reste vague pour diagnostiquer. La vraie première étape est d'activer le journal d'erreurs : ouvrez wp-config.php et ajoutez ces trois lignes juste avant /* That's all, stop editing! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Rechargez la page en panne, puis ouvrez wp-content/debug.log (par FTP, ou tail -n 50 wp-content/debug.log en SSH). La dernière ligne nomme presque toujours le fichier et la ligne exacts du plantage, par exemple :

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /var/www/wp-content/plugins/mon-plugin/class-importer.php on line 118

Vous venez de transformer un mystère en une adresse précise. WP_DEBUG_DISPLAY reste à false pour ne rien afficher publiquement, et WP_DEBUG se désactive une fois le diagnostic terminé — le laisser actif en production expose des chemins serveur.

Si debug.log reste vide alors que le site est bien cassé, l'erreur survient avant que PHP n'ait fini de charger WordPress, souvent dans wp-config.php. Si le 500 apparaît immédiatement, le suspect change de nature : voir plus bas.

Quelles sont les causes les plus fréquentes d'un site WordPress qui tombe ?

Sur les sites que nous dépannons, une poignée de causes reviennent dans l'écrasante majorité des cas :

Un point technique qui change la démarche : une erreur 500 déclenchée par un .htaccess corrompu se produit avant même que PHP ne s'exécute — Apache refuse la requête à cause d'une directive mod_rewrite invalide, donc WP_DEBUG_LOG ne verra jamais rien. Le test : renommez .htaccess en .htaccess.bak et rechargez. Si le site répond, régénérez-le depuis *Réglages → Permaliens → Enregistrer*, ou recollez le bloc par défaut :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Le message « Error establishing a database connection » suit une autre logique — identifiants changés, serveur MySQL saturé, table corrompue — détaillée dans notre article dédié : « Error establishing a database connection » : que faire vraiment.

Quelles vérifications pouvez-vous faire sans risque avant d'appeler un expert ?

Le réflexe destructeur, c'est de tout désactiver d'un coup depuis phpMyAdmin : vous perdez l'information sur *quelle* extension est en cause, et vous risquez d'emporter des réglages avec elle. À la place, isolez un élément à la fois :

# Lister les extensions actives (utile même si wp-admin est bloqué)
wp plugin list --status=active

# Désactiver le suspect désigné par debug.log, un seul à la fois
wp plugin deactivate mon-plugin

Sans accès SSH, le même geste se fait par FTP : renommez le dossier de l'extension suspecte (mon-plugin → mon-plugin_off). WordPress la désactive automatiquement au rechargement, sans passer par l'admin. Même logique pour le thème actif si le plugin n'y est pour rien.

Ce que vous pouvez vérifier sans aucun risque, dans l'ordre : l'hébergeur signale-t-il un incident (page de statut) ; le problème touche-t-il un seul appareil ou tout le monde en navigation privée ; la version PHP vient-elle de changer (notifications, panneau d'hébergement) ; debug.log contient-il une ligne Fatal error récente. Rien de tout ça ne modifie le site — ça éclaire seulement la suite.

Qu'est-ce qu'il ne faut surtout pas toucher ?

Trois gestes aggravent presque toujours la situation plutôt que de la résoudre :

• Modifier des fichiers dans wp-includes/ à la main. Si debug.log pointe là, ce n'est presque jamais un fichier à corriger — c'est le signal d'un cœur corrompu ou d'un piratage. On compare, on ne rafistole pas : wp core verify-checksums liste les fichiers altérés par rapport à la version officielle.
• Restaurer une sauvegarde en tout premier réflexe. Ça efface souvent la preuve utile au diagnostic, alors que la cause est parfois un simple plugin à renommer. Réservez la restauration au cas où le diagnostic échoue ou où une compromission est confirmée.
• Nettoyer seul des signes de piratage (fichiers PHP inconnus dans uploads/, comptes admin non créés par vous, redirections inconnues). Sauvegardez l'état actuel — même infecté, il sert au diagnostic — sans mesurer l'ampleur d'abord. Sujet à part entière : voir Site WordPress piraté : reprendre le contrôle sans tout perdre.

Checklist avant d'appeler un expert

• [ ] WP_DEBUG_LOG activé, wp-content/debug.log lu (fichier + ligne exacts du plantage, ou constat qu'il est vide)
• [ ] Statut de l'hébergeur vérifié (incident en cours ?)
• [ ] Plugin ou thème suspect isolé par renommage — un seul à la fois
• [ ] .htaccess testé si le 500 est immédiat et debug.log vide
• [ ] Aucun fichier cœur (wp-includes/) modifié à la main
• [ ] Aucune sauvegarde restaurée avant d'avoir compris la cause
• [ ] Capture d'écran ou copie exacte du message d'erreur conservée
• [ ] WP_DEBUG remis à false une fois le constat fait

Quand faut-il arrêter de bricoler et passer en urgence ?

Un arbre de décision simple, dans l'ordre où on le parcourt réellement en intervention :

1. debug.log pointe vers wp-includes/ ? → Stop, terrain de piratage potentiel, ne modifiez rien.
2. Fichiers .php inconnus dans uploads/, comptes admin non créés par vous, redirections inconnues ? → Stop, compromission suspectée, isolez sans nettoyer seul.
3. Checkout cassé, ou wp-admin inaccessible avec activité bloquée ? → Chaque minute a un coût direct, c'est le moment de passer en urgence plutôt que de continuer à tester.
4. Plugin ou thème isolé, site revenu, correctif définitif juste en attente d'un créneau ? → Pas d'urgence, planifiez normalement.
5. Plus de 30 à 45 minutes sans progrès net ? → Signal qu'il manque un œil habitué à ce type de panne, pas un problème de persévérance.

Dans les cas 1 à 3, HelpApp Pro propose une mobilisation accélérée — un supplément urgence peut s'appliquer selon le créneau, au tarif affiché sur notre page tarifs.

Questions fréquentes

Combien de temps faut-il pour diagnostiquer un bug WordPress critique ?

Avec debug.log lisible, la cause se repère en général en 15 à 30 minutes. Sans accès direct (hébergement fermé, support à contacter), le délai dépend de la réactivité de l'hébergeur, pas de la complexité technique.

Faut-il restaurer une sauvegarde en premier réflexe ?

Non. La lecture du log et l'isolement d'un plugin prennent quelques minutes et évitent de perdre du contenu récent. Réservez la restauration au cas où le diagnostic échoue ou où une compromission est confirmée.

Comment distinguer un bug ordinaire d'un piratage ?

Un bug ordinaire pointe vers une cause technique cohérente (un plugin, une page). Une compromission se signale par ce que rien n'explique dans votre activité normale : fichiers .php inconnus dans uploads/, comptes administrateurs jamais créés par vous, redirections vers des sites tiers.

WP_DEBUG doit-il rester activé en permanence ?

Non. Il s'active pour diagnostiquer, avec WP_DEBUG_DISPLAY à false, puis se désactive une fois la cause identifiée — le laisser en continu expose des chemins serveur dans les logs sans bénéfice.

Quand faire appel à HelpApp Pro

Trois signaux disent qu'il faut passer la main plutôt que continuer seul : l'erreur pointe vers le cœur de WordPress, une compromission est suspectée, ou le checkout est cassé pendant que chaque heure coûte des ventes. HelpApp Pro reprend ces pannes sans vendre une refonte quand un correctif ciblé suffit : lecture du debug.log avec vous, isolement de la cause réelle, vérification que rien d'autre n'a cassé au passage. Décrivez le blocage via le devis en ligne, ou consultez directement notre page bugs WordPress, Drupal, Prestashop si le site est déjà à l'arrêt.