Le no-code est un concept peu précis que l’on pense nouveau et qui sert à vendre des logiciels. En tout cas voici l’idée que j’en avais avant de me dire que ça faisait un peu trop de buzz pour continuer à l’ignorer : il est donc temps d’en parler un peu pour découvrir ce que c’est. 

On trouvera aussi NC/LC dans la littérature pour parler des solutions no code/low code, dont le concept est très proche, vous vous en doutez. On nous prome(u)t une programmation visuelle, avec peu ou pas de code, mais jusqu’où peut-on aller ?

Low-code et déceptions conceptuelles attendues

Bien que nos vendeurs favoris nous garantissent que l’avenir est dans le no-code, l’émergence concomitante du terme low-code nous laisse entrevoir des déceptions inévitables, avec une revue des ambitions à la baisse. Pour ma part, j’imagine très mal qu’un outil n’ait besoin d’aucune indication, aucune précision, ni aucune interaction complémentaire avec un humain pour fonctionner correctement ou faire correctement tout ce que l’on souhaite : cela signifierait que tous les cas sont prévus et qu’il serait possible de tout faire.

Il est donc fort probable que de petits ajustements soient nécessaires, par l’ajout de code ici ou là : on pourrait ainsi dire que le no-code serait une limite hypothétique à laquelle on tendrait grâce à des outils de développements qui autorisent un minimum de programmation.

Autre façon de voir les choses, le no-code pur pourrait se limiter à des réalisations simples et rapides, auquel cas il faudrait s’accommoder des limitations inhérentes aux environnements de développement proposés. Mais pourquoi pas : il n’y a pas mal d’usages de ce type possibles en entreprise. Donc soit on veut pouvoir tout faire, et il faudra rajouter du code à un moment ou à un autre, soit on reste dans un concept purement sans code et on sera limité par ce qu’on peut faire.

Autre déception conceptuelle attendue : on a beau dire que le no-code se fait sans code, en réalité c’est un raccourci fallacieux. Le no-code se rapporte en réalité à une programmation visuelle, sans écriture textuelle de code, mais qui représente néanmoins un algorithme qui reste, même avec une forme visuelle, un programme. No-code ne signifie pas no program. Les concepts utilisés resteront les mêmes, mais exprimés différemment.

L’espoir est que ces concepts soient accessibles et utilisés par des populations nouvelles, pour des raisons de gain de temps (« time-to-market ») mais aussi pour éviter certaines erreurs dues à l’éloignement fréquent des développeurs et des métiers, voire pour pallier le manque de main-d’œuvre, le marché de l’emploi en informatique restant assez tendu. Certains programmes d’automatisation trouvent aussi leur place : leur rôle étant d’automatiser des tâches souvent non scriptables (en passant par l’interface utilisateur), la programmation visuelle y trouvera aussi sa place.

Concept jeune ou vieux ?

En tant que vieux moi-même, je sais que ce concept n’a rien de nouveau : je me suis amusé avec des outils de ce genre – même si ça n’en portait pas le nom – dès les années 1990 (voir un peu avant). Sur Mac, il y avait le fameux HyperCard (et son concurrent SuperCard) créé par le génial Bill Atkinson, un outil payant au départ, mais ensuite rapidement distribué sur tous les Mac puis redevenu payant pour les développeurs.

Le principe était de proposer des piles (« stacks ») dont on pouvait concevoir visuellement l’interface graphique, avec la possibilité de coder des actions plus ou moins complexes dans le langage HyperTalk. Essentiellement graphique, on pourrait classer cet outil comme un des premiers outils de low-code. On pouvait y créer des jeux, des livres interactifs, des outils divers (généalogie, composition musicale, etc.) ainsi que des applications sérieuses avec des bases de données.

Source : Blog de TheArchive.org

