Freelance tech : protéger votre code préexistant face à la cession globale de propriété intellectuelle

Un freelance tech qui signe une clause de cession globale de propriété intellectuelle sans réserver expressément son code préexistant risque de céder à un client unique les bibliothèques, frameworks et outils qu'il réutilise sur toutes ses missions, c'est-à-dire son fonds de commerce technique. La parade existe : identifier contractuellement la background IP, la lister en annexe, ne céder que les développements propres à la mission et concéder une simple licence sur le reste. Encore faut-il le faire avant la signature, et dans les formes exigées par le Code de la propriété intellectuelle.

Le sujet est devenu critique avec la généralisation des contrats de consulting standardisés, souvent traduits de modèles anglo-saxons, qui stipulent que « tout livrable et tout work product est la propriété exclusive du client ». Pour un développeur indépendant, un data scientist ou un ingénieur DevOps, ces clauses posent une question existentielle : chaque mission repose sur un socle de code accumulé au fil des années, des snippets aux bibliothèques complètes, en passant par des générateurs, des scripts d'infrastructure et des architectures types. Céder ce socle à un client, même involontairement, c'est s'interdire de le réutiliser, s'exposer à des poursuites en contrefaçon pour avoir continué à s'en servir, et offrir gratuitement des années de travail. À l'inverse, le client a des préoccupations légitimes : être certain de pouvoir exploiter, maintenir et faire évoluer ce qu'il a payé.

Cet article expose le cadre juridique français de la cession de droits sur le logiciel, la pratique contractuelle internationale des « work products » et des annexes de PI préexistante, le piège de l'annexe vide, la question des licences open source incorporées, et les mécanismes de preuve et de réversibilité. Pour l'audit ou la négociation de vos contrats, notre équipe en contrats informatiques, IT et RGPD intervient aux côtés des indépendants comme des entreprises.

Le principe fondamental : le freelance reste propriétaire de son code par défaut

Pas de « work made for hire » en droit français

Première idée reçue à dissiper : payer un développement ne rend pas propriétaire des droits. En droit français, l'article L. 111-1 du Code de la propriété intellectuelle attribue à l'auteur, du seul fait de la création, un droit de propriété incorporelle exclusif et opposable à tous, et son troisième alinéa précise que l'existence d'un contrat de louage d'ouvrage ou de service n'emporte par elle-même aucune dérogation à ce principe. Autrement dit, le client qui commande et paie un logiciel à un freelance n'acquiert pas les droits d'auteur sur ce logiciel, sauf cession expresse. La Cour de cassation le rappelle avec constance : la simple remise du livrable et le paiement du prix ne valent pas cession de droits.

La dévolution automatique à l'employeur ne joue pas pour les indépendants

L'article L. 113-9 du CPI prévoit certes que les droits patrimoniaux sur les logiciels créés par un salarié dans l'exercice de ses fonctions sont dévolus à l'employeur. Mais ce texte est propre à la relation de travail : il ne s'applique ni aux freelances, ni aux dirigeants non salariés, ni aux stagiaires hors conditions spécifiques. Le client d'un indépendant ne peut donc compter que sur une chaîne contractuelle de cession explicite. Cette différence explique l'insistance, parfois brutale, des directions juridiques sur les clauses de cession dans les contrats de prestation : sans elles, le client est simple détenteur d'une copie, dans une situation juridique précaire. Les fondements de la protection du logiciel sont détaillés dans notre guide sur le code source et la propriété intellectuelle.

Le formalisme de l'article L. 131-3 du CPI : l'allié objectif du freelance

Lorsqu'une cession est stipulée, elle obéit côté français à un formalisme strict. L'article L. 131-3 du CPI exige que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue, sa destination, son lieu et sa durée. L'article L. 131-1 prohibe en outre la cession globale des œuvres futures. La jurisprudence interprète ces textes en faveur de l'auteur : tout ce qui n'est pas expressément cédé est réputé retenu. Une clause générale du type « le prestataire cède au client l'intégralité des droits de propriété intellectuelle sur les livrables » est donc fragile en droit français, et cette fragilité profite mécaniquement au freelance. Les exigences de rédaction sont décortiquées dans notre article sur le contrat de cession de droit d'auteur.

