À qui appartient le code ? Ce que vos contrats doivent dire
Payer un développement ne vous en rend pas propriétaire. En droit français, la cession de droits doit être écrite, détaillée et signée : sans quoi le code reste à son auteur.
Sommaire
C’est une conversation que nous avons plusieurs fois par an, et qui commence toujours de la même manière : « évidemment que le code est à nous, on l’a payé . »
Non. En droit français, payer une prestation de développement n’emporte aucun transfert de propriété sur le code produit. Ce n’est pas une subtilité de juriste : c’est le point qui décide de votre capacité à changer de prestataire, à revendre votre entreprise, ou simplement à faire corriger un bogue par quelqu’un d’autre.
Le code est une œuvre, pas une marchandise
Un logiciel — et le code source d’un site en est un — est protégé par le droit d’auteur. Il naît propriété de celui qui l’écrit, au moment où il l’écrit, sans dépôt ni formalité.
La conséquence est mécanique : la cession des droits doit être expresse et écrite. L’article L. 131-3 du code de la propriété intellectuelle exige que chacun des droits cédés soit mentionné distinctement, et que le domaine d’exploitation soit délimité quant à son étendue, sa destination, son lieu et sa durée.
Une phrase du type « le client sera propriétaire des livrables » ne répond à aucune de ces exigences. Elle rassure au moment de la signature, et ne vaut rien le jour où elle sert.
L’exception salariée, et ses trous
Il existe une exception, propre au logiciel et fort utile : les droits patrimoniaux sur les logiciels créés par un salarié dans l’exercice de ses fonctions sont dévolus à l’employeur, automatiquement, sans clause particulière. C’est l’article L. 113-9 du même code.
C’est cette règle qui fait qu’une entreprise ne se pose jamais la question pour son équipe interne. C’est aussi elle qui crée un angle mort, parce qu’elle vise les salariés, et eux seuls. Quatre situations n’en relèvent pas, et se rencontrent constamment :
- le prestataire indépendant, quelle que soit la durée de la mission ;
- le stagiaire, qui n’est pas titulaire d’un contrat de travail ;
- le dirigeant non salarié, y compris fondateur ;
- le bénévole d’une association, ou l’ami qui a rendu service au démarrage.
Ce dernier cas est le plus fréquent dans les jeunes entreprises, et le plus embarrassant lors d’une levée de fonds ou d’une cession : l’auditeur demande la chaîne de titularité du code, et découvre qu’une partie a été écrite par un cofondateur avant sa nomination, ou par un ami qui n’a jamais rien signé. Le sujet remonte alors très haut, très vite — nous l’avons évoqué à propos de la due diligence technique.
Ce que doit contenir la clause
Une clause utile tient en une page. Elle comporte six éléments.
1. L’objet, identifié. Pas « les livrables », mais le code source, les scripts de déploiement, la documentation technique, les schémas de base de données, les maquettes et les fichiers sources graphiques. Ce qui n’est pas nommé n’est pas cédé.
2. L’énumération des droits. Reproduction, représentation, adaptation, traduction, correction, distribution. Le droit d’adaptation est le plus important de la liste et le plus souvent absent : sans lui, vous possédez un code que vous ne pouvez faire modifier par personne d’autre. La cession devient alors décorative.
3. La délimitation. Étendue, destination, lieu, durée. Pour un logiciel d’entreprise, la formulation usuelle couvre tous supports, pour le monde entier, pour la durée légale des droits.
4. Le caractère exclusif, ou non. Une cession exclusive interdit au prestataire de réutiliser le code cédé ailleurs. C’est légitime pour ce qui est spécifique à votre métier ; c’est irréaliste pour les briques génériques dont vit toute agence. La bonne clause distingue les deux, plutôt que de prétendre tout emporter.
5. La garantie. Le prestataire garantit qu’il détient les droits qu’il cède, qu’il n’a pas repris de code d’un client précédent, et qu’il vous couvre en cas de revendication d’un tiers. C’est cette ligne qui vous protège de ce que vous ne pouvez pas vérifier.
6. La chaîne complète. Si le prestataire a lui-même sous-traité, il doit garantir avoir obtenu de ses propres intervenants les droits qu’il vous cède. Un maillon manquant casse toute la chaîne, et il est en général invisible.
Ce que la cession ne couvrira jamais
Un prestataire ne peut céder que ce qu’il détient. Trois catégories restent en dehors, et doivent être identifiées :
Les composants libres. Tout projet moderne en contient des dizaines. Ils restent régis par leur propre licence, et certaines imposent des obligations qui peuvent heurter votre modèle : obligation de publier les modifications, voire de publier le code d’un service exploité en ligne. Exigez l’inventaire des dépendances et de leurs licences. C’est un fichier, il se produit en une commande, et son absence est en soi un signal.
Les briques maison du prestataire. Presque toutes les agences ont leur socle, réutilisé de projet en projet. C’est sain — cela vous fait payer moins cher. Mais il ne vous est pas cédé : il vous est concédé sous licence. Trois questions à poser, et à faire écrire : cette licence est-elle perpétuelle, non exclusive, et transférable si vous vendez votre entreprise ?
Les services tiers. Une plateforme d’envoi de courriels, un service de paiement, un moteur de recherche hébergé : vous n’en possédez rien. Vous en dépendez, et ces dépendances doivent être listées quelque part.
Le droit moral, en deux phrases
L’auteur conserve un droit moral, incessible. Pour les logiciels, l’article L. 121-7 l’a heureusement réduit à presque rien : l’auteur ne peut ni s’opposer aux modifications de son programme, sauf atteinte à son honneur, ni exercer de droit de repentir.
Retenez simplement qu’un développeur peut demander à être mentionné comme auteur, et qu’il ne peut pas vous empêcher de faire évoluer le code. C’est tout ce que ce sujet mérite dans une négociation.
Le livrable, c’est le code, pas l’accès
Dernière précaution, la plus concrète : une cession sans remise n’est qu’une promesse.
Le contrat doit prévoir la remise effective du code source complet, dans un dépôt dont vous êtes propriétaire, avec son historique, la documentation de déploiement et les éléments de configuration. Pas un accès à un dépôt appartenant au prestataire. Pas une archive envoyée à la fin, quand on y pensera.
La différence se mesure le jour où le prestataire ne répond plus : nous avons décrit ailleurs la marche à suivre, et elle est nettement plus courte quand le code est déjà chez vous. C’est aussi la raison pour laquelle nous ouvrons les comptes au nom de nos clients, hébergement compris.
Ce que nous signons, nous
Pour éviter tout malentendu, voici notre pratique. Nos contrats prévoient la cession exclusive des droits patrimoniaux sur les développements spécifiques, incluant l’adaptation, pour la durée légale et sans limitation de territoire. Nos briques génériques sont concédées sous licence perpétuelle, non exclusive et transférable. L’inventaire des dépendances libres est livré avec le projet. Et le code vit, dès le premier jour, dans un dépôt appartenant au client.
Aucune de ces lignes n’est héroïque. Elles ont surtout un mérite : elles rendent la question de la propriété du code inintéressante, ce qui est exactement l’objectif.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préféréesQuestions fréquentes
Payer un développement suffit-il à en devenir propriétaire ?
Non. Le code source est une œuvre protégée par le droit d'auteur, et le paiement d'une prestation n'emporte aucune cession de droits. Sans clause écrite, le prestataire reste titulaire des droits patrimoniaux ; le client dispose au mieux d'un droit d'usage conforme à la destination convenue, ce qui est très en deçà de ce qu'il croit avoir acheté.
Le code écrit par un salarié appartient-il à l'entreprise ?
Oui, et c'est une exception propre au logiciel : les droits patrimoniaux sur les logiciels créés par un salarié dans l'exercice de ses fonctions sont dévolus à l'employeur, sans clause particulière. Attention toutefois : cette règle vise les salariés. Un stagiaire, un alternant selon son statut, un dirigeant non salarié ou un prestataire n'en relèvent pas.
Que doit contenir une clause de cession valable ?
L'identification précise de ce qui est cédé, l'énumération des droits transmis — reproduction, représentation, adaptation, traduction, correction, distribution — et la délimitation de l'étendue, de la destination, du lieu et de la durée. Une formule générale du type « le client sera propriétaire du livrable » ne satisfait pas ces exigences et se retourne contre celui qui l'a acceptée.
Le droit d'adaptation est-il vraiment indispensable ?
C'est le droit le plus important de la liste, et le plus souvent oublié. Sans lui, vous possédez un code que vous ne pouvez pas faire modifier par quelqu'un d'autre. Concrètement, vous restez lié à votre prestataire pour toute évolution — ce qui vide la cession de son intérêt.
La cession couvre-t-elle les composants open source utilisés ?
Non, et c'est normal : le prestataire ne peut céder que ce qu'il détient. Les bibliothèques tierces restent régies par leur propre licence. Ce qu'il faut exiger, c'est leur inventaire — car certaines licences imposent des obligations qui peuvent être incompatibles avec votre modèle économique, en particulier pour un logiciel exploité en ligne.
Le prestataire peut-il réutiliser le code chez un autre client ?
Cela dépend de ce qui a été écrit. Une cession exclusive le lui interdit sur les développements spécifiques. En revanche, la plupart des prestataires réutilisent légitimement leurs propres briques génériques : la question n'est pas de l'interdire, mais de savoir lesquelles, et sous quelle licence elles vous sont concédées.
