Protection du code pour les freelances : une solution d’horodatage

Alex est développeuse full-stack freelance. Il y a dix-huit mois, elle a créé une bibliothèque d’authentification réutilisable pour un projet client. Le contrat était léger sur les clauses de propriété intellectuelle, et le travail a été livré via un dépôt GitHub privé. La semaine dernière, Alex a trouvé un module d’authentification étrangement familier dans le nouveau produit SaaS du même client — une logique qu’elle avait écrite, réorganisée juste assez pour paraître différente.

Lorsqu’Alex a soulevé la question, le client a affirmé avoir développé la fonctionnalité de manière indépendante. Alex dispose de l’historique Git local, de fils d’e-mails et de quelques exports de fichiers. Mais l’avocat du client qualifie ces preuves d’intéressées et modifiables. Sans accord formel de propriété intellectuelle et sans enregistrement indépendant de la date d’existence de son code, Alex est bloquée.

C’est le cauchemar du freelance en matière de plagiat. Le travail technique est fait, mais la preuve manque.

Le cauchemar du plagiat pour les freelances

Les freelances disposent rarement de l’infrastructure juridique d’une entreprise. La plupart du travail repose sur un mélange de confiance, un contrat qui peut ne pas mentionner la propriété du code, et un dépôt Git auquel le client a peut-être encore accès ou non. Lorsqu’un litige survient, la situation des preuves est souvent pire que prévu.

Les sources de preuve courantes échouent rapidement :

• Les e-mails horodatés peuvent être transférés, modifiés ou écartés comme n’étant pas liés au code réel.
• Les dates de modification des fichiers sont des métadonnées locales et peuvent être modifiées avec des outils de base.
• Les dates de commit Git sont également des métadonnées. Elles peuvent être définies sur des valeurs arbitraires lors du commit, de sorte qu’un tribunal ou un client n’a aucune raison de les considérer comme infalsifiables.
• L’hébergement GitHub ou GitLab prouve que le code a existé sur le serveur de quelqu’un, mais pas nécessairement à une date précise, ni d’une manière indépendante du propriétaire du dépôt.

Pour Alex, la prise de conscience douloureuse est que « je l’ai écrit en premier » exige plus qu’une mémoire et un graphe de commits. Cela exige un horodatage que personne ne peut réécrire.

Pourquoi les freelances ont besoin d’un état de la technique cryptographique

Un hash de commit Git est une empreinte cryptographique à sens unique de l’état exact du dépôt à un instant donné. C’est un bon point de départ : le hash est mathématiquement lié au code. Mais un hash seul ne prouve pas quand il a existé. Pour créer cette preuve, le hash doit être ancré dans un support public et immuable.

C’est là que Bitcoin entre en jeu.

L’horodatage cryptographique utilise la blockchain Bitcoin comme témoin indépendant. Lorsqu’un hash de commit est intégré dans une transaction Bitcoin via le protocole OpenTimestamps, l’existence de ce hash est figée dans un bloc Bitcoin spécifique. Une fois confirmé, ce bloc ne peut pas être modifié, réordonné ou supprimé sans réécrire l’histoire de Bitcoin — ce qu’aucune partie seule ne peut faire.

Pour les freelances, cela crée une forme d’état de la technique qui est :

• Indépendante : la preuve ne dépend pas de votre compte GitHub, de votre ordinateur portable ou de la volonté de votre client d’admettre quoi que ce soit.
• Vérifiable : n’importe qui peut vérifier le reçu .ots contre la blockchain Bitcoin sans avoir besoin des serveurs de Timestamp GIT.
• À divulgation nulle de connaissance : vous pouvez prouver qu’un hash de commit spécifique a existé sans révéler le code source qui se cache derrière.

Il ne s’agit pas seulement de plagiat. Le même mécanisme protège contre les trolls de brevets, les litiges avec des sous-traitants et les revendications de « salle blanche » de la part de concurrents. Si vous souhaitez un contexte plus approfondi sur la logique Bitcoin sous-jacente, consultez Comment Bitcoin peut prouver que votre propriété intellectuelle a existé en premier.

