Une chaîne de hachage prouve-t-elle que les données étaient correctes dès le départ ?

Non. Elle prouve seulement que les données n'ont pas été modifiées sans être détectées depuis le début de la chaîne — une observation erronée dès le départ n'en est pas affectée.

Quelle est la différence entre le temps de l'événement et le temps de saisie ?

Le temps de l'événement correspond au moment où quelque chose s'est réellement produit ; le temps de saisie correspond au moment où cela a été enregistré dans le système. En cas de saisie hors ligne, les deux peuvent être nettement décalés.

← Savoir

Event-store bitemporel : comment fonctionne un historique immuable

Un event-store bitemporel enregistre chaque observation comme un événement immuable et horodaté (append-only) et distingue deux axes temporels : le moment où quelque chose s'est réellement produit et le moment où cela a été saisi dans le système. Une chaîne de hachage supplémentaire permet de détecter toute manipulation ultérieure — mais uniquement à partir du moment où la chaîne a commencé, et non rétroactivement pour la période précédente.

Principe de stockage: Append-only (jamais de suppression, jamais d'écrasement)
Axes temporels: 2 (temps de l'événement + temps de saisie)
Mécanisme d'intégrité: Chaîne de hachage
Ancrage externe: OpenTimestamps (quotidien) + horodatage RFC 3161 (hebdomadaire)

Ce que signifient « append-only » et « bitemporel »

Append-only signifie qu'un événement, une fois écrit, n'est jamais supprimé ni modifié — une correction est ajoutée comme un nouvel événement autonome, qui renvoie à l'événement original. Bitemporel signifie que chaque événement porte deux horodatages : le moment où il s'est réellement produit (temps de l'événement) et le moment où il a effectivement été enregistré dans le système (temps de saisie). Cette séparation rend visible le cas où une observation a été rattrapée avec retard (par exemple une saisie hors ligne sur le terrain, synchronisée seulement plus tard), sans fausser le moment d'observation réel.

Ce que la chaîne de hachage prouve — et ce qu'elle ne prouve pas

Chaque nouvel événement contient la valeur de hachage de son prédécesseur. Une modification ultérieure d'un événement antérieur romprait cette chaîne de manière visible. Un point est toutefois déterminant : ce mécanisme ne prouve l'intégrité qu'à partir du moment où la chaîne a effectivement commencé à fonctionner. Pour les événements antérieurs au début de la chaîne, il n'existe aucune garantie cryptographique rétroactive — une chaîne calculée rétroactivement ne prouve rien sur le passé antérieur à son propre point de départ.

Ancrage externe

Afin de protéger la chaîne elle-même contre une manipulation ultérieure, elle est en outre ancrée à l'extérieur : quotidiennement via le protocole gratuit OpenTimestamps et hebdomadairement via un service d'horodatage conforme à la norme RFC 3161. Cela déplace la confiance d'une affirmation interne vers un instant vérifiable de manière externe.

Pour votre entreprise

En pratique, cela signifie qu'une observation saisie sur le terrain sans connexion réseau, synchronisée seulement quelques heures plus tard, conserve son moment d'observation réel — elle n'est pas datée à tort du moment de synchronisation ultérieur.

Pour la collectivité mandante

Un historique append-only est un argument solide, mais non absolu, en faveur de la traçabilité — il ne remplace pas un examen propre de la force probante concrète dans un cas particulier.

Ce que cela ne signifie pas

Le terme « à toute épreuve devant un tribunal » ne fait volontairement pas partie de notre communication (art. 13a LCD) — un tribunal apprécie toujours librement les preuves (art. 157 CPC), une sécurisation technique peut appuyer cette appréciation, mais ne peut pas la remplacer.
La chaîne de hachage ne prouve l'intégrité qu'À PARTIR du début de la chaîne, jamais rétroactivement pour des données antérieures — il s'agit d'une limite délibérée et honnête de la technologie, non d'une affirmation marketing.
Un event-store bitemporel protège contre une modification ultérieure passée inaperçue, pas contre une observation initiale erronée dès le départ.

Questions fréquentes

Une chaîne de hachage prouve-t-elle que les données étaient correctes dès le départ ?: Non. Elle prouve seulement que les données n'ont pas été modifiées sans être détectées depuis le début de la chaîne — une observation erronée dès le départ n'en est pas affectée.
Quelle est la différence entre le temps de l'événement et le temps de saisie ?: Le temps de l'événement correspond au moment où quelque chose s'est réellement produit ; le temps de saisie correspond au moment où cela a été enregistré dans le système. En cas de saisie hors ligne, les deux peuvent être nettement décalés.