Propriété du codeContratSur-mesureChoisir un prestataire
À qui appartient le code source d'un logiciel sur mesure ?
6 min de lecture
Payer le développement d'un logiciel ne suffit pas, en droit français, à en posséder le code source. Sauf contrat de travail, les droits d'auteur restent à celui qui a écrit le code tant qu'un contrat écrit ne les cède pas expressément. Ce qui vous revient se lit donc dans le contrat, droit par droit, et c'est avant de signer qu'il faut le vérifier.
Cet article explique le cadre général, ce qu'un contrat sérieux doit préciser, et la position de LPR Studio. Il ne remplace pas un conseil juridique : un contrat de développement se fait relire par un avocat.
Ce que dit le droit français
Le logiciel est protégé par le droit d'auteur, comme un texte. L'article L122-6 du code de la propriété intellectuelle donne à son auteur le droit d'autoriser trois choses : la reproduction du logiciel, sa traduction ou son adaptation (donc sa modification), et sa mise sur le marché, location comprise. Qui détient ces droits décide de ce que l'on peut faire du code.
Deux situations très différentes coexistent.
Le code écrit par vos salariés. L'article L113-9 prévoit que les droits patrimoniaux sur un logiciel créé par des employés dans l'exercice de leurs fonctions, ou d'après les instructions de l'employeur, sont dévolus à l'employeur, sauf stipulation contraire. Une équipe interne produit donc du code qui vous appartient.
Le code écrit par un prestataire. Cette règle ne s'applique pas à une agence, à un studio ou à un freelance : ils ne sont pas vos salariés. Leurs droits ne vous sont transmis que par un contrat. L'article L131-3 du même code exige qu'une cession d'œuvre mentionne distinctement chaque droit cédé et délimite son exploitation quant à son étendue, sa destination, son lieu et sa durée. Son application exacte aux contrats de logiciel est discutée par les tribunaux, et c'est une raison de plus pour rédiger la clause avec ce niveau de précision plutôt que d'écrire « le client est propriétaire de tout ».
| Qui écrit le code | Qui détient les droits au départ | Ce qui les transmet |
|---|---|---|
| Un salarié, dans ses fonctions | L'employeur (art. L113-9) | La loi, sauf clause contraire |
| Un prestataire extérieur | Le prestataire | Un contrat écrit de cession ou de licence |
| Un projet open source | Ses auteurs | La licence du projet, qui s'impose à tous |
Cession ou licence : deux façons de vous donner des droits
Un contrat peut vous transmettre des droits de deux manières.
- La cession transfère les droits patrimoniaux : vous devenez titulaire, dans les limites écrites au contrat (usages, territoire, durée). Vous pouvez alors faire modifier le code par une autre équipe, le réutiliser, parfois le revendre, selon ce qui a été cédé.
- La licence vous autorise à utiliser le logiciel sans en devenir titulaire. Elle peut être large (usage illimité, modification autorisée) ou étroite (usage interne, sans accès au code). C'est le modèle de tout logiciel du marché et de tout SaaS.
Aucune des deux n'est meilleure dans l'absolu. Une licence large, assortie d'un accès au code en cas de défaillance, protège parfois mieux qu'une cession mal rédigée. Ce qui compte, c'est que le contrat dise clairement ce que vous pouvez faire le jour où vous voulez changer de prestataire.
Ce qui ne vous appartiendra jamais, quel que soit le contrat
Une application moderne n'est pas écrite entièrement pour vous. Elle assemble trois couches, et seule la première peut vous être cédée sans réserve.
- Le code spécifique, écrit pour votre projet : vos écrans, vos règles métier, vos intégrations. C'est l'objet normal de la négociation.
- Les briques du prestataire, qu'il réutilise d'un projet à l'autre (authentification, modèles de composants, outils de déploiement). Un prestataire les concède en licence plutôt que de les céder, sinon il ne pourrait plus s'en servir. Le contrat doit les nommer.
- Les composants open source (frameworks, bibliothèques). Ils restent soumis à leur propre licence. Certaines licences, comme la GPL, imposent des obligations si vous redistribuez le logiciel. Demandez la liste des composants et de leurs licences.
Les questions à poser avant de signer
- Quels droits me sont transmis : reproduction, modification, diffusion ? Par cession ou par licence ?
- Pour quel usage, quel territoire et quelle durée ?
- Quelles parties restent au prestataire, et à quelles conditions puis-je les utiliser ensuite ?
- Ai-je accès au dépôt de code pendant le projet, ou seulement à la fin, ou jamais ?
- Qui détient les comptes d'hébergement, les noms de domaine et les données ?
- Que se passe-t-il si le prestataire cesse son activité ou arrête la maintenance ?
La dernière question a une réponse classique : le dépôt du code chez un tiers. Le code est déposé chez un organisme indépendant, comme l'Agence pour la protection des programmes (APP) en France, et un contrat de séquestre fixe les cas où il vous sera remis. C'est utile quand vous utilisez un logiciel sans en recevoir le code.
Pour la suite du raisonnement, le choix d'un prestataire est traité dans notre guide en 12 questions, et la comparaison des modes de réalisation dans agence, freelance ou no-code.
Trois situations fréquentes
Le contrat ne dit rien. C'est le cas le plus risqué. Faute de cession écrite, les droits restent au prestataire, et vous disposez au mieux d'un droit d'utilisation implicite, dont l'étendue se discute. Faire modifier le logiciel par une autre équipe devient alors incertain.
Le contrat écrit « le client est propriétaire de tout ». La formule rassure mais reste fragile : elle ne précise ni les droits, ni l'usage, ni la durée, et elle ignore les briques du prestataire et l'open source. Demandez une clause qui détaille ces points.
Le contrat concède une licence d'utilisation. C'est le modèle normal d'un SaaS ou d'un abonnement. Vérifiez alors ce qui se passe à la fin du contrat, la restitution de vos données et, si l'application est critique, l'existence d'un dépôt du code chez un tiers.
La position de LPR Studio
Notre réponse dépend de la formule, et elle reste volontairement prudente, parce qu'elle touche à des engagements contractuels.
- Le prototype de démonstration reste la propriété de LPR Studio : il est présenté en visio, pas livré.
- Ensuite, les droits dépendent de la formule retenue et sont définis au cas par cas dans le contrat.
- En formule abonnement, LPR Studio reste éditeur et exploitant de l'application. C'est ce qui explique l'absence d'investissement initial : vous ne payez pas le développement, seulement un abonnement mensuel.
- Au forfait, l'étendue des droits qui vous sont transmis se discute au moment du chiffrage.
Le détail des formules est sur la page des offres, et la différence de coût entre abonnement et forfait est analysée dans cet article sur trois ans. Notre stack est volontairement standard (React, Next.js, TypeScript) : une application écrite avec des outils courants et documentés reste reprenable par une autre équipe, ce qui compte autant que la clause elle-même.
Par où commencer
Posez la question de la propriété dès le premier échange, pas au moment de la signature : elle change la formule, donc le prix. Chez LPR Studio, le prototype visuel est gratuit et présenté en visio sous 5 jours ouvrés ; c'est à ce moment que nous expliquons, pour votre projet, ce que chaque formule vous transmet.