Propriété du code source développé par un prestataire : ce que le client obtient vraiment

Une idée reçue circule largement chez les clients de prestataires informatiques : avoir payé le développement d'un logiciel, d'un site ou d'une application suffirait à en devenir propriétaire. En droit français, ce n'est pas le cas. L'article L. 111-1 du Code de la propriété intellectuelle prévoit que l'auteur jouit, du seul fait de la création, d'un droit de propriété incorporelle exclusif et opposable à tous — et l'existence d'un contrat de prestation n'emporte, par elle-même, aucune dérogation à cette jouissance.

Sauf clause de cession valablement rédigée, les droits sur le code source demeurent donc, en principe, la propriété de l'entreprise ou de la personne qui l'a développé, quand bien même ce développement aurait été intégralement financé par le client. Cet article détaille le principe de titularité applicable, la distinction entre cession et licence, le formalisme strict exigé pour transférer des droits, et les précautions à prendre pour garantir au client une réelle autonomie technique sur le logiciel qu'il a commandé.

Le principe : le prestataire reste titulaire des droits, sauf cession expresse

Ce principe surprend souvent les clients, alors qu'il découle directement de l'application au logiciel du droit commun de la propriété littéraire et artistique.

Le code source, une œuvre protégée par le droit d'auteur

Le logiciel, y compris son code source, bénéficie de la protection du droit d'auteur dès lors qu'il présente un caractère original. L'article L. 111-1 du Code de la propriété intellectuelle confère à l'auteur un droit de propriété incorporelle exclusif du seul fait de la création, sans qu'aucune formalité de dépôt ou d'enregistrement ne soit nécessaire. Cette protection couvre le code source, le code objet, l'architecture originale du programme, certains éléments de conception, la documentation technique et les interfaces graphiques lorsqu'elles présentent elles-mêmes une originalité propre.

Il faut cependant garder à l'esprit que le droit d'auteur protège l'expression du logiciel, et non les idées, principes, fonctionnalités ou méthodes abstraites qui le sous-tendent. Un client ne peut donc revendiquer aucun droit sur un concept ou une fonctionnalité en tant que tels, seulement sur l'expression concrète que le prestataire en a donnée dans son code.

Le paiement du prix ne transfère pas les droits

L'article L. 111-1 du Code de la propriété intellectuelle précise que l'existence d'un contrat de louage d'ouvrage ou de service par l'auteur d'une œuvre de l'esprit n'emporte aucune dérogation à la jouissance de son droit d'auteur. Le paiement du prix convenu ne suffit donc pas, à lui seul, à transférer les droits patrimoniaux au client. Cette règle s'applique quel que soit le statut du développeur : freelance, agence web, ESN, éditeur, consultant informatique, société étrangère, ou prestataire intervenant avec ses propres salariés ou sous-traitants.

En l'absence de clause contraire, le client bénéficie tout au plus d'un droit d'utilisation correspondant à la finalité du contrat conclu, mais ne dispose pas nécessairement du droit de modifier le code, de le faire maintenir par un tiers, de le revendre, de le sous-licencier, de le reproduire sur plusieurs environnements ou de le transmettre à un acquéreur en cas de cession de son entreprise. La pratique contractuelle invite donc à distinguer systématiquement la livraison matérielle du code du transfert effectif des droits de propriété intellectuelle qui s'y attachent.

Cession ou licence : deux modèles contractuels à ne pas confondre

Cette distinction conditionne l'ensemble de la stratégie contractuelle à adopter, et doit être choisie en connaissance de cause plutôt que par défaut, faute d'avoir été discutée entre les parties.

La licence d'utilisation

Lorsque le prestataire conserve la titularité des droits, il peut accorder au client une licence définissant précisément ses droits d'utilisation du logiciel. Cette licence doit préciser son caractère exclusif ou non exclusif, les utilisateurs autorisés, le nombre de sites ou d'environnements couverts, les droits de reproduction, de modification et de correction éventuellement concédés, la durée, le territoire et les conditions de résiliation.

