MVP en no-code ou en code : comment choisir quand on est founder

La plupart des comparatifs no-code répondent à une question que vous ne vous posez pas : quel est le meilleur outil ? Ils classent Bubble, Webflow, Softr et une dizaine d’autres avec des notes sur dix, comme si un outil pouvait être bon dans l’absolu. Un founder qui démarre a une question plus étroite et plus utile : sur quoi construire la première version de ce produit-là, sachant ce qu’elle doit prouver, ce qu’elle va devoir porter, et ce que coûtera d’en changer le jour où elle ne suffira plus ?

Cet article ne note aucun outil. Il donne une grille de six critères, l’applique à Bubble, Webflow et Softr, puis à la troisième voie apparue depuis : les générateurs de code par IA comme Lovable, Bolt ou v0. Il dit aussi dans quels cas le no-code est le bon choix. Ils sont plus nombreux que ce qu’un studio de développement a intérêt à admettre.

Ce que vous choisissez vraiment

Choisir entre no-code et code, ce n’est pas choisir une technologie. C’est choisir qui porte le risque technique, et à quel moment.

Avec un outil no-code, l’éditeur porte l’hébergement, la sécurité de la plateforme et les mises à jour ; vous acceptez en échange ses limites, ses prix et son calendrier. Avec du code, vous portez tout, mais rien ne vous est imposé. Avec un générateur IA, vous avez du code dès le premier jour, mais personne n’a vérifié ce qu’il contient. Les coûts tombent donc à des moments différents : au départ pour le code, à la sortie pour le no-code, à l’ouverture aux clients pour le généré.

Six critères pour trancher

1. Ce que la première version doit prouver, et en combien de temps

Si la question est « est-ce que quelqu’un paie pour ça ? », le produit n’a pas besoin d’exister en entier. Une page, un formulaire, un traitement à la main derrière, et parfois un portail no-code suffisent à obtenir une réponse en quelques semaines. Avant même de choisir un outil, vérifiez que vous avez besoin d’un produit pour valider : plusieurs tests coûtent moins de 2 000 € et répondent plus vite.

Si la question est de savoir si le produit tient en usage réel, chez des clients qui paient, on n’est plus dans la validation mais dans la construction, et ce critère penche moins vers le no-code.

2. La logique métier

C’est le critère le plus discriminant, et le plus mal évalué. La question n’est pas « mon produit est-il complexe ? » mais « ma valeur tient-elle dans des règles que je dois maîtriser finement ? »

Un annuaire, un portail client, un outil de réservation simple, un tableau de bord sur des données existantes : la logique est standard, l’outil la couvre. Un calcul de prix qui dépend de dix paramètres, un moteur de rapprochement, des droits d’accès qui varient selon l’organisation, le rôle et l’état d’un dossier : la logique est le produit. Exprimée dans un éditeur visuel, elle devient vite difficile à relire, à tester et à faire évoluer sans casser autre chose.

Un bon test : essayez d’écrire vos règles métier en une page de phrases simples. Si la page tient, un outil no-code les portera. Si elle déborde en exceptions et en cas particuliers, c’est le signe qu’il vous faudra du code tôt ou tard.

3. Les données sensibles

Données de santé, données financières, données personnelles de vos clients B2B : la question est aussi commerciale. Le premier client sérieux vous demandera où sont hébergées ses données, qui y a accès et comment vous les supprimez à la fin du contrat. Avec un outil no-code, la réponse dépend de ce que l’éditeur propose dans votre formule. S’il ne donne pas la réponse que vos clients exigent, l’outil est éliminé, quelles que soient ses autres qualités.

4. La montée en charge

Pour un MVP, la montée en charge est rarement le vrai sujet : quelques centaines d’utilisateurs ne font tomber aucune plateforme sérieuse. Le sujet, c’est le coût de la montée en charge. Les plateformes no-code facturent de plus en plus à l’usage : nombre de lignes, d’appels, d’utilisateurs ou d’unités de calcul. Votre facture suit alors votre succès, et parfois plus vite que votre chiffre d’affaires.

