Comment prouver la paternité d’un logiciel : un guide pour les développeurs

Maya est une développeuse freelance qui a créé une petite bibliothèque de synchronisation de données, critique mais compacte, pour un client début 2025. Dix-huit mois plus tard, la nouvelle équipe d’ingénierie du client affirme que la bibliothèque a été créée dans le cadre d’un contrat ultérieur et lui demande de cesser de l’utiliser dans ses autres projets. Maya dispose des commits Git du projet d’origine, mais lorsqu’elle envoie des captures d’écran du journal, l’avocat du client les balaie d’un revers de main : « L’historique Git peut être réécrit. Ces horodatages ne prouvent rien. »

Le problème de Maya n’est pas qu’elle manque de preuves. C’est que les preuves dont elle dispose sont assertives, et non vérifiables. Prouver la paternité d’un logiciel dans le cadre d’un litige, d’un dépôt de brevet, d’un audit de conformité ou d’un examen de secret commercial exige plus qu’une date de commit. Cela exige un enregistrement cryptographique qu’une partie indépendante peut vérifier sans faire confiance à votre dépôt, à votre plateforme ou à votre parole.

Ce guide explique comment les développeurs et les responsables de la conformité peuvent créer cet enregistrement en pratique. Il se concentre sur Timestamp GIT, un service géré qui automatise le protocole OpenTimestamps sous-jacent. Vous installez une GitHub App une seule fois, et le service ancre les hachages de vos commits dans la blockchain Bitcoin en arrière-plan.

Pourquoi la preuve traditionnelle de paternité est insuffisante

La plupart des développeurs disposent déjà de plusieurs moyens pour indiquer une date. Le problème est qu’aucun d’entre eux ne résiste à un examen réel.

L’historique Git auto-hébergé est modifiable. Les dates de commit Git ne sont pas infalsifiables. Avec des variables d’environnement telles que GIT_AUTHOR_DATE et GIT_COMMITTER_DATE, un commit peut être antidaté. Le rebasage, le force-push et la réécriture de l’historique peuvent altérer la chronologie apparente. Même si vous ne le faites jamais, la partie adverse peut soutenir que vous auriez pu le faire.

Les plateformes Git hébergées ne résolvent pas ce problème. Un dépôt GitHub affiche des horodatages, mais ces horodatages ne constituent pas une preuve d’existence indépendante. Ils dépendent des serveurs de GitHub, de la sécurité du compte GitHub et de la volonté ou de la capacité de GitHub à attester des données devant un tribunal. Un attaquant qui compromet un compte peut potentiellement modifier le contenu du dépôt. Un changement de politique de la plateforme peut rendre les enregistrements historiques plus difficiles à obtenir.

La protection formelle de la propriété intellectuelle est coûteuse et lente. Les brevets peuvent coûter des dizaines de milliers de dollars, prendre des années à être délivrés et peuvent exiger la divulgation d’informations que vous préféreriez garder privées. Pour les freelances, les startups, les agences et les petites équipes, les brevets sont souvent peu pratiques comme première ligne de défense.

Une approche plus solide consiste à ancrer une empreinte cryptographique de votre travail dans un registre public immuable. L’empreinte est un hachage à sens unique. Elle prouve qu’un état spécifique du dépôt existait à un moment précis, mais elle ne révèle pas le code source derrière cet état. Lorsque le registre est Bitcoin, la preuve peut être vérifiée indépendamment par quiconque dispose du fichier de reçu et d’un nœud Bitcoin.

Pour une explication plus approfondie de l’importance de cela dans les litiges de propriété intellectuelle, consultez Qu’est-ce que l’antériorité cryptographique et pourquoi est-ce important pour les logiciels ?.

Un guide pratique pour prouver la paternité avec Timestamp GIT

Timestamp GIT est une couche gérée, sans configuration, au-dessus d’OpenTimestamps. Vous n’avez pas besoin d’exécuter des commandes OpenTimestamps, de gérer des transactions Bitcoin ou d’exploiter votre propre infrastructure d’horodatage. Vous installez une GitHub App, connectez un dépôt et continuez à écrire du code. Le service s’occupe du reste.

Étape 1 : Installer la GitHub App Timestamp GIT

Installez la GitHub App Timestamp GIT sur le dépôt ou l’organisation que vous souhaitez protéger.

Le mode standard nécessite un accès en lecture seule à votre dépôt source et un accès en lecture/écriture à un dépôt cible où les fichiers de preuve seront stockés. La cible peut être le même dépôt ou un dépôt miroir séparé. Comme GitHub n’offre pas d’accès en lecture limité au hachage de commit, la permission de lecture existe même si Timestamp GIT ne lit que le hachage du commit HEAD.