Un point de vigilance mérite d'être souligné : une licence limitée à la simple utilisation du logiciel, sans droit de modification ni de correction, peut empêcher le client de confier la maintenance du produit à un autre prestataire en cas de rupture de la relation contractuelle initiale — une situation de dépendance qu'il est préférable d'anticiper avant la signature plutôt que de découvrir au moment d'un différend.

L'accès au code source sans transfert des droits

Le client peut également obtenir un accès technique au code source sans pour autant en devenir propriétaire ni même titulaire d'une licence de modification. Cet accès peut être prévu pendant la durée du contrat pour les besoins de la maintenance corrective, ou déclenché uniquement en cas de défaillance du prestataire, de cessation d'activité ou de procédure collective. Il faut toutefois garder à l'esprit que l'accès au code source n'emporte pas automatiquement le transfert des droits d'exploitation : la clause doit indiquer précisément quels actes le client est autorisé à réaliser une fois cet accès obtenu.

Le dépôt séquestre

Le code peut enfin être placé auprès d'un tiers séquestre, selon un mécanisme d'escrow. Le contrat doit alors préciser l'identité du dépositaire, la fréquence des dépôts, les versions et éléments remis, ainsi que les documents de compilation et les dépendances nécessaires à l'exploitation effective du code une fois libéré. Les événements de libération les plus couramment retenus sont la liquidation judiciaire du prestataire, la cessation définitive de la maintenance, une violation grave du contrat, ou l'abandon pur et simple du produit par son éditeur.

La cession des droits patrimoniaux : un formalisme strict

Contrairement à une pratique répandue, une clause générale prévoyant que « tous les droits sont cédés au client » ne suffit pas, en droit français, à sécuriser un transfert de droits d'auteur.

L'exigence de mention distincte de l'article L. 131-3 du Code de la propriété intellectuelle

L'article L. 131-3 du Code de la propriété intellectuelle subordonne la transmission des droits d'auteur à 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, sa destination, le lieu et la durée. La jurisprudence a précisé que ce formalisme n'est pas sanctionné par la nullité de la cession, mais son non-respect complique sérieusement l'interprétation de l'étendue réelle des droits transférés en cas de litige entre les parties.

La clause de cession doit ainsi viser distinctement, selon les besoins identifiés, le droit de reproduire le code, de le représenter, de l'adapter, de le modifier, de le corriger, de le traduire, de l'intégrer à une autre solution, de le distribuer, de le commercialiser et de concéder des sous-licences à des tiers. Une formule générale et imprécise, même rédigée avec l'intention manifeste de tout céder, expose le client au risque qu'un juge interprète restrictivement l'étendue réelle de ses droits.

Les éléments à préciser dans l'acte de cession

Au-delà de l'énumération des droits cédés, l'acte doit préciser si la cession revêt un caractère exclusif, sa date d'effet, la rémunération convenue, les territoires concernés, les supports d'exploitation visés et la durée retenue — généralement alignée sur la durée légale de protection du droit d'auteur. Il est également recommandé de traiter expressément le sort des versions et évolutions futures du logiciel, ce point étant fréquemment source de désaccord lorsque le contrat initial reste silencieux sur la question.

Le périmètre réel des développements cédés

Sans cette distinction, le client peut légitimement croire qu'il acquiert l'intégralité du logiciel, alors que le prestataire conserve en réalité la propriété de briques essentielles à son fonctionnement.

Éléments préexistants du prestataire

Il convient de distinguer nettement les développements spécifiquement réalisés pour le client des éléments préexistants du prestataire — frameworks internes, bibliothèques, outils ou connecteurs qu'il a développés avant le contrat et qu'il réutilise d'un projet à l'autre. Le prestataire doit annexer au contrat une liste précise de ces éléments préexistants qu'il ne cède pas. La solution la plus courante en pratique consiste à concéder au client une licence mondiale, suffisamment étendue pour utiliser, maintenir, modifier et exploiter le logiciel avec ces éléments, sans pour autant lui en transférer la propriété.

