Publié le
20
June
2022
Mise à jour le
7
minutes

5 idées reçues sur le NoCode

Mathieu
Tran
Dimitri
Nicolas

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. C’est parti pour remettre les pendules à l'heure !

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 plugin Bubble.io
Exemple de liste de plugins Bubble utilisés dans 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. WeWeb aussi pousse la personnalisation du front-end à un niveau incroyable pour les applications.

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

Pour en savoir plus sur Bubble et Webflow : Bubble : Tout savoir pour débuter et 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.

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.
diagramme UML
Exemple de diaggramme UML réalisé sur Miro
Tu peux aussi lire Code vs Nocode pour approfondir ta réflexion.

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.

module des règles de privacy sur bubble.io
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

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 ? 😊

Quelques exemples de projets développés en Bubble, accompagnés par SuperForge :

Mot de la fin

Malgré toutes ces idées reçues sur le NoCode, on a 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 qui reste toujours aussi bienveillante.

Partager
Besoin de conseils ?
Dimitri te propose 30 minutes de call gratuit.
Réserver un call

La newsletter SuperForge

1 fois par mois, des interviews, des infos sur l’univers NoCode et sur l’entrepreneuriat. No spam, c’est promis.👌🏻