2026-08-29 timestamp git blockchain proof

Comment prouver l’antériorité d’un logiciel : guide du développeur

Prouver l’antériorité d’un logiciel revient à une question précise : pouvez-vous démontrer qu’un commit Git spécifique existait à une date précise, avec la preuve qu’aucun serveur interne, administrateur de dépôt ou tiers ne peut l’altérer ? Ce guide explique exactement comment créer cette preuve sans exposer votre code source.

Vous utiliserez Timestamp GIT, un service managé et une GitHub App qui ancre les empreintes de vos commits Git dans la blockchain Bitcoin via le protocole OpenTimestamps. Le flux de travail consiste à installer une fois, committer normalement, puis laisser l’ancrage nocturne automatisé produire des fichiers de reçu .ots immuables.

À la fin de ce guide, vous aurez :

Installé la GitHub App sur les dépôts que vous souhaitez protéger.
Configuré l’endroit où les preuves cryptographiques sont livrées.
Déclenché et confirmé un horodatage ancré dans Bitcoin pour un commit réel.
Vérifié la preuve via un tableau de bord public et un badge.
Résolu les problèmes de permissions et de livraison les plus courants.

Prérequis

Avant de commencer, assurez-vous d’avoir :

Un compte GitHub et au moins un dépôt que vous souhaitez protéger.
Une familiarité de base avec les commits Git et les empreintes. Vous n’avez pas besoin d’expérience en cryptographie ou en blockchain.
Un compte Timestamp GIT. Les dépôts publics utilisent le plan gratuit ; les dépôts privés nécessitent le plan Pro Agency à 49 $/mois ou Enterprise ZK à 199 $/mois.
Facultatif : Docker si vous prévoyez d’auto-héberger Timestamp GIT dans un environnement isolé ou d’entreprise.

Étape par étape : configurer Timestamp GIT

Le chemin managé ne nécessite rien sur vos machines de développement. Vous installez la GitHub App une fois, sélectionnez les dépôts, puis chaque commit est automatiquement ancré dans Bitcoin chaque nuit.

Étape 1 : s’inscrire et connecter GitHub

Rendez-vous sur Timestamp GIT et connectez-vous avec votre compte GitHub. Le flux SaaS managé est le chemin par défaut.

Si vous vous auto-hébergez, commencez par le démarrage rapide Docker Compose :

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

Exécutez ensuite :

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

L’application auto-hébergée est disponible sur http://localhost:8080. Au premier lancement, un assistant de configuration vous guide pour connecter votre GitHub App et appliquer un fichier de licence.

Étape 2 : installer la GitHub App Timestamp GIT

Installez la GitHub App sur les dépôts que vous souhaitez protéger.

En mode standard, Timestamp GIT a besoin d’un accès en lecture seule au dépôt source. Ce n’est pas parce qu’il lit votre code — il lit uniquement l’empreinte du commit HEAD — mais parce que le système de permissions de GitHub n’expose pas de niveau d’accès limité aux empreintes uniquement.

Si les preuves sont livrées dans un dépôt cible distinct, l’application a également besoin d’un accès en lecture-écriture à ce dépôt cible.

Étape 3 : sélectionner les dépôts à surveiller

Depuis le tableau de bord Timestamp GIT, ouvrez la page Vos dépôts et sélectionnez les dépôts que vous souhaitez surveiller.

Chaque dépôt sélectionné est ajouté au pipeline de preuve nocturne. Timestamp GIT n’inspecte pas le contenu des fichiers, le code source ou le contenu des branches au-delà des empreintes de commit nécessaires à l’ancrage.

Étape 4 : configurer la livraison des preuves

Pour chaque dépôt surveillé, choisissez où les preuves cryptographiques doivent être écrites :

Une branche d’horodatage dédiée dans le même dépôt.
Un dépôt miroir distinct, qui peut être privé même si le dépôt source est public.

Timestamp GIT écrit les fichiers de manifeste et les reçus .ots à cet emplacement après la confirmation de l’ancrage quotidien.

