Le no-code permet de sortir des applications vite et moins cher qu'un sur mesure. Mais derrière les promesses, il y a des limites techniques réelles et des coûts qui montent vite. Voici ce qu'on découvre rarement avant de signer.
Le no-code n'est pas magique
Le no-code (Bubble, FlutterFlow, Glide, Softr et autres) a vraiment changé ce qu'on peut construire vite. Mais le discours marketing autour de ces outils est souvent trop enthousiaste : « vous économisez 80 % », « plus besoin de développeurs », « scalable à l'infini ». La réalité est plus nuancée.
Cet article ne dit pas que le no-code est mauvais. Il dit simplement qu'il faut le choisir en connaissance de cause, avec les limites et coûts cachés en tête.
Les coûts qui grimpent
| Outil | Plan démarrage | Plan volume sérieux |
|---|---|---|
| Bubble | ~30 €/mois | 150-500 €/mois selon trafic et workload |
| FlutterFlow | ~30 €/mois (sans coûts Firebase) | 30 € + coûts Firebase qui peuvent doubler ou tripler |
| Glide | ~25 €/mois | 100-300 €/mois selon utilisateurs |
| Softr | ~30 €/mois | 100-300 €/mois selon plan |
Les limites techniques bloquantes
- Performances variables : un Bubble lourd plafonne en réactivité quand on multiplie les workflows.
- SEO limité : le rendu côté serveur (SSR) qui permet un SEO sérieux n'est pas natif sur la majorité des plateformes.
- Intégrations complexes impossibles : synchronisation bidirectionnelle avec ERP custom, traitements d'image lourds, accès bas-niveau API.
- Personnalisation UI bloquée : impossible de sortir des composants prévus, accès limité au CSS/DOM.
- Tests automatisés difficiles : peu d'outils permettent de tester rigoureusement une app no-code.
La dépendance plateforme
Changement de pricing
L'éditeur peut augmenter ses tarifs significativement à tout moment. Vous payez ou vous migrez (= réécrire).
Suppression de fonctionnalités
Une feature critique peut disparaître entre deux versions. Vous adaptez ou vous migrez.
Fermeture de service
Rare mais arrivé. Tous vos process s'arrêtent, vous devez tout refaire ailleurs en urgence.
Quand le no-code reste le bon choix
Malgré les limites, le no-code est pertinent dans plusieurs cas :
- Validation rapide d'une idée : sortir un MVP en quelques semaines pour tester un marché.
- Outil interne pour petite équipe (5-20 utilisateurs) : les coûts SaaS restent contenus.
- Périmètre vraiment standard qui ne demande pas de complexité métier hors normes.
- Budget initial vraiment serré : sortir quelque chose plutôt que rien sortir du tout.
Pour évaluer si le no-code est pertinent pour votre projet (ou pas), prévoyez un premier appel. Voir aussi comparatif no-code vs sur mesure.
Questions fréquentes
À partir de quel volume le no-code devient cher ?
Variable selon l'outil. Sur Bubble, les paliers commencent à grimper dès quelques centaines d'utilisateurs actifs ou un trafic conséquent. Sur Glide, dès quelques dizaines d'utilisateurs en B2B. Sur Softr, selon le nombre de pages et le trafic. Toujours simuler le coût au volume cible avant de choisir.
Quelles intégrations sont vraiment impossibles en no-code ?
Variable selon plateforme : intégrations avec systèmes legacy propriétaires, calculs ou traitements en arrière-plan complexes, webhooks bidirectionnels avancés, contrôle fin du SEO (rendu côté serveur), accès bas-niveau au DOM. Pour ces cas, le sur mesure ou un mix hybride devient nécessaire.
Que se passe-t-il si Bubble ou un autre éditeur ferme ?
Le risque est réel : votre app cesse de fonctionner, et la migration vers une autre plateforme est rarement directe. Pour limiter le risque, choisir des éditeurs établis (Bubble, FlutterFlow ont des bases solides) et garder un export régulier de vos données. Mais le risque structurel ne disparaît jamais totalement.