2026-10-07 timestamp git blockchain proof

Preuve d’horodatage de commit Git pour les litiges de brevets

Dans un litige de brevets, la question coûteuse est rarement « avez-vous écrit ce code ? ». C’est « pouvez-vous prouver quand ? ». Git enregistre une date sur chaque commit, mais cette date vit dans une base de données que vous ne possédez pas et que vous pouvez réécrire avec un simple rebase. Une preuve d’horodatage de commit Git pour les litiges de brevets comble cette lacune en transformant votre historique de commits en antériorité cryptographique qu’un tiers peut vérifier par rapport à la blockchain Bitcoin — sans que personne ne lise votre code source.

Cet article explique ce qu’est réellement cette preuve, comment elle est produite automatiquement, et où elle tient la route dans une conversation juridique.

Qu’est-ce qu’une preuve d’horodatage de commit Git ?

Une preuve d’horodatage de commit Git est un enregistrement cryptographique montrant qu’un hash de commit spécifique existait à un instant précis, ancré dans la blockchain Bitcoin. C’est toute la définition. Elle ne décrit ni votre code, ni votre logique, ni votre activité — elle prouve l’existence d’une empreinte à un moment donné.

Il est utile de distinguer deux choses que les développeurs confondent généralement :

La date de commit dans Git. Stockée dans l’objet commit, modifiable avec git commit --amend ou un rebase, et hébergée sur une infrastructure que vous ne contrôlez pas si vous utilisez une plateforme comme GitHub. Lors d’un audit juridique, les journaux internes de ce type sont systématiquement écartés comme partials ou manipulables.
Une preuve ancrée dans Bitcoin. Un enregistrement attestant que le hash existait avant qu’un bloc Bitcoin donné ne soit miné. Une fois un bloc confirmé, aucune entité — ni l’hébergeur, ni nous, ni vous — ne peut le modifier ni l’antidater.

Un point qui surprend les gens : la preuve porte sur le hash de commit, pas sur le code source. Timestamp GIT ne voit, ne copie ni ne stocke jamais votre code source réel. Il horodate mathématiquement le hash et rien d’autre. C’est du zero-knowledge par conception, et c’est ce qui rend l’approche sûre à utiliser sur des dépôts privés et même des secrets commerciaux.

Si vous voulez la vue d’ensemble de la façon dont cela s’intègre dans une stratégie de PI, le guide de propriété intellectuelle pour les développeurs couvre le terrain environnant ; cet article se concentre sur la preuve d’horodatage elle-même.

L’analogie du notaire : pourquoi un horodatage est une preuve

Pensez à un notaire. Vous lui remettez une enveloppe scellée, et le notaire appose la date dessus. Le notaire n’ouvre pas l’enveloppe, ne lit pas la lettre et ne conserve pas de copie du contenu. Le tampon certifie une seule chose : cet objet scellé existait à cette date.

Maintenant, transposez cela sur ce workflow :

L’enveloppe scellée est votre hash de commit — une empreinte SHA-1/SHA-256 à sens unique de l’état du dépôt. Elle ne révèle rien du contenu, mais elle y est uniquement liée.
Le notaire est Bitcoin. Il ne peut pas être corrompu, il ne peut pas être contraint d’antidater un tampon, et il n’a aucune opinion sur votre activité.
Le carbone notarié que vous conservez est le fichier de reçu .ots et le manifeste. Vous détenez la preuve, et vous pouvez la remettre à n’importe qui.

Pourquoi cette analogie compte-t-elle juridiquement ? Parce que le mode de défaillance d’une preuve interne n’est pas qu’elle soit fausse — c’est qu’elle est votre preuve. Un journal de serveur Git dit « faites-moi confiance ». Un ancrage sur une blockchain publique dit « vérifiez vous-même, voici les mathématiques ». C’est cette différence qui transforme un historique de commits en quelque chose sur quoi un avocat peut bâtir un argument d’antériorité.

Comment Timestamp GIT transforme les commits en preuves pour les litiges de brevets

Le modèle en trois étapes est simple.

Étape 1 — Empreinte. Lorsque vous committez, Git génère un hash à sens unique unique (SHA-1 ou SHA-256) représentant l’état exact de l’ensemble de votre dépôt à cet instant. C’est une empreinte cryptographiquement sûre de votre travail.

Étape 2 — Ancrage. Timestamp GIT extrait uniquement les hash de commit, les rassemble dans un fichier manifeste texte quotidien par dépôt, génère un hash SHA-256 de ce manifeste, construit un arbre de Merkle et ancre la racine de Merkle dans une transaction Bitcoin via le protocole OpenTimestamps. L’existence du hash est figée dans le temps dans un bloc Bitcoin spécifique.

