2026-09-28 timestamp git blockchain proof

Qu’est-ce que la preuve d’existence pour le code logiciel ?

Pour les développeurs et les équipes de conformité, la « preuve d’existence » ne consiste pas à prouver la propriété ou la paternité. Elle répond à une question précise : ce code exact a-t-il existé à ce moment précis ? Dans un monde où l’historique Git peut être réécrit, où les horodatages de fichiers peuvent être modifiés et où les journaux internes sont souvent écartés comme étant intéressés, la preuve d’existence pour le code logiciel signifie ancrer une empreinte cryptographique de votre travail dans un registre public immuable.

Cet article explique ce que signifie la preuve d’existence, comment elle fonctionne sous le capot, et comment Timestamp GIT la transforme en un workflow GitHub sans configuration.

Que signifie la « preuve d’existence » pour le code ?

La preuve d’existence pour le code logiciel est la capacité de démontrer qu’un morceau de code spécifique — ou, plus précisément, un hachage cryptographique de ce code — existait à un moment précis dans le temps.

Ce dernier point est important. Vous n’avez pas besoin de publier votre code source, ni de le téléverser chez un tiers. Au lieu de cela, vous créez une empreinte à sens unique de l’état du dépôt et vous enregistrez cette empreinte quelque part de public et résistant à la falsification.

Pour comprendre la différence :

La preuve d’existence montre qu’un état de code donné existait à une date donnée.
La preuve de paternité montre qui a créé ou commité ce code.
La preuve de propriété est une conclusion juridique fondée sur la paternité, les contrats de travail, les cessions de droits ou d’autres éléments de preuve.

Un horodatage ancré dans une blockchain ne prouve pas que vous avez écrit le code. Il prouve que le code existait à ce moment-là. Dans de nombreux litiges, cette distinction suffit — car si votre implémentation existait avant le dépôt de brevet ou la revendication de quelqu’un d’autre, la chronologie devient mathématiquement ancrée.

Voici à quoi ressemble l’empreinte dans Git :

# Git crée une empreinte unique pour l'état exact du dépôt
git rev-parse HEAD
# 6f1ed002ab5595859012f3f9b6b4c2b1e1c9a2e5

Ce hachage représente l’état complet du dépôt au moment du commit. Modifiez un seul octet, et le hachage change complètement. Le hachage lui-même ne peut pas être inversé pour révéler votre code source.

Une analogie simple : le notaire et le coffre-fort

Imaginez que vous entrez chez un notaire avec une enveloppe scellée. Le notaire ne l’ouvre pas. Au lieu de cela, il enregistre la date, appose un cachet sur l’extérieur et signe une écriture dans son registre. Des années plus tard, vous pouvez ouvrir l’enveloppe devant un tribunal et montrer que son contenu existait à cette date, car le registre du notaire est indépendant et infalsifiable.

La preuve d’existence pour le logiciel fonctionne de la même manière, sauf que « l’enveloppe » est un hachage cryptographique et que le « notaire » est la blockchain Bitcoin.

Vous gardez le code privé. Le notaire — en l’occurrence, le service d’horodatage et le registre public — ne voit que l’empreinte.
L’enregistrement est indépendant. La blockchain Bitcoin est un registre public qu’aucun fournisseur unique ne contrôle. Une fois qu’une transaction est confirmée dans un bloc, modifier cet enregistrement est informatiquement impraticable.
La preuve survit au fournisseur. Parce que la preuve est ancrée dans Bitcoin, vous pouvez la vérifier même si le service d’horodatage disparaît.

Cette analogie aide les parties prenantes non techniques à comprendre pourquoi un horodatage blockchain est différent d’un journal Git interne. Un journal interne vit sur une infrastructure que vous contrôlez ou louez. Une preuve ancrée dans Bitcoin est publique, immuable et vérifiable indépendamment.

Comment fonctionne la preuve d’existence sous le capot

Le processus peut être décomposé en trois étapes.

Étape 1 : Empreinte

