Le no-code permet de sortir des applications plus vite qu'un sur mesure. Mais derrière les promesses, il y a des limites techniques réelles et des coûts qui montent avec l'usage. 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
Le piège n'est pas le tarif d'entrée, souvent modeste. C'est la courbe : ce que vous payez augmente avec l'usage réel, et le facteur qui fait grimper la facture diffère selon l'outil.
| Outil | Ce qui fait grimper la facture |
|---|---|
| Bubble | Trafic et charge de calcul (workload) : plus l'app travaille, plus le palier monte. |
| FlutterFlow | Coûts Firebase en plus de l'abonnement : ils peuvent doubler ou tripler avec les lectures/écritures de données. |
| Glide | Nombre d'utilisateurs actifs : la facturation par utilisateur monte vite en B2B. |
| Softr | Nombre de pages et trafic : le palier change selon le plan nécessaire. |
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.