Horodater automatiquement les commits Git avec une application GitHub

Vous savez déjà que prouver quand un commit a existé peut être aussi important que le code lui-même. Si des trolls de brevets, des litiges clients ou un ancien collaborateur remettent un jour en question votre chronologie, un journal Git auto-hébergé ne suffit généralement pas. Les journaux internes peuvent être modifiés, et l’historique d’un dépôt hébergé n’est pas une preuve immuable d’antériorité.

La méthode difficile consiste à apprendre le protocole d’horodatage sous-jacent, exécuter des commandes manuelles pour chaque commit, copier les hachages, attendre les confirmations et stocker les reçus dans un endroit sûr. Cette approche s’effondre dès que vous avez plusieurs dépôts, plusieurs développeurs ou une semaine de release chargée.

Timestamp GIT supprime entièrement cette charge manuelle. Vous installez une application GitHub une seule fois, sélectionnez les dépôts que vous souhaitez protéger, et chaque nouveau commit est automatiquement horodaté dans la blockchain Bitcoin selon un planning nocturne. Aucun outil CLI à exécuter, aucun fichier de reçu à gérer à la main, aucune commande OpenTimestamps à apprendre.

Si vous découvrez la raison sous-jacente de l’importance de tout cela, consultez Qu’est-ce que l’antériorité cryptographique et pourquoi est-ce important pour les logiciels ?.

Cet article parcourt le chemin automatisé : la configuration unique, ce qui se passe entre le commit et l’ancrage Bitcoin, comment surveiller vos preuves et comment maintenir le processus sain dans le temps.

Configuration unique : installer l’application GitHub

Toute la configuration consiste en l’installation d’une application GitHub. Il n’y a pas d’agent local, pas de fichier de configuration et pas de script à maintenir.

Voici la séquence :

1. Installez l’application GitHub Timestamp GIT depuis le GitHub Marketplace.
2. Sélectionnez les dépôts que vous souhaitez surveiller.
   • Les dépôts publics sont pris en charge dans l’offre gratuite.
   • Les dépôts privés nécessitent le plan Pro ou Enterprise.
3. Choisissez votre mode de déploiement :
   • Mode Standard : l’application GitHub lit le hachage du commit HEAD depuis le dépôt source et écrit les fichiers de preuve dans un dépôt ou une branche cible.
   • Mode Enterprise ZK : une GitHub Action exécutée dans votre environnement pousse uniquement les hachages de commit vers l’API Timestamp GIT. Timestamp GIT n’a aucun accès en lecture au dépôt source.
4. Confirmez les accès.
   • Le mode Standard nécessite un accès en lecture au dépôt source et un accès en lecture-écriture au dépôt cible. C’est une exigence du système de permissions GitHub : il n’existe pas de permission en lecture limitée au hachage de commit.
   • Le mode Enterprise ZK nécessite uniquement un accès en lecture-écriture au dépôt cible. Le dépôt source n’a jamais besoin d’accorder un accès en lecture à Timestamp GIT.
5. Terminé. À partir de ce moment, les nouveaux commits sont détectés automatiquement.

Après l’installation, vous pouvez gérer les dépôts surveillés depuis le tableau de bord Timestamp GIT. Il n’y a rien à compiler, aucun démon à exécuter et aucune tâche cron à configurer.

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

Une fois l’application GitHub installée, le processus s’exécute sans que vous y pensiez.

Ce qui se passe après chaque commit

Lorsque vous poussez un commit vers un dépôt surveillé, l’application GitHub détecte le nouveau commit via un webhook. L’application ne lit pas vos fichiers sources. Elle extrait uniquement le hachage du commit — une empreinte cryptographiquement sécurisée de l’état du dépôt à cet instant.

Ce hachage de commit est placé dans une file d’attente pour le prochain lot nocturne.

L’exécution d’ancrage nocturne

Chaque nuit, un processus worker exécute le pipeline suivant :

1. Tous les hachages de commit en file d’attente pour chaque dépôt surveillé sont collectés.
2. Les fichiers manifeste sont créés pour la journée.
3. Un arbre de Merkle est construit à partir des hachages collectés.
4. La racine de Merkle est ancrée dans la blockchain Bitcoin en utilisant le protocole OpenTimestamps.
5. Les reçus de preuve sont générés et renvoyés vers une branche d’horodatage dédiée ou un dépôt miroir.

La confirmation Bitcoin elle-même prend généralement quelques heures. Cela signifie que les fichiers de preuve apparaissent généralement dans votre dépôt quelques heures après l’exécution nocturne, pas immédiatement après le commit.

