Qu'est-ce qu'une preuve d'existence ?

Une preuve d'existence est un moyen de démontrer que des données précises existaient au plus tard à un instant donné, en s'appuyant sur un horodatage public que chacun peut vérifier.

La méthode est simple. On hache les données, on publie cette empreinte dans un record public horodaté, puis toute personne disposant des données d'origine peut recalculer l'empreinte et la comparer à celle du record. Si les deux empreintes correspondent, le vérificateur sait que les mêmes octets existaient au plus tard au moment de ce record. Il n'a pas à vous faire confiance, ni à votre serveur, ni à votre compte — seulement au record public et aux mathématiques.

Le fichier lui-même n'a jamais besoin d'être public. La preuve peut être publique alors que le contenu reste privé.

Que prouve une preuve d'existence ?

Elle prouve une affirmation unique, restreinte et utile :

Ces octets exacts existaient au plus tard à cet instant public.

C'est tout ce que la preuve de base affirme — et sa force vient justement de son caractère étroitement délimité.

Presque tout peut être réduit à une empreinte cryptographique : un document, une image, une vidéo, un jeu de données, une archive de code source, un artefact de build, un contrat, un fichier de journal, une sortie de modèle ou un manifeste. L'empreinte est un court condensé d'une séquence d'octets bien précise. Modifiez un seul octet et l'empreinte change entièrement.

Lorsque cette empreinte est ancrée dans un record public, le record devient un témoin temporel. Plus tard, si vous présentez à quelqu'un le fichier d'origine, cette personne le hache à nouveau. Si la nouvelle empreinte correspond à celle enregistrée, elle peut confirmer que le fichier qu'elle a sous les yeux est bien la même donnée que celle engagée auparavant — à la date de l'horodatage du record, ou avant.

C'est ce qui rend la preuve d'existence précieuse dès que la chronologie compte :

• démontrer qu'un fichier existait avant un litige ;
• démontrer qu'un rapport existait avant une échéance d'audit ;
• démontrer qu'un artefact logiciel existait au moment de la mise en production ;
• démontrer qu'un instantané de jeu de données existait avant sa modification ;
• démontrer qu'une sortie d'IA, un jeu de prompts ou un fichier multimédia existait avant d'être contesté.

La preuve n'est pas une description du fichier. C'est un engagement cryptographique sur ses octets exacts.

Pourquoi le fichier n'a-t-il pas besoin d'être public ?

Parce que ce qui est rendu public, c'est l'empreinte, pas le fichier.

Une bonne fonction de hachage fonctionne comme une empreinte à sens unique. Quiconque peut calculer l'empreinte à partir du fichier, mais une personne qui ne voit que l'empreinte ne peut pas reconstituer le fichier à partir d'elle. C'est pourquoi un document privé peut porter une preuve publique : le record dit « quelqu'un s'est engagé sur ces octets exacts à cet instant » sans dévoiler les octets.

Par exemple, une entreprise peut hacher le manifeste d'un jeu de données confidentiel et n'en publier que l'empreinte. Le jeu de données reste privé. Plus tard, si l'entreprise doit prouver ce que contenait l'instantané, elle peut révéler le manifeste complet, un sous-ensemble de celui-ci, ou une preuve d'inclusion portant sur un seul élément — selon ce que la situation exige.

C'est aussi pour cela que la preuve d'existence convient aux équipes juridiques, de conformité et de sécurité : elle crée un horodatage externe sans verser de pièces confidentielles dans une base de données publique. Pour un examen plus approfondi de ce schéma, voir la divulgation confidentielle sans fichiers publics.

Quel rôle joue la blockchain ?

La blockchain est le témoin temporel public — la partie que personne, pas même l'éditeur, ne peut discrètement réécrire.

Si une empreinte ne réside que dans votre propre base de données, la preuve dépend entièrement de votre système. Lorsque l'horodatage est contesté par la suite, on peut raisonnablement se demander si la base de données a été réécrite, restaurée à partir d'une sauvegarde, modifiée par un administrateur ou antidatée. Une blockchain publique lève ce doute. Une fois une transaction confirmée, le record horodaté est visible par tous et n'est plus sous le seul contrôle de l'éditeur.

Pour CardanoWall, le record de preuve est ancré dans les métadonnées d'une transaction Cardano, sous le label de métadonnées 309. Un vérificateur récupère la transaction depuis l'explorateur Cardano public de son choix, lit le record et compare l'empreinte du contenu aux octets d'origine. Aucun serveur CardanoWall n'intervient dans cette vérification — tout l'intérêt est que la preuve tienne sans nous.

La blockchain ne comprend pas votre document, et elle n'en a pas besoin. Elle enregistre les données de la preuve ; le sens vient d'un vérificateur qui recalcule l'empreinte et confirme que les octets correspondent.

Quelle est la preuve la plus simple ?

La preuve la plus simple ne contient qu'une empreinte.

Vous choisissez un fichier. Le logiciel calcule une empreinte, par exemple SHA-256 ou BLAKE2b-256. Cette empreinte est placée dans un record publié dans les métadonnées Cardano. Plus tard, un vérificateur répète le calcul de l'empreinte sur le fichier d'origine, et si le condensé correspond, la preuve est validée.

