Vous avez construit votre SaaS avec Lovable, Bolt, v0 ou Replit Agent. En quelques jours, seul, vous avez un produit fonctionnel. Mais avant de le vendre, de lever des fonds, ou même simplement de dormir tranquille : à qui appartient réellement ce code ?
La réponse a deux niveaux, et c’est justement là que la plupart des solopreneurs se trompent. Il y a ce que dit le contrat de la plateforme que vous utilisez (« vous êtes propriétaire de votre code »), et il y a ce que dit la loi sur le droit d’auteur, qui ne suit pas toujours le même raisonnement. Cet article fait la différence, et compare les principales solutions du marché sur ce point précis.
Ce que vous pouvez (ou ne pouvez pas) faire concrètement, selon votre outil
Avant d’entrer dans le détail juridique, voici cinq situations réelles que rencontrent les solopreneurs qui ont vibe-codé leur produit. Ce sont elles qui déterminent si votre choix d’outil était le bon.
« Je veux faire reprendre mon développement par une agence ou un freelance »
✅ Avec Lovable, Bolt, v0 ou Replit : oui, sans problème. Vous exportez votre dépôt GitHub, l’agence le clone et travaille directement sur du React, du Next.js ou une stack équivalente. C’est un transfert de projet classique.
❌ Avec Bubble ou Base44 : beaucoup plus compliqué. Il n’existe pas de code source portable à transmettre. L’agence doit soit apprendre l’outil propriétaire (peu en ont l’habitude), soit reconstruire le produit depuis zéro dans un autre environnement.
« J’arrête de payer mon abonnement, est-ce que je perds mon application ? »
✅ Avec un outil qui exporte du code standard : non, si vous avez déjà synchronisé votre projet vers votre propre dépôt GitHub, vous gardez le code et pouvez l’héberger ailleurs, même après résiliation.
❌ Avec une solution où l’application vit entièrement sur l’infrastructure du fournisseur : oui, dans les faits. Sans abonnement actif, votre application peut devenir inaccessible, car elle dépend des serveurs et de la base de données propriétaires du service.
« Je veux vendre mon SaaS ou lever des fonds »
✅ Un code exportable et documenté constitue un actif clair : l’acquéreur ou l’investisseur peut l’auditer, le faire relire par un développeur indépendant, en vérifier la qualité.
❌ Un produit enfermé dans une plateforme no-code propriétaire est beaucoup plus difficile à valoriser : ce que vous vendez n’est pas vraiment un logiciel, mais un accès à un service tiers que vous ne contrôlez pas entièrement.
« Un concurrent sort une app qui ressemble beaucoup à la mienne »
Dans la majorité des cas, vous ne pourrez pas agir sur la base du droit d’auteur si votre code a été généré sans intervention créative humaine significative : sans originalité démontrable, il n’y a pas de droit exclusif à faire valoir, quel que soit l’outil utilisé pour le produire.
Cette situation touche aussi bien les utilisateurs de Lovable ou Bolt que ceux de Bubble : ce n’est pas l’outil qui protège, c’est ce que vous en avez fait.
« Je veux migrer d’un outil à un autre en cours de route »
✅ Entre outils basés sur du code standard (par exemple de Bolt vers Cursor, ou de v0 vers un déploiement Vercel indépendant) : la migration est réaliste, car la base technique reste compatible.
❌ Depuis un outil no-code propriétaire vers n’importe quel autre environnement : il n’y a pas de « migration », seulement une reconstruction. C’est le prix du confort initial de ces outils.
« Je suis développeur freelance et je livre une app vibe-codée à mon client »
Ici, la question change de nature : ce n’est plus seulement « qui possède le code », mais « qui est responsable si le code pose problème ». Si un fragment généré par l’IA reproduit, à votre insu, un morceau de code sous licence tierce, c’est vous, le prestataire, qui êtes en première ligne face à votre client, même si l’outil utilisé (Lovable, Bolt ou autre) vous cède contractuellement tous les droits sur le code produit.
Cette situation est développée plus loin dans l’article, avec les clauses contractuelles à prévoir avant toute livraison client.
Le droit d’auteur sur le code : ce que dit la loi française
En France, un logiciel est protégeable par le droit d’auteur au même titre qu’une œuvre littéraire (article L112-2 du Code de la propriété intellectuelle). Comme pour tout droit d’auteur, la condition centrale reste l’originalité : le code doit porter l’empreinte de la personnalité de son auteur, des choix créatifs propres, pas une simple exécution automatique.
Particularité du logiciel : contrairement au droit d’auteur classique, quand un salarié développe un programme dans le cadre de ses fonctions, les droits patrimoniaux sont automatiquement dévolus à l’employeur (article L113-9 CPI). Mais pour un solopreneur qui génère son code avec une IA, cette règle ne s’applique pas directement, la question reste : qui est l’auteur, humain ou machine ?
Qui possède le code généré par une IA comme Lovable ou Bolt ?
Sur le plan contractuel, la réponse est plutôt rassurante : les principales plateformes de vibe coding (Lovable, Bolt, v0) indiquent explicitement dans leurs conditions générales que vous êtes propriétaire du code et des applications que vous construisez, et qu’elles ne revendiquent aucun droit dessus.
Mais cette « propriété » contractuelle n’est pas la même chose que le droit d’auteur. Une plateforme peut parfaitement vous céder tous ses droits sur un code… qui n’est lui-même pas protégeable par le droit d’auteur, faute d’originalité humaine suffisante. Un code généré intégralement par un prompt, sans retouche ni choix d’architecture personnels, se trouve dans la même zone grise qu’une image générée par IA : personne n’a vraiment de droit d’auteur exclusif dessus, et un concurrent pourrait obtenir un résultat très proche avec un prompt similaire.
Ce que les CGU vous garantissent, c’est un droit d’usage et d’exploitation commerciale du code produit. Ce qu’elles ne peuvent pas garantir, c’est une exclusivité juridique sur ce code face à un tiers qui produirait quelque chose de similaire.
Propriété contractuelle vs droit d’auteur : la nuance qui change tout
- Propriété contractuelle : la plateforme (Lovable, Bolt, v0…) s’engage par contrat à ne pas revendiquer de droits sur votre code, et vous autorise à l’exploiter commercialement.
- Droit d’auteur : protection légale automatique, mais réservée aux créations portant l’empreinte d’un auteur humain, ce qui suppose un travail de conception, de sélection, de correction, d’architecture au-delà du simple prompt.
Concrètement : vous pouvez avoir « la propriété » d’un code selon les CGU d’un outil, sans pour autant pouvoir empêcher légalement quelqu’un de le copier ou de produire un équivalent. C’est le même écart que pour un logo généré par IA : posséder l’usage n’est pas la même chose que détenir un droit opposable.
Comparatif des principales solutions de vibe coding
Toutes les solutions ne se valent pas sur ce point. Certaines livrent un code standard, exportable et réutilisable ailleurs (GitHub, autre hébergeur). D’autres gardent votre application dans un environnement propriétaire dont vous ne pouvez pas vraiment sortir. Voici un comparatif des principales solutions du marché, à jour à la date de publication de cet article.
| Solution | Catégorie | Code exportable vers GitHub | Base technique | Verrouillage propriétaire |
|---|---|---|---|---|
| Lovable | Générateur d’app IA (vibe coding) | Oui, sync bidirectionnelle | React, Vite, Tailwind, Supabase | Faible |
| Bolt.new (StackBlitz) | Générateur d’app IA (vibe coding) | Oui | Frameworks JS standards (Next.js, Vite…) | Faible |
| v0 (Vercel) | Générateur d’interfaces IA | Oui, natif | Next.js, React | Faible |
| Replit Agent | Environnement de dev cloud + agent IA | Oui, Git intégré | Multi-langages, environnement réel | Faible à modéré |
| Cursor | Éditeur de code assisté par IA | Oui, le code vit déjà dans votre dépôt | Votre stack, au choix | Aucun |
| GitHub Copilot | Assistant de complétion de code | Oui, le code vit déjà dans votre dépôt | Votre stack, au choix | Aucun |
| Base44 | Générateur d’app no-code/IA | Partiel, export payant du frontend, backend dépendant du SDK Base44 | Backend et base de données maison, hébergés chez Base44 | Élevé |
| Bubble | No-code visuel | Non, logique propriétaire | Moteur de workflow propriétaire Bubble | Élevé |
| Webflow | Site builder visuel | Partiel (export HTML/CSS statique possible, logique CMS non portable) | Moteur CMS propriétaire Webflow | Modéré à élevé |
Deux familles se dessinent clairement :
- Les outils qui livrent du code standard exportable (Lovable, Bolt, v0, Replit, Cursor, Copilot) : vous récupérez un projet basé sur des technologies ouvertes (React, Next.js, etc.), que vous pouvez héberger, modifier ou faire auditer où vous voulez. C’est le code lui-même qui constitue votre actif.
- Les solutions no-code ou à infrastructure propriétaire (Base44, Bubble, en partie Webflow) : votre application « vit » dans l’environnement du fournisseur. Vous ne possédez pas un code exploitable ailleurs, mais un accès à un service, ce qui change complètement la nature de ce que vous « détenez » en cas de revente d’activité, de changement de prestataire ou de fermeture du service. Nuance pour Base44 : un export payant existe (frontend inclus), mais le backend reste dépendant d’un SDK propriétaire qui continue d’appeler les serveurs Base44, ce qui rend l’indépendance réelle partielle même sur les plans payants.
Cette distinction est stratégique si votre outil doit un jour être valorisé, vendu, ou audité par un investisseur : un actif « code exportable » a une valeur patrimoniale claire. Un actif « compte sur une plateforme propriétaire » est beaucoup plus difficile à faire reconnaître et à transférer.
Le risque caché : le code « contaminé » par une licence copyleft
Même avec un code exportable et contractuellement « à vous », un risque juridique reste peu connu : les modèles d’IA sont entraînés sur d’immenses volumes de code open source, dont certains sous licences copyleft (GPL notamment). Ces licences imposent que tout logiciel intégrant ou dérivant de ce code soit lui-même publié en open source, sous les mêmes conditions.
Si une IA reproduit, même partiellement, un fragment de code sous licence GPL dans votre projet sans que vous le sachiez, vous pouvez théoriquement vous retrouver avec une obligation de publier votre propre code, l’inverse de ce que vous cherchiez en construisant un produit commercial propriétaire.
Ce risque reste rare en pratique sur des projets de taille modeste, mais il justifie une vérification avant toute levée de fonds, cession, ou usage commercial à grande échelle.
Développeur ou freelance : votre responsabilité si vous livrez du code sous licence tierce à un client
Ce point concerne directement les développeurs et freelances qui livrent des applications à des clients en s’appuyant sur des outils de vibe coding. Si le code livré contient un fragment reproduit par l’IA sous licence copyleft, sans que cela ait été détecté ni signalé, ce n’est généralement pas votre client qui en assume les conséquences en premier lieu, c’est vous.
En droit français, un prestataire professionnel est tenu à une obligation de délivrance conforme et, en pratique contractuelle, à une garantie proche de la garantie d’éviction : le client doit pouvoir exploiter le logiciel livré sans être inquiété par les droits d’un tiers. Si un ayant droit sur le fragment copyleft se manifeste (mise en demeure, exigence de publication du code, action en contrefaçon), le client peut se retourner contre vous pour non-conformité ou vice caché, y compris en demandant la résiliation du contrat ou des dommages-intérêts.
Le fait d’avoir utilisé une IA générative pour produire le code ne vous décharge pas de cette responsabilité : vous restez le prestataire professionnel vis-à-vis de votre client, et c’est votre diligence qui est attendue, pas celle de l’outil.
Quelques réflexes à intégrer si vous livrez du code IA-généré à des clients :
- Prévoyez une clause de garantie de non-contrefaçon adaptée à l’usage d’IA générative dans votre contrat de prestation, précisant l’étendue réelle des vérifications effectuées.
- Informez explicitement votre client que le code a été produit avec assistance IA, et communiquez si un audit de licences a été réalisé ou non.
- Faites réaliser un scan de licences (analyse de composition logicielle) avant toute livraison sur un projet commercial sensible.
- Ajustez votre clause de responsabilité si le budget du projet ne permet pas un audit complet, plutôt que de garder un silence qui vous exposerait davantage.
Ce n’est pas une raison d’arrêter d’utiliser ces outils avec vos clients, c’est une raison de cadrer contractuellement ce que vous livrez, exactement comme vous le feriez pour n’importe quelle prestation de développement classique.
Comment sécuriser la propriété de votre code généré par IA
- Privilégiez un outil qui exporte du code standard (React, Next.js, etc.) plutôt qu’un environnement propriétaire fermé, si votre produit a vocation à durer ou à être valorisé.
- Documentez votre intervention humaine : historique de commits, choix d’architecture, corrections, refactoring, c’est ce qui peut démontrer l’originalité nécessaire au droit d’auteur en cas de litige.
- Exportez régulièrement votre code vers un dépôt GitHub que vous contrôlez, indépendamment de la plateforme utilisée pour le générer.
- Faites vérifier les licences des dépendances avant toute commercialisation sérieuse, pour écarter le risque de contamination copyleft.
- Faites relire le code par un humain avant une mise en production durable, pas seulement pour la sécurité et le RGPD, mais aussi pour transformer un assemblage de prompts en un actif réellement défendable.
Le cas critique : vendre ou lever des fonds sur une app vibe-codée
C’est le moment où cette question cesse d’être théorique. Un acquéreur ou un investisseur qui audite votre produit (« due diligence ») va vérifier deux choses : que le code vous appartient réellement, et qu’il est exploitable indépendamment de la plateforme qui l’a généré. Un projet coincé dans un environnement propriétaire, ou dont l’originalité humaine n’est pas démontrable, perd immédiatement en valeur, voire devient bloquant pour la transaction.
Plus votre ambition est grande, plus tôt vous devez traiter cette question, pas au moment de la levée de fonds, mais dès la construction du produit.
Besoin de faire relire et sécuriser votre code vibe-codé ?
Un échange court pour évaluer votre application, identifier les risques (juridiques, techniques, RGPD) et voir ce qui doit être consolidé avant une mise en production durable ou une levée de fonds. Sans engagement, sans jargon.
FAQ, Droit d’auteur et code généré par IA
Qui possède le code généré par Lovable, Bolt ou v0 ?
Contractuellement, ces plateformes indiquent que vous êtes propriétaire du code et des applications que vous construisez, sans revendication de leur part. Cela reste toutefois un droit d’usage et d’exploitation, distinct de la protection par le droit d’auteur, qui exige une originalité humaine démontrable.
Un code généré uniquement par IA est-il protégé par le droit d’auteur ?
Pas automatiquement. Le droit d’auteur français exige l’empreinte de la personnalité d’un auteur humain. Un code produit sans intervention créative significative (choix d’architecture, corrections, arbitrages) se trouve dans une zone grise juridique, avec un risque d’absence d’exclusivité réelle.
Quelle est la différence entre Lovable, Bolt et un outil no-code comme Bubble ?
Lovable et Bolt génèrent du code standard (React, Next.js…) exportable vers GitHub, que vous pouvez héberger et faire évoluer où vous voulez. Bubble repose sur un moteur de workflow propriétaire : votre application reste dépendante de la plateforme, sans code source exportable et réutilisable ailleurs.
Peut-on vendre ou lever des fonds sur une application vibe-codée ?
Oui, mais l’acquéreur ou l’investisseur vérifiera que le code est réellement exploitable indépendamment de la plateforme qui l’a généré, et que son originalité peut être démontrée. Un projet enfermé dans un environnement propriétaire perd en valeur lors de cette vérification.
Le code généré par IA peut-il contenir du code sous licence GPL sans que je le sache ?
C’est un risque théorique identifié : les modèles sont entraînés sur du code open source, dont certains sous licence copyleft (GPL). Une reproduction non détectée pourrait créer une obligation de publier votre propre code. Le risque reste rare sur de petits projets, mais mérite une vérification avant toute commercialisation à grande échelle.
Qui est responsable si un développeur livre à son client du code contenant une licence tierce non déclarée ?
C’est en général le prestataire, pas le client final, qui en répond en premier lieu. Un professionnel est tenu à une obligation de délivrance conforme et à une garantie proche de la garantie d’éviction : le client doit pouvoir exploiter le logiciel sans être inquiété par les droits d’un tiers. L’usage d’une IA générative ne décharge pas le développeur de cette responsabilité.
Sources
Les informations contractuelles de cet article ont été vérifiées directement dans les conditions générales des solutions citées, à la date de publication soit le 21.08.2026
- Lovable, Product Terms : lovable.dev/product-terms
- Bolt.new / StackBlitz, Terms of Service : stackblitz.com/terms-of-service et support.bolt.new
- Vercel (v0), Terms of Service et AI Product Terms : vercel.com/legal/terms et vercel.com/legal/ai-product-terms
- Bubble, documentation officielle sur la propriété des applications : manual.bubble.io
- Base44, Terms of Service : base44.com/terms-of-service, et analyse pratique de l’export : perpet.io
- Cursor (Anysphere), Terms of Service : cursor.com/terms-of-service
- GitHub Copilot, Product Specific Terms : github.com/customer-terms
- Replit, Terms of Service : replit.com/terms-of-service
- Webflow, Terms of Service : webflow.com/legal/terms, et analyse du verrouillage propriétaire : broworks.net
- Code de la propriété intellectuelle, article L112-2 (logiciels protégés) : legifrance.gouv.fr
- Code de la propriété intellectuelle, article L113-9 (droits sur les logiciels créés par un salarié) : legifrance.gouv.fr
Les conditions générales des plateformes évoluent régulièrement : il est recommandé de vérifier les liens ci-dessus avant toute décision juridique importante.