Quand une application web affiche une page blanche ou qu’un serveur refuse une connexion, la première chose qu’un administrateur fait, c’est ouvrir un fichier. Ce fichier, c’est un log. Il contient la trace horodatée de chaque événement survenu sur le système : une requête reçue, une erreur déclenchée, un utilisateur authentifié. Comprendre les logs en informatique, c’est disposer d’un fil conducteur pour remonter à l’origine d’un problème, vérifier qu’un service fonctionne ou détecter un comportement anormal.
Ce que contient réellement un log et pourquoi le format change tout
Un log est un enregistrement d’événement. Chaque ligne associe au minimum une date, une source et un message. Sur un serveur web, par exemple, chaque visite génère une ligne qui précise l’adresse IP du visiteur, la page demandée, le code de réponse HTTP et le temps de traitement.
Vous avez déjà ouvert un fichier texte rempli de lignes incompréhensibles ? C’est souvent un log non structuré. Le message est rédigé en texte libre, sans format fixe. Chaque application écrit à sa manière, ce qui rend la recherche pénible dès que plusieurs services cohabitent.
À l’inverse, un log structuré en JSON organise chaque champ de façon lisible par une machine. La date, le niveau de sévérité, le service concerné et le message occupent chacun un champ dédié. Le gain est direct : un outil d’analyse peut filtrer, trier et croiser des milliers d’événements en quelques secondes au lieu de chercher un motif dans du texte brut.
Pour tout savoir sur les logs en informatique, la distinction entre format structuré et non structuré est le premier concept à maîtriser, parce qu’il conditionne la suite : collecte, stockage, analyse.
Niveaux de sévérité des logs : lire le bon signal au bon moment
Tous les événements enregistrés n’ont pas la même gravité. Les frameworks de journalisation utilisent une échelle de sévérité qui permet de filtrer ce qui mérite une attention immédiate.
- DEBUG : détails fins utilisés pendant le développement, désactivés en production pour éviter un volume excessif.
- INFO : événements normaux qui confirment le bon fonctionnement (démarrage d’un service, connexion réussie).
- WARN : situation inhabituelle qui n’empêche pas le fonctionnement mais signale un risque (espace disque bas, latence élevée).
- ERROR : un traitement a échoué, une action utilisateur n’a pas abouti. Une intervention est souvent nécessaire.
- FATAL : le service s’arrête. Toute l’application ou le serveur est hors ligne.
La tentation fréquente consiste à tout passer en DEBUG pour « ne rien rater ». Le résultat : des fichiers qui grossissent de plusieurs gigaoctets par jour, un coût de stockage qui explose et un bruit permanent qui noie les véritables alertes. Choisir le bon niveau de sévérité réduit le volume sans perdre d’information utile.
Données sensibles dans les logs : ce qu’il ne faut jamais enregistrer
Un log peut capturer presque tout ce qui transite dans une application. C’est justement le problème. L’OWASP recommande d’exclure des journaux les mots de passe, les jetons d’accès, les identifiants de session, les clés de chiffrement et les données personnelles sensibles.
Pourquoi cette prudence ? Parce que les logs eux-mêmes peuvent devenir une source de fuite de données. Un fichier log stocké sans restriction d’accès expose des informations exploitables par un attaquant. Quand un suivi reste nécessaire, la bonne pratique consiste à masquer ou pseudonymiser les valeurs sensibles avant l’écriture dans le journal.
La CNIL donne un repère pour les traces d’accès et d’actions des utilisateurs : une conservation de six mois à un an selon la finalité. Au-delà, le contenu collecté doit rester proportionné au besoin réel. Conserver des requêtes complètes pendant plusieurs années sans justification définie expose à un risque juridique autant que technique.
Protéger l’intégrité des journaux
Un log modifié ou supprimé perd toute valeur probante. L’OWASP préconise des contrôles d’intégrité, un accès restreint et surveillé, ainsi qu’une mise à l’abri des données de log. Un journal utile à une enquête doit aussi être digne de confiance. Un attaquant qui accède à un serveur tentera souvent d’effacer ses traces dans les logs avant toute autre action.
Réglementation européenne et journalisation : obligations concrètes
La journalisation n’est plus seulement une bonne pratique technique. Le Cyber Resilience Act européen inscrit la journalisation d’événements de sécurité parmi les exigences applicables aux produits numériques. La directive NIS 2, de son côté, impose aux entités concernées de mettre en place des capacités de détection et de réponse aux incidents, ce qui suppose un système de logs fonctionnel et exploitable.
Sans journalisation fiable, la conformité NIS 2 ou CRA devient impossible à démontrer. Ces textes ne détaillent pas quel outil utiliser, mais ils exigent la capacité de tracer, détecter et répondre. Les logs sont le socle technique de cette capacité.
Bonnes pratiques de gestion des logs au quotidien
Mettre en place des logs ne suffit pas. Leur utilité dépend de la façon dont ils sont collectés, centralisés et exploités.
- Centraliser les journaux de tous les services sur une plateforme unique évite de chercher manuellement dans chaque serveur. Un collecteur récupère les événements et les envoie vers un point d’analyse commun.
- Définir une politique de rétention adaptée à chaque type de log. Les traces d’accès utilisateur n’ont pas la même durée de conservation utile que les logs de diagnostic applicatif.
- Mettre en place des alertes sur les niveaux ERROR et FATAL pour réagir avant que les utilisateurs ne signalent le problème.
- Réviser régulièrement ce qui est enregistré. Un champ ajouté lors d’un développement rapide peut contenir des données personnelles sans que personne ne l’ait prévu.
La valeur d’un système de logs se mesure à la vitesse de résolution d’un incident. Un journal bien structuré, centralisé et purgé selon des règles claires transforme une panne de plusieurs heures en un diagnostic de quelques minutes. C’est ce qui sépare une équipe qui subit les incidents d’une équipe qui les anticipe.