Dans la même veine, et à la même époque, Adobe Authorware a pu proposer un équivalent, mais sa programmation en mode visuel se limitait souvent à produire des e-learnings (fonction aujourd’hui reprise par Captivate chez Adobe, mais sans que cet outil ne revendique spécialement être low-code).

Plus récemment, webMethods, une plateforme d’intégration d’application d’entreprise (EAI), utilisait une programmation essentiellement visuelle pour réaliser des tâches pouvant être complexes, mais orientées vers les fonctions d’un EAI (à savoir faire circuler les informations et créer des services au sein du système d’information d’une entreprise). Très souvent, des éditeurs de solutions BPM (Business Process Management) se sont orientés vers cette approche très adaptée pour la création et la mise en œuvre de flux métiers (“workflows”), révélant ainsi un cas d’usage tout trouvé pour ce type d’outil.

Exemple de « programme » sous webMethods : on y voit une séquence avec différentes tâches, conditions et boucles, sous forme visuelle. Source : documentation (site softwareag.com)

De nos jours, on trouve des outils low-code chez Microsoft, dans la longue suite d’outils associés à Office, avec par exemple PowerApps. Notez que Microsoft prend bien soin de parler de low-code pour ne pas trop induire ses clients en erreur.

Salesforce ou Zoho proposent aussi des outils low code pour rendre leurs offres encore plus attrayantes, et effectivement l’enrichissement d’un CRM via des petites applications « maison » est également un cas d’usage parfait pour ces usines low code. Du côté des RPA (Robotic Process Automation), on trouve UIPath ou Automation Anywhere, mais aussi Pegasystem, SAP, IBM etc.

À quoi ça sert ?

Le no-code reste de la programmation, ne nous y trompons pas. Par contre, il est évident que la façon de faire tend à rendre accessible la réalisation de programmes informatiques à une population a priori peu familiarisée avec le développement informatique classique, avec ses avantages et ses inconvénients.

Première cible : CRM et workflow

Par workflow, on entend une automatisation de tâches liées à son activité professionnelle, et souvent cela partira de la gestion de la relation client, ou CRM en anglais (“Customer Relationship Management”).

Il s’agira bien souvent d’utiliser une ou plusieurs sources de données pour en créer ou modifier d’autres. Exemple typique : importer des données d’un fichier .csv dans la « vraie » base client de l’entreprise, en vérifiant certaines conditions ou en enrichissant les données à partir des référentiels internes déjà existants.

