Payer une prestation ne vous rend pas propriétaire
C’est l’idée reçue la plus répandue dans les achats de prestations intellectuelles : « j’ai payé, donc c’est à moi ». En droit français, c’est faux.
L’article L111-1 du Code de la propriété intellectuelle est clair : le fait de conclure un contrat de prestation avec l’auteur d’une œuvre ne le prive pas de ses droits. Le prestataire qui crée reste titulaire des droits, sauf s’il les cède par écrit.
La situation est très différente avec un salarié. Pour un logiciel créé par un employé dans l’exercice de ses fonctions, les droits patrimoniaux reviennent automatiquement à l’employeur (article L113-9). Aucune règle de ce type ne joue en faveur du client d’un prestataire externe.
Prenons un exemple. Votre direction achats confie à une ESN la refonte de votre portail fournisseurs. Le projet comprend une étude de cadrage, des maquettes UX et le développement de l’application. Le contrat fixe un prix, un planning et des livrables, mais ne dit rien de la propriété intellectuelle. Deux ans plus tard, vous voulez confier les évolutions à un autre prestataire. Sans cession écrite, vous risquez de ne pas pouvoir modifier le code, le faire reprendre par un tiers ou réutiliser les maquettes.
Un cas réel : la cour d’appel de Colmar
Ce scénario n’a rien de théorique. Dans un arrêt du 9 avril 2025, la cour d’appel de Colmar a jugé que la société ayant réalisé les trois quarts de la programmation, dirigé le projet et rédigé la documentation technique était titulaire des droits sur le logiciel. Faute d’acte de cession écrit, la société cliente, qui avait pourtant participé au développement, est restée simple utilisatrice.
Pour trancher, la cour a analysé l’historique GitLab du projet, qui retrace les contributions de chaque développeur. Résultat : 76 % de la programmation revenait au prestataire, contre 21 % pour le client. Les équipes du client travaillaient surtout sur l’interface, dont les éléments fonctionnels ne sont pas, en eux-mêmes, protégeables par le droit d’auteur.
La cour a aussi rappelé qu’une cession ne peut pas être implicite, et que le paiement des factures ne suffit pas à rendre le client titulaire des droits sur le logiciel.
Vous l’aurez compris : sans clause de cession, le paiement couvre le travail réalisé, pas la propriété de ce qui a été créé.
Freelance ou ESN : les règles ne sont pas les mêmes
Tous les prestataires ne sont pas dans la même situation juridique. Cette distinction est souvent ignorée, alors qu’elle change la façon d’apprécier le risque.
Avec un freelance
Le freelance est une personne physique : il est l’auteur de ce qu’il crée, et il en reste titulaire tant qu’il n’a pas cédé ses droits. Or cette cession obéit à des règles strictes. L’article L131-3 du Code de la propriété intellectuelle exige un écrit qui mentionne distinctement chaque droit cédé (reproduction, adaptation, diffusion…) et en précise l’étendue, la destination, le territoire et la durée. Sans clause écrite, détaillée et conforme, il n’y a pas de cession : le client a payé la prestation, mais le code appartient toujours au freelance.
Avec une ESN ou un cabinet de conseil
Pour le code, les droits des développeurs salariés de l’ESN lui reviennent automatiquement (article L113-9). Quand l’ESN cède ensuite au client, elle n’est pas l’auteur : elle transmet des droits qu’elle a elle-même reçus. Or, depuis un arrêt de 1993, les juges considèrent que le formalisme strict de l’article L131-3 ne s’applique qu’aux cessions consenties par l’auteur lui-même.
Faut-il en conclure qu’une clause est inutile avec une ESN ou une agence ? Non. Une cession implicite n’est pas une protection. C’est une solution trouvée par un juge, au terme d’un contentieux, et dont l’issue reste incertaine. Les deux décisions citées ici montrent d’ailleurs que les juges n’aboutissent pas toujours au même résultat. Une clause écrite évite simplement d’avoir ce débat.
Code, études, maquettes : tous les livrables ne se valent pas
Autre point souvent négligé : la dévolution automatique à l’employeur de l’article L113-9 ne concerne que les logiciels et leur documentation.
Or une prestation intellectuelle produit bien d’autres livrables : études de cadrage, recommandations stratégiques, maquettes UX/UI, supports de formation, contenus éditoriaux. Pour ces créations, c’est le régime général du droit d’auteur qui s’applique. Même lorsqu’il est salarié de l’ESN, le consultant peut rester l’auteur de ce qu’il a créé.
Reprenons notre exemple du portail fournisseurs. Le code développé par les salariés de l’ESN appartient à l’ESN, qui peut vous le céder. En revanche, les droits sur les maquettes UX dépendent de la chaîne de cession entre les consultants et leur employeur. Si cette chaîne n’est pas sécurisée, l’ESN peut vous céder des droits qu’elle ne détient pas entièrement.
D’où l’importance, pour le donneur d’ordre, de :
- viser tous les livrables dans la clause de cession, pas seulement le code ;
- exiger du prestataire qu’il garantisse détenir les droits qu’il cède, y compris ceux de ses consultants et de ses sous-traitants.
Open source et IA générative : le risque caché
Deux sujets ont pris une place croissante dans les livrables : les composants open source et le code produit avec l’aide de l’IA.
Des conflits de licences en forte hausse
La quasi-totalité des logiciels intègrent aujourd’hui des composants open source, chacun soumis à sa propre licence. Certaines licences imposent des obligations fortes, par exemple la publication du code source d’un logiciel qui les intègre.
Selon le rapport OSSRA 2026 de l’éditeur Black Duck, 68 % des bases de code auditées contenaient des conflits de licences open source, contre 56 % l’année précédente. Black Duck attribue cette hausse en partie au « blanchiment de licence » : les assistants IA génèrent du code dérivé de sources sous licence copyleft sans conserver les informations de licence d’origine. Et ces outils sont utilisés même là où ils sont interdits : selon une autre étude du même éditeur, 76 % des entreprises qui les proscrivent reconnaissent que leurs développeurs y ont recours malgré tout.
L’IA pose aussi une question de titularité
En droit français, la protection par le droit d’auteur suppose une contribution créative humaine. Un livrable produit en grande partie par une IA pourrait donc ne pas être protégé du tout. Le prestataire pourrait alors vous céder des droits qui n’existent pas au titre du droit d’auteur, et le livrable pourrait être réutilisé par des tiers sous réserve des autres protections applicables.
Pour le donneur d’ordre, cela implique d’aller plus loin que la clause de cession classique : demander la liste des composants open source et de leurs licences, et la déclaration de l’usage d’outils d’IA générative dans la production des livrables.
Comment rédiger une clause de cession qui vous protège
Une clause de cession efficace repose sur quelques règles simples. En voici six, à vérifier avec votre direction juridique.
1. Signer avant le démarrage
C’est la règle la plus simple, et la plus souvent oubliée. Trop de prestations démarrent sur un bon de commande ou un accord verbal, avec un contrat qui arrive « plus tard ». Aucune prestation ne devrait démarrer sans contrat signé, y compris dans l’urgence.
2. Identifier précisément l’objet de la cession
L’article L131-1 prévoit que « la cession globale des œuvres futures est nulle ». Une clause qui céderait par avance, et sans les définir, toutes les créations futures du prestataire serait donc sans effet.
Nommez clairement ce qui est cédé : le logiciel concerné, ses codes sources et exécutables, sa documentation, ses versions et correctifs, mais aussi les livrables non logiciels (études, maquettes, supports). Pour les contrats-cadres et les prestations en régie, veillez à ce que chaque livrable soit identifiable.
3. Respecter les mentions obligatoires
L’article L131-3 est très précis : « La transmission des droits de l’auteur est subordonnée à la condition que chacun des droits cédés fasse l’objet d’une mention distincte dans l’acte de cession et que le domaine d’exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. »
Concrètement, la clause doit lister chaque droit cédé (reproduction, représentation, adaptation, modification, traduction, distribution) et préciser :
- le territoire, par exemple la France ou le monde entier ;
- la durée, par exemple toute la durée légale de protection des droits ;
- la destination, c’est-à-dire les usages prévus.
Une formule générale du type « le prestataire cède l’ensemble de ses droits » ne suffit pas.
Bon à savoir : pour un logiciel, la loi autorise une rémunération forfaitaire de la cession (article L131-4). Pas besoin de prévoir un pourcentage sur les revenus d’exploitation.
4. Distinguer le spécifique du réutilisable
Un prestataire s’appuie souvent sur des briques qu’il a développées avant votre prestation et qu’il réutilise chez d’autres clients. Il est légitime qu’il les conserve.
La clause doit donc distinguer deux choses :
- le code et les livrables développés spécifiquement pour vous, à céder en exclusivité ;
- les composants préexistants du prestataire, pour lesquels une licence d’utilisation suffit, à condition qu’elle soit durable et vous permette de faire évoluer le livrable.
5. Exiger des garanties
La clause doit prévoir plusieurs garanties :
- une garantie d’éviction : le prestataire garantit être titulaire des droits cédés et prend en charge les conséquences d’une action en contrefaçon engagée par un tiers ;
- une garantie sur la chaîne de droits : cette garantie couvre aussi les droits de ses consultants et de ses sous-traitants ;
- une déclaration des composants open source et de leurs licences ;
- une déclaration de l’usage d’outils d’IA générative dans la production des livrables.
6. Prévoir la réversibilité et conserver la trace
Les droits ne servent à rien si vous ne récupérez pas ce qu’il faut pour les exercer. Prévoyez la restitution en fin de contrat des livrables, des codes sources, de la documentation et des accès. C’est ce qui vous permettra de changer de prestataire sans repartir de zéro.
Enfin, conservez la trace : contrat signé, avenants, livrables, échanges. L’affaire de Colmar l’a montré : le jour d’un litige, c’est l’historique qui fait la preuve.
Un contrat ce n’est pas juste une formalité administrative. C’est lui qui fait que les droits vous appartiennent, que les données sont encadrées et que vous pouvez prouver ce que vous avez vérifié. Une prestation sans contrat conforme c’est une prestation à risque, même si le travail livré est excellent.Julie Charrier, Directrice des opérations, OPASE
Pour conclure
En matière de prestations intellectuelles, la propriété de vos livrables se joue au moment de signer, pas au moment de livrer. Payer ne suffit pas. Les règles diffèrent selon que vous travaillez avec un freelance ou une ESN, selon qu’il s’agit de code ou d’une étude. L’open source et l’IA ajoutent un risque que les contrats traditionnels n’ont pas prévu.
La réponse tient en trois réflexes : un contrat signé avant tout démarrage, une clause de cession précise et complète, et une trace conservée de chaque étape. Appliqués à chaque prestation, et non au cas par cas, ils évitent de découvrir trop tard que l’on ne possède pas ce que l’on a payé.
Questions fréquentes
Si je paie un prestataire pour développer un logiciel, en suis-je propriétaire ?
Pas automatiquement. Sans clause de cession écrite, le prestataire reste titulaire des droits. Vous disposez au mieux d’un droit d’utilisation, sans pouvoir modifier ou faire évoluer le logiciel librement.
Une cession de droits peut-elle être implicite ?
Avec un auteur personne physique, comme un freelance, la cession doit être écrite et détaillée. Avec une société qui cède des droits qu’elle a elle-même reçus, les juges admettent parfois une cession implicite. Mais cette solution suppose un contentieux et reste incertaine : mieux vaut une clause écrite.
La clause de cession doit-elle couvrir les livrables qui ne sont pas du code ?
Oui. La règle qui attribue automatiquement les droits à l’employeur ne vaut que pour les logiciels. Les études, maquettes et supports de formation doivent être expressément visés dans la clause.