No-code ou développement sur mesure : que choisir vraiment pour votre MVP ?

Depuis cinq ans, le no-code est devenu la religion des fondateurs pressés. Bubble pour les web apps, Glide pour les prototypes, FlutterFlow pour les apps mobiles, Adalo, Softr, Lovable. Les promesses sont belles : « construisez votre MVP en 2 semaines sans écrire une ligne de code ».

Est-ce vrai ? Parfois oui. Souvent non. Et le problème n'est pas le no-code en soi. C'est qu'il est systématiquement présenté comme une solution universelle, alors qu'il a des limites très précises que personne ne vous explique avant de souscrire à l'abonnement.

Ce que le no-code fait vraiment bien

Soyons honnêtes : le no-code est une avancée majeure pour une catégorie de projets bien définie.

Les outils internes et les back-offices

CRM personnalisé, dashboard d'équipe, outil de gestion de stock, système de suivi client. Pour ça, Airtable + Softr ou Bubble sont imbattables. Vous construisez en quelques jours quelque chose qu'un dev aurait mis 2 mois à coder. Et comme le produit est utilisé en interne, les limitations ne se voient pas.

Les landing pages et les MVP « statiques »

Une plateforme de prise de rendez-vous simple, un annuaire, un formulaire évolué avec logique conditionnelle. Le no-code est parfaitement adapté. Rapidité, coût faible, résultat propre.

La validation d'hypothèse pré-produit

Avant de coder quoi que ce soit, tester « est-ce que des gens cliqueraient sur ce bouton ? » ou « est-ce que ma cible s'inscrirait à ce service ? » peut se faire en quelques heures avec un outil no-code. C'est un usage intelligent et souvent sous-exploité.

Ce que le no-code fait mal (et qu'on découvre trop tard)

1. Les performances mobiles

Une app Bubble ou Adalo sur mobile, c'est typiquement 3 à 10 fois plus lent qu'une app codée en Flutter. Chargements interminables, animations qui saccadent, interactions molles. Pour un outil interne, personne ne remarque. Pour une app grand public, c'est le motif numéro un de désinstallation.

2. Les coûts qui explosent à l'échelle

Le no-code coûte 29€/mois au démarrage. Puis 99€. Puis 299€. Puis 899€ quand votre app a 5 000 utilisateurs actifs. Sur 3 ans, vous aurez souvent payé plus cher en abonnements qu'un développement sur mesure propre, sans jamais avoir possédé votre code.

3. La dépendance totale à la plateforme

Si Bubble augmente ses prix de 300%, vous n'avez aucun recours. Si Adalo ferme, votre app disparaît. Si FlutterFlow change sa logique de facturation, votre business model bascule du jour au lendemain. Vous ne possédez pas votre infrastructure.

4. Les limites techniques dès qu'on veut sortir du cadre

Paiements personnalisés, notifications push avancées, mode hors ligne, intégrations spécifiques, logiques métier complexes : dès que votre app a besoin d'un comportement « pas standard », vous vous retrouvez à contourner l'outil, à payer des plugins, à hacker des workarounds qui cassent à chaque mise à jour.

5. Le cauchemar du refactoring

Quand votre no-code atteint ses limites, vous devez tout recoder en natif ou en Flutter. Et là, mauvaise nouvelle : vous ne pouvez rien récupérer. Pas une ligne de code. Vous repartez de zéro, avec en plus un historique d'utilisateurs à migrer. C'est le prix à payer, et il est lourd.

Le cas FlutterFlow : le juste milieu ?

FlutterFlow mérite une mention à part. Contrairement à Bubble ou Adalo, il génère du vrai code Flutter que vous pouvez exporter et éditer. C'est l'outil no-code le plus proche du développement traditionnel.

Ce qu'il fait bien : vous permet de prototyper très vite, vous donne accès au code généré, s'intègre avec Firebase facilement. C'est un bon outil pour construire une V0 testable en 1 à 2 semaines.

Ce qu'il fait moins bien : le code généré est parfois difficile à maintenir quand il devient complexe. Les animations fines et les intégrations sur mesure demandent toujours un développeur Flutter pour intervenir directement dans le code. À partir d'un certain niveau de complexité, FlutterFlow devient un frein, pas un accélérateur.

La vraie question à se poser

Au lieu de demander « no-code ou code ? », demandez-vous :

Est-ce que mon app a vocation à rester un prototype, ou à devenir un vrai produit avec des milliers d'utilisateurs ?

Si c'est un prototype pour valider une hypothèse, tester un marché, ou gérer un flux interne : partez en no-code. Vous économiserez du temps et de l'argent, et vous apprendrez vite.

Si c'est un produit que vous voulez monétiser, faire grandir, revendre à terme, ou lever des fonds autour : partez directement en code. Chaque mois passé en no-code est un mois qu'il faudra refaire, plus les mois perdus à constater que ça ne tient plus la route.

Le vrai piège du no-code, ce n'est pas de l'utiliser. C'est de penser qu'on peut « basculer plus tard ». En pratique, on bascule toujours, mais sous pression, en urgence, après avoir perdu des utilisateurs. Autant partir au bon endroit dès le début.