asset 1
asset 2
asset 3
asset 2
asset 21

Comment activer WP_DEBUG pour diagnostiquer une erreur WordPress

6 mars 2026

Une page blanche. Une erreur 500. Un mes­sage indi­quant qu’une erreur cri­tique est sur­ve­nue sur le site. Si vous gérez votre site sans être déve­lop­peur, ces situa­tions peuvent être désta­bi­li­santes. On ne sait pas vrai­ment ce qui se passe, ni quoi dire pré­ci­sé­ment au sup­port technique.

Word­Press pro­pose pour­tant un outil simple pour obte­nir des infor­ma­tions concrètes : le mode débo­gage, acti­vé via WP_DEBUG.

Le but de cet article n’est pas de faire de vous un expert du code ou du débo­gage avan­cé. Il s’agit plu­tôt de vous mon­trer com­ment récu­pé­rer des infor­ma­tions utiles : savoir quel fichier est en cause, quelle exten­sion semble poser pro­blème, à quel moment l’erreur se produit.

Dans cet article, vous allez voir :

  • ce qu’est WP_DEBUG ;
  • com­ment l’activer correctement ;
  • où trou­ver le fichier d’erreurs ;
  • com­ment lire les infor­ma­tions essen­tielles sans entrer dans la tech­nique complexe.

L’objectif est simple : mieux com­prendre ce qui se passe et trans­mettre des élé­ments clairs à la per­sonne qui vous accompagne.

Qu’est-ce que WP_DEBUG ?

WP_DEBUG est une constante de confi­gu­ra­tion de Word­Press.
Concrè­te­ment, c’est un para­mètre que l’on active dans le fichier wp-config.php pour deman­der à Word­Press d’enregistrer les erreurs tech­niques qui se produisent.

Par défaut, ce mode est désac­ti­vé.
C’est nor­mal : sur un site public, visible par tout le monde, on ne doit pas affi­cher d’informations tech­niques aux visiteurs.

Lorsque WP_DEBUG est acti­vé, Word­Press peut :

  • signa­ler des erreurs PHP ;
  • enre­gis­trer des avertissements ;
  • indi­quer si une exten­sion ou un thème déclenche un problème ;
  • consi­gner ces infor­ma­tions dans un fichier de jour­na­li­sa­tion nom­mé debug.log.

Ces mes­sages per­mettent d’identifier plus pré­ci­sé­ment l’origine d’un pro­blème : exten­sion défaillante, incom­pa­ti­bi­li­té après une mise à jour, erreur dans un thème, etc.

➔ WP_DEBUG ne répare pas le site. Il aide sim­ple­ment à com­prendre ce qui se passe en arrière-plan.

Comment activer WP_DEBUG dans wp-config.php ?

L’activation de WP_DEBUG se fait dans un seul fichier : wp-config.php.

le fichier wp-config.php est situé à la racine de votre installation wordpress
Empla­ce­ment du fichier wp-config.php

Ce fichier se trouve à la racine de votre ins­tal­la­tion Word­Press, au même niveau que les dos­siers wp-admin, wp-content et wp-includes.

➔ Si vous n’êtes pas à l’aise avec la modi­fi­ca­tion de ce fichier, vous pou­vez consul­ter notre guide détaillé : Confi­gu­rer le fichier wp-config.php sous Word­Press.

1. Ouvrir le fichier wp-config.php

Vous pou­vez accé­der à ce fichier :

  • via le ges­tion­naire de fichiers de votre hébergement ;
  • ou avec un logi­ciel FTP.

Ouvrez ensuite le fichier wp-config.php dans un édi­teur de texte.

2. Modifier la configuration de débogage

Dans la plu­part des cas, vous trou­ve­rez déjà cette ligne dans le fichier :

define( 'WP_DEBUG', false );

Rem­pla­cez-la par le bloc suivant :

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

Si la ligne WP_DEBUG n’existe pas dans votre fichier, ajou­tez sim­ple­ment ce bloc, vers la fin du fichier, juste avant la ligne :

/* That's all, stop editing! Happy publishing. */

3. Que signifient ces lignes ?

  • WP_DEBUG active le mode débogage ;
  • WP_DEBUG_LOG enre­gistre les erreurs dans un fichier ;
  • WP_DEBUG_DISPLAY empêche l’affichage des erreurs à l’écran.

Ain­si, les erreurs seront enre­gis­trées pour ana­lyse, sans être visibles par les visiteurs.

Enre­gis­trez le fichier, puis rechar­gez la page qui posait pro­blème. Si une erreur se pro­duit, elle sera pro­ba­ble­ment consi­gnée dans le fichier debug.log.
Il est pos­sible qu’aucun mes­sage n’apparaisse : mal­heu­reu­se­ment, cer­tains pro­blèmes ne génèrent pas d’erreurs exploi­tables par WP_DEBUG.

