Introduction : Pourquoi les développeurs redoutent l'écran blanc ?
\n\nChaque développeur PHP a déjà vécu cette situation : le code semble correct, mais au lieu du résultat attendu, une page vide s'affiche. Ni erreur, ni avertissement. Juste le silence et la sueur froide. Vous reconnaissez ?
\n\nSur Stack Overflow, la question « How do I get PHP errors to display? » a recueilli des milliers de vues et des centaines de réponses. Ce n'est pas un hasard : savoir activer et gérer correctement les erreurs est une compétence de base qui fait gagner des heures de débogage. Mais attention : une mauvaise configuration peut non seulement être inefficace, mais aussi réduire les performances de votre site ou, pire encore, créer des failles de sécurité.
\n\nDans cet article, nous allons explorer toutes les méthodes pour activer l'affichage des erreurs PHP — des solutions rapides pour le développement local aux configurations sécurisées pour un serveur de production. Et bien sûr, nous aborderons l'optimisation : comment éviter de surcharger les logs et de ralentir votre site.
\n\nPetit rappel : quels sont les types d'erreurs PHP ?
\n\nAvant d'activer l'affichage, il est utile de comprendre ce que nous manipulons. PHP génère plusieurs niveaux d'erreurs :
\n\n- \n
- E_ERROR — erreur fatale. Le script s'arrête. Exemple : manque de mémoire, appel d'une classe inexistante. \n
- E_WARNING — non fatale. Le script continue, mais quelque chose ne va pas. Exemple : inclusion d'un fichier inexistant. \n
- E_NOTICE — notification. Généralement pour des problèmes mineurs (variable non définie). \n
- E_PARSE — erreur de syntaxe. Se produit avant l'exécution du code, difficile à attraper à l'exécution. \n
- E_ALL — inclut tous les niveaux, sauf E_STRICT (avant PHP 8.0). \n
Retenez ceci : en phase de développement, nous voulons voir toutes les erreurs. Sur un serveur de production, seules les erreurs critiques doivent être visibles, et encore, uniquement dans les logs, pas à l'écran.
\n\nMéthode n°1 : Rapide et directe — dans le code
\n\nLa méthode la plus simple pour un débogage ponctuel est d'insérer deux lignes magiques au début de votre script :
\n\n<?php\nini_set('display_errors', 1);\nini_set('display_startup_errors', 1);\nerror_reporting(E_ALL);\n?>\n\nQue se passe-t-il ici ?
\n- \n
display_errors— active l'affichage des erreurs à l'écran. \n display_startup_errors— affiche les erreurs survenues au démarrage de PHP (par exemple, dans php.ini). \n error_reporting(E_ALL)— définit le niveau de rapport : tout afficher. \n
Cette méthode est idéale pour un seul fichier que vous déboguez. Mais attention : vous devez penser à supprimer ces lignes avant de déployer en production. Sinon, vous risquez d'exposer les « entrailles » de votre application aux utilisateurs.
\n\nMéthode n°2 : Configuration de php.ini — globale et permanente
\n\nSi vous travaillez sur une machine locale ou contrôlez votre serveur, il est plus simple de modifier le fichier php.ini. Trouvez ce fichier (généralement dans /etc/php/ ou /usr/local/etc/php/) et modifiez les directives suivantes :
\n\ndisplay_errors = On\ndisplay_startup_errors = On\nerror_reporting = E_ALL\n\nAprès les modifications, n'oubliez pas de redémarrer le serveur web :
\nsudo systemctl restart apache2\n# ou\nsudo systemctl restart nginx php8.1-fpm\n\nImportant : sur un serveur de production, display_errors doit être Off. Configurez plutôt la journalisation des erreurs dans un fichier :
display_errors = Off\nlog_errors = On\nerror_log = /var/log/php_errors.log\nerror_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT\n\nCela réduit la charge sur l'affichage et protège les données du site.
\n\nMéthode n°3 : Via .htaccess — pour les hébergements mutualisés
\n\nSi vous n'avez pas accès à php.ini (par exemple, sur un hébergement bon marché), utilisez le fichier .htaccess à la racine de votre site :
\n\nphp_flag display_errors on\nphp_flag display_startup_errors on\nphp_value error_reporting 32767