Comment créer et accéder aux journaux d’erreurs pour WordPress (3 méthodes)

Les journaux d’erreurs WordPress sont des enregistrements de diagnostic qui capturent les erreurs PHP, les exceptions fatales, les échecs de base de données, les conflits de plugins et les incompatibilités de thèmes au fur et à mesure qu’ils se produisent sur votre serveur. Accéder à ces journaux et les interpréter est le moyen le plus rapide d’identifier la cause principale d’une page défectueuse, d’un écran blanc de la mort ou d’une régression de performance silencieuse — sans avoir à deviner ou à désactiver les plugins un par un.

Ce guide couvre trois méthodes éprouvées en production pour activer, localiser et lire les journaux d’erreurs WordPress : la pile native WP_DEBUG, les journaux au niveau du serveur via votre panneau de contrôle d’hébergement, et les visionneuses de journaux basées sur des plugins. Chaque méthode convient à un niveau d’accès et à un cas d’utilisation différents, et toutes trois sont expliquées avec des chemins de fichiers exacts, une syntaxe de configuration et des considérations de sécurité.

Pourquoi les journaux d’erreurs WordPress sont importants

WordPress fonctionne sur PHP, qui génère plusieurs classes de messages d’exécution : les erreurs fatales (l’exécution s’arrête), les avertissements (l’exécution continue mais quelque chose ne va pas), les notices (informatives, indiquant souvent du code déprécié) et les messages dépréciés (fonctions programmées pour être supprimées). Par défaut, aucun de ces messages n’est écrit dans un journal persistant sur la plupart des configurations de production — ils sont soit supprimés, soit affichés dans le navigateur, ce qui constitue un risque de sécurité.

Sans journal, une mise à jour de plugin qui introduit une erreur fatale ne produit qu’un écran blanc. Une bibliothèque SMTP mal configurée supprime silencieusement les e-mails. Un dépassement de limite mémoire interrompt le chargement d’une page sans laisser de trace visible. Les journaux d’erreurs convertissent ces échecs invisibles en entrées horodatées, référencées par fichier et numérotées par ligne sur lesquelles vous pouvez agir immédiatement.

Méthode 1 : Activer le mode débogage WordPress via wp-config.php

WordPress est livré avec un sous-système de débogage intégré contrôlé par un ensemble de constantes PHP définies dans wp-config.php. C’est la méthode la plus précise car elle capture les erreurs spécifiques à WordPress, y compris celles générées par l’API des plugins, le chargeur de thèmes et la couche d’abstraction de base de données (wpdb).

Étape 1 : Localiser et ouvrir wp-config.php

Connectez-vous à votre serveur via SFTP (préférable au FTP simple pour la sécurité) en utilisant un client comme FileZilla ou Cyberduck, ou ouvrez le Gestionnaire de fichiers de votre hébergeur. Naviguez jusqu’au répertoire racine de WordPress, généralement /public_html/ ou /var/www/html/. Le fichier wp-config.php se trouve à la racine de ce répertoire.

Si vous avez un accès SSH, vous pouvez le modifier directement :

nano /var/www/html/wp-config.php

Étape 2 : Configurer les constantes de débogage

Localisez la ligne existante :

define( 'WP_DEBUG', false );

Remplacez l’intégralité du bloc par la configuration suivante, qui active la journalisation sans exposer les erreurs aux visiteurs du site :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ce que fait chaque constante :

• WP_DEBUG — active le moteur de débogage WordPress et active le rapport d’erreurs PHP au niveau E_ALL.
• WP_DEBUG_LOG — écrit toutes les erreurs capturées dans un fichier journal au lieu de (ou en plus de) l’écran.
• WP_DEBUG_DISPLAY — lorsque défini à false, supprime l’affichage à l’écran. C’est essentiel sur les sites en production ; sans cela, les notices PHP exposent les chemins de fichiers internes et les noms de variables aux visiteurs.
• display_errors — la directive PHP sous-jacente ; la définir à 0 via ini_set fournit une deuxième couche de suppression au cas où un plugin ou un thème remplacerait WP_DEBUG_DISPLAY.

Étape 3 : Localiser le fichier journal de débogage

Avec WP_DEBUG_LOG défini à true, WordPress écrit les erreurs dans :

/wp-content/debug.log

Ce fichier est créé automatiquement lors de la première erreur journalisée. Vous pouvez le consulter via SFTP ou SSH :

tail -f /var/www/html/wp-content/debug.log