Composants open source et composants de tiers

Le code livré peut par ailleurs intégrer des composants open source ou des éléments appartenant à des tiers. Le contrat doit alors imposer au prestataire d'identifier ces composants, leur licence, les obligations de redistribution et de mention qui s'y attachent, ainsi que les éventuelles clauses de copyleft susceptibles de contaminer les développements propres au client. Le prestataire devrait garantir qu'il dispose des droits nécessaires, qu'il a respecté les licences applicables et qu'il communiquera au client la liste complète des composants intégrés.

Le tableau suivant synthétise le régime applicable selon la catégorie de code concernée.

La remise effective du code source

La propriété juridique du code ne suffit pas si le client ne reçoit pas, en pratique, un code réellement exploitable. La remise d'un fichier compressé contenant une version incomplète ou non compilable ne garantit aucune autonomie technique, quand bien même la cession des droits aurait été parfaitement rédigée.

Les livrables à définir contractuellement

Le contrat doit énumérer précisément les livrables attendus : code source complet, code objet, scripts de compilation, fichiers de configuration, documentation technique et d'architecture, schémas de base de données, scripts de migration, tests automatisés, liste des dépendances et procédures de sauvegarde et d'exploitation. Il faut également préciser le format de remise retenu, le dépôt technique utilisé, la fréquence des dépôts successifs, les critères permettant de vérifier la complétude de la livraison, ainsi que la procédure de recette applicable.

Maintenance, évolutions et continuité d'exploitation

Le régime de propriété défini au contrat ne s'arrête pas à la livraison initiale : il doit anticiper la vie du logiciel bien après sa recette.

À qui appartiennent les évolutions futures

Le contrat gagne à distinguer plusieurs catégories d'évolutions, dont le régime de propriété peut légitimement différer : les corrections nécessaires à la conformité du livrable initial, les fonctionnalités nouvelles spécifiquement demandées et financées par le client, les améliorations génériques que le prestataire pourrait réutiliser auprès d'autres clients, et les adaptations propres à l'environnement technique du client. Un régime uniforme et non différencié conduit souvent à des désaccords lorsque le prestataire souhaite réutiliser, pour un autre projet, une amélioration développée dans le cadre du contrat.

La chaîne de titularité des droits du prestataire

Le prestataire doit s'assurer que les personnes ayant matériellement développé le code lui ont elles-mêmes régulièrement transmis les droits nécessaires. En matière de logiciel, l'article L. 113-9 du Code de la propriété intellectuelle prévoit que, sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels 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 légale automatique ne doit toutefois pas être étendue sans précaution aux freelances, sous-traitants, consultants indépendants ou contributeurs externes, qui restent en principe titulaires de leurs propres droits d'auteur en l'absence de cession expresse. Le prestataire qui recourt à ce type de collaborateurs doit donc avoir obtenu contractuellement, en amont, les droits nécessaires auprès de chacun d'eux, et pouvoir en justifier la chaîne complète en cas de contestation ultérieure.

La garantie de jouissance paisible et les cas particuliers

Le client doit enfin être protégé contre le risque qu'un tiers vienne revendiquer des droits sur le code qui lui a été cédé ou concédé.

La garantie contre la contrefaçon

Le prestataire doit garantir que les droits cédés ou concédés au client peuvent être exploités sans porter atteinte aux droits de tiers. Cette garantie porte généralement sur l'originalité des développements, l'absence de contrefaçon connue, la titularité effective des droits des développeurs impliqués et le respect des licences open source intégrées. Le contrat doit également organiser la procédure applicable en cas de réclamation d'un tiers : information immédiate du prestataire, contrôle de la défense, remplacement du composant litigieux, ou à défaut remboursement ou résiliation, cette garantie devant rester cohérente avec les plafonds de responsabilité fixés par ailleurs dans le contrat.

Le cas du code développé avec une IA