Avant de choisir, regardez quelle unité l’outil facture, et estimez-la pour dix fois votre volume actuel. C’est un calcul d’une heure qui évite les mauvaises surprises au moment où le produit décolle.

5. Propriété et réversibilité

Que possédez-vous réellement à la fin ? Il y a trois niveaux, et ils ne se valent pas :

• les données : pouvez-vous les exporter complètes, dans un format lisible, sans demander la permission ?
• la logique : vos règles métier existent-elles ailleurs que dans l’éditeur ?
• le code : pouvez-vous faire tourner le produit sans la plateforme ?

La plupart des outils no-code vous laissent le premier niveau, rarement le deuxième, presque jamais le troisième. Ce n’est pas un défaut caché, c’est le modèle. Il faut juste le savoir avant de construire, pas le découvrir au moment de partir.

6. Le coût de la sortie, plus tard

C’est le critère que tout le monde oublie, parce qu’il ne coûte rien le premier jour. Il découle directement du précédent : si seules les données sortent, quitter la plateforme veut dire reconstruire toute l’application en code, en se servant de l’ancienne comme spécification. Si le code sort, quitter veut dire reprendre ce code, ce qui est un autre ordre de grandeur.

Posez-vous la question franchement : si ce produit marche, combien de temps vais-je rester sur cet outil, et qu’est-ce que je devrai refaire pour en partir ? Une réponse du type « six mois, puis tout réécrire » est acceptable, à condition de l’avoir décidée et budgétée.

La grille en un tableau

Bubble : un vrai back-end, qui ne vit que chez Bubble

Bubble est le seul des outils de cette liste qui prétend porter une application complète : base de données, logique, interface, comptes utilisateurs. C’est ce qui en fait le candidat naturel pour un MVP no-code, et c’est aussi ce qui rend le critère de réversibilité décisif.

Bubble est explicite sur ce point. Son centre d’aide indique que les données créées par vos utilisateurs peuvent être exportées en fichiers CSV, mais qu’il n’existe aujourd’hui aucun moyen d’exporter une application sous forme de code (consulté le 14 octobre 2026). En cas de départ, Bubble peut fournir un export brut de la logique et du design au format JSON : c’est utile comme documentation, pas comme point de départ d’une nouvelle application. Partir de Bubble, c’est donc reconstruire.

Deuxième point à regarder : la facturation. Bubble compte l’usage en workload units, une mesure de la charge de calcul de votre application. Au 14 octobre 2026, la page tarifs affiche par exemple une formule Starter à 59 $ par mois en facturation annuelle, avec 175 000 unités incluses, et un dépassement facturé à l’usage au-delà. Ce que consomme une application dépend de la façon dont ses workflows sont écrits : deux applications identiques à l’écran peuvent consommer des volumes très différents. Si vous partez sur Bubble, surveillez cette consommation dès les premiers utilisateurs.

Bubble a du sens pour un produit dont la logique reste standard, construit par un founder qui veut itérer seul, avec la décision explicite de le réécrire si le produit trouve son marché. Il en a moins quand la logique métier est le cœur de la valeur ou quand vous savez déjà que vous lèverez des fonds sur la base de ce produit.

Webflow : un excellent site, pas une application

Webflow n’est pas un outil de MVP au sens d’un produit logiciel. C’est un outil de site : pages, contenu, CMS, animations. Pour la page qui présente votre produit, recueille des inscriptions ou teste un positionnement, c’est souvent un très bon choix, et un développeur n’a aucune raison de vous en dissuader.

Ses limites apparaissent dès qu’on lui demande d’être le produit. Côté réversibilité, Webflow permet d’exporter le code d’un site, mais son centre d’aide précise que le contenu du CMS, les comptes utilisateurs et l’e-commerce ne font pas partie de l’export, que les formulaires et la recherche ne fonctionnent plus sur un site exporté, et que l’export est réservé à certaines formules (consulté le 14 octobre 2026). Ce qui sort, c’est la partie statique.

