Le no-code a explosé depuis 2020. Webflow, Bubble, Zapier, Notion, Airtable, Glide, FlutterFlow : on peut construire de plus en plus de choses sans coder. Et c’est tant mieux : ça démocratise la création digitale, ça permet à des entrepreneurs de tester des idées sans dépendre d’un dev.
Mais le no-code n’est pas magique. Il a des limites. Et ces limites se révèlent souvent au pire moment : quand votre projet décolle et qu’il faut le faire grandir.
Ce que le no-code fait très bien
Soyons clairs : le no-code a sa place. Et certains usages, il les fait mieux qu’un dev.
Tester rapidement une idée de produit avec une page de vente et une liste d’inscrits : Carrd, Framer, Webflow, parfaits.
Mettre en place un workflow d’automation entre plusieurs outils (mail, formulaire, CRM, Slack) : Zapier, Make, n8n, redoutables.
Centraliser des données métier dans un outil collaboratif : Airtable, Notion, NocoDB, vraiment efficaces.
Construire un MVP fonctionnel pour valider une idée : Bubble, Glide, FlutterFlow, peuvent suffire pour les six premiers mois.
Pour ces cas d’usage, le no-code est plus rapide, moins cher, plus accessible. Pas de discussion à avoir.
Limite numéro 1 : les performances
Les outils no-code génèrent du code générique, pas du code optimisé pour votre cas. Ce code générique est plus lourd, plus lent, moins efficace que ce qu’un dev produirait pour la même fonctionnalité.
Sur un site Webflow comparé à un site Next.js équivalent, j’ai mesuré des écarts de 30 à 60 % sur le LCP en 2025. Ce n’est pas négligeable. Sur un Bubble qui sert d’application web, l’INP est souvent à plus d’une seconde, là où un Next.js correctement codé tourne sous 200 ms.
Pour un site vitrine, ça reste acceptable. Pour une application utilisée plusieurs heures par jour, ça devient pénible.
Limite numéro 2 : les coûts qui explosent à l’échelle
Les outils no-code sont peu chers au démarrage et chers à grande échelle. Bubble, par exemple, fait grimper sa facture mensuelle à plusieurs centaines d’euros dès qu’on commence à avoir du trafic ou des données significatifs.
J’ai un client qui était sur Bubble et payait 350 € par mois pour son SaaS B2B avec 200 utilisateurs. À 2 000 utilisateurs, le tarif Bubble équivalent montait à 1 200 € par mois. La migration vers Next.js plus Supabase coûtait 22 000 € en one-shot, mais ramenait le coût mensuel à 80 €. Sur trois ans, l’économie était de 30 000 €.
Limite numéro 3 : la flexibilité métier
Tant que votre cas d’usage rentre dans ce que prévoit l’outil no-code, ça marche. Dès que vous voulez quelque chose qui n’est pas prévu, ça devient un cauchemar.
J’ai eu un projet sous Glide où le client voulait ajouter une logique de tarification dynamique selon plusieurs critères (taille, urgence, profil utilisateur). Sur Glide, c’était impossible sans plugins payants instables. Sur du code, c’était deux jours de travail.
Plus votre projet a de spécificités métier, plus le no-code devient contraignant.
Limite numéro 4 : l’enfermement
Tous les outils no-code souffrent du même problème : si vous voulez en sortir, vous repartez de zéro. L’export n’est pas vraiment un export. Le code généré, quand il existe, est inexploitable hors de l’outil.
Webflow propose un export HTML/CSS, mais pas la dynamique CMS. Bubble n’exporte rien d’utilisable. Notion idem.
Vous payez chaque mois pour rester dedans. Et plus vous restez, plus la sortie devient compliquée.
Limite numéro 5 : la dette technique invisible
Quand un projet no-code grossit, il accumule de la dette technique. Mais cette dette est cachée : pas de Git, pas de revue de code, pas de tests automatiques. Vous découvrez les bugs en production.
Sur Bubble, j’ai vu des spaghettis logiques qu’on retrouvait habituellement dans du code legacy de 15 ans. Sauf que là, c’était le résultat de 18 mois de no-code accumulé, devenu illisible et impossible à maintenir.
Quand passer au code
Je conseille à mes clients de migrer vers du code dans trois cas.
Premier cas : votre coût mensuel no-code dépasse 300 € par mois. À ce niveau, le ROI de la migration est rapide.
Deuxième cas : votre produit a trouvé son marché et vous devez maintenant l’optimiser pour scaler. Les performances et la flexibilité deviennent critiques.
Troisième cas : vous voulez ajouter des fonctionnalités spécifiques que l’outil no-code ne permet pas correctement. Continuer à bricoler vous coûte plus cher que de migrer.
Mon approche : combiner
Je travaille de plus en plus avec des combinaisons hybrides. Le no-code pour les workflows internes (Zapier pour les notifs, Notion pour la doc, Airtable pour les données métier). Le code pour le produit lui-même (Next.js, Supabase, parfois une app native).
Ce n’est pas un débat tout-no-code contre tout-code. C’est : utiliser le bon outil pour le bon usage. Le no-code n’est pas l’ennemi du code. C’est un complément utile, à condition de connaître ses limites.
L’erreur classique
L’erreur que je vois souvent : démarrer un produit ambitieux 100 % en no-code, parce que c’est moins cher au début. Six mois plus tard, le produit décolle, et il faut tout refaire en code parce que le no-code ne tient pas la charge ou n’autorise pas les évolutions nécessaires.
Si vous savez que votre projet a vocation à devenir significatif (en utilisateurs, en données, en complexité), commencez directement avec une stack code. Vous économiserez la refonte. Si vous voulez juste valider une idée et que le projet peut s’arrêter dans six mois, le no-code est parfait.
Le bon choix dépend de votre horizon, pas du dernier outil à la mode.