Les log levels sont des étiquettes de gravité attachées à chaque entrée de journal. Ils contrôlent ce qui est enregistré, ce qui est affiché et ce qui déclenche une alerte. Le standard dominant compte cinq niveaux — DEBUG, INFO, WARN, ERROR, FATAL — par gravité croissante. La valeur centrale de ce système : réduire le bruit au minimum en temps normal, puis filtrer et alerter rapidement par niveau quand quelque chose casse.
Référence rapide : les cinq niveaux standard
| Niveau |
Signification |
Contenu typique |
Production |
Alerte |
| DEBUG |
Détails de débogage |
Valeurs de variables, requêtes SQL, arguments de fonction |
Désactivé |
Non |
| INFO |
Jalons métier normaux |
Connexion utilisateur, commande créée, tâche lancée |
Activé |
Non |
| WARN |
Anormal mais auto-résorbé |
Retry réussi, repli déclenché, requête lente |
Activé |
Agréger et suivre manuellement |
| ERROR |
Échec d'une opération en cours |
API 5xx, paiement refusé, pointeur nul |
Activé |
Oui |
| FATAL |
Indisponibilité système |
Base de données injoignable, service qui ne démarre pas |
Activé |
Oui (réponse P0) |
Comment choisir le bon niveau
En pratique, le mauvais usage des niveaux est plus fréquent que l'absence de logs. Critères opérationnels :
DEBUG : pour les yeux du développeur
- Critère : cette information ne vaut rien tant que le système tourne normalement, et ne sert qu'enquête d'un bug précis ;
- Contenu typique : arguments et retours de fonctions, résultats intermédiaires, taux de hit du cache ;
- Principe clé : désactivé par défaut en production. Pas supprimé — filtré, pour pouvoir l'activer ponctuellement en cas de pépin.
INFO : pour ceux qui demandent « que fait le système »
- Critère : relire cette entrée six mois plus tard permet de reconstituer le parcours de l'utilisateur ;
- Contenu typique : actions métier clés (inscription, commande, publication), début/fin et durée des tâches ;
- Anti-pattern : logguer chaque HTTP 200 en INFO — c'est le travail du journal d'accès ; ne polluez pas les journaux métier avec ça.
WARN : quelque chose a dérapé, mais le système a tenu
- Critère : quelqu'un devrait le savoir, mais personne n'a besoin de se lever à 3 h du matin ;
- Contenu typique : succès après retry, limitation/dégradation déclenchée, durée de requête au-delà du seuil ;
- Signal de risque : une flambée de WARN précède souvent les ERROR — branchez-la sur une surveillance de tendance.
ERROR : l'action d'un utilisateur a échoué
- Critère : si ce n'est pas corrigé, l'utilisateur retombera sur le même problème ;
- Contenu typique : appel à un service externe en échec, exception de validation, erreur non interceptée ;
- Exigence clé : chaque ERROR doit porter son contexte (URL, ID utilisateur/tenant, paramètres de requête, stack trace), sinon ce n'est qu'un bruit inactionnable.
FATAL : le système est déjà à l'arrêt
- Critère : le service dans son ensemble ne peut plus assurer sa mission ;
- Contenu typique : échec de connexion à la base, configuration manquante, démarrage raté ;
- Conseil pratique : FATAL est rare dans les applications web — la plupart des « tout est par terre » se manifestent par une salve d'ERROR, couverte par une alerte « pic soudain d'ERROR ». N'abusez pas de FATAL, vous en dilueriez la gravité.
Les niveaux dans la Console du navigateur
Les niveaux front-end portent les mêmes noms mais font moins. La Console supporte nativement :
| Méthode |
Niveau dans la Console |
Usage |
console.debug() |
Debug (masqué par défaut ; activer Verbose) |
Débogage en développement |
console.log() |
Info |
Sortie générale |
console.info() |
Info |
Idem, plus explicite |
console.warn() |
Warning, jaune |
Indices de problèmes récupérables |
console.error() |
Error, rouge, avec stack trace |
Échecs et exceptions non interceptées |
Deux conseils pratiques :
Écrivez le débogage front-end avec console.debug plutôt que console.log — le build de production le cache derrière le filtre par défaut, pas de nettoyage manuel ;
Les exceptions non interceptées (window.onerror / unhandledrejection) sont de niveau ERROR par défaut : c'est le premier indice en production.
Le problème spécifique au front : les utilisateurs ne collectent pas les logs pour vous
Les logs back-end résident sur les serveurs, consultables dès qu'un problème survient. Les logs front-end se dispersent dans le navigateur de chaque utilisateur — l'utilisateur signale « la page est cassée », et les erreurs Console et requêtes en échec disparaissent avec cette session. Quand l'utilisateur suit un tutoriel pour ouvrir DevTools (étapes : ouvrir la console du navigateur), un refresh a déjà emporté les erreurs.
La question à laquelle une stratégie de logs front-end doit répondre n'est donc pas « comment attribuer les niveaux » mais « comment préserver les logs de l'instant exact de la panne ». Approches courantes :
| Approche |
Principe |
Coût |
| Reporter maison |
Renvoyer toute la sortie console au serveur |
Coût de stockage/vie privée élevé, échantillonnage difficile à régler |
| Plateforme de monitoring front-end |
Capture complète + rejeu de session |
Facturation au volume ; cher pour les petites et moyennes équipes |
| Capture à la demande (embarquée dans le rapport de bug) |
À la soumission d'un retour, les erreurs Console/Network de ce moment sont jointes automatiquement |
Coût minimal ; couvre « signalé par l'utilisateur », la plus grande source de toutes |
La troisième approche colle naturellement au rapport de bug : le moment où l'utilisateur signale un bug est exactement le moment où les logs comptent.
BugCapturer applique précisément cette capture à la demande : quand un utilisateur (même totalement non technique) envoie une capture/enregistrement annoté via l'extension ou le SDK embarqué, le rapport emporte automatiquement les erreurs Console du moment (avec les stack traces ERROR) et les requêtes Network en échec, plus l'URL et l'environnement navigateur (voir la fonction diagnostic). Le rapport arrive chez le développeur avec son contexte de logs ERROR — fini les « ouvre F12 et copie ». Les rapports se partagent par un lien sans connexion, ou sont poussés automatiquement dans un canal Slack / Microsoft Teams pour un suivi centralisé.
Erreurs fréquentes
| Erreur |
Bonne pratique |
Tout en console.log, jamais nettoyé |
Utiliser les niveaux : debug pour le débogage, info pour les jalons métier, retirer debug au build |
| Logguer les échecs en INFO « pour ne pas affoler l'ops » |
Un échec est un ERROR ; l'alerte repose sur les niveaux, pas sur la lecture des logs |
| ERROR sans contexte, un simple message |
Toujours joindre URL, paramètres et stack — sinon rien n'a été enregistré |
| DEBUG activé partout « pour dépanner plus vite » |
Les niveaux sont un filtre : DEBUG coupé en temps normal, activé à la demande en cas de problème |
| WARN qui s'accumule sans traitement |
Brancher les WARN sur des alertes de tendance ; une flambée annonce des ERROR |
FAQ
Q : Combien de log levels existe-t-il ?
R : Le standard dominant en compte cinq — DEBUG, INFO, WARN, ERROR, FATAL. Certains frameworks (Syslog, systèmes de type Trace) ajoutent des variantes TRACE/NOTICE/CRITICAL, dont la sémantique se mappe un à un sur le tableau ci-dessus.
Q : Comment choisir et configurer les logging levels ?
R : Tout activé en développement (dès DEBUG), INFO ou WARN et au-delà en production ; ERROR déclenche les alertes, WARN alimente la surveillance de tendance. Configurez les bibliothèques séparément du code métier pour que le DEBUG d'une dépendance ne noie pas tout.
Q : Le front a-t-il besoin de niveaux de logs comme le back ?
R : Oui, mais simplifié : quatre niveaux — debug / info / warn / error — suffisent. L'essentiel : ERROR avec stack trace, et résoudre le problème de la « préservation des logs à l'instant de la panne ».
Q : Comment obtenir les erreurs Console quand un utilisateur signale un bug ?
R : Faire copier des messages d'erreur à des non-techniciens est une cause perdue. Utilisez un outil comme BugCapturer qui capture automatiquement les erreurs Console/Network à la soumission — voir la section « capture à la demande » ci-dessus.