À qui appartient le code de votre logiciel ? Pas à vous, sauf si c'est écrit

« J’ai payé, donc c’est à moi. » Appliquée au logiciel, cette évidence du sens commun est juridiquement fausse, et la découverte se fait rarement au bon moment : elle attend la levée de fonds, la revente ou le conflit avec le prestataire. Cet article pose la règle, du point de vue inhabituel d’un studio qui écrit du code pour les autres : nous avons tout intérêt à ce que vous sachiez exactement ce que vous achetez.

Que dit le droit français sur la propriété du code ?

Le principe tient en deux phrases. Un logiciel original est protégé par le droit d’auteur, qui naît sur la tête de celui qui l’écrit, sans dépôt ni formalité (la propriété des codes sources, Légavox). Et commander ce logiciel n’y change rien : le code de la propriété intellectuelle pose que l’existence d’un contrat de commande n’emporte aucune dérogation au droit d’auteur, autrement dit, le paiement rémunère la prestation, pas le transfert de la propriété intellectuelle (Atias Avocats, propriété du code source d’un prestataire).

La conséquence pratique est brutale : sans acte de cession écrit, l’entreprise qui a financé le développement ne détient qu’un droit d’usage implicite, aux contours flous, sur l’outil qui fait parfois toute sa valeur. Elle peut l’utiliser ; modifier, faire évoluer par un autre prestataire, revendre ou apporter la technologie à une opération financière relèvent d’un autre registre, celui du titulaire des droits. Une exception existe pour les salariés (les droits sur un logiciel créé par un salarié dans ses fonctions reviennent à l’employeur), mais elle ne couvre ni les freelances, ni les agences, ni les studios : exactement les profils qui construisent les logiciels des PME et des startups.

Le tableau des contributeurs mérite d’être complet, parce que la chaîne des droits casse toujours au maillon oublié. Le salarié est le cas simple : les droits sur le logiciel créé dans ses fonctions reviennent à l’employeur. Tout le reste demande un écrit : le freelance, l’agence, le stagiaire (qui n’est pas un salarié), le cofondateur qui a codé avant la création de la société (ses lignes lui appartiennent personnellement tant qu’il ne les a pas apportées ou cédées), et même l’ami qui « a donné un coup de main » un week-end. Chaque contributeur passé est un maillon, et la solidité de la chaîne se mesure à son maillon le plus flou.

Pourquoi le problème reste-t-il invisible si longtemps ?

Parce qu’au quotidien, rien ne le trahit. Le logiciel tourne, les factures sont payées, le prestataire répond : la question de la titularité des droits n’a aucune raison d’émerger. Elle émerge aux trois moments où l’entreprise joue gros, et à ces moments-là seulement.

La due diligence d’abord : tout audit sérieux préalable à une levée ou un rachat vérifie la chaîne des droits, et découvrir que l’actif principal de la société ne lui appartient pas juridiquement transforme la négociation, c’est l’un des vices bloquants que nous décrivons dans notre grille de due diligence technique. Le conflit ensuite : un prestataire mécontent qui détient les droits détient un levier, et la régularisation se négocie alors au prix fort. Le changement de prestataire enfin : reprendre un logiciel dont on ne possède pas les droits ajoute un verrou juridique à un problème déjà technique, le scénario complet est dans que faire d’un logiciel sans développeur.

Le cas classique que ce mécanisme produit : une société fait développer son produit par un freelance en 2023, trois factures payées, aucune clause de cession. En 2026, un fonds entre en due diligence, l’avocat demande la chaîne des droits, et la levée se suspend le temps de retrouver le freelance, parti à l’étranger, pour lui faire signer une cession qu’il monnaye. Rien d’illégal nulle part : juste un actif qui n’avait jamais été transféré.

Quelles clauses exiger dans un contrat de développement ?

Six points font une cession solide, et ils se vérifient avant de signer :

1. Une cession expresse, écrite, distincte de la prestation. La cession ne se présume jamais : une formule vague type « le client devient propriétaire des livrables » est fragile. La clause doit dire explicitement que le prestataire cède ses droits patrimoniaux sur le code.
2. L’énumération de chaque droit cédé. Le formalisme de l’article L.131-3 du code de la propriété intellectuelle exige que reproduction, représentation, adaptation, modification et traduction soient mentionnées distinctement, avec un domaine d’exploitation délimité en étendue, destination, lieu et durée. C’est la première cause de nullité des cessions mal rédigées.
3. La livraison effective du code source et de ses accès. Une cession sans le code est un titre sans la chose : dépôt, historique, documentation et procédures de déploiement font partie du livrable.
4. Le sort des briques tierces et des licences. Aucun logiciel moderne n’est écrit à 100 % par son prestataire : les dépendances open source restent sous leurs licences propres, qui doivent être compatibles avec votre usage commercial. La clause distingue ce qui est cédé (le code spécifique) de ce qui est concédé (les briques standard).
5. La cession au fil de l’eau, pas à la fin. Une cession « à la recette finale » laisse un vide pendant tout le projet, et un moyen de pression en cas de désaccord. La bonne pratique : les droits sont cédés au fur et à mesure des paiements.
6. La réversibilité organisée. Le droit de partir ne vaut que si la pratique suit : documentation à jour, environnement reproductible, assistance de transition prévue au contrat.

