Protection du code source d’une startup : droit d’auteur et bonnes pratiques

Protection du code source d’une startup : droit d’auteur et bonnes pratiques

Le code source concentre votre avantage concurrentiel, votre capacité d’exécution et, souvent, une part majeure de votre valorisation. Le sécuriser juridiquement et opérationnellement n’est pas optionnel : c’est un chantier fondateur à mener dès les premières lignes de code.

1) Le cadre légal : pourquoi le code est protégé automatiquement

En droit français et européen, le logiciel – y compris son code source, son code objet, ses interfaces et documents préparatoires – est protégé par le droit d’auteur, dès sa création et sous réserve d’originalité. Cette protection découle du Code de la propriété intellectuelle (notamment art. L112-2 et s.) consultable sur Legifrance, et de la directive européenne dédiée à la protection des programmes d’ordinateur (EUR‑Lex, 2009/24/CE).

Droits patrimoniaux exclusifs et exceptions

L’auteur détient des droits patrimoniaux exclusifs (reproduction, traduction/adaptation/modification, mise sur le marché). Les exceptions au bénéfice de l’acquéreur légitime (copie de sauvegarde, observation, interopérabilité sous conditions) sont prévues par l’art. L122‑6‑1 du CPI (Legifrance, L122‑6‑1).

Droit moral : un régime particulier pour le logiciel

Le droit moral de l’auteur existe mais connaît des aménagements spécifiques pour les logiciels (notamment au regard des nécessités d’évolution et de maintenance). Références sur Legifrance.

2) Qui est titulaire des droits sur le code ?

Salariés

Pour les logiciels créés par un salarié dans l’exercice de ses fonctions ou d’après les instructions de l’employeur, les droits patrimoniaux sont automatiquement dévolus à l’employeur (CPI, art. L113‑9, consultable via Legifrance). Prévoyez néanmoins des clauses internes de clarification (confidentialité, remise de code, documentation, outils).

Prestataires, freelances et agences

Par défaut, le développeur indépendant reste titulaire des droits. Une cession écrite et expresse est indispensable, précisant l’étendue, le territoire, la durée et la rémunération. À défaut, vous vous exposez à une revendication sur le code, voire un blocage de mise sur le marché. Voir l’alerte sur les risques d’absence de protection et de gouvernance technique publiée par la DGSI.

3) Bonnes pratiques juridiques et opérationnelles

3.1 Sécuriser la chaîne de titres (contrats et process)

• Inclure dans tous les contrats prestataires des cessions de droits conformes (périmètre, modules, livrables, API, tests, documentation, durée, territoires, versions futures, maintenance, rémunération).
• Pour les salariés : clauses de confidentialité, de remise et traçabilité des contributions (dépôts Git, tickets), de non-intégration de code tiers non autorisé.
• Mettre en place un Contributor License Agreement (CLA) pour les contributions externes.
• Encadrer l’accès au code (principes du moindre privilège, révocation systématique en offboarding).
• Prévoir des engagements sur la non-utilisation d’IA générative sans validation de licence et d’opt-out d’entraînement, avec revue humaine obligatoire.

Besoin d’un cadre prêt à l’emploi ? Découvrez nos offres juridiques adaptées aux startups tech.

3.2 Preuves et dépôts probatoires

• Enveloppe Soleau numérique auprès de l’INPI – cas particulier : logiciels : date certaine et description des éléments protégés.
• Dépôt auprès d’un tiers de confiance (ex. organisme spécialisé) et constat de commissaire de justice pour figer l’état du code et de l’environnement de build ; informations utiles sur Justice.fr.
• Conserver l’historique Git, les revues de code, tickets, roadmaps, échanges techniques : ces éléments participent à la preuve d’originalité et d’antériorité (Service Public Pro).

3.3 Gouvernance open source (compliance by design)