En mode entreprise à connaissance nulle, vous n’accordez aucun accès en lecture au dépôt source. Au lieu de cela, une GitHub Action s’exécute sur votre infrastructure et envoie uniquement le hachage du commit à l’API Timestamp GIT.

Il n’y a rien à installer sur vos machines de développement. Votre flux de travail Git local reste inchangé.

Étape 2 : Continuez à committer du code comme d’habitude

Une fois l’App installée, les webhooks notifient Timestamp GIT chaque fois qu’un nouveau commit apparaît. En mode entreprise à connaissance nulle, votre GitHub Action envoie le hachage à la place.

Votre flux de travail normal ressemble à ceci :

git add src/
git commit -m "Implement rate limiter v2"
git push origin main

Aucune commande d’horodatage supplémentaire n’est requise. Le commit lui-même est le déclencheur.

Étape 3 : Laissez le lot nocturne ancrer vos hachages

Timestamp GIT n’ancre pas chaque commit individuellement. Il regroupe le travail par lots pour plus d’efficacité tout en préservant un chemin vérifiable pour chaque hachage de commit.

Chaque jour, le système :

1. Détecte les nouveaux commits via les webhooks ou la GitHub Action.
2. Met en file d’attente les hachages de commit dans un stockage clé-valeur en mémoire.
3. Regroupe les hachages en attente dans des fichiers manifeste par dépôt lors d’un traitement planifié.
4. Construit un arbre de Merkle à partir du lot quotidien.
5. Crée des preuves OpenTimestamps en utilisant des calendriers OTS publics.
6. Ancre la racine de Merkle dans la blockchain Bitcoin.

La confirmation Bitcoin prend normalement environ trois heures, donc les fichiers de preuve apparaissent quelques heures après le lot nocturne.

Étape 4 : Recevez vos fichiers de preuve

Une fois l’ancre confirmée, Timestamp GIT pousse le matériel de preuve vers la branche d’horodatage dédiée ou le dépôt miroir que vous avez configuré.

La preuve comprend :

• Des fichiers manifeste qui enregistrent quels hachages de commit ont été inclus.
• Des fichiers de reçu .ots qui contiennent les données de preuve OpenTimestamps.

Vous pouvez inspecter ce qui est arrivé sur la branche de preuve :

git fetch origin timestamps
git ls-tree -r --name-only origin/timestamps | tail

Vous pouvez également intégrer un badge de vérification dans votre README via le point de terminaison de badge authentifié. Le badge affiche le statut vérifié actuel et renvoie vers la page de statut publique de votre dépôt.

Étape 5 : Vérifiez à tout moment — même sans Timestamp GIT

La vérification est disponible via les pages publiques du produit. La page de vérification cryptographique parcourt les données de la chaîne de Merkle localement dans votre navigateur, de sorte que le service ne voit pas ce que vous vérifiez.

Vous pouvez également télécharger le fichier .ots et le vérifier indépendamment en utilisant les outils OpenTimestamps standard contre la blockchain Bitcoin. Comme la preuve ne dépend que de SHA-256 et des données de blocs Bitcoin, la vérification ne nécessite pas que Timestamp GIT reste en ligne.

Une vérification rapide du statut peut être effectuée via l’API publique :

curl -s https://timestampgit.dev/api/statusSummary/your-user/your-repo

Pour un registre complet, vous pouvez télécharger un CSV d’audit. Pour un jour spécifique, vous pouvez télécharger un certificat PDF.

Déploiements auto-hébergés et entreprise

Si vous avez besoin d’une isolation maximale ou si vous travaillez dans un environnement isolé du réseau, Timestamp GIT est disponible sous forme d’image Docker avec une licence auto-hébergée. Une pile Compose minimale 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

Démarrez-la ensuite avec :

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

Au premier lancement, un assistant de configuration vous guide pour connecter votre GitHub App et configurer l’instance. Une licence de démonstration à durée limitée est disponible pour l’évaluation.

Le mode entreprise à connaissance nulle utilise une GitHub Action qui s’exécute sur votre propre infrastructure. Elle envoie uniquement le hachage du commit à l’API Timestamp GIT, de sorte que votre code source ne quitte jamais votre environnement.

Ce qu’il faut éviter pour prouver la paternité d’un logiciel

Ne vous fiez pas uniquement aux journaux internes ou aux horodatages de contrôle de version. Ils ne sont pas infalsifiables. Un tribunal ou un auditeur peut les écarter comme étant intéressés, même s’ils sont exacts.

