Erreur critique sur WordPress : que faire, étape par étape

Si votre site affiche « Une erreur critique est survenue sur ce site », la cause est presque toujours une extension, un thème ou une version de PHP incompatible. La bonne nouvelle, c’est que rien n’est perdu : vos contenus sont intacts dans la base de données. La mauvaise, c’est qu’il faut identifier le coupable, et que le site reste hors ligne en attendant.

Voici la marche à suivre, dans l’ordre. Elle fonctionne dans la grande majorité des cas, sans compétence technique particulière.

Avant tout : ne touchez à rien

Le premier réflexe, quand un site tombe, c’est de cliquer partout. C’est exactement ce qu’il ne faut pas faire.

N’installez surtout pas une extension de réparation ou de nettoyage. Neuf fois sur dix, elle aggrave la situation en modifiant des fichiers déjà instables, et elle brouille les traces qui permettaient d’identifier la panne. J’ai passé plus de temps à réparer des tentatives de réparation qu’à réparer des pannes.

Ne réinstallez pas WordPress par-dessus. Ne supprimez pas de fichiers au hasard. Et si votre hébergeur vous propose de restaurer une sauvegarde, gardez cette option pour plus tard : vous perdriez les contenus publiés depuis, et vous ne sauriez toujours pas d’où vient le problème.

Cherchez l’e-mail envoyé par WordPress

Depuis la version 5.2, WordPress envoie automatiquement un e-mail à l’adresse d’administration quand une erreur fatale survient. Cet e-mail est le raccourci le plus utile de toute la procédure, et presque personne ne le lit.

Il contient deux choses précieuses. D’abord le nom du fichier et de l’extension à l’origine du plantage, souvent en toutes lettres. Ensuite un lien vers le « mode de récupération », qui vous permet d’accéder à l’administration même quand le site est cassé, avec l’extension fautive automatiquement désactivée.

Regardez dans la boîte de réception de l’adresse déclarée dans Réglages, y compris les indésirables. Si vous ne savez plus quelle adresse c’est, passez à l’étape suivante.

Activez l’affichage des erreurs

Sans l’e-mail, il faut faire parler le site. Connectez-vous à votre hébergement, par le gestionnaire de fichiers ou en FTP, et ouvrez le fichier wp-config.php situé à la racine.

Cherchez la ligne contenant WP_DEBUG et remplacez-la par :

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

Rechargez votre site, puis ouvrez le fichier wp-content/debug.log qui vient d’apparaître. Les dernières lignes désignent le fichier fautif, avec son chemin complet. Un chemin du type wp-content/plugins/nom-extension/ vous donne le nom de l’extension responsable.

Pensez à remettre WP_DEBUG sur false une fois la panne réglée. Laisser le mode débogage actif en production expose des informations sur votre installation.

Désactivez les extensions par les fichiers

Vous savez maintenant quelle extension pose problème, ou vous avez au moins un soupçon. Comme vous n’avez pas accès à l’administration, il faut la désactiver autrement.

Dans le gestionnaire de fichiers, allez dans wp-content/plugins/ et renommez le dossier de l’extension suspecte, par exemple woocommerce en woocommerce-off. WordPress ne la trouve plus, il la désactive tout seul, et le site revient.

Si vous n’avez aucune piste, renommez le dossier plugins entier en plugins-off. Toutes les extensions se désactivent d’un coup. Si le site revient, vous savez que le problème vient de l’une d’elles : recréez un dossier plugins, remettez les extensions une par une, et rechargez le site après chacune. Celle qui fait replanter est la vôtre.

C’est fastidieux, mais c’est la méthode la plus fiable, et c’est celle que j’applique moi-même quand les journaux d’erreurs ne sont pas clairs.

Testez le thème

Si la désactivation de toutes les extensions ne change rien, le thème est le suspect suivant. Même principe : renommez son dossier dans wp-content/themes/. WordPress bascule automatiquement sur un thème par défaut.

