2026-10-06 timestamp git blockchain proof

Comment vérifier l’horodatage Bitcoin d’un dépôt Git

Vous avez un reçu .ots dans votre dépôt. Maintenant, quelqu’un — un avocat, un auditeur, un acquéreur effectuant une due diligence technique — pose la seule question qui compte : comment savons-nous que c’est réel ?

Cette question est tout l’enjeu de l’antériorité cryptographique. Un horodatage que vous ne pouvez pas vérifier indépendamment n’est qu’une affirmation dans une base de données. Un horodatage que n’importe qui peut vérifier par rapport à la blockchain Bitcoin est une preuve. Cet article détaille le parcours de vérification pour les dépôts ancrés par Timestamp GIT, du badge README jusqu’à la preuve de Merkle.

Pourquoi la vérification compte pour les horodatages Git

L’historique Git est étonnamment facile à contester. Les dates de commit sont définies par la machine qui a effectué le commit, elles peuvent donc être antidatées avec une simple variable d’environnement. L’historique hébergé réside sur des serveurs que vous ne contrôlez pas, et l’historique auto-hébergé réside dans une base de données qu’une personne disposant de droits d’administration peut réécrire. Lors d’un audit juridique, les deux sont systématiquement rejetés comme intéressés.

L’ancrage cryptographique comble cette lacune — mais uniquement si la preuve peut être vérifiée par un tiers qui ne fait confiance ni à vous ni au fournisseur. Cela implique deux exigences :

La vérification ne doit pas exiger de faire confiance à Timestamp GIT. La preuve est une chaîne de hachages SHA-256 se terminant par un bloc Bitcoin. N’importe qui peut parcourir cette chaîne avec des outils open source.
La vérification ne doit pas exiger d’exposer votre code source. Timestamp GIT fonctionne sur un modèle à divulgation nulle de connaissance : le service reçoit des hachages de commit, jamais le contenu des fichiers. Il n’y a rien à inspecter hormis des hachages — ce qui est exactement ce que souhaite un auditeur, puisque cela signifie que la preuve peut être partagée sans partager la base de code.

En raison de cette conception, la vérification est un exercice cryptographique, et non une revue de code. Les auditeurs, la partie adverse ou l’équipe d’ingénierie d’une société acquéreuse peuvent tous valider le même reçu et parvenir à la même conclusion.

À quoi ressemble une preuve Timestamp GIT

Après l’exécution d’ancrage nocturne, chaque dépôt surveillé reçoit trois artefacts :

Un manifeste quotidien (.txt) — la liste des hachages de commit regroupés pour ce jour, un fichier par dépôt.
Une racine de Merkle — le hachage SHA-256 unique calculé à partir de ce manifeste. Tous les hachages individuels se réduisent à une seule valeur.
Un reçu .ots — la preuve OpenTimestamps qui lie la racine de Merkle à un bloc Bitcoin spécifique.

Ces artefacts sont repoussés dans votre dépôt sur une branche dédiée aux horodatages, ou dans un dépôt fantôme séparé si vous préférez garder le dépôt source propre. Dans les deux cas, les preuves sont versionnées aux côtés du code qu’elles attestent, mais dans leur propre référence — rien n’est jamais commité dans vos branches de travail.

Deux choses méritent d’être énoncées clairement :

La preuve ne contient aucun code source. Uniquement des hachages de commit et leurs réductions cryptographiques.
La preuve n’est pas propriétaire. Il s’agit d’un reçu OpenTimestamps standard sur une transaction Bitcoin, et il reste valide que Timestamp GIT existe encore ou non.

Une fois le fichier de reçu dans votre dépôt, vous disposez de tout ce qu’il faut pour vérifier — le reste n’est qu’une question d’outillage.

Vérification étape par étape avec les outils de Timestamp GIT

Étape 1 — Localiser la preuve

Ouvrez la branche des horodatages (ou le dépôt fantôme) et trouvez le manifeste correspondant à la date en question, ainsi que le fichier .ots correspondant. Si vous préférez ne pas fouiller dans les branches, la page de statut du dépôt affiche les mêmes informations dans un navigateur :

https://timestampgit.dev/status/{user}/{repo}

Étape 2 — Consulter la page de statut publique

La page de statut est le contrôle de cohérence le plus rapide. Elle affiche :

