Timestamp GIT Secure your prior art without exposing code

← Tous les articles

2026-08-31

Horodatez automatiquement chaque commit Git avec une application GitHub

Horodatez automatiquement chaque commit Git avec une application GitHub
timestamp git blockchain proof

Horodatez automatiquement chaque commit Git avec une application GitHub

Chaque fois que vous commitez, Git génère déjà un hachage unique qui identifie l’état exact de votre dépôt. Ce hachage est une empreinte cryptographiquement sécurisée de votre travail à cet instant précis. Ce qu’il n’est pas, en soi, c’est une preuve du moment où ce travail a existé. Transformer ce hachage en preuve immuable et recevable devant un tribunal signifiait autrefois un processus manuel : exécuter des commandes supplémentaires, surveiller la sortie, stocker des fichiers de reçu et répéter l’opération pour chaque commit.

L’alternative automatisée est plus simple : installez une application GitHub une seule fois, sélectionnez vos dépôts, et laissez chaque futur commit être ancré dans la blockchain Bitcoin pendant que vous dormez.

Timestamp GIT est un service géré construit autour de cette idée. Il automatise entièrement le protocole OpenTimestamps afin que vous n’ayez jamais besoin de toucher à une CLI, de construire une transaction Bitcoin ou de gérer des fichiers de preuve à la main. Cet article couvre la configuration unique, le pipeline d’automatisation nocturne, la surveillance, les bonnes pratiques et les questions fréquentes.

Configuration unique : installer l’application GitHub Timestamp GIT

L’ensemble du produit est conçu autour d’un flux de configuration unique. Après cela, committer du code est la seule action que vous devez effectuer.

Mode standard : application GitHub

  1. Installez l’application GitHub Timestamp GIT depuis le GitHub Marketplace.
  2. Accordez les autorisations demandées lors de l’installation. En mode standard, l’application nécessite un accès en lecture seule au dépôt source, car les autorisations GitHub n’offrent pas de portée limitée aux seuls hachages de commit. Timestamp GIT ne lit, ne copie ni ne stocke jamais votre code source.
  3. Sélectionnez les dépôts que vous souhaitez surveiller. Les dépôts publics sont pris en charge par le plan Open Source gratuit ; les dépôts privés nécessitent un plan payant.
  4. Choisissez où les fichiers de preuve doivent résider. Vous pouvez les stocker dans une branche dédiée timestamps dans le même dépôt, ou dans un dépôt cible séparé. Un dépôt miroir séparé garde l’historique de votre source principale propre.

Après l’installation, l’application GitHub surveille automatiquement les dépôts sélectionnés. Il n’y a aucune CLI à installer, aucune commande OpenTimestamps à apprendre et aucune étape manuelle à exécuter après la configuration.

Mode Enterprise ZK : GitHub Action

Pour les organisations qui souhaitent une isolation maximale, Timestamp GIT propose un mode Enterprise ZK. Au lieu de donner à l’application GitHub un accès en lecture à votre dépôt source, une GitHub Action s’exécute sur votre propre infrastructure et envoie uniquement le hachage du commit à l’API Timestamp GIT.

La forme du workflow ressemble à ceci :

name: timestamp-git-zk

on:
  push:

jobs:
  timestamp:
    runs-on: ubuntu-latest
    steps:
      - name: Push commit hash to Timestamp GIT
        env:
          COMMIT_SHA: ${{ github.sha }}
          REPO: ${{ github.repository }}
        run: |
          curl -fsS -X POST \
            -H "Authorization: Bearer ${{ secrets.TIMESTAMP_GIT_HMAC }}" \
            -H "Content-Type: application/json" \
            -d "{\"repo\":\"$REPO\",\"hash\":\"$COMMIT_SHA\"}" \
            "${{ vars.TIMESTAMP_GIT_API_URL }}"

L’URL exacte de l’API, les identifiants de dépôt et le secret HMAC sont fournis lors de l’assistant de configuration Enterprise. L’important est ce que le workflow ne fait pas : il n’envoie jamais de code source, de fichiers ou de contenu de dépôt. Il envoie un hachage de commit et rien d’autre.

Dans ce mode, Timestamp GIT n’a besoin d’aucun accès en lecture à votre dépôt source.

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

Une fois l’application GitHub ou la GitHub Action en place, l’horodatage devient une tâche d’arrière-plan.

1. Détection des commits

