Alternatives à OpenTimestamps : l’horodatage Git managé

Vous avez déjà accepté la prémisse : vous voulez que vos commits Git soient ancrés dans Bitcoin, afin qu’un état précis de votre dépôt ait existé de manière prouvable à une date précise. Ce point n’est pas à débattre.

La vraie décision d’achat porte sur qui exploite le pipeline.

Le protocole OpenTimestamps est le standard sur lequel la plupart de ces systèmes sont construits, et il est réellement bon — ouvert, neutre vis-à-vis des fournisseurs, vérifiable directement contre Bitcoin. Mais un protocole est une boîte à outils, pas un produit. Quelque part entre « le protocole existe » et « mes commits sont horodatés chaque nuit, et mon responsable conformité peut télécharger un certificat PDF », beaucoup de travail doit être accompli. Cet article compare les options réalistes pour l’horodatage Git en 2026, afin que vous puissiez décider où ce travail doit vivre : sur les épaules de votre équipe, ou derrière une GitHub App que vous installez une fois.

La décision d’achat : pourquoi chercher au-delà d’OpenTimestamps brut ?

OpenTimestamps résout le problème cryptographique difficile : il transforme un hash en preuve d’existence ancrée dans la blockchain Bitcoin, en utilisant des serveurs de calendrier publics afin que vous ne payiez pas de frais de transaction par horodatage.

Ce qu’il ne résout pas :

• La détection des commits. Le protocole n’a aucune idée de ce qu’est Git. Quelqu’un doit décider quels commits sont horodatés.
• L’économie du regroupement. Horodater une preuve par commit est inefficace. Les configurations réelles regroupent les hash quotidiennement dans un arbre de Merkle et n’ancrent que la racine.
• Le stockage des clés et des preuves. Les reçus .ots sont petits, mais ils doivent vivre quelque part de durable, un endroit qu’un avocat pourra retrouver dans trois ans.
• L’expérience de vérification. « Téléchargez un fichier et vérifiez-le contre Bitcoin » n’est pas un flux de travail que la plupart des équipes conformité adopteront.
• L’exploitation continue. Les bizarreries des serveurs de calendrier, les chemins de mise à niveau, et la question de savoir qui est d’astreinte quand la tâche nocturne cesse silencieusement de produire des preuves.

C’est là le coût caché du DIY : non pas la cryptographie, mais la plomberie qui l’entoure. Le choix consiste à savoir si vous continuez d’exploiter un protocole ou si vous adoptez un service qui l’automatise de bout en bout. Timestamp GIT est l’option managée dans cette comparaison — elle masque le protocole derrière une GitHub App et une tâche nocturne, de sorte qu’aucun développeur ne touche jamais à une commande d’horodatage.

Une phrase d’honnêteté avant la comparaison : oui, vous pouvez accomplir tout cela à la main avec le protocole ouvert et une tâche cron. Cet article compare cette voie aux alternatives ; il ne vous guide pas dans sa construction.

Le paysage : quelles options existent pour l’horodatage Git ?

Vous rencontrerez quatre formes de solution.

1. L’approche OpenTimestamps brute. Vous installez l’outillage client, vous scriptez votre propre collecte de commits, vous gérez l’interaction avec les calendriers, vous stockez les preuves vous-même et vous vérifiez manuellement contre Bitcoin. Contrôle maximal, surface d’attaque maximale. Ce n’est pas natif Git, et cela ne vient pas avec un tableau de bord, un badge ou un rapport d’audit.

2. Les plateformes d’horodatage blockchain avec API. Elles vous donnent un point de terminaison HTTP qui accepte un hash et renvoie un reçu. Mieux que l’outillage brut, mais elles sont génériques — elles horodatent n’importe quoi, donc l’intégration Git est votre problème. Vous construisez toujours la logique de surveillance des commits, le regroupement et la couche de stockage.

3. Les services d’horodatage Git managés. C’est la catégorie qu’occupe Timestamp GIT : installez une GitHub App, sélectionnez des dépôts, et chaque commit est collecté automatiquement. Chaque nuit, un worker regroupe les hash de commits de la journée, construit un arbre de Merkle et ancre la racine dans Bitcoin via les calendriers OpenTimestamps publics. Les preuves reviennent dans votre propre dépôt.

4. Les déploiements auto-hébergés sous licence. La commodité managée ne signifie pas nécessairement les serveurs de quelqu’un d’autre. Timestamp GIT est livré sous forme d’image Docker que vous pouvez exécuter vous-même — l’option pertinente pour les environnements isolés et les politiques de sécurité strictes.

Critères de sélection : ce que les développeurs et les équipes conformité doivent évaluer

