Comment exporter et posséder le code de mon app générée par IA ?

Réponse courte : connecte le projet à un dépôt GitHub dans un compte que tu contrôles, ce que tous les plans de Lovable, Bolt, v0 et Replit permettent et que Base44 propose à partir de son plan Builder, puis exporte séparément ce que le dépôt ne contient jamais : tes données, tes comptes utilisateurs, tes fichiers, tes secrets et ta configuration de production. Les conditions d'utilisation des cinq plateformes t'attribuent le code généré ; ce qui décide si tu possèdes vraiment l'app, c'est ta capacité à la faire tourner sans la plateforme.

Tout ce qui suit a été vérifié à la source le 13 septembre 2026, dans la documentation officielle et les conditions d'utilisation de chaque outil. Ces pages changent souvent : regarde la date de la page avant d'agir sur un détail.

Ce que « exporter » donne, plateforme par plateforme

Chaque outil offre un moyen de sortir les fichiers. Les différences tiennent au plan requis, au fait que la copie reste ou non synchronisée avec l'éditeur, et surtout à l'endroit où vit le reste de l'app.

Lovable

La connexion GitHub est disponible sur tous les plans et fonctionne dans les deux sens : ce que tu changes dans Lovable est enregistré dans le dépôt, et ce que tu pousses sur la branche connectée revient dans l'éditeur. Le dépôt est créé dans le compte ou l'organisation GitHub de ton choix : assure-toi que ce compte est le tien et que tu en es l'administrateur. Renommer le dépôt est détecté automatiquement ; le transférer vers un autre compte casse la synchro, bonne raison de le créer au bon endroit dès le premier jour. Sur les plans payants, Project settings, puis Git, propose aussi un ZIP ponctuel « Download codebase ».

