Vous dirigez une startup tech. Votre logiciel a été développé sur trois ans par un mélange d'équipes : deux co-fondateurs présidents et CTO, quatre développeurs salariés, deux freelances longue durée, un stagiaire de fin d'études, et plus récemment vos équipes utilisent GitHub Copilot et Claude Code pour accélérer leur production. Une levée de fonds approche. L'investisseur vous demande la chaîne de titularité complète du code. Vous découvrez à ce moment-là que la question n'a jamais été clarifiée. Elle l'est maintenant, et elle peut décoter votre valorisation, voire bloquer le closing. La règle juridique française fait du code une œuvre dont la titularité dépend du statut exact de chaque contributeur, avec des nuances que les fondateurs sous-estiment systématiquement. Cet article expose les cinq cas de figure et les pièges qui peuvent transformer un actif en passif.
Le principe : le code appartient à son créateur, pas à celui qui paie
L'article L. 111-1 du code de la propriété intellectuelle (CPI) pose le principe directeur du droit d'auteur français : l'auteur d'une œuvre de l'esprit jouit, du seul fait de sa création, d'un droit de propriété incorporelle exclusif et opposable à tous. L'article L. 112-2 13° du CPI inclut expressément les logiciels parmi les œuvres de l'esprit protégées, à condition qu'ils soient originaux au sens de la jurisprudence (apport intellectuel propre, effort personnalisé allant au-delà de la simple mise en œuvre d'une logique automatique).
Cette règle a une conséquence directe et souvent ignorée par les dirigeants : le seul fait de payer un développeur pour produire du code n'emporte pas transfert de propriété sur ce code. L'article L. 111-1 alinéa 3 du CPI le précise : l'existence d'un contrat de louage d'ouvrage ou de service ne déroge pas, par lui-même, au droit de propriété de l'auteur. Autrement dit, vous pouvez avoir signé un contrat de prestation, payé toutes les factures, et ne pas être titulaire du code livré.
Cette règle générale connaît une exception unique en droit français : la dévolution automatique des droits patrimoniaux sur les logiciels créés par les salariés à leur employeur, prévue à l'article L. 113-9 du CPI. C'est la seule hypothèse dans laquelle le contrat de travail vaut cession sans formalité supplémentaire. Toutes les autres relations de travail (freelance, prestation, stage hors recherche, mandat social) imposent une cession écrite explicite respectant le formalisme strict de l'article L. 131-3 du CPI.
Le droit moral, quant à lui, reste attaché à la personne du créateur même en cas de dévolution. Pour les logiciels, ce droit moral est cependant restreint par la loi : le créateur ne peut pas s'opposer aux modifications apportées par le titulaire des droits patrimoniaux, sauf si ces modifications portent atteinte à son honneur ou à sa réputation. En pratique, ce droit moral résiduel est rarement invoqué dans le contexte commercial.
La conséquence stratégique de ces règles est directe : la titularité du code de votre startup se construit contributeur par contributeur, statut par statut, sans automatisme général. Une cartographie précise s'impose dès la phase d'audit pré-financement, et plus largement tout au long de la vie de l'entreprise.
Les salariés : dévolution automatique à l'employeur sous trois conditions
L'article L. 113-9 du CPI énonce le principe : sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur, qui est seul habilité à les exercer. Cette dévolution est automatique et ne suppose aucun acte de cession formel.
L'application de cette règle est subordonnée à plusieurs conditions cumulatives.
Première condition : la qualité de salarié au sens du droit du travail. Cette notion implique un lien de subordination juridique, des directives, un contrôle, une intégration dans l'organisation. Un freelance, même travaillant exclusivement pour l'entreprise sur de longues périodes, n'est pas un salarié au sens de L. 113-9 (sauf requalification du contrat par le juge prud'homal ou social, hypothèse dans laquelle d'autres conséquences s'appliquent).
Deuxième condition : la création du logiciel dans l'exercice des fonctions ou d'après les instructions de l'employeur. La jurisprudence apprécie cette condition de façon assez large. Le fait que le code ait été développé partiellement à domicile, en dehors des heures de bureau, ou avec du matériel personnel, n'écarte pas la dévolution dès lors que le développement s'inscrit dans la mission du salarié et bénéficie à l'employeur. À l'inverse, un logiciel développé par un salarié en dehors de toute mission professionnelle, sans rapport avec son activité salariée et sans utilisation de moyens de l'entreprise, reste sa propriété personnelle.
Troisième condition : l'absence de stipulations contraires. Le contrat de travail peut déroger au régime légal en faveur du salarié (par exemple, en lui réservant la propriété du code en contrepartie d'une rémunération particulière), mais cette dérogation est rare en pratique. Les contrats de travail des entreprises tech rappellent généralement la dévolution prévue par L. 113-9 sans la modifier.
Le salarié conserve son droit moral, mais celui-ci est limité par les articles L. 121-7 et L. 121-7-1 du CPI. Il peut exiger la mention de son nom, mais ne peut pas s'opposer aux modifications, à la mise sur le marché ou à l'évolution du logiciel par l'employeur.
L'enjeu pratique est de documenter précisément les missions des développeurs salariés, le périmètre de leurs fonctions et les outils mis à disposition. Cette documentation simplifie la défense en cas de contestation ultérieure, notamment lors d'une due diligence en levée de fonds sur la chaîne de titularité du code.
Enfin, l'article L. 113-9 alinéa 3 étend la dévolution automatique aux agents de l'État, des collectivités publiques et des établissements publics à caractère administratif, ce qui aligne le régime du secteur public sur celui du secteur privé pour les logiciels.
Les freelances et ESN : aucune dévolution automatique, cession écrite obligatoire
Pour les freelances, indépendants, auto-entrepreneurs et entreprises de services du numérique (ESN), la règle est diamétralement opposée. La dévolution automatique de l'article L. 113-9 ne s'applique pas. Le prestataire reste titulaire des droits sur le code livré, sauf cession écrite expresse respectant le formalisme légal.
L'article L. 131-3 du CPI fixe ce formalisme. La transmission des droits de l'auteur est subordonnée à deux exigences cumulatives : chaque droit cédé doit faire l'objet d'une mention distincte dans l'acte de cession ; le domaine d'exploitation doit être délimité quant à son étendue, sa destination, son lieu et sa durée.
En pratique, une clause se limitant à énoncer que "le prestataire cède l'ensemble de ses droits sur le code livré" ne respecte pas ce formalisme. Elle est susceptible d'être requalifiée en simple licence d'usage, ce qui prive l'entreprise de la possibilité de modifier le code, de le céder à un tiers ou de l'apporter à une opération de M&A. Une cession opposable énumère chaque droit (reproduction, traduction, adaptation, distribution, mise sur le marché, location), précise la finalité (exploitation commerciale interne, distribution sous licence, intégration dans une plateforme), le territoire (France, Union européenne, monde) et la durée (pour la durée légale de protection).
L'absence de cession écrite ne signifie pas que le client ne peut rien faire du code. La jurisprudence reconnaît une licence implicite tacite : le client qui a commandé et payé un développement peut utiliser le code conformément à la finalité prévue par le contrat. Mais cette licence implicite est limitée. Elle ne couvre ni la modification, ni la cession à un tiers, ni l'exploitation au-delà du périmètre initial. Le freelance peut s'opposer à toute exploitation sortant de ce périmètre et exiger une rémunération complémentaire.
Plusieurs configurations à risque méritent attention. Première configuration : le freelance qui a quitté l'entreprise sans signer de cession formelle. Le code reste juridiquement le sien, et toute modification ultérieure par l'entreprise peut être contestée. Régularisation possible mais coûteuse, parfois bloquante en cas de mauvaise volonté de l'ancien prestataire. Deuxième configuration : l'ESN ou le freelance qui a réutilisé des briques de code génériques d'autres clients dans le code livré. Sans clarification contractuelle, la chaîne de titularité est compromise. Troisième configuration : le développement collaboratif entre salariés et freelances, qui peut faire naître une qualification d'œuvre de collaboration ou d'œuvre collective avec des règles de titularité partagée.
L'audit de la chaîne de droits sur les freelances est l'un des points les plus systématiquement creusés en due diligence. La régularisation tardive est possible mais expose à des renégociations défavorables et, dans certains cas, à des contentieux. La sécurisation préventive (clause de cession conforme à L. 131-3 dans chaque contrat de prestation) est un investissement structurant. Cette discipline contractuelle relève de la même logique que la sécurisation des contrats commerciaux et partenariats stratégiques.
Les mandataires sociaux : le piège classique des fondateurs
C'est le piège qui revient le plus fréquemment dans les startups tech, et celui qui surprend le plus les fondateurs : le mandataire social, qu'il soit président de SAS, directeur général, gérant de SARL, n'est pas un salarié au sens de l'article L. 113-9 du CPI. Si ce mandataire développe lui-même du code pour la société, ce code reste sa propriété personnelle, sauf cession formelle ou apport en nature.
La raison est juridique et stricte. L'article L. 113-9 vise expressément les "employés", c'est-à-dire les personnes liées par un contrat de travail caractérisé par une subordination juridique. Or le mandataire social, par définition, exerce un mandat social et non un contrat de travail. Il dirige, il représente, il engage la société. Il n'est pas subordonné au sens du droit du travail. Le cumul possible d'un mandat social et d'un contrat de travail (président-salarié) suppose des conditions strictes (fonctions techniques distinctes, lien de subordination réel, rémunération distincte) que la plupart des fondateurs n'organisent pas.
Conséquence directe : un fondateur président-CTO de SAS qui code lui-même la première version du logiciel, sans contrat de travail formalisé et sans acte de cession, conserve la titularité de ce code. La société exploite alors un actif qu'elle ne détient pas. Cette situation est massivement répandue dans les startups au stade amorçage, où les fondateurs codent eux-mêmes le MVP avant les premiers recrutements.
Plusieurs voies de régularisation existent. La première est la cession formelle des droits patrimoniaux à la société par acte écrit respectant L. 131-3 du CPI. Cette cession suppose une contrepartie (prix, augmentation de capital, attribution de titres) et doit respecter les règles de conventions réglementées de l'article L. 227-10 du code de commerce pour les SAS ou L. 225-38 pour les SA. Une cession non régulièrement autorisée n'est pas nulle mais expose le dirigeant à une responsabilité envers la société, ce qui constitue un risque majeur en levée de fonds.
La deuxième voie est l'apport en nature du logiciel à la société, généralement réalisé au moment de la création ou d'une augmentation de capital. L'apport suppose une évaluation par un commissaire aux apports dans les conditions des articles L. 225-8 et suivants du code de commerce, sauf dispense applicable selon la valeur. L'apport est rémunéré par des titres de la société, ce qui aligne les intérêts du fondateur et de la structure.
La troisième voie, moins courante, est la concession d'une licence d'exploitation à la société par le fondateur. Cette voie laisse la propriété au fondateur mais permet l'exploitation. Elle est généralement défavorable en cas de levée de fonds, car les investisseurs préfèrent que la société détienne ses actifs structurants plutôt que de dépendre d'une licence concédée par un fondateur, susceptible d'être remise en cause en cas de conflit.
Cette question des actifs détenus par les fondateurs avant constitution de la société recoupe les enjeux plus larges de structuration juridique d'une startup à la création. La régularisation au moment de la constitution évite des coûts et des complexités bien supérieurs lors d'une levée de fonds ou d'une cession.
Les stagiaires et chercheurs : la règle particulière de L. 113-9-1 depuis 2021
L'article L. 113-9-1 du CPI, introduit par l'ordonnance n° 2021-1518 du 24 novembre 2021 et entré en vigueur le 17 décembre 2021, étend la dévolution automatique des droits patrimoniaux sur les logiciels à certaines personnes non salariées. Cette extension est souvent mal comprise et exagérément généralisée par les contenus en ligne.
Le texte vise précisément les personnes qui, sans relever de l'article L. 113-9 (donc sans être salariées), sont accueillies dans le cadre d'une convention par une personne morale de droit privé ou de droit public réalisant de la recherche, et qui créent des logiciels dans l'exercice de leurs missions ou d'après les instructions de la structure d'accueil. La dévolution n'opère que si deux conditions complémentaires sont réunies : la personne perçoit une contrepartie, et elle est placée sous l'autorité d'un responsable de la structure.
La portée pratique de cette règle est plus restreinte qu'il n'y paraît. Le texte ne s'applique qu'aux structures "réalisant de la recherche". Une startup classique éditrice de SaaS qui accueille un stagiaire pour développer une fonctionnalité métier sans dimension de recherche scientifique formalisée n'entre pas nécessairement dans le champ de L. 113-9-1. La frontière entre une activité de développement logiciel ordinaire et une activité de recherche au sens du texte est délicate, et la jurisprudence n'a pas encore stabilisé les critères.
Plusieurs cas sont concernés sans ambiguïté. Les doctorants en thèse CIFRE, les post-doctorants accueillis dans une équipe R&D structurée, les stagiaires dans des structures bénéficiant déjà du Crédit d'impôt recherche pour des activités qualifiées. Pour ces personnes, la dévolution automatique des droits patrimoniaux opère sans contrat de cession.
À l'inverse, plusieurs cas restent dans le régime général de droit commun, ce qui impose une cession écrite formelle si l'entreprise veut acquérir les droits. Les stagiaires de master ou d'école d'ingénieur en startup non-recherche relèvent du droit commun. Les apprentis (qui sont des salariés) sont sous L. 113-9 et donc déjà couverts. Les bénévoles, contributeurs occasionnels, intervenants en hackathon ou stagiaires non rémunérés sont hors de toute dévolution automatique : ils conservent leurs droits sauf cession explicite.
L'erreur fréquente consiste à supposer qu'un stagiaire est automatiquement couvert depuis 2021 alors que la condition de "structure réalisant de la recherche" n'est pas remplie. Cette erreur peut générer des trous dans la chaîne de titularité que la due diligence détecte facilement.
Recommandation pratique : en cas de doute sur l'applicabilité de L. 113-9-1, faire signer une cession écrite explicite à chaque stagiaire. Le coût d'une clause-type est négligeable, et la sécurité juridique apportée vaut largement la formalité.
L'IA générative dans le développement : code Copilot, Claude Code, Cursor : qui détient quoi ?
L'intégration des outils d'IA générative dans les workflows de développement (GitHub Copilot, Claude Code, Cursor, Tabnine, Amazon CodeWhisperer) a transformé la production de code. Elle pose des questions juridiques que ni la loi ni la jurisprudence n'ont encore stabilisées. Trois points méritent attention.
Premier point : la titularité du code généré. Le droit français exige une création humaine pour qu'une œuvre soit protégée par le droit d'auteur. La doctrine et les premières décisions étrangères convergent : un code purement généré par une IA, sans intervention créative humaine, n'est pas protégeable par le droit d'auteur. Il tombe dans le domaine public. À l'inverse, un développeur qui utilise une IA comme assistant (formule des prompts précis, accepte ou rejette les suggestions, les modifie, les intègre dans une architecture qu'il a conçue) exerce une activité créative qui peut emporter protection. La protection porte alors sur l'apport intellectuel humain, pas sur la production brute de l'outil. Plus l'autonomie de l'IA est importante (génération de fonctions complètes sans supervision), plus la protection est fragile. Plus l'apport humain est documenté (revue, correction, choix architecturaux), plus la protection est solide.
Deuxième point : le risque de contrefaçon par reproduction de code source d'entraînement. Les modèles d'IA générative sont entraînés sur des corpus de code sources, dont une partie est protégée par le droit d'auteur ou soumise à des licences open source contraignantes. Une IA peut, dans certaines configurations, reproduire des fragments de code identiques ou substantiellement similaires à du code d'entraînement. L'entreprise qui intègre ce code dans son propre logiciel devient potentiellement contrefactrice, sans le savoir. Le contentieux engagé contre GitHub Copilot devant les juridictions américaines en 2022 a fait apparaître ce risque, sans encore le trancher de manière définitive. Pour limiter le risque, les outils proposent désormais des options de filtrage des suggestions reproduisant du code public, options à activer systématiquement et dont l'usage doit être documenté.
Troisième point : la traçabilité et la documentation. La preuve de la titularité du code utilisant de l'IA repose sur une documentation continue : conservation des prompts, journalisation des suggestions acceptées et rejetées, revue par le développeur, intégration dans une architecture conçue par l'humain. Cette traçabilité s'inscrit dans la même logique que la documentation requise pour prouver l'originalité d'un logiciel en vue d'une éligibilité IP Box. Plus largement, elle conditionne la défense en cas de contestation de titularité ou de contrefaçon.
Les contrats de travail et les contrats de prestation doivent désormais intégrer des clauses spécifiques sur l'usage des outils d'IA générative : type d'outils autorisés, paramétrage obligatoire (filtrage des suggestions risquées), obligation de revue humaine, traçabilité des prompts, déclaration explicite par le contributeur de la part respective de production humaine et assistée. Sans ces clauses, l'entreprise s'expose à une zone d'incertitude juridique croissante.
La matière est en construction. Les positions jurisprudentielles vont se stabiliser au cours des deux à trois prochaines années, sous la pression conjuguée du règlement européen sur l'IA (AI Act) et des contentieux engagés sur les modèles génératifs. Les entreprises qui structurent dès maintenant leur usage des outils d'IA dans une logique de traçabilité construiront un avantage défensif durable.
FAQ : Titularité des droits sur le code
Mon développeur freelance a quitté l'entreprise sans signer de cession : que faire ?
Le code livré reste juridiquement la propriété du freelance, sauf clause de cession dans un autre document (contrat-cadre, devis signé, conditions générales). La régularisation passe par une cession rétroactive écrite, négociée avec l'ancien prestataire. La rémunération de cette cession peut être symbolique si la relation s'est bien terminée, ou nettement plus élevée en cas de tension. À défaut d'accord, l'entreprise peut continuer à utiliser le code dans les limites de la licence implicite tacite (usage prévu par le contrat initial), mais ne peut ni le modifier substantiellement, ni le céder.
Le code créé par mon co-fondateur président avant la création de la société m'appartient-il ?
Non, sauf cession formelle. Un mandataire social n'est pas un salarié au sens de l'article L. 113-9 du CPI. Le code créé par un fondateur, même destiné à la future société, reste sa propriété personnelle jusqu'à acte de cession respectant l'article L. 131-3 du CPI ou apport en nature au capital. Cette régularisation doit intervenir au moment de la création de la société ou immédiatement après, faute de quoi la chaîne de titularité présente un trou structurel.
Un stagiaire en entreprise non-recherche cède-t-il automatiquement ses droits ?
Non. L'article L. 113-9-1 du CPI ne couvre que les personnes accueillies dans une structure "réalisant de la recherche", et placées sous autorité avec contrepartie. Un stagiaire en startup non-recherche reste sous le régime général : il conserve ses droits sauf cession écrite explicite. La sécurité juridique impose de faire signer une cession formelle à chaque stagiaire, sans s'appuyer sur la dévolution automatique de L. 113-9-1.
Mes développeurs utilisent GitHub Copilot : qui possède le code généré ?
Le code purement généré par l'IA, sans intervention créative humaine, n'est pas protégeable par le droit d'auteur. Le code produit par un développeur utilisant l'IA comme assistant (prompts, sélection, modification, intégration architecturale) reste protégeable, sous réserve d'apport intellectuel humain démontrable. La traçabilité (prompts conservés, revue documentée) est l'élément clé. Les outils doivent être paramétrés pour filtrer les suggestions reproduisant du code public, et les contrats de travail doivent encadrer ces usages.
Que vaut une cession de droits orale ou tacite sur du code ?
La cession orale ne respecte pas les exigences de l'article L. 131-3 du CPI, qui impose une mention distincte de chaque droit cédé et la délimitation du domaine d'exploitation (étendue, destination, lieu, durée). En l'absence de cession écrite, la jurisprudence reconnaît une licence implicite tacite limitée à la finalité prévue, mais cette licence ne couvre ni la modification substantielle, ni la cession à un tiers, ni l'exploitation au-delà du périmètre initial. Une cession orale ou tacite n'est donc pas suffisante pour permettre une exploitation pleine et entière, et constitue un point d'arrêt en due diligence.
