Le fonctionnement technique, en détail
Cette page s'adresse aux développeurs, experts techniques et conseils en PI qui veulent vérifier le mécanisme de bout en bout. Version grand public : la page « Comment ça marche ».
1. Empreinte SHA-256, calculée côté client
Au dépôt, le fichier est haché en SHA-256 directement dans le navigateur (WebAssembly, lecture en flux par blocs de 8 Mo — les fichiers de plusieurs Go ne saturent pas la mémoire). Le fichier ne fait l'objet d'AUCUN téléversement : seuls l'empreinte (64 caractères hexadécimaux), le nom, la taille et le type MIME sont transmis à l'API.
Propriétés utiles au dossier de preuve : déterminisme (le même fichier produit toujours la même empreinte), effet avalanche (un octet modifié change l'empreinte du tout au tout), résistance à la préimage (l'empreinte ne révèle rien du contenu) et résistance aux collisions (aucune collision SHA-256 n'est publiquement connue à ce jour).
2. Preuve n° 1 — jeton d’horodatage RFC 3161
L'empreinte est soumise à une autorité d'horodatage (TSA) conforme à la RFC 3161 : requête TSQ construite sur le condensat SHA-256, réponse TSR signée par l'autorité, incluant l'heure UTC certifiée et le certificat de la TSA. Autorité primaire : freeTSA.org ; repli automatique : DigiCert. Le jeton .tsr est stocké avec le dépôt et téléchargeable dans le dossier de preuve.
Vérification indépendante (OpenSSL) : « openssl ts -reply -in DEPOT.tsr -text » pour lire le jeton (statut, heure, autorité), puis « openssl ts -verify -digest <empreinte_hex> -in DEPOT.tsr -CAfile cacert.pem » avec le certificat racine de l'autorité pour valider la signature. Une TSA indisponible ne bloque jamais un dépôt : le jeton est obtenu en différé et l'ancrage Bitcoin reste la preuve principale.
3. Preuve n° 2 — ancrage Bitcoin via OpenTimestamps
L'empreinte est soumise aux serveurs calendriers publics du protocole ouvert OpenTimestamps (alice.btc.calendar, bob.btc.calendar, finney.calendar, catallaxy). Les calendriers agrègent les empreintes reçues dans un arbre de Merkle dont la racine est ancrée dans une transaction Bitcoin (champ OP_RETURN). Le fichier .ots remis contient le chemin cryptographique complet : empreinte → opérations (append/prepend/sha256) → racine → attestation de bloc.
À la confirmation (typiquement 1 à 3 h), notre worker « upgrade » le .ots pour y intégrer l'attestation définitive avec le numéro de bloc ; le statut public passe à « ancré », avec numéro et heure du bloc. Précision temporelle : l'horodatage Bitcoin est celui du bloc (tolérance de protocole d'environ ± 2 h) — c'est la complémentarité avec le jeton RFC 3161, précis à la seconde, qui donne au faisceau sa force.
Vérification indépendante, sans nos serveurs : glisser fichier + .ots sur opentimestamps.org, ou en CLI « ots verify -f fichier depot.ots ». La preuve reste vérifiable même si Certified Date disparaît : elle ne dépend que du protocole ouvert et de la chaîne Bitcoin.
4. Dépôts multi-fichiers : le manifeste
Pour un dossier complet, chaque fichier est haché individuellement côté client, puis un manifeste JSON canonique est construit : { "v": 1, "files": [{ "path", "size", "sha256" }…] }. C'est l'empreinte SHA-256 de ce manifeste qui est scellée (RFC 3161 + Bitcoin). Le serveur vérifie que l'empreinte reçue correspond bien au manifeste transmis avant d'accepter le dépôt.
Intérêt probatoire : produire UNE pièce (fichier + sa ligne du manifeste + le manifeste scellé) prouve son antériorité sans divulguer les autres pièces — utile pour préserver le secret des affaires en procédure. Le certificat liste chaque pièce avec son empreinte propre.
5. Versions chaînées et registre public
Un dépôt peut référencer un dépôt parent : la chronologie de versions (codes, dates, empreintes) est affichée sur la page publique de vérification — un journal de création horodaté, pièce par pièce. Chaque dépôt est par ailleurs inscrit au registre public interne (numéro, date, empreinte, état des scellés), consultable par quiconque sans compte.
6. Modèle de preuve et limites — sans marketing
Ce que le dispositif établit : un contenu exactement identique au fichier présenté existait au plus tard aux dates certifiées par les deux scellés. Ce qu'il n'établit PAS : la paternité (le certificat nomme un déposant et des co-auteurs déclarés), ni la licéité du contenu, ni l'issue d'un litige — le juge apprécie librement. La preuve exige la conservation du fichier original strictement identique : sans lui, l'empreinte seule ne permet aucune reconstitution.
Surface de confiance : le hachage s'exécute dans votre navigateur (code auditable via les sources de la page) ; les scellés sont émis par des tiers (TSA, chaîne Bitcoin) ; la vérification complète est possible sans aucune interaction avec nos serveurs. Notre base de données n'est PAS un maillon de confiance de la preuve.