Background IP et foreground IP : la distinction qui structure tout

Définitions et enjeux

La pratique contractuelle internationale a forgé une distinction que le droit français ne nomme pas mais accueille parfaitement. La background IP (ou PI préexistante) désigne l'ensemble des éléments de propriété intellectuelle détenus par le prestataire avant la mission ou développés en dehors d'elle : bibliothèques, frameworks maison, algorithmes, outils de build, documentation type, savoir-faire formalisé. La foreground IP désigne ce qui est créé spécifiquement pour la mission et pour le client : le code métier, les développements sur mesure, les livrables commandés. Certains contrats ajoutent une catégorie intermédiaire, la sideground IP, pour les créations réalisées pendant la mission mais sans lien avec elle. L'équilibre standard d'un contrat bien construit est simple : la foreground IP est cédée au client ; la background IP reste au prestataire, qui concède au client une licence sur les éléments préexistants incorporés aux livrables, dans la mesure nécessaire à leur exploitation.

Pourquoi la cession globale de la background IP est dangereuse pour tous

Pour le freelance, céder sa background IP à un client revient à liquider son actif principal : il ne peut plus, en droit, réutiliser ses propres bibliothèques chez d'autres clients sans devenir contrefacteur de ce qu'il a lui-même écrit. Le paradoxe est brutal : plus le prestataire est expérimenté et outillé, plus la cession globale le dépouille. Mais l'opération est également risquée pour le client : une cession trop large est exposée à la nullité ou à l'interprétation restrictive sur le fondement des articles L. 131-1 et L. 131-3 du CPI, et un prestataire dépouillé de ses outils est un prestataire qui disparaît ou qui triche. L'intérêt bien compris des deux parties converge vers une architecture cession/licence propre, ce qui suppose un travail de qualification précis des composants. Ce travail de cartographie contractuelle est exactement celui qu'un avocat en contrats informatiques mène lors de l'audit d'un contrat de consulting.

Tableau 1 - Background, foreground et open source : qui possède quoi ?

La pratique common law : « work product » et présomptions inversées

Des logiques juridiques opposées

Les contrats de consulting d'inspiration américaine reposent sur la doctrine du work made for hire : aux États-Unis, l'œuvre commandée dans certaines conditions appartient dès l'origine au commanditaire, et les contrats complètent ce régime par des clauses de cession automatique du type « Consultant hereby assigns all right, title and interest in and to the Work Product ». La logique est inverse de la logique française : tout appartient au client, sauf ce qui est expressément réservé. C'est précisément pour organiser cette réserve que ces contrats comportent une annexe « Prior Inventions » ou « Pre-existing IP », dans laquelle le prestataire est invité à lister les éléments qu'il entend exclure de la cession.

Le piège de l'annexe vide : la mention « NIL »

C'est ici que se niche le piège le plus fréquent et le plus coûteux. L'annexe de PI préexistante est presque toujours pré-remplie avec la mention « NIL », « None » ou laissée en blanc, et signée telle quelle dans la précipitation de l'onboarding. Juridiquement, le freelance déclare alors qu'il n'a aucune propriété intellectuelle préexistante : tout ce qu'il utilisera pendant la mission, y compris ses bibliothèques développées des années plus tôt, tombera dans le champ de la cession ou, à tout le moins, dans une zone grise très défavorable. Certaines clauses aggravent l'effet en stipulant que tout élément préexistant non listé mais incorporé aux livrables est réputé licencié gratuitement, irrévocablement et de manière perpétuelle au client, quand d'autres vont jusqu'à présumer sa cession. Un exemple générique : un développeur qui incorpore dans le livrable son moteur de génération de rapports, fruit de cinq ans de travail, sans l'avoir listé en annexe, peut se voir opposer par le client l'exclusivité sur ce moteur et se voir reprocher sa réutilisation chez un concurrent. Remplir cette annexe avec précision, sans pour autant divulguer son savoir-faire, est un exercice d'équilibre : c'est précisément à ce stade qu'un accompagnement par un avocat en contrats informatiques fait toute la différence.

Le conflit de lois : quelle protection quand le contrat est étranger ?

