La journalisation d’une application consiste à enregistrer automatiquement, pour chaque événement important, quand il a eu lieu, où, qui l’a déclenché et quoi exactement. Bien conçue, elle permet de répondre en quelques minutes à la question « qui a modifié ce dossier, et quand ? », de détecter une intrusion et de prouver sa bonne foi en cas de litige. La CNIL recommande de conserver ces traces six mois à un an, de les protéger contre la modification et d’en exclure les données sensibles comme les mots de passe.
Dans beaucoup d’applications métier, la traçabilité se limite à une colonne « modifié le » qui écrase la précédente. Le jour où une remise anormale apparaît sur une facture ou qu’un client affirme ne jamais avoir validé une commande, personne ne peut reconstituer les faits.
À quoi sert la traçabilité dans une application métier ?
On confond souvent deux usages qui obéissent à des règles différentes.
La piste d’audit métier retrace l’histoire des données : création d’une commande, modification d’un prix, changement de statut, validation d’une dépense. Elle s’adresse aux utilisateurs, aux managers, aux auditeurs internes ou aux commissaires aux comptes. Elle répond à des questions comme « pourquoi ce devis est-il passé de 12 à 9 % de remise ? ».
Le journal de sécurité enregistre les événements qui intéressent la protection du système : connexions réussies et échouées, refus d’accès, changements de droits, exports massifs, erreurs inhabituelles. Il sert à détecter et à enquêter.
La CNIL résume l’objectif : assurer « une traçabilité des accès et des actions des différents utilisateurs habilités » et disposer d’un « outil efficace de détection et d’investigation en cas d’incident ». Les deux usages se complètent : la piste d’audit explique ce qui s’est passé, le journal de sécurité aide à comprendre comment.
Quels événements faut-il journaliser ?
Tout enregistrer est une fausse bonne idée. L’OWASP met en garde contre le « brouillard d’alertes » : à force de tout tracer, plus personne ne voit l’essentiel. Voici la sélection que nous recommandons pour une application de gestion.
| Famille | Événements à tracer | Pourquoi |
|---|---|---|
| Authentification | Connexions réussies et échouées, déconnexions, réinitialisations de mot de passe, activation de la MFA | Détecter les tentatives d’usurpation de compte |
| Autorisation | Refus d’accès, changements de rôle ou de périmètre, création de comptes administrateurs | Repérer une escalade de privilèges ou une erreur de paramétrage |
| Données métier | Création, modification (avant / après), suppression des objets sensibles : prix, remises, coordonnées bancaires, statuts | Reconstituer l’historique d’un dossier, trancher un litige |
| Opérations à risque | Exports, imports, téléchargements en masse, envois groupés | Détecter une exfiltration de données |
| Système | Erreurs applicatives, échecs d’intégration avec d’autres outils, changements de configuration | Diagnostiquer les pannes, prouver la disponibilité |
| Consentements | Acceptation des conditions, opt-in et opt-out | Démontrer la conformité |
La CNIL encourage précisément la journalisation « des actions d’accès, création, modification et suppression ». L’OWASP ajoute les actions métier suspectes, comme une suite d’opérations dans un ordre anormal ou des tentatives de dépasser une limite.
Que doit contenir chaque trace ?
Une trace exploitable répond à quatre questions, selon la grille proposée par l’OWASP :
- Quand ? La date et l’heure de l’événement, avec un fuseau horaire explicite. Tous les serveurs doivent être synchronisés sur la même horloge, sinon il devient impossible de recouper deux journaux.
- Où ? L’application, sa version, le module ou l’adresse appelée.
- Qui ? L’identifiant de l’utilisateur, ou du compte technique pour une synchronisation automatique, et l’adresse d’origine.
- Quoi ? Le type d’événement, l’objet concerné (la commande n° 4521), le résultat (réussi, refusé, en erreur) et, pour une modification, l’ancienne et la nouvelle valeur.
Un identifiant de corrélation complète utilement l’ensemble : il relie tous les événements d’une même action, de l’écran jusqu’aux appels vers l’ERP ou la plateforme de facturation. C’est indispensable quand l’application échange avec d’autres outils, comme nous l’expliquons dans notre article sur les synchronisations fiables.
Ce qu’il ne faut jamais écrire dans un journal
Les journaux sont souvent moins protégés que la base de données. Y copier des informations sensibles crée donc une seconde fuite potentielle. L’OWASP et la CNIL convergent sur une liste d’exclusions :
- les mots de passe, et même leur empreinte, que la CNIL cite explicitement ;
- les jetons de session et clés d’accès aux API ;
- les coordonnées bancaires complètes et les données de carte de paiement ;
- les clés de chiffrement et chaînes de connexion aux bases de données ;
- les données personnelles qui ne sont pas nécessaires à la compréhension de l’événement.
Pour une modification de coordonnées bancaires, on trace l’événement, son auteur et les quatre derniers chiffres de l’IBAN, pas l’IBAN complet. Pour un dossier médical ou RH, on trace l’accès au dossier, pas son contenu. Ce principe de minimisation est au cœur du RGPD appliqué aux applications métier.
Combien de temps conserver les journaux ?
La CNIL recommande dans sa fiche « Tracer les opérations » de conserver les événements « sur une période glissante comprise entre six mois et un an ». Sa recommandation de 2021 admet une durée plus longue, jusqu’à trois ans dans les cas les plus courants, pour les traitements soumis à des mesures de contrôle interne, à condition de la justifier.
| Type de trace | Durée de référence | Justification à documenter |
|---|---|---|
| Journal de sécurité (connexions, accès, refus) | 6 mois à 1 an | Recommandation CNIL |
| Piste d’audit de traitements soumis à contrôle interne | Jusqu’à 3 ans | Exigence de contrôle, démontrée et écrite |
| Historique métier rattaché à une pièce comptable ou contractuelle | Durée de conservation de la pièce elle-même | Obligation légale propre au document |
| Journal technique (erreurs, performances) | Quelques semaines à quelques mois | Besoin de diagnostic |
La CNIL range explicitement parmi les mauvaises pratiques le fait de « conserver les traces sans limite de durée ». Une purge automatique, paramétrée par type de trace, règle la question une fois pour toutes.
Protéger, centraliser, exploiter
Une trace qui peut être effacée par celui qu’elle accuse ne vaut rien. Les recommandations sont convergentes :
- Centraliser les journaux hors du serveur de l’application, dans un espace dédié. L’OWASP cite parmi les défaillances classiques les journaux stockés uniquement en local.
- Empêcher la modification : stockage en ajout seul, contrôle d’intégrité, droits de lecture restreints et eux-mêmes tracés.
- Superviser le dispositif : la CNIL recommande de vérifier régulièrement la présence de journaux exploitables. Un journal qui s’arrête silencieusement après une mise à jour est un classique.
- Encadrer les sous-traitants : exiger contractuellement la journalisation et la notification rapide de tout incident, notamment chez l’hébergeur.
L’OWASP a d’ailleurs renommé sa catégorie dédiée en 2025 : elle s’intitule désormais « Security Logging and Alerting Failures », pour souligner que sans alerte, la réponse à incident arrive trop tard. Quelques règles d’alerte simples suffisent souvent à démarrer : une série d’échecs de connexion sur un compte, un export inhabituellement volumineux, une connexion administrateur à une heure atypique, une rafale de refus d’accès, qui signale souvent une tentative d’exploiter un contrôle d’accès défaillant.
Transparence et usages interdits
Journaliser les actions de salariés est un traitement de données personnelles. La CNIL demande d’informer les utilisateurs, par exemple à la connexion ou dans la charte informatique, après consultation des représentants du personnel. Elle rappelle surtout que les journaux ne doivent servir qu’à garantir le bon usage du système : les utiliser pour compter les heures travaillées est un détournement de finalité.
Une bonne pratique consiste à rendre la piste d’audit métier visible là où elle est utile : un onglet « historique » sur chaque dossier, consultable par ceux qui ont accès au dossier. La traçabilité devient alors un outil de travail, qui évite les échanges de courriels pour savoir qui a changé quoi, plutôt qu’un dispositif de surveillance.
La checklist pour votre projet
- Lister avec les métiers les objets sensibles dont l’historique doit être conservé (prix, remises, statuts, coordonnées bancaires, droits).
- Définir les événements de sécurité à tracer et les règles d’alerte associées.
- Fixer une durée de conservation par type de trace et automatiser la purge.
- Exclure les données sensibles des journaux et le vérifier en recette.
- Centraliser et protéger les journaux, avec des droits de lecture restreints.
- Informer les utilisateurs et documenter la finalité.
- Tester le dispositif : simuler un incident et vérifier que l’on retrouve la séquence complète.
Ces exigences s’intègrent naturellement au cahier des charges et pèsent peu dans un projet si elles sont prévues dès le départ. Les ajouter après coup est nettement plus laborieux. Elles contribuent aussi aux obligations de détection d’incidents que la directive NIS2 impose aux entreprises concernées. Vous souhaitez évaluer la traçabilité de votre application actuelle ou la concevoir correctement pour un nouvel outil ? Parlons-en.
