La question revient à chaque litige entre un prestataire et son client, ou entre associés qui se séparent : comment protéger du code ?

La réponse commence par une clarification. En Europe, un programme d'ordinateur n'est pas brevetable en tant que tel. La convention sur le brevet européen l'exclut explicitement, et le droit français reprend cette exclusion à l'article L611-10 du code de la propriété intellectuelle. Seule une invention technique mettant en oeuvre un logiciel peut, dans des conditions strictes, être brevetée.

Le logiciel relève du droit d'auteur. Il est protégé dès son écriture, sans formalité, comme une oeuvre littéraire.

Le problème n'est pas la protection, c'est la preuve

Votre code est donc protégé sans que vous ayez rien à faire. Mais en cas de conflit, la protection ne sert que si vous pouvez répondre à deux questions.

Que contenait exactement votre code à une date donnée ? Et pouvez-vous le démontrer autrement que par votre propre parole ?

Les situations où ces questions se posent sont banales. Un client refuse de payer et affirme que la livraison ne correspond pas à ce qui était convenu. Un ancien associé part avec une base de code et prétend l'avoir écrite. Un prestataire réutilise chez un concurrent un module développé pour vous. Un investisseur demande, lors d'un audit, ce qui appartient réellement à la société.

Pourquoi le dépôt Git ne suffit pas

La réaction immédiate d'un développeur est de montrer l'historique du dépôt. C'est une trace utile, mais elle a une faiblesse précise : les dates d'un commit sont déclaratives.

La date d'un commit provient de la machine qui l'a créé, et rien n'empêche de la fixer arbitrairement. Un historique entier peut être réécrit, et les identifiants recalculés en conséquence. Face à une partie adverse qui soulève ce point, l'historique perd beaucoup de sa force.

Un dépôt hébergé chez un tiers ajoute une trace côté hébergeur, ce qui est déjà mieux. Mais cette trace appartient à un prestataire privé, dépend de la conservation de votre compte, et disparaît si le dépôt est supprimé ou l'abonnement résilié. Elle n'est pas conçue pour faire preuve.

Ce que l'horodatage apporte au code

L'horodatage électronique certifié répond exactement à ce manque. Le principe est adapté au code : on ne transmet pas le code, on transmet son empreinte.

Une empreinte numérique est une suite de caractères calculée à partir du contenu exact d'un fichier. Modifier un octet, une espace, un commentaire, produit une empreinte entièrement différente. Cette empreinte seule est envoyée à une autorité d'horodatage indépendante, qui la scelle avec la date et l'heure et signe l'ensemble, selon la norme RFC 3161 et dans le cadre du règlement eIDAS.

Votre code, lui, ne circule jamais. C'est un point décisif quand le code est justement ce qu'on cherche à protéger.

Le résultat est une attestation vérifiable par n'importe qui, sans compte ni logiciel particulier. Un expert judiciaire, un avocat ou la partie adverse peut contrôler par lui-même que le fichier produit est bien celui qui a été daté.

Comment s'y prendre en pratique

Quelques choix rendent la preuve nettement plus solide.

Horodatez une archive, pas des fichiers isolés. Une archive de l'arborescence complète établit l'état d'un projet à un instant, pas seulement l'existence d'un fichier. C'est ce qui permet de démontrer une architecture, des choix de conception, une organisation, et pas seulement quelques lignes.

Horodatez aux moments qui comptent. Une livraison client, une mise en production, la fin d'une mission, l'entrée d'un associé, une levée de fonds. Ce sont les dates dont on discute ensuite. Un horodatage quotidien n'apporte rien de plus qu'un horodatage aux jalons réels.

Conservez l'archive exacte. L'attestation prouve qu'un contenu existait à une date. Elle ne conserve pas ce contenu à votre place. Une archive recompressée différemment ne produira pas la même empreinte, et la démonstration échouera. Gardez le fichier tel quel, bit pour bit.

Ce que cela permet, et ce que cela ne permet pas

Une preuve d'antériorité sur du code établit qu'un contenu déterminé existait avant une date. C'est considérable dans une discussion sur la paternité ou sur le périmètre d'une livraison.

Elle ne règle pas la question de la titularité des droits, qui dépend des contrats, du statut de l'auteur et, pour un salarié, de l'article L113-9 du code de la propriété intellectuelle. Un code horodaté par un prestataire reste un code dont les droits ont pu être cédés par contrat.

La preuve d'antériorité et le contrat répondent à deux questions différentes. La première dit ce qui existait et quand. Le second dit à qui cela appartient. Les deux sont nécessaires, et l'absence de la première est ce qui manque le plus souvent quand le conflit arrive.