À qui appartient le code généré par IA ? Ce que le dirigeant doit vérifier

Le code que Lovable, Cursor ou Claude Code a écrit pour vous, à qui appartient-il ? Réponse courte : face à l'éditeur de l'outil, il vous appartient en général, si ses conditions d'utilisation le disent. Face au reste du monde, c'est moins simple. En droit français, un code produit sans apport créatif humain significatif n'est pas protégé par le droit d'auteur. Vous pouvez l'utiliser, le modifier et le céder avec votre entreprise, mais vous aurez du mal à empêcher quelqu'un de le copier.

Pour un dirigeant, la question « à qui appartient le code généré par IA » recouvre en fait trois questions plus concrètes. Que disent les conditions de l'outil utilisé ? Qui détient les droits si un prestataire a codé pour vous ? Et surtout, contrôlez-vous les comptes sans lesquels le code ne sert à rien : le dépôt, l'hébergement, la base de données, le nom de domaine ?

Cet article passe les trois en revue et se termine par une liste de vérifications à faire vous-même. Il ne remplace pas l'avis d'un avocat en propriété intellectuelle, surtout avant une levée de fonds ou une cession d'entreprise.

À qui appartient le code généré par IA, juridiquement ?

En France, le droit d'auteur protège les logiciels comme les autres œuvres, à une condition : qu'ils soient originaux, c'est-à-dire qu'ils portent l'empreinte de la personnalité de leur auteur. Un auteur, au sens du droit d'auteur, est un être humain. La question est donc de savoir ce qui reste d'humain dans un code écrit par une IA.

Le Conseil supérieur de la propriété littéraire et artistique (CSPLA) a publié le 16 juillet 2026 un rapport sur le statut des productions de l'intelligence artificielle. Il distingue deux cas :

