Les nouvelles offres #nocode, mort ou salut des développeurs ?
image Shutterstock

Les nouvelles offres #nocode, mort ou salut des développeurs ?

C’est une évidence, le marché du « #nocode » semble atteindre l’âge de la maturité. Fédérant les outils promettant le développement d’applications « sans écrire une seule ligne de code », et donc en se passant des développeurs, cette tendance signe-t-elle leur fin ? pas si sûr…

Derrière le mot valise #nocode, les WebFlow, Bubble ou AirTable, pour ne citer qu’un petit échantillon, génèrent un véritable engouement sur le web et les réseaux sociaux. En pratique, ce hashtag désigne une kyrielle d’outils, en mode SaaS pour la plupart, qui ont des périmètres fonctionnels et des ambitions très variés. Du simple connecteur de données, comme Sheety, à l’atelier logiciel complet comme Bubble ou le français Panda Suite, on peut trouver aujourd’hui tous les composants permettant de fabriquer, comme un jeu de Lego (ou de Mécano, pour ma génération ;-) ) n’importe quelle application web ou mobile. Sur le fond, le besoin à satisfaire n’est pas nouveau. Et ces réponses, bien que nouvelles en apparence et parfois vendue comme une révolution, ne sont qu'une la suite logique d'un long passé.

Une vielle quête du Graal

Dès l’apparition des ordinateurs civils, à l’après-guerre, leurs utilisateurs, qui étaient par essence aussi leurs programmeurs, n'ont eu de cesse de mettre au point des interfaces ou des langages, leur permettant de parler à leurs machines autrement qu’en stimulis binaires, les fameux 0 et 1. Toutes les générations d'informaticiens ont alors suivi ce long développement des langages, des Fortran ou Cobol de l’époque, aux Java, C#, Javascript, Go ou Python d’aujourd’hui. Langages qui, bien que dits « évolués », restent pour le novice un charabia abscons. Pour contourner ce défaut, dès les années 70, IBM imagine le GAP, premier outil de l’histoire qu’on pourrait qualifier de #nocode. L'histoire raconte qu'il voulait redonner du travail aux comptables dont il absorbait les missions avec ses ordinateurs. La méthode s’appuyait sur formulaire standardisé, où le concepteur cochait des cases dans un agencement précis, pour exprimer son souhait de traitement. Bon, ça restait fastidieux et très éloigné de nos outils d’aujourd’hui mais c’était un début.

Dans les années 80, avec l’avènement des micro-ordinateurs et des interfaces graphiques (Mac OS puis Windows), on voit apparaître des outils de développement adaptés à ces nouveaux univers. C’est la période de gloire des Visual Basic de Microsoft ou plus tard de WinDev en France, premiers IDE (interface de développement) à vocation #nocode. Le développeur pouvait s’appuyer largement sur des blocs graphiques préconçus et des interactivités pré-gérées et le tout, à grand renfort de conception visuelle et de drag’n drop. Au niveau utilisateur bureautique, Microsoft Access, est déjà un tout-en-un #nocode. Avec un peu de temps, on peut en effet construire une application complète autour d’une base de données, avec des menus, des formulaires, des états, et toujours sans écrire une seule ligne de code, largement guidé par des assistants et des modèles préétablis.

L’avènement du web, au milieu des années 90, voit émerger d’autres outils #nocode : les éditeurs HTML (GoLive, FrontPage ou Dreamweaver). Ils permettent alors de fabriquer nos premières pages web, sans écrire une seule ligne de code…HTML, seul langage reconnu par nos navigateurs.

Dans leur prolongement, les années 2000 voient se développer les CMS (Content Management System) : les Wordpress, Drupal ou Joomla. Ils permettent alors de concevoir un site web et de maintenir son contenu, là encore, sans écrire quoi que ce soit, juste en choisissant dans des catalogues d’options, de plugins ou de modèle d’interfaces (les fameux « templates »). On est déjà encore et toujours dans du #nocode. Ce marché a d’ailleurs donné naissance à nombre de webmasters et d’agences web, travaillant exclusivement sous Wordpress par exemple et premiers développeurs #nocode, un début de réponse à la question initiale.

L’avènement des AirTable, Bubble ou Power Apps, vrais outils qualifiés de #nocode est donc une suite logique et naturelle. Comme attendus, et même si certains d’entre eux arrivent avec de nouveaux paradigmes – comme AirTable - ils poussent simplement plus loin les pratiques de leurs prédécesseurs : interfaces totalement graphiques, catalogues de modèles, multiples assistants et toujours la souris comme bras armé. Le Graal d’expliquer à la machine ce qu’elle doit faire sans le dire dans sa langue est-il atteint ? on en est encore loin mais on s’en rapproche.

Des avantages évidents

Tout comme leurs prédécesseurs, les outils #nocode offrent la facilité, la rapidité et la souplesse dans la composition des applications. Ce qu’elles ont de plus aujourd’hui, c’est qu’elles s’inscrivent toutes dans une architecture « cloud » avec ses paradigmes techniques et commerciaux : un hébergement externalisé et redondant, un déploiement de fait aisé, une montée en charge fluide et maîtrisée pour les aspects techniques. Un modèle tarifaire simple puisque souvent basé sur l’abonnement, en lieu et place d'une acquisition de licence, pour l'aspect commercial. Le "multi-plateformes" natif (desktop, tablette, mobile) est aussi un atout certain, bien que cet attribut était déjà présent dans certains outils du siècle dernier (WinDev).

Mais des défauts endogènes occultés

Le premier défaut est inhérent à l’environnement cloud de ces outils : le mode SaaS offert pour la plupart soulève les questions récurrentes de sécurité, confidentialité et réversibilité des données qui y sont gérées. On a du mal à imaginer une entreprise développer une application critique pour son activité sur une plateforme dont elle ne maîtrise pas la solidité et la pérennité. Crainte amplifiée par la nécessité fréquente d'agréger de multiples outils et services indépendants pour couvrir l'ensemble des besoins fonctionnels.

Le deuxième défaut est propre à toutes les solutions promettant de répondre à des besoins individualisés, à partir d’une mécanique unique. Piège vécu par tous ceux qui s’y sont déjà frottés au travers des CMS par exemple et que je nomme 80/20 ou 90/10 : L’outil va permettre de résoudre aisément et rapidement 90% de votre problème, et les 10% restant - que vous avez souvent négligés en vous engageant avec enthousiasme dans le projet - vont vous compliquer la vie, vous faire perdre temps et argent, voire vous amener à abandonner le projet s’ils s’avèrent critiques.

Le troisième écueil, et non des moindres, est celui de la confusion entretenue dans le potentiel réel de ces outils avec les compétences et la disponibilité d’un usager non spécialiste. Leur présentation, toujours plus séduisantes, amènent à faire croire qu’on pourra tout faire avec. Ce qui est une erreur. Car si un bon ouvrier a toujours de bons outils, ce n’est pourtant pas l’outil qui fait l’ouvrier. Ce n’est pas parce que vous maîtriserez Word que vous deviendrez auteur de roman à succès. Tous ceux qui travaillent – les développeurs, chefs de projet et autres PO – dans la conception d’applications le savent bien. Outre du temps dédié, leurs activités imposent des dispositions mentales particulières, d’abstraction pour la conception, de raisonnement algorithmique pour le codage organique des process, qui ne s’improvisent pas et/ou ne peuvent émerger simplement par ces outils. Combien d’utilisateurs bureautiques, forcément un peu curieux et volontaires, ont cédé aux sirènes du #nocode version Access par exemple, et qui ont souffert – en temps et énergie – pour arriver à un résultat potable, quand ils l’on atteint ?

Alors, mort ou salut ?

Evidemment, ni l’un ni l’autre. L’offre actuelle a tout pour séduire un large éventail de nouveaux praticiens et initier encore de nouveaux profils de développeurs. C’est donc un marché qui s’élargit. Et puis, si les premiers chantiers ne révèlent pas de carrières de développeurs, ça promet toujours du travail de maintenance et d’évolution pour des spécialistes métiers.

Terminons sur une mise en garde de vieux routier. Ne l’oublions pas, ceux qui ont réussi et fait fortune à l’époque de la ruée vers l’or, ce ne sont pas les chercheurs d'or mais les vendeurs de pelles et de pioches. En d'autres termes, ne foncez pas acheter cette machine à pain, même si son packaging semble séduisant et appétissant, laissez-faire votre boulanger, vous aurez probablement beaucoup de mal à l'égaler, en qualité de production et dans la durée.

Jean Jacques Zemmal

Consultant Formateur Gestion chez Eurocompetences

4 ans

Meilleurs vœux Laurent

Pierre BUFFET

Product Owner du service LS MESSAGERIE MQSERIES DEA SNCF

4 ans

Très juste analyse, pour avoir vécu une partie de l'évolution du dev, j'ai cru a ces outils tout fait avant de me rendre compte que ce sont des outils pour des besoins standard. Dès que la demande client sort de l'ordinaire et l'on sait l'imagination des clients ces outils dont souvent plus générateur de sueurs, de bugs et d'heures perdue.

Encore une fois, bravo Laurent pour ce post efficace et éclairant... je partage le point de vue de la fin : ce ne sont pas les outils qui créent/conçoivent, c'est l'homme lorsqu' il a le cerveau correctement orienté ! Bonne année, attention à vous

Nathalie Badreau

Veille Stratégique Social Media - Web - Tech | Enjeux Metaverses Influence & Leadership des Dirigeants - Conférencière

4 ans

Merci Laurent pour cette mise en perspective fort documentée. Nos points de vues sur le numérique divergent parfois ( à propos nous fêtons la mort de Flash Adode ce soir 😉😂) mais nos échangent sont toujours palpitants! Merci 🙏

Identifiez-vous pour afficher ou ajouter un commentaire

Plus d’articles de Laurent Tedesco

Autres pages consultées

Explorer les sujets