On peut imaginer un collaborateur qui se déplace et qui n’a accès que périodiquement à son SI (système d'information), et qui note les infos de ses clients ou interlocuteurs sur un coin de table(ur) mais qui a besoin d’officialiser ses contacts. Ou sinon un site web réalisé à l’arrache pour une campagne de marketing, qui aurait recueilli (légalement) des informations sur des prospects, qu’il faudra à un moment ou à un autre faire rentrer dans la base.

Principes d’usage et de programmation

Avant, on requêtait via SQL, on chargeait via un script (ou un ETL pour les plus audacieux), on montait un projet, mais aujourd’hui on clique pour réaliser l’équivalent. Notons que cela diminue forcément le taux d’erreur, principalement dans le paramétrage.

Exemple sous Salesforce de déroulement d’étapes de création d’une application, tout en mode visuel (source : Salesforce)

Autre remarque importante : on voit bien que ces étapes sont génériques, et ne comportent quasiment aucune logique (au sens « métier »), parce qu’une fonctionnalité métier est souvent longue et complexe à décrire, et qu’on rentre alors dans les cas où la programmation visuelle n’apporte pas de gain évident par rapport au code classique. Certains audacieux ajoutent la possibilité de se connecter à un module d’IA pour aider à la décision, mais cela reste pour l’instant difficile à maîtriser.

Étape suivante : gérer le “workflow”, à savoir les suites d’actions à entreprendre, de façon automatisée mais pas obligatoirement (source : Salesforce)

Une fois votre workflow défini (dans votre tête), vous le construisez visuellement puis vous le faites glisser sur votre jolie application finale, et le tour est joué !

Et maintenant on glisse (source : Salesforce)

On voit bien que c’est joli, rapide, mais qu’on est obligé de faire des compromis : pour que tout soit « intégré », il faut accepter les modèles (« templates ») proposés par le produit sans chercher la personnalisation ou la performance à outrance. On ne va pas concevoir un traitement par lots de millions d’enregistrements par cette technique.

Idem pour PowerApps : beaucoup de visuel, un peu de code

En résumé, le low code se prête bien à certains cas d’usage :

• Création de workflows simples,
• Création de sites web peu complexes,
• Automatisation de tâches,
• Analyse de données, recherches marketing, aide à la création de modèles de machine learning etc.,
• Échanges entre SI et logiciels bureautiques,
• Prototypage d’applications.

La liste n’est absolument pas limitative, mais elle permet d’appréhender le type de réalisations possibles.

Vous êtes bien urbain, aujourd’hui ?

Les vendeurs de rêve nous parlent de programmation purement visuelle et de « citizen developers », dans le sens où tout un chacun peut développer une application, sans être du « sérail » ; mais il faut aussi retenir que la notion de citoyenneté implique des obligations et une bonne intégration dans la « société » (en l’occurrence l’entreprise), en suivant des règles d’urbanisme.

La corvée de l’administration de l’outil

Car comme la plupart des outils informatiques, on a en général besoin d’administrateurs techniques, même pour des solutions low-code, surtout si l’usage grandit. La maintenance dans le temps, l’intégration dans les SI, mais aussi la gouvernance (« dire comment l’utiliser et suivre l’usage ») et même le choix des outils doivent rester cohérents et maîtrisés afin de ne pas créer une jungle informatique dans l’entreprise. C’est ce qu’on appelle l’urbanisme en informatique, outil essentiel pour maîtriser la qualité, les coûts et la sécurité.

La sécurité

Souvent délaissée même quand on y est sensibilisé, la sécurité risque fort de pâtir du manque de formation d’une population qui n’est justement pas constituée de professionnels du développement. Et cela va de la sécurité des données, du respect du RGDP à la continuité d’activité. Un programme qui marche, c’est bien, mais il faut aussi savoir réagir en cas de panne ou d’attaque, et cela se prépare avec minutie, surtout lorsqu’on touche à une fonction critique de l’entreprise.

L’effet « shadow IT »

Plus c’est facile et plus on a tendance à en faire le moins possible. Faire un truc qui marche dans son coin, c’est bien, mais que se passera-t-il si le collaborateur part ou s’il est malade ? Que deviendra la valeur ajoutée du développement si personne ne sait plus s’en servir ou le faire évoluer ? Et si un produit exotique a été utilisé, comment le faire évoluer ou rapatrier le code en mode visuel (souvent spécifique à chaque produit et donc peu portable) ?

Laisser le champ libre à des non-développeurs ne veut pas dire leur laisser faire n’importe quoi, et donc un minimum de structuration et de formation sera indispensable pour cette population, qui ne doit pas échapper à une bonne gouvernance pour harmoniser et coordonner les pratiques de développement… Sinon effet silo garanti et fort risque de perte de la connaissance à prévoir : on aura un truc qui marche, mais on ne sait plus comment.

Pour finir

Ces outils ne sont pas magiques : ils sont utiles dans certains usages, mais il reste impératif de cadrer les usages (et les utilisateurs). Le no code ne signifie pas « autorisation de tout faire » : si on veut en tirer le meilleur, il faut que cela se fasse avec contrôle et avec une bonne gouvernance, et parfois de la formation. Le fait même que les utilisateurs ciblés ne soient pas des professionnels du développement fait courir le risque de mauvaises pratiques qui effaceraient le gain de la rapidité et de la fluidité de la programmation visuelle.