Pour cet article, l’objectif est plus restreint : donner aux développeurs freelances un moyen pratique de prouver la paternité avant qu’un litige ne survienne.

Un guide pratique : protéger votre code avec Timestamp GIT

Timestamp GIT automatise l’intégralité du flux de travail d’horodatage cryptographique. Vous n’avez pas besoin d’exécuter des commandes OpenTimestamps, de gérer des transactions Bitcoin ou de vous souvenir d’un processus d’horodatage manuel. Le flux de travail est conçu autour des outils que vous utilisez déjà en tant que freelance.

Étape 1 : installez l’application GitHub Timestamp GIT une seule fois

Commencez par installer l’application GitHub Timestamp GIT et sélectionnez les dépôts que vous souhaitez surveiller. Il s’agit d’une étape de configuration unique.

En mode standard, l’application GitHub ne lit que le hash du commit HEAD de chaque dépôt surveillé. Elle ne lit pas, ne copie pas et ne stocke pas votre code source. Le modèle de permissions de GitHub exige un accès en lecture au dépôt source pour la détection des commits, ainsi qu’un accès en écriture à un dépôt cible où les preuves seront stockées. La cible peut être le même dépôt ou un dépôt fantôme distinct.

Pour une procédure d’installation complète, consultez Horodater automatiquement chaque commit Git avec une application GitHub.

Étape 2 : continuez à committer comme d’habitude

Après l’installation, aucune étape supplémentaire n’est nécessaire dans votre flux de travail quotidien. Chaque nouveau hash de commit est détecté automatiquement, mis en file d’attente et inclus dans un lot nocturne.

Chaque nuit, Timestamp GIT regroupe les hashes de commit en attente par dépôt, crée un fichier manifeste, construit un arbre de Merkle et ancre la racine de Merkle dans la blockchain Bitcoin via le protocole OpenTimestamps. Vous continuez à écrire du code ; la preuve s’accumule en arrière-plan.

Étape 3 : récupérez vos reçus de preuve

Une fois qu’un lot est traité, Timestamp GIT renvoie le manifeste et les fichiers de reçu .ots vers une branche d’horodatage dédiée ou un dépôt fantôme. Comme la confirmation Bitcoin prend normalement environ trois heures, la livraison de la preuve n’est pas instantanée — mais elle ne nécessite aucune action de votre part.

Le fichier .ots est la preuve essentielle. Vous pouvez également générer un certificat PDF depuis le tableau de bord Timestamp GIT pour une date spécifique.

Étape 4 : affichez publiquement le statut de vérification

Timestamp GIT fournit des badges de vérification intégrables pour votre README. Après avoir connecté un dépôt, vous pouvez utiliser le widget de badge sur la page Repository Connected pour générer un extrait markdown avec l’URL correcte du badge Shields.io.

Un badge public fait deux choses pour les freelances : il montre aux clients que votre projet dispose d’une piste d’horodatage indépendante, et il rend la vérification immédiatement accessible.

Étape 5 : utilisez la preuve en cas de litige

Si un client prétend avoir développé de manière indépendante, vous pouvez remettre le reçu .ots et un lien de vérification. L’autre partie n’a pas besoin d’accéder à Timestamp GIT. Elle peut télécharger le reçu et le vérifier localement contre la blockchain Bitcoin à l’aide des outils OpenTimestamps standard.

Pour les dépôts privés, les URL de statut de vérification sont protégées par un HMAC chiffré afin que seuls les utilisateurs autorisés puissent consulter l’état d’horodatage du dépôt. La preuve elle-même reste vérifiable indépendamment via le fichier .ots.

Lorsque vous ne pouvez pas accorder l’accès au dépôt source