Ce premier niveau se résume donc à trois faits :

1. Le contenu existe.
2. Son empreinte est ancrée sur la chaîne.
3. Toute personne disposant du contenu d'origine peut vérifier la correspondance.

Pour de nombreux usages, cela suffit. Une empreinte horodatée est puissante précisément parce qu'elle est simple — il y a peu de choses à mal configurer et rien à devoir prendre sur parole.

Quand une empreinte ne suffit-elle pas ?

Une empreinte seule répond bien à une question, mais pas à toutes.

Elle ne dit pas qui a créé le fichier. Elle montre seulement que les octets existaient. Si deux personnes détiennent le même PDF public, l'une comme l'autre peut en publier l'empreinte ; l'empreinte seule ne dit rien de la paternité.

Elle ne préserve pas le fichier. Perdez les octets d'origine et il vous reste une empreinte publique, mais vous risquez de n'avoir plus rien à comparer avec elle.

Et elle ne remet le fichier à personne. Si une autre personne a besoin des données d'origine, une empreinte seule ne les lui transmettra pas.

C'est pourquoi le format de record sous-jacent est organisé en couches. Un record qui ne contient qu'une empreinte est parfaitement valide, mais le standard prend aussi en charge les signatures, les contenus scellés (chiffrés), la remise adressée à un destinataire et le regroupement Merkle — chacun ajoutant une capacité par-dessus l'horodatage.

En quoi une signature modifie-t-elle la preuve ?

Une signature ajoute une affirmation adossée à une clé.

Un record signé dit plus que « ces octets existaient avant cet instant ». Il peut aussi dire « cette clé a signé ce record ». Cela compte pour la paternité, les approbations, les contrôles internes et les processus métier : une organisation peut utiliser une clé de signature pour montrer qu'un système, une équipe ou une identité précise s'est portée garante d'un record, et un créateur peut signer une preuve pour associer son identité à une œuvre.

La formulation doit toutefois rester précise. Une signature montre que la clé a signé le record — pas qui, dans le monde réel, détient cette clé. Rattacher une clé à une personne dépend d'un contexte établi en dehors du record. (CardanoWall garde les signatures optionnelles par conception ; chacun peut publier, et les vérificateurs n'ont jamais à faire confiance à l'éditeur.)

En quoi le scellement modifie-t-il la preuve ?

Une preuve scellée ajoute une préservation chiffrée.

Dans un record scellé, la preuve sur la chaîne s'engage toujours sur l'empreinte du texte en clair. Mais le fichier lui-même peut être chiffré et stocké à un emplacement adressé par le contenu — une adresse ar:// (Arweave) ou ipfs:// — seule sa référence figurant dans le record. La chaîne ne voit jamais le texte en clair.

Cela compte lorsque la perte du fichier d'origine rendrait l'empreinte difficile à exploiter. Avec une preuve scellée, une personne détenant la bonne clé peut plus tard récupérer le texte chiffré stocké, le déchiffrer, recalculer l'empreinte du texte en clair et confirmer que le fichier déchiffré correspond exactement au contenu engagé sur la chaîne. Comme l'adresse de stockage dérive des octets eux-mêmes, le destinataire peut aussi constater qu'un gateway de stockage a renvoyé les bons octets sans avoir à faire confiance à ce gateway.

La chaîne publique n'a jamais à exposer le texte en clair. Le contenu chiffré voyage avec la preuve tandis que la clé de déchiffrement reste entre les mains de la personne censée la détenir.

En quoi la remise à un destinataire modifie-t-elle la preuve ?

La remise à un destinataire permet de chiffrer un record scellé à l'intention de quelqu'un d'autre.

