Modèle de cession de droits sur un logiciel gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous acquérez la propriété d’un logiciel. Une société qui rachète le code d’un outil développé en interne par une jeune pousse, ou qui récupère les droits sur une application conçue par un prestataire, veut devenir titulaire des droits patrimoniaux, non un simple utilisateur. Le contrat de cession de droits d’auteur organise ce transfert de propriété, avec l’assiette exacte des droits cédés et les garanties attachées. Il n’organise pas un accès temporaire, mais une acquisition définitive.

Vous cédez un logiciel que vous avez développé. Un éditeur qui vend sa technologie, un indépendant qui transfère à son client la propriété d’un développement sur mesure, signe le même contrat, en position de cédant. La vigilance porte alors sur le périmètre réellement transféré, le prix et les garanties que vous consentez, pour ne pas engager votre responsabilité au-delà de ce qui a été négocié.

Le transfert doit être total et non un simple droit d’usage. Si l’acquéreur veut pouvoir modifier, revendre ou concéder à son tour le logiciel sans revenir vers vous, seule une cession le permet. Une licence d’utilisation laisse la propriété au cédant et n’autorise que les usages expressément concédés. La distinction commande toute la rédaction du contrat.

La chaîne de titularité doit être sécurisée. Un logiciel agrège souvent des contributions de salariés, de prestataires et de composants tiers. Avant de céder, il faut s’assurer que le cédant détient bien tous les droits, y compris la propriété intellectuelle antérieure mobilisée. Le contrat s’appuie sur des déclarations et garanties de titularité et d’originalité.

Quand ce modèle ne convient pas. Si l’entreprise souhaite seulement utiliser un logiciel sans en devenir propriétaire, une licence est plus adaptée et moins coûteuse. Si le programme est mis à disposition en ligne par abonnement, la relation relève du contrat SaaS, non de la cession. Si l’objet du contrat est de faire développer un logiciel qui n’existe pas encore, un contrat de développement au forfait, prévoyant la dévolution des droits au fil de la réalisation, est préférable, car la loi prohibe la cession globale des œuvres futures. [À VÉRIFIER JURISTE : portée exacte de la prohibition de l’article L. 131-1 sur les évolutions futures d’un logiciel existant.]

Ce que dit le droit français

Le logiciel est une œuvre protégée par le droit d’auteur. Le logiciel, y compris le matériel de conception préparatoire, figure parmi les œuvres protégées énumérées à l’article L. 112-2, 13° du Code de la propriété intellectuelle. Les droits patrimoniaux spécifiques du logiciel sont définis à l’article L. 122-6 : reproduction permanente ou provisoire, traduction, adaptation, arrangement, et mise sur le marché. L’article L. 122-6-1 réserve à l’acquéreur légitime certaines facultés, comme la copie de sauvegarde et la décompilation aux fins d’interopérabilité, que la cession ne peut lui retirer.

L’écrit est exigé pour toute transmission de droits. L’article L. 131-2, alinéa 2 du Code de la propriété intellectuelle impose un écrit pour toute cession de droits d’auteur. Un accord verbal, même prouvé, ne suffit pas à opérer le transfert. Ce formalisme protège l’auteur et sécurise l’acquéreur, qui doit pouvoir démontrer l’étendue exacte de ce qu’il a acquis.

Chaque droit cédé doit être délimité. L’article L. 131-3 du Code de la propriété intellectuelle exige que la transmission des droits soit délimitée quant à son étendue, sa destination, le lieu et la durée. Un droit non mentionné est réputé non cédé, ou fait l’objet d’une interprétation restrictive au bénéfice de l’auteur. La clause de cession doit donc lister précisément les droits transférés, les territoires et la durée, en principe la durée légale de protection.

La cession globale des œuvres futures est prohibée. L’article L. 131-1 du Code de la propriété intellectuelle frappe de nullité la cession globale des œuvres futures. Un contrat ne peut donc pas transférer par avance, en bloc, les droits sur des logiciels qui n’existent pas encore. Les évolutions à venir doivent faire l’objet d’un encadrement spécifique, distinct du logiciel existant cédé.

