Comment prouver qu’un code existait à une date précise (sans le révéler)
Si vous devez prouver qu’un morceau de code spécifique existait avant une certaine date — pour un litige de brevet, un désaccord entre employés ou la revendication de « développement indépendant » d’un concurrent — l’historique Git standard ne suffit pas. Les journaux internes vivent sur des serveurs que vous ne possédez pas, peuvent être modifiés et sont souvent écartés lors des audits juridiques car considérés comme intéressés. Cet article détaille la tâche exacte : prouver qu’un code existait à un moment précis sans révéler le code lui-même.
Vous y parviendrez en ancrant des hachages de commits Git — et non le code source — dans la blockchain Bitcoin à l’aide de l’application GitHub gérée Timestamp GIT. À la fin, vous disposerez d’une preuve immuable, prête pour un tribunal, que n’importe qui peut vérifier indépendamment, sans travail cryptographique manuel et sans que votre code source ne quitte jamais votre dépôt.
Si vous découvrez le concept sous-jacent, consultez Qu’est-ce que la preuve cryptographique de paternité d’un code ?.
Prérequis
- Un compte GitHub et un dépôt que vous souhaitez horodater. Les dépôts publics fonctionnent avec le plan Open Source gratuit. Les dépôts privés nécessitent un plan payant Pro Agency ou Enterprise ZK.
- L’accès à l’application GitHub Timestamp GIT et un compte Timestamp GIT. Vous installerez l’application une seule fois depuis la page produit sur Timestamp GIT.
- Une familiarité de base avec les commits Git et la structure d’un dépôt. Aucune connaissance avancée en cryptographie n’est nécessaire.
- Pour les dépôts privés, assurez-vous que votre compte dispose d’un plan payant incluant les dépôts privés.
Étape par étape : configurer l’horodatage automatique
Étape 1 : Installer l’application GitHub Timestamp GIT
Rendez-vous sur le tableau de bord Timestamp GIT et lancez l’installation de l’application GitHub. Choisissez votre compte personnel ou votre organisation, puis accordez les autorisations demandées :
- Accès en lecture au dépôt source. Le système de permissions de GitHub exige au minimum un accès en lecture seule, car les hachages de commits ne sont pas exposés sans cela.
- Accès en lecture-écriture au dépôt cible où les fichiers de preuve seront écrits.
La garantie importante : Timestamp GIT ne lit, ne copie et ne stocke jamais votre code source. Il extrait uniquement les hachages de commits.
Étape 2 : Connecter votre dépôt
Après avoir installé l’application, ouvrez le tableau de bord Timestamp GIT et sélectionnez le dépôt que vous souhaitez surveiller. Choisissez où les preuves doivent être livrées :
- Une branche dédiée
timestampsdans le même dépôt, ou - Un dépôt miroir séparé.
Cet emplacement cible est l’endroit où le manifeste et les fichiers de reçus .ots seront poussés ultérieurement.
Étape 3 : Configurer les préférences d’horodatage
Le comportement par défaut est le traitement par lots nocturne automatique. Les hachages de commits en attente sont regroupés quotidiennement, un arbre de Merkle est construit, les preuves OpenTimestamps sont créées et la racine de Merkle est ancrée dans Bitcoin. Dans la plupart des cas, vous n’avez rien à modifier.
Si vous utilisez le mode Enterprise ZK, vous exécuterez une courte GitHub Action sur votre propre infrastructure au lieu d’accorder un accès en lecture au dépôt source. Cette action envoie uniquement les hachages de commits à l’API Timestamp GIT, de sorte que votre code source ne quitte jamais votre environnement.
Étape 4 : Faire un nouveau commit
Commitez dans votre dépôt comme d’habitude. L’application GitHub détecte automatiquement le nouveau commit via les webhooks.
git add .
git commit -m "Add new feature logic"
git push origin main
Aucune commande d’horodatage supplémentaire n’est nécessaire. Le hachage du commit entre automatiquement dans la file d’attente de Timestamp GIT.
Étape 5 : Attendre la tâche cron nocturne
Chaque nuit, Timestamp GIT traite les hachages en attente :
- Regroupe tous les hachages de commits en attente de la journée.
- Crée des fichiers texte de manifeste pour chaque dépôt.
- Construit un arbre de Merkle nativement.
- Crée des preuves OpenTimestamps à l’aide de calendriers OTS publics.
- Ancre la racine de Merkle dans la blockchain Bitcoin.
La confirmation Bitcoin prend généralement quelques heures après le lot nocturne.
Étape 6 : Recevoir votre preuve
Une fois la transaction Bitcoin confirmée, Timestamp GIT pousse les fichiers de preuve vers la branche désignée. Vous verrez :
- Un fichier manifeste listant les hachages de commits.
- Des fichiers de reçus
.otspour le lot quotidien.
Ces fichiers de preuve sont indépendants du fournisseur. Vous pourrez les vérifier ultérieurement même si le service Timestamp GIT disparaît.
Étape 7 : Ajouter un badge de vérification à votre README
Depuis la page d’état du dépôt, copiez le markdown du badge Shields.io fourni et collez-le dans votre README.md. Pour les dépôts publics, le badge renvoie vers une page de vérification publique. Pour les dépôts privés, l’URL du badge inclut un HMAC chiffré afin que seuls les utilisateurs autorisés puissent consulter l’état.
Le tableau de bord fournit l’extrait markdown exact, qui ressemblera à ceci :
[](https://timestampgit.dev/status/your-user/your-repo)
Remplacez your-user et your-repo par les valeurs réelles affichées dans le tableau de bord.
Comment confirmer que cela a fonctionné (vérification)
Consulter le tableau de bord d’état du dépôt
Ouvrez la page d’état publique de votre dépôt. Elle affiche :
- La longévité de la preuve et la date d’ancrage la plus ancienne.
- La régularité de l’ancrage quotidien et une carte de chaleur calendaire.
- La hauteur de bloc Bitcoin et les données de transaction.
- Un CSV d’audit téléchargeable et un certificat PDF pour une date spécifique.
Exécuter la vérification dans le navigateur
Utilisez la page de vérification pour un dépôt et une date spécifiques. Elle déroule la vérification de la chaîne de Merkle étape par étape, et tous les calculs s’effectuent localement dans votre navigateur. Personne ne voit ce que vous vérifiez.
Télécharger un certificat PDF
Pour un document prêt pour un tribunal, téléchargez le certificat PDF pour la date dont vous avez besoin. Cela vous donne une preuve propre et partageable sans exposer aucun code.
Interroger l’API par programmation
Vous pouvez interroger les points de terminaison d’état publics avec curl :
curl https://timestampgit.dev/api/statusLast/your-user/your-repo
curl https://timestampgit.dev/api/statusCount/your-user/your-repo
curl https://timestampgit.dev/api/statusSummary/your-user/your-repo
Le dernier point de terminaison renvoie un résumé combiné adapté aux badges Shields.io.
Vérification indépendante pour les utilisateurs avancés
Comme la preuve repose uniquement sur SHA-256 et les données de blocs Bitcoin, vous pouvez télécharger le reçu .ots et le vérifier avec les outils de vérification OpenTimestamps standard contre la blockchain Bitcoin. Cela ne nécessite pas de faire confiance à Timestamp GIT ni à aucun fournisseur. L’application gérée automatise simplement le processus qui nécessiterait autrement un travail manuel sur le protocole.
Résolution des problèmes courants
Aucun horodatage n’apparaît après un commit
Vérifiez que l’application GitHub est installée sur le compte ou l’organisation et que le dépôt est connecté dans le tableau de bord Timestamp GIT. Seuls les commits effectués après la configuration seront horodatés.
La preuve n’est pas livrée après 24 heures
La confirmation Bitcoin peut prendre plusieurs heures après le lot nocturne. Consultez le tableau de bord d’état du dépôt pour voir un état en attente. Si vous utilisez un dépôt privé, confirmez que votre plan inclut les dépôts privés.
Le badge affiche « non vérifié » ou un lien cassé
Vérifiez l’URL du badge depuis le tableau de bord et assurez-vous que le dépôt est public ou que le HMAC chiffré est inclus pour les dépôts privés. Un lien cassé signifie souvent que le dépôt ou le nom d’utilisateur est mal orthographié.
Vous devez prouver l’existence d’un code non hébergé sur GitHub
Utilisez le mode Enterprise ZK. Une GitHub Action s’exécute sur votre infrastructure et envoie uniquement les hachages de commits à l’API. Cela fonctionne avec n’importe quel dépôt Git, et Timestamp GIT n’a besoin d’aucun accès en lecture au dépôt source.
Vous souhaitez vous auto-héberger dans un environnement isolé
Timestamp GIT est disponible sous forme d’image Docker avec une licence auto-hébergée. Vous pouvez exécuter le même flux de travail géré sur votre propre infrastructure à l’aide de la configuration Docker Compose fournie :
services:
timestampgit:
image: rue1401/timestampgit:prod
ports:
- "8080:8080"
volumes:
- ./data:/app/data
restart: unless-stopped
valkey:
image: valkey/valkey:8
restart: unless-stopped
Démarrez-le ensuite 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. Une licence de démonstration à durée limitée est disponible pour évaluation.
FAQ
L’horodatage de mon code révèle-t-il son contenu à quiconque ?
Non. Timestamp GIT extrait uniquement le hachage du commit Git — une empreinte cryptographique — et ancre ce hachage dans la blockchain Bitcoin. Votre code source réel n’est jamais lu, copié ou stocké par le service.
Combien de temps faut-il pour obtenir une preuve d’horodatage ?
Le processus est automatique. Après votre commit, le hachage est mis en file d’attente et ancré lors du prochain lot nocturne. La confirmation Bitcoin prend généralement quelques heures, après quoi les fichiers de preuve sont poussés vers votre dépôt.
Puis-je vérifier l’horodatage sans dépendre de Timestamp GIT ?
Oui. La preuve repose sur le protocole OpenTimestamps et les données de la blockchain Bitcoin. Vous pouvez télécharger le reçu .ots et le vérifier indépendamment à l’aide des outils OpenTimestamps standard, même si Timestamp GIT disparaît.
Que faire si je dois prouver l’existence d’un code non hébergé sur GitHub ?
Timestamp GIT propose un mode Enterprise ZK où une GitHub Action s’exécute sur votre infrastructure et envoie uniquement les hachages de commits à l’API. Cela fonctionne avec n’importe quel dépôt Git, et votre code ne quitte jamais votre environnement.
Conclusion
Vous savez maintenant comment prouver qu’un code existait à un moment précis sans le révéler : installez l’application GitHub Timestamp GIT une seule fois, connectez un dépôt et laissez le service ancrer automatiquement chaque hachage de commit dans Bitcoin. Votre code source ne quitte jamais votre dépôt — seules les empreintes cryptographiques sont horodatées.
Les preuves sont indépendantes de tout fournisseur unique, reposent sur les mathématiques de Bitcoin et peuvent être vérifiées dans un navigateur, via l’API ou avec les outils OpenTimestamps standard. Pour les dépôts publics, le plan Open Source gratuit est un point de départ pratique. Pour les dépôts privés ou les environnements isolés, les options de licence Pro Agency, Enterprise ZK et Docker auto-hébergé couvrent le reste.
Si vous souhaitez comprendre les concepts sous-jacents ou comparer l’approche gérée avec le protocole brut, consultez les articles ci-dessous.
Articles connexes
- Qu’est-ce que la preuve cryptographique de paternité d’un code ?
- Timestamp GIT vs. OpenTimestamps : lequel vous convient ?
- Installer une application GitHub pour horodater automatiquement vos commits