Ne révélez pas votre code source dans le processus de preuve. Un horodatage doit prouver que le code existait, pas publier ce qu’il fait. Utilisez une méthode à connaissance nulle qui n’ancre qu’un hachage à sens unique. Cela protège les secrets commerciaux et évite toute divulgation accidentelle.

N’utilisez pas de services d’horodatage propriétaires qui pourraient disparaître ou altérer les enregistrements. Si la preuve dépend d’un système fermé, vous revenez à faire confiance à un intermédiaire. Les normes ouvertes comme SHA-256, OpenTimestamps et Bitcoin sont vérifiables sans le fournisseur.

N’attendez pas qu’un litige survienne. Commencez à horodater tôt et souvent. Une chaîne continue de commits ancrés montre un modèle de travail continu, et non une tentative de dernière minute pour fabriquer des preuves.

L’approche manuelle d’OpenTimestamps exigerait d’exploiter le protocole vous-même. Timestamp GIT existe pour masquer cette complexité derrière une GitHub App et un pipeline nocturne automatisé.

FAQ

Qu’est-ce que la preuve cryptographique de paternité d’un logiciel exactement ?

La preuve cryptographique de paternité d’un logiciel est une méthode permettant de prouver qu’une version spécifique de votre code existait à un moment donné, sans révéler le code lui-même. Elle fonctionne en créant un hachage unique, ou empreinte, du code et en ancrant ce hachage dans un registre public immuable comme la blockchain Bitcoin. N’importe qui peut ensuite vérifier que le hachage existait à ce moment-là, fournissant une preuve infalsifiable de paternité.

Comment Timestamp GIT prouve-t-il la paternité sans voir mon code ?

Timestamp GIT utilise une approche à connaissance nulle. Il ne lit que le hachage du commit, qui est une empreinte cryptographique, jamais le code source réel. Le hachage est inclus dans un arbre de Merkle et ancré dans Bitcoin via le protocole OpenTimestamps. Comme le hachage est à sens unique, personne ne peut l’inverser pour voir votre code, mais l’horodatage prouve que le code existait à ce moment-là.

Puis-je vérifier l’horodatage moi-même si Timestamp GIT disparaît ?

Oui. La preuve repose entièrement sur des normes ouvertes : SHA-256, Bitcoin et OpenTimestamps. Vous recevez des fichiers de reçu .ots qui peuvent être vérifiés indépendamment en utilisant les outils OpenTimestamps standard contre la blockchain Bitcoin. Aucune technologie ou service propriétaire n’est requis pour la vérification, donc votre preuve reste valide même si Timestamp GIT cesse d’exister.

Est-ce juridiquement reconnu ?

Les horodatages cryptographiques ancrés dans des blockchains publiques sont de plus en plus reconnus comme des preuves solides dans les procédures judiciaires. Ils fournissent un enregistrement d’existence à un moment précis infalsifiable et mathématiquement vérifiable. La reconnaissance juridique varie selon la juridiction, mais ces preuves sont bien plus robustes que les journaux internes ou les horodatages d’e-mails. Elles peuvent être présentées aux tribunaux, aux auditeurs ou aux parties adverses pour établir l’antériorité ou la paternité.

Combien coûte Timestamp GIT ?

Les dépôts publics sont pris en charge par un plan gratuit. Les dépôts privés sont disponibles avec le plan Pro Agency à 49 $ par mois. Le mode entreprise à connaissance nulle, qui utilise les GitHub Actions, est disponible à 199 $ par mois. Une licence de démonstration à durée limitée est également disponible pour l’évaluation auto-hébergée avec Docker.

Conclusion : intégrez la preuve de paternité à votre flux de travail

Prouver la paternité d’un logiciel ne doit pas compliquer votre processus de développement. Timestamp GIT transforme automatiquement vos commits Git existants en reçus ancrés dans Bitcoin. Le flux de travail est à connaissance nulle, ce qui signifie que votre code source reste privé. La preuve est indépendante du fournisseur, ce qui signifie qu’elle reste vérifiable même si le service disparaît.

Installez la GitHub App Timestamp GIT, connectez un dépôt et laissez l’ancrage nocturne s’exécuter en arrière-plan. Les dépôts publics peuvent commencer gratuitement, tandis que les dépôts privés sont couverts par les plans Pro et Enterprise. Une fois la première confirmation Bitcoin arrivée, vous aurez une réponse cryptographique à la question : « Pouvez-vous prouver que vous avez écrit cela en premier ? »

Articles connexes

• Comment vérifier un horodatage de commit Git
• Horodater automatiquement les commits Git avec une GitHub App
• Qu’est-ce que l’antériorité cryptographique et pourquoi est-ce important pour les logiciels ?