Livraison des preuves

Le livrable est un fichier de reçu .ots accompagné du manifeste quotidien. Ces fichiers sont écrits dans une branche dédiée ou un dépôt miroir, ce qui les maintient séparés de votre historique source normal.

Vous pouvez vérifier le résultat avec des commandes Git ordinaires :

# Après la fin de l'ancrage nocturne
git fetch origin

# Cherchez la branche d'horodatage dédiée ou le dépôt miroir
git branch -r

# Basculez sur la branche qui contient les reçus .ots
git checkout <timestamps-branch>

# Listez les fichiers de preuve quotidiens
ls -1 *.ots

Le nom exact de la branche dépend de la configuration de votre dépôt.

Mode Enterprise ZK

Pour les équipes qui ne peuvent accorder aucun accès au code source à un tiers, le mode Enterprise ZK modifie le flux de données.

Au lieu que l’application GitHub lise les métadonnées du dépôt source, une petite GitHub Action s’exécute dans votre infrastructure. L’action pousse uniquement le hachage du commit vers l’API Timestamp GIT. Timestamp GIT ne reçoit jamais de code, ne lit jamais le dépôt source et ne voit jamais rien d’autre que le hachage.

Le pipeline d’ancrage nocturne est identique à partir de ce point : file d’attente de hachages, manifeste, arbre de Merkle, preuve OpenTimestamps, ancrage Bitcoin et livraison des preuves vers votre dépôt cible.

Surveillance et gestion des échecs

L’automatisation ne signifie pas une confiance aveugle. Vous devez pouvoir voir que le système fonctionne, et vous devez avoir un chemin clair lorsque quelque chose semble anormal.

Tableau de bord de statut des dépôts

Chaque dépôt surveillé dispose d’une page de statut qui affiche :

• La longévité des preuves, y compris la date d’ancrage la plus ancienne.
• La régularité de l’ancrage quotidien.
• Les données de bloc et de transaction Bitcoin liées à chaque horodatage.
• Une carte de chaleur calendaire des jours ancrés.
• Des rapports d’audit téléchargeables en CSV et des certificats PDF.

Vous pouvez également interroger le statut via l’API publique :

curl -s https://timestampgit.dev/api/statusLast/$GITHUB_USER/$GITHUB_REPO | jq .

Les dépôts privés ajoutent un HMAC chiffré aux URL de statut. Seuls les utilisateurs autorisés peuvent consulter les horodatages des dépôts privés, et le HMAC est spécifique à l’instance serveur.

Badges README

Timestamp GIT fournit des badges intégrables pour votre README. Le badge affiche l’état de vérification actuel, et toute personne qui clique peut vérifier l’horodatage depuis la page liée. C’est utile pour les projets open source et pour les agences qui souhaitent montrer publiquement une preuve de travail sans exposer de code privé.

Exports d’audit et de conformité

Pour un examen de conformité ou juridique, vous pouvez télécharger :

• Un registre d’audit complet au format CSV.
• Un certificat PDF pour une date spécifique.

Ces fichiers vous donnent un enregistrement hors chaîne qui complète les reçus cryptographiques dans votre dépôt.

Que se passe-t-il si un commit est manqué ?

Si un commit n’est pas traité dans le lot nocturne attendu, le hachage en file d’attente reste dans la file d’horodatage et est récupéré lors de l’exécution suivante. Le tableau de bord de statut du dépôt est le premier endroit à vérifier pour détecter des lacunes ou des irrégularités. Si un dépôt affiche systématiquement des jours manquants, contactez le support avant de vous appuyer sur la plage concernée pour une revendication juridique.

Option Docker auto-hébergée

Pour les environnements isolés ou un contrôle opérationnel maximal, Timestamp GIT est disponible sous forme d’image Docker. Une instance auto-hébergée utilise le même flux de travail d’application GitHub mais s’exécute sur une infrastructure que vous possédez.

Une configuration Docker 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 après le démarrage. Au premier lancement, un assistant de configuration vous guide pour connecter votre application GitHub et configurer l’instance. Une licence de démonstration limitée dans le temps est disponible pour l’évaluation.

Bonnes pratiques pour l’horodatage automatisé

L’automatisation supprime le travail répétitif, mais quelques habitudes rendent votre historique d’horodatage beaucoup plus solide.

Commitez fréquemment. Le pipeline ancre des lots quotidiens. Si vous ne commitez qu’une fois par mois, vous créez moins de points de preuve et des écarts plus grands entre les ancrages. Des commits réguliers créent un enregistrement d’antériorité dense et continu.