• Établir une SBOM (Software Bill of Materials) et un registre des licences (MIT, Apache‑2.0, GPL, AGPL, LGPL, etc.).
• Mettre en place des politiques d’approbation des dépendances et un outillage d’audit (SCA) continu.
• Documenter les obligations de redistribution (copyleft, notices, fourniture de code source, mentions d’attribution).
• Choisir consciemment votre modèle de licence de diffusion (propriétaire, dual licensing, modules OSS) avec un contrôle des exportations si nécessaire.

Pour aller plus loin sur PI et data, vous pouvez aussi lire nos articles sur RGPD et propriété intellectuelle.

4) Sécurité et RGPD : ce que votre code doit intégrer

Le code est un vecteur de conformité : principe de privacy by design, minimisation, journalisation proportionnée, chiffrement ; se référer aux lignes directrices du Comité européen de la protection des données (EDPB) et aux recommandations de la CNIL (sécurité des données, tests, anonymisation/pseudonymisation). Un défaut de gouvernance technique (secrets en dur, dépendances vulnérables, logs excessifs de données personnelles) peut engager votre responsabilité, nuire à la preuve d’antériorité et accélérer la fuite d’actifs stratégiques.

5) Check-list opérationnelle 30‑60‑90 jours

J+30 : socle indispensable

• Cartographier le code, les dépôts, les accès et les contributeurs.
• Vérifier tous les contrats prestataires ; lancer les avenants de cession manquants.
• Activer une politique d’approbation open source et générer une première SBOM.
• Initier un dépôt probatoire (INPI Soleau) et figer un tag Git signé.

J+60 : montée en maturité

• Mettre en production un process d’on/offboarding incluant la révocation d’accès au code.
• Signer des NDA avec tous les accès (internes/externes).
• Déployer l’outillage SCA/SAST et une politique de revue de code obligatoire.
• Formaliser les règles IA générative et la traçabilité des sorties.

J+90 : industrialisation

• Mettre en place un CLA pour contributions externes et des templates de licences pour SDK/API.
• Effectuer un audit de conformité licences et corriger les écarts (attributions, obligations copyleft).
• Planifier des dépôts probatoires récurrents à chaque release majeure.
• Réaliser un exercice de crise (revendication de droits ou fuite de code) et un plan de réponse.

6) Anticiper les litiges et faire valoir vos droits

• Mise en demeure avec démonstration d’antériorité et de titularité ; annexer extraits de code, hashes, preuves de dépôt.
• Constat de commissaire de justice (preuve technique, empreintes) et préservation des preuves numériques (Justice.fr).
• Action en contrefaçon et demandes de mesures provisoires si urgence (référé) ; s’appuyer sur les textes CPI disponibles via Legifrance.

Vous avez un doute sur la solidité de votre chaîne de titres, ou une urgence contentieuse ? Consultez notre FAQ juridique et conformité et découvrez nos offres juridiques pour sécuriser vos actifs logiciels.

FAQ synthétique

Le code est-il protégé sans dépôt ?

Oui. La protection par droit d’auteur naît automatiquement si le code est original (CPI via Legifrance). Un dépôt probatoire (INPI, constat) renforce votre preuve.

Qui possède le code développé par un salarié ?

Pour les logiciels créés dans l’exercice des fonctions, les droits patrimoniaux appartiennent à l’employeur (art. L113‑9, CPI ; voir Legifrance).

Que risque-t-on sans cession écrite avec un freelance ?

Le prestataire peut revendiquer la propriété et bloquer l’exploitation. Voir l’alerte de la DGSI.

Pouvons-nous utiliser des dépendances GPL ?

Oui, mais selon la GPL choisie (GPL/AGPL/LGPL), des obligations de mise à disposition du code source peuvent s’appliquer. Auditez et documentez vos choix (voir INPI).

Pour aller plus loin

Consultez nos guides connexes : Proteger sa marque : depot INPI et strategie, Propriete intellectuelle et contenus generes par IA et RGPD et IA : obligations legales.