Un vol dans une zone sécurisée. Une fuite de données dont l’origine pourrait être physique. Un litige avec un prestataire sur sa présence effective un jour donné. Dans ces situations, la première question des enquêteurs est invariablement : « qui était là, et à quelle heure ? ». La réponse se trouve dans vos logs d’accès badge. Encore faut-il qu’ils soient exploitables. Dans cet article signé Elliaden, on fait le point sur ce que ces données valent vraiment (et sur ce qu’elles ne valent pas).
Ce que les logs d’accès enregistrent réellement
Chaque passage de badge génère une ligne dans le système de gestion du contrôle d’accès. Cette ligne contient, selon la configuration du système, plusieurs informations :
- l’identifiant unique du badge,
- la porte ou le lecteur concerné,
- la date et l’heure exactes du passage,
- et le résultat de la transaction (accès accordé ou refusé).
C’est cette granularité qui fait la force des logs de badge en situation d’incident.
Comme nous le soulignons dans notre article sur le badge et le RGPD, cette traçabilité native est l’un des atouts distinctifs du badge physique : elle est produite par construction, sans infrastructure supplémentaire, et constitue un historique continu des mouvements dans les locaux.
En cas d’enquête interne, d’audit NIS2 ou de procédure judiciaire, ces données permettent de reconstituer une chronologie précise : qui a eu accès à quelle zone, dans quel ordre, sur quelle durée.
C’est un point que notre dossier sur la conformité NIS2 soulève explicitement : la traçabilité et l’auditabilité des accès physiques sont une exigence directe de la directive, satisfaite sans surcoût par un système de badges correctement configuré.
Les limites que personne ne mentionne assez
La force des logs de badge est réelle. Mais leur portée a des limites précises qu’il faut connaître avant d’en avoir besoin, pas après.
Un log prouve un passage, pas une présence
C’est la limite la plus fondamentale. Un log de badge enregistre qu’un badge a franchi un lecteur à un instant précis. Il n’enregistre pas que la personne à qui ce badge appartient était bien celle qui l’utilisait.
Un badge prêté, volé, ou emprunté par un collègue « pour rendre service » produit exactement le même log qu’un passage légitime. La traçabilité porte sur l’identifiant physique, pas sur l’individu.
C’est pourquoi la qualité de la matrice des droits d’accès et la rigueur des procédures d’attribution conditionnent directement la valeur probante des logs. Un système où les badges sont régulièrement partagés ou dont les droits sont attribués par défaut à des profils larges produit des logs qui ne disent pas grand-chose de précis en cas d’incident.
Un log peut être lacunaire si le système est mal configuré
Tous les systèmes de contrôle d’accès ne journalisent pas les mêmes événements par défaut.
Certains n’enregistrent que les accès accordés, pas les refus. D’autres ne conservent les logs que sur une fenêtre glissante de 30 ou 90 jours avant écrasement. D’autres encore n’horodatent pas avec une précision suffisante pour être exploitables en situation de contentieux.
Comme le rappelle notre article sur le coût réel d’un badge, l’absence de logs fiables rend toute investigation impossible, avec des implications légales qui peuvent être majeures.
Un log devient inutilisable si les droits d’accès étaient mal gérés
Imaginez un incident survenu trois jours après le départ d’un collaborateur dont le badge n’a pas été désactivé. Les logs indiquent un passage avec son identifiant. Mais si cet identifiant est toujours actif dans le système, vous ne pouvez pas distinguer un passage de l’intéressé d’un passage d’un tiers ayant récupéré son badge.
Nous développions ce scénario dans notre article sur l’offboarding badge : les logs d’un badge fantôme contaminent la lisibilité de toute la chronologie.
Le même problème se pose avec les accès temporaires laissés ouverts après la fin d’une mission prestataire. Des logs produits par un badge toujours actif mais appartenant à quelqu’un qui n’est plus censé être dans les locaux sont, au mieux, inexplicables. Au pire, ils brouillent l’enquête.
Ce que vaut un log d’accès dans une procédure
La valeur juridique des logs de contrôle d’accès est reconnue sous conditions.
En droit français, les journaux d’accès constituent des éléments de preuve recevables dans le cadre d’une procédure judiciaire, à condition qu’ils répondent à plusieurs critères.
- Ils doivent d’abord être authentiques et intègres : aucune modification ne doit avoir été apportée après les faits, ce qui suppose un stockage sécurisé et, idéalement, une solution d’archivage avec horodatage certifié.
- Ils doivent ensuite avoir été produits dans le cadre d’un traitement déclaré et conforme au RGPD : les collaborateurs doivent avoir été informés de l’existence de ce suivi des accès, conformément aux obligations de transparence de l’article 13 du règlement.
- Enfin, leur durée de conservation doit être justifiée par la finalité poursuivie et cohérente avec la politique interne documentée.
Ces conditions ne sont pas complexes à satisfaire. Mais elles supposent d’avoir anticipé. Un log extrait en urgence lors d’un incident, sans que personne ne sache précisément comment il a été produit, conservé ou sécurisé, perd beaucoup de sa portée dans un contentieux.
Quatre conditions pour que vos logs soient vraiment exploitables
- Journaliser tous les événements, pas seulement les accès accordés. Les tentatives d’accès refusées sont souvent les données les plus parlantes en cas d’intrusion ou de tentative de fraude. Vérifiez que votre système les enregistre systématiquement.
- Définir une politique de conservation adaptée aux risques. La durée de conservation des logs doit être formalisée dans votre politique RGPD. Pour des zones standard, 3 mois est souvent suffisant. Pour des zones sensibles (salle serveur, R&D, direction), une conservation plus longue peut se justifier et se documenter.
- Sécuriser et archiver les logs de manière irréfutable. Les journaux d’accès ne doivent pas être accessibles en écriture par les administrateurs du système. Idéalement, ils sont exportés vers un stockage dédié avec horodatage certifié, ce qui garantit leur intégrité en cas de contestation.
- Maintenir la cohérence du référentiel de badges. La valeur d’un log est directement proportionnelle à la rigueur avec laquelle les badges ont été attribués, désactivés et gérés. Des logs produits dans un système mal tenu (badges partagés, droits larges par défaut, profils inactifs jamais révoqués) ne disent rien de précis sur qui était réellement présent.
La donnée de badge, bien plus qu’un outil d’investigation a posteriori
Réduire les logs d’accès à leur seule utilité en cas d’incident serait passer à côté d’une grande partie de leur valeur. Comme nous le développons dans notre article sur la data cachée dans les badges, ces données constituent une matière première stratégique pour piloter la sécurité de manière proactive.
Un accès dans une zone à une heure inhabituelle. Un badge utilisé sur plusieurs sites simultanément — signe d’un clonage ou d’un partage non autorisé. Une série de tentatives refusées concentrées sur une même porte en quelques minutes. Ces signaux, analysés en temps réel ou lors d’une revue périodique, permettent de détecter une anomalie avant qu’elle ne devienne un incident.
C’est précisément ce que l’IA appliquée au contrôle d’accès commence à rendre possible : des systèmes capables d’apprendre les comportements habituels et d’alerter automatiquement en cas de déviation significative. La donnée de badge, bien exploitée, passe ainsi d’un registre passif à un outil de sécurité active.
Un outil puissant, à condition d’avoir anticipé
Les logs de badge sont parmi les preuves de présence les plus solides disponibles dans un environnement professionnel. Horodatés, granulaires, produits en continu sans intervention humaine, ils ont tout pour constituer un instrument d’investigation fiable.
Mais leur valeur réelle dépend entièrement de ce qui a été fait avant l’incident : comment les badges ont été attribués, comment les droits ont été gérés, comment les logs ont été conservés et sécurisés. Un log extrait dans l’urgence depuis un système mal tenu est au mieux un indice flou. Au pire, une source de confusion supplémentaire.
La question n’est donc pas « avez-vous des logs ? » (presque tous les systèmes en produisent). La question est « avez-vous des logs exploitables ? ». Et la réponse se prépare aujourd’hui, pas le jour de l’incident.
