Prouver la paternité d’un code source pour freelances et ESN

Quand tout se passe bien, un repo Git suffit dans les échanges entre développeurs. Mais en cas de litige (client qui conteste, ancien prestataire, départ d'un salarié, conflit ESN/client), un historique Git seul peut être discuté : il peut être réécrit, rejoué, dupliqué, et ne prouve pas toujours à lui seul l'existence d'une version à une date donnée. (Git)

Le but n'est pas de construire une "preuve absolue". C'est de muscler votre dossier avec une méthode claire : traçabilité (repo + releases) + intégrité (hash) + horodatage (preuve de date) + conservation.

Prouver la paternité d'un code, c'est démontrer que vous déteniez une version précise à une date donnée et que cette version n'a pas été altérée.

Dans ce guide, on déroule un workflow directement exploitable : repo, commits, releases -> archive zip/tar -> hash -> horodatage -> pack preuve.

Définition simple

Prouver la paternité d'un code source consiste à pouvoir démontrer :

1. Qui a produit (ou, au minimum, détenu) une version donnée.
2. Quand cette version existait déjà.
3. Que le contenu présenté aujourd'hui est identique à celui de l'époque.

En droit français, l'auteur jouit en principe de droits du seul fait de la création, indépendamment d'un contrat de prestation (sous réserve des exceptions légales). (Légifrance)

Pour les logiciels créés par des salariés dans l'exercice de leurs fonctions, un régime spécifique s'applique : les droits patrimoniaux peuvent être dévolus à l'employeur, sauf stipulation contraire. (Légifrance)

Comment ça marche

L'idée est de figer une "photo" vérifiable du code, puis de l'ancrer dans le temps.

• Repo + commits : traçabilité.
• Tag/release : version stable et nommée.
• Archive + hash : contenu figé et empreinte d'intégrité.
• Horodatage : preuve d'existence à date.
• Archivage : conservation du dossier pour vérification ultérieure.

1. 1
   Stabiliser une version et la nommer

   Choisissez un jalon (fin de sprint, livraison), puis créez un tag/release clair, par exemple v1.3.0-livraison-2026-02-22. Signez le tag si vous avez une clé configurée.
2. 2
   Signer commits et tags

   Activez la signature GPG/SSH/S/MIME. Sur GitHub ou GitLab, le statut Verified renforce l'attribution et l'authenticité perçue.
3. 3
   Exporter une archive de livraison

   Générez un zip/tar de la version taggée. Ajoutez un MANIFEST avec version, hash, date, commit et périmètre livré.
4. 4
   Calculer et conserver les hash

   Calculez un SHA-256 de l'archive. Cette empreinte est votre référence d'intégrité : un octet modifié, hash différent.
5. 5
   Horodater l'empreinte

   Horodatez l'archive ou son hash via un mécanisme vérifiable (ex. OpenTimestamps). Conservez le fichier de preuve (.ots).
6. 6
   Constituer un pack preuve

   Conservez archive, hash, preuve d'horodatage, export release, et pièces de contexte (contrat, BC, emails, CR). Stockage redondant recommandé.

Exemples de commandes

Signer et vérifier un tag Git : (GitHub Docs)

git tag -s v1.3.0 -m "Release v1.3.0"
git tag -v v1.3.0

Activer la signature automatique des commits : (GitHub Docs)

git config --global commit.gpgsign true

Horodater une archive avec ots : (OpenTimestamps Client)

# Cree une preuve livraison-v1.3.0.zip.ots
ots stamp livraison-v1.3.0.zip

# Verifie la preuve (apres confirmation blockchain)
ots verify livraison-v1.3.0.zip.ots

Où LegalStamp apporte de la valeur

LegalStamp s'insère sur l'étape critique : vous fournissez une archive (zip/tar, export, PDF de livraison), la plateforme calcule le hash, applique un horodatage vérifiable, et vous restitue une preuve à archiver et re-vérifier plus tard.

Ce que ça prouve, et ce que ça ne prouve pas

Ce que ça prouve bien

• Antériorité : l'empreinte de l'archive existait à une date donnée (ou avant un bloc Bitcoin avec OpenTimestamps). (OpenTimestamps)
• Intégrité : si l'archive change, le hash change.
• Attribution renforcée : commits/tags signés et statut Verified augmentent la crédibilité de l'origine. (GitHub Docs)

Ce que ça ne prouve pas à lui seul

• La paternité ou la titularité juridique dans l'absolu : le contexte contractuel reste déterminant. (Légifrance)
• L'absence totale de collaboration : il faut aussi tickets, CR, MR, revues.
• Une présomption eIDAS spécifique sur date/heure, sauf recours à un horodatage qualifié eIDAS. (ANSSI)

Bonnes pratiques (checklist)

• [ ] Travailler dans un repo avec issue tracker et merge requests.
• [ ] Activer la signature des commits/tags et vérifier les statuts Verified. (GitHub Docs)
• [ ] Créer une release nommée à chaque jalon (version + date + scope).
• [ ] Générer une archive livrable (zip/tar) depuis le tag/release.
• [ ] Ajouter un MANIFEST.txt (version, commit, date, liste fichiers, hash).
• [ ] Calculer le hash SHA-256 de l'archive.
• [ ] Horodater et conserver la preuve (fichier .ots ou reçu équivalent). (OpenTimestamps Client)
• [ ] Conserver un pack preuve complet (contrat/BC, échanges, CR, release notes, facturation).
• [ ] Stocker en redondant (cloud + coffre + support offline chiffré).
• [ ] Préparer une procédure litige (qui fournit quoi, comment vérifier, qui explique).

FAQ

1) Un repo Git suffit-il pour prouver que j'ai écrit le code ?

