Trois objections reviennent systématiquement quand on propose de construire un outil sans passer par du développement classique.
On sera vite limité. Ça ne tiendra pas la charge. Ce n’est pas sécurisé.
Elles méritent d’être prises au sérieux, parce qu’elles viennent souvent de gens qui ont vu un projet mal tourner. Mais elles se sont toutes les trois déplacées ces dernières années, et les répéter telles quelles fait passer à côté des limites qui, elles, sont bien réelles.
Voici ce que vaut chacune aujourd’hui — et surtout, ce qu’il faut craindre à la place.
Premier mythe : on est vite limité en fonctionnalités
C’est sans doute la croyance la plus erronée de toutes, celle qui consiste à penser que le no-code ne permet pas de développer un grand nombre de fonctionnalités différentes. Si on met de côté les limites de fonctionnalités inhérentes à l’outil que vous choisissez, les outils no-code offrent au contraire une grande liberté dans le développement de nouvelles fonctionnalités.
C’est un des qualités principales de ces outils.
Attention tout de même à ne pas empiler les fonctionnalités couche sur couche, le tout doit rester cohérent en termes d’architecture technique, autrement vous risquez de devoir enchaîner les périodes de “Refactoring”, moment où l’on retravaille complètement un pan de l’application pour le rendre plus robuste.
La plupart des outils no-code peuvent accueillir beaucoup de fonctionnalités au fil du temps et à un rythme bien plus soutenu qu’un projet de développement “classique”, à condition d’avoir des fondations solides.
Deuxième mythe : ça ne tient pas la charge
Ici, au-delà du nombre d’utilisateurs qui est très relatif on parle avant tout de performance. Un grand nombre d’utilisateurs signifie que la charge imposée à votre infrastructure technique augmente fortement et que cela peut entraîner un risque de baisse de performance globale de l’application.
Tout d’abord sachez que derrière les outils que vous utilisez pour construire votre application il y a des équipes de développeurs dont le métier est de faire en sorte que ce que vous avez construit fonctionne pour le plus grand nombre. Aucun outil no-code n’est développé pour une base restreinte d’utilisateurs. Bien que cela paraisse assez “bateau” comme argument, il est toujours bon de le rappeler.
L’avantage d’utiliser un outil no-code pour son projet est qu’il est très souvent basé sur le cloud, vous déplacez ainsi la charge de la performance aux principaux acteurs du marché. Bubble est par exemple construit sur AWS et vous pouvez tout à fait utiliser un Xano ou Firebase si vous le souhaitez.
Beaucoup d’entreprises utilisent actuellement des outils no-code pour une partie de leur produit, on pense notamment à Collective, Getaround ou Cuure. Ces entreprises font face à un afflux de nouveaux utilisateurs toujours plus important.
Enfin, si vous avez besoin, même momentanément, d’augmenter la performance de votre projet, sachez que la plupart des outils no-code proposent des tarifs adaptés à vos besoins. Pour reprendre l’exemple de Bubble.io, l’entreprise propose cinq niveaux d’abonnement : Gratuit, Personnel, Professionnel, Production, et “Dedicated”. “Dedicated” est destiné à ceux qui vont au-delà des possibilités des plans standards, ici les performances seront “faites sur mesure”.
Troisième mythe : ce n’est pas sécurisé
La sécurisation d’un projet no-code est peut-être l’aspect le plus variable de tous. La menace d’une faille de sécurité venant plus souvent de la façon dont a été développée l’application que de l’éditeur lui-même. À niveau d’expérience et compétence égales un développeur traditionnel et un développeur no-code devrait construire un produit avec le même niveau de sécurité.
Dans la pratique donc un projet no-code a plus chance d’être sujet à une faille de sécurité à cause d’une erreur/insuffisance humaine.
Aucun éditeur no-code n’est connu à date pour générer des failles de sécurité majeures. Mais ici l’argument consistant à laisser la pleine responsabilité de la sécurisation des applications développées à l’éditeur ne tient pas.
Les limites qui, elles, sont réelles
Pour synthétiser, lorsqu’une application no-code est correctement développée et mise à jour il n’y a pas de risque de sous performance ou de faille de sécurité majeure. En revanche vous devez savoir qu’il existe des limites au développement d’un projet no-code.
Les limites natives de chaque outil
Chaque outil no-code a ses propres limites de fonctionnalité, Airtable peut stocker maximum 50k lignes par base de données par exemple. Nous avons écrit un article qui décrit les limites natives à Bubble.
Mais si vous ne tentez pas de concurrencer Facebook ou ChatGPT, théoriquement, les fonctionnalités natives, couplées avec les plugins développés par la communauté devraient suffire à votre projet.
Le nombre de “développeurs” ou “builder”
Une des différences importantes entre un projet tech “classique” et un projet no-code, notamment lorsque vous entrez dans une phase de croissance et de développement intense, est le nombre de personnes qui peuvent développer simultanément votre application. À date certains outils no-code gèrent la collaboration, mais ça n’est pas le cas de tous. Vous risquez donc de vous marcher sur les pieds lorsque votre équipe de product builder grandira.
Questions fréquentes
Est-on vite limité en fonctionnalités ?
C'est la croyance la plus erronée. Hors limites propres à l'outil choisi, ces plateformes offrent une grande liberté. Le vrai risque est ailleurs : empiler les fonctionnalités couche sur couche jusqu'à devoir tout retravailler.
Qu'est-ce que le refactoring ?
Le moment où l'on retravaille complètement un pan de l'application pour le rendre plus robuste. Il arrive quand l'architecture technique a cessé d'être cohérente, à force d'ajouts non pensés.
Ces outils tiennent-ils la charge ?
Cela dépend de l'outil et du volume, pas de la catégorie. La question se pose en nombre d'utilisateurs simultanés et en volume de données, et elle se vérifie avant de construire, pas après.
Sont-ils sécurisés ?
Les plateformes sérieuses embarquent chiffrement, authentification forte et correctifs réguliers, souvent mieux qu'une application interne dont personne ne suit les mises à jour. Le sujet réel est la gouvernance : qui a le droit de créer quoi, avec quelles données.
Quelles sont les limites réelles alors ?
La dépendance à la plateforme, la propriété du code, et l'hébergement. Ces trois-là ne se contournent pas : elles se décident avant de commencer.
