Un log est un fichier texte généré automatiquement par un système, une application ou un équipement réseau pour enregistrer chaque événement survenu dans son périmètre. Chaque ligne correspond à une action horodatée : connexion d’un utilisateur, erreur de traitement, requête reçue par un serveur. Ce mécanisme de journalisation constitue la mémoire brute de tout environnement informatique.
Anatomie d’une ligne de log : les champs qui comptent
Avant de parler d’outils ou de bonnes pratiques, il faut comprendre ce que contient concrètement une ligne de log. Quel que soit le système qui la produit, une entrée de journal repose sur quelques champs récurrents.
A lire également : Quels sont les deux types de virtualisation de réseau ?
- L’horodatage (timestamp) : date et heure précises de l’événement, souvent au millième de seconde. Sans ce champ, impossible de reconstituer la chronologie d’un incident.
- Le niveau de sévérité : DEBUG, INFO, WARN, ERROR, CRITICAL. Ce classement permet de filtrer rapidement les lignes pertinentes avec un outil comme grep ou un agrégateur centralisé.
- La source : nom du service, du processus ou du module qui a émis l’entrée. Sur un serveur qui héberge plusieurs applications, ce champ évite de mélanger les flux.
- Le message : description en texte libre de l’événement. C’est la partie la plus variable, et souvent la moins normalisée.
Un format structuré (JSON, clé-valeur) facilite l’analyse automatisée. Un format non structuré (texte libre) reste courant dans les applications anciennes, mais complique le filtrage dès que le volume de lignes augmente.
Lire également : Pourquoi l'IA n'est pas fiable ?
Logs et sécurité : une obligation réglementaire, pas un luxe
La journalisation dépasse le simple diagnostic technique. Le règlement d’exécution européen (UE) 2024/2690, applicable depuis le 7 novembre 2024, impose des exigences de surveillance et de journalisation à plusieurs catégories d’entités couvertes par la directive NIS2 : fournisseurs cloud, centres de données, CDN, services gérés et de sécurité gérés, places de marché en ligne, moteurs de recherche et réseaux sociaux.
En cas d’incident significatif, NIS2 exige une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final dans le mois. Sans journaux horodatés, centralisés et protégés, reconstituer la chronologie exigée devient pratiquement impossible.
Les logs doivent donc être conçus comme des preuves exploitables, pas comme un simple historique que l’on consulte après coup. Cela implique de protéger leur intégrité (pas de modification a posteriori), de les stocker sur un système distinct de celui qu’ils surveillent, et de définir une durée de rétention cohérente avec les obligations sectorielles.
RGPD et logs : ce qu’il faut éviter d’enregistrer
Collecter le maximum de données dans les logs peut sembler prudent du point de vue de la sécurité. Le RGPD impose la logique inverse. Les principes de finalité, de minimisation et de limitation de la conservation s’appliquent aux journaux comme à toute autre collecte de données personnelles.
Concrètement, la CNIL recommande de référencer les données concernées plutôt que de les dupliquer dans les fichiers de log. Recopier systématiquement des requêtes complètes, des données métier ou des identifiants sensibles peut être considéré comme disproportionné.
L’enregistrement de mots de passe ou de leurs empreintes dans les logs est explicitement déconseillé. Ce piège est fréquent dans les applications qui journalisent l’intégralité des requêtes HTTP en mode DEBUG, y compris les formulaires de connexion.
Trouver l’équilibre entre traçabilité et minimisation
La tension entre sécurité et protection des données personnelles se résout par la conception. On définit en amont quels événements méritent d’être journalisés, quels champs sont nécessaires dans chaque ligne, et quelle durée de stockage correspond à chaque usage.
Un log d’accès destiné à détecter des tentatives d’intrusion n’a pas besoin de conserver le contenu complet de chaque requête. L’horodatage, l’adresse IP source, le code de réponse et l’identifiant de session suffisent dans la majorité des cas.
Gestion et stockage des logs à grande échelle
Sur un serveur unique, consulter les logs avec grep ou tail reste efficace. Dès qu’un système repose sur plusieurs machines, conteneurs ou microservices, la collecte centralisée devient nécessaire.
Le principe est simple : chaque composant envoie ses logs vers un collecteur central qui les indexe et les rend interrogeables. Des outils comme la suite Elastic (Elasticsearch, Logstash, Kibana) ou des solutions basées sur OpenTelemetry remplissent cette fonction. Le choix dépend du volume de données, du format des logs et des compétences de l’équipe.
Le problème du volume de données
Les logs grossissent vite. Une application web à fort trafic peut générer plusieurs gigaoctets de journaux par jour. Sans politique de rotation et de rétention, le stockage explose et la recherche devient lente.
La rotation consiste à archiver ou supprimer automatiquement les fichiers les plus anciens. Sous Linux, l’utilitaire logrotate gère cette tâche pour la plupart des services système. Pour les environnements centralisés, la politique de rétention se configure directement dans l’outil d’indexation.
Trois questions permettent de calibrer le stockage :
- Quelle durée de conservation est imposée par la réglementation applicable (NIS2, RGPD, normes sectorielles) ?
- Quel niveau de détail (DEBUG vs INFO) est réellement exploité au quotidien ?
- Les logs archivés doivent-ils rester interrogeables en temps réel ou un accès différé suffit-il ?
Réduire le niveau de verbosité en production (passer de DEBUG à WARN, par exemple) divise significativement le volume sans perdre les événements critiques.
Format structuré ou texte brut : un choix qui impacte toute la chaîne
Un log en texte brut ressemble à une phrase humaine : 2025-09-22 14:03:12 ERROR Connexion refusée pour user admin depuis 192.168.1.42. Lisible à l’oeil, mais chaque outil d’analyse doit deviner où se trouvent les champs.
Un log structuré en JSON expose ses champs explicitement. Le parser n’a plus besoin de regex fragiles pour extraire l’adresse IP ou le nom d’utilisateur. Le format structuré réduit les erreurs d’interprétation automatisée et accélère les requêtes sur de gros volumes.
Migrer vers un format structuré a un coût : adapter le code applicatif, revoir les pipelines de collecte, former les équipes. Sur un projet existant, la transition se fait souvent service par service, en commençant par les composants les plus critiques.
La qualité d’un système de journalisation ne se mesure pas au nombre de lignes produites, mais à la capacité de retrouver la bonne information au bon moment. Un log bien conçu, avec des champs normalisés, un niveau de sévérité cohérent et une durée de rétention adaptée, transforme un fichier texte passif en outil de diagnostic, de preuve et de pilotage.