Votre site sera hideux pendant quelques minutes, mais s’il s’affiche, vous avez trouvé. Le plus souvent, il s’agit d’un thème qui n’a pas été mis à jour depuis longtemps et qui utilise une fonction supprimée dans une version récente de PHP.

Vérifiez la version de PHP

C’est la cause que je vois le plus souvent chez les hébergeurs qui mettent à jour automatiquement. Votre hébergeur passe le serveur de PHP 7.4 à PHP 8.2 pendant la nuit, et une extension ancienne ne suit pas.

Dans le panneau de votre hébergement, cherchez « Version PHP » ou « Configuration PHP ». Si vous constatez un changement récent, revenez à la version précédente : le site redevient accessible immédiatement.

Attention, c’est un dépannage, pas une solution. Les anciennes versions de PHP ne reçoivent plus de correctifs de sécurité. Il faut mettre à jour ou remplacer l’extension incompatible, puis repasser à la version récente.

Augmentez la mémoire allouée

Une erreur du type Allowed memory size exhausted dans le journal signale un manque de mémoire, pas un bug. Ajoutez cette ligne dans wp-config.php, avant la ligne « happy blogging » :

define( 'WP_MEMORY_LIMIT', '512M' );

Si le site repart, notez que c’est un symptôme. Un site vitrine qui a besoin de 512 Mo a généralement trop d’extensions, ou l’une d’elles fait quelque chose d’anormal.

Quand appeler quelqu’un

Arrêtez-vous et faites appel à un professionnel dans trois situations.

Si le journal d’erreurs pointe vers un fichier du cœur de WordPress plutôt que vers une extension, il peut s’agir d’une corruption de fichiers ou d’une intrusion. Si le site affiche des redirections étranges ou des pages inconnues en plus de l’erreur, c’est très probablement un piratage et la marche à suivre est complètement différente. Et si vous n’avez pas de sauvegarde récente, mieux vaut ne pas expérimenter : chaque manipulation supplémentaire réduit les chances de récupération propre.

Dans tous les cas, si le site est votre outil de travail et qu’il est à l’arrêt depuis plus de deux heures, le calcul est vite fait. Une intervention de dépannage en urgence coûte moins cher qu’une journée sans site.

Le mode de récupération, en détail

Ce mode mérite quelques lignes de plus, parce qu’il évite la moitié des manipulations décrites plus haut et que presque personne ne sait qu’il existe.

Quand WordPress détecte une erreur fatale provoquée par une extension, il met automatiquement celle-ci en pause et vous envoie un lien de récupération valable 24 heures. Ce lien vous connecte à l’administration dans un mode particulier : le site public reste cassé pour les visiteurs, mais vous, vous voyez le tableau de bord normalement.

Une bannière vous indique alors quelle extension a été mise en pause. Vous pouvez la désactiver proprement, la mettre à jour, ou la supprimer, puis quitter le mode de récupération. Aucun accès FTP, aucun fichier à renommer.

Deux conditions pour que ça marche. L’adresse e-mail d’administration doit être valide et relevée : vérifiez-la dès aujourd’hui dans Réglages, section Général. Et l’envoi d’e-mails doit fonctionner sur votre hébergement, ce qui n’est pas toujours le cas par défaut. Une extension d’envoi SMTP correctement configurée règle ce second point, et rend service bien au-delà de cette situation.

Si vous gérez un site professionnel, prenez cinq minutes pour vérifier ces deux réglages. Le jour où le site tombera, vous gagnerez une heure.

Éviter que ça recommence

Une erreur critique n’arrive presque jamais par hasard. Elle arrive parce qu’une mise à jour a été appliquée sans test, ou parce que le site n’a pas été touché depuis deux ans et qu’un décalage s’est creusé.

Deux habitudes suffisent à faire disparaître le problème. Sauvegarder avant chaque mise à jour, fichiers et base de données, sur un support distinct du serveur. Et tester les mises à jour sur une copie du site avant de les appliquer en ligne.

C’est exactement ce que couvre un contrat de maintenance, et c’est aussi ce que vous pouvez faire vous-même si vous êtes rigoureux. L’important, c’est que quelqu’un le fasse.