Si vous connaissez l'adresse de réception d'un destinataire (une clé publique qu'il a partagée), vous pouvez publier un record scellé que lui seul peut ouvrir avec sa propre clé. Fait notable, le record ne contient aucun champ disant « ceci est destiné à Alice ». Il n'y a aucun destinataire sur la chaîne. Le logiciel du destinataire parcourt les records publics et tente discrètement de déchiffrer à l'essai ceux qui pourraient être adressés à ses clés, n'ouvrant que ceux qui le sont réellement.

Cela fait de la preuve d'existence bien plus qu'un simple horodatage personnel. Elle peut prendre en charge la divulgation confidentielle, l'échange de pièces juridiques, les dossiers de conformité privés et les transferts d'audit interne — des processus où la chronologie doit être publique mais le contenu non. Avant de sceller quoi que ce soit à l'intention de quelqu'un, il est toutefois prudent de confirmer que la clé lui appartient réellement ; voir vérifier un destinataire avant de sceller un fichier.

Une limite à reconnaître honnêtement : le chiffrement protège les octets, pas les personnes. Le scellement garde le texte en clair lisible uniquement par les détenteurs de clé, mais il ne garantit pas l'anonymat, et un destinataire peut toujours divulguer le texte en clair une fois qu'il l'a déchiffré.

En quoi le regroupement Merkle modifie-t-il la preuve ?

Le regroupement Merkle permet à un seul record de s'engager sur de nombreux éléments à la fois.

Au lieu d'une transaction par fichier, un système peut hacher des milliers ou des millions d'éléments, replier ces empreintes dans un arbre de Merkle et publier une seule racine de 32 octets. Plus tard, une preuve d'inclusion montre qu'un élément précis faisait partie du lot engagé. Le vérificateur n'a pas besoin de tous les fichiers sur la chaîne : la racine est l'engagement public, et une courte preuve d'inclusion — qui ne croît qu'avec le logarithme de la taille du lot — relie un élément individuel à cette racine. Tous les autres éléments du lot restent privés.

Cela convient aux processus à fort volume :

• artefacts CI/CD et manifestes de version ;
• journaux de conformité quotidiens ;
• contenu généré par IA à grande échelle ;
• instantanés de jeux de données ;
• dossiers de pièces d'audit ;
• archives multimédias et éditoriales.

Le mode Merkle garde le record sur la chaîne minuscule tout en permettant à une seule preuve de couvrir un ensemble énorme d'éléments. Pour un exemple détaillé, voir un seul record pour des milliers de fichiers.

Que ne prouve pas une preuve d'existence ?

C'est la section qui garde la preuve à sa juste mesure. Un engagement horodaté est solide parce qu'il est précis — et cette précision même implique qu'il y a des affirmations qu'il ne fait tout simplement pas.

Elle ne prouve pas qu'un document est vrai. Un document mensonger peut être horodaté aussi facilement qu'un document véridique.

Elle ne prouve pas la propriété. Quiconque peut hacher un fichier qui ne lui appartient pas.

Elle ne prouve pas la paternité à elle seule. La paternité requiert des signatures, une gestion de clés et un contexte réel ajoutés par-dessus.

Elle ne prouve pas qu'un build logiciel est sûr. Elle peut montrer quel artefact, SBOM, journal ou manifeste existait à un instant donné, mais la sécurité dépend du processus de build et des contrôles qui l'entourent.

Elle ne prouve pas qu'un jeu de données a été collecté ou utilisé licitement. Elle peut montrer qu'un engagement sur un jeu de données existait — ce qui peut constituer un élément de preuve important — mais les droits légaux sont une question distincte qui dépend de votre juridiction et de votre conseil juridique.

En résumé : une preuve d'existence vous donne la chronologie et l'intégrité, pas la vérité ni les droits. Toute affirmation supplémentaire doit être construite avec soin sur cette base. Ce qu'une preuve ne prouve pas examine plus en détail où se situe exactement la limite.

Pourquoi CardanoWall s'appuie sur Label 309

Une preuve ne vaut que par sa portabilité. Une preuve qui ne fonctionne qu'au sein d'un seul site web n'en est guère une — une preuve sérieuse doit être lisible par des outils indépendants, vérifiable depuis une infrastructure publique et comprise par des logiciels que le service d'origine n'a jamais écrits.

C'est pourquoi CardanoWall est bâti sur Label 309, un standard ouvert et indépendant des fournisseurs pour la preuve d'existence sur Cardano. C'est Label 309 — et non l'application CardanoWall — qui est l'artefact durable ; l'application web, l'outil en ligne de commande et les SDK en sont des implémentations de référence dérivées. Le standard définit un format de record unique qui s'étend d'un simple horodatage jusqu'aux usages avancés :

• des preuves limitées à une empreinte, pour l'existence simple ;
• des preuves signées, pour des affirmations de paternité adossées à une clé ;
• des preuves scellées, pour une préservation chiffrée ;
• des preuves scellées au destinataire, pour une remise privée ;
• des preuves Merkle, pour les lots à fort volume ;
• des identifiants d'algorithmes nommés, afin que la cryptographie puisse évoluer dans le temps sans casser les records antérieurs.

Le format est aussi soumis à une revue publique : la preuve d'existence sous le label de métadonnées 309 a été soumise au processus CIP de Cardano et est en cours d'examen par les éditeurs CIP en tant que proposition de la catégorie Metadata. (Le label de métadonnées 309 est l'identifiant sur la chaîne ; le numéro de CIP est attribué séparément par le processus.) Le standard complet, ses implémentations de référence et tout le code open source sont publiés publiquement sur github.com/cardanowall sous des licences permissives.

CardanoWall est l'interface. Label 309 est le format de record. La preuve est conçue pour survivre aux deux — l'interface comme l'entreprise qui vous a aidé à la publier.

Pour aller plus loin

• Comment fonctionne Label 309 — le standard derrière chaque preuve CardanoWall.
• Ce qui est inscrit sur la blockchain — exactement quels octets sont publiés, et lesquels ne quittent jamais votre appareil.
• Vérifier un record Label 309 — vérifier une preuve vous-même, à partir de la seule infrastructure publique.
• Comment la preuve d'existence se compare à d'autres systèmes d'horodatage et de provenance : face à OpenTimestamps, face à une autorité d'horodatage, et face à C2PA / Content Credentials.