Pourquoi la date Git ne suffit pas pour protéger la propriété intellectuelle de vos logiciels

« Git horodate déjà notre code » : c'est l'objection que nous entendons le plus souvent des équipes techniques lorsqu'une direction juridique souhaite sécuriser la preuve de ses développements logiciels. Et elle est parfaitement fondée sur le plan technique : Git enregistre bien une date pour chaque version du code.

Mais il faut distinguer la réalité technique de la réalité juridique. Git a été conçu pour faire collaborer des développeurs, pas pour un cas d'usage de datation PI. Reprenons les choses dans l'ordre.

1. Que vaut réellement une date Git ?

a) Une date déclarative, fixée par le poste du développeur

Chaque version du code (chaque « commit ») porte deux dates : celle de l'auteur et celle de l'intégrateur. Toutes deux proviennent de l'horloge locale de la machine du développeur, et toutes deux se modifient librement.

Admettons qu'un développeur souhaite faire apparaître aujourd'hui un commit daté d'il y a dix ans. Une seule ligne suffit :

GIT_COMMITTER_DATE="2015-03-12T10:00:00" \
  git commit --date="2015-03-12T10:00:00" -m "Version 1.0"

Une fois publié, ce commit apparaîtra daté du 12 mars 2015 dans tout l'historique, y compris sur GitHub.

Réécrire l'historique n'est pas un détournement de Git. Les commandes qui le permettent (amend, rebase, force push) font partie du quotidien des développeurs et sont prévues par l'outil.

b) La signature des commits ne change rien

On nous oppose parfois la signature cryptographique des commits. Elle atteste l'identité du signataire, pas la véracité de la date qu'il a déclarée. Un commit signé et antidaté reste un commit antidaté.

c) Et les dates conservées par le serveur ?

GitHub, GitLab ou Bitbucket enregistrent effectivement la date à laquelle le code leur a été transmis. Distinguons deux situations.

• En auto-hébergement, fréquent dans les grandes entreprises pour des raisons de confidentialité, l'administrateur de la plateforme a la main sur ces données. Elles dépendent donc de vous.
• Sur une plateforme hébergée, ces dates existent mais il s'agit de journaux techniques internes d'un prestataire tiers, souvent étranger, qui n'ont pas été conçus pour servir de preuve. Il faudra les obtenir, puis les faire interpréter par un expert : c'est long, coûteux et à l'issue incertaine. Et elles ne certifient pas le contenu : elles indiquent qu'une opération a eu lieu, pas ce que le code contenait précisément à cet instant.

2. Pourquoi le problème est-il d'abord juridique ?

a) Un historique Git est recevable devant le juge

Soyons clairs : en droit français, la preuve d'un fait juridique est libre (article 1358 du Code civil). La création d'un logiciel est un fait. Un historique Git, des journaux serveur ou un e-mail sont donc parfaitement recevables pour tenter d'établir une date de création.

b) Recevable ne veut pas dire convaincant

La question n'est pas de savoir si le juge acceptera de regarder votre historique Git, mais quel poids il lui accordera. Cette force probante relève de son appréciation souveraine.

En droit d'auteur, le logiciel est protégé dès sa création, sans formalité. C'est un avantage, mais il a un revers : en cas de litige, c'est à vous de prouver ce que vous avez créé, et quand. Un contrefacteur de mauvaise foi n'aura qu'à rappeler que la date d'un commit se modifie en une commande pour semer le doute. Vous aurez peut-être raison sur le fond, mais vous entrerez dans un débat d'expertise que vous n'avez pas choisi, avec une preuve dont la valeur dépendra de la conviction du juge.

Le cas du dépôt public est différent : un projet open source visible depuis des années, avec ses contributeurs, ses forks et ses discussions, forme un faisceau d'indices difficile à contester. Mais le code qui a de la valeur pour votre entreprise est, par définition, celui que vous ne publiez pas.

3. Ce que change l'ancrage blockchain de chaque version du code

a) Une date qui ne dépend de personne

L'ancrage blockchain consiste à calculer l'empreinte numérique de chaque version du code et à l'inscrire dans une blockchain publique. La date obtenue ne dépend ni de vous, ni de votre hébergeur, ni de votre prestataire. L'intégrité et l'antériorité sont vérifiables par tous.

b) Une preuve déjà reconnue par les tribunaux

Le 20 mars 2025, le Tribunal judiciaire de Marseille a prononcé la première condamnation pour contrefaçon sur la base d'une preuve BlockchainyourIP.

c) Quatre bénéfices concrets pour une direction juridique

• Chaque version est datée automatiquement, sans jamais solliciter les développeurs.
• Le juridique dispose d'une visibilité sur les projets en cours, sans avoir à ouvrir Git.
• Vous délimitez précisément le périmètre de vos secrets d'affaires, ce qui contribue aux mesures de protection raisonnables.
• Le jour où il faut négocier ou agir, vous disposez d'une preuve dédiée, déjà reconnue par un tribunal.

Gardez Git, ajoutez la preuve

Git est un excellent outil de collaboration pour les développeurs. BlockchainyourIP fonctionne comme une surcouche à Git : chaque version de votre code est ancrée automatiquement, avec une date que personne ne peut modifier, dans un outil pensé pour les juristes. Vos développeurs continuent de travailler comme avant, mais leur développement est protégé automatiquement au fil de l'eau, et vous êtes en mesure de réagir en cas de détournement de votre propriété intellectuelle.