• La création hybride : un humain garde un rôle créatif. L'œuvre peut être protégée si elle atteint le seuil d'originalité. Selon le rapport, cette originalité peut apparaître à trois moments : la conception et le paramétrage, la génération (itérer, orienter l'outil), puis la sélection, la retouche et l'intégration du résultat.
• La production synthétique : elle est générée sans intervention humaine significative. Elle échappe au droit d'auteur, et le rapport la rattache au domaine public.

Le rapport traite aussi de la preuve. Celui qui conteste la protection doit d'abord apporter des éléments concrets montrant une génération sans apport humain décisif. Celui qui revendique la protection doit ensuite montrer que ses choix viennent de sa propre activité créative.

Concrètement, si vous avez décrit votre besoin en trois phrases et accepté tout ce que l'outil a produit, votre code est probablement peu protégé. Si vous ou votre développeur avez conçu l'architecture, découpé le travail, relu, corrigé et réécrit, la part humaine est réelle, mais il faut pouvoir la montrer. D'où l'intérêt de garder des traces : spécifications, historique Git, revues de code.

Gardez aussi la mesure : la valeur de votre application tient rarement au code seul. Vos données, vos clients, votre connaissance du métier et votre capacité à faire évoluer l'outil comptent davantage. Un concurrent qui copierait votre code n'aurait ni l'un ni l'autre.

Ce que disent les conditions de Lovable et des autres outils

En l'absence de loi propre au code généré, c'est le contrat avec l'outil qui règle la relation entre vous et son éditeur. Prenons Lovable, très utilisé par les non-développeurs. Ses conditions d'utilisation, mises à jour le 28 août 2026, disent :

• vous êtes propriétaire de vos contenus, y compris les applications que vous construisez avec le service ;
• vous êtes aussi propriétaire des résultats générés par l'IA pour vous, sous réserve des droits de tiers sur les modèles sous-jacents, leurs données d'entraînement ou leurs résultats ;
• en contrepartie, vous accordez à Lovable une licence mondiale, perpétuelle et gratuite pour utiliser, copier, modifier et analyser ces contenus pour ses besoins ;
• Lovable peut utiliser vos contenus pour entraîner des modèles d'IA. Vous pouvez vous y opposer pour l'avenir, gratuitement, quelle que soit votre formule.

Autrement dit, propriétaire ne veut pas dire exclusif. Si votre application contient une logique métier sensible ou des données confidentielles, la première chose à faire est de vérifier si l'opposition à l'entraînement est activée sur votre compte.

Les autres outils (assistants de code, générateurs d'applications) ont chacun leurs conditions, qui changent souvent selon la formule et au fil des versions. Lisez la section qui parle de vos contenus et des résultats générés (souvent intitulée Content, Output ou Customer Data) et posez-vous trois questions : à qui appartient le résultat, quelle licence l'éditeur se réserve, et utilise-t-il vos données pour entraîner ses modèles ? Relisez-la au moins une fois par an.

Dernier point, souvent oublié : être propriétaire du résultat ne garantit pas qu'il est libre de droits de tiers. Une IA peut reproduire des morceaux de code publiés sous une licence qui impose des obligations. C'est l'une des raisons pour lesquelles un code généré mérite une relecture humaine avant d'être considéré comme un actif de l'entreprise.

Si un prestataire a codé votre application avec l'IA

Ici, le droit français fait une distinction nette selon qui a écrit le code.

Un salarié. L'article L113-9 du Code de la propriété intellectuelle attribue à l'employeur les droits patrimoniaux sur les logiciels créés par un salarié dans l'exercice de ses fonctions ou d'après ses instructions, sauf clause contraire. Pas besoin de contrat de cession.

Un freelance ou une agence. Cette règle ne s'applique pas. Selon l'article L131-3 du même code, la cession de droits d'auteur doit être écrite, chaque droit cédé doit être mentionné séparément, et le contrat doit préciser l'étendue, la destination, le lieu et la durée de l'exploitation. Payer la facture ne vaut pas cession. Sans clause conforme, le prestataire reste titulaire des droits sur ce qu'il a créé.

L'IA ne rend pas cette clause inutile, au contraire. Même si une partie du code est faiblement protégée, la clause couvre la part humaine : architecture, choix de conception, documentation, maquettes. Elle évite aussi toute discussion le jour où vous changez de prestataire. Profitez-en pour demander par écrit :

• quels outils d'IA ont été utilisés pour votre projet ;
• si votre code ou vos données ont été envoyés à ces outils, et sous quelles conditions (entraînement activé ou non) ;
• si le prestataire a réutilisé des briques qui lui appartiennent (code « maison » préexistant), et sous quelle licence vous pouvez les utiliser.

Le second point touche aussi à vos obligations sur les données personnelles : voir notre article Application vibe coding et RGPD : où sont vos données.

Au-delà du code : les comptes qui font que l'application est à vous

Dans la pratique, ce qui bloque une entreprise est rarement une question de droit d'auteur. Ce sont les comptes. Vous pouvez être juridiquement propriétaire d'un code que vous ne pouvez ni déployer, ni modifier, ni même télécharger.

Le scénario à éviter ressemble à ceci : l'application a été créée sur le compte personnel d'un associé ou d'un freelance. Le dépôt GitHub est à son nom, l'hébergement est payé avec sa carte, le nom de domaine a été réservé par lui. Le jour où la relation s'arrête, vous dépendez de sa bonne volonté pour récupérer ce qui fait tourner votre activité.

Les comptes à vérifier :

• Le dépôt de code (GitHub, GitLab) : une organisation au nom de l'entreprise, dont vous êtes propriétaire.
• L'outil de génération (espace Lovable, Bolt, etc.) : rattaché à un compte de l'entreprise, avec la synchronisation vers un dépôt Git activée.
• L'hébergement et la base de données (Supabase, Vercel, OVH, etc.) : facturés à l'entreprise, avec un accès administrateur pour vous.
• Le nom de domaine : la société doit en être le titulaire auprès du bureau d'enregistrement, pas seulement le payeur.
• Les services tiers : paiement, envoi d'e-mails, clés d'API d'IA. Chaque clé doit pouvoir être renouvelée par vous.

Si l'application vit encore sur Lovable, sachez que l'export du code ne suffit pas toujours à la faire tourner ailleurs. Nous détaillons ce point dans Héberger une application Lovable ailleurs : ce que l'export oublie. Et si le prestataire est déjà parti, notre article sur la reprise d'une application quand le prestataire est parti donne l'ordre des opérations.

Vérifier que votre application vous appartient : la liste

Voici les vérifications à faire, sans compétence technique particulière :

1. Nom de domaine : connectez-vous chez le bureau d'enregistrement et vérifiez que le titulaire est votre société.
2. Dépôt de code : vérifiez qu'il appartient à une organisation de l'entreprise, avec au moins deux propriétaires, dont vous.
3. Export : faites télécharger le code complet une fois et vérifiez qu'il est bien là. Un export jamais testé n'est pas une garantie.
4. Hébergement et base : les factures sont-elles au nom de l'entreprise ? Avez-vous un accès administrateur ?
5. Contrats : si un prestataire est intervenu, relisez la clause de cession au regard de l'article L131-3. En cas de doute, faites-la relire par un avocat.
6. Conditions des outils d'IA : propriété du résultat, licence réservée par l'éditeur, entraînement sur vos données et option d'opposition.
7. Documentation minimale : où est le code, comment on le déploie, où sont rangés les secrets. Une page suffit pour commencer.
8. Traces de vos choix : spécifications, échanges, historique des modifications. Ce sont elles qui montrent l'apport humain si la question se pose un jour.

Si vous comptez confier la suite de l'application à un développeur, ce sont aussi les premières choses qu'il vous demandera. Lorsqu'en formule Pilote Devnco reprend et fait évoluer une application, c'est par là que tout commence : savoir précisément ce qui vous appartient et à quoi vous avez accès.

Questions fréquentes

Puis-je vendre mon entreprise si l'application a été codée avec l'IA ?

Oui. Rien n'interdit de céder une entreprise dont l'application a été générée en tout ou partie par une IA. L'acheteur ou l'investisseur vérifiera en revanche les points de la liste ci-dessus : contrats, comptes, conditions des outils. Mieux vaut les avoir réglés avant.

Un concurrent peut-il copier mon application générée par IA ?

Si le code est purement synthétique, le droit d'auteur vous aidera peu. Le rapport du CSPLA mentionne d'autres pistes lorsque le droit d'auteur ne peut pas être invoqué, comme l'action en parasitisme. Dans les faits, votre meilleure protection reste ce qui ne se copie pas : vos données, vos clients et votre rythme d'évolution.

Mon ancien prestataire refuse de me donner accès au code. Que faire ?

Rassemblez le contrat, les factures et les échanges, puis consultez un avocat. Tout dépendra de la clause de cession et de la propriété des comptes. C'est précisément pour éviter cette situation qu'il faut vérifier la liste pendant que la relation se passe bien.

Vous n'êtes pas sûr de savoir où se trouvent votre code, vos accès ou vos contrats ? On peut faire le point ensemble, simplement, pour savoir où vous en êtes avant de décider quoi que ce soit.