Comment le vendor lock-in fonctionne réellement dans les outils no-code et les builders IA : pourquoi l'app que vous avez construite risque de ne pas survivre à votre abonnement, les promesses d'export qui ne sont pas de vraies portes de sortie, cinq questions qui révèlent la vérité avant de vous engager, et comment garder la vitesse de construction sans renoncer à la propriété.
Fondateurs et opérationnels qui ont construit, ou s'apprêtent à construire, sur une plateforme no-code ou IA et qui veulent rester libres de partir.
- Une vision précise de ce qu'est le lock-in et du moment où il commence à vous coûter
- Le test de l'export factice, qui perce toutes les promesses rassurantes
- Cinq questions qui révèlent qui possède quoi avant d'engager un projet
La façon la plus rapide de construire peut devenir, sans bruit, l'endroit le plus coûteux où rester coincé. Le lock-in ne s'annonce jamais sur la page tarifs ; il apparaît le jour où vous essayez de partir et découvrez que ce que vous avez construit ne peut pas vous suivre. Voici comment le piège fonctionne vraiment, comment repérer les exports qui ne sont pas de vraies sorties, et comment garder la vitesse sans porter la cage.
Le lock-in signifie que ce que vous avez construit n'existe qu'à l'intérieur de la plateforme d'un seul éditeur : l'app tourne sur son runtime, la logique vit dans son format, et les données reposent dans son schéma. Arrêtez de payer et l'app s'arrête ; voulez partir et il n'y a rien de portable à emporter. Vous possédez un compte, pas une application. Le test est simple : un développeur pourrait-il faire tourner et maintenir votre app sur un serveur que vous contrôlez, sans l'éditeur ? Si non, vous êtes verrouillé.
Ce qui rend ce piège efficace, c'est que tout ressemble à de la propriété vu de l'intérieur. Vous avez créé l'app, elle porte votre marque, vos clients l'utilisent chaque jour. L'écart entre ce sentiment et la réalité juridique et technique n'apparaît qu'au moment de la sortie, c'est-à-dire au moment le plus coûteux possible pour le découvrir. À ce stade, le coût de la reconstruction est votre position de négociation, et l'éditeur le sait.
Et le jour de la sortie arrive plus souvent qu'on ne le prévoit : une hausse de prix que vous ne pouvez pas absorber, une fonctionnalité que la plateforme ne construira jamais, un rachat qui change les conditions, ou simplement votre produit qui dépasse le gabarit. Une reconstruction sur mesure coûte entre 15 000 et 300 000 dollars, ce qui est précisément la rançon qu'une position verrouillée remet entre les mains de votre éditeur.
Parce que les acheteurs ont appris à poser la question du lock-in, les éditeurs ont appris à répondre avec des fonctionnalités qui sonnent comme de la liberté et ne changent rien. Apprenez à entendre la différence, car les formulations sont soigneusement choisies et les distinctions bien réelles.
Un fondateur demande à deux plateformes ce qui se passe s'il résilie. Plateforme A : « vous pouvez exporter toutes vos données à tout moment », c'est-à-dire des fichiers CSV de lignes. Plateforme B : « votre projet est un dépôt de code ; voici comment le faire tourner chez n'importe quel hébergeur », c'est-à-dire que le produit lui-même part avec lui. Les deux réponses rassurent en rendez-vous commercial. Une seule des deux est une sortie, et la différence vaut exactement une reconstruction complète.
Un développeur compétent pourrait-il prendre ce que vous avez construit, le faire tourner sur une infrastructure que vous contrôlez, et continuer à l'améliorer avec des outils ordinaires, sans le runtime ni la permission de l'éditeur ? Oui signifie que vous possédez une application. Toute autre réponse signifie que vous possédez un abonnement.
Posez ces questions avant de confier un vrai projet à une plateforme, et exigez des réponses claires. Les réponses évasives sont des réponses.
Il est tentant de classer tout cela dans les problèmes pour plus tard. C'est mal comprendre la mécanique du coût : le lock-in pèse sur votre position en continu, pas seulement au moment de la sortie.
Votre coût de migration est le plafond de ce qu'un éditeur peut vous facturer, et quand migrer signifie tout reconstruire, ce plafond est très haut. Les négociations de renouvellement le reflètent. Posséder votre code garde l'éditeur honnête année après année, parce que partir reste toujours une option réelle.
Toute plateforme fermée a une frontière, et les produits qui réussissent finissent par la trouver : l'intégration qu'elle ne gérera pas, la règle que son modèle ne peut pas exprimer, la performance qu'elle ne peut pas fournir. Sur une fondation fermée, cette frontière est un mur derrière lequel vous attendez. Sur une fondation ouverte, c'est la ligne où vous commencez à modifier le code directement.
Une entreprise qui tourne sur un logiciel qu'elle possède accumule un actif : quelque chose que vous pouvez héberger n'importe où, confier à un développeur, ou vendre avec la société. Les mêmes flux de travail construits dans une plateforme fermée sont un passif permanent déguisé en progrès, et une due diligence les traite exactement comme tel.
Pendant une décennie, la réponse honnête était non, et ce compromis a bâti l'industrie du no-code. Les builders visuels vous donnaient la vitesse et prenaient votre liberté ; écrire du code de zéro vous donnait la liberté et prenait vos mois. La plupart des gens choisissaient rationnellement la vitesse en espérant que le mur resterait loin.
La construction par IA a dissous ce compromis. Vous pouvez désormais décrire ce que vous voulez en langage courant, obtenir le jour même une application fonctionnelle avec une vraie base de données et une authentification, et repartir avec du vrai code source modifiable et vos propres données, hébergés où vous voulez, maintenables avec des outils ordinaires, extensibles au-delà de tout gabarit. La voie facile pour entrer n'exige plus une cage à la sortie.
Alors tenez chaque outil, y compris les builders IA les plus récents, au standard complet : vraie vitesse à l'entrée, vraie propriété à la sortie. Les deux existent ensemble désormais. Accepter l'un sans l'autre est un choix, et avec ce que vous savez maintenant, ce serait un choix coûteux.
Posez une seule question et exigez une réponse claire : si j'arrête de payer, un développeur compétent peut-il faire tourner et maintenir mon app sur une infrastructure que je contrôle ? Puis vérifiez pendant l'essai : cherchez du vrai code source et un schéma de base de données que vous pouvez emporter, pas un bouton d'export qui produit des tableurs.
Non. Des lignes sans le schéma, les relations, la logique et les écrans sont des enregistrements, pas un produit. Les utiliser ailleurs signifie tout reconstruire autour d'elles à partir de zéro, ce qui est exactement le coût que le no-code devait vous épargner.
Plus maintenant. Les builders IA produisent désormais une application fonctionnelle à partir d'une description en langage courant en une journée, tout en vous laissant du vrai code modifiable et vos propres données. Le compromis vitesse contre propriété qui justifiait les plateformes fermées a disparu.
Parce que le coût s'accumule pendant que vous restez : un éditeur qui sait que partir signifie tout reconstruire fixe ses prix en conséquence, et le jour où vous avez besoin d'une chose que la plateforme ne sait pas faire, vous attendez au lieu de construire. La propriété est un levier que vous tenez chaque année, pas seulement une assurance pour la sortie.