Le forfait est admis pour le logiciel. La rémunération de la cession de droits d’auteur est en principe proportionnelle aux recettes d’exploitation, selon l’article L. 131-4 du Code de la propriété intellectuelle. Ce même article admet expressément le forfait pour la cession d’un logiciel. Un prix ferme forfaitaire est donc valable, ce qui simplifie les acquisitions de technologies.

Le droit moral du logiciel est atténué, et sa dévolution encadrée. L’article L. 121-7 du Code de la propriété intellectuelle prive l’auteur d’un logiciel, salarié ou non, du droit de s’opposer aux modifications et du droit de repentir ou de retrait sur le logiciel. L’article L. 113-9 dévolue à l’employeur les droits patrimoniaux sur les logiciels créés par ses salariés dans l’exercice de leurs fonctions. Cette dévolution ne joue toutefois pas de plein droit pour les prestataires indépendants, dont les droits doivent être expressément cédés. [À VÉRIFIER JURISTE : articulation de la dévolution L. 113-9 avec les contributions de prestataires externes et de composants open source.]

Le cédant doit garantir une jouissance paisible. Comme tout vendeur, le cédant est tenu à la garantie contre l’éviction, en application de l’article 1626 du Code civil : il répond des troubles de droit qui priveraient l’acquéreur de sa jouissance. Le contrat stipule des garanties de titularité, d’originalité, de jouissance paisible et d’éviction, qui protègent le cessionnaire contre les revendications de tiers sur le code ou ses composants.

Ce que contient ce modèle, article par article

Article 1. Définitions et objet. L’article identifie le logiciel cédé, ses versions, le code source et objet, la documentation et le matériel de conception préparatoire. Il pose que le contrat opère une cession de propriété, non une concession d’usage, afin d’écarter tout risque de requalification en licence.

Article 2. Droits cédés. Cœur du contrat, cet article liste les droits patrimoniaux transférés au sens de l’article L. 122-6 du Code de la propriété intellectuelle, et les délimite quant à leur étendue, leur destination, le territoire et la durée, conformément à l’article L. 131-3. Un droit omis est réputé non cédé.

Article 3. Assiette de la cession. L’article précise ce qui est matériellement transféré : code source commenté, code objet, jeux d’essai, documentation technique et fonctionnelle. Il peut prévoir un séquestre ou un dépôt du code chez un tiers de confiance, pour garantir la remise effective à l’acquéreur.

Article 4. Composants tiers et propriété intellectuelle antérieure. L’article traite le sort des briques préexistantes et des composants tiers intégrés au logiciel, notamment les bibliothèques open source. Il identifie les licences applicables, en particulier les licences copyleft, dont les obligations peuvent limiter la liberté d’exploitation de l’acquéreur.

Article 5. Prix et modalités de paiement. Montant de la cession, forfaitaire ou proportionnel, échéancier, et le cas échéant part variable indexée sur l’exploitation. L’article rappelle que le forfait est admis pour le logiciel, en application de l’article L. 131-4 du Code de la propriété intellectuelle.

Article 6. Déclarations et garanties du cédant. Le cédant déclare détenir l’ensemble des droits cédés, garantit l’originalité du logiciel, l’absence de contrefaçon et la régularité de la chaîne de titularité, y compris pour les contributions de salariés et de prestataires. Ces déclarations fondent la responsabilité du cédant en cas de revendication ultérieure.

Article 7. Garantie d’éviction et de jouissance paisible. Le cédant garantit l’acquéreur contre tout trouble de droit, sur le fondement de l’article 1626 du Code civil, et s’engage à le défendre en cas d’action d’un tiers. L’article peut aussi organiser la garantie des vices cachés affectant le code livré.

Article 8. Droit moral. L’article prend acte du régime atténué du droit moral sur le logiciel, tel qu’il résulte de l’article L. 121-7 du Code de la propriété intellectuelle, et de la renonciation, dans les limites permises, aux prérogatives compatibles avec l’exploitation.

Article 9. Exclusivité et non-concurrence. Le cédant s’interdit de céder à nouveau les mêmes droits et, le cas échéant, de développer ou commercialiser un logiciel concurrent reprenant les fonctions cédées, dans un périmètre et une durée proportionnés.

