Comment prouver que votre code existait avant un dépôt de brevet

Le scénario est brutal : vous avez conçu une fonctionnalité novatrice, l’avez livrée dans un dépôt privé, puis êtes passé à autre chose. Dix-huit mois plus tard, un concurrent dépose un brevet sur la même technique. Si vous ne pouvez pas prouver que votre implémentation existait avant leur date de dépôt, la conversation passe de « nous l’avons construit en premier » à « prouvez-le ». Ce guide vous montre exactement comment prouver que votre code existait avant un dépôt de brevet en utilisant Timestamp GIT et son application GitHub gérée. À la fin, vous disposerez d’horodatages immuables ancrés dans Bitcoin pour vos commits Git, prêts à appuyer une défense fondée sur l’antériorité.

La méthode difficile consisterait à apprendre le protocole OpenTimestamps, à exécuter des étapes d’ancrage manuelles et à maintenir votre propre pipeline de preuves. Timestamp GIT élimine tout cela : installez l’application GitHub une seule fois, connectez un dépôt, et chaque commit est regroupé et ancré dans la blockchain Bitcoin automatiquement chaque nuit.

Prérequis : ce dont vous avez besoin avant de commencer

Vous n’avez pas besoin d’un portefeuille Bitcoin, d’un nœud blockchain ni d’aucun outil cryptographique. Vous avez besoin de :

• Un compte GitHub et au moins un dépôt contenant le code que vous souhaitez protéger. Les dépôts publics peuvent utiliser le plan Open Source gratuit ; les dépôts privés nécessitent un plan payant.
• Une familiarité de base avec les commits Git et les paramètres des dépôts GitHub. Vous devez savoir pousser des commits, installer une application GitHub et lire les journaux de workflow.
• Un compte Timestamp GIT. Le niveau gratuit couvre les dépôts publics. Pour les dépôts privés, le plan Pro Agency est à 49 $/mois et le plan Enterprise ZK Mode à 199 $/mois.
• Facultatif : pour les environnements isolés ou auto-hébergés, un hôte Docker. Timestamp GIT publie une image Docker et fournit une licence de démonstration à durée limitée.

Si vous souhaitez évaluer le chemin auto-hébergé, le fichier 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

Pour la plupart des développeurs, cependant, l’application GitHub gérée est la voie la plus rapide. Ce guide suit ce chemin géré.

Étape par étape : ancrer votre code dans Bitcoin avec Timestamp GIT

Étape 1 : Installer l’application GitHub Timestamp GIT

Commencez depuis le tableau de bord Timestamp GIT et installez l’application GitHub. Sélectionnez le dépôt cible que vous souhaitez surveiller. En mode Standard, le système de permissions GitHub nécessite un accès en lecture au dépôt source, car GitHub ne peut pas exposer uniquement un hash de commit. Timestamp GIT lit uniquement le hash du commit HEAD, pas le contenu de vos fichiers.

L’application a également besoin d’un accès en écriture à un dépôt cible où les preuves seront stockées. Cette cible peut être le même dépôt sur une branche dédiée, ou un dépôt miroir séparé.

Étape 2 : Configurer les dépôts à surveiller

Après l’installation, ouvrez la liste des dépôts dans le tableau de bord et activez la surveillance pour les dépôts que vous souhaitez protéger. Une fois activée, l’application GitHub détecte les nouveaux commits via des webhooks. Il n’y a pas de CLI à installer, pas de hook de pré-commit à configurer et aucune commande OpenTimestamps à apprendre.

Chaque hash de commit détecté entre dans une file d’attente en mémoire pour un traitement quotidien. Timestamp GIT ne stocke pas, ne copie pas et ne lit pas votre code source.

Étape 3 : Conserver le mode Standard ou passer au mode Enterprise ZK

Le mode Standard suffit pour de nombreuses équipes. L’application GitHub lit automatiquement le hash du commit HEAD et écrit les fichiers de preuve sur la branche cible de votre choix.

Pour une opération à divulgation nulle de connaissance maximale, choisissez le mode Enterprise ZK. Une courte GitHub Action s’exécute sur votre infrastructure et pousse uniquement le hash du commit et l’ID du commit vers l’API Timestamp GIT. Dans ce mode, Timestamp GIT n’a pas besoin d’accès en lecture au dépôt source. Votre source ne quitte jamais votre environnement.