L’option tail -f diffuse les nouvelles entrées en temps réel, ce qui est précieux lors de la reproduction d’une erreur spécifique de manière interactive.

Étape 4 : Utiliser un chemin de journal personnalisé (recommandé pour la sécurité)

Le chemin par défaut debug.log est accessible publiquement si votre serveur web ne le bloque pas explicitement. Un serveur mal configuré servira https://yourdomain.com/wp-content/debug.log à n’importe quel visiteur, exposant les chemins internes, les préfixes de tables de base de données et les noms de classes.

Option A — Déplacer le fichier journal en dehors de la racine web :

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Créez le répertoire cible et définissez les permissions :

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Option B — Bloquer le chemin par défaut via .htaccess (Apache) :

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Option C — Équivalent Nginx dans votre bloc serveur :

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Étape 5 : Désactiver le mode débogage après le dépannage

Ne laissez jamais WP_DEBUG défini à true sur un site en production plus longtemps que nécessaire. Une fois le problème résolu :

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

Laisser le mode débogage actif sur un site en production dégrade les performances (PHP traite chaque notice E_ALL) et peut exposer des traces de pile sensibles si WP_DEBUG_DISPLAY est accidentellement défini à true.

Méthode 2 : Accéder aux journaux d’erreurs au niveau du serveur via votre panneau de contrôle d’hébergement

Les erreurs WordPress qui surviennent avant que le démarrage de WordPress ne soit terminé — comme un wp-config.php corrompu, une incompatibilité de version PHP ou un échec de connexion à la base de données — n’apparaîtront jamais dans debug.log car WordPress lui-même ne se charge jamais. Pour celles-ci, vous avez besoin du journal d’erreurs PHP du serveur ou du journal d’erreurs Apache/Nginx.

Hébergement basé sur cPanel

Si votre environnement d’hébergement utilise un VPS avec cPanel, le journal d’erreurs est accessible via l’interface du panneau de contrôle :

1. Connectez-vous à cPanel.
2. Naviguez vers Métriques > Erreurs.
3. Le panneau affiche les 300 dernières lignes du journal d’erreurs Apache pour votre compte.

Pour le fichier journal complet, utilisez le Gestionnaire de fichiers de cPanel ou connectez-vous via SFTP et naviguez vers :

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Les noms de fichiers exacts varient selon la configuration du serveur, mais le modèle est cohérent sur la plupart des installations cPanel.

Hébergement basé sur Plesk

Dans Plesk, naviguez vers Sites Web & Domaines > sélectionnez votre domaine > Journaux. Vous pouvez filtrer par type de journal (accès, erreur, PHP) et télécharger le fichier journal complet.

Accès direct au serveur (VPS ou dédié)

Sur un environnement VPS Hosting ou Serveur dédié où vous disposez d’un accès root, les emplacements des journaux dépendent de votre stack :

Pour surveiller le journal PHP-FPM en temps réel :

tail -f /var/log/php8.2-fpm.log

Pour rechercher les erreurs fatales spécifiques à WordPress dans le journal Apache :

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Configurer la journalisation des erreurs PHP au niveau du serveur

Si les erreurs PHP ne sont pas écrites dans un journal, vérifiez votre configuration php.ini :

php --ini | grep "Loaded Configuration"

Ouvrez le fichier php.ini identifié et vérifiez ou définissez :

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Redémarrez PHP-FPM après les modifications :

systemctl restart php8.2-fpm

Vous pouvez également remplacer les paramètres PHP par site en utilisant un fichier .htaccess (Apache uniquement) :

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Méthode 3 : Utiliser un plugin de journalisation des erreurs WordPress

Pour les environnements où l’accès direct au serveur est restreint — comme l’Hébergement Web Mutualisé — ou pour les équipes où des administrateurs non techniques doivent examiner les erreurs sans accès SSH, un plugin WordPress constitue une alternative viable.

Plugins recommandés

• WP Log Viewer — lit le fichier debug.log existant et l’affiche dans l’administration WordPress avec filtrage et recherche.
• Error Log Monitor — ajoute un widget de tableau de bord affichant les erreurs récentes et peut envoyer des alertes par e-mail lorsque de nouvelles erreurs sont journalisées.
• Query Monitor — va au-delà de la journalisation des erreurs pour profiler les requêtes de base de données, les appels HTTP API, les hooks et les balises conditionnelles. Indispensable pour le débogage des performances.
• Health Check & Troubleshooting — le plugin officiel de WordPress.org ; active un mode de dépannage qui active un thème par défaut et désactive tous les plugins pour votre session uniquement, sans affecter les autres visiteurs.

