L’export de code est la fonctionnalité vers laquelle se tournent les acheteurs inquiets de l’enfermement propriétaire, et le raisonnement est logique : si vous possédez le code, aucun fournisseur ne peut vous couper l’accès ou vous imposer des tarifs prohibitifs. Mais le terme « exportable » couvre des réalités très différentes, allant d’une base de code propre exploitable partout par vos développeurs à un enchevêtrement servant de brouillon pour une reconstruction. Ce guide distingue la portabilité qui vous protège réellement de celle qui n’en a que l’apparence, et explique comment l’intégrer dans le choix d’une plateforme.
Les critères utilisés pour l’analyse sont définis dans la section /methodology.
Les deux sens du terme « enfermement propriétaire »
L’enfermement propriétaire a une dimension logicielle (code) et une dimension données, et les conséquences diffèrent.
L’enfermement au niveau du code concerne la possibilité de transférer la logique de l’application ailleurs. Bubble en est l’exemple type : il n’y a ni export du code source, ni export de l’architecture de la base de données. Partir signifie donc reconstruire chaque page, flux de travail et formulaire à partir de zéro sur la plateforme suivante. Une courbe de coûts devenue inacceptable en deuxième année n’est alors pas l’objet d’une renégociation, mais d’une décision de reconstruction ; c’est pourquoi l’enfermement doit entrer dans le calcul initial de l’achat, et non être une simple note de bas de page.
L’enfermement au niveau des données concerne la possibilité d’extraire vos enregistrements. C’est généralement l’issue la plus simple ; même sur Bubble, les lignes de données peuvent être exportées. Pour la plupart des applications métier, l’extraction des données est la partie cruciale, car la valeur de l’application réside dans ses enregistrements, pas dans le style de ses boutons.
L’export est réel, mais « exportable » ne signifie pas « maintenable »
Les outils qui exportent le code apportent une valeur réelle. Bolt télécharge des bases de code React/Vite standards avec synchronisation GitHub et sans format propriétaire. Lovable génère du React et du TypeScript que vous pouvez synchroniser avec GitHub et continuer à modifier dans VS Code ou Cursor. Replit sacrifie le prix forfaitaire mais fournit un code réellement exportable, ce qui est l’avantage concret de son modèle à crédits.
Le piège réside dans le contenu de l’export. Un utilisateur de Lovable l’explique clairement : « le code derrière n’est pas vraiment fait pour être porté proprement. La solution la plus simple est d’utiliser votre page d’accueil comme référence visuelle et de demander à votre développeur de la reconstruire ». Des avis sur G2 et Product Hunt décrivent le même obstacle : les constructeurs IA gèrent les premiers 70 % d’un projet mais peinent sur les 30 % finaux de logique métier, et beaucoup recommandent d’exporter pour terminer le développement à la main. L’export peut donc être une issue de secours ou un brouillon inachevé ; tout dépend de la qualité du code généré et des compétences de l’équipe qui le récupère.
L’export n’aide qu’une équipe capable de s’en servir
C’est le critère que la plupart des arguments de vente sur l’export occultent. Un export ne vous protège que si quelqu’un peut lire et maintenir le résultat. Pour une équipe d’ingénieurs, une base de code React/TypeScript sur GitHub est une véritable sortie et un actif réel. Pour un opérateur non technique créant un portail client, une base de code exportée n’est pas une issue ; c’est un fardeau qu’il ne peut pas ouvrir, et la maintenabilité que l’export était censé offrir s’évapore dès que le créateur original s’en va.
En d’autres termes, l’export de code améliore la maintenabilité pour les équipes disposant de développeurs, mais n’apporte rien aux équipes qui n’en ont pas. Évaluez ce point en fonction de votre équipe réelle, et non de celle présentée dans l’étude de cas du fournisseur.
L’autre moyen de désamorcer l’enfermement
Il existe une seconde réponse à l’enfermement qui ne fait aucun appel à l’export de code : supprimer la raison de partir. Une plateforme avec une facture forfaitaire prévisible et une maintenance faible crée peu de pression à l’idée de quitter l’outil, car la courbe des coûts n’explose jamais et les modifications post-lancement ne nécessitent jamais de développeur. Softr n’exporte pas non plus de code, et son évaluation le mentionne honnêtement, mais il associe un prix forfaitaire (de 49 $ à 269 $/mois facturés annuellement, sans compteur d’utilisation) à un score de maintenabilité de 9,0. Ainsi, la discussion sur la reconstruction en deuxième année, qu’impose Bubble, ne commence presque jamais. L’export de données couvre les enregistrements ; la facture forfaitaire couvre le reste.
C’est l’arbitrage à faire : l’export de code offre une sortie aux équipes capables de s’en servir, tandis que le prix forfaitaire allié à une maintenance faible supprime l’envie de chercher la sortie. Aucune des deux options n’est universellement meilleure ; elles répondent à des craintes différentes.
Comment intégrer la portabilité dans votre décision
Posez-vous trois questions avant de payer un supplément pour l’export. Votre équipe peut-elle réellement lire et maintenir le code exporté ? Le code est-il assez propre pour être exécuté ailleurs, ou s’agit-il d’un brouillon de reconstruction ? Et la facture de la plateforme est-elle assez volatile pour que vous ayez réellement besoin de cette sortie ? Si vous avez des ingénieurs et une facturation volatile, accordez un poids important à l’export de code et tournez-vous vers Replit ou Bolt. Si vous n’êtes pas technique et que la facture est forfaitaire, privilégiez l’export de données et la maintenabilité ; la comparaison Bubble vs Softr illustre parfaitement cet arbitrage. Commencez par les critères dans la section /methodology et le guide build vs buy pour définir vos priorités objectivement.