Étape 3 — Preuve. Vous recevez un fichier de reçu .ots immuable. Le manifeste et les reçus sont repoussés dans votre propre dépôt — soit dans une branche timestamps dédiée, soit dans un dépôt fantôme séparé — prêts pour un avocat, un auditeur ou un tribunal.

Sous le capot, le pipeline managé ressemble à ceci :

Détection des commits — l’application GitHub détecte les nouveaux commits via des webhooks.
File de hash — les hash de commit entrent dans un magasin clé-valeur en mémoire pour le traitement par lots.
Worker cron de minuit — chaque nuit, un worker regroupe les hash en attente, écrit les manifestes .txt, construit l’arbre de Merkle, crée les preuves par rapport aux calendriers OTS publics et ancre la racine dans Bitcoin.
Livraison des preuves — les manifestes et les reçus reviennent dans votre dépôt. La confirmation Bitcoin prend normalement environ trois heures, donc l’écriture des preuves se termine quelques heures après l’exécution du lot.

Le point important pour votre équipe : vous installez l’application GitHub une seule fois. Pas d’outils CLI, pas de commandes de protocole, pas d’étapes manuelles. Le worker nocturne fait le reste, et il n’y a rien à installer sur les machines de vos développeurs. Même l’approche par protocole brut — orchestrer vous-même les calendriers et les transactions — est quelque chose que nous traitons comme un détail d’implémentation plutôt qu’un workflow que vous devriez avoir à exécuter.

Pour les équipes qui veulent que le hash quitte leur infrastructure de leur propre main, le mode Enterprise ZK remplace le webhook par une GitHub Action de 12 lignes qui s’exécute sur vos runners et ne pousse que le hash de commit vers l’API Timestamp GIT. Votre dépôt source reste totalement hors du tableau.

Pourquoi cela compte dans un litige de brevets (et ce que les gens comprennent mal)

Trois scénarios reviennent sans cesse :

Les trolls de brevets. Des entités non pratiquantes déposent des brevets larges sur des technologies courantes. Si vous avez implémenté cette technologie des mois avant leur date de dépôt et pouvez le prouver, la date de commit ancrée devient une antériorité qui peut invalider la revendication.
Les litiges entre employés. Quand un développeur principal part, des disputes éclatent sur le moment où une fonctionnalité a été conçue. Un horodatage immuable remplace le « il a dit, elle a dit » par une date que ni l’un ni l’autre ne peut modifier.
Les revendications de développement en salle blanche. Un concurrent affirme avoir « développé indépendamment » quelque chose de similaire. Prouver que vous aviez la logique finalisée 18 mois plus tôt crée un mur mathématique qu’une histoire de développement indépendant ne peut franchir.

Et trois idées fausses à tuer d’emblée :

« Mon historique de commits GitHub suffit. » Il est hébergé par un tiers que vous ne contrôlez pas, et il est modifiable. Amend, rebase, force-push — les dates bougent.
« Je dois publier mon code pour prouver que je l’avais. » Non. Timestamp GIT ancre le hash, jamais la source. Vous obtenez une preuve d’antériorité sans divulguer l’implémentation — ce qui est exactement ce que vous voulez pour les secrets commerciaux.
« Je devrais exécuter OpenTimestamps moi-même. » Non. L’application GitHub gère le protocole de bout en bout, et la section suivante montre comment vérifier le résultat.

Vérifier et présenter la preuve

La vérification est locale et zero-knowledge. N’importe qui peut prendre le fichier .ots et le vérifier par rapport à la blockchain Bitcoin sans faire confiance à Timestamp GIT — ni avoir besoin que notre entreprise existe. La preuve cryptographique repose entièrement sur SHA-256 et les données de blocs Bitcoin. C’est ce que signifie « indépendant du fournisseur » en pratique : pas de format propriétaire, pas d’enfermement.

Pour l’usage quotidien, le produit expose la même preuve sous des formes plus conviviales :

Page de vérification publique à /verification/{user}/{repo}/{date} — une vérification de la chaîne de Merkle étape par étape, à plusieurs niveaux. Tous les calculs se font localement dans votre navigateur. Personne ne voit ce que vous vérifiez.
Certificat PDF pour une date spécifique (/api/report/{user}/{repo}/{date}), qui est l’artefact que vous remettez à votre conseil juridique.
CSV d’audit du registre complet (/api/audit/{user}/{repo}), utile pour une revue complète de la chaîne de possession.
Badges README qui affichent publiquement le statut de vérification. Les investisseurs et les acquéreurs les lisent comme des signaux de maturité en matière de PI. Les URL des badges et les extraits markdown proviennent de /api/badgeLink/{user}/{repo}.