Git effectue déjà la première étape pour vous. Chaque commit reçoit un hachage unique — SHA-1 dans les anciennes versions de Git, avec prise en charge de SHA-256 dans les dépôts plus récents — qui couvre l’état complet du dépôt à ce moment-là.

Ce hachage n’est pas votre code. C’est un condensé mathématique de taille fixe. Vous ne pouvez pas reconstruire le code source à partir de celui-ci, et le même état de code produit toujours le même hachage.

Étape 2 : Ancrage

L’étape suivante consiste à ancrer le hachage dans un registre public. Timestamp GIT collecte les hachages de commit et les regroupe dans des fichiers manifestes quotidiens. Il construit un arbre de Merkle à partir de ces hachages et crée des preuves OpenTimestamps. La racine de Merkle est ensuite ancrée dans une transaction Bitcoin.

Une fois cette transaction confirmée dans un bloc Bitcoin, l’horodatage devient immuable. Il n’y a pas de bouton de suppression, pas de dérogation administrative et pas de base de données propriétaire qui puisse être modifiée ultérieurement.

Le flux ressemble à ceci :

hachage de commit -> manifeste quotidien -> arbre de Merkle -> transaction Bitcoin -> reçu .ots

Étape 3 : Preuve

Le résultat est un reçu cryptographique, généralement un fichier .ots. Ce reçu permet à quiconque de vérifier l’horodatage par rapport à la blockchain Bitcoin à l’aide des outils OpenTimestamps standard.

C’est important : la preuve repose sur SHA-256 et les données de blocs Bitcoin. Il n’y a aucun verrouillage au format ou à l’infrastructure d’un fournisseur unique. Même si le fournisseur SaaS n’existe plus, la preuve reste vérifiable.

Faire cela manuellement avec les outils OpenTimestamps bruts est possible, mais cela implique de gérer soi-même les calendriers, les arbres de Merkle et la surveillance des confirmations Bitcoin. Cette complexité manuelle est exactement ce que Timestamp GIT élimine en automatisant le pipeline derrière une application GitHub.

Pourquoi la preuve d’existence est importante pour les développeurs et la conformité

La preuve d’existence est importante parce que la question du moment est souvent la question centrale dans les litiges de propriété intellectuelle.

Chasseurs de brevets : Une défense courante contre un brevet logiciel large est l’antériorité. Si vous pouvez montrer que votre code existait avant la date de dépôt, la revendication de brevet peut être invalidée. La preuve d’existence transforme votre dépôt privé en un enregistrement d’antériorité daté et vérifiable. Pour plus de détails, voir Comment prouver que votre code existait avant un dépôt de brevet.
Litiges avec les employés et les clients : Lorsqu’un développeur part, ou qu’un client remet en question la date d’achèvement d’un jalon, un hachage de commit horodaté est plus solide qu’un historique de chat exporté ou un historique Git modifié.
Conformité et gouvernance : Les équipes qui ont besoin de pistes d’audit pour les revues de sécurité, la due diligence ou la gouvernance interne peuvent montrer un enregistrement régulier et vérifiable des moments où les états de code ont existé.

Il y a aussi des idées reçues courantes à dissiper.

Ce n’est pas un enregistrement de droit d’auteur. Un horodatage blockchain ne remplace pas l’enregistrement du droit d’auteur, et il ne prouve pas à lui seul la paternité.
Cela ne prouve pas qui a écrit le code. Cela prouve qu’un hachage donné existait à un moment donné. La paternité nécessite toujours des dossiers d’emploi, des métadonnées de commit ou d’autres preuves.
Ce n’est pas « juste un journal interne ». L’historique Git peut être réécrit, forcé par un push ou perdu. Une preuve ancrée dans Bitcoin est externe, publique et mathématiquement vérifiable.

Comment Timestamp GIT rend la preuve d’existence sans effort

Timestamp GIT est un SaaS géré et une application GitHub qui automatise l’ensemble du pipeline de preuve d’existence. Vous n’avez pas besoin d’exécuter des commandes OpenTimestamps, de gérer des calendriers ou d’interagir directement avec Bitcoin.

