2026-09-09 timestamp git blockchain proof

Automatisez l’horodatage des commits Git avec une application GitHub

Si vous avez déjà essayé de prouver quand un commit Git a eu lieu, vous connaissez la routine manuelle : créer un reçu cryptographique pour un hash de commit, stocker le fichier .ots dans un endroit durable, faire correspondre ce reçu au bon commit, puis répéter le processus pour chaque branche et chaque dépôt qui compte. Manquez un seul commit et vous avez un trou dans votre registre d’antériorité.

Timestamp GIT remplace cette routine par une application GitHub qui horodate automatiquement les commits Git. Cet article porte sur le chemin d’automatisation, pas sur les concepts cryptographiques sous-jacents. Pour un rappel sur la preuve d’existence et son importance, consultez Preuve d’existence pour le code : ce que c’est et pourquoi c’est important.

La corvée d’horodatage manuel que vous pouvez éliminer

L’horodatage manuel échoue généralement pour des raisons banales, pas pour des raisons de sécurité.

Vous oubliez d’horodater une branche de fonctionnalité importante.
Les reçus finissent dispersés entre ordinateurs portables, artefacts CI et dossiers aléatoires.
Il n’existe aucune correspondance claire entre les fichiers de reçu et les commits spécifiques.
Différents coéquipiers utilisent des processus différents, voire aucun processus du tout.
Lorsqu’un litige survient réellement, vous découvrez que le reçu n’a jamais été créé.

La méthode difficile consiste à travailler directement avec OpenTimestamps : installer les outils, horodater les hashes de commit à la main et stocker vous-même les fichiers de reçu. Cette approche fonctionne techniquement, mais c’est une corvée qui entre en concurrence avec le travail de développement réel.

Timestamp GIT vous débarrasse de cette corvée. C’est un SaaS géré et une application GitHub qui automatise entièrement et masque le protocole OpenTimestamps. Une fois installée, elle surveille vos dépôts, collecte les hashes de commit et les ancre dans la blockchain Bitcoin chaque nuit. Pas d’outils CLI, pas de gestion manuelle des reçus, rien à mémoriser.

Configuration unique : connectez votre dépôt à l’application GitHub

Le modèle de configuration est volontairement simple : installez une fois, connectez les dépôts, et passez à autre chose.

Mode standard avec l’application GitHub :

Installez l’application GitHub Timestamp GIT depuis le GitHub Marketplace.
Accordez l’accès aux dépôts que vous souhaitez surveiller.
Choisissez où les preuves doivent être stockées : une branche dédiée dans le même dépôt ou un dépôt miroir séparé.
Terminé.

Après l’installation, l’application GitHub commence automatiquement à surveiller les nouveaux commits via des webhooks. Aucune modification de code, aucun fichier de configuration local, et rien à installer sur les machines des développeurs.

Permissions en mode standard :

L’application a besoin d’un accès en lecture seule au dépôt source afin de pouvoir lire le hash du commit HEAD.
Elle a besoin d’un accès en lecture-écriture au dépôt ou à la branche cible où les fichiers de preuve seront stockés.
Elle ne lit ni ne stocke jamais votre code source réel.

Mode Enterprise ZK pour les environnements à divulgation nulle de connaissance :

Si votre politique de sécurité exige que votre code source ne quitte jamais votre infrastructure, vous pouvez utiliser le mode Enterprise ZK. Une GitHub Action de 12 lignes s’exécute de votre côté et envoie uniquement le hash du commit à l’API Timestamp GIT. Dans ce mode, Timestamp GIT n’a pas du tout besoin d’un accès en lecture au dépôt source — seulement d’un accès en lecture-écriture au dépôt cible où les preuves sont stockées.

Cette distinction est importante pour les équipes de conformité : le mode standard lit les hashes de commit depuis GitHub, tandis que le mode Enterprise ZK envoie uniquement les hashes depuis votre GitHub Action.

Le pipeline automatisé : du commit à l’ancrage Bitcoin

Après la configuration, le pipeline s’exécute sans intervention manuelle.

Chaque nuit, un processus worker collecte les hashes de commit en attente de la journée et les traite par lot :

