Ah, les logs. Ces petits messages qui s’accumulent dans des fichiers obscurs, comme des post-it collés sur un frigo par un colocataire bordélique. Vous savez, ceux qui disent « Erreur 500 » sans jamais préciser pourquoi, ou « Tout va bien » alors que votre application vient de s’écraser comme un drone en panne de batterie. Si vous en êtes encore à utiliser error_log() ou, pire, var_dump() dans un fichier texte, cet article est pour vous. Bienvenue dans l’ère du logging moderne avec PSR-3.
PSR-3 : le standard qui a mis tout le monde d’accord (enfin, presque)
PSR-3, c’est la norme PHP-FIG qui définit une interface commune pour logger des messages. Son but ? Éviter que chaque framework, chaque librairie, ne réinvente la roue du logging à sa sauce. Résultat : une interface simple, Psr\Log\LoggerInterface, avec des méthodes comme emergency(), alert(), critical(), error(), warning(), notice(), info() et debug(). Oui, c’est inspiré de syslog, et non, ce n’est pas une excuse pour utiliser emergency() à chaque fois que votre test unitaire échoue.
L’avantage ? Vous pouvez brancher n’importe quel logger compatible PSR-3 à votre application, sans tout casser. Monolog ? Log4php ? Votre propre implémentation maison ? Peu importe, tant que ça respecte l’interface. C’est un peu comme choisir entre une Tesla et une Prius : au final, vous roulez, et c’est l’essentiel.
Monolog : le couteau suisse du logging (et votre nouveau meilleur ami)
Si PSR-3 est l’interface, Monolog est l’implémentation la plus populaire. Et pour cause : ce truc est aussi flexible qu’un yogi en pleine séance de méditation. Vous voulez logger dans un fichier ? Un socket ? Une base de données ? Slack ? Un pigeon voyageur ? Monolog peut le faire. Enfin, presque.
Voici un exemple basique pour vous mettre l’eau à la bouche :
<?php
require 'vendor/autoload.php';
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
$log = new Logger('mon_app');
$log->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::DEBUG));
$log->info('L’application démarre, tout va bien… pour l’instant.');
$log->warning('Attention, ce code est plus fragile qu’un château de cartes.');
$log->error('Oh non, tout est cassé. Enfin, presque tout.');
Avec Monolog, vous pouvez aussi ajouter des processors pour enrichir vos logs (ajouter l’IP du client, l’ID de la requête, etc.) ou des formatters pour les rendre plus lisibles. Parce que oui, un log en JSON, c’est classe, mais un log en JSON bien formaté, c’est encore mieux.
Pourquoi error_log() est (presque) un crime contre l’humanité
Bon, soyons honnêtes : error_log() a sauvé des vies. Enfin, des applications. Mais aujourd’hui, c’est un peu comme utiliser un marteau pour enfoncer une vis : ça marche, mais c’est pas optimal. Voici pourquoi vous devriez l’éviter :
- Pas de niveaux de log : tout est mélangé, comme dans un sac de courses après un sprint en supermarché. Impossible de filtrer les erreurs critiques des messages de debug.
- Pas de contexte : un message comme « Erreur » sans contexte, c’est comme un SMS « On se voit plus tard » sans préciser où ni quand. Utile, mais frustrant.
- Pas de flexibilité : vous voulez logger dans un fichier et envoyer une alerte Slack ? Bonne chance avec
error_log(). - Pas de standard : chaque développeur utilise
error_log()à sa manière, ce qui donne des logs aussi cohérents qu’un menu de fast-food.
PSR-3 et Monolog résolvent tous ces problèmes. Et en plus, ils vous permettent de faire des choses vraiment utiles, comme logger des exceptions avec leur stack trace, ou ajouter des tags pour filtrer les logs plus tard. Bref, c’est le jour et la nuit.
Les pièges à éviter (parce que oui, il y en a)
PSR-3 et Monolog, c’est génial, mais ce n’est pas une excuse pour logger n’importe quoi, n’importe comment. Voici quelques erreurs à éviter :
- Logger trop (ou pas assez) : un log de debug à chaque itération d’une boucle, c’est comme allumer un feu de camp dans un placard. À l’inverse, ne pas logger les erreurs critiques, c’est comme conduire les yeux fermés.
- Ne pas utiliser les niveaux de log : si tout est
error(), plus rien n’a de sens. C’est comme crier « Au feu ! » à chaque fois que vous voyez une allumette. - Oublier le contexte : un message comme « Échec de la connexion » sans préciser l’URL ou l’utilisateur, c’est comme envoyer un colis sans adresse. Ça n’ira nulle part.
- Ne pas configurer les handlers : logger dans un fichier, c’est bien. Logger dans un fichier rotatif (qui se compresse et se supprime automatiquement), c’est mieux. Sinon, vous allez finir avec un fichier de 50 Go qui fera planter votre serveur.
Un exemple de bon usage du contexte :
$log->error('Échec de la connexion à la base de données', [
'dsn' => $dsn,
'user' => $user,
'exception' => $e->getMessage(),
]);
Là, au moins, vous savez pourquoi ça a merdé.
Conclusion : PSR-3, ou comment arrêter de faire semblant
Si vous en êtes encore à error_log(), il est temps de grandir. PSR-3 et Monolog ne sont pas juste une mode passagère : ce sont des outils qui rendent votre vie de développeur plus simple, vos logs plus utiles, et vos nuits moins courtes. Alors, la prochaine fois que vous verrez un var_dump() dans un fichier de log, souvenez-vous : il y a une meilleure façon de faire. Et elle s’appelle PSR-3.
Allez, à vos claviers. Et n’oubliez pas : un bon log, c’est comme un bon café. Trop léger, et vous ne voyez pas le problème. Trop fort, et vous êtes submergé. Trouvez le juste milieu.