Étape 5 : facultatif : activer le mode Enterprise ZK

Pour les équipes qui exigent un accès nul au code source, le mode Enterprise ZK est un modèle de déploiement plus robuste.

Lors de la configuration, Timestamp GIT génère un workflow GitHub Action de 12 lignes. Vous ajoutez ce fichier généré à votre dépôt sous :

.github/workflows/timestampgit.yml

L’action s’exécute sur votre propre infrastructure, pas sur les systèmes de Timestamp GIT. Elle envoie uniquement l’empreinte du commit à l’API Timestamp GIT. Dans ce mode, Timestamp GIT n’a besoin d’aucun accès en lecture au dépôt source — uniquement un accès en lecture-écriture au dépôt cible où les preuves sont livrées.

Étape 6 : faire un commit pour déclencher le processus

Une fois la surveillance configurée, committez et poussez normalement :

git add .
git commit -m "feat: add payment webhook handler"
git push origin main

En mode standard, la GitHub App détecte automatiquement la nouvelle empreinte du commit HEAD. En mode Enterprise ZK, la GitHub Action envoie l’empreinte depuis votre environnement CI.

Étape 7 : attendre l’ancrage Bitcoin nocturne

Timestamp GIT regroupe les empreintes de commit en attente dans une file d’attente en mémoire. Chaque nuit, un worker :

Regroupe les empreintes en attente par dépôt.
Crée des fichiers de manifeste quotidiens.
Construit un arbre de Merkle à partir des empreintes de commit.
Crée des preuves OpenTimestamps à l’aide de calendriers OTS publics.
Ancre la racine de Merkle dans la blockchain Bitcoin.

La confirmation Bitcoin prend normalement environ 3 heures. Après confirmation, le manifeste et les fichiers de reçu .ots sont poussés vers votre branche d’horodatage ou votre dépôt miroir configuré.

Comment confirmer que cela a fonctionné

Une fois l’exécution nocturne terminée, vous pouvez vérifier la preuve de plusieurs manières.

1. Inspecter la branche d’horodatage

Récupérez la branche d’horodatage et confirmez que les fichiers de manifeste et les reçus .ots sont présents :

git fetch origin timestamps
git ls-tree -r --name-only origin/timestamps | head

Le nom exact de la branche dépend de votre configuration, mais le signal important est la présence de fichiers .ots associés aux données de manifeste quotidiennes.

2. Utiliser la page de vérification publique

Timestamp GIT fournit une page de vérification basée sur le navigateur où tout le calcul de la chaîne de Merkle s’effectue localement dans votre navigateur :

https://timestampgit.dev/verification/{user}/{repo}/{date}

Remplacez {user}, {repo} et {date} par votre dépôt et la date que vous souhaitez vérifier.

3. Vérifier l’API de statut

Vous pouvez confirmer le dernier bloc Bitcoin ancré via le point de terminaison de statut public :

curl https://timestampgit.dev/api/statusLast/acme/widget-api

La réponse inclut les informations du dernier bloc Bitcoin ancré pour le dépôt.

4. Télécharger un certificat PDF

Pour un jour spécifique, téléchargez un certificat PDF depuis :

https://timestampgit.dev/api/report/{user}/{repo}/{date}

Le registre d’audit du dépôt est également disponible au format CSV :

https://timestampgit.dev/api/audit/{user}/{repo}

5. Intégrer un badge de vérification

Le tableau de bord Timestamp GIT fournit des URL de badge et des extraits Markdown prêts à copier-coller pour votre README. Les dépôts privés ajoutent un HMAC chiffré aux URL de badge afin que seuls les spectateurs autorisés puissent voir les informations de statut.

Le badge renvoie vers une page de vérification publique où n’importe qui peut inspecter la preuve. Le fichier .ots lui-même reste un reçu OpenTimestamps standard, de sorte que les auditeurs techniques peuvent également le télécharger et le vérifier indépendamment contre la blockchain Bitcoin à l’aide des outils OpenTimestamps standard.