Les hashes de commit sont détectés par l’application GitHub ou envoyés par votre Action Enterprise ZK.
Les hashes restent dans une file d’attente en mémoire jusqu’à l’exécution nocturne.
Un worker cron de minuit regroupe les hashes en attente par dépôt.
Le worker crée des fichiers manifest pour chaque dépôt.
Il construit un arbre de Merkle à partir du lot quotidien.
Il crée des preuves OpenTimestamps en utilisant des calendriers OTS publics.
La racine de Merkle est ancrée dans un bloc Bitcoin.

Le manifest et les fichiers de reçu .ots sont ensuite renvoyés vers votre branche d’horodatage dédiée ou votre dépôt miroir.

Une note importante sur le timing : la confirmation Bitcoin prend plusieurs heures, normalement environ trois heures. Comme le lot s’exécute à minuit et que l’ancrage se termine plus tard, les preuves apparaissent généralement le lendemain. Ce délai n’est pas un échec — c’est le réseau Bitcoin qui fait le travail qui rend l’horodatage immuable.

Vous pouvez vérifier le dernier statut ancré avec l’API REST :

# Dernières informations sur le bloc Bitcoin ancré
curl -s https://timestampgit.dev/api/statusLast/acme/webapp

# Nombre total de commits horodatés
curl -s https://timestampgit.dev/api/statusCount/acme/webapp

# Résumé combiné utilisé par les badges Shields.io
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp

Remplacez acme/webapp par votre utilisateur ou organisation GitHub et le nom du dépôt.

Pour un README public, vous pouvez intégrer un badge de vérification. La page Repository Connected fournit l’extrait Markdown après l’installation. Un badge typique ressemble à ceci :