Votre tableau de bord fournit l’extrait d’action exact. Conceptuellement, le workflow n’envoie que des métadonnées — jamais de fichiers, de chemins, de blobs ou de contenu de dépôt.

Étape 4 : Laisser le worker cron nocturne ancrer vos hashes

Timestamp GIT traite les hashes en attente une fois par jour. À minuit, un worker cron :

• Regroupe les hashes de commits en attente par dépôt.
• Crée des fichiers manifestes pour chaque dépôt.
• Construit un arbre de Merkle nativement.
• Crée des preuves OpenTimestamps en utilisant des calendriers OTS publics.
• Ancre la racine de Merkle dans la blockchain Bitcoin.

Après l’ancrage quotidien, la création des preuves se poursuit en arrière-plan. La confirmation Bitcoin prend normalement environ trois heures, donc les preuves apparaissent quelques heures après le début du lot nocturne. Vous n’avez pas besoin de surveiller ce processus ni de le déclencher manuellement.

Étape 5 : Recevoir les fichiers de preuve immuables

Une fois la confirmation terminée, Timestamp GIT pousse les artefacts de preuve vers votre dépôt. Vous verrez :

• Un fichier manifeste décrivant le lot et les commits couverts.
• Un ou plusieurs fichiers de reçu .ots contenant la preuve d’horodatage cryptographique.

Les fichiers résident sur une branche d’horodatages dédiée ou dans un dépôt miroir, selon votre configuration. Ce sont des fichiers ordinaires dans Git, donc faciles à préserver, copier et remettre à un avocat.

Étape 6 : Ajouter un badge de vérification à votre README

Depuis la page Repository Connected, copiez le code d’intégration du badge généré. Il suit le modèle markdown standard de type Shields.io :

