Installez une application GitHub pour horodater automatiquement vos commits

2026-09-14 timestamp git blockchain proof

Installez une GitHub App pour horodater automatiquement vos commits

Vous automatisez déjà les builds, les tests, le linting et le déploiement. Alors pourquoi continuer à horodater manuellement vos commits lorsque vous devez prouver une antériorité ? La méthode laborieuse consiste à exécuter les outils de protocole commit par commit et à gérer vous-même les fichiers de preuve. Timestamp GIT remplace cela par une GitHub App gérée qui horodate automatiquement chaque commit et l’ancre dans la blockchain Bitcoin.

Le flux de travail est volontairement ennuyeux après l’installation : installez la GitHub App une seule fois, sélectionnez les dépôts à surveiller, et laissez le pipeline nocturne créer les reçus de preuve .ots. Aucune CLI à installer sur les machines des développeurs, aucune commande manuelle à retenir avant une release, et aucune archive locale d’horodatage fragile.

Cet article couvre la configuration unique, ce qui se passe entre le commit et l’ancrage Bitcoin, comment surveiller les preuves, et les pratiques qui gardent vos preuves solides devant un tribunal.

Configuration unique : connecter la GitHub App

L’automatisation commence par une seule installation. Ensuite, la GitHub App d’horodatage des commits fait le travail répétitif à votre place.

1. Installez la GitHub App Timestamp GIT

Installez l’application sur votre compte personnel ou votre organisation depuis le tableau de bord Timestamp GIT. Pendant l’installation, vous accordez l’accès aux dépôts comme pour n’importe quelle autre GitHub App.

En mode standard, l’application nécessite :

Accès en lecture au dépôt source. GitHub n’offre pas de permission limitée au hash des commits, donc l’application a besoin au minimum d’un accès en lecture seule pour détecter les hashes de commits.
Accès en écriture au dépôt ou à la branche cible. Les fichiers de preuve doivent être stockés quelque part. Cela peut être une branche dédiée timestamps dans le dépôt source ou un dépôt miroir séparé.

Même avec un accès en lecture, l’application ne lit que le hash du commit HEAD des dépôts surveillés. Elle ne lit pas les fichiers sources, les diffs, les issues ou le contenu des pull requests.

2. Sélectionnez les dépôts à surveiller

Après l’installation, choisissez les dépôts qui doivent recevoir un horodatage automatique. Les dépôts publics sont disponibles avec le plan gratuit. Les dépôts privés nécessitent un plan payant Pro ou Enterprise, selon vos besoins de sécurité et de conformité.

Aucune modification du code applicatif n’est nécessaire. Vous n’installez rien sur les machines des développeurs, et votre équipe n’a pas besoin de changer son flux de travail de commit.

3. Choisissez la livraison des preuves

Par défaut, l’application crée une branche Git dédiée ou un dépôt miroir pour les artefacts de preuve. Cela garde les preuves séparées de l’historique principal de votre code source et évite de polluer les pull requests avec des fichiers .ots.

Mode Enterprise ZK : zéro accès au code

Si votre code est propriétaire, réglementé ou isolé du réseau, le mode Enterprise ZK est l’option la plus stricte. Une GitHub Action de 12 lignes s’exécute sur votre infrastructure et envoie uniquement le hash du commit à l’API Timestamp GIT.

Dans ce mode, l’application Timestamp GIT n’a besoin d’aucun accès en lecture à votre dépôt source. Vous installez la GitHub Action, et seuls les hashes de commits quittent votre environnement. Votre code source ne le quitte jamais.

Optionnel : mode auto-hébergé avec Docker

Pour un contrôle maximal, Timestamp GIT est également disponible sous forme d’image Docker. C’est utile pour les environnements isolés du réseau ou les organisations qui doivent garder toute leur infrastructure sur site.

Une configuration Compose minimale 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

Lancez-la avec :

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