Le workflow principal est le suivant :

Installez l’application GitHub une seule fois.
Sélectionnez les dépôts que vous souhaitez surveiller.
Continuez à commiter du code normalement.

Chaque nuit, Timestamp GIT regroupe automatiquement les hachages de commit en attente, construit un arbre de Merkle, crée des preuves OpenTimestamps et ancre la racine de Merkle dans la blockchain Bitcoin. Après la confirmation Bitcoin — normalement environ trois heures — les fichiers de manifeste et de reçu .ots sont poussés vers une branche d’horodatage dédiée ou un dépôt miroir.

Caractéristiques clés :

Conçu sans divulgation de connaissances. Timestamp GIT ne voit, ne copie et ne stocke jamais votre code source. Il ne traite que les hachages de commit.
Aucune étape manuelle. Aucun outil CLI à installer sur les machines des développeurs et aucune transaction Bitcoin brute à construire.
Déploiement flexible. Le mode standard utilise l’application GitHub et nécessite un accès en lecture au dépôt source et un accès en lecture-écriture au dépôt cible. Le mode Enterprise ZK utilise une GitHub Action sur votre infrastructure pour pousser uniquement le hachage de commit vers l’API Timestamp GIT, de sorte que le service n’a besoin d’aucun accès en lecture au dépôt source.
Vérification publique. Vous pouvez intégrer des badges de statut dans votre README, consulter la page de statut publique, télécharger des CSV d’audit ou générer des certificats PDF.
Indépendance vis-à-vis du fournisseur. Le reçu .ots peut être vérifié hors ligne avec les outils OpenTimestamps standard, même si Timestamp GIT cesse de fonctionner.

Pour les environnements auto-hébergés ou isolés, une image Docker est disponible :

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

Vous pouvez également interroger directement les points de terminaison de statut public, par exemple :

curl https://timestampgit.dev/api/statusLast/your-org/your-repo

Ce point de terminaison renvoie des informations sur le dernier bloc Bitcoin ancré pour un dépôt surveillé.

FAQ

La preuve d’existence est-elle reconnue juridiquement ?

Les horodatages cryptographiques sont de plus en plus acceptés par les tribunaux comme preuve d’antériorité. Ils fournissent un enregistrement solide et infalsifiable qui peut être vérifié indépendamment. Cependant, la reconnaissance juridique varie selon les juridictions, et il est conseillé de consulter un avocat pour les cas spécifiques.

La preuve d’existence révèle-t-elle mon code source ?

Non. La preuve d’existence utilise des hachages cryptographiques, qui sont des fonctions à sens unique. Le code source réel n’est jamais transmis ni stocké. Seul le hachage est ancré dans la blockchain, votre code reste donc privé.

Combien coûte l’horodatage de mon code ?

Timestamp GIT propose un niveau gratuit pour les dépôts publics. Les plans payants commencent à 49 $/mois pour les dépôts privés, avec un plan Enterprise ZK à 199 $/mois. Des licences Docker auto-hébergées sont également disponibles.

Puis-je vérifier l’horodatage sans dépendre de Timestamp GIT ?

Oui. Les preuves sont basées sur le protocole OpenTimestamps et la blockchain Bitcoin. Vous pouvez télécharger le reçu .ots et le vérifier à l’aide des outils OpenTimestamps standard, même si Timestamp GIT cesse d’exister.

Conclusion

La preuve d’existence pour le code logiciel est l’un des rares outils de développement qui soit à la fois économique, mathématiquement rigoureux et utile dans les contextes juridiques et de conformité. Elle ne prouve pas la paternité ni la propriété, mais elle crée un point fixe dans le temps extrêmement difficile à contester.

La méthode difficile consiste à exécuter manuellement le protocole OpenTimestamps. La méthode pratique consiste à installer l’application GitHub Timestamp GIT, à connecter vos dépôts et à laisser le pipeline d’ancrage nocturne faire le reste. Commencez à horodater vos commits sur Timestamp GIT.

Articles connexes

Qu'est-ce que la preuve d'existence pour le code logiciel ?