[![Timestamp status](https://timestampgit.dev/api/statusSummary/{user}/{repo})](https://timestampgit.dev/status/{user}/{repo})

Remplacez {user} et {repo} par votre compte GitHub et le nom de votre dépôt réels. Le badge renvoie vers le tableau de bord de statut public, où n’importe qui peut inspecter la date d’ancrage la plus ancienne, la régularité quotidienne et les données de blocs Bitcoin.

Pour les dépôts privés, l’URL du badge inclut un HMAC chiffré afin que seuls les utilisateurs autorisés puissent consulter le statut.

Étape 7 : Télécharger le certificat PDF ou le CSV d’audit

Pour les dossiers juridiques, ouvrez le tableau de bord Repository Status et téléchargez :

• Un certificat PDF pour une date spécifique.
• Un CSV d’audit complet répertoriant le registre complet des commits horodatés.

Les deux sont utiles lorsque vous avez besoin d’un document lisible par un humain pour un conseiller juridique, un investisseur ou un dépôt au tribunal. Le fichier .ots sous-jacent reste la preuve mathématiquement indépendante.

Comment vérifier que votre horodatage a réellement fonctionné

Consulter le tableau de bord Repository Status

La page de statut publique est le signal le plus rapide. Elle affiche :

• La longévité de la preuve et la date d’ancrage la plus ancienne.
• La régularité de l’ancrage quotidien.
• La hauteur de bloc Bitcoin et les données de transaction.
• Une carte thermique calendaire des jours horodatés.

Si vous voyez la date du commit actuel avec un bloc Bitcoin confirmé, l’ancrage a réussi.

Exécuter une vérification locale dans votre navigateur

La page de vérification à /verification/{user}/{repo}/{date} effectue une vérification de chaîne de Merkle étape par étape localement dans votre navigateur. Cela signifie que le calcul de vérification ne repose pas sur le serveur de Timestamp GIT pour prouver son propre résultat. Vous suivez le chemin cryptographique depuis votre hash de commit jusqu’au bloc Bitcoin.

Vérifier indépendamment le reçu .ots

Parce que la preuve utilise uniquement SHA-256 et les données de blocs Bitcoin, vous n’êtes pas enfermé dans Timestamp GIT. 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. Aucun logiciel propriétaire n’est requis, donc la preuve reste valide même si l’entreprise disparaît.

Confirmer le badge README

Enfin, confirmez que le badge dans votre README affiche un état vérifié et renvoie vers la page de statut publique. Ce badge est un signal externe léger pour les collègues, les auditeurs et les mainteneurs.

Dépannage des problèmes courants

Aucun commit n’est horodaté

Vérifiez d’abord les permissions de l’application GitHub. En mode Standard, Timestamp GIT doit avoir un accès en lecture au dépôt source et un accès en écriture au dépôt ou à la branche cible. Si l’une de ces permissions manque, les hashes de commits ne peuvent pas être lus et les preuves ne peuvent pas être écrites.

Les preuves prennent trop de temps

Un horodatage n’est pas instantané. Timestamp GIT regroupe les hashes chaque nuit, puis ancre la racine de Merkle dans Bitcoin. La confirmation Bitcoin prend normalement environ trois heures après la diffusion de la transaction. Les preuves sont écrites après la confirmation, donc un délai de plusieurs heures est attendu.

Le statut du dépôt privé n’est pas visible

Les URL de statut des dépôts privés utilisent un HMAC chiffré lié à l’instance du serveur Timestamp GIT. Si la page de statut est vide ou non autorisée, assurez-vous d’être authentifié sur la même instance et d’utiliser le lien généré pour votre dépôt privé.

La configuration auto-hébergée échoue

Pour l’auto-hébergement Docker, vérifiez que le fichier Compose est valide, que le fichier de licence est monté correctement et que le service valkey est en cours d’exécution. Les journaux Timestamp GIT de docker compose logs -f timestampgit sont le premier endroit à vérifier.

FAQ

Un horodatage Bitcoin est-il juridiquement reconnu comme antériorité ?

Bien que les lois varient selon les juridictions, les horodatages cryptographiques fournissent une preuve solide de l’existence à un moment précis. Timestamp GIT utilise le protocole OpenTimestamps, qui ancre les données dans la blockchain Bitcoin, ce qui les rend extrêmement difficiles à contester. Consultez toujours un conseiller juridique pour votre cas spécifique.

Dois-je exposer mon code source à Timestamp GIT ?

Non. Timestamp GIT traite uniquement les hashes de commits Git, jamais votre code source. En mode Standard, l’application GitHub lit uniquement le hash du commit HEAD. En mode Enterprise ZK, une GitHub Action sur votre infrastructure pousse uniquement le hash vers l’API, donc votre code ne quitte jamais votre environnement.

Que se passe-t-il si Timestamp GIT fait faillite ? Mes preuves resteront-elles valides ?

Oui. Vos preuves sont ancrées dans la blockchain Bitcoin et peuvent être vérifiées indépendamment à l’aide des outils OpenTimestamps standard. La preuve repose uniquement sur SHA-256 et les données de blocs Bitcoin, sans technologie propriétaire ni verrouillage.

Puis-je utiliser Timestamp GIT pour des dépôts privés ?

Oui, avec le plan Pro Agency à 49 $/mois ou le plan Enterprise ZK à 199 $/mois. Les URL de statut des dépôts privés sont protégées par un HMAC chiffré, de sorte que seuls les utilisateurs autorisés peuvent consulter le statut de l’horodatage.

Conclusion : sécurisez votre antériorité dès aujourd’hui

Vous disposez désormais d’un workflow reproductible pour prouver que votre code existait avant un dépôt de brevet. Connectez l’application GitHub, laissez l’ancrage nocturne s’exécuter et collectez les reçus .ots, les certificats PDF et les journaux d’audit. Le résultat est un bouclier d’antériorité cryptographique qui ne dépend pas de vos propres journaux, d’un serveur tiers ou de l’existence continue de Timestamp GIT.

Installez l’application GitHub Timestamp GIT maintenant et connectez votre premier dépôt. Les dépôts publics peuvent commencer gratuitement ; les dépôts privés sont couverts par les plans Pro Agency ou Enterprise ZK. Pour les environnements isolés, demandez une licence de démonstration Docker et auto-hébergez le même pipeline. La prochaine revendication de brevet devrait rencontrer votre preuve avant de s’intensifier.

Pour une perspective plus large sur l’importance de cela dans les litiges et les pressions de licence, consultez Horodater les commits Git pour se défendre contre les trolls de brevets.

Articles connexes

• Horodater les commits Git pour se défendre contre les trolls de brevets
• Automatiser l’horodatage du code avec une application GitHub
• La meilleure application GitHub pour horodater vos commits