Lorsque le prestataire recourt à un outil d'intelligence artificielle pour développer tout ou partie du logiciel, le contrat doit identifier les outils utilisés, les conditions de réutilisation des prompts, les risques de similarité avec du code tiers préexistant, et le niveau de contrôle humain exercé avant la livraison. La génération assistée par IA ne dispense en aucun cas le prestataire de vérifier la qualité, la sécurité, la licéité et l'exploitabilité réelle du code finalement livré au client — la clause doit donc préciser que le prestataire garantit la traçabilité des composants générés et la compatibilité de leurs licences avec l'usage envisagé. Les clauses à intégrer plus largement dans un contrat de prestation recourant à l'intelligence artificielle sont détaillées dans notre article consacré à la clause IA dans un contrat de prestation.

Foire aux questions sur la propriété du code source développé par un prestataire

Le paiement de la prestation transfère-t-il automatiquement la propriété du code ?

Non. En droit français, l'article L. 111-1 du Code de la propriété intellectuelle prévoit que l'existence d'un contrat de prestation n'emporte aucune dérogation à la jouissance du droit d'auteur de son créateur. Seule une clause de cession expresse, respectant le formalisme de l'article L. 131-3 du même code, permet de transférer les droits patrimoniaux au client.

Quelle différence entre cession et licence d'utilisation ?

La cession transfère au client la titularité des droits patrimoniaux sur le code, tandis que la licence lui accorde seulement un droit d'utilisation dont l'étendue est définie par le contrat, le prestataire restant titulaire des droits. Le choix entre ces deux modèles doit être négocié explicitement, car il conditionne directement l'autonomie future du client sur le logiciel.

Le client peut-il confier la maintenance à un autre prestataire sans clause spécifique ?

Pas nécessairement. Une licence limitée à la simple utilisation, sans droit de modification ni de correction, peut empêcher le client de faire maintenir le code par un tiers. Cette possibilité doit être expressément prévue dans la licence ou organisée par un accès au code source assorti des droits de modification nécessaires.

Le prestataire peut-il réutiliser le code développé pour un client ?

Cela dépend de la rédaction du contrat. Les développements spécifiques cédés au client ne peuvent en principe plus être réutilisés librement par le prestataire, sauf clause contraire. En revanche, les éléments préexistants et les améliorations génériques du prestataire peuvent, si le contrat le prévoit, continuer à être exploités par celui-ci pour d'autres clients.

Qu'est-ce qu'un dépôt séquestre et quand le prévoir ?

Le dépôt séquestre, ou escrow, consiste à confier une copie du code source à un tiers dépositaire, qui le libère au client si certains événements surviennent — liquidation du prestataire, cessation de maintenance, ou violation grave du contrat. Il est particulièrement recommandé lorsque le client ne dispose pas d'un accès permanent au code source ou d'une cession complète des droits.

Qui est propriétaire d'un code généré avec l'aide d'une IA ?

La titularité suit en principe le même régime que pour tout autre développement : elle dépend de la clause de cession ou de licence conclue entre le prestataire et le client. Le recours à l'IA ne dispense pas le prestataire de garantir la traçabilité, la licéité et l'exploitabilité du code livré, ni de vérifier l'absence de similarité problématique avec un code tiers préexistant.

Conclusion

La propriété du code source ne se présume jamais : elle se négocie et se rédige, en distinguant précisément les développements spécifiques, les éléments préexistants du prestataire et les composants open source ou de tiers intégrés au logiciel. Un client qui néglige cette distinction au moment de la signature risque de découvrir, souvent au pire moment — rupture de la relation contractuelle, revente de son entreprise, ou simple besoin de changer de prestataire — qu'il ne dispose pas de l'autonomie qu'il pensait avoir acquise. Lorsque le développement fait par ailleurs appel à des outils d'intelligence artificielle, ces clauses de propriété intellectuelle doivent être complétées par les garanties spécifiques détaillées dans notre article sur la clause IA dans un contrat de prestation.

Article rédigé sur la base de l'état du droit et des textes officiels disponibles à la date de publication.

‍