5 idées reçues sur le NoCode

Mathieu
Tran
Dimitri
Nicolas

7

minutes

Bubble
Webflow

Difficile de naviguer dans la jungle NoCode sans tomber sur beaucoup d’idées reçues sur le sujet. 😥

Pour cette raison, on a listé 5 idées reçues pour démêler le vrai du faux. 👇

💡 Si tu veux en savoir plus sur le NoCode et le LowCode, nous avons ces articles :

👉 Le NoCode : C’est quoi ?

👉 LowCode vs NoCode

Maintenant, c’est parti pour les idées reçues…

1 - Le NoCode n’est pas personnalisable

Faux. Mais ça dépend de l’outil en question ! Certains outils ne sont pas assez avancés (ce n’est pas leur but principal aussi pour certains) pour permettre une personnalisation avancée. En règle générale, les outils NoCode tendent à donner de la flexibilité pour celles et ceux qui souhaitent aller plus loin que l’usage initial. 🚀🚀🚀

Par exemple sous Bubble, il est possible de créer des applications personnalisées grâce à l’intégration de plugins ou bien le développement et l’intégration de ton propre code custom (en “front” ou en “back”).

Liste de plugins Bubble utilisés sur une Web App

En terme des personnalisations visuelles, certains outils sont plus forts que d’autres. Webflow est très bon pour ça et te permet de faire un site web “pixel perfect”, avec de belles animations. 🎨

À l’inverse, Dorik sera plus limité mais permet une construction d’un site plus rapide.

👉 Bubble : Tout savoir pour débuter

👉 Webflow : Tout savoir pour débuter

2 - Le NoCode va remplacer les développeurs web

Faux. C’est le mot “remplacer” qui n’est pas le bon ! 🤔 Tous les métiers évoluent, surtout celui de développeur. Ils évoluent aussi avec les outils que l’on met à disposition des développeurs.

Les outils NoCode représentent une gamme d’outils permettant de faire gagner beaucoup de temps au développeur. Il pourra ainsi se concentrer sur du développement à “plus forte valeur ajoutée”, là où un logiciel ne pourra pas le remplacer.

Le développeur sera donc concentré sur des briques métiers complexes ou le code sera nécessaire : de l’algorithmie poussée ou une logique métier complexe par exemple.

📌 À noter que les outils NoCode eux-mêmes sont développés avec du code. 💪

On se rassure, le développeur est loiiiiiiinnn d’être une espèce en voie de disparition (quoique… avec le changement climatique, rien n’est moins sûr 🌫️).

3 - Le NoCode n’est pas du vrai code

Vrai. C’est inscrit dans son nom, NoCode “veut dire” sans code. Cela ne veut pas dire qu’il n’y a pas de programmation. Beaucoup de problématiques de développement classique se retrouvent dans le NoCode : architecture, performance, sécurité, maintenance…

Développer avec un outil NoCode c’est programmer avec des éléments visuels. Est-ce que l’on ne peut pas considérer les éléments visuels comme du code ? Une abstraction supplémentaire au-dessus des abstractions des frameworks de développement sortis ces dernières années.

NoCode ne veut pas non plus dire “facile”. Loin de là ! Ce sont des outils et il appartient à chaque utilisateur de se former puis d’utiliser le bon outil, correctement, pour le bon cas d’utilisation.

📌 Le NoCode n’utilise pas de code traditionnel mais les logiques de programmation restent les mêmes. Avoir le mindset de développeur est un atout considérable en utilisant un outil dit NoCode.

Pour illustrer la promiscuité entre le NoCode et le code, voici une étape que l’on effectue avant de commencer tout développement, la phase d’architecture :

  • Création d’un diagramme UML, de la base de données et des styles.
  • Structuration et optimisation des pages de l’application.

Exemple d’un diagramme UML sur Miro

4 - Le NoCode n’est pas sécurisé

Faux. Le NoCode permet une abstraction grande de logiques qui se retrouvent encapsulées. Une fois ces briques testées, approuvées et mises à disposition des développeurs, elles sont moins enclines à poser des problèmes de sécurités (en leur sein).

Par contre l’usage de ces briques ou outils NoCode (tout comme pour le développement classique) peut poser problème.

Par exemple, si la brique NoCode qui permet le développement d’une authentification utilisateur t'autorise à configurer les règles de restriction sur les mots de passe et que le développeur met des règles peu limitantes, alors le risque est plus élevé. Mais la brique qui permet l’authentification utilisateur est bien construite.

Le module permettant la configuration des règles sur les mots de passe dans Bubble

De plus, il existe des outils dédiés à la sécurisation des outils NoCode, ncScale en est un exemple.

👉 Pour en savoir plus sur la sécurité des outils NoCode, nous avons interviewé le fondateur de ncScale : Interview de Benoît.

5 - Le NoCode sert seulement pour les prototypes et MVP

Faux. Peut-être la plus grosse idée reçue ! On utilise en effet beaucoup le NoCode pour la création de POC, Prototypes ou MVP : développement rapide, pour tester une idée, avec la possibilité de jeter ce qui a été développé en fin de test (voir cet article pour plus de détail sur les POC, Prototypes et MVP)

Mais le NoCode est loin de ne servir qu’à ça !

Un exemple de site web créé avec Webflow, un outil NoCode, est le site sur lequel tu es en train de lire cet article. Pas mal non ? Ça ne ressemble pas à un MVP que l'on va jeter rassure-moi ? 😊

Deux autres exemples de projets accompagnés par Superforge:

  • la plateforme Call Of Success, développée en Bubble pour un usage de production
  • la plateforme FeeZeen, développée en Bubble, également pour un usage de production

Pour d’autres exemples, je te propose de regarder notre page de projets accompagnés.

Et dans l'écosystème Nocode tu as encore plein d'exemples :

Et j'en passe...

Pour finir, j’ai toute confiance dans les technologies NoCode / LowCode pour permettre de créer des projets digitaux, petits et grands. Ils évoluent rapidement, récoltent des fonds, développent de nouvelles fonctionnalités et deviennent de plus en plus complets et puissants.

Un plus indéniable est la communauté NoCode qui s’agrandit de jour en jour et toujours aussi bienveillante 🤝. Pour la découvrir c’est par ici : NoCode France.