La longévité de la preuve et la date d’ancrage la plus ancienne
La régularité quotidienne (une carte thermique calendaire des jours ancrés)
Le bloc et la transaction Bitcoin qui portent l’ancre
Des liens de téléchargement pour le CSV d’audit et le certificat PDF

Pour les vérifications automatisées, les mêmes données sont exposées en JSON :

# Dernier bloc Bitcoin ancré
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service

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

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

Étape 3 — Vérifier une date spécifique dans le navigateur

Pour une preuve au niveau du jour, utilisez la page de vérification cryptographique :

https://timestampgit.dev/verification/{user}/{repo}/{date}

Cette page effectue la vérification complète de la chaîne de Merkle à plusieurs niveaux localement dans votre navigateur. Le hachage de commit, le manifeste, le chemin de Merkle et l’en-tête du bloc Bitcoin sont tous vérifiés sur votre machine — la page ne téléverse pas ce que vous vérifiez. Cette propriété est importante lorsque le dépôt est privé ou sous NDA : l’auditeur peut confirmer la preuve sans que le fournisseur apprenne quelle date l’intéressait.

Étape 4 — Récupérer le registre d’audit ou le certificat PDF

Les équipes de conformité ont généralement besoin d’un artefact qu’elles peuvent classer. Les deux sont à une requête de distance :

# Registre d'audit complet au format CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv

# Certificat PDF pour un jour
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf

Étape 5 — Facultativement, intégrer un badge de vérification

Le widget de badge à l’adresse /connected/{user}/{repo} vous offre un aperçu en direct et un extrait Markdown prêt à coller pour votre README. Intégrez-le et n’importe qui — un client, un investisseur, un acquéreur potentiel — peut cliquer pour accéder à la vue de vérification publique :

<!-- Extrait copié depuis https://timestampgit.dev/connected/acme/payments-service -->
[![Bitcoin-timestamped](BADGE_IMAGE_URL)](VERIFY_LINK)

Chaque étape ci-dessus fonctionne avec le workflow géré de la GitHub App. Vous installez l’application une fois, et la vérification se résume à un chargement de page ou une requête HTTP — aucun outil en ligne de commande, aucune gestion manuelle du protocole, rien à maintenir sur les machines des développeurs.

Interpréter les résultats de vérification et les cas limites

Une vérification réussie vous apprend quelque chose d’étroit et de puissant : le hachage de commit existait au plus tard à l’horodatage du bloc Bitcoin référencé par le reçu, et la preuve de Merkle relie ce hachage spécifique à ce bloc. Comme les blocs Bitcoin ne peuvent pas être réécrits sans refaire la preuve de travail, la borne « au plus tard » est absolue.

Quelques situations reviennent régulièrement :

Aucune preuve pour une date donnée. Cela signifie généralement qu’il n’y a pas eu de commits ce jour-là — le manifeste est construit à partir des hachages en attente, donc un jour vide ne produit rien à ancrer. Consultez la carte thermique sur la page de statut pour confirmer.
Confirmation en attente. L’ancrage est un processus en deux étapes. Le worker cron nocturne regroupe les hachages, construit l’arbre de Merkle et soumet la racine aux calendriers OpenTimestamps publics ; la confirmation dans un bloc Bitcoin prend ensuite quelques heures — généralement environ trois. Une preuve écrite peu après minuit peut donc ne pas être définitive avant plus tard dans la matinée.
Dépôts privés. L’accès aux pages de statut et de vérification pour les dépôts privés nécessite un HMAC chiffré ajouté à l’URL. Le HMAC est spécifique à l’instance du serveur, les liens ne peuvent donc pas être rejoués contre un autre déploiement.
Indépendance vis-à-vis du fournisseur. Si vous préférez ne pas utiliser du tout le vérificateur hébergé, téléchargez le fichier .ots et exécutez-le vous-même via les outils OpenTimestamps open source contre la blockchain Bitcoin. C’est la méthode difficile, et elle est plus lente, mais elle existe — et son existence est ce qui rend le parcours géré crédible.

Vérifier dans les environnements d’entreprise et auto-hébergés

Mode ZK entreprise. Une GitHub Action de 12 lignes s’exécute sur votre propre infrastructure et ne pousse que des hachages de commit vers l’API Timestamp GIT. Le service n’a jamais d’accès en lecture au dépôt source ; vous n’avez besoin que d’un accès en lecture-écriture au dépôt cible qui reçoit les preuves. La vérification reste inchangée — les mêmes fichiers .ots, les mêmes données Bitcoin publiques, les mêmes vérifications de Merkle dans le navigateur.

