Lancer un MVP SaaS en 2026 : no-code ou code, on tranche

Le verdict d’abord : no-code pour valider, code pour grandir. Vous lancez un MVP SaaS pour répondre à une seule question, est-ce que des gens paient pour ça. Le no-code (Bubble, Softr, Glide) vous y amène en deux à quatre semaines pour quelques centaines d’euros. Le jour où la réponse est oui, avec des utilisateurs qui paient et qui reviennent, vous repassez en code. Et vous budgétez cette bascule dès le départ, au lieu de la découvrir comme une mauvaise surprise au sixième mois.

Je dis ça en ayant fait les deux. J’ai construit ClairDossier, une plateforme SaaS de gestion documentaire pour le secteur juridique, directement en code, parce que sa valeur tenait dans un modèle de données structuré et dans la propriété du produit par le client. Et j’ai aussi conseillé à des fondateurs de démarrer sur Bubble plutôt que de me payer trois mois de développement pour une idée pas encore validée. L’arbitrage n’est pas idéologique.

Voici la question qui tranche réellement, ce que le no-code fait mieux que le code en phase de validation, le mur qu’il rencontre au sixième mois, et la façon dont je décide concrètement avec mes clients.

La question qui tranche : votre valeur est dans l’idée ou dans l’exécution ?

Le facteur déterminant n’est pas votre budget ni votre niveau technique. C’est la nature de votre valeur ajoutée. Posez-vous une question simple : si demain un concurrent copiait votre produit, qu’est-ce qui serait dur à reproduire ?

Si la réponse est l’idée ou le workflow, vous adressez un métier que personne ne sert correctement, vous orchestrez un process que les gens font encore à la main, alors votre valeur est dans le concept. Le no-code la teste très bien, parce que ce qui compte c’est que le workflow existe, pas qu’il soit codé proprement. Bubble ou Softr posés sur Airtable suffisent à prouver que des gens paient.

Si la réponse est l’exécution, une interface que vos utilisateurs ouvrent huit heures par jour, un modèle de données qui doit tenir des cas complexes, une performance qui fait partie de la promesse, ou la propriété intellectuelle du produit, alors codez dès le premier jour. Pour ClairDossier, la valeur tenait précisément là : un dossier juridique structuré avec un historique fiable, et un client qui devait posséder son code et son hébergement sans dépendre d’un éditeur tiers. Un Bubble aurait enfermé ces données dans une plateforme que le client ne contrôlait pas, ce qui était exactement le risque que le projet voulait écarter.

Phase validation : le no-code gagne, sans débat

En phase de validation, votre seul objectif est de répondre oui ou non à la question : est-ce que des gens paient. Tout euro et tout jour dépensés ailleurs sont gaspillés. Le no-code optimise exactement ça.

Dans ma pratique, un MVP no-code fonctionnel sort en deux à quatre semaines. Le même produit codé proprement, avec authentification, base de données, paiement et un front correct, c’est deux à trois mois de développement, soit 8 000 à 15 000 euros au TJM d’un freelance senior. Pour une idée que personne n’a encore validée, c’est un pari à cinq chiffres sur une simple intuition.

La pile que je recommande à ce stade est connue : Bubble pour la logique applicative, Airtable comme base de données, Softr ou Glide quand l’interface est simple, Make ou Zapier pour les automatisations, et Stripe pour l’encaissement. Notez ce dernier point : même un MVP no-code branche le vrai Stripe pour facturer un abonnement récurrent. La facturation, elle, n’est jamais simulée. Si dix personnes sortent leur carte sur votre Bubble bricolé, vous tenez votre validation. Si personne ne paie malgré le trafic, vous venez d’économiser trois mois de code pour un produit que le marché ne voulait pas.

Le mur du no-code : ce qui casse au sixième mois

Le no-code tient tant que vous restez dans son couloir. Le problème, c’est que le succès vous en fait sortir. Voici ce que je vois casser, dans l’ordre, chez les fondateurs qui ont validé sur Bubble.

La performance plafonne. Une application Bubble avec quelques milliers d’enregistrements et des workflows imbriqués devient lente, et vous n’avez pas la main pour l’optimiser finement. Sur un SaaS que les gens utilisent tous les jours, la lenteur tue la rétention aussi sûrement qu’un bug.

Le prix grimpe par paliers que vous ne contrôlez pas. Le ticket d’une application Bubble en production tourne autour de 100 à 115 euros par mois, mais la facture monte avec la charge : capacité serveur, volume de workflows, plugins payants. Ajoutez Airtable au-delà de son offre gratuite et les connecteurs Make, et vous payez plusieurs centaines d’euros par mois pour un produit que vous ne possédez pas.