Beaucoup de freelances français contractent avec des clients américains, britanniques ou des plateformes internationales, sous des contrats soumis au droit de l'État de Californie, de New York ou au droit anglais. Le formalisme protecteur de l'article L. 131-3 du CPI n'est alors pas nécessairement applicable, même si certaines protections du droit d'auteur français, notamment le droit moral, résistent aux clauses contraires en raison de leur caractère d'ordre public. L'articulation entre la loi du contrat, la loi du pays de protection et les règles impératives françaises est technique et dépend de chaque situation : avant de signer un contrat international de consulting tech, une revue par un avocat en droit des contrats informatiques et internationaux est le seul moyen d'identifier ce qui est réellement négociable et ce qui est perdu d'avance.

Open source : la troisième propriété intellectuelle dans la pièce

On ne cède pas ce qui ne nous appartient pas

Tout livrable moderne incorpore des composants open source : frameworks, bibliothèques, dépendances transitives. Or ces composants appartiennent à leurs auteurs et sont régis par leurs licences : le freelance ne peut ni les céder, ni garantir au client une propriété pleine et entière sur un livrable qui en contient. Une clause de cession globale assortie d'une garantie d'éviction absolue, signée sans réserve open source, met le prestataire en situation de violation contractuelle dès le premier commit. La cartographie des licences des composants incorporés est donc un préalable à toute négociation de clause de PI, dans la logique décrite par notre guide du droit des logiciels et des bases de données.

Licences permissives et licences copyleft : des effets radicalement différents

Les licences permissives (MIT, BSD, Apache 2.0) autorisent l'incorporation dans un logiciel propriétaire moyennant des obligations légères, principalement de mention. Les licences copyleft fortes (GPL v2 et v3, AGPL) imposent en revanche que le logiciel dérivé distribué soit lui-même soumis à la même licence, code source inclus ; l'AGPL étend cette obligation à la simple mise à disposition en réseau, ce qui la rend redoutable pour les applications SaaS. Un freelance qui incorpore un composant AGPL dans le produit propriétaire de son client sans le signaler crée un risque de contamination que le client découvrira, au pire moment, lors d'un audit de due diligence à l'occasion d'une levée de fonds ou d'une cession. La clause de PI doit donc organiser trois choses : l'inventaire des composants tiers, la conformité de leur usage et la répartition des responsabilités en cas de non-conformité. Le calibrage de ces garanties, dans un sens protecteur sans être suicidaire commercialement, relève du conseil individualisé d'un avocat en contrats IT.

Tableau 2 - Principales licences open source et compatibilité avec un livrable propriétaire

Side letter, annexes et preuve : sécuriser l'antériorité de votre code

La side letter et l'annexe de PI préexistante

Lorsque le contrat principal est un modèle imposé et difficile à amender (contrat de plateforme, conditions générales d'une ESN, master services agreement d'un grand groupe), la pratique recourt à la side letter : un document séparé, signé des deux parties, qui précise ou déroge au contrat principal sur des points ciblés, notamment la liste de la PI préexistante du prestataire et le régime de licence applicable. Sa force juridique dépend de sa rédaction et de son articulation avec le contrat principal, en particulier avec les clauses d'intégralité (entire agreement) qui privent d'effet les documents extérieurs non visés. Une side letter mal articulée peut ne rien valoir : sa rédaction et son ordre de signature obéissent à des règles précises qu'il est imprudent d'improviser.

Constituer la preuve de l'antériorité

Réserver sa background IP ne sert à rien si l'on ne peut pas prouver, des années plus tard, que tel module existait avant la mission. La preuve de l'antériorité repose sur un faisceau de moyens dont la valeur probante varie : dépôt auprès de l'Agence pour la protection des programmes (APP), enveloppe Soleau ou e-Soleau auprès de l'INPI, constat d'huissier, horodatage qualifié, et, plus quotidiennement, l'historique des dépôts de code (les journaux de commits d'un dépôt Git, s'ils sont correctement gérés, constituent un commencement de preuve utile). En droit, la titularité et la date de création se prouvent par tous moyens, la charge pesant sur celui qui revendique (article 1353 du Code civil). La stratégie probatoire optimale dépend de la valeur du code et du niveau de risque : un avocat en propriété intellectuelle et contrats informatiques vous aidera à dimensionner le dispositif sans surinvestir.

