Horodater du code source et un dépôt Git : la méthode

Les dates des commits Git ne montrent pas quand votre code existait. N'importe qui peut leur donner la valeur de son choix, et un rebase les réécrit. Pour fixer une date sur votre code qu'un inconnu, un client ou un tribunal devra accepter, prenez un instantané exact du code, en général un ZIP d'un commit tagué, et apposez un horodatage électronique qualifié sur son empreinte. Seule l'empreinte quitte votre machine : la méthode fonctionne donc aussi pour du code privé ou propriétaire. Voici la procédure exacte, ce qu'elle établit et ce qu'elle n'établit pas.

Informations générales sur la preuve, pas un conseil juridique pour un litige précis.

Pourquoi votre historique Git n'est pas une preuve indépendante d'une date

Git enregistre deux dates sur chaque commit, la date d'auteur et la date de commit, et toutes deux proviennent de la machine qui crée le commit. Personne ne les vérifie. Définir GIT_AUTHOR_DATE et GIT_COMMITTER_DATE avant un commit, ou lancer git commit --amend --date, produit un historique qui dit ce que vous voulez. Le rebase interactif, les squash merges et les cherry-picks réécrivent des dates comme simple effet secondaire du travail courant.

Cela ne rend pas votre historique inutile. C'est une excellente preuve de la manière dont le code a été construit : petites étapes, raisonnement dans les messages de commit, issues, revues, branches abandonnées. C'est une preuve faible du moment, parce que la personne qui s'en prévaut est celle qui aurait pu l'écrire.

Les plateformes d'hébergement aident, sans combler l'écart. GitHub, GitLab et Bitbucket enregistrent l'heure à laquelle un push leur est parvenu, mais ces données sont détenues par une entreprise privée, peuvent être difficiles à obtenir plus tard et disparaissent avec un dépôt ou un compte supprimé. Un force-push remplace ce qui s'y trouvait.

En France, il n'existe pas de registre des œuvres. Les développeurs recourent souvent au dépôt auprès de l'APP (Agence pour la protection des programmes) ou à l'enveloppe e-Soleau de l'INPI. Ce sont des moyens de dater et de conserver un exemplaire, qui ne créent aucun droit : le droit d'auteur naît de la création. Tous deux supposent de confier une copie du code à un tiers.

Ce qu'apporte un horodatage qualifié

Un horodatage électronique qualifié est délivré par un prestataire de services de confiance supervisé, en application du règlement européen eIDAS. Selon son article 41, paragraphe 2, les juridictions de chaque État membre présument l'exactitude de sa date et de son heure, ainsi que l'intégrité des données qu'il couvre. La date ne vient pas de vous : on ne peut donc pas la contester au motif que vous l'auriez fixée vous-même.

L'horodatage est lié à l'empreinte SHA-256 d'un fichier. Modifiez un seul octet et l'empreinte ne correspond plus. C'est pourquoi la méthode ci-dessous consiste à choisir un fichier exact et à le conserver.

Méthode 1 : horodater un ZIP d'un commit tagué (la plus solide)

1. Taguez l'état que vous voulez fixer. git tag v1.4.0 (ou utilisez un commit déjà tagué).
2. Exportez exactement cet état. git archive --format=zip -o monprojet-v1.4.0.zip v1.4.0. L'archive contient les fichiers suivis à ce commit et rien d'autre : pas de .env, pas de résultat de build, pas de modifications non commitées.
3. Faites délivrer un certificat pour ce ZIP. L'empreinte est calculée dans votre navigateur ; le ZIP lui-même n'est pas téléversé. Les fichiers jusqu'à 500 Mo sont acceptés.
4. Conservez le ZIP sans le modifier à côté du PDF du certificat, à au moins deux endroits. Ne le décompressez pas pour le recompresser : une nouvelle archive de fichiers identiques peut tout de même avoir une autre empreinte.

Pourquoi un ZIP et pas le dossier : le certificat couvre un seul fichier. Une archive transforme toute l'arborescence en un fichier unique, dont vous pourrez recalculer l'empreinte plus tard avec n'importe quel outil SHA-256. La sortie de git archive peut varier d'une version de Git à l'autre ; c'est justement pour cela que vous gardez l'archive horodatée au lieu de compter la régénérer.

Méthode 2 : horodater une fiche de commit (légère)

Si vous voulez dater de nombreux commits à moindre coût, ou si le dépôt dépasse 500 Mo, rédigez un court fichier texte et horodatez-le à la place :

repository: git@example.com:moi/monprojet.git
tag: v1.4.0
commit: 3f9c2e7d0a5b8c1e4f6a9d2b7c0e3f5a8b1d4c6e
tree: 9b2e4d6f8a0c1e3b5d7f9a1c3e5b7d9f0a2c4e6b
note: release candidate envoyée au client à sa demande

Remplissez les lignes commit et tree avec les vraies valeurs de git rev-parse v1.4.0 et git rev-parse v1.4.0^{tree}. Un identifiant de commit Git est un hash calculé sur l'arbre du commit, ses parents et son message : il rattache donc l'horodatage à cet état exact du code et à tout l'historique antérieur. Conservez le dépôt en sécurité, avec ce commit ; sans lui, le fichier texte seul ne montre rien.

