Protéger

Protéger son code et ses applications

Le code se copie encore plus vite qu'il ne s'écrit : un dépôt cloné, une archive qui circule, un prestataire ou un « associé » qui repart avec l'essentiel. Quand le conflit éclate, tout se résume à une question que l'historique Git ne tranche pas seul : qui détenait ce code, à quelle date ?

Le risque réel

Les litiges logiciels naissent rarement d'un vol spectaculaire : un freelance dont le client réutilise le code au-delà du contrat, un prototype montré à un partenaire qui « développe la même chose », un cofondateur qui part avec la base de code, une agence dont le prestataire recycle les modules chez un concurrent.

Git horodate, certes — mais un historique se réécrit (rebase, squash, dates de commit arbitraires) et un dépôt privé reste sous VOTRE contrôle : en litige, c'est une preuve que la partie adverse contestera comme auto-produite. Les plateformes d'hébergement ferment des comptes, les organisations changent de mains.

Ce qui manque, c'est un tiers infalsifiable : une empreinte de votre arbre de code, ancrée hors de votre contrôle, à date certaine. Release après release, ces empreintes chaînées racontent le développement — une chronologie qu'aucun repreneur de code ne peut reconstituer à son profit.

Comment dater votre code en 30 secondes

1

Glissez le dossier du projet (ou l'archive de release) : chaque fichier source est haché dans votre navigateur. Votre code ne quitte jamais votre machine — aucun serveur tiers, pas même le nôtre.

2

Le manifeste chemin → empreinte scelle l'arbre complet ; son empreinte est ancrée au registre public, doublée d'un jeton RFC 3161.

3

Recevez le certificat listant chaque fichier. À chaque release : un dépôt rattaché au précédent. Votre CI peut même le faire pour vous, via l'API.

Protéger ma création — 2 dépôts gratuits

Sans carte bancaire, sans engagement. Votre fichier ne quitte jamais votre appareil.

Le développeur

L’« associé » qui a lancé l’application tout seul

Malik, développeur, mûrit depuis deux ans une idée d'application : le concept, les écrans, le modèle économique, tout est formalisé dans un document de trente pages. Pour passer à la vitesse supérieure, il cherche un associé business. Un contact chaleureux se présente, multiplie les rendez-vous, demande « le dossier complet pour avancer ».

Puis plus rien. Les messages restent lus, sans réponse. Huit mois plus tard, Malik découvre sur les stores une application au positionnement identique, aux écrans troublants de ressemblance — portée par son ancien « associé », qui lève au passage plusieurs centaines de milliers d'euros.

Malik a tout : le document, les maquettes, les mois de travail. Mais rien qui date de façon incontestable la formalisation de son concept avant leurs échanges. Pas d'accord de confidentialité signé, pas de dépôt, pas de trace opposable. Son avocat est direct : « En l'état, vous n'avez pas de dossier. »

Avec un dépôt daté de quelques euros de son document de conception, effectué avant le premier rendez-vous, Malik aurait pu établir qu'il avait formalisé ce concept le premier. Le rapport de force aurait été inversé.

Récit illustratif inspiré de situations réelles fréquentes — prénoms et détails fictifs.

Ce que dit le droit

Le code source original est protégé par le droit d'auteur dès son écriture, en France (avec des règles propres au logiciel) comme dans les 180+ pays de la Convention de Berne. Ni idée d'application ni fonctionnalité ne sont protégeables en tant que telles — mais leur mise en œuvre dans le code, si.

Un dépôt horodaté n'est pas un brevet et ne confère aucun monopole : il établit un fait, librement apprécié par le juge — cet arbre de code exact existait chez vous à cette date. Combiné à vos contrats (cession, NDA, licence), il verrouille la question d'antériorité qui empoisonne la plupart des différends logiciels.

Questions fréquentes des développeurs

Je dépose le dossier source ou l’archive de release ?
Les deux approches marchent. Le dossier source via manifeste date chaque fichier individuellement — idéal pour prouver l'antériorité d'un module précis. L'archive (tar/zip) donne une empreinte unique — pensez alors à conserver l'archive exacte déposée.
node_modules, builds, secrets : je fais quoi ?
Excluez-les : déposez ce que VOUS avez écrit (sources, configs, docs). Les dépendances tierces ne vous appartiennent pas, les artefacts de build se régénèrent, et un dépôt n'est pas un coffre à secrets — même si seules les empreintes nous parviennent.
Peut-on automatiser le dépôt à chaque release ?
Oui : une requête REST par release depuis votre CI (hachage local, seule l'empreinte part). La documentation publique de l'API contient les exemples curl et JavaScript — comptez une matinée d'intégration, en étant large.
Voir aussi :Protéger le contenu de son site internetProtéger une idée ou un concept avant de le pitcherProtéger un logo

Votre prochaine création mérite une date certaine

Protéger ma création maintenant

Vos fichiers ne quittent jamais votre appareil · Preuve valable même si nous disparaissons · Sans engagement