Le bon usage : Webflow pour le site marketing, à côté d’un produit construit ailleurs. Les deux vivent très bien ensemble, et ce découpage vous laisse changer l’un sans toucher à l’autre.

Softr : une interface au-dessus de vos données

Softr fait une chose précise : construire des portails, des espaces clients et des outils internes au-dessus d’une source de données. Sa documentation liste notamment Airtable, Google Sheets, Notion, Supabase et des bases SQL comme PostgreSQL, en plus de sa propre base, Softr Databases.

Ce modèle a un avantage rare en no-code : pour les sources externes, Softr indique qu’il ne stocke ni ne synchronise vos données et se connecte directement à la source, avec un cache de 24 heures (consulté le 14 octobre 2026). Si cette source est une base PostgreSQL ou Supabase que vous contrôlez, vos données ne sont jamais prisonnières de l’outil. Le jour où vous remplacez l’interface par du code, la base reste en place. La même page note la contrepartie : les sources externes imposent leurs propres limites de requêtes, qui deviennent la contrainte quand le nombre d’utilisateurs augmente.

Softr a du sens pour un portail client, un annuaire ou un outil interne dont la logique est simple et dont les données ont déjà, ou doivent avoir, une vie propre. Il en a moins quand l’essentiel de la valeur se joue dans des règles métier ou dans une expérience très spécifique.

Lovable, Bolt et v0 : la troisième voie

Les générateurs de code par IA ont changé la question. On décrit le produit en langage naturel, l’outil écrit une application, le plus souvent en React avec une base Supabase, et l’héberge. La différence avec le no-code est structurelle : il y a du code, et il vous appartient.

• Lovable synchronise le projet avec un dépôt Git que vous possédez, dans les deux sens, et le dépôt reste intact si vous vous déconnectez ;
• Bolt permet de télécharger le projet en archive ou de le relier à GitHub ;
• v0 pousse le code vers un dépôt GitHub qui devient la source de vérité du projet.

(Documentation des trois outils consultée le 14 octobre 2026.)

Ce que ces outils ne changent pas, c’est l’écart entre une démo et un produit ouvert à des clients payants. Les failles les plus fréquentes ne sont pas dans le code affiché à l’écran, mais dans ce que personne n’a demandé : les règles d’accès à la base. En mai 2025, Matt Palmer a publié l’analyse de 1 645 applications de la vitrine Lovable : 170 d’entre elles, soit environ 10,3 %, avaient des règles d’accès insuffisantes, au point que leurs tables pouvaient être lues sans connexion. En février 2026, The Register rapportait qu’un chercheur avait relevé 16 failles, dont 6 critiques, sur une seule application hébergée par Lovable, exposant 18 697 enregistrements d’utilisateurs, en partie à cause d’une fonction d’authentification dont la logique était inversée.

Posséder le code ne veut donc pas dire posséder un code prêt. Avant d’ouvrir le produit à des clients, il faut au minimum relire les règles d’accès de la base, chercher les secrets exposés dans le code envoyé au navigateur, et vérifier que les paiements et les e-mails tiennent ailleurs qu’en démo. C’est le travail que nous avons fait sur une douzaine d’applications générées par IA, reprises et mises en production. Si votre application tourne déjà, la liste de ce qu’il faut vérifier avant le lancement vous permet d’en juger seul, et notre audit de reprise d’app Lovable, Bolt ou v0 rend un verdict : on garde et on renforce, ou on refait.

Un générateur a du sens quand vous voulez un produit utilisable vite et la garantie de pouvoir en sortir. Il impose une condition : faire relire le code avant d’ouvrir le produit à des clients et à leurs données, pas après le premier incident. Et le jour où l’application doit changer de framework, la migration se mène par étapes, sans l’arrêter : nous l’avons décrit pour une app Lovable qui passe à Next.js.

Quand le no-code est le bon choix