En mode standard, l’application GitHub reçoit des webhooks lorsque de nouveaux commits arrivent dans vos dépôts surveillés. En mode Enterprise ZK, votre GitHub Action envoie directement le hachage du commit à l’API.

2. File d’attente des hachages

Les hachages de commit détectés entrent dans un stockage clé-valeur en mémoire où ils attendent le traitement par lots. Timestamp GIT n’analyse pas votre code, ne clone pas votre dépôt complet et n’inspecte pas le contenu des fichiers.

3. Worker cron nocturne

Chaque nuit, un worker regroupe tous les hachages en attente par dépôt. Pour chaque dépôt, il crée un fichier manifeste, construit un arbre de Merkle de manière native et crée des preuves OpenTimestamps à l’aide de calendriers OTS publics.

4. Ancrage Bitcoin

La racine de Merkle du lot quotidien est intégrée dans une transaction Bitcoin à l’aide du protocole OpenTimestamps. Une fois cette transaction confirmée dans un bloc Bitcoin, l’ancrage devient immuable. Aucune entité — y compris Timestamp GIT — ne peut l’altérer ou le falsifier.

La confirmation Bitcoin prend normalement environ trois heures. Cela signifie qu’un commit effectué pendant la journée de travail est généralement ancré le lendemain matin.

5. Livraison des preuves

Après confirmation, le manifeste et les fichiers de reçu .ots sont renvoyés vers votre emplacement de preuve configuré : soit une branche timestamps dédiée, soit un dépôt miroir. Les fichiers de preuve sont de petits fichiers texte et binaires qui prouvent que votre hachage de commit existait avant que le bloc Bitcoin ne soit miné.

Vous pouvez interroger le dernier bloc ancré pour un dépôt public avec un simple appel API :

curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

La réponse contient les informations du dernier bloc Bitcoin ancré. Des endpoints supplémentaires renvoient le nombre total de commits horodatés, des résumés de statut combinés et les données complètes de la chaîne de Merkle pour un jour spécifique.

Surveillance et gestion des échecs

L’automatisation n’est utile que lorsque vous pouvez constater qu’elle fonctionne.

Tableau de bord de statut du dépôt

Chaque dépôt connecté dispose d’une page de statut publique ou authentifiée. Le tableau de bord affiche :

  • La longévité des preuves : jusqu’où remonte votre date d’ancrage la plus ancienne
  • La régularité quotidienne : si les commits sont traités par lots de manière cohérente
  • Les données de bloc et de transaction Bitcoin pour chaque ancrage
  • Une carte thermique calendaire pour une vue visuelle de l’activité

La page de statut vous donne une réponse rapide à la question : « Les commits d’hier ont-ils été ancrés ? »

Exports d’audit et de conformité

Timestamp GIT fournit des enregistrements d’audit téléchargeables :

# Download a full audit ledger as CSV
curl -o audit.csv https://timestampgit.dev/api/audit/your-org/your-repo

Vous pouvez également télécharger un certificat PDF pour une date spécifique. Ces exports sont utiles pour les archives de conformité, les revues juridiques ou la documentation de propriété intellectuelle au niveau de la direction.

Gestion des commits manqués

En fonctionnement normal, un commit qui manque le lot nocturne — par exemple, parce qu’une livraison de webhook a été retardée — est récupéré lors de l’exécution nocturne suivante. La conception orientée par lots signifie que les échecs temporaires ne vous obligent pas à réexécuter quoi que ce soit manuellement.

Confidentialité des dépôts privés

Pour les dépôts privés, les endpoints de statut sont protégés par un HMAC chiffré. Seuls les utilisateurs autorisés disposant de la signature d’URL correcte peuvent consulter le statut du dépôt. Le HMAC est spécifique à l’instance serveur, de sorte que les données de statut ne sont pas exposées au public.

Bonnes pratiques pour l’horodatage automatisé

Une application GitHub peut automatiser la mécanique, mais quelques choix de configuration rendent la preuve plus solide et plus facile à gérer.

Surveillez tous les dépôts actifs

Ne surveillez pas uniquement les branches de release. Les litiges d’antériorité reposent souvent sur un commit expérimental précoce, une branche en cours de développement ou un prototype rapide. Activez la surveillance sur chaque dépôt où du code significatif est écrit.

Utilisez un dépôt miroir dédié

