Prouver la propriété des logiciels : scellé cryptographique pour le code source (2026)

Si vous pensez que l'historique de vos commits git prouve que vous avez écrit le code, un avocat adverse démolira cette affirmation en quelques minutes. Les horodatages git sont définis par l'horloge locale du committer — pas par une autorité indépendante et accréditée. Toute personne ayant accès au dépôt peut réécrire l'historique, antidater des commits ou recommitter à partir d'un horodatage manipulé. Un scellé cryptographique qualifié ne présente pas ces faiblesses.

Pourquoi l'historique git est une preuve fragile devant les tribunaux

Git est un outil de collaboration, pas un système d'archivage juridique. L'historique est mutable par conception : git commit --amend modifie l'horodatage d'un commit, git push --force réécrit une branche entière, et un acteur malveillant peut cloner votre dépôt public, ajouter des commits antidatés et publier le fork comme l'original.

Même sans fraude délibérée, les horodatages git sont contestables. Une horloge système mal configurée ou un pipeline CI/CD recommittant des artefacts compilés produit des horodatages que les tribunaux traitent comme de simples indices. Dans un litige portant sur qui a écrit un algorithme propriétaire en premier, l'historique git est un point de départ — pas une conclusion.

Ce qu'apportent les horodatages électroniques qualifiés

Swiss Trust Layer calcule un hash SHA-256 de votre fichier source ou de l'archive ZIP du dépôt — modifiez un seul caractère et le hash change complètement — et soumet ce hash à Swisscom Trust Services, un Qualified Trust Service Provider (QTSP) accrédité selon le droit européen et suisse. Swisscom émet un horodatage conforme à RFC 3161, liant votre hash à une heure UTC précise avec une signature cryptographique qu'aucune des parties ne peut modifier.

Le résultat est un certificat conforme PAdES que tout le monde peut vérifier sur swisstrustlayer.com/validate — sans contact avec vous. En vertu de l'eIDAS Art. 41, l'horodatage bénéficie d'une présomption légale d'exactitude dans les 27 États membres de l'UE. ZertES Art. 2 prévoit la même présomption en droit suisse. C'est une valeur probante fondamentalement différente de celle d'un git log.

Trois scénarios critiques où les développeurs en ont besoin

Litige avec un prestataire — qui a écrit l'algorithme en premier ?

Un développeur freelance livre un modèle de machine learning. Des mois plus tard, le client affirme que l'algorithme a été développé en interne avant le début du contrat. Le dépôt interne du client peut être fabriqué rétroactivement. Un scellé qualifié sur le prototype initial du prestataire, horodaté avant la date revendiquée par le client, fournit un prior art présumé légalement qui ne peut être écarté comme une erreur d'horloge ou un commit réécrit.

Due diligence des investisseurs — prouver la chaîne de titre IP

Les équipes VC et M&A exigent désormais systématiquement la provenance des logiciels IP. Un scellé cryptographique sur la base de code à chaque étape clé — prototype, Series A, Series B — crée une chaîne de titre auditée qui satisfait les équipes juridiques sans se fier uniquement à l'historique git.

Licence open-source — établir un prior art avant un fork

Si une entité commerciale forke votre bibliothèque, supprime les attributions et la relicencie, votre meilleure défense est la date de publication originale. Un horodatage qualifié sur la première version publique vous donne un dossier de prior art juridiquement solide que le fork ne peut antidater.

Étape par étape : sceller un fichier source ou une archive ZIP de dépôt

Étape 1 : Préparer l'artefact. Pour un fichier unique, utilisez directement le fichier source. Pour un dépôt complet, exportez une archive ZIP — git archive --format=zip HEAD > repo-v1.0.zip. Tout fichier jusqu'à 500 Mo est pris en charge.

Étape 2 : Télécharger sur swisstrustlayer.com. Le hash SHA-256 est calculé côté client. Votre code source ne quitte jamais votre navigateur — seul le hash est transmis aux serveurs de Swiss Trust Layer.

