Protéger code source, maquettes et prototypes
Une preuve d'antériorité datée pour votre travail — code source, design systems, maquettes Figma, prototypes — pour 2 €, sans inscription, vérifiable par n'importe qui.
Situation type
Vous êtes développeur freelance. Vous remettez à un client le prototype d'une plateforme métier — backend, frontend, schéma de base de données, documentation d'architecture. Le contrat de poursuite ne se conclut pas. Quelques mois plus tard, vous reconnaissez votre architecture dans la solution lancée par l'entreprise, développée en interne ou par un prestataire moins cher. Votre travail a servi de base sans accord.
Ou : vous êtes designer UX/UI. Vous proposez à une startup un design system complet — composants, tokens, principes d'interaction, prototypage Figma. La startup ne donne pas suite. Six mois après, son produit reprend votre arborescence d'interface, vos micro-interactions caractéristiques, votre logique de navigation.
Ou — situation devenue centrale en 2026 — vous êtes développeur, vous publiez du code open source sur GitHub depuis des années sous licence MIT, Apache 2.0 ou GPL. Un assistant IA reproduit des extraits de votre code dans les complétions qu'il propose à d'autres développeurs, parfois sans préserver les mentions de licence ni l'attribution. La class action Doe v. GitHub (Northern District of California, depuis novembre 2022) porte précisément sur ce type de griefs.
Le préalable juridique commun à ces trois situations : pouvoir démontrer à quelle date votre travail existait sous cette forme, et que c'est bien vous qui l'avez créé.
Le cadre juridique : un régime particulier
Le droit français traite le code source différemment des autres œuvres : c'est l'une des rares œuvres pour lesquelles le législateur a prévu un régime spécifique au sein du Code de la propriété intellectuelle.
Pour le code source
L'article L.112-2, 13° du CPI inclut explicitement « les logiciels, y compris le matériel de conception préparatoire » parmi les œuvres protégées. La décision fondatrice est l'arrêt Pachot (Cass. Ass. plén., 7 mars 1986, n° 83-10.477) qui a reconnu la protection du logiciel par le droit d'auteur en France.
L'originalité du logiciel doit être démontrée. La Cour de cassation a précisé qu'elle suppose « un effort personnalisé allant au-delà de la simple mise en œuvre d'une logique automatique et contraignante » matérialisé dans « une structure individualisée portant la marque de son apport intellectuel » (Cass. 1ère civ., 17 octobre 2012, n° 11-21.641).
L'article L.122-6 CPI définit les droits patrimoniaux exclusifs de l'auteur d'un logiciel : reproduction, modification (y compris traduction, adaptation), et mise sur le marché. Toute reproduction non autorisée constitue une contrefaçon.
Pour les interfaces graphiques (UI)
Point juridique important souvent ignoré : les interfaces utilisateur graphiques ne sont pas couvertes par le droit d'auteur spécial des logiciels. La Cour de justice de l'Union européenne l'a tranché dans l'arrêt BSA (CJUE, 22 décembre 2010, aff. C-393/09) : l'interface graphique n'est pas une forme d'expression du programme, mais un élément qui permet aux utilisateurs d'exploiter les fonctionnalités du programme.
En revanche — et c'est ce qui compte pour les designers UX/UI — la même décision précise qu'une interface graphique peut bénéficier de la protection par le droit d'auteur commun au titre de la directive 2001/29, « si elle constitue une création intellectuelle propre à son auteur ». Autrement dit : l'originalité de l'agencement, du look and feel, des micro-interactions est protégeable, mais elle relève d'un régime juridique distinct de celui qui couvre le code lui-même.
Conséquence pratique : pour un produit numérique, deux objets juridiques distincts coexistent — le code (régime spécial logiciel) et l'interface (régime général droit d'auteur). Tous deux sont protégeables, mais pas selon les mêmes règles, et pas avec les mêmes preuves.
Pour les deux
Le cas particulier de l'IA et du code
Pour les développeurs publiant sur GitHub ou tout dépôt public, un risque nouveau s'est superposé aux contentieux classiques.
La class action Doe v. GitHub (US District Court for the Northern District of California, juge Jon S. Tigar, déposée le 3 novembre 2022) oppose un groupe de développeurs anonymes à GitHub, Microsoft et OpenAI au sujet de l'entraînement de Copilot sur du code publié sous licences open source. Les griefs portent notamment sur la suppression des Copyright Management Information (CMI) — c'est-à-dire les mentions d'auteur, de licence, de copyright — lors de la reproduction du code en sortie.
L'état actuel de la procédure (mi-2026) :
- En juin 2024, le juge Tigar a rejeté la majeure partie des griefs DMCA § 1202(b), considérant que le code produit par Copilot n'était pas suffisamment identique au code original
- En septembre 2024, le tribunal a certifié un appel interlocutoire sur la question de savoir si DMCA § 1202(b) exige une identité parfaite ou couvre les œuvres dérivées
- En décembre 2024, la Ninth Circuit Court of Appeals a accepté l'appel (référence 24-6136), la procédure de première instance est suspendue dans l'attente de la décision
- Les griefs maintenus en première instance portent sur la violation des licences open source et la rupture de contrat — point clé : le juge reconnaît que les licences open source sont des accords contractuels opposables
Du côté européen, le règlement (UE) 2024/1689 (AI Act), entré en vigueur le 1er août 2024, impose depuis le 2 août 2025 aux fournisseurs de modèles d'IA généralistes (GPAI) deux obligations qui concernent directement les développeurs publiant du code :
- Article 53(1)(c) : mettre en place une politique de respect du droit d'auteur, incluant l'identification et le respect des opt-outs exprimés au titre de l'article 4(3) de la directive (UE) 2019/790 (text and data mining)
- Article 53(1)(d) : publier un résumé suffisamment détaillé du contenu utilisé pour entraîner le modèle, selon le template officiel publié par l'AI Office le 24 juillet 2025
Aucune issue n'est encore garantie dans ces procédures — mais le simple fait que les tribunaux acceptent d'examiner sérieusement ces griefs change déjà la position de négociation des développeurs. Le préalable à toute action reste le même : prouver à quelle date votre code existait sous cette forme.
Ce qu'on peut ancrer
Pour les développeurs
- Code source complet, à un moment donné (export figé)
- Repos Git entiers — utiliser git archive HEAD --format=zip -o snapshot.zip pour produire un snapshot daté de la branche courante
- Digests gitingest — pour les repos publics, un fichier unique qui agrège l'arborescence et le contenu des fichiers, déterministe, idéal à hasher
- Documentation d'architecture (PDF figés depuis Mermaid, draw.io, Excalidraw)
- Schémas de base de données (DDL, diagrammes)
- Spécifications techniques et API contracts (OpenAPI, GraphQL schemas)
- Tests (suites de tests automatisés, qui démontrent souvent autant d'effort créatif que le code lui-même)
- Notes d'architecture et ADR (Architecture Decision Records)
- Roadmaps techniques, plans de migration
- Communications client (emails exportés en PDF)
Note pour les repos privés : la solution la plus simple est de rendre temporairement le repo public, d'exécuter gitingest, d'ancrer le digest, puis de remettre le repo en privé. La visibilité d'un repo GitHub n'affecte ni le contenu des fichiers ni l'historique git. Pour les repos sensibles, l'option git archive localement reste préférable.
Pour les designers UX/UI
- Maquettes Figma, Sketch, Adobe XD (exports PDF figés — l'export sert de preuve, vous gardez le fichier source)
- Design systems complets (tokens, composants, principes)
- Prototypes interactifs (exports vidéo ou PDF des écrans clés)
- Wireframes et flux utilisateurs
- Recherche utilisateur (notes d'entretien, personas, journey maps)
- Moodboards et exploration visuelle
- Spécifications d'interaction (micro-interactions, animations, états)
- Charte d'accessibilité et règles WCAG
- Documentation de design (rationale, alternatives explorées, choix justifiés)
- Briefs et notes de cadrage écrits
Pourquoi le bundle change tout
Côté développement : un projet logiciel n'est pas un fichier — c'est un système. Le code seul ne raconte pas l'histoire de la décision technique : pourquoi cette architecture plutôt qu'une autre, pourquoi cette base de données, pourquoi ce framework. Un bundle qui contient le code, la documentation d'architecture, les ADR, les schémas, les tests, démontre une conception et pas seulement un produit fini. C'est exactement la matière que demande un juge pour caractériser « l'effort personnalisé » et la « structure individualisée » exigés par la jurisprudence Pachot et ses suites.
Côté design : un design system n'est pas un Figma — c'est une logique. Les composants seuls ne suffisent pas à démontrer l'originalité de l'agencement et du look and feel. Un bundle qui réunit les wireframes initiaux, la recherche utilisateur, les itérations rejetées, le design system final, les spécifications d'interaction, donne au juge la matière pour caractériser « la création intellectuelle propre à son auteur » exigée par l'arrêt BSA pour la protection d'une interface.
Pour 2 € — le prix d'un seul ancrage — vous pouvez réunir jusqu'à 50 Mo de fichiers dans un même bundle. Un projet logiciel complet en exports figés, ou un design system entier, tient largement dans cette enveloppe.
Cas concret
Un développeur freelance livre un prototype fonctionnel à un client — application web, API REST, base de données PostgreSQL, documentation complète, suite de tests. Le client juge le devis de la phase 2 (industrialisation) trop élevé et reprend le projet en interne. Trois mois plus tard, le produit en production reprend votre architecture, vos noms de tables, votre découpage modulaire — mais sans vous, et sans accord sur la reprise du travail réalisé.
Sans preuve datée, le développeur n'a que ses fichiers de travail locaux, ses emails de livraison, et son repo Git privé. La défense adverse pourra prétendre que l'architecture en question est « une mise en œuvre standard de patterns connus », c'est-à-dire dénuée de l'originalité requise par la jurisprudence Pachot.
Avec un bundle ETcH ancré au moment de la livraison du prototype — contenant le repo (git archive), les ADR, les schémas, la doc technique, les tests — le développeur répond à deux objections en une fois. La date est opposable et vérifiable indéfiniment sur Etherscan. Le faisceau de pièces démontre l'effort personnalisé et la structure individualisée, en allant bien au-delà du seul code produit.
À partir de là, plusieurs voies de recours existent — la plupart sans avocat et sans procès — pour faire cesser la reprise ou obtenir réparation : mise en demeure, signalement plateforme si le produit est distribué sur un store, action en concurrence déloyale ou en contrefaçon si nécessaire.
Pour l'angle français en propriété intellectuelle, le Tribunal judiciaire de Marseille a reconnu le 20 mars 2025 la valeur probante d'horodatages blockchain pour démontrer l'antériorité de créations originales (affaire AZ Factory contre Valeria Moda, RG 23/00046). La décision concernait des croquis de mode, mais le principe juridique est transposable à tout document numérique, y compris code source et maquettes d'interface.
Alternatives à connaître : APP et dépôts INPI
Le paysage français offre déjà des solutions pour les développeurs, qu'il est honnête de mentionner :
L'APP (Agence pour la Protection des Programmes) propose depuis 1982 le dépôt de logiciels avec attribution d'un numéro IDDN et conservation d'une logibox scellée. L'APP est une référence reconnue, ses procès-verbaux ont une force probante établie devant les tribunaux français, et elle dispose d'agents assermentés. C'est un dispositif robuste, particulièrement adapté aux éditeurs de logiciels qui ont des problématiques d'entiercement (séquestre) auprès de clients. L'adhésion à l'APP et les dépôts ont un coût, à évaluer selon votre volumétrie.
L'INPI permet le dépôt de marques (190 € + 40 €/classe supplémentaire en 2026) et de dessins et modèles. Pertinent pour le nom de votre logiciel et son logo, moins pour le code ou les maquettes en eux-mêmes.
Mode opératoire
Finalisez vos livrables dans la version que vous voulez protéger. Pour le code, utilisez git archive ou gitingest. Pour les maquettes, exportez en PDF figé — les fichiers natifs modifient leurs métadonnées à l'ouverture, ce qui invalide la preuve.
Rassemblez les fichiers du projet que vous jugez utiles à la preuve : code, documentation d'architecture, ADR, schémas, tests, maquettes, wireframes, correspondances pertinentes.
Déposez-les sur etchproof.eu Le calcul des empreintes se fait dans votre navigateur — aucun fichier ne quitte votre machine.
Conservez le ZIP de preuve délivré après ancrage. Il contient le certificat PDF, le manifeste, la transaction Ethereum et vos fichiers originaux. C'est lui qui sert en cas de litige — gardez-en au moins deux copies, dans deux emplacements différents.
Limites honnêtes
L'horodatage ETcH prouve l'antériorité, pas la qualité d'auteur. Pour étayer la qualité d'auteur en cas de contentieux, il faut souvent ajouter d'autres éléments : témoignages, correspondances, preuves de conception itérative — d'où l'intérêt du bundle.
L'horodatage ne remplace pas un éventuel constat de commissaire de justice si le litige va jusqu'au tribunal. Mais ce constat peut intervenir des mois ou des années après l'ancrage : dans l'affaire AZ Factory, le constat est survenu plus de quatorze mois après les ancrages initiaux. Vous payez 2 € maintenant — et seulement le coût du constat (généralement entre 150 et 500 €) si un litige se présente.