[![Timestamp GIT](https://timestampgit.dev/api/statusSummary/acme/webapp)](https://timestampgit.dev/status/acme/webapp)

Pour les dépôts privés, les URL de statut sont protégées par un HMAC chiffré. Seuls les utilisateurs autorisés peuvent consulter le statut de ces dépôts, et le HMAC est spécifique à l’instance du serveur.

Surveillance et gestion des échecs : garder vos preuves en bonne santé

L’automatisation ne signifie pas ignorer le système. Cela signifie surveiller le résultat au lieu d’effectuer la tâche à la main.

La page de statut du dépôt est votre principal tableau de bord de santé. Elle affiche :

La longévité des preuves
La date d’ancrage la plus ancienne
La régularité quotidienne
Les données de bloc et de transaction Bitcoin
Une carte thermique calendaire des jours horodatés
Un CSV d’audit téléchargeable
Un certificat PDF par date horodatée

Pour une surveillance programmatique, les endpoints de l’API publique couvrent les cas courants :

# Vérifier le bloc ancré le plus récent
curl -s https://timestampgit.dev/api/statusLast/acme/webapp

# Compter combien de commits ont été horodatés
curl -s https://timestampgit.dev/api/statusCount/acme/webapp

# Récupérer un résumé combiné pour les scripts ou Shields.io
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp

Ces endpoints peuvent être branchés sur votre moniteur de disponibilité existant, votre tableau de bord interne ou votre vérification CI. Par exemple, un script planifié peut appeler statusLast une fois par jour et alerter si la date d’ancrage attendue est manquante.

Les scénarios d’échec courants incluent :

Accès au dépôt révoqué dans GitHub.
Application GitHub désinstallée.
Problèmes réseau entre GitHub et le service Timestamp GIT.

Ces échecs apparaissent sur la page de statut du dépôt plutôt que d’échouer silencieusement. Comme les hashes de commit sont regroupés par date, une exécution nocturne manquée peut récupérer les hashes en attente lors du prochain lot réussi.

Pour la conformité et la conservation des enregistrements, téléchargez périodiquement le CSV d’audit et le certificat PDF. Stockez-les dans vos archives juridiques avec les autres documents de propriété intellectuelle.

Bonnes pratiques pour l’horodatage Git automatisé

Une fois l’automatisation en place, quelques habitudes renforceront votre registre d’antériorité.

Horodatez tous les dépôts, y compris les dépôts privés. De nombreuses équipes n’horodatent que les projets publics. Mais les trolls de brevets et les litiges d’emploi ciblent souvent les systèmes internes et les secrets commerciaux. Les dépôts privés comptent tout autant, voire davantage.

Gardez les fichiers de preuve hors de la branche source principale. Utilisez une branche d’horodatage dédiée ou un dépôt miroir séparé. Cela garde votre branche main propre tout en donnant aux auditeurs un endroit unique pour trouver les reçus .ots et les fichiers manifest.

Intégrez le badge de vérification dans votre README. Un badge visible indique aux contrefacteurs potentiels que votre historique de commits est ancré dans Bitcoin. Ce n’est pas qu’une décoration ; c’est un moyen de dissuasion à faible coût.

Utilisez le mode Enterprise ZK lorsque le code source doit rester interne. Si votre équipe de conformité interdit l’accès en lecture par des tiers aux dépôts source, l’approche GitHub Action n’envoie que les hashes de commit à l’API Timestamp GIT.

Pour les environnements isolés ou auto-hébergés, utilisez l’image Docker. Timestamp GIT est disponible sous forme d’image Docker pour un contrôle total :

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

Démarrez-le avec :

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

L’application devient disponible sur http://localhost:8080. Au premier lancement, un assistant de configuration vous guide pour connecter votre application GitHub et configurer l’instance. Une licence de démonstration à durée limitée est disponible sur la page Docker License.

Téléchargez périodiquement les rapports d’audit. N’attendez pas un litige juridique pour commencer à collecter des preuves. Un export trimestriel ou mensuel prend quelques minutes et vous donne une archive hors ligne.

FAQ

Comment l’application GitHub horodate-t-elle automatiquement mes commits ?

Une fois installée, l’application GitHub Timestamp GIT surveille votre dépôt pour détecter les nouveaux commits via des webhooks. Chaque nuit, elle collecte tous les hashes de commit de la journée, crée un arbre de Merkle et ancre la racine dans la blockchain Bitcoin en utilisant le protocole OpenTimestamps. Les preuves sont ensuite renvoyées automatiquement vers votre dépôt. Aucune étape manuelle n’est requise.

L’application GitHub a-t-elle accès à mon code source ?

En mode standard, l’application nécessite un accès en lecture seule au dépôt source pour lire les hashes de commit, mais elle ne lit ni ne stocke jamais votre code source réel. Pour une confidentialité maximale, le mode Enterprise ZK utilise une GitHub Action qui envoie uniquement le hash du commit à l’API Timestamp GIT, de sorte que votre code source ne quitte jamais votre environnement.

Puis-je utiliser Timestamp GIT avec des dépôts privés ?

Oui. Les plans Pro et Enterprise prennent en charge les dépôts privés. L’application peut stocker les preuves dans un dépôt miroir ou une branche dédiée, et l’accès aux endpoints de statut est protégé par HMAC pour les dépôts privés.

Comment puis-je vérifier que mon commit a été horodaté ?

Vous pouvez vérifier via le tableau de bord de statut public, les endpoints de l’API tels que /api/statusLast, ou en téléchargeant le reçu .ots et en exécutant les outils de vérification OpenTimestamps standard contre la blockchain Bitcoin. La vérification est indépendante et ne repose pas sur les serveurs de Timestamp GIT.

Conclusion : configurez et oubliez

L’horodatage Git automatisé change la question de « Ai-je pensé à horodater ce commit ? » à « L’ancrage nocturne apparaît-il dans mon tableau de bord ? »

Timestamp GIT gère l’intégralité du protocole OpenTimestamps en coulisses. Vous installez l’application GitHub une fois, connectez vos dépôts et laissez le pipeline nocturne ancrer les hashes de commit dans Bitcoin. Le résultat est une preuve d’antériorité immuable, prête pour les tribunaux, sans nouvelle habitude manuelle.

Commencez avec le plan gratuit pour les dépôts publics, passez à Pro Agency pour les dépôts privés, ou utilisez Enterprise ZK lorsque le code source doit rester dans votre infrastructure. Les auto-hébergeurs peuvent déployer l’image Docker pour un contrôle total.

Installez l’application GitHub dès aujourd’hui sur Timestamp GIT et faites de l’horodatage quelque chose que vos dépôts font automatiquement.

Articles connexes

Automatisez l'horodatage des commits Git avec une application GitHub