Le lock-in est réel. Vous pouvez exporter vos données, jamais votre logique. Le jour où vous migrez, vous ré-implémentez tout depuis le début. Et c’est là le piège que personne ne budgète : le re-build. Dans ma pratique, refaire en code un MVP no-code validé représente le même montant que si vous aviez codé directement, souvent 8 000 à 15 000 euros. L’économie de départ n’a pas disparu, mais elle a servi à acheter du temps et de la validation, pas un produit pérenne. Le fondateur qui croit que son Bubble va monter en charge indéfiniment se réveille au sixième mois avec une dette technique qu’il paie cash.

RGPD : l’angle que les fondateurs no-code oublient

Il y a un sujet que je vois presque toujours négligé au démarrage en no-code : la conformité RGPD. Dès que votre SaaS héberge des données personnelles de vos utilisateurs, et un SaaS en héberge quasiment toujours, votre plateforme no-code devient un sous-traitant au sens du RGPD. La CNIL est explicite : vous devez signer un contrat de sous-traitance qui encadre ce que le prestataire a le droit de faire de ces données, conformément à l’article 28 du règlement.

Deuxième point, plus épineux : où sont les serveurs ? Beaucoup d’outils no-code hébergent aux États-Unis. Vous tombez alors dans le régime des transferts de données hors UE, que la CNIL encadre strictement depuis l’arrêt Schrems II rendu en 2020. Ce n’est pas rédhibitoire, mais ça demande des garanties, clauses contractuelles types et vérification du niveau de protection, que peu de fondateurs anticipent au moment de choisir leur outil.

Je ne dis pas que le no-code est incompatible avec le RGPD. Je dis que c’est une variable de la décision, au même titre que le prix et la performance. Pour ClairDossier, qui manipulait des données juridiques sensibles, héberger sur une infrastructure maîtrisée n’était pas un luxe d’ingénieur, c’était une exigence du métier.

La pile que j’utilise quand on passe en code

Si votre valeur est dans l’exécution, ou si vous avez déjà validé et que vous passez à l’échelle, le code en 2026 n’est plus le chantier lent et cher qu’il était il y a dix ans. La pile que je monte pour un SaaS qui démarre tient en quatre briques.

Supabase pour le backend : une base Postgres managée, l’authentification, le stockage et des API générées automatiquement, sans gérer de serveur. Astro avec des îlots React pour le front, ce qui me donne un site rapide par défaut et la possibilité d’embarquer de l’interactif là où il le faut. Stripe Billing pour les abonnements récurrents, la facturation et la relance des paiements échoués. Et la Claude API quand le produit a une vraie composante IA, plutôt qu’un habillage marketing autour d’un modèle.

Avec cette pile, un MVP SaaS codé et propre sort en quatre à six semaines, pas en six mois. Le delta de vitesse avec le no-code s’est réduit, et ce que vous obtenez en échange vous appartient : le code est sur Git, l’hébergement est le vôtre, et le jour où vous levez des fonds ou recrutez un CTO, il hérite d’une base saine plutôt que d’un Bubble à jeter.

Comment je tranche, concrètement

Je tranche avec mes clients en trois questions, dans cet ordre.

Une : avez-vous déjà des utilisateurs qui paient ? Si non, votre seul travail est de le découvrir le plus vite et le moins cher possible. No-code, point. Ne codez rien.

Deux : votre valeur est-elle dans l’exécution, c’est-à-dire une interface intensive, un modèle de données complexe, la performance, la propriété intellectuelle ou des données sensibles soumises au RGPD ? Si oui, codez dès le départ, parce que le no-code ne pourra jamais posséder ce qui fait votre différence.

Trois : si vous avez validé en no-code et que ça décolle, planifiez la migration vers le code maintenant, pas quand l’application sera à genoux. Inscrivez un budget de re-build dans votre prochain plan de trésorerie. La bonne nouvelle, c’est qu’un produit qui paie justifie largement cette dépense.

Le faux débat, c’est « no-code ou code » posé comme une religion. Le vrai sujet, c’est le timing : le no-code valide, le code fait grandir, et le seul piège mortel est de confondre les deux phases.

Ce qu’il faut retenir

• No-code (Bubble, Softr, Glide) pour valider un MVP SaaS en deux à quatre semaines et quelques centaines d’euros, avant d’avoir prouvé que des gens paient
• Codez dès le départ si votre valeur est dans l’exécution : interface intensive, modèle de données complexe, performance, propriété du produit ou données sensibles
• Le re-build d’un no-code validé coûte autant qu’un développement direct, 8 000 à 15 000 euros dans ma pratique : budgétez-le dès le départ au lieu de le subir au sixième mois
• Votre plateforme no-code est un sous-traitant au sens du RGPD : la CNIL impose un contrat de sous-traitance, et un hébergement hors UE relève du régime des transferts encadré depuis Schrems II
• En 2026, un MVP codé avec Supabase, Astro, Stripe Billing et la Claude API sort en quatre à six semaines et reste possédé sur Git, ce qui réduit fortement l’avantage de vitesse historique du no-code
• Le bon arbitrage n’est pas technique mais une question de timing : le no-code valide, le code fait grandir