Utilisez des messages de commit significatifs. Ce sont les hachages de commit qui sont horodatés, mais la piste d’audit lisible par un humain compte toujours. Un message comme Implémenter le préchauffage du cache pour les réponses API est bien plus utile dans un litige que corriger des trucs.

Gardez les reçus .ots séparés du code source. Traitez la branche d’horodatage ou le dépôt miroir comme un magasin de preuves en ajout uniquement. Évitez de le modifier, de le squasher ou de le supprimer.

Vérifiez régulièrement un échantillon. Au moins une fois par trimestre, ouvrez la page de vérification publique pour un horodatage représentatif et confirmez que la preuve de Merkle se résout correctement. Cela permet de détecter une dérive de configuration avant d’avoir besoin de la preuve.

Utilisez le mode Enterprise ZK pour les projets sensibles. Si le dépôt contient des secrets commerciaux, des outils internes ou de la logique produit non publiée, le mode Enterprise ZK est le choix par défaut le plus sûr. Timestamp GIT ne voit jamais que des hachages de commit, et votre code ne quitte jamais votre environnement.

Envisagez l’auto-hébergement Docker pour les environnements réglementés. Si vous avez besoin d’un fonctionnement isolé ou d’un contrôle total sur la connexion de l’application GitHub, auto-hébergez avec l’image Docker.

FAQ

Comment fonctionne l’horodatage automatique avec une application GitHub ?

Une fois que vous installez l’application GitHub Timestamp GIT et sélectionnez des dépôts, l’application détecte automatiquement les nouveaux commits via des webhooks. Chaque nuit, elle regroupe tous les hachages de commit, crée un arbre de Merkle et ancre la racine dans la blockchain Bitcoin en utilisant OpenTimestamps. Les reçus de preuve (fichiers .ots) sont ensuite renvoyés vers une branche dédiée dans votre dépôt — aucune étape manuelle requise.

Mon code source est-il jamais exposé à Timestamp GIT ?

Non. Timestamp GIT traite uniquement les hachages de commit Git, pas le code source réel. En mode Standard, l’application GitHub nécessite un accès en lecture au dépôt pour récupérer le hachage du commit, mais elle ne lit jamais le contenu des fichiers. En mode Enterprise ZK, une GitHub Action s’exécute sur votre infrastructure et pousse uniquement le hachage du commit vers l’API, donc Timestamp GIT n’a aucun accès à votre code.

Que se passe-t-il si Timestamp GIT cesse son activité ?

Vos horodatages restent valides pour toujours. Les preuves sont ancrées dans la blockchain Bitcoin et reposent uniquement sur SHA-256 et les données de bloc Bitcoin. Vous pouvez les vérifier indépendamment en utilisant les outils OpenTimestamps standard, même si Timestamp GIT cesse d’exister. Les fichiers de reçu .ots sont stockés dans votre dépôt, donc vous les avez toujours.

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. Pour les dépôts privés, les badges de statut et les liens de vérification incluent un HMAC chiffré afin que seuls les utilisateurs autorisés puissent consulter le statut de l’horodatage. Le mode Enterprise ZK est recommandé pour une confidentialité maximale, car il ne nécessite aucun accès en lecture au dépôt source.

Configurez et oubliez

L’horodatage manuel échoue parce qu’il dépend de quelqu’un qui se souvient de le faire. La valeur de l’antériorité cryptographique vient de la cohérence sur des mois et des années, pas d’un effort héroïque ponctuel.

Timestamp GIT transforme cette cohérence en infrastructure. Installez l’application GitHub une fois, connectez vos dépôts, et le worker nocturne gère l’empreinte, le regroupement, l’ancrage Bitcoin et la livraison des preuves. Vous obtenez une preuve immuable d’antériorité sans charge opérationnelle continue.

L’offre gratuite couvre les dépôts publics. Pro ajoute les dépôts privés à 49 $/mois, et le mode Enterprise ZK coûte 199 $/mois avec le workflow GitHub Action. Pour les environnements isolés ou réglementés, la licence Docker auto-hébergée est également disponible.

Commencez à construire votre portefeuille d’antériorité cryptographique dès aujourd’hui : installez l’application GitHub Timestamp GIT et connectez votre premier dépôt.

Articles connexes

• Qu’est-ce que l’antériorité cryptographique et pourquoi est-ce important pour les logiciels ?
• Comment prouver que du code existait à un moment précis (sans le révéler)
• Qu’est-ce que la preuve cryptographique de paternité pour le code ?