Horodatage Git automatisé : comment une GitHub App ancre chaque commit

Vous poussez un commit qui compte — le cœur d’une fonctionnalité dont on vous demandera de prouver que vous l’avez construite en premier. Avec l’approche manuelle, c’est le moment où votre flux se brise. Vous vous arrêtez, changez de contexte et entamez un petit rituel d’outillage local et de gestion de preuves pour épingler le commit à un instant précis. Puis vous recommencez au commit suivant, et au suivant, jusqu’au jour où vous oubliez.

C’est le piège de l’horodatage manuel. Les registres d’antériorité ne valent que par leur densité et leur régularité, et les registres issus de processus humains ne sont ni l’une ni l’autre. Les développeurs sautent l’étape pendant un coup de feu, la configurent mal sur une nouvelle machine, ou ne l’installent jamais sur le dépôt qui s’avère finalement important. Les trous dans la chaîne sont exactement ce que recherche un avocat adverse ou un auditeur.

Cet article porte sur le fait de retirer l’humain de cette boucle entièrement grâce à l’horodatage Git automatisé via une GitHub App. Une seule installation, et chaque commit vers un dépôt surveillé est empreinté et ancré dans Bitcoin chaque nuit — par une machine, selon un planning, sans que personne ne tape une commande.

Ceci est un guide d’automatisation, pas une plongée en profondeur dans la cryptographie. Pour le pourquoi, voir Protéger la propriété intellectuelle : un guide pour les développeurs de logiciels et Protection de l’antériorité pour les startups logicielles : un guide. Pour la mécanique de vérification d’une preuve plus tard, voir Vérifier les horodatages de code sans partager votre code source.

(Pour contexte : l’approche brute consiste à exécuter l’outillage OpenTimestamps à la main, commit par commit, et à gérer vous-même vos soumissions de calendrier. C’est la manière difficile. Tout ce qui suit est le chemin automatisé.)

Configuration initiale : installez la GitHub App et oubliez-la

Timestamp GIT est un SaaS managé construit autour d’une GitHub App. Vous l’installez une fois sur un dépôt ou une organisation entière, et l’automatisation prend le relais.

Il existe deux modes de déploiement, et vous choisissez selon le niveau d’accès que vous êtes prêt à accorder :

Mode Standard (GitHub App). La GitHub App lit uniquement le hash du commit HEAD de votre dépôt surveillé — automatiquement, à chaque push. Les preuves sont écrites dans une branche dédiée du même dépôt ou dans un dépôt fantôme séparé. Comme le modèle de permissions de GitHub n’offre pas de portée « hash de commit uniquement », ce mode nécessite un accès en lecture seule au dépôt source et un accès en lecture-écriture au dépôt cible où atterrissent les preuves.

Mode Enterprise ZK (GitHub Action). L’étape de collecte se déplace dans votre propre CI. Une GitHub Action de 12 lignes s’exécute sur vos runners, extrait le hash HEAD et pousse uniquement ce hash vers l’API Timestamp GIT. Le compromis est explicite : vous conservez l’accès en lecture pour vous-même, et Timestamp GIT n’a besoin que d’un accès en lecture-écriture au dépôt cible. Aucun code source et aucun accès en lecture au dépôt ne franchit jamais la frontière.

Deux choses à noter concernant la configuration :

• Rien n’est installé sur les machines des développeurs. Pas de CLI, pas de démon local, pas de dérive de configuration d’un portable à l’autre. L’app s’exécute sur l’infrastructure de GitHub et notre backend ; l’Action s’exécute sur des runners hébergés par GitHub ou auto-hébergés.
• Il n’y a aucune configuration continue. Après l’installation, l’app détecte les nouveaux commits via des webhooks. Personne n’a à se souvenir de quoi que ce soit.

Vous pouvez consulter et gérer les dépôts surveillés depuis votre page de dépôts après l’installation.

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

Une fois l’app installée, voici ce qui se passe réellement entre git push et l’apparition d’un fichier de preuve immuable dans votre dépôt.

1. Détection des commits et mise en lots

Un webhook se déclenche sur les nouveaux commits. L’app — ou votre Action, en mode Enterprise ZK — extrait le hash du commit et le dépose dans un magasin clé-valeur en mémoire. Ce magasin est une file d’attente, pas un registre ; il existe uniquement pour accumuler les hashs jusqu’à l’exécution du lot nocturne.

Seul le hash circule. Jamais le diff, jamais le contenu des fichiers, jamais l’historique de branche.

2. Le worker cron de minuit

