Cession de logiciel : titularité, périmètre et garanties

Céder un logiciel ne revient pas à remettre une copie du code source. L’opération doit identifier le titulaire, les droits transférés, les composants tiers, les livrables, les environnements nécessaires et les obligations qui subsistent après la cession.

Auditer la chaîne de titularité

Recensez les auteurs, salariés, prestataires, stagiaires, dirigeants et partenaires ayant contribué au logiciel ou à sa documentation. L’article L. 113-9 dévolue en principe à l’employeur les droits patrimoniaux sur les logiciels et leur documentation créés par les employés dans l’exercice de leurs fonctions ou selon ses instructions, sauf dispositions ou stipulations contraires.

Cette règle ne couvre pas automatiquement toutes les contributions externes. Vérifiez les contrats de prestation, les apports antérieurs, les acquisitions, les projets collaboratifs et les éléments réutilisés depuis d’autres produits.

Pour les dirigeants non salariés, les fondateurs intervenus avant la constitution de la société et les consultants, ne déduisez pas la titularité de la seule règle applicable aux employés. Reprenez chaque contribution et son contrat afin d’identifier le titulaire et le périmètre des droits documentés. L’article L. 113-9 établit la dévolution concernant les logiciels créés par les employés dans les conditions qu’il précise ; l’analyse des autres situations doit donc rester attachée aux pièces disponibles.

Pour les prestataires et sociétés externes, l’article L. 131-3 du CPI prévoit, pour les cessions de droits d’auteur qui y sont soumises, une mention distincte de chaque droit cédé et une délimitation par étendue, destination, lieu et durée. La portée exacte de cette exigence dépend du type d’œuvre et de contrat en cause et connaît des tempéraments propres au logiciel : mieux vaut donc examiner la nature précise de l’accord avant d’en tirer une conclusion univoque.

Cartographier les composants et licences

Établissez une nomenclature des dépendances : bibliothèques open source, composants commerciaux, API, modèles, polices, contenus, bases de données, outils de build et services cloud. Pour chacun, conservez la version, la licence, les avis requis et les conditions de redistribution ou d’accès.

Un acquéreur doit savoir quels éléments peuvent être cédés, lesquels restent sous licence et lesquels nécessitent un nouveau contrat. Le code propriétaire ne peut pas être évalué correctement si les dépendances indispensables restent inconnues. Le guide sur les mécanismes de protection du logiciel aide à distinguer les droits et preuves en présence.

Signalez les composants dont la licence encadre la redistribution ou l’accès. Le packet ne contient pas le texte de licences particulières : il ne permet donc pas d’énoncer ici leurs obligations propres. L’audit doit rester factuel et consigner, pour chaque dépendance, sa version, sa licence, les avis requis et les conditions relevées dans les documents applicables. Cette lecture composant par composant complète la nomenclature sans présumer d’une conséquence identique pour toutes les licences.

Classer chaque élément avant la négociation

Délimiter les droits cédés

L’acte mentionne distinctement les droits transférés et délimite leur domaine d’exploitation quant à l’étendue, la destination, le lieu et la durée. Pour le logiciel, les droits d’exploitation couvrent notamment la reproduction, l’adaptation et la mise sur le marché dans les conditions prévues par le Code de la propriété intellectuelle.

Précisez les versions, modules, branches, interfaces, documentations et éléments préparatoires concernés. Indiquez si la cession inclut les évolutions futures, les correctifs en cours, les marques, noms de domaine, brevets, données ou savoir-faire associés. Lorsque la chronologie des versions est déterminante, le guide sur le dépôt de logiciel et l’horodatage rappelle ce que ces preuves permettent — ou non — d’établir.

Organiser le transfert technique

Listez les dépôts, historiques, tickets, clés, scripts, procédures de déploiement, tests, documentation d’architecture, sauvegardes et accès à remettre. Définissez un processus sécurisé pour les secrets et identifiants ; ils ne doivent pas être copiés sans contrôle dans une archive de transfert.

Prévoyez la période d’assistance, les personnes disponibles, les critères de recette et la gestion des incidents découverts pendant la transition. Un transfert juridique sans capacité de compilation, déploiement ou maintenance peut perdre une grande partie de son intérêt économique. La pratique consiste souvent, à titre éditorial, à identifier de part et d’autre un référent technique et un mode d’échange convenu pour les questions bloquantes ; les modalités précises restent à la main des parties.

Vérifier que le logiciel reste exploitable

Avant la recette, faites reproduire les opérations essentielles depuis un environnement maîtrisé : récupération du dépôt, installation des dépendances, compilation, tests et déploiement. L’objectif n’est pas seulement de recevoir des fichiers, mais de vérifier que les éléments remis permettent effectivement la continuité du produit.

Adapter les garanties au résultat de l’audit

Les garanties peuvent porter sur la titularité, les pouvoirs, les licences révélées, l’absence de sûretés connues et la remise des éléments convenus. Elles doivent être cohérentes avec le niveau d’audit et les limites connues.

Répartissez aussi les responsabilités pour les réclamations de tiers, les vulnérabilités, la protection des données, les mises à jour et les contrats clients. Pour les services externes en cours, déterminez si le contrat peut être transféré ou s’il faut obtenir un nouvel accord. Pour préparer l’acte et l’audit, consultez notre service de cession de logiciel.