Le prix de la cession : un paramètre de négociation, pas un détail

Dernier point souvent ignoré : la cession de droits a un prix. La rémunération de l'auteur obéit en principe à une logique de participation proportionnelle aux recettes (article L. 131-4 du CPI), le forfait étant admis dans de nombreux cas, notamment pour le logiciel. En pratique, le freelance a intérêt à distinguer dans sa facturation la prestation de développement et la cession de droits, et à moduler le prix selon l'étendue de la cession : une cession exclusive, mondiale, pour toute la durée des droits, tous modes d'exploitation, ne vaut pas le même prix qu'une licence d'usage interne. Ce levier de négociation est presque toujours laissé sur la table par les indépendants, alors que la logique en est exposée dans notre article sur la cession de droits.

Réversibilité, droit à copie et fin de mission

La réversibilité vue du freelance

La clause de réversibilité, classique des contrats IT, organise la restitution au client des livrables, codes sources, documentations et données en fin de contrat, afin qu'il puisse reprendre ou confier à un tiers l'exploitation du système : ses mécanismes sont détaillés dans notre guide de la clause de réversibilité. Vue du freelance, la réversibilité doit être symétrisée : le prestataire doit pouvoir conserver une copie de sa background IP (par définition, elle lui appartient), une copie de ses documents de travail dans la mesure permise, et les éléments nécessaires à la défense de ses droits en cas de litige ultérieur, notamment fiscal ou probatoire. À l'inverse, il devra restituer ou détruire les éléments confidentiels du client. La frontière entre ce qui se garde et ce qui se rend doit être écrite noir sur blanc, faute de quoi la fin de mission se transforme en négociation sous contrainte.

Le droit à copie et la maintenance future

Le client, de son côté, doit vérifier qu'il dispose du code source et non des seuls binaires, des scripts de build et de déploiement, et de la documentation permettant une maintenance autonome, le cas échéant via un séquestre (escrow) auprès d'un tiers de confiance. Le cessionnaire des droits sur un logiciel bénéficie en outre des prérogatives légales de l'utilisateur légitime (articles L. 122-6 et L. 122-6-1 du CPI : copie de sauvegarde, correction d'erreurs dans certaines limites, décompilation encadrée), mais ces prérogatives ne remplacent pas une organisation contractuelle claire. L'articulation entre cession de PI, réversibilité et maintenance est au cœur des contrats de développement, comme l'expose notre guide du contrat de développement logiciel. Négocier cet ensemble de manière cohérente, plutôt que clause par clause, est ce qui distingue un contrat robuste d'un empilement de stipulations contradictoires : c'est le travail d'un avocat en contrats informatiques.

Tableau 3 - Checklist des points de PI à traiter avant de signer un contrat de consulting tech

Questions Fréquemment Posées (FAQ)

Mon client est-il propriétaire du code que je développe pour lui en freelance ?

Pas automatiquement. En droit français, la commande et le paiement d'un développement ne transfèrent pas les droits d'auteur (article L. 111-1 du CPI) : sans clause de cession conforme au formalisme de l'article L. 131-3, le client ne détient qu'une copie et des droits d'utilisation limités. C'est la raison pour laquelle les contrats de prestation comportent presque toujours une clause de cession, dont le périmètre doit être négocié.

Qu'est-ce que la background IP dans un contrat de consulting ?

La background IP (ou propriété intellectuelle préexistante) désigne les éléments créés par le prestataire avant la mission ou en dehors d'elle : bibliothèques, outils, frameworks, savoir-faire formalisé. Elle s'oppose à la foreground IP, créée spécifiquement pour la mission. Le standard contractuel équilibré consiste à céder la foreground IP au client et à ne concéder sur la background IP qu'une licence d'utilisation.

Que se passe-t-il si j'ai signé une annexe de PI préexistante vide ou marquée « NIL » ?