Certains contrats de freelance imposent des NDA stricts qui empêchent d’accorder à toute application tierce un accès en lecture au dépôt source. Dans ce cas, le mode Enterprise ZK est la solution adaptée. Une GitHub Action de 12 lignes s’exécute sur votre infrastructure et envoie uniquement le hash de commit à l’API Timestamp GIT. Votre code source ne quitte jamais votre environnement, et Timestamp GIT n’a pas besoin d’accès en lecture au dépôt source.

Ce qu’il faut éviter : les erreurs courantes en matière de protection du code

Avant qu’un litige ne survienne, les développeurs freelances s’appuient souvent sur des habitudes qui semblent sûres mais qui sont fragiles sous un examen approfondi. Évitez ces pratiques.

Se fier uniquement aux horodatages des e-mails ou aux journaux Git auto-hébergés

Un historique Git est utile pour votre propre débogage. Ce n’est pas une preuve d’existence indépendante. Les dates de commit peuvent être manipulées, et les journaux internes sont souvent considérés comme intéressés dans les litiges juridiques ou avec les clients. Utilisez Git pour le développement, mais ne le traitez pas comme un notaire.

Attendre qu’un litige survienne pour commencer à horodater

L’état de la technique cryptographique n’est utile que si l’horodatage existe avant le travail contesté. Horodater après qu’une réclamation a été faite ne prouve rien sur la date de création originale. La seule approche pratique consiste à horodater chaque commit dès le début d’un projet.

Utiliser les outils CLI OpenTimestamps manuels pour chaque commit

Le protocole brut fonctionne, mais le faire manuellement sur plusieurs projets freelance prend du temps et est source d’erreurs. Vous devriez construire votre propre système de traitement par lots, stocker les reçus, gérer la vérification et vous souvenir d’exécuter le processus de manière cohérente. C’est la voie difficile. Timestamp GIT existe pour remplacer ce travail manuel par un flux de travail géré et automatisé.

Supposer que la publication sur GitHub prouve la paternité

Publier du code sur GitHub prouve que le code est disponible maintenant. Cela ne prouve pas quand vous l’avez écrit, et cela ne crée pas un horodatage immuable. Un concurrent ou un ancien client peut toujours prétendre avoir construit quelque chose en premier. L’hébergement GitHub seul n’est pas une protection d’état de la technique.

Ignorer la chaîne de traçabilité des fichiers de preuve

Un reçu .ots n’est utile que si vous pouvez le retrouver et le relier au bon commit. Gardez les reçus organisés. Si un projet s’étend sur plusieurs dépôts ou clients, stockez les reçus avec les noms de projet et les dates. Timestamp GIT conserve les reçus dans une branche d’horodatage ou un dépôt fantôme, ce qui vous donne une chaîne de traçabilité cohérente sans classement manuel.

Timestamp GIT : la solution gérée sans configuration

Timestamp GIT est conçu pour les développeurs qui veulent une preuve cryptographique sans devenir des experts en horodatage. Une fois l’application GitHub installée, chaque commit vers un dépôt surveillé est ancré dans Bitcoin automatiquement chaque nuit. Pas d’outil CLI, pas de commande OpenTimestamps manuelle, pas de configuration locale du protocole.

Propriétés clés du flux de travail géré :

• Intégration de l’application GitHub : les dépôts surveillés sont connectés une seule fois, et les hashes de commit circulent automatiquement.
• Architecture à divulgation nulle de connaissance : Timestamp GIT n’horodate que les hashes de commit. Il ne lit jamais, ne copie jamais et ne stocke jamais le code source.
• Indépendance vis-à-vis du fournisseur : les preuves utilisent uniquement SHA-256 et les données de blocs Bitcoin. Vous pouvez tout vérifier hors ligne, même si Timestamp GIT disparaît.
• Rien à installer sur les machines des développeurs : le flux de travail SaaS géré s’exécute sans agents locaux.