Chaque nuit, un worker récupère chaque hash en attente et :

1. Les regroupe par dépôt et écrit un fichier manifeste (.txt) par dépôt.
2. Construit un arbre de Merkle nativement sur le lot.
3. Crée des preuves OpenTimestamps à l’aide de serveurs de calendrier publics.
4. Ancre la racine de Merkle dans la blockchain Bitcoin.

Cette dernière étape est celle qui rend le registre immuable. Une fois la racine confirmée dans un bloc Bitcoin, aucune entité — y compris Timestamp GIT — ne peut la modifier ou la falsifier après coup.

3. Livraison des preuves

Après l’ancrage, le manifeste et les fichiers de reçu .ots correspondants sont poussés dans votre dépôt, soit dans une branche timestamps dédiée, soit dans un dépôt fantôme.

Prévoyez quelques heures pour cela. La confirmation Bitcoin prend généralement environ 3 heures, donc les preuves arrivent en général quelques heures après l’exécution nocturne plutôt qu’immédiatement.

Mode Enterprise ZK : le seul mode avec un fichier de workflow

C’est le seul endroit où vous regarderez jamais du YAML. L’assistant de configuration génère le workflow avec votre endpoint et votre secret pré-remplis ; il ressemble approximativement à ceci :

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Send HEAD hash to Timestamp GIT
        env:
          TSG_ENDPOINT: ${{ secrets.TIMESTAMPGIT_ENDPOINT }}
        run: curl -fsS -X POST "$TSG_ENDPOINT" --data "$(git rev-parse HEAD)"

C’est toute l’intégration. Il existe un guide dédié dans GitHub Action pour l’horodatage de commits : guide de configuration si vous souhaitez approfondir ce mode.

Pipelines personnalisés : l’API ZK Commit

Si vous devez intégrer l’horodatage dans autre chose que le flux standard, l’API ZK Commit accepte directement les hashs de commit. Elle est authentifiée par HMAC — la valeur de hash de l’URL signée doit accompagner la requête — donc une URL divulguée seule ne suffit pas à écrire dans votre registre.

Pour l’automatisation en lecture seule, les endpoints de statut publics sont plus simples :

# Last anchored Bitcoin block for a repo
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

# Total stamped commit count
curl -s https://timestampgit.dev/api/statusCount/your-org/your-repo

# Combined summary (what the Shields.io badge consumes)
curl -s https://timestampgit.dev/api/statusSummary/your-org/your-repo

Surveillance et gestion des échecs

Une automatisation que vous ne pouvez pas auditer n’est pas une automatisation en laquelle vous pouvez avoir confiance lors d’un litige. Timestamp GIT expose l’état de votre chaîne de preuves à trois endroits.

Le tableau de bord de statut public

/status/{user}/{repo} affiche la longévité des preuves, la date d’ancrage la plus ancienne, la régularité quotidienne, ainsi que les données de bloc et de transaction Bitcoin derrière chaque ancrage. Il y a une carte thermique calendaire pour que les trous soient visuellement évidents, plus des exports CSV d’audit et de certificats PDF téléchargeables.

La régularité est la métrique à surveiller. Une carte thermique trouée raconte une histoire d’antériorité plus faible qu’une carte pleine.

Badges de vérification

Vous pouvez intégrer des badges Shields.io dans votre README pour afficher publiquement le statut de vérification. Le widget à /connected/{user}/{repo} vous donne un aperçu en direct et l’extrait markdown, et /api/badgeLink/{user}/{repo} renvoie les URLs de badge et l’extrait par programmation.

Les dépôts privés ajoutent un HMAC chiffré aux URLs de badge et de statut, limité à l’instance serveur. Cela signifie que le badge s’affiche toujours tandis que seuls les utilisateurs autorisés peuvent résoudre les données de statut sous-jacentes.

Quand une exécution nocturne échoue

L’échec le plus probable est une congestion du réseau Bitcoin retardant la confirmation. Le système réessaie plutôt que d’abandonner le lot. Vérifiez l’état via le tableau de bord, ou via l’API si vous connectez cela à votre propre système d’alerte :

# Confirm the latest anchored block; a stale value means the last run didn't land
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo | jq .

Si vous avez besoin de preuves ponctuelles pour la conformité, récupérez directement les artefacts :

# Full audit ledger as CSV
curl -sO https://timestampgit.dev/api/audit/your-org/your-repo

# PDF certificate for a specific date
curl -sO https://timestampgit.dev/api/report/your-org/your-repo/2026-10-04