Installation et configuration d’Error Log Monitor

1. Dans l’administration WordPress, allez dans Extensions > Ajouter.
2. Recherchez Error Log Monitor et cliquez sur Installer maintenant, puis sur Activer.
3. Naviguez vers Réglages > Error Log Monitor.
4. Définissez le chemin du fichier journal. Si vous avez déplacé debug.log en dehors de la racine web, entrez ici le chemin absolu du serveur.
5. Configurez la fréquence des alertes par e-mail si vous souhaitez des notifications pour les nouveaux types d’erreurs.

Le plugin lit le même fichier debug.log dans lequel WP_DEBUG_LOG écrit. Il ne crée pas de mécanisme de journalisation séparé — c’est une visionneuse. Cela signifie que WP_DEBUG et WP_DEBUG_LOG doivent toujours être activés dans wp-config.php pour que le plugin affiche quoi que ce soit.

Limitation critique : Les plugins se chargent après le démarrage de WordPress. Toute erreur qui empêche WordPress de se charger (échec de connexion à la base de données, fichier core corrompu, version PHP incompatible) ne sera visible dans aucune visionneuse de journaux basée sur un plugin. Pour ces scénarios, la Méthode 2 est la seule option.

Comparaison : Trois méthodes de journalisation des erreurs WordPress

Lecture et interprétation des entrées du journal d’erreurs WordPress

Une entrée brute de debug.log ressemble à ceci :

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Comment lire ceci :

• L’horodatage est en UTC — convertissez-le dans le fuseau horaire local de votre serveur si nécessaire.
• PHP Fatal error signifie que l’exécution s’est arrêtée. La page qui a déclenché cela a renvoyé une erreur 500 ou un écran blanc.
• Call to undefined function get_field() signifie que le plugin Advanced Custom Fields est soit désactivé, soit chargé après que le functions.php du thème a essayé de l’appeler.
• La trace de pile indique le fichier exact et le numéro de ligne. Commencez le débogage à la ligne 47 de functions.php.

Modèles d’erreurs courants et leurs causes :

• PHP Warning: require(): Failed opening required — un chemin de fichier est incorrect ou un fichier est manquant. Souvent causé par un plugin faisant référence à un fichier qui a été supprimé.
• PHP Deprecated: Function _register_controls is deprecated — un plugin ou un thème utilise une API obsolète. Pas fatal, mais indique un plugin qui n’a pas été mis à jour pour la version actuelle de WordPress/Elementor.
• WordPress database error ... for query — une requête wpdb a échoué. Vérifiez les incompatibilités de préfixe de table ou les tables corrompues.
• Maximum execution time of 30 seconds exceeded — un script a fonctionné trop longtemps. Fréquent avec les importations volumineuses, les requêtes non optimisées ou les appels API externes qui expirent.
• Allowed memory size of X bytes exhausted — PHP a atteint la limite mémoire. Augmentez memory_limit dans php.ini ou identifiez le plugin qui provoque une fuite mémoire.

Meilleures pratiques pour la gestion des journaux d’erreurs WordPress

Faites tourner les journaux pour éviter l’épuisement du disque. Un site WordPress très fréquenté sous attaque ou avec une erreur récurrente peut générer des centaines de mégaoctets de données de journal par jour. Sur les serveurs Linux, configurez logrotate :

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Ne commitez jamais debug.log dans le contrôle de version. Ajoutez-le à .gitignore :

wp-content/debug.log

Auditez votre wp-config.php après chaque migration de serveur. Les migrations d’hébergement réinitialisent fréquemment WP_DEBUG à false ou introduisent un nouveau modèle wp-config.php qui écrase vos constantes.

Utilisez SAVEQUERIES pour le débogage au niveau de la base de données. Ajoutez cette constante aux côtés de WP_DEBUG pour journaliser chaque requête SQL exécutée par WordPress :

define( 'SAVEQUERIES', true );

Inspectez ensuite $wpdb->queries dans un modèle personnalisé ou via Query Monitor. Désactivez-le immédiatement après utilisation — il stocke chaque requête en mémoire et augmente significativement la consommation de RAM.