L’application est disponible sur http://localhost:8080. Au premier lancement, un assistant de configuration vous guide pour connecter votre GitHub App et configurer l’instance.

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

Une fois la GitHub App installée, le processus d’horodatage s’exécute tout seul.

Étape 1 : détection des commits

En mode standard, la GitHub App détecte les nouveaux commits via des webhooks. En mode Enterprise ZK, votre GitHub Action envoie les hashes de commits à l’API dans le cadre du CI/CD.

Dans les deux cas, la seule donnée qui entre dans le pipeline Timestamp GIT est le hash du commit.

Étape 2 : traitement par lots nocturne et ancrage Bitcoin

Les hashes de commits sont stockés dans un stockage clé-valeur en mémoire pour le traitement par lots. Chaque nuit, un worker cron :

Regroupe tous les hashes de commits en attente.
Crée un fichier manifeste pour chaque dépôt.
Construit un arbre de Merkle à partir du lot quotidien.
Crée des preuves OpenTimestamps en utilisant des calendriers OTS publics.
Ancre la racine de Merkle dans la blockchain Bitcoin.

La racine de Merkle quotidienne est ce qui est intégré dans Bitcoin. Une fois cette transaction confirmée, le hash est définitivement figé dans un bloc Bitcoin spécifique.

Étape 3 : livraison des preuves

Après la confirmation de la transaction Bitcoin, Timestamp GIT renvoie le manifeste et les fichiers de reçus .ots vers la branche timestamps dédiée ou le dépôt miroir.

La confirmation Bitcoin prend normalement environ trois heures après la soumission du lot nocturne. Cela signifie qu’un commit effectué pendant la journée aura généralement son fichier de preuve disponible le lendemain.

Étape 4 : statut et vérification

Vous pouvez consulter l’historique des ancrages depuis le tableau de bord de statut du dépôt. Le tableau de bord public affiche :

La longévité des preuves
La date d’ancrage la plus ancienne
La régularité des ancrages quotidiens
Les données de bloc et de transaction Bitcoin
Une heatmap calendaire
Un CSV d’audit téléchargeable et un certificat PDF

Pour un accès programmatique, des endpoints de statut publics sont disponibles :

# Informations sur le dernier bloc Bitcoin ancré
curl -s https://timestampgit.dev/api/statusLast/acme/payments-api

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

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

Le produit fournit également un endpoint de badge authentifié pour générer des badges README en une seule requête. Pour les dépôts privés, les URLs de badge incluent un HMAC chiffré afin que seuls les utilisateurs autorisés puissent voir le statut.

Surveillance et gestion des échecs

L’automatisation ne signifie pas ignorer le système. Vous devez surveiller la régularité des ancrages de la même manière que vous surveillez la santé de votre CI.

Le tableau de bord de statut est l’endroit le plus rapide pour repérer un jour manquant. Si un lot nocturne ne produit pas de preuve, la date manquante sera visible comme un trou dans la heatmap calendaire et dans la vue de régularité quotidienne.

Pour les vérifications programmatiques, les mêmes endpoints ci-dessus peuvent alimenter votre surveillance interne :

Utilisez /api/statusLast/{user}/{repo} pour confirmer l’ancrage Bitcoin le plus récent.
Utilisez /api/statusCount/{user}/{repo} pour comparer les commits horodatés avec le nombre de commits attendu.
Utilisez /api/audit/{user}/{repo} pour télécharger le registre d’audit complet au format CSV.

Exemple :

# Télécharger le registre d'audit complet
curl -OJ https://timestampgit.dev/api/audit/acme/payments-api

# Télécharger un certificat PDF pour une date spécifique
curl -OJ https://timestampgit.dev/api/report/acme/payments-api/2026-09-13

Comme le système regroupe les hashes à minuit et que la confirmation Bitcoin prend environ trois heures, ne considérez pas un commit nouvellement poussé comme entièrement horodaté tant que le fichier de preuve n’apparaît pas dans la branche timestamps.