Article 10. Confidentialité. Le cédant, qui conserve la connaissance du code, s’engage à ne pas divulguer les éléments techniques transférés et à préserver le secret des informations échangées lors de la négociation.

Article 11. Responsabilité. Plafond et exclusions éventuelles, encadrés pour ne pas vider de sa substance la garantie d’éviction, qui reste l’obligation centrale du cédant.

Article 12. Droit applicable et litiges. Droit français, langue du contrat et attribution de compétence, le cas échéant précédées d’une étape de règlement amiable.

Les pièges à éviter

Confondre cession et licence. Rédiger le contrat comme une simple concession d’usage, alors que l’intention est un transfert de propriété, expose à une requalification qui priverait l’acquéreur des droits qu’il croyait détenir. Le vocabulaire doit être sans ambiguïté : la cession transfère la propriété des droits patrimoniaux, la licence ne fait qu’autoriser certains usages. Cette distinction structure tout le contrat.

Omettre la délimitation des droits. Un contrat qui cède les droits sans préciser leur étendue, leur destination, le territoire et la durée s’expose à l’interprétation restrictive de l’article L. 131-3 du Code de la propriété intellectuelle. Tout droit non expressément mentionné risque d’être réputé non cédé. La liste des droits transférés doit être exhaustive et explicite.

Négliger la chaîne de titularité. Céder un logiciel sans vérifier que le cédant détient réellement tous les droits, notamment ceux issus de prestataires externes ou de composants open source sous licence copyleft, expose l’acquéreur à une revendication de tiers. La dévolution des droits à l’employeur ne joue pas de plein droit pour les indépendants : leurs cessions doivent être documentées avant la vente.

Sous-estimer les composants tiers. Un logiciel qui intègre des bibliothèques open source peut être soumis à des obligations de reversement du code source ou de non-appropriation. Ignorer ces licences fait peser sur l’acquéreur un risque juridique invisible au moment de l’achat. L’audit des composants doit précéder la cession, pas la suivre.

Affaiblir la garantie d’éviction par une clause de responsabilité. Un plafond de responsabilité qui réduirait la garantie d’éviction à une somme dérisoire, face à un logiciel qui constitue l’actif principal de l’acquisition, risque d’être écarté. La garantie contre les revendications de tiers reste l’obligation centrale du cédant et ne peut être vidée de sa substance.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la désignation précise du logiciel et de ses versions, l’assiette exacte de la cession, le prix et ses modalités. Le reste du texte convient à la plupart des cessions de technologies courantes entre entreprises.

La délimitation des droits cédés mérite le plus grand soin. C’est elle qui détermine ce que l’acquéreur pourra réellement faire du logiciel. Précisez les droits transférés, les territoires visés et la durée, en principe la durée légale de protection, et n’omettez aucun droit que vous entendez acquérir, sous peine de le voir réputé non cédé.

Le traitement des composants tiers s’ajuste selon la composition réelle du logiciel. Si le programme intègre des briques open source, identifiez les licences applicables et vérifiez leur compatibilité avec l’exploitation envisagée. Si des prestataires ont contribué au code, assurez-vous que leurs droits ont bien été cédés au cédant avant la vente, et sécurisez cette chaîne par les déclarations et garanties appropriées.

Adaptez enfin la clause de rémunération à l’économie de l’opération. Un forfait convient à un rachat de technologie clairement valorisé, quand une part proportionnelle indexée sur l’exploitation future peut mieux répondre à une cession dont la valeur reste incertaine. Le forfait étant expressément admis pour le logiciel, les deux voies sont ouvertes.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni l’historique de développement du logiciel, ni la composition exacte du code, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : une cession qui s’inscrit dans une opération de rachat de société, où le transfert des droits s’articule avec la cession de titres et un audit d’acquisition ; un logiciel comportant de nombreux composants open source, dont les licences copyleft peuvent limiter la liberté d’exploitation de l’acquéreur ; et une chaîne de titularité incertaine, où des contributions de prestataires ou d’anciens salariés n’ont pas été formellement cédées.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.