La contrepartie : le lien entre le fichier texte et votre code repose sur le hachage propre à Git. La plupart des dépôts utilisent encore SHA-1 pour les identifiants d'objets, qui fait l'objet d'attaques par collision connues, même si Git intègre une détection de l'attaque connue. Pour un jalon de routine, cela suffit généralement. Pour la version sur laquelle vous vous appuierez le plus probablement en cas de litige, utilisez la méthode 1, où l'horodatage couvre les fichiers eux-mêmes.

Quelle méthode, dans quel cas

Code privé et propriétaire

L'empreinte est calculée sur votre appareil. Sauf si vous choisissez expressément de conserver une copie du fichier, StampR ne reçoit que l'empreinte, le nom et la taille du fichier, et les informations que vous saisissez. L'empreinte ne permet pas de reconstituer le code. Pour du code propriétaire, laissez décochée l'option de conserver et d'afficher l'original : un original conservé est affiché sur la page publique du certificat.

Choisissez le nom du fichier et la description avec le même soin. Les deux sont imprimés sur le certificat. monprojet-v1.4.0.zip ne pose pas de problème ; un nom qui révèle un produit non annoncé, peut-être si.

Ce que cela ne fait pas

• Cela ne montre pas que vous avez écrit le code. Cela montre que ce code exact existait à ce moment-là et que vous l'avez déclaré vôtre. Votre historique de commits, vos issues et vos notes de conception montrent le travail accompli.
• Cela ne tranche pas la question de la titularité du code. Dans l'UE, lorsqu'un salarié crée un programme dans l'exercice de ses fonctions, l'employeur est habilité à exercer les droits patrimoniaux, sauf dispositions contractuelles contraires (directive 2009/24/CE, article 2, paragraphe 3 ; en France, article L113-9 du Code de la propriété intellectuelle). Pour le travail en freelance ou en agence, tout dépend du contrat. Un horodatage fixe des dates ; il ne prime pas sur un accord.
• Cela ne couvre pas une idée ou un algorithme en tant que tels. Le droit d'auteur européen sur les logiciels porte sur l'expression d'un programme, pas sur les idées et principes qui le sous-tendent (directive 2009/24/CE, article 1, paragraphe 2). Les questions de brevet sont distinctes, et une publication peut les affecter.
• Cela ne remplace pas une licence. Si vous publiez du code, choisissez et joignez une licence ; l'horodatage est un élément de preuve, pas une autorisation.

Horodatez un instantané de votre code : le premier certificat avec un compte coûte 4,90 €.

Vérifier plus tard

N'importe qui peut vérifier le certificat sans avoir à vous faire confiance. Lancez sha256sum monprojet-v1.4.0.zip (macOS : shasum -a 256, Windows : Get-FileHash), puis comparez le résultat avec l'empreinte figurant sur le certificat, ou saisissez-la sur la page de vérification. Si elles correspondent, le fichier est, octet pour octet, celui qui a été horodaté.

Pour aller plus loin

• Horodater des centaines de fichiers avec un seul certificat : la méthode du manifeste, quand un ZIP n'est pas pratique.
• Un horodatage tient-il devant un tribunal ? : ce que change la présomption eIDAS dans un litige.
• Toutes les options pour consigner la paternité d'une œuvre, comparées : y compris quand un horodatage n'est pas le bon outil.

Questions fréquentes

Les dates des commits Git peuvent-elles servir de preuve du moment où le code a été écrit ?

On peut les produire, mais elles sont faibles sur la date, parce qu'elles sont fixées par la machine qui crée le commit et peuvent être modifiées par des variables d'environnement, un amend ou un rebase. Elles montrent bien comment le travail a progressé, et fonctionnent au mieux aux côtés d'une date indépendante, comme un horodatage qualifié.

Dois-je téléverser mon code source ?

Non. L'empreinte SHA-256 est calculée dans votre navigateur et seule l'empreinte est envoyée, sauf si vous choisissez de conserver une copie du fichier. Pour du code propriétaire, ne conservez pas de copie.

Faut-il horodater le ZIP ou le hash du commit ?

Le ZIP d'un commit tagué est l'option la plus solide, car l'horodatage couvre directement les fichiers. Un fichier texte contenant l'identifiant du commit coûte moins cher pour des jalons réguliers et couvre tout l'historique antérieur, mais son lien avec le code repose sur le hachage propre à Git.

L'heure d'un push sur GitHub suffit-elle ?

C'est un élément complémentaire utile, mais il est détenu par une plateforme privée, peut être difficile à obtenir plus tard et disparaît si le dépôt ou le compte est supprimé. Un horodatage qualifié est conservé par vous et présumé exact par les juridictions de l'UE.

Un horodatage montre-t-il que le code m'appartient ?

Non. La titularité dépend de qui l'a écrit et des contrats de travail ou de prestation. L'horodatage établit que ce code exact existait à un moment donné et que vous l'avez déclaré vôtre.

À quelle fréquence faut-il horodater ?

Aux moments que vous pourriez devoir invoquer plus tard : avant de remettre du code à quelqu'un, avant un changement de licence, à la fin d'un contrat et lors des versions majeures. Beaucoup de développeurs ajoutent entre-temps une fiche de commit mensuelle.