Audit trail : définition, exigences, application au vote en ligne.
Un audit trail — ou journal d'audit — est l'enregistrement chronologique, inviolable et exhaustif de tous les événements significatifs d'un système d'information : qui a fait quoi, quand, depuis quelle adresse, avec quel résultat. Cette page expose la définition technique et juridique de l'audit trail, les cinq propriétés qu'il doit présenter pour être opposable, les exigences applicables au vote en ligne (CNIL délibération n° 2019-053 niveaux 2 et 3, référentiel ANSSI RGS, contrôle ISO 27001 A.12.4, article 32 du RGPD, valeur probante eIDAS), et les choix techniques qui distinguent un véritable audit trail d'un simple journal applicatif ou d'un log de debug.
L'audit trail, colonne vertébrale probatoire du vote en ligne.
L'audit trail — littéralement « piste d'audit » — désigne le journal chronologique, signé et inviolable, qui consigne tous les événements significatifs d'un système d'information. Le terme est emprunté à la comptabilité d'origine anglo-saxonne, où la piste d'audit désigne la chaîne ininterrompue qui permet, à partir d'un solde final, de remonter à chaque écriture élémentaire ayant contribué à ce solde. Transposé au système d'information, l'audit trail consigne les authentifications, les ouvertures de session, les actions métier (ouverture d'un scrutin, dépôt d'un bulletin, scellement d'une urne, déchiffrement collégial, signature d'un procès-verbal), les opérations d'administration, les alertes de sécurité, les exports de données et les modifications de paramètres. Cette page distingue précisément l'audit trail du journal applicatif — qui sert au monitoring opérationnel et à la mesure de performance — et du log de debug, qui sert au diagnostic technique des incidents et n'a aucune vocation probatoire. L'audit trail, lui, est conçu pour produire une preuve : il est horodaté par une autorité qualifiée au sens du règlement eIDAS, scellé par signature cryptographique, chaîné par hash de type Merkle pour interdire toute insertion ou modification rétroactive, et archivé sur un support immuable pendant une durée définie par le régime juridique applicable. Pour le vote en ligne, l'audit trail est la seule garantie technique permettant à un juge, à un huissier ou à un expert judiciaire de reconstituer la régularité du scrutin sans rompre l'anonymat des votants. Il est exigé par la délibération de la CNIL n° 2019-053 du 25 avril 2019 portant adoption d'une recommandation relative à la sécurité des systèmes de vote par correspondance électronique, qui en fait l'un des piliers des niveaux de sécurité 2 et 3.
Cinq propriétés qu'un audit trail doit présenter pour être opposable.
Un journal qui ne présente pas ces cinq propriétés n'est pas un audit trail au sens probatoire du terme : c'est, au mieux, un journal applicatif utile à l'exploitation, mais inopérant devant un juge en cas de contestation d'un scrutin.
Cinq étapes pour produire un audit trail opposable.
Mettre en place un audit trail digne de ce nom n'est pas une opération de configuration cosmétique. C'est une démarche d'ingénierie qui mobilise cinq décisions structurantes, auditées dès la conception du système.
Audit trail, journal applicatif, log de debug : trois objets distincts.
Quatre acteurs interagissent avec un audit trail de scrutin.
L'audit trail n'a pas un destinataire unique. Sa conception doit refléter les besoins distincts de quatre rôles, chacun ayant un niveau d'accès et un usage propre.
Configure le périmètre des événements, supervise la santé du dispositif de journalisation, garantit l'intégrité technique de la chaîne (horodatage, scellement, archivage). N'a pas accès en lecture aux événements à valeur probatoire dans un mode d'exploitation normal.
Consulte l'audit trail pour vérifier la conformité du système aux référentiels applicables (ISO 27001, ANSSI RGS, RGPD). Émet un rapport d'audit indépendant. La consultation elle-même est consignée dans l'audit trail.
Reçoit l'export signé de l'audit trail à l'issue du scrutin et le joint au procès-verbal. Peut le consulter pendant le scrutin pour s'assurer du bon déroulement. Vérifie indépendamment l'intégrité de la chaîne sans dépendre de Sephos.
Mobilise l'audit trail en cas de contestation pour reconstituer l'enchaînement des faits. Sollicite l'export complet, vérifie la chaîne cryptographique et l'horodatage, conclut sur la régularité ou l'irrégularité du scrutin sans rompre l'anonymat des votants.
Douze points à vérifier sur l'audit trail de votre scrutin.
La liste de contrôle que nos équipes parcourent avec chaque DPO ou RSSI au moment de la mise en production. Sephos couvre par défaut l'intégralité de ces points ; cette liste vous permet de les valider et de les faire valider par votre propre direction de la conformité.
- Périmètre des événements documenté et validé par le DPO
- Format normalisé auto-descriptif (JSON structuré ou CEF)
- Horodatage qualifié eIDAS sur chaque entrée ou bloc
- Hash chaîné de type Merkle entre entrées successives
- Signature cachet électronique qualifié périodique
- Archivage sur support immuable (WORM ou équivalent crypto)
- Matrice d'accès en lecture documentée et opposable
- Consultation de l'audit trail elle-même journalisée
- Données personnelles minimisées au sens de l'article 5 du RGPD
- Durée de conservation alignée sur le régime juridique applicable
- Procédure d'export signé documentée et testée
- Vérification périodique d'intégrité avec rapport horodaté
Tous les régimes applicables à l'audit trail de scrutin.
L'audit trail d'un système de vote en ligne est encadré par une superposition de textes français et européens. Aucun ne le définit de bout en bout : sa conception sérieuse exige de les composer.
Recommandation relative à la sécurité des systèmes de vote par correspondance électronique. Définit trois niveaux de sécurité (1, 2, 3) selon les risques pesant sur le scrutin. Les niveaux 2 et 3 exigent un journal d'audit complet, intègre, signé et conservé. Le niveau 3 impose explicitement l'horodatage qualifié et le scellement cryptographique. Sephos est nativement aligné niveau 2 et activable au niveau 3.
Le référentiel général de sécurité de l'ANSSI fixe les règles applicables aux systèmes d'information de l'administration et des opérateurs de services essentiels. Sa section sur les fonctions de journalisation impose la collecte horodatée, l'intégrité par signature et la conservation pluriannuelle. L'ANSSI publie en outre un guide spécifique « journalisation » qui détaille les événements à consigner.
Le contrôle A.12.4 de la norme ISO 27001:2022 impose la mise en place d'un système de journalisation des événements (A.12.4.1), la protection des journaux contre la falsification (A.12.4.2), la journalisation des actions d'administration (A.12.4.3) et la synchronisation horaire fiable (A.12.4.4). Sephos applique ces quatre sous-contrôles par défaut sur l'ensemble de son périmètre.
L'article 32 du règlement (UE) 2016/679 impose aux responsables de traitement et aux sous-traitants la mise en œuvre de mesures techniques et organisationnelles appropriées, dont la capacité à garantir la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes. Un audit trail probant est l'un des moyens structurants de démontrer cette intégrité. L'article 5.1.f sur la sécurité des données renforce cette exigence.
Le règlement eIDAS organise la reconnaissance transfrontière des services de confiance qualifiés : signature électronique, cachet électronique, horodatage électronique. Un audit trail horodaté par une Time Stamping Authority qualifiée et scellé par un cachet électronique qualifié bénéficie d'une présomption de fiabilité directement opposable devant les juridictions de l'Union européenne (article 41).
Standard technique IETF définissant le format des jetons d'horodatage cryptographique. Le RFC 3161 spécifie la structure ASN.1 des jetons, le protocole d'émission par une TSA et les mécanismes de vérification. Sephos émet et consomme exclusivement des jetons RFC 3161 conformes, garantissant l'interopérabilité avec tout outil de vérification tiers.
Six dispositifs cryptographiques garantissent l'audit trail Sephos.
L'audit trail d'un scrutin Sephos ne repose pas sur la bonne foi de la plateforme. Il repose sur six dispositifs cryptographiques cumulatifs, vérifiables indépendamment par tout tiers autorisé.
Six difficultés récurrentes dans la gestion d'un audit trail.
Concevoir un audit trail probant est une chose. L'exploiter à l'échelle, sur plusieurs années et plusieurs centaines de scrutins en est une autre. Voici les six points de friction les plus fréquents que nos équipes voient revenir en audit d'organisation.
Un scrutin de 10 000 votants peut générer plusieurs centaines de milliers d'événements consignés. La volumétrie cumulée sur plusieurs années devient significative et exige une architecture de stockage dimensionnée.
Conserver un journal lisible et vérifiable pendant dix ans suppose une stratégie de migration de support, une garantie de pérennité des formats et une vérification périodique d'intégrité — autant de tâches sous-estimées au moment de la mise en production.
Pendant la fenêtre de vote, plusieurs centaines d'événements par seconde peuvent arriver à journaliser. L'horodatage qualifié, qui suppose un aller-retour avec une TSA externe, doit être bufférisé pour ne pas dégrader l'expérience utilisateur.
L'audit trail contient nécessairement des données personnelles (identifiants des votants, adresses IP, empreintes navigateur). L'article 5 du RGPD impose la minimisation et la limitation de durée — l'arbitrage entre valeur probante et minimisation exige une analyse cas par cas.
Définir qui peut consulter quoi, dans quelles circonstances et avec quel niveau de détail, est une question politique autant que technique. Une matrice trop large expose à des fuites ; trop stricte, elle empêche l'exercice du contrôle indépendant.
Vérifier l'intégrité d'un audit trail de plusieurs centaines de milliers d'entrées suppose des outils dédiés. Sephos publie un vérificateur indépendant open source, mais peu d'organisations savent qu'il existe et l'utilisent en routine.
Cinq erreurs que Sephos neutralise par construction.
Les défaillances d'audit trail observées dans les contentieux convergent vers cinq erreurs structurelles. Sephos les élimine par défaut.
Un journal stocké en clair sur un système de fichiers classique est modifiable par tout administrateur. Sephos applique un hash chaîné Merkle et un scellement TSP — toute modification rétroactive devient cryptographiquement détectable.
Un horodatage généré par l'horloge du serveur n'est ni opposable juridiquement ni protégé contre la manipulation par l'administrateur. Sephos utilise exclusivement des jetons RFC 3161 émis par une TSA qualifiée eIDAS.
Conserver un audit trail dix ans sans scellement périodique expose à la perte progressive de preuve : la révocation d'une TSA, la péremption d'un certificat ou la migration d'un support peuvent rendre la vérification impossible. Sephos rescelle automatiquement à chaque échéance.
Consigner systématiquement le User-Agent complet, l'empreinte navigateur ou des données techniques détaillées rompt le principe de minimisation du RGPD. Sephos hash ou pseudonymise ces données lorsqu'elles ne sont pas strictement nécessaires à la valeur probante.
Oublier de consigner un type d'événement (par exemple les modifications de paramètres en cours de scrutin) crée un angle mort exploitable lors d'une contestation. Sephos documente l'intégralité du périmètre et soumet la liste à validation conjointe DPO/RSSI avant chaque mise en production.
Une fédération nationale, contestation devant le tribunal judiciaire.
Le dossier complet — export brut, jetons d'horodatage, signature cachet, rapport du vérificateur — a tenu sur un support archivé conforme. L'organisation n'a pas eu à mobiliser son équipe technique : l'export et la vérification sont des fonctions natives de la plateforme. La fédération a documenté ce cas dans sa procédure interne de gestion des contentieux et l'a transmise à l'ensemble de ses ligues régionales comme cas de référence.
Trois objections fréquentes, trois réponses documentées.
« Les logs applicatifs suffisent, pas besoin d'audit trail dédié. »
Les logs applicatifs sont conçus pour le monitoring opérationnel. Ils ne sont ni horodatés qualifié, ni scellés cryptographiquement, ni conservés sur support immuable. Devant un juge, un log applicatif n'a pas valeur probante : il peut avoir été modifié par l'administrateur, tronqué par rotation, ou simplement contredit par un autre log issu d'un autre composant. L'audit trail répond à un cahier des charges distinct, explicitement défini par la délibération CNIL n° 2019-053 et la norme ISO 27001 A.12.4.
Lire la délibération CNIL 2019-053« Un audit trail signé eIDAS est une sur-spécification pour un petit scrutin. »
Le coût marginal de l'audit trail qualifié, rapporté à un scrutin, est de l'ordre de quelques centimes par votant. Le coût d'une contestation judiciaire est sans commune mesure — frais d'avocat, expertise, mobilisation des équipes, potentielle annulation du scrutin et obligation de le rejouer. La proportionnalité plaide pour la qualification, pas contre. Sephos active l'horodatage qualifié et le scellement TSP par défaut sur l'ensemble de ses scrutins, indépendamment du nombre de votants.
Voir la grille tarifaire« Conserver dix ans de logs est incompatible avec le RGPD. »
L'article 5.1.e du RGPD autorise la conservation sur des durées prolongées dès lors qu'elle est « nécessaire au respect d'une obligation légale » ou « à la constatation, à l'exercice ou à la défense de droits en justice » (article 17.3.e). L'audit trail d'un scrutin entre clairement dans cette catégorie. La minimisation est appliquée à la collecte (pas de données personnelles superflues) et la conservation est documentée dans le registre du responsable de traitement.
Six raisons d'exiger un audit trail probant pour vos scrutins.
Un audit trail conforme n'est pas un raffinement technique. Il est la condition pour défendre la régularité d'un scrutin en cas de contestation et pour démontrer la conformité de l'organisation aux référentiels applicables.
Le journal horodaté qualifié et scellé eIDAS bénéficie d'une présomption de fiabilité directe devant les juridictions de l'Union européenne (article 41 du règlement eIDAS).
Le décompte d'un scrutin chiffré peut être ré-exécuté à partir de l'audit trail et des bulletins archivés, avec une preuve cryptographique de cohérence avec le résultat initial.
Un expert judiciaire désigné peut vérifier indépendamment l'intégrité de la chaîne sans dépendre de Sephos. Le vérificateur open source fonctionne hors plateforme.
Le périmètre, le format et la conservation respectent par défaut les exigences des niveaux 2 et 3 de la délibération CNIL n° 2019-053 sur le vote électronique par correspondance.
Les observateurs habilités peuvent consulter l'audit trail pendant le scrutin et en récupérer l'export signé à son issue. La transparence ne repose pas sur la confiance accordée à l'organisateur.
Pendant toute la durée de conservation, le journal reste vérifiable. La preuve du résultat ne dépend pas de la mémoire d'un témoin ou de la conservation d'un PV papier.
Définition, propriétés, cadres, application au vote en ligne.
Définition de l'audit trail — origines comptables et SI
Le terme audit trail — littéralement « piste d'audit » — naît dans la comptabilité d'origine anglo-saxonne. Il désigne d'abord la chaîne ininterrompue d'écritures comptables qui permet, à partir d'un solde inscrit dans les états financiers, de remonter à chaque écriture élémentaire ayant contribué à ce solde, jusqu'au document justificatif d'origine. La règle, codifiée notamment par le Plan comptable général français et par les normes internationales IFRS, exige que cette piste soit ininterrompue, complète et conservée pendant la durée légale de prescription fiscale. Le concept est transposé dans les années 1980 aux systèmes d'information sous l'impulsion des premiers référentiels d'audit informatique (CobiT, ISACA). L'audit trail informatique désigne alors l'enregistrement chronologique, signé et inviolable, de tous les événements significatifs d'un système d'information, permettant à un auditeur de reconstituer a posteriori l'enchaînement des actes significatifs sans dépendre de la coopération de l'administrateur du système. Aujourd'hui, l'audit trail est exigé par la quasi-totalité des référentiels de sécurité et de conformité (ISO 27001 A.12.4, NIST SP 800-92, ANSSI RGS, PCI-DSS req. 10) et constitue un pilier de la défense en profondeur. Pour le vote électronique, il devient la pièce maîtresse de la valeur probante du scrutin.
Différence avec le journal applicatif et le log technique
L'erreur la plus fréquente consiste à confondre l'audit trail avec le journal applicatif ou le log de debug. Ces trois objets coexistent dans un même système mais répondent à des finalités distinctes. Le journal applicatif sert au monitoring opérationnel : il consigne les requêtes entrantes, les temps de réponse, les taux d'erreur, les volumétries. Il alimente les tableaux de bord de l'équipe d'exploitation et les alertes de supervision. Sa rotation typique est de 7 à 90 jours, et son contenu peut être verbeux. Le log de debug, lui, sert au diagnostic technique des incidents : il consigne les stack traces, les variables internes, les états intermédiaires de traitement. Sa conservation est très courte (24 à 72 heures généralement) et son contenu peut inclure des données techniques sensibles (tokens, headers, requêtes brutes) qui doivent être épurées régulièrement. L'audit trail répond à une troisième finalité, étrangère aux deux premières : produire une preuve juridique opposable. Il ne consigne pas tout indistinctement, mais uniquement les événements à valeur probatoire — authentifications, actions métier significatives, modifications de paramètres, alertes de sécurité. Son format est normalisé, son horodatage est qualifié au sens eIDAS, sa chaîne est scellée cryptographiquement, sa conservation est alignée sur le régime juridique applicable (typiquement cinq à dix ans). Confondre les trois conduit, dans le meilleur des cas, à une explosion de la volumétrie et des coûts ; dans le pire, à une absence de preuve opposable le jour où elle est requise.
Les cinq propriétés d'un audit trail conforme
Pour être opposable, un audit trail doit cumulativement présenter cinq propriétés. La chronologie absolue exige que chaque événement soit horodaté par une autorité de confiance indépendante du système journalisé — en pratique, une Time Stamping Authority qualifiée eIDAS émettant des jetons conformes au RFC 3161. L'inviolabilité exige que toute modification rétroactive soit cryptographiquement détectable, ce qui suppose un hash chaîné de type Merkle entre entrées successives et un scellement périodique par signature cachet électronique qualifié. L'exhaustivité exige que tous les événements significatifs soient consignés sans exception, selon un périmètre documenté à l'avance et validé par le DPO et le RSSI. L'accessibilité contrôlée exige que les parties habilitées — organisateur, bureau de vote, observateurs, autorité de contrôle, expert judiciaire — puissent consulter le journal selon une matrice de droits explicite, la consultation elle-même étant journalisée. L'archivage long terme exige enfin que le journal reste lisible, vérifiable et signé pendant toute la durée légale applicable, avec migration de support contrôlée et vérification périodique d'intégrité. La défaillance d'une seule de ces propriétés suffit à fragiliser l'opposabilité de l'ensemble.
Chronologie absolue — horodatage qualifié eIDAS
L'horodatage est l'opération qui associe à un événement une date et une heure certaines, opposables devant un tiers. L'horodatage interne — celui qui repose sur l'horloge du serveur, synchronisée par NTP avec une source publique — est précis pour l'exploitation mais n'a pas de valeur probante : il peut être manipulé par l'administrateur du serveur, désynchronisé par incident réseau, ou simplement contesté faute de tiers garant. L'horodatage qualifié au sens du règlement eIDAS (article 42) repose sur l'intervention d'une Time Stamping Authority listée dans la Trust List européenne, qui émet pour chaque événement un jeton cryptographique conforme au RFC 3161. Le jeton contient le hash de l'événement horodaté, la date et l'heure certifiées par la TSA, et la signature de la TSA elle-même. Il est vérifiable indépendamment de la TSA et reste opposable même après révocation ultérieure du certificat de la TSA, à condition d'avoir été ancré périodiquement par re-horodatage ou ancrage externe. Pour un audit trail de scrutin, l'horodatage est appliqué soit à chaque entrée individuelle (modèle dit « per-event »), soit à des blocs d'entrées agrégées (modèle « batch »). Le modèle batch, retenu par Sephos, permet de soutenir des débits élevés pendant la fenêtre de vote tout en garantissant une opposabilité indistinguable du modèle per-event. Voir la page horodatage eIDAS pour le détail technique du protocole.
Inviolabilité — hash chaîné Merkle et signatures
L'inviolabilité d'un audit trail repose sur deux dispositifs cumulatifs : le hash chaîné et le scellement par signature. Le hash chaîné consiste à inclure dans chaque entrée du journal le hash cryptographique de l'entrée précédente, formant une chaîne où chaque modification rétroactive d'une entrée casse mécaniquement le hash de toutes les entrées suivantes. Sephos utilise l'algorithme SHA-256, choisi pour son équilibre entre résistance cryptographique et performance d'ingestion. La structure est en réalité un arbre de Merkle : les entrées sont regroupées en feuilles, dont les hashes sont combinés par paires jusqu'à produire une racine unique. Cette racine résume cryptographiquement l'intégralité du journal et permet de prouver l'appartenance d'une entrée donnée à la chaîne sans divulguer le reste — propriété précieuse lorsque seul un extrait du journal est requis pour une procédure. La racine est ensuite signée périodiquement par un cachet électronique qualifié au sens eIDAS, attribué à l'organisation responsable du traitement. Le cachet permet à un tiers de vérifier, à partir de la seule racine signée et de l'extrait pertinent, que la chaîne n'a pas été altérée. Sephos publie en option la racine sur un ancrage externe (typiquement une chaîne publique ou un journal de transparence) pour renforcer l'opposabilité à très long terme. Cette architecture rend toute modification rétroactive non seulement détectable, mais traçable jusqu'à l'entrée modifiée.
Exhaustivité — quels événements consigner pour un vote
Le périmètre des événements à consigner dans l'audit trail d'un scrutin se construit en amont de la mise en production. Sephos documente par défaut entre 25 et 40 types d'événements selon la complexité du scrutin. La liste minimale comprend : la création du scrutin et l'identité de son créateur, l'ouverture et la clôture de la fenêtre de vote, chaque authentification (réussie et échouée), chaque dépôt de bulletin (avec hash du bulletin chiffré, sans contenu), chaque scellement cryptographique, chaque démarrage de cérémonie de déchiffrement collégial, chaque apport de fragment de clé privée par un membre du bureau, le résultat agrégé déchiffré, la signature du procès-verbal, chaque consultation de l'audit trail par une partie habilitée, chaque export, chaque alerte de sécurité (par exemple une tentative d'authentification anormale), chaque modification de paramètre en cours de scrutin (qui déclenche en outre une procédure de validation renforcée). Chaque événement est sérialisé dans un format auto-descriptif (JSON structuré ou Common Event Format), contient l'identifiant pseudonymisé de l'acteur, le type d'événement, le hash de l'entrée précédente et l'horodatage qualifié. Les données personnelles sont minimisées : l'adresse IP est pseudonymisée, le User-Agent est tronqué à ses informations significatives, aucun contenu de bulletin n'est jamais journalisé en clair. Cette liste est soumise à validation conjointe du DPO et du RSSI de l'organisation cliente avant chaque mise en production et figure dans le registre des activités de traitement.
Cadre CNIL — délibération n° 2019-053, niveaux 2 et 3
La délibération n° 2019-053 du 25 avril 2019 de la Commission nationale de l'informatique et des libertés porte adoption d'une recommandation relative à la sécurité des systèmes de vote par correspondance électronique. Elle remplace la délibération n° 2010-371 antérieure et constitue le texte de référence pour l'ensemble des scrutins professionnels et associatifs français recourant au vote à distance. La recommandation définit trois niveaux de sécurité — 1, 2 et 3 — selon les risques pesant sur le scrutin (impact des enjeux, niveau de menace adverse identifié, taille du corps électoral). Le niveau 1 est réservé aux scrutins à faibles enjeux (typiquement, élections internes d'amicales ou de petites associations) ; il exige un journal d'audit mais ne contraint pas les modalités techniques. Le niveau 2 — applicable à la grande majorité des élections professionnelles, des AG d'association et de copropriété — exige explicitement un journal d'audit complet, intègre, signé et conservé. Le niveau 3 — applicable aux scrutins à très forts enjeux ou exposés à des menaces sophistiquées — ajoute l'exigence d'un horodatage qualifié au sens eIDAS, d'un scellement cryptographique périodique, d'une vérifiabilité indépendante par un tiers de confiance et d'une publication de la racine de la chaîne sur un support indépendant. Sephos est nativement aligné niveau 2 sur l'ensemble de ses scrutins et activable au niveau 3 sur demande, sans modification d'architecture. Voir la page eIDAS pour le détail du règlement européen applicable.
ANSSI — référentiel général de sécurité et guide de journalisation
L'Agence nationale de la sécurité des systèmes d'information publie le référentiel général de sécurité (RGS), qui fixe les règles techniques applicables aux systèmes d'information de l'administration et des opérateurs de services essentiels. Le RGS comporte une section dédiée aux fonctions de journalisation, qui impose la collecte horodatée des événements, l'intégrité du journal par signature ou hash chaîné, et la conservation pluriannuelle. L'ANSSI publie en complément un guide spécifique intitulé « Recommandations de sécurité pour la mise en œuvre d'un système de journalisation », qui détaille les événements à consigner par catégorie (authentification, accès aux données, action d'administration, alerte de sécurité), les formats normalisés à utiliser, les exigences de centralisation (typiquement un SIEM indépendant des systèmes journalisés) et les modalités de protection contre la falsification. Bien que ces documents ne soient pas directement opposables aux opérateurs privés, ils constituent l'état de l'art français reconnu par les juridictions et servent régulièrement de référence en cas d'expertise judiciaire. Sephos a calé son architecture de journalisation sur ces recommandations afin d'en présenter la conformité au premier examen.
ISO 27001 — contrôle A.12.4 « Logging and monitoring »
La norme ISO/IEC 27001:2022 est le référentiel international de management de la sécurité de l'information. Elle est complétée par la norme ISO/IEC 27002:2022 qui détaille les contrôles techniques et organisationnels. Le contrôle A.12.4 — « Logging and monitoring » — fixe quatre exigences cumulatives. A.12.4.1 « Event logging » impose la mise en place d'un système de journalisation des événements consignant les activités des utilisateurs, les exceptions, les fautes et les événements de sécurité. A.12.4.2 « Protection of log information » impose la protection des journaux contre la falsification et l'accès non autorisé — c'est sur ce contrôle que repose l'exigence de hash chaîné et de scellement. A.12.4.3 « Administrator and operator logs » impose la journalisation spécifique des actions des administrateurs et opérateurs, qui doivent être elles-mêmes contrôlées indépendamment. A.12.4.4 « Clock synchronisation » impose la synchronisation horaire fiable de l'ensemble des systèmes journalisés sur une source de référence — c'est sur ce contrôle que se greffe le recours à l'horodatage qualifié eIDAS. L'ensemble de ces contrôles est audité périodiquement par un organisme certifié indépendant dans le cadre de la certification ISO 27001 de l'organisme exploitant. Sephos est en cours de certification ISO 27001 sur son périmètre cœur ; les contrôles A.12.4 sont audités à chaque cycle.
Audit trail et RGPD — minimisation et durée
L'audit trail d'un système de vote contient nécessairement des données à caractère personnel : identifiants des votants, adresses IP, empreintes navigateur, horodatages d'actions individuelles. Il est donc soumis aux principes du règlement (UE) 2016/679 (RGPD). Deux principes structurent l'arbitrage entre valeur probante et protection des personnes : la minimisation et la limitation de durée. La minimisation (article 5.1.c) impose de ne collecter que les données « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités ». Pour un audit trail, cela signifie pseudonymiser systématiquement l'identifiant du votant, hash ou tronquer les informations techniques (User-Agent, IP), et n'inclure aucun contenu de bulletin en clair. La limitation de durée (article 5.1.e) impose de ne pas conserver les données « pendant une durée n'excédant pas celle nécessaire au regard des finalités ». Pour l'audit trail, la durée est justifiée par deux dispositions de l'article 17 du RGPD : l'article 17.3.b (« respect d'une obligation légale » — typiquement la délibération CNIL 2019-053 ou les durées de mandat applicables) et l'article 17.3.e (« à la constatation, à l'exercice ou à la défense de droits en justice » — qui couvre la durée de prescription des actions en nullité d'un scrutin). Sephos applique par défaut une conservation de dix ans, justifiée dans le registre des activités de traitement et notifiée aux votants dans la politique de confidentialité du scrutin.
Archivage long terme — cinq ans minimum, dix ans par défaut
La conservation d'un audit trail au-delà de quelques mois soulève des défis techniques propres. Trois enjeux structurent l'archivage long terme. D'abord, la pérennité du format : un journal au format JSON structuré, accompagné de son schéma d'interprétation, reste lisible indéfiniment ; un journal au format binaire propriétaire risque de devenir illisible avec l'évolution des outils. Sephos publie le schéma de ses entrées d'audit et le maintient en compatibilité ascendante. Ensuite, la pérennité de l'horodatage : la validité d'un jeton RFC 3161 dépend de la validité du certificat de la TSA émettrice ; au-delà de la durée de validité du certificat (typiquement quelques années), une procédure de re-horodatage ou d'ancrage externe est nécessaire pour préserver l'opposabilité. Sephos rescelle automatiquement la racine de l'arbre Merkle à chaque échéance, conformément aux préconisations ETSI EN 319 421. Enfin, la pérennité du support : un stockage WORM (Write Once Read Many) garantit l'immuabilité du contenu, mais la durée de vie physique des supports impose une migration contrôlée. Sephos réplique l'audit trail sur plusieurs supports indépendants hébergés sur l'infrastructure souveraine OVH Cloud, avec vérification trimestrielle d'intégrité et plan de migration documenté. La conservation par défaut est de dix ans, ce qui couvre l'intégralité des régimes juridiques applicables aux scrutins internes français, et peut être étendue contractuellement.
Contre-expertise judiciaire — comment l'audit trail prouve
La valeur d'un audit trail se mesure le jour où il est mobilisé devant un juge. La procédure type, observée dans les contentieux de scrutins internes, se déroule en quatre temps. Premier temps : à la réception d'une assignation contestant la régularité d'un scrutin, l'organisation responsable sollicite auprès de Sephos l'export signé de l'audit trail. L'export est produit sous quarante-huit heures, accompagné de l'ensemble des jetons d'horodatage et de la signature cachet eIDAS. Deuxième temps : le tribunal désigne un expert judiciaire — typiquement un informaticien inscrit sur la liste des experts près la cour d'appel — qui prend en charge la vérification technique. L'expert utilise le vérificateur indépendant publié par Sephos (open source, fonctionnant hors plateforme), vérifie successivement l'intégrité de la chaîne Merkle, la validité de chaque jeton d'horodatage auprès de la TSA, la signature cachet finale. Troisième temps : l'expert établit un rapport circonstancié constatant la régularité ou les irrégularités relevées. Quatrième temps : le tribunal tranche au vu du rapport. La jurisprudence converge vers le principe selon lequel un audit trail cryptographiquement scellé et horodaté qualifié bénéficie d'une présomption de fiabilité que seule la démonstration d'une faille cryptographique avérée peut renverser. Voir la page sur le procès-verbal de scrutin pour l'articulation entre audit trail et PV signé eIDAS.