Où en êtes-vous, concrètement ? Les 4 situations types

La quasi-totalité des entreprises se reconnaît dans l’une de ces quatre situations, chacune avec ses droits réels et son geste prioritaire :

Trois montages, enfin, doivent déclencher une alarme immédiate quand ils vous sont proposés. La « licence d’utilisation » mensuelle sur un développement pourtant payé sur mesure : vous financez un actif dont vous devenez locataire. Le code hébergé exclusivement sur les comptes du prestataire, « pour simplifier » : chaque jour qui passe renforce sa position de fait, quelle que soit votre position de droit. Et la sous-traitance en cascade non déclarée : votre agence fait développer par des indépendants qu’elle n’a pas fait signer, et la chaîne des droits se brise à un maillon que vous ne voyez même pas. Dans les trois cas, la question à poser est la même : « qui détient quoi, et où est-ce écrit ? ». La gêne dans la réponse est une information.

Comment ça se passe chez un studio sérieux ?

La réponse tient en une pratique vérifiable : le dépôt de code est créé au nom du client dès le premier jour, et chaque commit lui appartient au fil des paiements, cession écrite à l’appui. Pas de « vous aurez tout à la fin », pas de code hébergé sur les comptes du prestataire, pas de zone grise : le client peut, à tout moment, partir avec l’intégralité de son actif et le confier à qui il veut. C’est notre pratique, elle est posée dans notre méthode, et elle vaut engagement : un prestataire qui organise votre dépendance vous vend une laisse, pas un logiciel.

L’honnêteté impose de tracer aussi la limite de l’autre côté, parce qu’elle est légitime : un studio ne cède pas son savoir-faire générique. Les briques standard qui accélèrent tous les projets (authentification, API, droits, outillage) vivent chez nous dans un socle open source, FastEdgy, sous une licence qui vous en garantit l’usage sans jamais vous enfermer : c’est la façon propre de résoudre la tension entre « tout céder » et « réinventer à chaque projet ». Ce que vous payez vous appartient ; ce qui existait avant vous reste ouvert à tous. Méfiez-vous des montages où le générique est propriétaire et fermé : c’est la dépendance déguisée en accélérateur. Et si votre projet passe par un montage en dev for equity, le principe s’inverse en miroir et se pose au pacte : la répartition des droits se décide à l’entrée, jamais en cours de route.

Que faire si vous êtes déjà dans le flou ?

Auditer, puis régulariser, dans cet ordre et sans attendre d’en avoir besoin. L’audit prend quelques heures : rassembler les contrats et devis de chaque contributeur passé (agences, freelances, parfois un ancien associé), et vérifier pour chacun l’existence d’une clause de cession conforme. Le résultat est une liste de trous, généralement courte, souvent complète.

L’avenant type tient en deux pages : identification du logiciel et des contributions, énumération des droits cédés conformément au formalisme, territoire et durée, et une contrepartie même symbolique pour asseoir l’acte. Votre avocat le rédige en quelques heures une fois l’inventaire fait ; le coût est sans commune mesure avec l’enjeu.

La régularisation se joue ensuite sur une vérité simple : tant que les relations sont bonnes, un avenant de cession se signe facilement, parfois contre un montant symbolique. C’est le même acte qui, exigé en urgence au milieu d’une levée de fonds par un prestataire devenu incontournable, se négocie en position de faiblesse. La propriété du code rejoint ici son jumeau organisationnel, la dépendance aux personnes : nous avons montré dans notre article sur le bus factor que la valeur d’un actif logiciel est ce qui reste quand les gens changent. Le droit et la pratique se répondent : cession écrite d’un côté, connaissance transférable de l’autre, et votre logiciel devient réellement à vous.

Pour les logiciels les plus critiques, un étage de protection supplémentaire existe : le dépôt du code auprès d’un tiers de confiance (séquestre ou entiercement), qui garantit l’accès aux sources dans des cas définis au contrat, comme la défaillance du prestataire. C’est une ceinture de sécurité utile dans les relations longues, mais elle ne remplace jamais la cession : elle garantit l’accès à la chose, pas la titularité du droit.

Un doute sur votre propre situation ? Apportez vos contrats à la conversation : 30 minutes en visio avec un fondateur suffisent pour repérer les trous dans la chaîne des droits et prioriser la régularisation, avec l’aide de votre avocat pour la rédaction. Parlons-en pendant que c’est un détail administratif, pas quand c’est devenu le point de blocage d’une levée.