Que l’on soit pour ou contre, on entend beaucoup d’opinions contrastées sur le no-code, et malheureusement, peu sont justifiées et a contrario, beaucoup sont de l’ordre de l’idée reçue. Pas facile alors de se poser les bonnes questions, et encore moins, lorsque l’on hésite, à se décider à y aller ou pas. Il faut dire que les laconiques et traditionnelles listes d'avantages et d'inconvénients, sorties de leur contexte, n'aident pas beaucoup ! On vous livre aujourd’hui nos opinions, au-delà du dogmatisme, sans langue de bois !
Démystification de quelques idées reçues sur le no-code
1. Le no-code, on peut tout faire avec (ou inversement, on ne peut faire que des choses triviales avec)
On commence par le grand classique, qui oppose les fanboys / fangirls qui tombent amoureux du no-code et les codeurs endurcis (”de toute façon, tu ne codes pas, tu ne devrais pas dire que tu es développeuse”. Ça vous dit quelque chose ?). Mais laissons pour le moment de côté le no-code hate, nous parlerons de ce sujet dans un futur billet.
✅ Plutôt vrai
Certes, les outils no-code couvrent un nombre impressionnant de cas d’utilisation désormais et certains sont très flexibles à l’image de Notion et Make (ex-Integromat) par exemple. Leur pouvoir est de plus décuplé lorsqu’on les combine entre eux, permettant de créer des choses parfois bluffantes en un temps record.
❌ Plutôt faux
Toutefois, prétendre qu’on peut tout faire avec reste illusoire. L’une des raisons est que parfois, des cas d’utilisation sont parfois tout simplement trop complexes pour être abstractisés de manière rentable (n’oublions pas que les éditeurs des outils no-code restent des entreprises à but lucratif)
Verdict : ✅ vrai ET ❌ faux
2. Le no-code, c’est le futur !
❌ Faux
Alors là, c’est plus facile : le no-code, ce n’est pas le futur, c’est le présent, même si tout le monde n’en a pas encore conscience.
La révolution silencieuse est encore relativement discrète, mais elle a commencé il y a quelques années déjà et la prise de conscience est déjà totale aux États-Unis. Nous l’avons déjà mentionné dans ce billet : en faisant de chacun d’entre nous un Citizen Developer, elle apporte une réponse (partielle) à la crise du recrutement des informaticiens et réduit à sa façon la fracture numérique.
Étant donné qu’elle est inéluctable, autant embrasser le changement plutôt que d’attendre de ne plus avoir le choix !
3. Le no-code, c’est facile !
Là, au-delà des préjugés, la réponse est moins évidente, ce qui finalement est assez normal étant donnée la diversité des outils, de leur qualité, de leurs cas d’utilisation respectifs, et des gammes déclinées.
✅ Plutôt vrai
Par essence, les outils no-code nous dispensent de devoir apprendre le code, qui est une compétence rare à l’échelle humaine (moins de 0,5% de la population mondiale) et coûteuse car il faut des années de pratique pour être à l’aise en programmation, sans parler de la formation initiale.
❌ Plutôt faux
Selon les outils, quelques jours à quelques semaines peuvent suffire pour être à l’aise en no-code. Mais en maîtriser plusieurs et être capable de les assembler (en stack) pour produire un ensemble cohérent peut s’avérer très technique. Et soyons honnête, avoir un passé tech, ça aide beaucoup (”Ah une API c’est quoi déjà ? Ah oui, c’est vrai. Et un webhook ?”).
Verdict : ✅ vrai ET ❌ faux
De mon point de vue, c’est plus une question de courbe d’apprentissage que de difficulté : le no-code est globalement beaucoup plus accessible que le code traditionnel et produit des résultats visibles plus rapidement. Si j’osais une comparaison, je dirais que c’est un peu comme lorsqu’on commence la musique : on sort vite nos premières mélodies au piano alors qu’il faut plusieurs mois voire années pour produire quelque chose d’écoutable au violon, les parents qui sont passés par là vous le diront !
4. Le no-code, c’est flexible (et notamment parce que c’est rapide et peu cher)
Qualité souvent mise en avant par les aficionados du no-code, la flexibilité du no-code reste relative.
✅ Plutôt vrai
Du moment que les outils ont été bien choisis par rapport au besoin, et que le besoin n’évolue pas au-delà de ce que les outils choisis à ce stade peuvent assurer, le no-code présente tous les avantages qu’on lui connaît, et par-dessus tout, est économe en temps et en argent. Pour cette même raison, il est également flexible en ce que son efficacité nous donne un droit à l’erreur ou au changement d’avis plus important.
❌ Plutôt faux
Toutefois, il existe des cas justement où les besoins évoluent au fil du temps pour finir par sortir du cadre prévu par les outils utilisés pour réaliser le besoin initial. Il n’est alors pas rare de devoir complètement changer d’outil et de devoir remodeler une partie de la stack, ou de “contorsionner” les outils pour répondre au nouveau besoin. C’est alors que les avantages du no-code s’estompent, que la facture s’alourdit, que la stack se fragilise si l’on a recours à des hacks.
Verdict : ✅ vrai ET ❌ faux
5. Le no-code produit du code de mauvaise qualité
Cet argument est souvent avancé par les personnes qui font du web front, et souvent en relation avec des considérations liées au SEO ou à la performance des pages web.
Avant d’aller plus loin, prenons un moment pour nous souvenir que cela ne concerne en réalité qu’une fraction des cas d’utilisation du no-code. Attention donc à ne pas généraliser de manière excessive !
✅ Plutôt vrai
À l’heure où j’écris ces lignes (l’avenir et l’IA me donneront peut-être tort), rien ne saurait écrire du code plus optimisé qu’un développeur front spécialiste pointu et bien-versé dans le SEO. En cela, et dans une optique de comparaison stricte, l’utilisation d’outils no-code quels qu’ils soient produit du code de qualité inférieure.
❌ Plutôt faux
Cela ne signifie pourtant pas que le code produit par des outils comme Webflow soit mauvais, et dans la plupart des cas, la différence en termes de performances reste marginale à faible. Bien sûr, comme toujours, le choix de l’outil reste primordial. Du moment que l’on reste sur des outils qui répondent aux standards du web moderne (responsiveness, mobile-first, etc), on se met déjà relativement à l’abri des mauvaises surprises.
Verdict : ✅ vrai ET ❌ faux
Conclusion
J’ai fait volontairement le choix de terminer sur la question de la qualité du code produit, car je pense qu’il illustre bien l’état du no-code tel qu’il est aujourd’hui compris par les personnes qui s’intéressent au numérique.
Tour à tour, il passionne, dégoûte, divise, alimente des débats enflammés qui finalement ont peu de sens (en 2022, c’est toujours aussi drôle de demander “Windows ou Linux ?” dans une soirée où sont présents de informaticiens 😏)
La vérité, c’est que les avis très tranchés, pour ou contre, trahissent souvent la subjectivité et le manque d’ouverture d’esprit de la personne qui les émet.
À quoi bon vouloir à tout prix comparer deux cas d’utilisation, deux philosophies, deux manières de faire, différentes ? Surtout lorsque les deux objets se veulent eux-même différents en essence et en intention ?
Pour nous, c’est une affaire de compromis : ici, on accepte d’avoir un peu moins de contrôle mais on cherche à itérer plus rapidement, alors on choisit un outil no-code. Là, cette fonctionnalité est primordiale, on part donc sur du code sur-mesure dans le cloud, instrumenté pour être observable.
A Breizh e-nov, nous croyons qu’actuellement, c’est la bonne approche : choisir le bon moyen selon le besoin, concilier les outils et les approches, faire le bon compromis.
“Eh oui, c’est comme le modèle de responsabilité partagée dans le cloud, c’est encore et toujours une question de compromis”, me souffle-t-on dans l’oreillette.
Pour terminer, on vous laisse, cher lecteur, sur une question de notre cru. On a touché du doigt la notion d’observabilité un peu plus haut ; comment vous assurez-vous que vos solutions sont fiables / stables dans le temps ?
On vous livre quelques éléments de notre réponse à cette question dans un prochain billet technique.
En attendant, nous serons heureux de parler avec vous de tout ça ; n'hésitez donc pas à entrer en contact avec nous !
A bientôt, happy no-coding !