No Code : tu as vu comment tu parles ?
Low Code ou No Code, tout est affaire de proportions mais dans les deux cas, l’expression désigne cette catégorie de progiciels censés nous permettre de répondre aux exigences métiers tout en nous épargnant de fastidieuses lignes de Java, Python, C# ou autres langues barbares. Le sujet est à la mode, rien d’étonnant donc à ce qu’il s’invite dans un débat entre spécialistes de la Data Intelligence : mine de rien, il nous arrive de réfléchir. Rien d’étonnant non plus à ce que l’assemblée se divise en deux : les pro et les anti.
Au-delà du doute sur le réalisme d’une telle promesse, l’opposition telle que je l’ai entendue se résumait surtout à ce point : la Data est affaire de spécialistes, et les non-codeurs n’en font pas partie. Mes connaissances en matière de code se limitant au SQL et à quelques vagues souvenirs de Cobol, autant dire que l’argument m’a plongé dans un abîme de réflexion. OK, je dramatise peut-être un peu mais disons qu’à défaut d’abîme, l’ornière m’est apparue.
La première question que je me suis posée a donc été la suivante : pourquoi lier à ce point savoir et code ? Je pense que la réponse se trouve dans le mot lui-même, qui nous ramène inévitablement au code secret, à ce quelque chose que ne partagent que les seuls initiés, une sorte de Graal à déchiffrer. En ce sens, le code devient pour le développeur moyen et finalité, ce qui donne le sentiment d’avoir craqué Enigma chaque fois qu’un programme se lance pour la première fois… et celui de perdre toute puissance lorsque le Graal devient aussi difficile à débusquer qu’un œuf de Pâques planqué par ma grand-tante agoraphobe (autant dire qu’il suffisait d’ouvrir la porte).
Ceci étant, cette tendance à la simplification ne date pas d’hier, et si l’on voulait être rigoureux il faudrait convenir qu’à moins de le faire en binaire, la plupart d’entre nous ne codent pas : ils parlent à leur machine. De fait, Java, Python et consorts sont des langages (et plus exactement des langues d’ailleurs, mais c’est un autre débat). Comme elles, ils ont un vocabulaire, une syntaxe, une grammaire, et sont capables à l’aide de classes ou autres Perform de réutiliser ce qui a été précédemment décrit. Leur vocabulaire est généralement proche de l’anglais, et masque en réalité toute notion de code (qui sait combien de 0 et de 1 se cachent derrière un simple « While » ?). Et si leur syntaxe peut parfois sembler complexe, elle aussi tend à se simplifier. Mon cher vieux Cobol par exemple interprétait différemment une même phrase selon la colonne dans laquelle elle débutait, ce qui nous obligeait à compter les espaces en début de lignes et était bien entendu totalement contre-intuitif en regard des langues naturelles. Autant dire qu’aucun jeune informaticien n’accepterait plus une telle contrainte ! Il est clair que l’évolution des langages informatiques vise à les rapprocher de plus en plus des langues humaines afin de les rendre accessibles : nous voilà bien loin du code secret et, à l’instar de Monsieur Jourdain, il me semble que nous faisons depuis longtemps du No Code sans le savoir.
De façon générale, tout notre rapport à l’informatique et la technologie est régi par cette même tendance : des menus simples, des options faciles à paramétrer, des Wizards, des chatbots, etc. Plus personne ne s’émerveille de naviguer dans l’explorateur Windows sans passer par une ligne de commande et nous savons tous customiser notre écran de veille. De même, ouvrir et faire pivoter un rapport sans SQL est une évidence : nous nous sommes habitués à la possibilité de modifier en quelques clics le comportement de nos appareils.
Considérons à présent la manière dont cette tendance se traduit dans les progiciels, à travers l’exemple des deux produits dédiés au Master Data Management que sont EBX5 d’Orchestra Networks, et Step de Stibo Systems. Tous deux jouent clairement la carte de la simplification en embarquant autant de fonctionnalités paramétrables que possible, le but étant de pouvoir délivrer un projet rapidement, en se concentrant sur les besoins métiers et non pas les contraintes techniques. Outre le gain de temps, les fonctions pré-embarquées assurent également une maintenabilité optimale, la compatibilité ascendante liée à des migrations de composants annexes (montée de version de la JVM par exemple) étant assurée par les éditeurs.
Mais la réalité métier et la spécificité de chaque entreprise finissent toujours par échapper, dans une certaine proportion, aux meilleures tentatives d’anticipation. En d’autres termes, il y aura toujours une part de règles non arbitrables et cependant non adressables par simple paramétrage. De ce point de vue, les deux solutions adoptent une approche différente.
La philosophie d’EBX5 est résolument multi-domaines (Produits, Clients, Structures, etc.). Dans ces conditions, le spectre des possibles apparaît trop important pour espérer couvrir tous les cas, et une porte de sortie est indispensable. En l’espèce, elle prend la forme d’une API Java qui permet de créer toute fonction manquante, et de l’appeler ensuite depuis le cœur du produit. On pourrait parler de Low Code.
Step, quant à lui, a longtemps été presque exclusivement destiné au domaine Produits (à noter qu’il s’ouvre ces dernières années aux autres domaines de l’entreprise). Dans cette mesure, on peut considérer qu’une fonction manquante est, soit pertinente (elle correspond à de nouveaux usages de la donnée produits, liés au Big Data par exemple), soit non pertinente (e.g. elle relève du système décisionnel). Dans le premier cas, cette fonctionnalité doit être ajoutée par l’éditeur dans le cœur même du produit, et dans le second il appartient à l’intégrateur de jouer son rôle de conseil auprès du client afin de garantir le respect des bonnes pratiques. Le développement n’étant porté ni par le client, ni par l’intégrateur, on peut parler de No Code.
Et c’est bien là une promesse d’avenir parce que l’enjeu ultime de la technique est, je crois, de se faire transparente. Rendre à l’utilisateur final la maîtrise de sa donnée, lui permettre de changer ses règles métiers, d’intégrer une nouvelle typologie de données, le tout sans l’aide de l’IT, n’est-ce pas ce que nous souhaitons tous ? La réalité est toute autre, et l’IT est toujours indispensable pour déployer ces produits. Pourquoi ? Parce que le No Code implique un si grand nombre et une telle finesse de paramétrages que le progiciel expose ainsi un nouveau métalangage auquel il est indispensable de se former. Comme le développeur Java, l’expert solution doit apprendre un vocabulaire et une syntaxe.
De plus, le No Code n’a de sens que dans un univers extrêmement cadré : on l’a vu, plus le domaine d’action du produit est large, plus les risques de faire face à un besoin non couvert sont élevés. Avez-vous déjà essayé de construire un tracteur avec une boîte Légo « conquête de l’espace » ? Ça ne marche pas. De la même façon, vous ne ferez pas de CRM avec un MDM, et vice-versa.
Dans ces conditions, qu’avons-nous gagné ? De même qu’un simple « while » Java recouvre une myriade d’instructions obscures, le moindre paramétrage de Step ou EBX5 recouvre lui une myriade d’instructions Java, mettant entre nos mains des outils de plus en plus puissants mais aussi de plus en plus spécialisés. Enfin, ces outils eux-mêmes se combinent en un métalangage plus large encore, qui forme le Système d’Information dans sa globalité. Au final, la fonction codage se déporte de plus en plus en amont de la Data Intelligence, formant un assemblage de poupées gigognes qui s’éloignent des fonctions machines pour recouvrir de plus en plus concrètement des fonctions métiers.
Le No Code au fond, c’est l’histoire du langage.