Vous préparez une levée de fonds. L’investisseur vous demande une pièce simple : la preuve que votre société détient les droits sur son logiciel. Or le code a été écrit par un freelance, complété par une agence, puis enrichi avec un outil d’IA.
Vous avez tout payé. Vous utilisez le logiciel tous les jours. Et pourtant, vous ne trouvez aucun document qui dise que le code est à vous.
Cette situation est fréquente. Elle l’est plus encore depuis que les outils d’IA et de no-code permettent de créer une application en quelques jours, parfois sans savoir coder, et sans que les contrats aient suivi.
Le fil rouge de cet article : payer un logiciel, l’utiliser et en être propriétaire sont trois choses différentes. Un investisseur ou un acquéreur ne paie que la troisième.
À qui appartient le code écrit par un prestataire, un salarié ou un associé ? Que vaut la « propriété » promise par un outil d’IA ? Que possédez-vous vraiment sur une plateforme no-code ? Et comment sécuriser tout cela avant une opération ?
À qui appartient un logiciel développé par un prestataire ?
» J’ai payé le développement, le code est à moi, non ? «
Pas nécessairement. En droit d’auteur, payer une prestation ne transfère pas la propriété de ce qui a été créé. Sans contrat de cession, les droits restent en principe à celui qui a écrit le code.
Le logiciel est une œuvre protégée par le droit d’auteur
L’article L. 112-2, 13° du Code de la propriété intellectuelle range parmi les œuvres de l’esprit » les logiciels « , y compris le matériel de conception préparatoire ». Les droits naissent sur la tête de la personne qui crée le code.
Ces droits sont étendus. Selon l’article L. 122-6 du même code, l’auteur d’un logiciel a seul le droit d’autoriser sa reproduction, sa modification et sa mise sur le marché. Faire évoluer un logiciel ou le commercialiser suppose donc de détenir ces droits.
Sans écrit précis, pas de transfert
Deux textes encadrent la cession :
- L’article L. 131-2 : les contrats par lesquels sont transmis des droits d’auteur doivent être constatés par écrit.
- L’article L. 131-3 : chacun des droits cédés doit faire l’objet d’une mention distincte, et le domaine d’exploitation doit être délimité quant à son étendue, sa destination, son lieu et sa durée.
En pratique, ne valent pas cession :
- une facture acquittée, même libellée « développement sur mesure »
- la livraison du code source ou l’accès au dépôt
- une mention générale du type « tous droits cédés », dont la portée peut être contestée.
Avec une agence, une chaîne à vérifier
Une agence ne peut vous céder que ce qu’elle détient elle-même. Si ses développeurs sont salariés, elle est en principe titulaire des droits. Si elle a fait appel à des freelances, elle doit avoir obtenu leur cession avant de vous céder quoi que ce soit.
Sans cession, vous disposez au mieux d’un droit d’usage, dont l’étendue se discute au cas par cas. Confier l’évolution du code à un autre prestataire ou revendre le logiciel devient alors risqué.
Salarié, stagiaire, associé : qui est couvert par la dévolution automatique ?
» C’est mon associé qui a tout codé, la société est donc propriétaire ? «
Pas automatiquement. La loi ne prévoit un transfert automatique à l’entreprise que dans des cas précis. Un associé ou un dirigeant non salarié n’en fait pas partie.
Les salariés : la règle la plus favorable à l’entreprise
Selon l’article L. 113-9 du Code de la propriété intellectuelle sur les logiciels créés par les salariés, les droits patrimoniaux sur les logiciels et leur documentation créés par un employé dans l’exercice de ses fonctions, ou d’après les instructions de son employeur, sont dévolus à l’employeur. La règle s’applique sauf stipulations contraires.
Deux limites sont à garder en tête. La règle vise le logiciel, pas les autres créations du salarié (charte graphique, contenus, visuels). Et elle suppose un travail réalisé dans le cadre des fonctions ou sur instructions.
Les stagiaires : un régime étroit
Depuis le 17 décembre 2021, l’article L. 113-9-1 étend cette dévolution à des personnes non salariées. Mais ses conditions sont strictes. La personne doit être accueillie, dans le cadre d’une convention, par une structure » réalisant de la recherche « , percevoir une contrepartie et être placée sous l’autorité d’un responsable de cette structure.
Toutes les entreprises et tous les stages n’entrent pas dans ce cadre. En cas de doute, une cession écrite reste le réflexe le plus sûr.
Les associés et dirigeants non salariés : l’angle mort
C’est la situation la plus fréquente dans les jeunes sociétés. Le cofondateur technique écrit le code, sans contrat de travail. Aucun texte ne transfère ses droits à la société.
La Cour de cassation l’a rappelé dans un arrêt du 15 janvier 2015 (Cass. 1re civ., n° 13-23.566, publié au Bulletin) : une personne morale ne peut pas avoir la qualité d’auteur. Elle a censuré une cour d’appel qui avait reconnu à une société la qualité d’auteur de deux logiciels, fruit du travail de ses associés.
De nombreux fondateurs pensent que le code » appartient à la boîte » parce qu’il a été écrit pour elle. C’est inexact pour un associé non salarié : sans cession ou apport écrit, les droits restent à la personne qui a codé.
Le bon réflexe : faire signer une cession de droits à la société par chaque fondateur qui a contribué au code, dès la création. C’est simple quand tout va bien, et très difficile après un départ conflictuel.
Code préexistant et open source : ce que le prestataire ne peut pas vous céder
» J’ai une clause de cession, je suis tranquille ? «
Pas tout à fait. Une cession ne porte que sur ce que le prestataire a créé pour vous et qu’il a le droit de céder. Or un logiciel est rarement écrit à partir d’une page blanche.
- Les briques du prestataire : bibliothèques, modules ou outils qu’il réutilise d’un client à l’autre. Il ne vous les cède pas, il vous en concède l’usage. Les conditions de cette licence comptent : durée, droit de modifier, sort en cas de changement de prestataire.
- Les composants de tiers : ils restent soumis à leur propre licence, que votre contrat ne peut pas modifier.
- L’open source : la licence suit le code. Certaines licences imposent des obligations fortes, par exemple diffuser le code modifié sous la même licence.
Un risque qui se chiffre
Le non-respect d’une licence libre peut constituer une contrefaçon. La cour d’appel de Paris l’a jugé le 14 février 2024, à propos d’un logiciel diffusé sous licence GNU GPL version 2.
Elle a alloué à son éditeur 800 000 euros de dommages et intérêts : 500 000 euros pour les conséquences économiques, 150 000 euros pour le préjudice moral et 150 000 euros au titre des bénéfices réalisés.
Le bon réflexe : exiger à la livraison un inventaire des composants préexistants et open source, avec leurs licences. Ce document vous sera demandé lors de tout audit.
Logiciel créé avec l’IA : possédez-vous vraiment le code ?
» L’outil dit que le code généré m’appartient. Ça suffit ? «
Non. Les conditions d’utilisation d’un outil règlent vos rapports avec son éditeur. Elles ne créent pas un droit d’auteur opposable à tous.
Ce que disent les conditions d’un outil
Prenons l’exemple de Lovable, un outil qui génère des applications à partir d’instructions en langage courant. Ses conditions, mises à jour le 28 août 2026, prévoient que :
- l’utilisateur est propriétaire des applications qu’il construit et des résultats générés pour lui par l’IA
- cette propriété s’entend sous réserve des droits de tiers sur les modèles, les données d’entraînement ou les résultats
- l’éditeur ne garantit pas que ces résultats soient uniques ni libres de droits de tiers, et ils peuvent être similaires ou identiques à ceux générés pour d’autres utilisateurs.
Autrement dit, l’éditeur ne revendique pas le code. Il ne vous garantit pas pour autant que personne d’autre ne peut le revendiquer, ni que vous pourrez en interdire la copie.
Ce que dit le droit d’auteur
Le droit d’auteur protège une création humaine. Pour un logiciel, la Cour de cassation exige depuis 1986 qu’il porte la marque de l’apport intellectuel de son auteur (Cass. ass. plén., 7 mars 1986, n° 83-10.477).
Un code produit par une IA sans choix humains identifiables risque donc de ne pas être protégé. À notre connaissance, aucune décision française n’a encore tranché cette question pour du code généré, à la date de rédaction de cet article. L’incertitude est réelle.
La conséquence est concrète. Ce qui n’est pas protégé par le droit d’auteur ne peut ni être cédé à ce titre, ni être défendu par une action en contrefaçon. En revanche, lorsqu’un développeur conçoit l’architecture, sélectionne, corrige et réécrit, une protection reste envisageable sur ses apports, au cas par cas.
Votre freelance a utilisé l’IA
Beaucoup de prestataires utilisent aujourd’hui ces outils pour livrer plus vite. Votre clause de cession ne couvre alors que ce qui est protégeable. Trois points méritent d’être écrits :
- une déclaration du prestataire sur les outils d’IA utilisés
- une garantie contre les réclamations de tiers sur le code livré
- la conservation des éléments qui documentent ses apports personnels.
Et la confidentialité ?
Les mêmes conditions prévoient que l’éditeur peut utiliser les données de ses clients pour développer et entraîner des modèles d’IA, sauf demande contraire de l’utilisateur. Or le secret des affaires ne protège une information que si elle fait l’objet de mesures de protection raisonnables (article L. 151-1 du Code de commerce). Vérifier ce réglage fait partie de ces mesures.
De nombreux contenus affirment que « le code généré par l’IA vous appartient ». C’est une simplification : ce que l’outil vous accorde par contrat n’est pas un droit d’auteur, et ne vous protège pas contre un concurrent qui obtiendrait un code similaire.
Application en no-code : propriétaire ou locataire ?
» J’ai construit mon appli sans coder, elle est à moi ? «
En partie seulement. Sur une plateforme no-code, vous êtes propriétaire de ce que vous y apportez, pas du moteur qui fait fonctionner l’application.
Bubble, l’une des plateformes les plus utilisées, l’explique dans sa documentation :
- Ce qui vous revient : vos données et le design de votre application.
- Ce qui reste à la plateforme : le code sous-jacent qui fait fonctionner l’application.
- Ce que vous ne pouvez pas faire : exporter votre application sous forme de code. Elle ne fonctionne que sur la plateforme. Si vous la quittez, la logique applicative est à reconstruire.
La plateforme précise que cette page est informative et que ses conditions générales prévalent. Elle s’engage par ailleurs à publier son code sous licence libre si elle cessait son activité.
Ce que cela change pour votre entreprise
- Vous ne détenez pas un « code source » que vous pourriez céder, déposer ou faire auditer.
- La valeur de votre application repose sur d’autres actifs : la marque, les données, le design, la clientèle, les contrats.
- Votre activité dépend des conditions et des tarifs de la plateforme.
Point clé : le no-code n’est pas un mauvais choix. C’est un modèle de dépendance assumée, qu’il faut connaître avant de promettre à un investisseur ou à un acquéreur la « propriété du logiciel ».
Fonctionnalités et concept : le droit d’auteur s’arrête au code
» Un concurrent peut-il refaire mon logiciel avec l’IA ? «
En principe oui, s’il ne copie pas votre code. Le droit d’auteur protège la forme d’un logiciel, pas ce qu’il fait.
La Cour de justice de l’Union européenne l’a jugé dans son arrêt SAS Institute du 2 mai 2012 sur la protection des fonctionnalités d’un logiciel (CJUE, C-406/10) : ni la fonctionnalité d’un programme d’ordinateur, ni le langage de programmation, ni le format de fichiers de données ne sont protégés par le droit d’auteur sur les programmes d’ordinateur.
Avec les outils d’IA, reproduire les fonctions d’un logiciel existant sans en copier une ligne est devenu rapide et peu coûteux. D’autres protections doivent donc prendre le relais :
- La marque : elle protège le nom sous lequel votre logiciel est connu.
- Le secret des affaires : il protège vos algorithmes, votre architecture et vos données, à condition de les garder réellement confidentiels.
- Les contrats : confidentialité, non-concurrence, conditions d’utilisation interdisant certaines reprises.
- La concurrence déloyale et le parasitisme : ils peuvent sanctionner certains comportements, au cas par cas et sous réserve de preuve.
À RETENIR
✔ Sans cession écrite et détaillée, le code reste à celui qui l’a écrit (art. L. 131-2 et L. 131-3 CPI).
✔ Seuls les salariés bénéficient d’une dévolution automatique à l’employeur (art. L. 113-9 CPI).
✔ Une société ne peut pas être auteur : l’associé non salarié doit céder ses droits (Cass. 1re civ., 15 janv. 2015).
✔ La « propriété » accordée par un outil d’IA n’est pas un droit d’auteur.
✔ Les fonctionnalités ne sont pas protégées : seul le code l’est (CJUE, 2 mai 2012, C-406/10).
Levée de fonds ou cession : ce que l’investisseur va vérifier
» Qu’est-ce que je risque vraiment ? «
De découvrir le problème au pire moment. Lors d’une levée ou d’une cession, la propriété du logiciel est l’un des premiers points audités. Trois vérifications reviennent presque toujours.
- La chaîne de titularité : pour chaque personne qui a contribué au code, un contrat de travail, une cession ou un apport.
- L’inventaire des composants : briques de prestataires et composants open source, avec leurs licences.
- L’usage de l’IA et du no-code : quelle part du logiciel a été générée, avec quels outils, sous quelles conditions.
Les conséquences d’une chaîne incomplète
- Une décote sur la valorisation.
- Des garanties renforcées demandées au fondateur.
- Une régularisation exigée avant la signature, qui retarde l’opération.
Régulariser après coup suppose l’accord de l’auteur. Un ancien prestataire ou un cofondateur parti en mauvais termes se retrouve alors en position de force pour négocier.
Le plan d’action : six étapes pour sécuriser la propriété de votre logiciel
» Par où je commence ? «
Par un état des lieux. Les six étapes suivantes se déroulent dans cet ordre, et les premières peuvent être menées en quelques jours.
- Cartographier qui a écrit quoi. Salariés, freelances, agences, associés, stagiaires, outils d’IA : dressez la liste des contributeurs et des périodes.
- Rassembler les contrats. Pour chaque contributeur, vérifiez l’existence d’un écrit et la précision de la cession.
- Régulariser les cessions manquantes. Tant que les relations sont bonnes, un acte de cession confirmatif se signe sans difficulté.
- Encadrer l’IA et l’open source dans vos contrats. Déclaration des outils utilisés, inventaire des composants, garantie contre les réclamations de tiers.
- Documenter les apports humains. Spécifications, choix d’architecture, historique des versions : ces éléments prouvent l’originalité et datent la création.
- Protéger ce que le droit d’auteur ne couvre pas. Dépôt de la marque, mesures de confidentialité, clauses adaptées dans vos conditions d’utilisation.
Trois situations concrètes
» Est-ce que mon cas ressemble à l’un de ceux-là ? «
Cas 1 · Le micro-SaaS construit en no-code
Un fondateur a créé seul, sur une plateforme no-code, un outil de gestion qui compte 300 clients. Un acquéreur lui demande de céder « le logiciel et son code source ».
Le risque : promettre ce qu’il ne détient pas. La cession doit être construite sur les actifs réels : marque, données, design, contrats clients, compte sur la plateforme, dans le respect des conditions de celle-ci.
Cas 2 · La PME et son agence web
Une PME a fait développer un outil métier par une agence, sur simple devis. Trois ans plus tard, elle veut confier la maintenance à un autre prestataire. L’agence s’y oppose et invoque ses droits sur le code.
Le risque : un blocage, voire un contentieux. Tout dépend des documents échangés. Une clause de cession dans le contrat initial, avec un inventaire des briques réutilisées, aurait évité la discussion.
Cas 3 · Le cofondateur technique qui s’en va
Deux associés créent une start-up. L’un, non salarié, écrit l’essentiel du code, en s’aidant d’un outil d’IA. Il quitte la société avant la première levée de fonds.
Le risque : la société n’est pas titulaire des droits sur son produit principal. L’investisseur exigera une cession, que l’ancien associé est libre de négocier. Une cession signée à la création aurait sécurisé la société.
L’enseignement commun : dans les trois cas, le logiciel fonctionne et les factures sont payées. Ce qui manque, c’est l’écrit qui dit à qui il appartient.
FAQ : propriété d’un logiciel développé par un tiers
Le code source qui m’a été livré m’appartient-il ?
Pas nécessairement. La remise du code source ne transfère pas les droits d’auteur. Il faut un contrat écrit qui mentionne chaque droit cédé et délimite son étendue, sa destination, son lieu et sa durée (article L. 131-3 du Code de la propriété intellectuelle). Sans cet écrit, vos droits se limitent en principe à un usage.
Mon freelance peut-il réutiliser le code chez un autre client ?
Cela dépend de votre contrat. Sans cession, il reste titulaire des droits et peut en principe réutiliser son code. Avec une cession exclusive, il ne le peut plus pour ce qui a été cédé. Les briques qu’il utilisait déjà avant votre projet restent généralement sa propriété.
Le code généré par une IA est-il protégé par le droit d’auteur ?
Ce n’est pas certain. Le droit d’auteur suppose un apport intellectuel humain. Un code généré sans intervention créative identifiable risque de ne pas être protégé, et aucune décision française n’a, à notre connaissance, tranché la question à la date de rédaction. Les apports d’un développeur qui structure et réécrit le code peuvent en revanche être protégés, au cas par cas.
Puis-je vendre une application créée en no-code ?
Oui, mais pas comme un logiciel classique. Vous cédez vos données, votre design, votre marque, vos contrats et l’accès à votre compte, dans le respect des conditions de la plateforme. Le code sous-jacent reste la propriété de celle-ci. L’acte de cession doit décrire précisément ces actifs.
Comment régulariser une cession de droits oubliée ?
Par un acte de cession signé avec l’auteur du code, qui couvre les développements déjà réalisés. Cet acte doit respecter les mêmes exigences qu’une cession initiale. Il suppose l’accord de l’auteur : mieux vaut donc s’en occuper avant tout désaccord ou toute opération sur le capital.
Faut-il déposer son logiciel pour être protégé ?
Non. Le droit d’auteur naît sans formalité, du seul fait de la création. Un dépôt reste utile pour dater le code et faciliter la preuve en cas de litige. Il ne remplace ni un contrat de cession, ni la conservation des éléments qui démontrent l’originalité.
En conclusion, payer un logiciel, l’utiliser et en être propriétaire sont trois choses différentes.
Les enjeux sont doubles. Au quotidien, la propriété conditionne votre liberté de faire évoluer le code, de changer de prestataire et de vous défendre contre une copie. Lors d’une levée de fonds ou d’une cession, elle conditionne la valeur de l’entreprise. Les outils d’IA et de no-code n’ont pas changé ces règles : ils ont multiplié les situations où personne ne s’est posé la question.
La bonne posture n’est ni de renoncer à ces outils, ni de s’en remettre à leurs conditions générales. C’est de savoir précisément ce que l’on détient, et de l’écrire avant d’en avoir besoin.
En savoir plus, je vous invite à lire mon article : IA et droit d’auteur : votre entreprise est-elle exposée à un risque de contrefaçon en 2026 ?
Votre logiciel a été développé par un prestataire, un associé ou avec l’IA ?
Le Cabinet Nathalie Matteoda, avocat en propriété intellectuelle et droit du numérique à Paris, vous accompagne : audit de la titularité du code, régularisation des cessions, clauses IA et open source dans vos contrats de développement.
Prendre rendez-vous : Tél. 06 42 18 50 53 ou prenez rendez-vous en ligne.
Suivre mon actualité sur Linkedin ? Nathalie Matteoda – Avocat en droit de la propriété intellectuelle
Cet article fournit une information juridique générale et ne constitue pas un conseil individualisé. Chaque logiciel, chaque contrat et chaque outil méritent une analyse dédiée. Les conditions d’utilisation des outils cités sont celles publiées à la date de rédaction et peuvent évoluer. Pour sécuriser la propriété de votre logiciel, consultez un avocat en propriété intellectuelle.