Pour les freelances qui veulent un contrôle maximal ou qui ont besoin d’un environnement isolé, Timestamp GIT est également disponible sous forme d’image Docker auto-hébergée. Un docker-compose.yml de base 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-le avec :

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

L’application est alors disponible à l’adresse http://localhost:8080. Un assistant de configuration vous guide dans la connexion de votre application GitHub. Une licence de démonstration à durée limitée est disponible sur la page Docker License.

Pour la plupart des freelances, les offres gérées sont le point de départ pratique : Open Source est gratuit pour les dépôts publics, Pro Agency est à 49 $/mois pour les dépôts privés, et Enterprise ZK est à 199 $/mois pour le flux de travail basé sur GitHub Action sans accès en lecture.

Si vous comparez les options, consultez Timestamp GIT vs OpenTimestamps manuel : lequel est le meilleur ?.

FAQ : protection du code freelance avec Timestamp GIT

Timestamp GIT m’oblige-t-il à exposer mon code source ?

Non. Timestamp GIT ne lit que les hashes de commit, jamais votre code réel. En mode standard, l’application GitHub exige un accès en lecture au dépôt pour détecter les commits, mais elle ne stocke pas et ne transmet pas votre source. Pour une confidentialité maximale, le mode Enterprise ZK utilise une GitHub Action qui envoie uniquement le hash de commit à l’API, de sorte que votre code ne quitte jamais votre environnement.

Comment puis-je prouver que l’horodatage est authentique dans un litige juridique ?

Vous recevez un fichier de reçu .ots qui peut être vérifié indépendamment contre la blockchain Bitcoin à l’aide des outils OpenTimestamps standard. La preuve est mathématiquement absolue et ne dépend pas des serveurs de Timestamp GIT. Vous pouvez également générer un certificat PDF et partager un lien de vérification depuis le tableau de bord Timestamp GIT.

Que faire si je travaille sur des dépôts privés ?

Timestamp GIT prend en charge les dépôts privés avec l’offre Pro Agency à 49 $/mois. L’application GitHub exige un accès en lecture au dépôt source et un accès en écriture à un dépôt cible, qui peut être un dépôt fantôme. Pour les freelances soumis à des NDA stricts, le mode Enterprise ZK à 199 $/mois permet l’horodatage sans accorder d’accès en lecture au dépôt source.

L’horodatage est-il juridiquement reconnu ?

Les horodatages cryptographiques ancrés dans la blockchain Bitcoin sont de plus en plus acceptés comme preuve d’état de la technique et de paternité. Ils fournissent un enregistrement infalsifiable et vérifiable indépendamment. Cependant, la reconnaissance juridique varie selon les juridictions, alors consultez un conseiller juridique pour les cas spécifiques. Timestamp GIT fournit la preuve technique ; il ne remplace pas les conseils juridiques.

Conclusion : horodatez avant d’avoir besoin de la preuve

L’erreur d’Alex n’était pas un manque de compétence — c’était d’attendre le litige pour chercher une preuve. Les freelances ne peuvent pas compter sur la confiance, les fils d’e-mails ou les métadonnées Git modifiables lorsqu’un client prétend avoir développé de manière indépendante.

Timestamp GIT change la donne en rendant l’état de la technique cryptographique automatique. Installez l’application GitHub une fois, connectez les dépôts et continuez à committer. Chaque hash de commit est ancré dans Bitcoin chaque nuit, les reçus sont livrés dans une branche d’horodatage ou un dépôt fantôme, et vous obtenez un enregistrement vérifiable qui existe indépendamment de toute relation client.

Commencez avec des dépôts publics gratuits sur Timestamp GIT et prenez cette habitude dès maintenant. Le meilleur moment pour prouver que vous avez écrit quelque chose, c’est le jour où vous l’écrivez.

Articles connexes

• Comment Bitcoin peut prouver que votre propriété intellectuelle a existé en premier
• Horodater automatiquement chaque commit Git avec une application GitHub
• Timestamp GIT vs OpenTimestamps manuel : lequel est le meilleur ?