Où trouver le fichier debug.log ?

Lorsque WP_DEBUG_LOG est acti­vé, Word­Press enre­gistre les erreurs dans un fichier nom­mé debug.log. Ce fichier se trouve dans le dos­sier : /wp-content/debug.log

Comment y accéder ?

Vous pou­vez ouvrir ce fichier :

  • via le ges­tion­naire de fichiers de votre hébergement ;
  • ou avec votre client FTP.

Dans le ges­tion­naire de fichiers de votre héber­ge­ment, il suf­fit géné­ra­le­ment de :

  1. Ouvrir le dos­sier wp-content ;
  2. Recher­cher le fichier debug.log ;
  3. L’ouvrir ou le télé­char­ger pour le consulter.

➔ Impor­tant : le fichier debug.log n’apparaît que lorsqu’une erreur a été enre­gis­trée. S’il n’existe pas, cela signi­fie qu’aucune erreur n’a encore été consignée.

Comment lire et comprendre une erreur WordPress ?

Ouvrir le fichier debug.log peut impres­sion­ner au pre­mier regard. Pour­tant, il suf­fit sou­vent d’identifier quelques élé­ments simples. 

Chaque entrée indique :

  • la date et l’heure ;
  • le type d’erreur (Fatal error, War­ning, Notice) ;
  • le fichier concerné ;
  • la ligne pré­cise du code.

Vous n’avez pas besoin de com­prendre le code. Il suf­fit sou­vent d’identifier :

  • le type d’erreur ;
  • le nom de l’extension ou du thème mentionné ;
  • le moment où elle s’est produite.

Ces infor­ma­tions sont lar­ge­ment suf­fi­santes pour :

  • désac­ti­ver tem­po­rai­re­ment une exten­sion récente ;
  • signa­ler pré­ci­sé­ment le pro­blème au support ;
  • com­prendre si une mise à jour est en cause.

Trois exemples courants d’erreurs

Exemple 1 : Notice (message non bloquant)

[04-Mar-2026 09:01:11 UTC] PHP Notice:  Function _load_textdomain_just_in_time was called incorrectly.

Dans ce cas :

  • PHP Notice indique un mes­sage informatif ;
  • le site fonc­tionne géné­ra­le­ment normalement ;
  • il s’agit sou­vent d’un appel fait trop tôt dans le char­ge­ment de Word­Press (sou­vent lié à une exten­sion ou un thème).

Ce type de mes­sage n’empêche pas le site de fonc­tion­ner, mais il signale une mau­vaise pra­tique ou une incompatibilité.

Exemple 2 : Warning (avertissement)

[04-Mar-2026 09:05:42 UTC] PHP Warning:  Undefined array key "id" in /wp-content/plugins/mon-extension/fichier.php on line 87

Dans ce cas :

  • PHP War­ning indique un pro­blème plus sérieux qu’une notice ;
  • le site peut fonc­tion­ner, mais cer­taines fonc­tion­na­li­tés peuvent être instables ;
  • le che­min per­met d’identifier l’extension concernée.

Exemple 3 : Fatal error (erreur bloquante)

[04-Mar-2026 09:12:03 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function my_custom_function() in /wp-content/themes/mon-theme/functions.php:42

Ici :

  • PHP Fatal error est une erreur bloquante ;
  • le site peut affi­cher une page blanche ou un mes­sage d’erreur critique ;
  • le fichier et la ligne indi­qués per­mettent d’identifier pré­ci­sé­ment l’origine.

Désactiver WP_DEBUG après diagnostic

Le mode débo­gage est un outil ponc­tuel. Il ne doit pas res­ter acti­vé en per­ma­nence sur un site public. Une fois votre diag­nos­tic effectué :

1. Ouvrez à nouveau le fichier wp-config.php

Accédez‑y via le ges­tion­naire de fichiers du cPa­nel ou votre client FTP.

2. Désactivez le mode débogage

Si vous avez uti­li­sé le bloc recom­man­dé pré­cé­dem­ment, rem­pla­cez-le par :

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

Enre­gis­trez le fichier.

3. Supprimez le fichier debug.log

Le fichier debug.log peut conte­nir des infor­ma­tions tech­niques détaillées. Il est pré­fé­rable de le sup­pri­mer une fois votre diag­nos­tic ter­mi­né. Pour cela :

  1. Ren­dez-vous dans le dos­sier wp-content ;
  2. Sup­pri­mez le fichier debug.log.

À retenir

WP_DEBUG ne cor­rige pas les erreurs. Il per­met de com­prendre leur ori­gine. Uti­li­sé ponc­tuel­le­ment, puis désac­ti­vé cor­rec­te­ment, c’est un outil simple et effi­cace pour mieux dia­lo­guer avec le sup­port tech­nique ou votre prestataire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *