Le numérique s’implante plus ou moins difficilement dans les TPE et PME françaises. La relative lenteur de cette implantation s’explique facilement par le manque de compétences informatiques disponibles au sein de ces mêmes entreprises. Et faire appel à des agences externes coûte cher et est souvent perçu comme risqué et pas toujours à tord.

Pourtant l’usage des outils numériques est devenu incontournable et tout le monde a compris l’intérêt que cela représente en terme de productivité et d’économie.

Dans ce contexte, le No code semble apporter la réponse qu’il faut : permettre aux néophytes de développer leur propres outils sans aucune compétence informatique, pour des coûts moins élevés et des délais raccourcis.

Mais est-ce vraiment aussi simple ? C’est ce que nous allons voir dans cet article.

Un peu d’histoire ne nous ferait pas de mal

Avant de parler de No code (ou no-code ou nocode), il me semble utile de comprendre d’où ça vient.

Je vous propose de grimper dans ma machine à remonter le temps pour que je puisse partager avec vous mon expérience de l’informatique.

Prêt ?

Zou, en avant pour 1980 !

Bien entendu l’histoire de l’informatique ne commence pas avec les années 80, mais pour ce que j’ai à partager c’est un bon début.

Dans les années 80, le mot « codeur » n’existait pas dans le milieu informatique. A cette époque un codeur était un appareil qui codait des messages, aujourd’hui on dirait plutôt « cryptait ».

Pour désigner la personne qui s’occupait de parler avec les ordinateurs, qui n’étaient pas encore des PC, on utilisait le mot « Analyste-programmeur ». Et ça, c’est intéressant.

En fait, un analyste-programmeur c’était parfois, voire souvent, deux personnes aux compétences bien distinctes : un analyste et un programmeur.

L’analyste devait comprendre les besoins exprimés par son client pour les transformer en algorithmes. Le programmeur devait transformer ces algorithmes en langages compréhensibles par une machine. Ce programmeur était, en quelque sorte, le traducteur entre la pensée de l’analyste et l’ordinateur : il était capable de parler à l’ordinateur pour que ce dernier puisse exécuter les ordres de l’analyste.

Dans les années 80, il n’était déjà plus question de cartes perforées, mais de langages évolués (COBOL, FORTRAN). Le programmeur utilisait ces langages pour donner directement des instructions aux ordinateurs via son clavier (avec l’aide d’un pupitreur). Ce travail se faisait souvent de nuit, au moment où les programmes ne tournaient pas.

Ce programmeur travaillait donc souvent avec un pupitreur. Il s’agissait d’un opérateur de saisie chargé d’entrer les instructions informatiques au clavier de son terminal.

Il est intéressant de noter qu’à cette époque, l’analyste et le programmeur n’intervenaient pas directement sur les ordinateurs, du moins ils n’étaient pas censés le faire.

Dans la hiérarchie professionnelle, tout le monde savait que l’analyste était supérieur au programmeur qui était lui-même supérieur au pupitreur. D’ailleurs, ce dernier était perçu comme une secrétaire un peu particulière (les deux passait leur vie devant un clavier !). Ceci s’explique fort bien : c’est beaucoup plus compliqué d’apprendre à créer des algorithmes que d’apprendre un langage informatique et encore plus que d’apprendre à utiliser un clavier. Et ça, c’est toujours vrai aujourd’hui.

Peu à peu, les métiers d’analyste, de programmeur et de pupitreur ont fusionné pour accoucher de l’analyste-programmeur. Le pupitreur à carrément fini par disparaître, du moins dans sa forme initiale. Ce faisant, les processus gagnaient deux étapes et évitaient pas mal d’erreurs d’interprétation.

Au milieu des années 80, les ordinateurs familiaux ont commencé à inonder le marché, créant ainsi beaucoup de pupitreurs, un peu de programmeurs et quelques analystes. Et c’est à ce moment que la confusion a commencé : toute personne qui pouvait, grâce à un langage simple comme le BASIC, faire exécuter un ordre à son PC pouvait se prendre pour un analyste-programmeur. Mais en était-ce vraiment un ? A part quelques exceptions, évidemment que non !

La beauté d’un programme ne repose pas sur son langage mais sur ses algorithmes.

Puis Internet a débarqué. Et les analystes-programmeurs sont devenus des programmeurs, puis des codeurs.

Passons par les années 2000…

Avec l’arrivée du Web et de son langage, le HTML, le monde a découvert l’informatique facile et s’y est engouffré.

La simplicité du HTML a encore enfoncé le clou : plus simple que le BASIC (mais pas vraiment comparable), plus facile à utiliser, il permet des résultats rapides et voyants, donc satisfaisants.

Et tout le monde est devenu « codeur ». Pourtant, si je ne me trompe pas, le code, c’est le langage. Alors ou est passé l’analyse ? Je dirai, si j’étais taquin, que l’analyse a bel et bien disparue quand on voit la qualité de certains codes fournis par ces nouveaux codeurs auto-proclamés.

…puis par 2010…

Aux alentours des années 2010, la technologie Web a évolué et les ordinateurs sont devenus beaucoup plus puissants. Ce sont de véritables applications embarquées qui sont proposées : les modes SaaS (Software as a Service). Il s’agit de logiciels qui peuvent être utilisés à distance sans aucune installation sur un PC local.

Pour développer ces logiciels il faut de véritables analystes-programmeurs (qui sont devenus des programmeurs) alors qu’au niveau de l’utilisateur, la simplicité d’utilisation est de mise. Car selon la règle bien connue des informaticiens : plus c’est simple pour l’utilisateur final et plus c’est complexe à développer.

…retour en 2021 et au-delà (on verra)

Avec la multiplicité des SaaS est apparu le besoin de les faire communiquer entre eux pour encore plus de souplesse et plus de performances. Les dieux de l’informatique ont donc créé des SaaS pour automatiser des SaaS…

Le don nous est fait de pouvoir créer des applications complètes, en mode SaaS, sans écrire la moindre ligne de code. Ainsi, on peut créer de véritables logiciels « métiers » constitués d’un assemblage de briques SaaS qui pourront chacune avoir un rôle bien précis.

Ainsi est né le No code.

Le métier du no codeur consiste alors à faire que toutes les briques puissent correctement dialoguer entre elles, en utilisant d’autres briques spécialisées et sans écrire la moindre ligne d’un langage informatique quelconque.

Dans la vraie vie, c’est un peu différent. On est souvent amené à ajouter quelques lignes de codes ici ou là. Dans ce cas, on parle de « low code » en lieu et place du « no code ».

Mais, au final, ce sont de véritables projets informatiques qu’il faut penser et créer. Si le langage a été simplifié par l’arrivée de nouvelles briques plus simples à mettre en œuvre, il ne s’est toujours pas affranchi de l’étape préalable cruciale : l’analyse.

Pourtant, la majorité des promoteurs de la mode du No code oublient cette étape en prétendant que n’importe qui (comprendre sans compétence particulière) peut développer des applications complexes.

C’est faux !

Alors, le No code est-il pour tout le monde ?

En fait, le No code remplace l’étape d’apprentissage d’un langage qui permet de donner des ordres à un ordinateur, mais absolument pas l’étape qui consiste à analyser le besoin et à le transcrire en logique informatique.

En pratiquant le No code, on peut gagner beaucoup de temps sur le « codage », mais aucun sur l’analyse. C’est déjà beaucoup car cela permet une forte réduction des coûts et des délais. Mais en aucun cas, cela ne permet à des néophytes de créer leurs propres applications sans une solide formation préalable.

Avec le No code, le risque de zapper la phase d’analyse est grand. Ce qui conduira inévitablement à des déceptions.

D’ailleurs ceux de nos clients qui s’y sont risqué l’ont regretté : plateformes de No code chères, temps d’apprentissage et maîtrise de l’outil longs, maintenance compliquée. Et je ne parle pas du risque de voir ses données hébergées on ne sait où par on ne sait qui.

Le No code pour des fonctions simples…

Si vous êtes incompétent en programmation informatique et que votre besoin est simple, comme envoyer un email si votre SaaS de comptabilité identifie un impayé, cette technologie est bien adaptée et fera le job.

Après quelques tutos pêchés sur YouTube, vous vous en sortirez très bien.

…mais attention aux usines à gaz.

En revanche, si votre besoin est complexe, vous devriez faire appel à des pros du No code. Si non, vous risquez de passer beaucoup de temps à inventer une usine à gaz qui ne fonctionnera pas vraiment.

Ah oui, il faut que je précise une chose : les meilleurs « no-codeurs » sont pratiquement toujours des codeurs. Comme quoi, c’est bien l’esprit d’analyse qui compte, même en no-code. Et la boucle est bouclée !