Notarisation blockchain : ancrer des empreintes de documents pour une preuve indépendante

La notarisation blockchain consiste à inscrire l’empreinte cryptographique d’un document dans une transaction de blockchain publique, de sorte que le consensus de la chaîne et sa preuve de travail deviennent un témoin indépendant que le document existait, dans exactement ces octets, à ce moment. Comme la vérification n’exige que le document, un petit fichier de preuve et les données publiques de la chaîne, la preuve survit à tout fournisseur et n’exige de faire confiance à aucune autorité unique. Ce qu’elle prouve est étroit : l’existence et l’intégrité à un moment donné, pas la paternité, l’exactitude ni l’exécution juridique. C’est le bon outil pour les cas adverses, à long horizon ou publiquement vérifiables; pour les dossiers d’affaires courants, une autorité d’horodatage RFC 3161 ou une base de données disciplinée est plus simple et suffit habituellement.

Cette page explique le mécanisme, les limites honnêtes et un cadre de décision. Elle suppose le vocabulaire du carrefour de la provenance documentaire et s’appuie sur les patrons des documents à preuve d’altération.

Le mécanisme, sans la mystique

Le schéma est antérieur aux blockchains. Haber et Stornetta ont montré en 1991 qu’on peut rendre des horodatages numériques dignes de confiance en chaînant des empreintes de sorte que ni les utilisateurs ni le service d’horodatage ne puisse antidater ou postdater un document; le livre blanc de Bitcoin cite ces travaux et décrit son propre serveur d’horodatage dans les mêmes termes. Une blockchain publique est, entre autres, la chaîne de hachage la plus attestée qui existe, ce qui en fait une ancre commode.

Notariser un document prend quatre étapes :

1. Hacher localement. Calculez SHA-256 sur le document. Seul ce condensé quitte votre machine; le contenu reste privé.
2. Agréger. Engager une transaction blockchain par document serait lent et coûteux, alors les empreintes sont regroupées dans un arbre de Merkle et seule la racine est inscrite. C’est ainsi qu’OpenTimestamps passe à l’échelle : ses serveurs calendrier agrègent un nombre illimité de condensés dans une seule transaction Bitcoin, de sorte que les horodatages individuels sont effectivement gratuits et prennent environ une seconde à créer.
3. Ancrer. La racine de Merkle atterrit dans une transaction; une fois le bloc confirmé, la preuve de travail de la chaîne et chaque bloc subséquent se portent garants.
4. Conserver la preuve. Vous recevez un petit fichier de preuve (un reçu .ots dans OpenTimestamps) contenant le chemin de Merkle de l’empreinte de votre document jusqu’à la racine ancrée. La vérification consiste à recalculer ce chemin et à contrôler l’en-tête de bloc. Une fois la preuve mise à niveau avec le chemin complété, elle est autonome : plus besoin de serveur calendrier, de fournisseur ni de Webisoft.

Le même patron fonctionne sur Ethereum et d’autres chaînes (un événement de contrat ou des calldata portant la racine), avec une confirmation plus rapide et l’option d’une logique de vérification sur chaîne, au prix de frais par transaction et d’un historique de permanence plus jeune. Pour du pur horodatage, Bitcoin plus OpenTimestamps est le choix conservateur par défaut, parce que le standard est ouvert et que les preuves sont indépendantes de tout service.

Ce qu’elle prouve, et ce qu’elle ne prouve pas

La précision ici est ce qui sépare l’ingénierie du marketing.

Prouvé : les octets exacts qui donnent ce condensé existaient au moment du bloc ou avant, et n’ont pas changé depuis (tout changement brise l’empreinte). N’importe qui peut le vérifier de façon indépendante, aujourd’hui ou dans trente ans, à partir de données publiques.

Non prouvé :

• La paternité. La chaîne a vu une empreinte, pas qui a produit le document. Combinez l’ancrage avec des signatures numériques si l’origine compte (voir les documents à preuve d’altération).
• L’exactitude. Une déclaration fausse ancrée sur chaîne est une déclaration fausse avec une date vérifiable.
• L’exclusivité. L’ancrage ne prouve pas que c’est la seule version; quelqu’un peut ancrer dix brouillons contradictoires. La séquence et l’unicité exigent une conception de journal en ajout seul, pas seulement des ancres.
• L’exécution juridique. L’ancrage n’est pas un régime de signature électronique. En vertu du règlement eIDAS de l’UE, c’est l’horodatage électronique qualifié qui bénéficie d’une présomption légale d’exactitude et d’intégrité dans les États membres; une ancre Bitcoin est une preuve admissible que vous devez expliquer à un tribunal, pas une présomption obtenue gratuitement.
• L’heure précise. Les horodatages de bloc sont grossiers. Une confirmation Bitcoin vous donne une certitude de l’ordre de l’heure, pas la précision à la milliseconde de l’horloge d’une TSA. Si « avant 17 h 00 min 00 s le 14 » compte, un jeton de TSA est le bon instrument (utilisez les deux si vous voulez précision et indépendance).

Ancre blockchain vs TSA RFC 3161 vs base de données : la comparaison honnête

Lisez le tableau à froid et la conclusion manque d’éclat, ce qui est le but : la colonne blockchain ne gagne que sur les lignes de la confiance et de la longévité. Si ces lignes ne sont pas votre problème, ce n’est pas votre solution.

Quand l’ancrage blockchain convient réellement