Étape 3 : L'horodatage qualifié est émis. Swisscom Trust Services ancre votre hash dans un horodatage électronique qualifié conforme à RFC 3161. C'est l'événement juridiquement contraignant.

Étape 4 : Télécharger votre certificat. Le certificat conforme PAdES contient votre hash de fichier, l'horodatage, la chaîne d'émetteur et l'identité vérifiée. Conservez-le à côté du fichier original ou committez-le dans un dépôt de preuves séparé.

Étape 5 : Vérifier de manière indépendante. Partagez le lien de vérification sur /validate avec tout tiers — investisseur, avocat, fondation open-source — qui doit confirmer votre revendication de prior art sans vous croire sur parole.

Valeur juridique : le fondement réglementaire

Le logiciel est protégé comme œuvre littéraire en vertu de la Convention de Berne Art. 5 — le droit d'auteur existe dès la création dans 181 États membres, sans enregistrement requis. Mais la Convention protège le droit ; elle ne prouve pas la date. C'est précisément ce que fait un horodatage qualifié.

L'eIDAS Art. 41 accorde une présomption légale d'exactitude à la date et à l'heure indiquées par un horodatage électronique qualifié — opérant devant tout tribunal de l'UE, la charge de la réfutation incombant au contestataire. ZertES Art. 2 est l'équivalent en droit suisse. Ce sont des présomptions légales, pas des lignes directrices.

Foire aux questions

Un horodatage de commit git constitue-t-il une preuve légalement contraignante de paternité ?

Non. Les horodatages git sont définis par l'horloge système locale du committer et peuvent être modifiés par toute personne ayant accès au dépôt via des commandes git standard. Ils sont traités comme des indices, pas comme des preuves faisant autorité. Un horodatage électronique qualifié d'un QTSP accrédité en vertu de l'eIDAS Art. 41 bénéficie d'une présomption légale d'exactitude que l'historique git ne possède pas.

Puis-je sceller un dépôt entier, pas seulement un fichier ?

Oui. Exportez votre dépôt en archive ZIP avec git archive --format=zip HEAD > repo.zip, puis sceller le fichier ZIP. Swiss Trust Layer prend en charge n'importe quel format de fichier jusqu'à 500 Mo, de sorte qu'une base de code complète — y compris la documentation, les tests et les scripts de build — peut être scellée en une seule opération. Le hash SHA-256 couvre le contenu binaire exact de l'archive entière.

Le scellé du code source expose-t-il mon code propriétaire à Swiss Trust Layer ?

Non. Le hash SHA-256 est calculé dans votre navigateur avant toute transmission. Swiss Trust Layer reçoit uniquement le hash — une chaîne hexadécimale de 64 caractères — jamais le code source lui-même. Vos algorithmes propriétaires et détails d'implémentation restent entièrement privés.

Que se passe-t-il si je scelle un fichier puis effectue des commits par-dessus ?

Chaque scellé est un instantané à un moment précis. Sceller à nouveau lors de la publication d'une nouvelle version. La série de scellés crée un parcours de provenance montrant l'évolution de votre base de code — utile pour la due diligence des investisseurs et les preuves de développement continu.

Combien coûte le scellé de code source sur Swiss Trust Layer ?

Le scellé commence à CHF 5 par document. Des plans volumiques sont disponibles pour les équipes avec des cycles de livraison fréquents. Le coût d'un horodatage qualifié représente une fraction des honoraires juridiques dans tout litige IP.

L'historique git est un enregistrement de développement. Ce n'est pas un instrument juridique. Pour les prestataires, fondateurs et mainteneurs open-source qui doivent prouver qu'ils ont écrit le code en premier, un scellé cryptographique qualifié — ancré auprès d'une autorité d'horodatage indépendante et accréditée et admissible sous eIDAS, ZertES et la Convention de Berne — est la seule preuve que les tribunaux traitent comme présumément exacte. Sceller votre base de code avant que le litige ne survienne. En savoir plus sur le cadre juridique sur /eidas et /zertes.