Le no-code : une solution pérenne pour l'avenir ?

Premier mythe : vous allez être vite limités en termes de 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 : le no-code n’est pas adapté à un grand nombre d’utilisateurs.

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".

Mythe numéro trois : un outil no-code 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.

Quelques limites

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.

‍