Il aide, mais peut être contesté. En cas d'enjeu, ajoutez release/tag signé, archive, hash et horodatage. (Git)

2) À quoi sert la signature des commits et tags ?

Elle lie cryptographiquement un commit/tag à une clé (GPG/SSH/S/MIME). Le statut Verified renforce la crédibilité de l'attribution. (GitHub Docs)

3) Pourquoi faire un zip/tar en plus du repo ?

Parce qu'un livrable figé est plus simple à expliquer et à comparer en cas de litige.

4) L'horodatage révèle-t-il mon code ?

Non si vous horodatez une empreinte. Le contenu n'est pas publié, uniquement le digest. (OpenTimestamps Client)

5) Combien de temps prend la confirmation OpenTimestamps ?

La confirmation complète peut prendre un certain délai selon l'ancrage blockchain, souvent quelques heures. (OpenTimestamps Client)

6) En ESN, qui détient les droits ?

Pour un logiciel créé par un salarié dans ses fonctions, les droits patrimoniaux peuvent être dévolus à l'employeur, sauf clause contraire. (Légifrance)

7) En freelance, le client devient-il automatiquement propriétaire ?

Pas automatiquement par principe. Les clauses de cession ou licence contractuelles sont déterminantes. (Légifrance)

8) L'horodatage eIDAS change-t-il la donne ?

Oui sur le plan probatoire : un horodatage qualifié eIDAS bénéficie de présomptions spécifiques sur date/heure et intégrité. (ANSSI)

Conclusion

Un repo Git seul ne suffit pas en cas de litige sérieux. Ce qui tient, c'est la superposition : Git pour la traçabilité, signatures pour l'attribution, release + archive pour figer un état, hash + horodatage pour dater et garantir l'intégrité, archivage long terme pour pouvoir démontrer plus tard.

LegalStamp gère la partie critique — geler, horodater, archiver, vérifier — sans alourdir la livraison quotidienne.

Disclaimer : article informatif et pédagogique, sans valeur de conseil juridique. Pour un cas concret (cession, salariat, sous-traitance, contentieux), faites valider votre stratégie par un professionnel du droit.