Vous avez déclaré n'avoir aucune PI préexistante : les éléments anciens incorporés à vos livrables risquent d'être considérés comme cédés ou licenciés très largement au client, et leur réutilisation ailleurs devient juridiquement risquée. La situation n'est pas toujours irrattrapable, notamment au regard du formalisme français de la cession, mais elle exige une analyse individuelle rapide avant toute réutilisation du code concerné.

Puis-je réutiliser chez un nouveau client du code écrit pour un ancien client ?

Cela dépend de la qualification du code. Votre background IP réservée reste réutilisable ; le code spécifique cédé à l'ancien client ne l'est pas, sous peine de contrefaçon et de violation contractuelle. Les compétences, méthodes et connaissances générales restent en revanche toujours les vôtres. La frontière exacte se trace contrat par contrat, d'où l'importance de faire auditer vos clauses avant de trancher.

Une clause qui cède « tous les droits sur tous les livrables » est-elle valable en France ?

Elle est fragile. L'article L. 131-3 du CPI exige la mention distincte de chaque droit cédé et la délimitation du domaine d'exploitation (étendue, destination, lieu, durée), et l'article L. 131-1 prohibe la cession globale des œuvres futures. La jurisprudence interprète les cessions restrictivement en faveur de l'auteur. Le régime est plus souple pour le logiciel que pour les autres œuvres, mais une clause générale et sèche demeure une source d'insécurité pour les deux parties.

Comment prouver que mon code existait avant la mission ?

Par tout moyen créant une date certaine ou un faisceau probatoire solide : dépôt auprès de l'Agence pour la protection des programmes, enveloppe e-Soleau de l'INPI, constat d'huissier, horodatage qualifié, et historique de commits correctement tenu. Le bon dispositif dépend de la valeur du code : quelques centaines d'euros de dépôts bien choisis peuvent sécuriser des années de développement.

Le client peut-il m'interdire de garder une copie de mon propre code ?

Il ne peut pas vous priver de votre background IP, qui vous appartient. En revanche, les clauses de confidentialité et de restitution peuvent légitimement vous imposer de rendre ou détruire les éléments propres au client, y compris la foreground IP cédée. Si le contrat est muet ou ambigu, la fin de mission devient conflictuelle : mieux vaut régler la question des copies noir sur blanc avant de commencer.

Qui est responsable si un composant open source contamine le livrable ?

En l'absence de clause, la responsabilité se discute sur le terrain des garanties et de l'obligation de conseil du prestataire ; avec une clause, c'est sa rédaction qui décide. Les contrats bien construits organisent un inventaire des composants tiers, des garanties calibrées et une répartition claire des risques. Un prestataire ne devrait jamais garantir une pleine propriété sans réserve sur un livrable incorporant de l'open source.

Conclusion

Pour un freelance tech, la clause de propriété intellectuelle n'est pas une clause parmi d'autres : c'est celle qui décide si votre capital technique se consolide de mission en mission ou s'évapore à chaque signature. Les réflexes essentiels tiennent en quatre points : ne jamais signer une cession globale sans avoir qualifié background et foreground IP, ne jamais laisser une annexe de PI préexistante vide, traiter l'open source avant qu'il ne se rappelle à vous, et constituer la preuve d'antériorité de votre code au fil de l'eau. Côté client, les mêmes clauses, bien rédigées, sécurisent l'exploitation, la maintenance et la valorisation future du logiciel. Dans les deux cas, quelques heures de travail juridique en amont pèsent infiniment moins lourd qu'un contentieux de contrefaçon en aval. Notre cabinet audite et négocie ces contrats au quotidien : avant votre prochaine mission, faites relire votre clause de propriété intellectuelle par un avocat en contrats informatiques.

Article rédigé par Guillaume Leclerc, avocat d'affaires à Paris, 34 Avenue des Champs-Élysées.

« Pour aller plus loin » :

• Code source et propriété intellectuelle : le guide complet pour protéger vos créations logicielles
• Le contrat de cession de droit d'auteur
• Contrat de développement logiciel : guide complet
• Droit des logiciels et des bases de données : le guide complet
• La cession de droits : comprendre pour mieux protéger et exploiter ses créations
• Clause de réversibilité : définition, emploi, exemples et rédaction
• Le guide complet du contrat freelance en France
• Contrat de licence de logiciel : guide complet pour rédiger et sécuriser votre contrat