Si vous ne voulez pas que les fichiers de preuve encombrent votre dépôt principal, configurez Timestamp GIT pour envoyer les preuves vers un dépôt séparé. Cela garde l’historique source propre tout en offrant aux avocats, auditeurs et équipes de conformité un endroit unique où chercher les reçus de preuve.

Choisissez le mode Enterprise ZK pour une isolation maximale

Si votre code est hautement sensible ou si votre politique de sécurité interdit l’accès en lecture par des tiers aux dépôts source, utilisez le mode Enterprise ZK. L’approche GitHub Action signifie que votre code source ne quitte jamais votre environnement. Timestamp GIT ne reçoit jamais que des hachages de commit.

Archivez régulièrement les CSV d’audit

Les fichiers .ots constituent la preuve cryptographique, mais les CSV d’audit sont l’enregistrement lisible par l’homme. Téléchargez-les selon un calendrier régulier et stockez-les avec vos autres documents de conformité. En cas de litige, disposer d’un registre chronologique propre fait gagner du temps.

Ajoutez des badges de vérification à votre README

Les dépôts publics peuvent afficher un badge de vérification qui renvoie vers la page de statut Timestamp GIT. La page de connexion du dépôt fournit les URL de badge et les extraits Markdown. Un badge typique ressemble à ceci :

[![Timestamp GIT verification](https://timestampgit.dev/api/badgeLink/your-org/your-repo)](https://timestampgit.dev/status/your-org/your-repo)

Toute personne consultant le dépôt peut cliquer et vérifier le statut d’horodatage actuel sans rien installer.

FAQ

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

Une fois installée, l’application GitHub surveille vos dépôts sélectionnés. Chaque nuit, elle collecte tous les nouveaux hachages de commit, crée un arbre de Merkle, ancre la racine dans la blockchain Bitcoin via OpenTimestamps et renvoie les fichiers de preuve .ots vers votre dépôt. Aucune étape manuelle n’est requise.

L’application GitHub a-t-elle besoin d’accéder à mon code source ?

En mode standard, l’application GitHub nécessite un accès en lecture seule au dépôt source pour lire les hachages de commit, car les autorisations GitHub exigent cette portée. Cependant, Timestamp GIT ne lit, ne copie ni ne stocke jamais votre code source — il traite uniquement le hachage du commit. En mode Enterprise ZK, une GitHub Action s’exécute sur votre infrastructure et envoie uniquement le hachage du commit à l’API, de sorte que l’application n’a aucun accès à votre dépôt source.

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

Les commits sont traités par lots chaque nuit. Après le traitement du lot, la transaction Bitcoin est diffusée. La confirmation sur la blockchain Bitcoin prend généralement environ trois heures, après quoi les fichiers de preuve sont écrits dans votre dépôt. Un commit effectué pendant la journée aura généralement sa preuve d’horodatage disponible le lendemain matin.

Puis-je vérifier l’horodatage sans dépendre de Timestamp GIT ?

Oui. La preuve est un fichier OpenTimestamps .ots standard. Vous pouvez le télécharger et le vérifier localement à l’aide de n’importe quel outil de vérification OpenTimestamps contre la blockchain Bitcoin. Timestamp GIT fournit également une page de vérification web et des certificats PDF pour plus de commodité.

Conclusion : configurez et oubliez

Timestamp GIT transforme la protection cryptographique de l’antériorité d’une corvée manuelle en un processus d’arrière-plan automatique. Installez l’application GitHub une fois, sélectionnez vos dépôts, et chaque futur commit passe par le même pipeline : détection des hachages, traitement par lots nocturne, construction de l’arbre de Merkle, ancrage Bitcoin et livraison des preuves.

Le modèle de sécurité est intentionnellement à connaissance nulle. Votre code source n’est jamais lu ni stocké. Le mode standard ne traite que les hachages de commit, et le mode Enterprise ZK garde même ces hachages sous votre contrôle jusqu’à ce que vous les envoyiez à l’API.

La tarification couvre les cas courants : Open Source est gratuit pour les dépôts publics, Pro Agency coûte 49 $/mois pour les dépôts privés, et Enterprise ZK coûte 199 $/mois avec prise en charge des GitHub Actions. Pour les environnements air-gapped ou autogérés, une licence Docker auto-hébergée est également disponible.

Si vous créez encore manuellement des horodatages pour des commits individuels, le chemin le plus rapide est d’installer l’application GitHub Timestamp GIT ou de demander une licence Docker auto-hébergée pour un contrôle maximal.

Articles connexes

EU label: AI-generated content