Le 15 novembre 2011, la Cour de cassation a tranché un litige que beaucoup de dirigeants découvrent trop tard. Un prestataire informatique refusait de rendre à son client les codes sources qu'il avait modifiés pendant une mission de maintenance, en se prévalant de sa qualité d'auteur. Il a perdu, mais pour une raison très précise que retient l'arrêt : rien n'étant prévu au contrat concernant la propriété des codes sources modifiés, ce sont les dispositions légales qui se sont appliquées. Autrement dit, tout s'est joué sur ce qui n'avait pas été écrit.
En bref. En droit français, payer une prestation de développement ne vous rend pas propriétaire du code. Le prestataire en est l'auteur, donc le titulaire des droits, jusqu'à ce qu'une cession écrite et détaillée soit signée. Sans cette clause, vous financez un logiciel que vous ne détenez pas.
C'est contre-intuitif, et c'est pourtant la règle. J'édite mes propres logiciels depuis plusieurs années, j'ai cédé l'un d'eux à un tiers, et je développe du sur mesure pour des entreprises. J'ai vu la question de la propriété du code se poser des trois côtés de la table. Voici ce qu'il faut regarder, et surtout ce que les guides juridiques oublient de dire.
Pourquoi le paiement ne transfère aucun droit
Le code source est une œuvre de l'esprit. Il est protégé par le droit d'auteur dès sa création, sans dépôt ni formalité, et son auteur en est le titulaire initial. Cet auteur, c'est la personne qui a écrit les lignes, pas celle qui a signé le devis.
La confusion vient d'une analogie fausse avec l'achat d'un bien matériel. Quand vous achetez une machine, vous en devenez propriétaire. Quand vous commandez du développement, vous payez une prestation de service. Le paiement rémunère un travail, il n'opère pas de transfert de propriété intellectuelle. Sans acte de cession distinct, votre prestataire conserve ses droits patrimoniaux, et vous ne disposez au mieux que d'un droit d'usage implicite, étroit et fragile.
Une nuance importante sépare le salarié du prestataire. Pour un logiciel créé par un salarié dans l'exercice de ses fonctions, les droits patrimoniaux sont dévolus automatiquement à l'employeur, sans clause particulière. Pour un prestataire externe, freelance ou agence, cette dévolution automatique n'existe pas. C'est précisément pour cela que la question devient sensible dès que vous externalisez, et que l'Agence pour la Protection des Programmes rappelle qu'un contrat de cession de droits est nécessaire dès lors que l'auteur est stagiaire, prestataire, indépendant ou intérimaire.
Ce que doit contenir une clause de cession pour tenir
L'article L131-3 du Code de la propriété intellectuelle impose un formalisme que beaucoup de contrats ignorent. Chacun des droits cédés doit faire l'objet d'une mention distincte : reproduction, représentation, adaptation, modification, traduction. Le domaine d'exploitation doit être délimité quant à son étendue, sa destination, le lieu et la durée.
La conséquence est brutale pour les contrats bâclés : une formule globale du type "tous droits cédés" ne remplit pas ces conditions. Elle est régulièrement jugée inopérante. Beaucoup de dirigeants ont dans leurs archives une clause de deux lignes qu'ils croient protectrice et qui ne les protège pas.
Deux points méritent une attention particulière. Le premier est l'exclusivité : sans cession exclusive sur la partie spécifique, votre prestataire reste libre de réutiliser ce code, y compris chez un concurrent du même secteur. Le second est la remise matérielle. Une cession qui n'organise pas la livraison effective du code commenté, de la documentation et des environnements vous rend propriétaire sur le papier et dépendant dans les faits.
Une bonne nouvelle au passage : le droit d'auteur impose en principe une rémunération proportionnelle aux recettes, mais la loi prévoit une exception pour les logiciels, où la rémunération de l'auteur peut être évaluée forfaitairement. Un montant fixe dans votre devis ne fragilise donc pas la cession.
Le piège dont personne ne vous parle : la cession d'un logiciel qui n'existe pas encore
Voici le point que je n'ai vu traité nulle part dans les guides destinés aux dirigeants, alors qu'il concerne presque tous les projets menés par lots successifs.
Le Code de la propriété intellectuelle dispose que la cession globale des œuvres futures est nulle. Traduit dans votre contexte : la clause de cession signée en janvier ne couvre pas valablement des développements indéterminés que vous commanderez en octobre. Il reste possible de céder les droits sur un logiciel futur, mais à la condition qu'il soit clairement identifiable au moment de la signature.
Concrètement, si votre application métier se construit en cinq phases étalées sur deux ans, une clause unique et vague signée au départ peut laisser les phases suivantes hors périmètre. La parade est simple et coûte une signature : rattacher à chaque bon de commande ou chaque avenant une cession qui identifie précisément le livrable concerné. C'est le genre de détail qui ne se voit jamais tant que la relation est bonne, et qui devient un point de blocage le jour où vous changez de prestataire.
Sur ce sujet précis, mon article sur le cahier des charges d'une application métier explique comment découper un projet en lots identifiables, ce qui sert autant au pilotage qu'à la solidité juridique de la cession.
Propriété juridique et contrôle réel ne sont pas la même chose
C'est mon principal désaccord avec la façon dont ce sujet est traité. On vous explique longuement la théorie des droits, et on vous laisse croire que le combat est gagné une fois la clause signée. Dans la pratique des PME, le blocage n'est presque jamais juridique. Il est opérationnel.
J'ai vu des entreprises parfaitement titulaires de leurs droits se retrouver paralysées parce que le dépôt de code était hébergé sur le compte personnel du développeur, que le nom de domaine était enregistré au nom de l'agence, que les clés d'accès aux services tiers n'existaient que dans la tête d'une seule personne, ou que la base de données tournait sur un hébergement facturé au prestataire. Vous êtes propriétaire, et vous ne pouvez rien faire.
La vraie question à poser en réunion de lancement n'est donc pas seulement "à qui appartient le code", mais "si notre collaboration s'arrête demain matin, qu'est-ce que je récupère, sous quel format, et sur quels comptes". Exigez que le dépôt de code soit hébergé sur une organisation dont votre entreprise est propriétaire, que les noms de domaine et les hébergements soient à votre nom avec vous en contact administratif, et qu'un inventaire des accès et des services tiers soit tenu à jour. Ce point rejoint ce que je décris dans mon retour sur la reprise d'un logiciel développé par un autre prestataire : les dossiers les plus douloureux ne sont pas ceux où les droits manquent, ce sont ceux où les accès ont disparu.
Pour les cas sensibles, il existe une solution intermédiaire trop peu connue : l'entiercement, ou escrow. Vous déposez le code chez un tiers de confiance comme l'APP, qui vous le remet si le prestataire disparaît ou cesse d'assurer la maintenance. C'est le compromis raisonnable quand un éditeur refuse de céder son code mais que votre activité en dépend.
Vous ne posséderez jamais 100 % de votre logiciel
Autre illusion à dissiper. Même avec la meilleure clause du monde, vous ne devenez pas propriétaire de l'intégralité de ce qui tourne sur vos serveurs.
Une application moderne est assemblée à partir de centaines de briques open source : la couche de sécurité, la gestion des dates, l'envoi des e-mails, le rendu des documents. Le rapport OSSRA 2026 de Black Duck, établi sur l'analyse de 947 bases de code réparties dans dix-sept secteurs, relève que 98 % d'entre elles contiennent des composants open source, avec un nombre moyen de composants en hausse de 30 % sur un an. Ces briques ne vous appartiennent pas et n'appartiennent pas davantage à votre prestataire. Elles sont utilisées sous licence.
Ce que vous achetez et faites céder, c'est la partie spécifique : votre logique métier, vos écrans, vos règles de gestion, l'assemblage. C'est la seule chose qui ait de la valeur pour vous, et c'est aussi la seule qu'un concurrent pourrait vouloir. Réclamer la propriété du reste n'a aucun sens.
En revanche, deux exigences sont légitimes et rarement formulées. Demandez la liste des composants et de leurs licences, parce que certaines licences dites copyleft imposent des obligations lourdes si vous distribuez le logiciel. Et demandez une garantie que le prestataire est bien titulaire de ce qu'il vous cède : cette garantie d'éviction découle du Code civil, et elle vous couvre si un tiers venait revendiquer une partie du code.
Quatre situations, et ce que vous détenez vraiment
| Ce que dit votre contrat | Ce que vous détenez | Ce que ça change en pratique |
|---|---|---|
| Aucune clause de cession | Rien, sinon un droit d'usage fragile | Vous ne pouvez ni faire modifier le logiciel par un tiers, ni le revendre |
| Formule vague, type tous droits cédés | Une cession contestable au regard du L131-3 | Tient tant que personne ne conteste, s'effondre en cas de litige ou d'audit |
| Cession détaillée mais sans remise du code | Les droits, pas la matière | Vous êtes propriétaire et dépendant, la maintenance reste captive |
| Cession détaillée, exclusive, avec remise et accès à votre nom | Le contrôle complet | Vous changez de prestataire quand vous voulez, la valeur reste chez vous |
| Abonnement à un logiciel du marché | Un droit d'usage assumé | Vous ne possédez rien, et ce n'est pas forcément un problème |
Le cas où réclamer la propriété du code est une erreur
Cette dernière ligne mérite un développement, parce qu'elle va contre le réflexe naturel.
J'édite plusieurs logiciels en abonnement, dont Simply Spa pour les spas et les instituts, Simply Resa pour la réservation, Geko pour la gestion de stock et Postwa pour la publication sur les réseaux. Aucun de mes clients ne possède ces codes sources, et aucun n'en a besoin. Ils paient l'usage d'un outil mutualisé qui évolue en continu, dont les corrections profitent à tout le monde et dont ils n'assument ni l'hébergement, ni la sécurité, ni la dette technique. Vouloir la propriété du code d'un logiciel mutualisé revient à demander qu'on vous vende un exemplaire figé d'un produit vivant, avec la charge de le maintenir seul ensuite.
La propriété du code se justifie quand le logiciel constitue un avantage concurrentiel, quand vos règles de gestion sont trop particulières pour un produit du marché, ou quand la valeur de votre entreprise repose dessus. Dans ces cas, elle n'est pas négociable. C'est le raisonnement que je détaille dans la comparaison entre logiciel sur mesure et logiciel du marché, et c'est aussi la logique qui structure mon accompagnement en développement de SaaS sur mesure.
Une transparence s'impose ici, parce qu'elle m'a coûté une clarification en cours de projet. Mes premiers contrats de développement spécifique ne distinguaient pas assez nettement le socle technique que je réutilise d'un client à l'autre, comme l'authentification ou la facturation, et la partie réellement propre au client. Un client m'a demandé si la cession couvrait tout, et ma réponse honnête était non : le socle reste à moi, sous licence d'utilisation perpétuelle pour lui, et le spécifique lui est cédé en exclusivité. C'est aujourd'hui écrit noir sur blanc au devis. Un prestataire qui vous répond que "tout est à vous" sans distinguer ces deux couches vous ment ou n'a pas réfléchi à la question. Les deux sont mauvais signe.
Mon verdict
Considérez que le code ne vous appartient pas tant que vous n'avez pas trois choses réunies : une clause de cession qui énumère les droits, l'exclusivité sur la partie spécifique, et vos propres accès aux dépôts, hébergements et noms de domaine. Un seul de ces trois éléments manquant suffit à vous rendre dépendant.
Le meilleur moment pour poser ces questions, c'est avant la signature, quand la relation est bonne et que la demande passe pour du sérieux plutôt que pour de la méfiance. Un prestataire compétent vous répondra sans détour, parce qu'il a déjà réfléchi à ces sujets et qu'il applique la même rigueur à ses propres actifs. Une régularisation obtenue après coup dépend en revanche du bon vouloir de quelqu'un qui n'a plus rien à gagner à vous la signer.
Ce sujet touche à la fois au droit des contrats et à la propriété intellectuelle. Les principes exposés ici sont ceux du Code de la propriété intellectuelle, mais la rédaction d'une clause qui tient devant un juge relève d'un avocat spécialisé, surtout si un litige est déjà en germe. Si vous préparez un projet de logiciel métier et que vous voulez que ces questions soient cadrées dès le devis, parlons de votre projet et je vous montrerai comment je formalise la cession et la remise des accès.
Questions fréquentes
Le code que j'ai payé m'appartient-il automatiquement ?
Non. Le paiement rémunère une prestation, il n'opère pas de transfert de droits d'auteur. Le prestataire reste titulaire des droits patrimoniaux sur le code qu'il a écrit tant qu'aucune cession écrite et conforme à l'article L131-3 du Code de la propriété intellectuelle n'a été signée. Sans cette clause, vous disposez au mieux d'un droit d'usage implicite très limité.
Une clause disant tous droits cédés suffit-elle ?
Non, elle est fragile. L'article L131-3 exige que chacun des droits cédés fasse l'objet d'une mention distincte et que le domaine d'exploitation soit délimité quant à son étendue, sa destination, le lieu et la durée. Une formule globale ne remplit pas ces conditions et se retrouve régulièrement écartée. Faites énumérer les droits un par un.
Mon prestataire peut-il réutiliser mon code chez un concurrent ?
Cela dépend entièrement du contrat. En l'absence de cession exclusive, il conserve ses droits sur le code et peut le réutiliser, y compris pour une entreprise de votre secteur. Il faut distinguer le socle technique générique, dont la réutilisation est normale, de la partie spécifique à votre activité, qui doit être cédée en exclusivité.
Que faire si mon prestataire refuse de céder le code ?
Deux cas. S'il s'agit d'un logiciel en abonnement mutualisé, ce refus est normal et vous n'avez pas besoin de la propriété. S'il s'agit d'un développement spécifique que vous avez financé, négociez à défaut un entiercement auprès d'un tiers de confiance, qui vous remettra le code si le prestataire disparaît ou cesse la maintenance, et assurez-vous au minimum de détenir vous-même les accès à l'hébergement et aux noms de domaine.
Photo : Vitaly Gariev sur Unsplash