Lorsque vous comparez des options, le protocole sous-jacent importe moins que le modèle d’exploitation au-dessus. Six critères portent l’essentiel de la décision :

• L’effort de mise en place. Installation de la GitHub App en un clic contre installation d’outillage, écriture de scripts et câblage d’un ordonnanceur.
• Le niveau d’automatisation. Le système remarque-t-il les nouveaux commits de lui-même, ou un humain doit-il y penser ?
• La sécurité et la confidentialité. Le service peut-il faire son travail sans lire votre code source ? Existe-t-il un mode où votre code ne quitte jamais votre infrastructure ?
• La surface d’intégration. Intégration à l’hébergement Git, badges README, points de terminaison REST, registres d’audit CSV, certificats PDF.
• Le modèle de coût. Niveau gratuit pour les dépôts publics, tarification transparente par niveau pour les dépôts privés, et une licence auto-hébergée quand vous avez besoin de souveraineté.
• La vérifiabilité et l’enfermement propriétaire. Un tiers peut-il vérifier votre preuve à l’aide d’outils standards et des données de blocs Bitcoin, sans que votre fournisseur soit impliqué ?

Ce dernier critère est celui que les équipes sous-estiment. Un horodatage que vous ne pouvez pas vérifier indépendamment n’est qu’une ligne dans une base de données avec un bon marketing.

Comparaison côte à côte : protocole brut vs services managés

Notez le schéma dans la colonne du milieu : une API élimine le travail cryptographique mais laisse le travail Git. C’est souvent là que les projets DIY s’enlisent — non pas parce que l’ancrage est difficile, mais parce que la collecte des commits, le regroupement et la livraison sont assez ennuyeux pour être perpétuellement dépriorisés.

Verdict : qui devrait choisir quelle option ?

Développeurs solo et mainteneurs open source. Si vous aimez la plomberie et que vos dépôts sont de toute façon publics, le protocole brut est défendable. Mais le niveau gratuit de Timestamp GIT couvre les dépôts publics, donc la vraie question est de savoir si votre temps est mieux investi dans votre projet que dans la maintenance d’un pipeline de preuves. Au minimum, cela élimine le mode de défaillance « je vais automatiser ça correctement le mois prochain ».

Startups et agences. Prenez la voie managée. Les arguments d’antériorité ne se soucient pas que vous auriez pu horodater ces commits — ils se soucient que vous l’ayez fait, de manière constante, pendant les mois précédant le litige. La constance est une fonctionnalité produit, et l’automatisation nocturne la fournit bien mieux que les bonnes intentions. Si vous prouvez des dates de livraison lors d’un litige de paiement, voir Protecting Agency Code Deliverables With Blockchain Proof.

Entreprises avec des politiques de sécurité strictes. Le mode Standard plus la voie Enterprise ZK, ou la licence auto-hébergée Docker, vous donnent le contrôle dont vous avez besoin sans reconstruire le protocole vous-même. Le mode Enterprise ZK est celui à privilégier lorsque le dépôt source ne doit pas être lisible par le service — une GitHub Action pousse le hash du commit depuis votre propre infrastructure. Si votre préoccupation est l’exposition en matière de brevets plutôt que les permissions de dépôt, Git Commit Timestamp Proof for Patent Disputes couvre ce scénario.

En bref : Timestamp GIT n’est pas simplement une alternative à l’exploitation du protocole — c’est la version du protocole que vous n’avez pas à exploiter.

Comment Timestamp GIT fonctionne comme alternative managée

Voici l’intégralité du flux de travail côté développeur.

1. Installez la GitHub App une fois. Rien à installer sur les machines des développeurs. L’app ne lit que le hash du commit HEAD des dépôts surveillés ; votre code source n’est jamais lu, copié ni stocké. En mode Standard, l’app nécessite au moins un accès en lecture seule au dépôt source (il n’existe pas de permission « hash uniquement » dans le modèle de GitHub) et un accès en lecture-écriture au dépôt cible, où les preuves sont écrites.

2. Les commits sont collectés automatiquement. Soit la GitHub App détecte les nouveaux commits via des webhooks, soit — en mode Enterprise ZK — une GitHub Action de 12 lignes pousse uniquement le hash du commit vers l’API Timestamp GIT. En mode ZK, aucun accès en lecture au dépôt source n’est requis, mais vous installez l’Action. Les hash en attente résident dans un magasin clé-valeur en mémoire, en attendant le lot.

3. Un worker cron de minuit ancre le lot. Chaque nuit, le worker regroupe tous les hash en attente, construit des fichiers manifeste .txt par dépôt, construit un arbre de Merkle, crée des preuves OpenTimestamps à l’aide des calendriers OTS publics, et ancre la racine de Merkle dans la blockchain Bitcoin. La confirmation Bitcoin prend normalement environ trois heures, donc les preuves apparaissent quelques heures après l’exécution du lot.

