C'est l'une des questions les plus fréquentes qu'on nous pose, et l'une des plus mal comprises. Beaucoup de dirigeants découvrent le sujet le jour où ils veulent changer de prestataire, et s'aperçoivent que l'application qu'ils utilisent depuis trois ans ne leur appartient pas vraiment.
Ce guide décrit le cadre français du droit d'auteur appliqué au logiciel. Il ne remplace pas l'avis d'un avocat sur votre contrat : si les montants en jeu sont importants, faites relire votre clause de cession par un spécialiste en propriété intellectuelle.
Le principe : le code appartient d'abord à celui qui l'écrit
Un logiciel est une œuvre de l'esprit protégée par le droit d'auteur, au titre des articles L.111-1 et L.112-2 du Code de la propriété intellectuelle. Cette protection naît de la création elle-même, sans dépôt ni formalité. Le titulaire initial des droits est l'auteur, c'est-à-dire le prestataire, l'agence ou le freelance qui a écrit le code.
Autrement dit, le point de départ n'est pas neutre : par défaut, le code n'est pas à vous. Il le devient uniquement si un acte le prévoit.
Payer une facture ne vaut pas cession
C'est le contresens le plus répandu. Le paiement rémunère une prestation de service, pas un transfert de propriété intellectuelle. En l'absence d'un acte de cession distinct, le prestataire conserve ses droits patrimoniaux, et le client ne dispose que d'un droit d'usage implicite, dont l'étendue est étroite et incertaine.
Concrètement, ce droit d'usage restreint peut ne pas couvrir la modification du code, sa réutilisation sur un autre projet, ou sa transmission à un autre prestataire. Exactement les trois choses dont vous aurez besoin le jour où la relation s'arrête.
Salarié et prestataire : deux régimes opposés
La confusion vient souvent de là. Pour un logiciel créé par un salarié dans l'exercice de ses fonctions, l'article L.113-9 du CPI prévoit une dévolution automatique des droits patrimoniaux à l'employeur. Aucun contrat particulier n'est nécessaire.
Cette dévolution automatique n'existe pas pour un prestataire externe. Un développeur indépendant ou une agence n'est pas votre salarié : la règle qui vous rassure dans un cas ne s'applique pas du tout dans l'autre.
Ce que doit contenir une clause de cession valable
L'article L.131-3 du CPI impose un formalisme strict. Une cession n'est valable que si elle est écrite et si elle précise, point par point :
- L'énumération distincte de chaque droit cédé : reproduction, représentation, adaptation, modification, traduction.
- L'étendue de l'exploitation autorisée.
- Sa destination, c'est-à-dire les usages couverts.
- Le territoire sur lequel elle s'applique.
- La durée de la cession.
Point décisif : une formule générique du type « tous droits cédés » est jugée insuffisante par la jurisprudence. Une clause qui se contente de cette mention peut être privée d'effet, ce qui vous laisse dans la situation exacte que vous pensiez avoir évitée.
Une clause de cession qui tient en une ligne est presque toujours une clause qui ne tient pas.
Les questions à poser avant de signer
- Le contrat contient-il une clause de cession, et énumère-t-elle chaque droit séparément ?
- La cession couvre-t-elle explicitement le droit de modifier le code et d'en faire des œuvres dérivées ?
- Est-elle consentie pour la durée des droits et pour le monde entier, ou limitée ?
- La cession est-elle conditionnée au paiement intégral ? C'est légitime, mais vous devez le savoir.
- Que se passe-t-il pour les briques réutilisables du prestataire, ses composants maison, ses bibliothèques internes ?
Cette dernière question est la plus négligée. Beaucoup d'agences construisent sur un socle interne qu'elles ne cèdent pas, et qu'elles vous concèdent seulement sous licence. Ce n'est pas illégitime, mais c'est très différent d'une cession : le jour où vous partez, vous emportez une application qui ne fonctionne pas sans une brique qui ne vous appartient pas.
Au-delà du contrat : ce qui rend une cession réelle
Une cession juridiquement parfaite ne sert à rien si vous n'êtes pas en mesure d'exercer vos droits. La propriété du code est une condition nécessaire, pas suffisante. Pour qu'elle soit effective, il faut aussi que vous disposiez de la matière.
- Le code source complet, dans un dépôt dont vous êtes propriétaire, pas seulement une copie envoyée à la fin.
- La documentation d'installation et d'exploitation, suffisante pour qu'une autre équipe reprenne.
- Les accès : hébergement, base de données, noms de domaine, services tiers, tous à votre nom.
- La liste des dépendances externes et de leurs licences, avec leur coût.
- Les données, exportables dans un format ouvert.
Le test le plus honnête est celui-ci : si votre prestataire disparaissait demain, une autre équipe pourrait-elle reprendre l'application sans lui parler ? Si la réponse est non, la question de la propriété du code est déjà tranchée dans les faits, quel que soit ce que dit le contrat.
Notre position
Chez Olidian, vous repartez avec le code, la documentation et les accès, sans dépendance cachée à notre atelier. Vous pouvez faire évoluer votre application avec votre équipe, avec un autre prestataire, ou avec nous dans le cadre du Run : c'est un choix que vous gardez, pas une contrainte que vous subissez.
Nous ne prétendons pas que ce soit une position rare par générosité. C'est simplement la seule qui nous oblige à mériter le renouvellement plutôt qu'à le verrouiller.