J’ai eu une conversation la semaine dernière avec un fondateur qui avait lancé son SaaS sur Bubble il y a 18 mois. Bonne idée, bonne exécution initiale. Sauf qu’aujourd’hui, son application met 8 secondes à charger avec 200 utilisateurs actifs, il ne peut pas implémenter la logique de facturation au prorata dont ses clients ont besoin, et son prestataire lui dit que la migration vers du développement custom va lui coûter deux fois ce qu’il a déjà investi.
Il n’avait pas fait le mauvais choix dès le départ. Il avait fait un bon choix au mauvais moment, sans planifier la suite.
J’aurais pu lui montrer l’autre extrême — le fondateur qui a dépensé 35 000€ de développement pour un site vitrine avec un formulaire de contact et un espace membres basique, quelque chose que Webflow aurait géré en trois semaines pour quelques centaines d’euros.
Je suis développeur fullstack depuis 10 ans. J’utilise du no-code moi-même — n8n tourne dans ma stack d’automatisation, Webflow a servi sur des projets clients, et Framer fait ce que Framer fait bien. Mais je vois aussi ce que ces outils ne peuvent pas faire, et à quel moment le choix d’un outil no-code devient un piège dont il est coûteux de sortir.
Le no-code et le développement ne s’opposent pas. Ils répondent à des besoins différents. La question n’est pas “lequel est meilleur” mais “dans quel cas je suis”.
Ce que le no-code fait vraiment bien
Commençons par là, parce que le réflexe inverse est tout aussi fréquent : des développeurs qui méprisent le no-code et conseillent systématiquement du custom quand c’est une dépense inutile.
Valider une idée avant d’investir
C’est le cas d’usage le plus solide du no-code. Vous avez une idée de produit. Vous ne savez pas encore si les gens vont l’utiliser, ni exactement sous quelle forme ils veulent l’utiliser. Investir 30 000€ de développement avant d’avoir une seule validation terrain, c’est risqué.
Bubble peut vous permettre de construire un prototype fonctionnel en quelques semaines. Vous testez. Vous apprenez. Si l’idée ne prend pas, vous avez limité votre exposition financière. Si elle prend, vous avez des données réelles pour orienter le développement qui suivra.
Le prototype no-code n’est pas votre produit final. C’est votre outil de validation.
Sites vitrines et landing pages
Webflow est excellent pour ça. Framer aussi. Ces outils permettent de créer des sites beaux, rapides, bien référencés, avec une interface de gestion de contenu intégrée, pour un coût et un délai sans commune mesure avec du développement custom.
Pour un site vitrine ou une landing page, sauf contrainte technique très spécifique, le no-code est souvent la bonne réponse. Astro est une alternative légère si vous avez un développeur dans l’équipe, mais pour un client ou un fondateur solo, Webflow fait le travail.
Applications avec des workflows simples
Bubble peut gérer des applications avec des règles métier basiques et prévisibles. Marketplace simple, place de réservation, annuaire avec filtres, application de gestion interne pour une équipe réduite. Tant que les règles sont stables, les volumes modérés, et les intégrations limitées aux connecteurs natifs disponibles, ça fonctionne.
“Simple et prévisible” sont les mots clés. Pas simples au sens de primitifs, mais simples au sens de stables et bien définis.
Formulaires et collecte de données
Typeform, Tally, Airtable pour les formulaires complexes — ces outils font ça mieux que n’importe quel développement custom raisonnable. Inutile de développer un formulaire multi-étapes avec logique conditionnelle quand Tally le fait en 20 minutes et que le résultat est stocké proprement.
Automatisations
Zapier, Make, n8n — même si n8n permet du JavaScript natif dans ses nœuds, ce qui en fait une frontière avec le low-code. Ces outils automatisent des workflows entre applications sans que vous ayez besoin d’écrire une ligne de code. Pour connecter un CRM à une boîte mail, envoyer des notifications Slack quand un événement se produit dans votre base de données, ou synchroniser des données entre plusieurs plateformes, c’est souvent plus rapide et moins coûteux qu’une intégration développée sur mesure.
Les vraies limites du no-code
C’est là que le choix devient critique.
Performance à grande échelle
Bubble en particulier est architecturalement contraint. Ses performances se dégradent sensiblement avec les volumes — plusieurs centaines d’utilisateurs simultanés, des tables avec des dizaines de milliers de lignes, des workflows complexes déclenchés fréquemment. Ce n’est pas un défaut caché : les équipes de Bubble le documentent. C’est une limite de conception.
Si votre produit doit tenir une charge sérieuse, il faut en tenir compte dès le départ, pas au moment où vos utilisateurs se plaignent des temps de réponse.
Logique métier complexe ou propriétaire
Certaines règles métier ne peuvent pas s’exprimer dans une interface visuelle. Des calculs financiers complexes, des algorithmes de matching propriétaires, des workflows avec des branches conditionnelles imbriquées sur 4 ou 5 niveaux, des règles de conformité spécifiques à votre secteur.
Vous pouvez souvent en implémenter une version approchante dans Bubble. Mais “approchant” n’est pas “exact”, et dans certains domaines — facturation, comptabilité, droit — cette différence a des conséquences réelles.
Intégrations non supportées nativement
Les plateformes no-code ont leurs connecteurs natifs. Si votre stack existante utilise des outils moins courants, ou si vous avez besoin de logique personnalisée dans vos intégrations, vous allez vous heurter aux limites rapidement.
Théoriquement, vous pouvez appeler une API avec Bubble. Pratiquement, les API calls complexes avec authentification spécifique, payloads dynamiques et gestion d’erreurs fine deviennent rapidement pénibles à maintenir dans une interface visuelle.
Données sensibles et conformité
C’est un point que j’observe souvent sous-estimé. Les données de santé, les données financières, les informations sensibles qui impliquent des obligations RGPD spécifiques — elles nécessitent une maîtrise complète de votre infrastructure de données.
Avec Bubble, vos données sont sur les serveurs de Bubble. Vous n’avez pas de contrôle sur le chiffrement au repos, les mécanismes de pseudonymisation, la localisation précise des données. Ce n’est pas rédhibitoire pour tous les cas, mais pour certains secteurs réglementés, ça l’est.
Coût à long terme
Les abonnements no-code s’accumulent. Bubble peut atteindre plusieurs centaines d’euros par mois pour un usage sérieux. Webflow a ses propres tarifs. Ajoutez Zapier ou Make pour les automatisations, Airtable ou Notion pour la base de données, et le total mensuel peut dépasser ce que coûterait une infrastructure custom bien dimensionnée.
Ce n’est pas systématiquement le cas — il faut faire le calcul pour votre situation — mais l’idée que le no-code est toujours moins cher que le développement est un mythe. C’est moins cher à court terme. Pas nécessairement à 3 ou 5 ans.
Le vendor lock-in
C’est le risque le moins visible mais potentiellement le plus coûteux. Votre produit est construit sur Bubble. Bubble change ses prix de façon significative. Bubble décide de fermer telle fonctionnalité. Bubble a des problèmes de stabilité sur plusieurs semaines.
Vous n’avez pas de plan de sortie simple. Votre produit est dans leur format propriétaire. La migration est coûteuse et longue.
Ce risque est réel. Des plateformes no-code ont disparu, fusionné ou changé radicalement leur modèle tarifaire ces dernières années. Construire son produit core sur une plateforme tierce fermée, c’est accepter cette dépendance.
Le vrai critère de décision
Pas “qu’est-ce qui va plus vite” — parce que no-code va souvent plus vite aujourd’hui. La vraie question est : dans 18 mois, est-ce que je vais regretter ce choix ?
Pour répondre à cette question, il faut être honnête sur deux choses.
D’abord, la trajectoire de votre produit. Si vous validez une idée, si vous ne savez pas encore si ça va marcher, si votre modèle est encore flou, alors la vitesse de départ vaut plus que la maintenabilité à long terme. Le no-code a sa place.
Si vous construisez quelque chose que vous pensez sérieusement déployer à 1 000, 5 000, 50 000 utilisateurs, avec de la logique métier qui va évoluer, avec des contraintes de données — là, les fondations comptent.
Ensuite, le coût réel de la migration. La migration d’une application Bubble vers du développement custom n’est pas une réécriture incrémentale. C’est souvent une reconstruction quasi-complète. Si vous l’anticipez dès le départ et planifiez les ressources pour ça, c’est un choix éclairé. Si vous découvrez ce coût 18 mois plus tard avec des clients en production, c’est une crise.
L’arbre de décision
Voici comment j’analyse une situation quand on me pose la question.
C’est un prototype pour valider une idée avant d’investir → No-code. Bubble, Glide, des fois même un simple Notion ou Airtable avec du formulaire. Validez d’abord, développez ensuite.
C’est un site vitrine ou une landing page → No-code. Webflow ou Framer pour du visuel sophistiqué, Astro si vous avez un développeur et voulez le contrôle total.
C’est une application avec des règles métier simples et stables → No-code possible. Bubble pour des workflows prévisibles, des volumes modérés, des intégrations courantes. Planifiez la trajectoire.
C’est une application qui doit s’intégrer à un système existant complexe → Développement. Dès que vous avez des intégrations API complexes, des webhooks bidirectionnels, de la synchronisation temps réel avec vos outils internes, le no-code devient plus une contrainte qu’une aide.
C’est une application avec des données sensibles → Développement. Santé, finances, données personnelles réglementées — vous avez besoin du contrôle complet sur votre infrastructure.
C’est une application avec une logique métier propriétaire ou complexe → Développement. Vos règles de calcul, vos algorithmes, votre logique spécifique à votre domaine — elles méritent d’être dans du code versionné, testé, maintenable.
C’est une application dont le modèle est encore flou → Commencez no-code, planifiez la migration. C’est le cas le plus délicat. Allez vite maintenant, mais ne vous berçez pas d’illusions sur la nature de la transition à venir.
Ce que j’aurais dit au fondateur sur Bubble
Je lui aurais dit de construire son MVP sur Bubble — c’était le bon choix à l’époque. Mais je lui aurais aussi dit trois choses dès le départ.
Premièrement, définir clairement les critères qui déclenchent la migration : X utilisateurs actifs, Y temps de chargement, telle fonctionnalité impossible à implémenter. Pas attendre d’être dans le mur.
Deuxièmement, documenter sa logique métier. Pas dans l’interface Bubble — dans un document accessible, en langage naturel ou en pseudocode. Pour que la migration soit une traduction, pas une reconstruction à partir de rien.
Troisièmement, chiffrer le coût de migration dès le départ. L’intégrer dans son plan financier. Si la migration coûte 40 000€ dans 18 mois et que le produit génère 5 000€/mois à ce moment, c’est planifiable. Si c’est une surprise, c’est une crise.
FAQ
Peut-on vraiment migrer d’un outil no-code vers du développement custom ?
Oui, mais avec lucidité. Ce n’est pas une migration technique — c’est une reconstruction. Les données peuvent souvent être exportées. La logique métier doit être réimplémentée. L’interface doit être redesignée. Dans la plupart des cas, on repart d’une feuille presque blanche, avec l’avantage de connaître exactement ce qu’on veut construire grâce aux apprentissages du produit no-code. Anticipez ce coût très tôt et traitez-le comme un investissement planifié, pas comme une surprise.
Le no-code est-il vraiment sans code ?
Non, dans les cas d’usage un peu sérieux. Bubble a son propre système d’expressions conditionnelles. Webflow a du CSS et parfois du JavaScript. n8n permet d’écrire du JavaScript natif dans ses nœuds. Airtable a des formules. Ce n’est pas du code au sens traditionnel, mais ce n’est pas non plus aussi accessible que les discours marketing le laissent entendre. Un fondateur technique va se débrouiller. Un fondateur sans background technique va rapidement atteindre ses limites ou dépendre d’un prestataire no-code.
Le low-code, c’est quoi exactement ?
Entre le no-code pur et le développement custom, il y a des outils qui permettent d’écrire du code dans certaines zones tout en automatisant le reste. Retool est l’exemple typique pour les interfaces internes. Xano est une alternative à Bubble pour le backend, avec plus de flexibilité. Supabase est une plateforme backend qui automatise l’infrastructure mais vous laisse écrire votre logique en SQL et en code. Ces outils sont souvent le meilleur compromis pour des équipes avec quelques profils techniques qui veulent aller vite sans partir de zéro.
Quels outils no-code recommandes-tu pour débuter ?
Ça dépend de votre cas. Pour un site vitrine : Webflow ou Framer, avec des templates de qualité disponibles et une courbe d’apprentissage raisonnable. Pour un prototype d’application : Bubble reste la référence malgré ses limitations, sa communauté est large et les ressources sont abondantes. Pour des automatisations : n8n si vous avez un profil technique (self-hostable, open source, très puissant), Make si vous voulez quelque chose de plus visuel, Zapier si vous voulez le plus simple possible. Pour des formulaires et bases de données légères : Tally pour les formulaires, Airtable ou Notion pour les données avec interfaces simples.
Vous hésitez entre no-code et développement pour votre projet ? Je peux vous aider à faire le bon choix dès le départ. Me contacter