4. Les preuves sont livrées dans votre dépôt. Le manifeste et les fichiers de reçu .ots sont poussés vers une branche timestamps dédiée ou un dépôt fantôme. À partir de ce moment, l’horodatage est immuable — aucune entité, y compris Timestamp GIT, ne peut le modifier ou le falsifier.

5. Vous vérifiez et publiez. Des badges README intégrables affichent le statut de vérification et renvoient vers la page de vérification publique. Le tableau de bord de statut du dépôt expose la longévité des preuves, la date d’ancrage la plus ancienne, la régularité quotidienne, les données de blocs et de transactions Bitcoin, une carte thermique calendaire, ainsi que des registres d’audit CSV et des certificats PDF téléchargeables. La vérification elle-même s’exécute localement dans le navigateur contre la chaîne de Merkle — aucun calcul de notre côté, personne ne voit ce que vous vérifiez. Si vous voulez les mécanismes en détail, lisez How to Verify a Git Repository’s Bitcoin Timestamp.

Pour l’automatisation au-delà du tableau de bord, il existe des points de terminaison publics :

curl https://timestampgit.dev/api/statusSummary/your-org/your-repo
curl https://timestampgit.dev/api/statusLast/your-org/your-repo
curl -O https://timestampgit.dev/api/audit/your-org/your-repo

Les dépôts privés ajoutent un HMAC chiffré à leurs URL, spécifique à l’instance serveur, afin que seuls les utilisateurs autorisés puissent lire leur statut.

L’option auto-hébergée

Pour une sécurité maximale et les environnements isolés, Timestamp GIT est disponible 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 à l’adresse http://localhost:8080. Au premier lancement, un assistant de configuration vous guide dans la connexion de votre GitHub App et la configuration de l’instance. Une licence de démonstration à durée limitée est disponible en soumettant le formulaire de demande sur la page Docker License avec votre nom, votre entreprise, votre e-mail et un numéro de téléphone facultatif ; le fichier de licence peut ensuite être téléchargé.

FAQ

Dois-je exécuter des commandes OpenTimestamps ?

Non. Timestamp GIT est un service managé. Une fois la GitHub App installée, elle détecte automatiquement les commits et les ancre dans Bitcoin chaque nuit. Vous n’avez jamais besoin d’exécuter d’outils CLI ni de gérer le protocole vous-même.

Puis-je vérifier les preuves sans Timestamp GIT ?

Oui. Les fichiers de reçu .ots et les preuves de Merkle reposent sur des standards ouverts. Vous pouvez les vérifier indépendamment à l’aide des outils de vérification OpenTimestamps standards contre la blockchain Bitcoin, ou utiliser la vérification locale de Timestamp GIT dans le navigateur qui effectue tous les calculs côté client.

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

Vos preuves sont ancrées dans la blockchain Bitcoin et sont indépendantes du fournisseur. Les fichiers .ots et les preuves de Merkle peuvent être vérifiés hors ligne à l’aide d’outils open source. Timestamp GIT ne vous enferme pas ; la preuve cryptographique repose uniquement sur SHA-256 et les données de blocs Bitcoin.

Mon code source est-il un jour exposé ?

Non. Timestamp GIT fonctionne selon un principe de connaissance nulle. En mode Standard, la GitHub App ne lit que le hash du commit, pas le code source. En mode Enterprise ZK, une GitHub Action pousse uniquement le hash du commit depuis votre infrastructure, de sorte que votre source ne quitte jamais votre environnement.

Conclusion

Chaque option de cette comparaison aboutit au même endroit : un hash SHA-256 à l’intérieur d’un bloc Bitcoin. Ce qui diffère, c’est la quantité d’ingénierie, de discipline opérationnelle et de mémoire institutionnelle que vous devez fournir pour y parvenir — et si le résultat est quelque chose qu’une équipe conformité peut réellement remettre à un avocat.

Si vous voulez les garanties cryptographiques sans devenir le mainteneur d’un pipeline d’horodatage, installez la GitHub App une fois et laissez le worker nocturne faire le reste. Commencez sur le niveau gratuit avec un dépôt public pour voir les preuves arriver, puis migrez les dépôts privés vers Pro Agency quand vous serez prêt. Vos commits ont déjà des hash ; autant qu’ils aient des témoins.

Articles similaires

• Protecting Agency Code Deliverables With Blockchain Proof
• Git Commit Timestamp Proof for Patent Disputes
• How to Verify a Git Repository’s Bitcoin Timestamp