Chaque outil de vibe coding avec un bouton GitHub répète une variante de la même phrase : “vous possédez votre code, pas de verrouillage.” C’est sur la page de tarification, dans la FAQ, généralement juste à côté d’une coche verte. Traitez cette phrase comme une affirmation à vérifier, pas comme un fait à accepter, car l’écart entre “vous pouvez exporter un fichier” et “vous pouvez partir” est là où se cache la majeure partie du véritable verrouillage.
Ce que l‘“export” omet discrètement
Une base de code n’est pas une chose unique. C’est un frontend, un backend et une base de données, et un outil peut annoncer un “export de code” en ne parlant que du premier des trois. Base44 documente clairement cette séparation : le code source du frontend s’exporte vers GitHub, mais la logique backend est hébergée et gérée entièrement sur l’infrastructure propre de Base44, décrite dans ses propres documents comme impossible à modifier ou exporter directement. Les avis Product Hunt sur Base44 confirment ce même schéma du côté utilisateur : la base de données et le backend restent enfermés dans l’infrastructure fermée de la plateforme, même si le frontend, lui, s’en va proprement. Un utilisateur Reddit ayant essayé de vraiment quitter la plateforme rapporte s’être vu proposer une année du plan Builder à 40 $/mois, soit 480 $, juste pour accéder aux fichiers source après que son application ait planté à répétition dans une boucle de débogage.
Zite évite carrément la question. Il n’offre aucune synchronisation GitHub ni aucun export de code, ce que ses propres utilisateurs signalent sur Reddit comme un véritable obstacle au moment de la migration ou d’un transfert à un développeur. Sans bouton d’export, la conversation sur “vous possédez votre code” ne commence même pas.
Du code exporté dont vous ne voulez pas
L’autre moitié de l’illusion consiste à supposer que le code exporté est un code que quiconque choisirait de maintenir. Lovable exporte véritablement du React et du TypeScript standard, et se synchronise avec GitHub pour le développement local, ce qui est un vrai atout. Mais les retours de ses propres utilisateurs décrivent le résultat comme désordonné et non évolutif : un créateur l’a résumé en disant que c’était correct comme référence visuelle mais pas quelque chose à porter proprement, recommandant plutôt à un développeur de reconstruire l’application sur une vraie stack que d’hériter de celle générée. C’est cohérent avec le schéma plus large que ce site suit : la boucle de correction laisse derrière elle des fonctions utilitaires dupliquées et des styles rapiécés, parce que le modèle ne voit pas l’ensemble de la base de code qu’il modifie. L’export vous remet ce rapiéçage avec une URL GitHub attachée, pas une base de code qu’un nouveau développeur peut reprendre dès le premier jour.
Le côté base de données aggrave les choses. Des utilisateurs de Lovable sur Reddit ont qualifié la plateforme d‘“Hotel California” pour votre base de données : on peut y entrer, mais plusieurs témoignages décrivent l’IA initiant d’elle-même une migration du backend, depuis le projet Supabase privé d’un créateur vers le Supabase géré propre à Lovable, sans consentement explicite. Quelle que soit l’apparence de l’export du frontend, le backend et son schéma constituent un projet de migration à part, conçu par l’IA et que le créateur n’a peut-être jamais entièrement examiné.
Les outils qui font bien les choses, et ce que ce “bien” coûte
Bolt et v0 sont les contre-exemples honnêtes, et méritent d’être cités comme tels. Bolt documente un téléchargement direct de la base de code ainsi qu’une synchronisation GitHub automatique produisant une base de code React/Vite standard sans format propriétaire. Les propres documents de v0 décrivent les exports comme du code React et TypeScript propre et inspectable, sans couche propriétaire ni mécanisme de verrouillage. Les deux affirmations se rapprochent davantage de ce que devrait signifier “pas de verrouillage” : ce qui quitte la plateforme est ce sur quoi vous voudriez réellement continuer à construire.
Mais notez ce que cette honnêteté ne supprime pas. Un export propre vous remet quand même une base de code écrite par un modèle à la fenêtre de contexte limitée, toujours soumise au problème du deuxième jour : elle fonctionne aujourd’hui, et sa survie à six mois de changements réels dépend de si quelqu’un examine ce qu’elle contient. Un code portable est nécessaire pour éviter le verrouillage. Il ne suffit pas à éviter la facture de maintenance.
La question sous la coche
Avant de croire une affirmation d’export, trois questions séparent le marketing de la réalité. D’abord, ce qui part réellement : le frontend seul, ou le backend et la base de données avec lui. Ensuite, qui peut le lire sans l’aide de l’outil, car un code que personne dans l’équipe ne peut maintenir n’est portable que de nom. Enfin, ce qu’ont rapporté les créateurs qui ont essayé, car un fil Reddit sur des frais de sortie de 480 $ vous en apprend plus qu’une coche sur une page de tarification.
Pour les applications métier, portails, outils internes, CRM, il existe un moyen structurel de contourner toute la question : construire là où l‘“export” n’est pas du code au départ. Sur Softr, l’authentification, les permissions et la structure des données sont de la configuration de plateforme, et les données sous-jacentes peuvent résider dans des sources que vous contrôlez déjà (Airtable, Google Sheets ou SQL) ou être atteintes via la propre base de données de Softr par API et MCP, si bien qu’un créateur n’attend pas un export GitHub pour éviter de dépendre de l’infrastructure d’un seul fournisseur. C’est un compromis différent de la propriété du code, pas un substitut : vous échangez “je peux exporter le code” contre “les données n’ont jamais été piégées au départ.” Le compromis qui convient dépend de si l’application a besoin d’un développeur pour posséder une logique personnalisée, ce qui plaide pour Cursor ou Bolt, ou si elle a simplement besoin de fonctionner sans.