Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

« Erreur critique » sur votre site WordPress

Le message « Une erreur critique s’est produite sur ce site » ne donne aucun détail par défaut : c’est volontaire, WordPress masque l’erreur réelle pour ne pas exposer d’informations sensibles. Il faut aller la chercher dans les logs pour savoir quoi corriger.

Décrire mon problème Discuter sur WhatsApp

Comment je procède

  1. Activation du débogage

    Je passe WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php pour faire apparaître l’erreur réelle dans wp-content/debug.log au lieu du message générique.

  2. Lecture de l’erreur PHP

    Je lis la trace complète : fichier, ligne, fonction en cause. La plupart du temps, c’est une fonction dépréciée ou un fichier manquant dans un plugin ou le thème.

  3. Isolation par renommage

    Je renomme le dossier du plugin suspect (ou tout wp-content/plugins) pour désactiver sans passer par l’interface d’administration, souvent inaccessible dans ce cas.

  4. Vérification de compatibilité

    Je vérifie la version de PHP du serveur : beaucoup d’erreurs critiques apparaissent après une montée de version PHP automatique chez l’hébergeur, incompatible avec un vieux plugin.

  5. Correction et remise en ligne

    Je corrige, mets à jour ou remplace l’élément fautif, je vide les caches actifs (plugin de cache, cache serveur) et je repasse WP_DEBUG sur false.

Ce que je traite régulièrement

  • Message « Une erreur critique s’est produite sur ce site WordPress »
  • Écran blanc total, site public ou administration
  • Erreur apparue juste après une mise à jour automatique de plugin ou de WordPress
  • Site fonctionnel puis cassé sans action apparente, souvent après une mise à jour PHP silencieuse de l’hébergeur
  • Impossible d’accéder à wp-admin pour désactiver le plugin en cause

Les causes les plus fréquentes

Sur un site WordPress, l’erreur critique vient dans l’immense majorité des cas d’un conflit entre plugins, ou d’une incompatibilité entre un plugin/thème et la version de PHP du serveur. Une fonction appelée par un vieux plugin peut avoir été supprimée dans une version récente de PHP, ce qui provoque une erreur fatale immédiate.

Le deuxième cas fréquent est une mise à jour interrompue : coupure réseau ou timeout pendant une mise à jour automatique de plugin, laissant des fichiers à moitié écrits. WordPress détecte parfois ce cas et active un mode maintenance qui reste bloqué (fichier .maintenance à la racine).

Enfin, un dépassement de la limite mémoire PHP (WP_MEMORY_LIMIT) peut aussi provoquer ce type d’erreur, en particulier sur des sites avec beaucoup de plugins actifs simultanément ou des imports de données volumineux.

wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Pages liées

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle est l’ampleur du problème ?
Quel type de message s’affiche ?
Qu’est-ce qui a changé juste avant ?

Neuf fois sur dix, une extension ou un thème récemment mis à jour est en cause.

WP_DEBUG est-il activé dans wp-config.php ? (facultatif)

Cette option révèle le fichier et la ligne exacts en cause, au lieu du message générique affiché aux visiteurs.

De quels accès disposez-vous ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Est-ce que je risque de perdre mes articles ou mes commandes ?
Non. L’erreur critique empêche l’affichage des pages, elle n’altère pas la base de données. Vos contenus, commandes et clients restent intacts.
Pourquoi je n’avais rien touché et le site s’est cassé tout seul ?
C’est fréquent : une mise à jour automatique de plugin, ou une montée de version PHP décidée par l’hébergeur sans prévenir, suffit à casser un site resté stable depuis des mois.
Quels accès dois-je vous fournir ?
Un accès FTP ou SSH pour lire les fichiers et les logs, et un accès à la base de données. Si wp-admin est accessible, ses identifiants aident aussi mais ne sont pas indispensables.
Combien de temps pour remettre le site en ligne ?
Dans la majorité des cas, l’identification du plugin ou du fichier fautif se fait en moins d’une heure une fois les accès obtenus. La correction elle-même dépend de ce qui est cassé.
Comment éviter que ça se reproduise ?
Je peux limiter les mises à jour automatiques de plugins sensibles et mettre en place un environnement de test pour valider les mises à jour avant de les appliquer en production.