Résolution des problèmes courants

Aucune preuve après 24 heures

Vérifiez les permissions de la GitHub App. Le mode standard nécessite au moins un accès en lecture seule au dépôt source. Confirmez également que le dépôt est toujours sélectionné dans le tableau de bord Timestamp GIT.

Le statut du dépôt privé n’est pas visible

Les dépôts privés utilisent des URL signées HMAC. Assurez-vous que le badge ou le lien de statut provient du tableau de bord Timestamp GIT et inclut le paramètre HMAC. Le HMAC est spécifique à l’instance de serveur qui l’a généré.

L’action Enterprise ZK ne livre pas les preuves

Vérifiez que le fichier de workflow généré est présent sous .github/workflows/timestampgit.yml et que la GitHub Action est installée dans le dépôt. Le dépôt cible où les preuves sont livrées doit avoir un accès en lecture-écriture depuis la configuration de votre action.

L’instance Docker auto-hébergée ne produit pas d’horodatages

Confirmez que le fichier de licence a été téléchargé pendant l’assistant de configuration. Vérifiez également que l’instance dispose de la connectivité réseau requise pour l’OAuth de la GitHub App et l’ancrage des horodatages.

La vérification de la preuve échoue

Assurez-vous de vérifier le bon fichier .ots et la bonne date. Un reçu pour un dépôt et une date donnés ne validera pas un commit d’un autre jour ou d’un autre dépôt.

FAQ

Q : Qu’est-ce que l’antériorité dans le domaine logiciel ?

R : L’antériorité est la preuve que votre invention, comme du code, un algorithme ou une conception, existait avant une certaine date. Elle est généralement utilisée pour invalider des revendications de brevet ou prouver la paternité d’une œuvre.

Q : Comment l’ancrage Bitcoin prouve-t-il l’antériorité ?

R : L’empreinte de votre commit Git est intégrée dans une transaction Bitcoin via le protocole OpenTimestamps. Une fois confirmée dans un bloc, l’horodatage est immuable et vérifiable par n’importe qui, prouvant que l’empreinte existait à ce moment-là.

Q : Timestamp GIT est-il gratuit pour les projets open source ?

R : Oui. Timestamp GIT propose un plan gratuit pour les dépôts publics. Les dépôts privés nécessitent un plan payant, soit Pro Agency, soit Enterprise ZK.

Q : Puis-je utiliser Timestamp GIT sans exposer mon code source ?

R : Oui. En mode standard, seules les empreintes de commit sont lues — pas le code source. En mode Enterprise ZK, une GitHub Action envoie uniquement les empreintes depuis votre propre infrastructure, de sorte que le code source ne quitte jamais votre environnement.

Q : Combien de temps faut-il pour qu’un horodatage soit confirmé ?

R : Le worker nocturne regroupe et ancre les empreintes après minuit. La confirmation Bitcoin prend normalement environ 3 heures après la transaction d’ancrage, attendez-vous donc à ce que les fichiers de preuve .ots apparaissent peu après.

Conclusion

L’historique Git seul n’est pas une preuve d’antériorité solide, car il peut être modifié, supprimé ou rejeté comme étant intéressé. Un reçu OpenTimestamps ancré dans Bitcoin est mathématiquement plus difficile à ignorer.

Timestamp GIT rend cela pratique pour les développeurs en activité : installez la GitHub App une fois, sélectionnez un dépôt et continuez à committer comme d’habitude. L’ancrage nocturne, la livraison des preuves, les badges, les certificats PDF et les CSV d’audit sont gérés automatiquement. Vous n’avez jamais besoin d’exécuter des commandes OpenTimestamps ni d’interagir manuellement avec la blockchain Bitcoin.

Commencez gratuitement avec les dépôts publics sur Timestamp GIT.

Articles connexes

Comment prouver l'antériorité d'un logiciel : guide du développeur