Un moyen rapide de vérifier le statut public depuis un script :

curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Les dépôts privés ajoutent un HMAC chiffré à l’URL, de sorte que seuls les utilisateurs autorisés peuvent consulter leur statut. Le HMAC est spécifique à l’instance de serveur.

Pour la version pas à pas de ce processus — y compris comment parcourir vous-même la chaîne de Merkle — voir Comment vérifier l’horodatage Bitcoin d’un dépôt Git.

Options de déploiement : managé, Enterprise ZK ou auto-hébergé

Mode standard (application GitHub). Installez l’application sur le dépôt. Elle ne lit que le hash du commit HEAD et écrit les preuves dans une branche timestamps ou un dépôt fantôme. Le modèle de permissions de GitHub signifie que nous avons besoin au minimum d’un accès en lecture seule au dépôt source (il n’existe pas de permission limitée au hash de commit), plus d’un accès en lecture-écriture au dépôt cible.

Mode Enterprise ZK. Une GitHub Action de 12 lignes s’exécute sur votre infrastructure et ne pousse que le hash de commit vers l’API. Aucun accès en lecture au dépôt source n’est requis, et votre code ne quitte jamais votre environnement.

Licence Docker auto-hébergée. Pour une sécurité maximale et les environnements isolés, Timestamp GIT est livré sous forme d’image Docker. Une configuration Docker Compose de démarrage rapide ressemble à ceci :

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

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

L’application est disponible à http://localhost:8080 après le démarrage, et un assistant de configuration au premier lancement vous guide pour connecter votre application GitHub. Une licence de démonstration à durée limitée pour l’évaluation est disponible via le formulaire de demande sur la page Docker License. Le tutoriel Docker auto-hébergé couvre la configuration complète si vous choisissez cette voie.

FAQ

Un horodatage de commit Git ancré dans Bitcoin est-il réellement admissible dans un litige de brevets ? Il fournit des preuves recevables par un tribunal, fondées sur des normes cryptographiques mondialement reconnues. La preuve montre qu’un hash de commit existait à un moment de bloc Bitcoin spécifique, ce qui peut servir à établir une antériorité. L’admissibilité dépend de votre juridiction et de votre conseil juridique, mais la preuve cryptographique elle-même est mathématiquement vérifiable par n’importe qui.

Timestamp GIT voit-il ou stocke-t-il mon code source ? Non. Timestamp GIT ne traite que les hash de commit. En mode standard, l’application GitHub lit le hash du commit HEAD ; en mode Enterprise ZK, une GitHub Action ne pousse que le hash depuis votre infrastructure, sans accès en lecture au dépôt source. Votre code reste dans votre environnement.

Que dois-je installer sur les machines de mes développeurs ? Rien. Timestamp GIT est une application GitHub managée. Vous l’installez une fois sur le dépôt, et chaque commit est ancré automatiquement chaque nuit. Il n’y a aucun outil CLI que votre équipe doit apprendre ou retenir.

Combien coûte la protection d’un dépôt privé ? Les dépôts publics sont gratuits dans le cadre du plan Open Source. Les dépôts privés sont couverts par Pro Agency à 49 $/mois, et Enterprise ZK avec GitHub Actions à 199 $/mois. Une licence Docker auto-hébergée est également disponible pour les environnements isolés, avec une licence de démonstration à durée limitée pour l’évaluation.

Conclusion

Une preuve d’horodatage de commit Git transforme quelque chose que vous faites déjà — committer du code — en antériorité que vous pouvez défendre. L’historique de commits seul ne survivra pas à un audit juridique, parce qu’il est modifiable et hébergé par quelqu’un d’autre. Un hash ancré dans Bitcoin, si, parce que les mathématiques sont publiques et l’enregistrement immuable.

La voie pratique consiste à cesser de considérer les horodatages comme une corvée manuelle. Installez l’application GitHub une fois, pointez-la vers les dépôts qui comptent, et laissez l’ancrage nocturne faire le travail. Consultez le tableau de bord de statut quand vous avez besoin de preuves, intégrez un badge quand vous voulez montrer votre maturité en matière de PI, et remettez le reçu .ots à votre avocat le jour où vous en avez réellement besoin.

Preuve d'horodatage de commit Git pour les litiges de brevets