Les données sont le point à regarder de près. Avec ton propre projet Supabase, la base et les comptes utilisateurs vivent déjà dans un compte que tu contrôles. Avec Lovable Cloud, la documentation indique qu'il n'existe pas de migration en un clic vers ton propre projet Supabase : tu exportes la base (structure et données, jusqu'à 5 Go, un export par 24 h), et cet export n'inclut ni les fichiers du stockage, ni le code des fonctions serveur, ni les secrets, que tu déplaces séparément. Les exports ne peuvent plus être téléchargés une fois Cloud retiré du projet : exporte d'abord, retire ensuite.

Bolt

Clique sur le titre du projet, puis Export et Download, pour obtenir un ZIP ; le centre d'aide précise qu'il faut Node.js sur ta machine pour le lancer. L'intégration GitHub enregistre ton travail automatiquement, relit GitHub toutes les 30 secondes pour récupérer les changements faits hors de Bolt, et ne peut être gérée que par le propriétaire du projet. Si l'app utilise Bolt Database, les données vivent dans un compte géré par Bolt tant que tu ne les réclames pas : Database, puis Advanced, puis Claim déplace la base dans ta propre organisation Supabase, à condition d'en être le propriétaire. Attention au mouvement inverse : connecter une autre base Supabase à un projet qui a déjà une Bolt Database remplace la connexion, et la documentation prévient que cela peut perdre des données.

v0

Quand tu connectes GitHub, v0 crée un dépôt privé dans ton compte et y pousse le code courant ; à partir de là, dit la documentation, ce dépôt « devient la source de vérité du code de ton projet ». Tu peux aussi télécharger un ZIP depuis le menu du projet. Ce que le dépôt ne contient pas : les variables d'environnement du projet Vercel, le domaine, et le service de données que tu as branché (Neon, Supabase, Upstash ou un autre), chacun avec son propre compte et sa propre procédure d'export.

Replit

Le menu à trois points en haut de l'arborescence propose « Download as zip » ; le panneau Git connecte le projet à GitHub, avec une option de synchro automatique dans les deux sens. La documentation est explicite sur ce qu'une copie du projet n'inclut pas : les secrets, la base de données et la configuration de déploiement doivent être recréés de l'autre côté. Un détail d'organisation : un administrateur Enterprise peut activer « Ban source code export », auquel cas le téléchargement ZIP disparaît pour les membres, donc demande avant de compter dessus.

Base44

La synchro GitHub bidirectionnelle demande le plan Builder ou supérieur ; un téléchargement ZIP existe aussi. Le projet exporté contient l'interface (src/), les fonctions serveur (functions/) et les définitions d'entités, et dépend du paquet @base44/sdk. Ce dernier point compte : la documentation indique qu'avec l'intégration GitHub, « les entités sont gérées dans Base44 et ne sont pas incluses dans ton dépôt local ». Tes tables et leur contenu restent sur la plateforme ; elles s'exportent table par table en CSV depuis Dashboard, puis Data. Faire tourner le code ailleurs revient donc à remplacer les appels au SDK par une base, un service d'authentification et des intégrations à toi, ce qui relève de la conception plutôt que du téléchargement.

Claude Code, Codex, Cursor et les autres agents

Rien à exporter : ces outils écrivent directement dans un dossier de ta machine, et le code vit là où tu le pousses. La question de propriété se déplace vers le dépôt distant : quel compte GitHub, GitLab ou Bitbucket l'héberge, qui en a les droits d'administration, et si la personne qui a piloté l'agent était toi, un freelance ou une agence sur son propre compte. Les conditions commerciales d'Anthropic (17 juin 2025) cèdent au client les droits d'Anthropic sur les résultats et excluent tout entraînement dessus ; celles d'OpenAI te cèdent ses droits sur l'Output ; celles de Cursor (3 septembre 2026) font de même pour ses « Suggestions ». La checklist des basiques couvre l'hygiène des comptes qui va avec.

Les cinq choses qui ne voyagent jamais avec le code

Un dépôt contient l'interface, les fonctions serveur, les migrations de la base et les fichiers de configuration vidés de leurs valeurs. Cinq choses restent sur place, et chacune a sa propre porte.

1. Les données. Les lignes de la base s'exportent par un mécanisme distinct : un dump SQL, un CSV par table, ou la réclamation de la base dans ton propre compte. Teste l'import ailleurs avant de compter dessus.
2. Les comptes utilisateurs. Les emails et les profils s'exportent en général ; les mots de passe sont stockés sous forme de hachages, et leur transfert entre services d'authentification ne fonctionne que dans des cas précis. Prévois une réinitialisation de mot de passe ou un email « reconnecte-toi ».
3. Les fichiers. Documents et images déposés vivent dans un espace de stockage, pas dans la base. L'export de Lovable Cloud, par exemple, les exclut explicitement.
4. Les secrets. Les clés des services de paiement, d'email ou d'IA n'ont rien à faire dans un dépôt. Tu les recrées sur la cible, ce qui suppose de savoir où chacune a été émise.
5. La configuration de production. Domaine, enregistrements DNS, certificats, tâches planifiées, journaux, alertes et adresse d'expédition de tes emails transactionnels. Si le domaine est enregistré dans le compte de quelqu'un d'autre, l'app n'est toujours pas à toi.

Es-tu légalement propriétaire du code généré par IA ?

La propriété s'empile en trois couches, et c'est la confusion entre elles qui bloque les projets. Cette section rapporte les faits vérifiés ; ce n'est pas un avis juridique, et un contrat ou un litige mérite un avocat.

Couche 1 : le contrat dit que c'est à toi

Toutes les grandes plateformes t'attribuent le code généré. Les conditions de Lovable (version du 28 août 2026) : « you own your Customer Data, including the applications, websites, or other projects you build using the Services », et « you also own any AI Output generated for you ». Celles de Base44 (Wix.com Ltd, 22 juin 2026) : « the Customer owns all rights, title and interest in the code and applications generated by the Platform ». Les AI Product Terms de Vercel (17 mars 2026) te cèdent « Vercel's rights, if any, in the Output » et ajoutent que « the Output may not be unique ». Replit (3 août 2026) : « you retain any and all of your rights to any content you submit ». Bolt fonctionne sous les conditions de StackBlitz, datées du 10 janvier 2024, selon lesquelles « StackBlitz does not claim any ownership rights », sans aucune clause sur l'IA.

Lis le paragraphe suivant de chaque document, parce que c'est là que vit la licence que tu accordes en retour. Lovable prend une licence « worldwide, perpetual, royalty-free » sur tes Customer Data pour ses besoins commerciaux, entraînement de modèles compris, et te permet de la refuser à tout moment, gratuitement et quel que soit ton plan. La licence de Base44 est « irrevocable, non-exclusive, worldwide, royalty-free, perpetual » et couvre l'entraînement de modèles et le marketing. Vercel peut entraîner ses modèles sur le contenu des plans Hobby et Pro d'essai, désactive l'entraînement par défaut sur les plans Pro payants, et offre une garantie contractuelle aux clients Enterprise. Rien de tout cela ne retire ta propriété. Cela signifie que « le code est à toi » et « toi seul peux utiliser le code » sont deux phrases différentes.

Couche 2 : le droit d'auteur protège ce qu'un humain a décidé

Aux États-Unis, le rapport du Copyright Office du 29 janvier 2025 conclut qu'un résultat généré par IA sans apport humain suffisant ne peut pas être protégé, que les prompts seuls ne constituent pas un acte d'auteur, et que les parties humaines d'une œuvre mixte peuvent l'être. Le 18 mars 2025, la cour d'appel du circuit de D.C. a confirmé dans Thaler v. Perlmutter qu'une IA ne peut pas être auteur, et la Cour suprême a refusé de réexaminer cette décision le 2 mars 2026.

Dans l'Union européenne, la Cour de justice exige depuis Infopaq (2009) et Painer (2011) qu'une œuvre soit « la création intellectuelle propre à son auteur », reflet de choix libres et créatifs. Il n'existe pas encore de règle européenne spécifique aux résultats d'IA ; une étude publiée par le Parlement européen en juillet 2025 lit la jurisprudence de la même façon : taper un prompt ne fait pas de toi un auteur, sélectionner, itérer, éditer et combiner peut le faire. Le droit belge (Code de droit économique, livre XI) applique le même critère d'originalité.

Lecture pratique : l'architecture que tu as choisie, le code que tu as modifié, les tests que tu as écrits et la façon dont tu as assemblé les pièces sont à toi et protégeables. Un bloc généré d'un coup et jamais retouché repose sur un terrain plus fragile et, comme le notent les conditions de Vercel, peut être servi à un autre utilisateur. Pour une entreprise, cela compte rarement au quotidien. Cela compte lors d'une due diligence, d'un rachat ou d'un litige avec un ancien prestataire, et c'est pourquoi la troisième couche pèse plus que les deux premières.

Couche 3 : le contrôle, c'est ce que tu peux réellement faire tourner

La couche qui décide de tout est opérationnelle. Tu possèdes l'app quand le dépôt est dans un compte que tu administres, quand les données peuvent être exportées puis importées ailleurs, quand les comptes utilisateurs et les fichiers sont récupérables, quand chaque secret peut être réémis, et quand le domaine et l'adresse d'expédition de tes emails sont enregistrés à ton nom. Chacun de ces points est un réglage ou un compte, et aucun ne figure dans un contrat. Une app peut très bien rester sur Lovable et rater ce test sur le seul domaine.

Le test de propriété en 20 minutes

Fais-le sur une machine qui n'a jamais ouvert le projet, ou demande à un développeur de le faire pendant que tu regardes.

1. Clone le dépôt depuis ton propre compte. S'il te faut l'identifiant de quelqu'un d'autre pour y arriver, arrête-toi et corrige ça d'abord : transfère ou recrée le dépôt sous ton organisation.
2. Installe et construis. npm install, puis npm run build, ou les équivalents indiqués dans le README. Cela doit aboutir sans fichier caché venu de la plateforme et sans paquet manquant.
3. Liste les variables sans leurs valeurs. Un fichier .env.example ou une section du README doit nommer chaque clé dont l'app a besoin. Si la liste n'existe pas, écris-la maintenant, tant que la plateforme t'affiche encore les réglages.
4. Exporte les données et importe-les ailleurs. Un dump chargé dans une base vide, ou un CSV ouvert dans un tableur, selon l'app. Compte les lignes.
5. Vérifie les comptes. Registrar du domaine, projet de base de données, hébergement, prestataires de paiement et d'email : chacun doit appartenir à l'adresse email de ton organisation, avec la double authentification activée et un second administrateur nommé.
6. Retrouve l'origine de chaque secret. Pour chaque clé, note quel tableau de bord l'a émise et qui peut la renouveler.

Six coches et tu possèdes l'app au sens qui compte. Un raté et tu sais exactement quoi corriger, ce qui est déjà l'essentiel du travail.

Que faire quand un point échoue

Le dépôt est dans le compte d'un prestataire : demande un transfert vers ton organisation, puis reconnecte la plateforme au nouvel emplacement, puisque Lovable et v0 lient la synchro à un dépôt précis. La construction échoue hors de la plateforme : le code dépend de quelque chose que la plateforme fournit, le plus souvent un SDK ou un fichier d'environnement, et un développeur doit le nommer avant que quiconque parle de migration. L'export des données n'est pas documenté : lance-le maintenant, dans un moment calme plutôt qu'en plein incident, et note les limites (5 Go et une cadence de 24 h chez Lovable Cloud, CSV table par table chez Base44). Le domaine ou l'expéditeur des emails appartient à la plateforme : branche un sous-domaine de ton entreprise et déplace l'adresse d'expédition, deux points couverts dans la checklist de lancement.

Rien de tout cela n'oblige à quitter la plateforme. Lovable, Bolt, v0, Replit et Base44 peuvent rester le bon endroit pour construire ; l'enjeu est de pouvoir partir, ce qui change la conversation avec tes clients, tes investisseurs et ton prochain développeur. Quand la carte n'est pas claire, le Scan la dresse sur ton projet réel : code, données, comptes, fichiers, secrets et production, chacun avec sa preuve et son action recommandée, sans présumer qu'une migration s'impose.