N’importe qui peut aussi vérifier indépendamment l’horodatage d’une seule journée via /verification/{user}/{repo}/{date}, où le calcul complet de la chaîne de Merkle se fait localement dans le navigateur. Personne — y compris Timestamp GIT — ne voit ce que vous vérifiez.

Environnements isolés (air-gapped)

Si votre posture de sécurité n’autorise pas du tout un service managé, 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 vous guide pour connecter votre GitHub App et configurer l’instance au premier lancement. Une licence de démonstration à durée limitée pour l’évaluation est disponible via la page Docker License. Horodatage blockchain auto-hébergé avec Docker couvre ce chemin en détail.

Bonnes pratiques pour l’horodatage automatisé

• Commitez régulièrement, en lots de taille raisonnable. Chaque commit ajoute une feuille à l’arbre de Merkle quotidien. Une chaîne dense constitue un meilleur registre d’antériorité que quatre commits géants par trimestre.
• Écrivez des messages de commit significatifs. Seuls les hashs sont horodatés, mais lors d’un audit vous devrez corréler les preuves aux fonctionnalités. De bons messages rendent cette mise en correspondance triviale.
• Mettez en place des alertes sur les ancrages obsolètes. Un badge vert doit signifier qu’une exécution récente a réussi, pas qu’une exécution a eu lieu une fois en mars.
• Ne touchez pas au workflow. Le plus grand risque de l’horodatage automatisé est que quelqu’un « améliore » le pipeline. La configuration par défaut n’a aucune étape manuelle pour une raison.
• Optez pour le mode Enterprise ZK quand votre source ne peut pas être lue. Si la conformité interdit d’accorder un accès en lecture au dépôt à un tiers, exécutez l’Action sur vos propres runners.
• Dites à votre équipe que c’est automatique. Les ingénieurs qui pensent que l’horodatage est une tâche manuelle finiront par essayer de le faire manuellement, et c’est ainsi qu’apparaissent des entrées en double ou malformées.

Vous pouvez commencer depuis timestampgit.dev — installez l’app, connectez un dépôt, et laissez le premier lot nocturne s’exécuter.

FAQ

Q : Dois-je modifier mon workflow Git pour utiliser l’horodatage automatisé ? R : Non. Une fois que vous installez la GitHub App Timestamp GIT, elle détecte automatiquement les nouveaux commits via des webhooks et les horodate chaque nuit. Vous continuez à commiter comme d’habitude — aucune commande ni étape supplémentaire.

Q : Que se passe-t-il si j’utilise plusieurs branches ou dépôts ? R : La GitHub App surveille toutes les branches des dépôts auxquels vous accordez l’accès. Vous pouvez aussi configurer les dépôts surveillés. Pour plusieurs dépôts, chacun obtient son propre manifeste et ses propres fichiers de preuve.

Q : Mon code source est-il un jour exposé à Timestamp GIT ? R : Non. En mode Standard, l’app lit uniquement le hash du commit HEAD — jamais votre code source. En mode Enterprise ZK, une GitHub Action sur votre infrastructure pousse uniquement le hash du commit vers notre API, donc votre code ne quitte jamais votre environnement.

Q : Combien de temps faut-il pour qu’un commit soit horodaté ? R : Les hashs de commit sont mis en lots et ancrés dans Bitcoin une fois par nuit. Après l’exécution nocturne, la transaction Bitcoin prend généralement environ 3 heures pour être confirmée, après quoi les fichiers de preuve .ots sont poussés dans votre dépôt.

Conclusion

L’horodatage manuel échoue pour la même raison que toute conformité manuelle échoue : il dépend d’un humain qui se souvient, à chaque fois, pour toujours. La GitHub App supprime cette dépendance. Installez-la une fois, et chaque commit sur vos dépôts surveillés est empreinté, mis en lot, enraciné en Merkle et ancré dans Bitcoin selon un planning nocturne — avec des badges, un tableau de bord de statut public, un CSV d’audit, des certificats PDF et une vérification locale dans le navigateur pour le soutenir.

Si vous évaluez cela pour une équipe, commencez par un seul dépôt privé et regardez la première semaine de carte thermique se remplir. Décidez ensuite jusqu’où le déployer.

Installez la GitHub App, connectez votre premier dépôt, et laissez le worker de minuit faire le reste.

Articles liés

• Protéger la propriété intellectuelle : un guide pour les développeurs de logiciels
• Protection de l’antériorité pour les startups logicielles : un guide
• GitHub Action pour l’horodatage de commits : guide de configuration