• Vérification adversariale. La personne à convaincre est une contrepartie, une partie adverse en litige ou un régulateur qui n’a aucune raison de faire confiance à vos systèmes ou à vos fournisseurs. Les revendications d’antériorité de propriété intellectuelle, les soumissions d’appels d’offres et les cahiers de laboratoire de recherche sont les cas classiques.
• Des horizons plus longs que les fournisseurs. Les dossiers qui doivent rester vérifiables pendant plus de 20 ans survivent aux TSA, aux plateformes et aux produits. AWS a abandonné sa base de données registre QLDB avec fin du soutien le 31 juillet 2025; une preuve OpenTimestamps autonome n’a aucun fournisseur à perdre.
• Les engagements publics. Publier une empreinte aujourd’hui pour prouver plus tard ce que vous saviez (divulgation responsable, registres de prédictions, versionnage de jeux de données, intégrité de documents publiés).
• Les systèmes multipartites sans arbitre naturel. Les consortiums et chaînes d’approvisionnement où chaque exploitant candidat du journal d’audit est aussi un participant. Ancrer la racine de Merkle du journal partagé neutralise l’avantage de l’exploitant.
• Comme second témoin peu coûteux. Parce que l’ancrage agrégé ne coûte presque rien, ancrer la racine quotidienne de votre journal d’audit aux côtés des jetons de TSA en vaut souvent la peine par pure assurance; c’est la troisième couche de la conception de référence dans les documents à preuve d’altération.

Quand c’est le mauvais outil

• Vous avez besoin d’une présomption légale, pas d’indépendance cryptographique. Dans l’UE, un jeton de TSA qualifiée porte un poids légal qu’une ancre brute n’a pas. Achetez le jeton.
• Tout le monde fait déjà confiance à un exploitant. Archives de conformité internes, pistes d’audit d’une seule entreprise, dossiers qu’un régulateur accepte explicitement de vos systèmes existants : les tables de registre ou un simple journal chaîné par hachage livrent la preuve d’altération sans nouvelles dépendances d’écosystème.
• Vous avez besoin d’horodatages précis ou instantanés. La latence de confirmation et les heures de bloc grossières excluent l’ancrage comme registre principal pour les événements où le temps est critique.
• Le document lui-même doit aller sur la chaîne. Il ne le doit pas. Publier du contenu sur chaîne détruit la confidentialité de façon irrévocable et fait gonfler les coûts; les conceptions correctes ne publient que des condensés. Tout fournisseur qui propose de stocker des documents sur chaîne a mal compris le problème.
• « Blockchain » est l’exigence plutôt que la conclusion. Si la phrase « n’importe qui doit pouvoir vérifier ceci sans nous faire confiance, au-delà de la vie de tout fournisseur » ne décrit pas votre besoin, la colonne plus simple du tableau ci-dessus est votre réponse. Survendre les ancres érode exactement la crédibilité qu’elles existent pour fournir.

Notes d’implémentation tirées du terrain

• Ancrez des racines de Merkle, pas des empreintes brutes de documents, même à volume modeste. Vous y gagnez une amplification de confidentialité (un observateur ne peut même pas compter vos documents), un coût marginal négligeable et un point de regroupement naturel (horaire ou quotidien).
• Traitez les fichiers de preuve comme des dossiers. Un reçu .ots naît incomplet (une promesse des serveurs calendrier) et doit être mis à niveau une fois la transaction Bitcoin confirmée, après quoi il est vérifiable de façon autonome. Automatisez la mise à niveau, stockez les preuves avec les documents qu’elles attestent et incluez-les dans les politiques de rétention et de sauvegarde. Une preuve perdue est un horodatage perdu, même si l’ancre elle-même est permanente.
• Vérifiez selon un calendrier. Intégrez la vérification aux opérations (rehacher, parcourir le chemin de Merkle, contrôler l’en-tête de bloc via votre propre nœud ou plusieurs sources publiques). Une preuve que personne n’a jamais vérifiée tend à échouer la première fois qu’elle compte.
• Prévoyez le vieillissement des algorithmes. Les ancres sont permanentes mais les algorithmes de hachage ne le sont pas; le NIST a retiré SHA-1 après que les collisions sont devenues praticables. Consignez l’algorithme dans votre manifeste et réancrez les archives avec des algorithmes plus récents bien avant la dépréciation.
• Combinez, ne choisissez pas, pour les dossiers à hauts enjeux. Signature (origine) + jeton de TSA qualifiée (temps légal) + ancre de chaîne (longévité indépendante) se composent proprement, et chacun couvre la ligne faible des autres dans le tableau.

Où cela se situe dans un projet Webisoft

En pratique, nous implémentons la notarisation comme une couche mince sur la chaîne à preuve d’altération : les documents sont hachés et journalisés dans un journal de Merkle en ajout seul, et la racine du journal est ancrée selon un calendrier via OpenTimestamps, avec des contresignatures de TSA quand les clients ont besoin d’un temps de calibre eIDAS. Les parties propres à la blockchain (services d’ancrage, garde des preuves, outillage de vérification et composants sur chaîne quand un cas d’usage en a vraiment besoin) s’appuient sur la pratique d’ingénierie blockchain que Webisoft exploite sous sa marque de R et D deepspace.io.

Si vous pesez l’ancrage contre une TSA ou une base de données registre pour un système précis, les ingénieurs de Webisoft conçoivent et construisent des chaînes de notarisation documentaire de bout en bout.