Enfin, n’importe qui peut vérifier indépendamment un fichier .ots contre la blockchain Bitcoin. La preuve repose sur des reçus OpenTimestamps standard et les données de blocs Bitcoin, donc la vérification ne dépend pas de la disponibilité continue de Timestamp GIT.

Bonnes pratiques pour l’horodatage automatisé

1. Activez-le sur tous les dépôts critiques

Horodater uniquement les dépôts publics laisse le travail interne privé sans protection. Les trolls de brevets et les litiges entre employés impliquent souvent des systèmes propriétaires qui ne quittent jamais votre infrastructure. Utilisez les plans pour dépôts privés ou le mode Enterprise ZK pour ceux-là.

2. Utilisez le mode Enterprise ZK pour les secrets commerciaux

Si un dépôt contient des secrets commerciaux ou du code réglementé, n’accordez à aucune application tierce un accès en lecture. Utilisez la GitHub Action pour que seuls les hashes de commits quittent votre environnement.

3. Protégez la branche `timestamps`

Les reçus .ots et les fichiers manifestes sont vos preuves. Traitez la branche timestamps dédiée ou le dépôt miroir comme un stockage de preuves immuable. Restreignez l’accès en écriture à l’application et aux administrateurs requis.

4. Archivez régulièrement les enregistrements d’audit

Téléchargez les CSV d’audit et les certificats PDF selon un calendrier, par exemple trimestriellement ou avant les releases majeures. Conservez des copies dans vos archives de conformité ou juridiques. La preuve blockchain existe indépendamment, mais avoir une piste d’audit organisée facilite grandement la revue juridique.

5. Ajoutez un badge de vérification à votre README

Les badges de vérification publics sont un moyen simple de signaler qu’un dépôt a l’horodatage automatique activé. Utilisez le lien du badge depuis le tableau de bord ou l’API authentifiée pour intégrer un badge Shields.io dans votre README.

FAQ

Est-ce que la GitHub App lit mon code source ?

Non. En mode standard, l’application ne lit que le hash du commit HEAD. En mode Enterprise ZK, une GitHub Action de votre côté envoie uniquement le hash du commit à l’API, donc l’application n’a jamais aucun accès à votre dépôt.

Combien de temps faut-il pour qu’un commit soit horodaté ?

Les commits sont collectés tout au long de la journée et ancrés dans Bitcoin lors d’un lot nocturne. Après la soumission du lot, la confirmation Bitcoin prend généralement environ 3 heures. Vous recevez le fichier de preuve .ots une fois la confirmation effectuée.

Puis-je vérifier l’horodatage sans utiliser Timestamp GIT ?

Oui. Les preuves sont des fichiers OpenTimestamps .ots standard. N’importe qui peut télécharger le fichier et le vérifier localement contre la blockchain Bitcoin en utilisant des outils open source. Timestamp GIT fournit également un vérificateur web et des certificats PDF.

L’auto-hébergement est-il disponible ?

Oui. Timestamp GIT propose une image Docker pour l’auto-hébergement, adaptée aux environnements isolés du réseau ou hautement réglementés. Une licence de démonstration à durée limitée est disponible sur demande.

Conclusion : configurez et oubliez

L’horodatage manuel est fragile car il dépend de quelqu’un qui se souvient de le faire. Un pipeline basé sur une GitHub App élimine ce mode de défaillance.

Avec Timestamp GIT, vous installez une fois, sélectionnez les dépôts, et laissez le worker nocturne ancrer les hashes de commits dans Bitcoin. Votre équipe continue d’écrire du code normalement. Les preuves s’accumulent automatiquement sous forme de fichiers .ots, de rapports d’audit et de badges de statut.

Installez la GitHub App Timestamp GIT dès aujourd’hui, ou commencez avec le plan gratuit pour les dépôts publics. Les plans Pro et Enterprise sont disponibles pour les dépôts privés et les déploiements zero-knowledge plus stricts.

Installez une application GitHub pour horodater automatiquement vos commits