Corrélez les horodatages des journaux avec les événements de déploiement. Si un nouveau type d’erreur apparaît, vérifiez s’il coïncide avec une mise à jour de plugin, une mise à jour du core WordPress ou un changement de version PHP sur le serveur. La plupart des panneaux de contrôle d’hébergement journalisent les changements de version PHP dans une piste d’audit séparée.

Matrice de décision : Quelle méthode utiliser

Liste de contrôle des points clés techniques

• Définissez WP_DEBUG_DISPLAY à false avant d’activer WP_DEBUG_LOG sur tout site avec du trafic en direct.
• Déplacez debug.log en dehors de la racine web ou bloquez-le via des règles serveur — le chemin par défaut est accessible publiquement.
• Utilisez tail -f sur le fichier journal lors de la reproduction interactive des erreurs ; cela élimine le besoin d’actualiser le fichier manuellement.
• Les journaux PHP et Apache/Nginx au niveau du serveur sont la seule source de vérité pour les erreurs qui surviennent avant le chargement de WordPress.
• Les visionneuses de journaux basées sur des plugins nécessitent que WP_DEBUG_LOG soit actif — ce sont des lecteurs, pas des rédacteurs.
• Implémentez la rotation des journaux sur tout serveur où WP_DEBUG_LOG est activé pendant plus de quelques heures.
• Ne laissez jamais SAVEQUERIES activé en production ; c’est une charge pour la mémoire et les performances.
• Après avoir résolu un problème, redéfinissez toutes les constantes de débogage à false et vérifiez avec une requête navigateur qu’aucune notice PHP n’apparaît dans le code source de la page.

—

Questions fréquemment posées

Où se trouve le fichier journal de débogage WordPress par défaut ?

WordPress écrit le journal de débogage dans /wp-content/debug.log par rapport à votre répertoire racine WordPress. Ce chemin n’est créé qu’après la journalisation de la première erreur et uniquement lorsque WP_DEBUG et WP_DEBUG_LOG sont tous deux définis à true dans wp-config.php. Vous pouvez remplacer le chemin en passant une chaîne de chemin de fichier absolu comme valeur de WP_DEBUG_LOG au lieu de true.

Est-il sûr d’activer WP_DEBUG sur un site en production ?

C’est sûr uniquement si WP_DEBUG_DISPLAY est explicitement défini à false et display_errors est défini à 0. Sans ces deux paramètres, les erreurs PHP — y compris les chemins de fichiers internes et les noms de tables de base de données — sont rendues directement dans le code source HTML de chaque page. Associez toujours WP_DEBUG true avec WP_DEBUG_DISPLAY false sur tout site avec du trafic public.

Pourquoi mon fichier debug.log est-il vide même si WP_DEBUG est activé ?

Les causes les plus courantes sont : le processus du serveur web n’a pas la permission d’écriture dans le répertoire /wp-content/ ; WP_DEBUG_LOG est défini à false ou est absent de wp-config.php ; ou l’erreur se produit au niveau du serveur avant le chargement de WordPress, ce qui signifie qu’elle apparaîtra dans le journal Apache ou PHP-FPM plutôt que dans debug.log. Vérifiez les permissions du répertoire avec ls -la wp-content/ et assurez-vous que les constantes sont définies dans le bon ordre dans wp-config.php.

Quelle est la différence entre WP_DEBUG_LOG et le journal d’erreurs PHP du serveur ?

WP_DEBUG_LOG est une constante au niveau WordPress qui achemine les erreurs capturées par le gestionnaire d’erreurs personnalisé de WordPress vers debug.log. Le journal d’erreurs PHP du serveur (configuré via error_log dans php.ini) capture toutes les erreurs PHP au niveau de l’interpréteur, y compris celles qui surviennent avant l’initialisation de WordPress. Sur un serveur correctement configuré, les deux journaux sont actifs simultanément et se complètent mutuellement.

Puis-je activer la journalisation des erreurs sur un hébergement mutualisé sans accès SSH ?

Oui. Vous pouvez modifier wp-config.php via le Gestionnaire de fichiers de votre hébergeur dans cPanel ou Plesk, activer WP_DEBUG et WP_DEBUG_LOG, puis lire debug.log via la même interface du Gestionnaire de fichiers. Pour les journaux au niveau du serveur sur l’Hébergement Web Mutualisé, utilisez la section Erreurs sous Métriques dans cPanel. Si vous avez besoin d’un contrôle plus granulaire sur la configuration PHP et les chemins de journaux, passer à un plan VPS Hosting vous donne un accès direct à php.ini et un accès SSH complet à tous les fichiers journaux.