Il faut le dire clairement : dans beaucoup de cas, le no-code est la meilleure décision, y compris pour un founder qui finira par faire développer son produit.

• Vous n’avez pas encore de preuve que quelqu’un paiera. Dépenser plusieurs dizaines de milliers d’euros en développement pour tester une hypothèse est un mauvais usage de votre trésorerie. Un MVP no-code, même imparfait, coûte surtout votre temps.
• Le service peut être rendu à la main derrière une interface simple. Beaucoup de produits commencent par un formulaire, une base et un founder qui traite les demandes. Le no-code est parfait pour ce mode, et ce que vous apprenez en faisant le travail à la main vaut une spécification.
• Votre produit est un portail sur des données qui existent déjà. Un espace client, un annuaire, un catalogue : Softr ou un équivalent fait le travail, et vos données restent dans votre base.
• La logique tient sur une page et restera stable. Si votre valeur est dans la distribution, la relation client ou le contenu, et pas dans le logiciel, le logiciel n’a pas besoin d’être sur mesure.

Dans tous ces cas, la seule erreur serait de ne pas décider à l’avance du moment où l’on change d’outil. Fixez un déclencheur mesurable : un nombre de clients payants, un premier contrat B2B qui exige des garanties, une règle métier que l’outil ne sait plus exprimer, une facture mensuelle qui dépasse un seuil. Quand il est atteint, la question n’est plus à rouvrir.

Quand partir en code dès le départ

À l’inverse, certains signaux justifient de commencer directement en code, ou au minimum avec un générateur dont on fait relire le résultat :

• la logique métier est votre avantage concurrentiel. La reconstruire plus tard revient à payer deux fois la partie la plus difficile du produit ;
• vous vendez à des entreprises qui poseront des questions sur l’hébergement, les accès et la suppression des données dès le premier appel d’offres ;
• le produit gère plusieurs organisations clientes, avec des données qui ne doivent jamais se croiser. L’isolation des données fait partie des fondations qu’on ne rattrape pas après le MVP ;
• la validation est faite. Vous avez des clients qui paient ou un engagement ferme. Construire sur une plateforme que vous savez devoir quitter dans six mois n’a plus de sens.

Partir en code ne veut pas dire tout construire. Un MVP en code accepte volontairement de la dette : duplication, pas de back-office, pas d’optimisation. Il refuse seulement quelques points non négociables, comme l’isolation des données, les permissions vérifiées côté serveur ou les secrets hors du dépôt. Ce tri entre dette acceptable et dette interdite est ce qui permet de livrer vite sans se condamner à réécrire.

Préparer la sortie dès le premier jour

Quel que soit votre choix, deux habitudes réduisent le coût de la sortie, et elles ne coûtent presque rien au départ.

Gardez vos données dans une source que vous contrôlez. Quand l’outil le permet, branchez-le sur une base que vous possédez plutôt que sur sa base interne. C’est la différence entre migrer une interface et migrer une entreprise.

Écrivez vos règles métier hors de l’outil. Un document simple, tenu à jour : qui peut faire quoi, comment se calcule un prix, ce qui se passe quand un abonnement échoue. Le jour de la reprise, ce document vaut plus que l’application elle-même, parce qu’il dit ce qui est voulu et ce qui est accidentel.

Ce qu’on ferait à votre place

Si vous n’avez pas encore validé votre idée, commencez sans développement, ou avec l’outil no-code qui colle le mieux à votre cas, et fixez dès aujourd’hui le déclencheur qui vous en fera sortir. Si vous voulez un produit rapidement et la certitude de pouvoir le faire évoluer, un générateur IA est souvent le meilleur compromis, à condition de faire relire le code avant les premiers clients. Si la validation est faite et que la logique métier est votre valeur, partez en code, avec un périmètre serré.

Dans ce dernier cas, deux lectures vous feront gagner du temps : ce que contient vraiment un devis de MVP, pour comparer des propositions qui ne chiffrent pas la même chose, et notre façon de construire un MVP SaaS, si vous voulez en discuter avec nous.