Journalisation dans les applications PHP : meilleures pratiques et outils

Introduction : Pourquoi la journalisation est la base d'une application PHP fiable

La journalisation (log) est le processus d'enregistrement des événements qui se produisent dans une application dans un journal spécial (fichier de log). Pour un développeur PHP, une journalisation compétente n'est pas seulement un « plus dans la karma », mais une nécessité. Sans elle, le débogage des erreurs de production devient un jeu de devinettes, et la surveillance des performances devient impossible. Une journalisation mal configurée peut entraîner une fuite de données sensibles ou, au contraire, une perte d'informations critiques.

Dans cet article, nous allons analyser les meilleures pratiques de journalisation en PHP : du choix de la bibliothèque et des niveaux de journalisation à la structuration des messages et à la sécurité. Vous apprendrez comment transformer des echo et var_dump dispersés en un système de surveillance professionnel.

1. Choix de la bibliothèque : PSR-3 et Monolog

Dans la communauté PHP moderne, l'interface Psr\\Log\\LoggerInterface (PSR-3) est la norme de facto. Elle définit 8 méthodes pour différents niveaux de journalisation : emergency, alert, critical, error, warning, notice, info, debug.

L'implémentation la plus populaire de PSR-3 est la bibliothèque Monolog. Elle est flexible, puissante et prise en charge par pratiquement tous les frameworks modernes (Laravel, Symfony, Yii2).

Installation de Monolog via Composer

composer require monolog/monolog

Exemple d'utilisation de base

<?phprequire 'vendor/autoload.php';

use Monolog\\Logger;use Monolog\\Handler\\StreamHandler;

// Création d'un logger avec un nom de canal (par exemple, 'my_app')$log = new Logger('my_app');// Ajout d'un handler : écrit dans un fichier, niveau - INFO et supérieur$log->pushHandler(new StreamHandler(__DIR__ . '/app.log', Logger::INFO));

// Journalisation des messages$log->info('Utilisateur connecté', ['user_id' => 123]);$log->warning('Mot de passe incorrect', ['attempts' => 3]);$log->error('Erreur de connexion à la base de données', ['exception' => $e->getMessage()]);?>

Remarque : le deuxième argument est le contexte (context). Vous pouvez y passer toutes les données supplémentaires : ID utilisateur, IP, stack trace, etc. Ne concaténez jamais les données dans la chaîne du message — utilisez le contexte.

2. Niveaux de journalisation et filtrage

L'utilisation des bons niveaux est la base d'un journal lisible. La règle générale : plus le niveau est élevé, moins il y a de messages. Voici une aide-mémoire rapide :

• DEBUG (100) — informations de débogage pour le développement. Généralement désactivé en production.
• INFO (200) — événements importants : utilisateur inscrit, commande créée.
• NOTICE (250) — événements normaux mais significatifs.
• WARNING (300) — situation anormale, mais l'application continue de fonctionner (par exemple, tentative de connexion échouée).
• ERROR (400) — erreur nécessitant une intervention (impossible de sauvegarder le fichier).
• CRITICAL (500) — erreur critique (base de données inaccessible).
• ALERT (550) — action immédiate requise.
• EMERGENCY (600) — système inopérant.

Filtrage dans différents environnements

En production, il n'est pas nécessaire d'écrire des messages DEBUG — ils créent une charge inutile sur le disque et rendent difficile la recherche d'enregistrements importants. Utilisez différents handlers pour différents environnements :

<?phpuse Monolog\\Logger;use Monolog\\Handler\\StreamHandler;use Monolog\\Handler\\FingersCrossedHandler;

$log = new Logger('app');

if (getenv('APP_ENV') === 'production') {    // En production, on écrit uniquement WARNING et supérieur    $log->pushHandler(new StreamHandler('/var/log/app/error.log', Logger::WARNING));    // FingersCrossedHandler : bufferise tout, mais n'écrit qu'en cas d'erreur    $log->pushHandler(new FingersCrossedHandler(        new StreamHandle