Auto-hébergement Docker. Pour les environnements isolés, Timestamp GIT est fourni sous forme d’image Docker que vous exécutez vous-même. 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’instance est disponible à l’adresse http://localhost:8080, et un assistant de configuration au premier lancement vous guide pour connecter votre GitHub App et configurer le déploiement. La vérification fonctionne entièrement à l’intérieur de votre réseau : les fichiers .ots, les manifestes et le vérificateur local sont tout ce dont vous avez besoin.

Une licence de démonstration à durée limitée pour l’évaluation est disponible en soumettant le formulaire de demande sur la page de licence Docker avec votre nom, votre entreprise, votre e-mail et un numéro de téléphone facultatif ; le fichier de licence peut être téléchargé immédiatement.

Automatiser la vérification pour les équipes de conformité

La vérification manuelle convient pour un seul audit. La conformité continue la veut dans un pipeline. L’API REST couvre ce besoin :

#!/usr/bin/env bash
set -euo pipefail

REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"

# Données de la chaîne de Merkle pour la vérification locale d'un jour spécifique
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"

# Registre d'audit mensuel
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"

# Certificat PDF par jour ancré
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"

Pour les tableaux de bord, interrogez les endpoints de statut plutôt que la charge utile de vérification complète :

# Alimentez /api/statusLast et /api/statusCount dans votre système de surveillance
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"

Un schéma utile consiste à traiter un statusLast obsolète comme une condition d’alerte : si le dernier bloc ancré n’a pas bougé depuis plus d’un jour pour un dépôt avec des commits actifs, quelque chose dans le pipeline nécessite votre attention. Tous les calculs de vérification se font localement dans le navigateur ou dans votre propre script — aucune charge utile sensible ne quitte votre contrôle. Si vous êtes encore en train de mettre en place le volet ancrage, consultez Horodatage Git automatisé : comment une GitHub App ancre chaque commit ; cet article porte délibérément sur ce qui se passe après.

FAQ

Dois-je exécuter des outils en ligne de commande pour vérifier une preuve Timestamp GIT ? Non. Timestamp GIT fournit une page de vérification web qui effectue toutes les vérifications cryptographiques localement dans votre navigateur. Vous pouvez également télécharger le fichier .ots et utiliser les outils OpenTimestamps standard si vous préférez, mais le service géré ne nécessite aucune utilisation de CLI.

Puis-je vérifier un horodatage sans faire confiance à Timestamp GIT ? Oui. La preuve repose uniquement sur des hachages SHA-256 et des données de blocs Bitcoin. Vous pouvez vérifier indépendamment le fichier .ots par rapport à la blockchain Bitcoin à l’aide d’outils OpenTimestamps open source, garantissant ainsi l’indépendance vis-à-vis du fournisseur.

Combien de temps faut-il pour qu’un horodatage devienne vérifiable ? Après que la tâche cron nocturne a ancré la racine de Merkle dans une transaction Bitcoin, il faut généralement environ 3 heures pour que la transaction soit confirmée dans un bloc Bitcoin. Une fois confirmée, la preuve est immuable et vérifiable.

Puis-je vérifier les horodatages de dépôts privés ? Oui, mais l’accès aux pages de statut et de vérification pour les dépôts privés nécessite un HMAC chiffré ajouté à l’URL. Cela garantit que seuls les utilisateurs autorisés peuvent consulter les détails de la preuve.

Conclusion

La vérification est le moment où un horodatage cesse d’être une promesse pour devenir une preuve. La chaîne est courte et vérifiable : hachage de commit → manifeste quotidien → racine de Merkle → bloc Bitcoin. Que vous la confirmiez sur la page de statut, exécutiez la vérification de Merkle dans le navigateur ou récupériez le registre CSV pour un dépôt, la conclusion repose sur les mathématiques de Bitcoin plutôt que sur la parole de quiconque — y compris la nôtre.

Installez la GitHub App sur un dépôt, laissez l’exécution nocturne faire son travail, puis vérifiez vous-même une date avant que quiconque vous le demande. Cela prend quelques minutes et c’est la différence entre « nous pensons pouvoir le prouver » et « voici la preuve ».

Comment vérifier l'horodatage Bitcoin d'un dépôt Git