Des solutions permettent l’automatisation d’actions et peuvent être implémentées par les utilisateurs eux-mêmes. Ce sont elles qui sont utilisées dans ce contexte. Une telle approche est pourtant risquée puisqu’elle peut mener à des fuites d’information.

Bien qu’elles existent depuis des décennies, ce n’est que récemment que ces outils ont émergé comme une solution à part entière, fournie, supportée mais aussi gouvernée au sein de certaines organisations. Alors que les utilisateurs de ces solutions peuvent automatiser leurs actions ou implémenter par eux-mêmes leurs propres écrans et solutions, le département informatique peut alors se concentrer sur les aspects de la gouvernance et augmenter la sécurité des données. A cela s’ajoute la possibilité pour ce dernier d’accompagner les utilisateurs dans leur quotidien et leur apporter leur expertise. C’est de cette manière que se voit augmenter la collaboration entre les utilisateurs et le département informatique, en profitant de ce que chacun connait le mieux.

L’émergence des plateformes no-code/low-code

Plus loin, plus vite

Face au manque de ressources ayant des compétences de développement, les organisations et ses membres ont besoin d’outils pour créer des solutions bien souvent nécessaires pour apporter des avantages concurrentiels. La démocratisation de la technologie, notamment la capacité d’enregistrer des actions et de les rejouer sans nécessiter de faire du code avancé, mais aussi l’intelligence, permettent, en effet, à tout un chacun de mettre en place des solutions par lui-même.

Mais au-delà du gain pour les personnes en charge de l’opérationnel, c’est surtout l’apparition de nouvelles méthodes de travail qui change la donne. La collaboration avec les équipes qui opèreront les systèmes se voit accrue. Ces derniers peuvent ainsi faire plus qu’auparavant mais aussi plus rapidement. Le département informatique y trouve, en effet, son compte puisque son implication diminue tout en voyant augmenter le nombre de solutions implémentées.

Grace à ces outils, il est possible de voir apparaitre des personnes faisant partie de l’opérationnel faire le lien entre ses équipes et le département informatique. Il s’agit du développeur citoyen, ou citizen developer dans la littérature qui maintient le terme anglophone. Le Citizen Developer est, au sein de l’organisation, une personne qui démontre un intérêt marqué pour les outils digitaux et souhaite approfondir ses compétences techniques. Le Citizen Developer n’a pas besoin de connaître un ou plusieurs langages informatiques, mais de comprendre et maîtriser les plateformes de développement no-code/low-code. Il se fait, ainsi, l’interface entre les équipes et le département informatique, connait les contraintes de sécurité et les besoins des différents collaborateurs en termes informatiques.  Il s’agit d’un axe de modernisation des processus et impliquer les utilisateurs mènera à une adoption plus rapide des changements, pouvant même mener à un changement culturel dans l’organisation.

Des similarités et des différences

Nous parlons de no-code/low-code depuis un certain temps sans donner d’information sur ce qu’il s’agit exactement. Voyons, dès lors, comment les classifier:

• Le no-code permet d’automatiser des actions en composant des suites d’opérations au sein d’un outil de conception, généralement graphique. Il permet, aussi, de créer des écrans ou encore des solutions basées sur l’intelligence artificielle
• Le low-code permet de faire la grande majorité des opérations tout comme en no-code mais en permettant l’utilisation de développement, qui est alors accessible pour des actions particulières
• Enfin, le Robotic Process Automation (RPA), grâce à des capacités de détection et de lecture permet d’aller encore plus loin dans le no-code/low-code puisqu’il tiendra compte de ce qui est visible à l’écran.

Comme nous pouvons le voir, les trois types de plateformes proposent généralement à chacun des outils de modélisation, que ce soient des écrans ou des flux de travail. Le Citizen Developer peut effectuer des intégrations avec d’autres systèmes et automatiser des opérations plus ou moins complexes. A ces cas d’utilisation s’ajoutent des solutions simples basées sur des affichages divers : un site web ou une application ne comportant que peu de logique de calcul et bien d’autres. Parce que les cas d’utilisation sont multiples, nous pouvons voir apparaître, depuis une année ou deux, l’arrivée massive du machine learning et autres intelligences artificielles au sein même de ces plateformes. Ces nouvelles opportinités vont augmenter fortement les possibilités d’exploitation en élargissant le champ des possibilités et en rendant ces capacités accessibles à un plus grand nombre.

Le développeur classique pourra, également, profiter de tels systèmes pour compléter des solutions existantes et ce, de manière plus rapide. Le RPA permet, aussi, d’effectuer des changements sur des applications existantes puisqu’il propose des fonctionnalités de lecture visuelle et de simulation de mouvement de la souris et d’actions clavier, ce qui permet alors de répondre à des besoins complémentaires, en combinant ces capacités de lecture et de simulation aux autres fonctionnalités du no-code/low-code.

Des avantages certains… mais aussi des inconvénients

Sur base des éléments précédemment décrits, il est assez simple de comprendre que la productivité augmente. Les études parlent de pouvoir produire des applications de 2 à 8x plus rapidement, selon les cas d’utilisation. De plus, un avantage considérable est de pouvoir travailler directement avec les utilisateurs voire de les laisser décrire leurs processus dans de tels outils. Cette collaboration, permet d’ailleurs de :

• Réduire les délais de mise en œuvre puisque la charge de travail est partagée entre plusieurs personnes
• Augmenter l’agilité en permettant à l’utilisateur de tester par lui-même les fonctionnalités et les différentes approches
• Réduire les coûts de développement puisque les spécifications des fonctionnalités sont de plus en plus précises voire déjà implémentées 
• Favoriser l’adoption et l’adaptation puisque l’utilisateur est le premier concerné, son implication sera plus élevée 
• Faire appel à des ressources moins expérimentées et économiser des ressources précieuses.

Du point de vue de la gouvernance, ces plateformes viennent avec des avantages considérables : en n’exposant que des capacités exposées, elles réduisent le risque et en assurent la consistance dans les méthodes de développement. Fini donc les éternelles macros dans Excel qui donnent des maux de tête dès qu’il s’agit de les maintenir.

Dans le cas du low-code, tout changement dans la plateforme elle-même nécessite de s’assurer que le code fonctionne toujours. C’est donc un point important à garder en tête dans la gestion du cycle de vie de cette plateforme et des solutions qui sont basées dessus. De plus, alors qu’un passage d’une plateforme à l’autre peut être aisé si toutes les bonnes pratiques ont été suivies, il peut être difficile voire impossible de passer d’une plateforme à l’autre dans le cas des plateformes no-code.

Cela s’appelle le vendor lock-in. Au-delà de ce risque, certains systèmes font appel à du code situé ailleurs. Non maitrisée, cette interconnexion peut mener à des situations complexes, puisque la gestion cohérente entre les deux plateformes est nécessaire.

Des utilisations différentes

De nombreuses utilisations peuvent être envisagées dès que l’on parle de plateformes low-code / no code.

En voici quelques-unes :

• La collecte d’informations dans le contexte des revues annuelles, le recrutement, la gestion de projets, et bien d’autres 
• La circulation d’informations et la collecte d’approbations 
• La visualisation de données, les rapports de données et, dans le même style, les tableaux de bord 
• La manipulation de données, que ce soit la lecture, la transformation ou encore l’enregistrement des informations brutes ou transformées 
• Les solutions basées sur l’intelligence artificielle telles que les chatbots
• L’extension de fonctionnalités d’applications à l’ancienne comme nous l’avons expliqué auparavant 
• L’intégration entre des modules, notamment dans le domaine de l’Internet of Things.

Quelques exemples, pour ne citer que ceux-là. Pour le no-code : Shopify, Webflox, Microsoft Forms, le low-code : WordPress, Power Platform et enfin BluePrism et UIPath pour le RPA.

Comme nous pouvons le voir, il existe des dizaines de plateformes couvrant ces domaines. Voici quelques questions pour déterminer la plateforme adéquate pour les utilisateurs :

• Quelles sont les utilisations attendues pour ces plateformes ? Quels sont les objectifs qui y sont associés ?
• En particulier, prévoit-on de faire des intégrations avec d’autres systèmes ?
• Quelles sont les contraintes dans la gestion des déploiements des solutions ?
• Quel niveau de confidentialité des données est autorisé dans la solution ?
• En conséquence, à qui s’adressent-elles et quelles sont les compétences nécessaires pour y accéder ?

Toutes ces questions doivent être répondues préalablement au choix de la plateforme.

La gouvernance de l’information quand les plateformes sont dans les mains des utilisateurs eux-mêmes

La première étape sera de toujours bien clarifier l’utilisation de chacune des plateformes. En effet, bien que nous pourrions être tentés de mettre en place une même solution pour tous les usages, il s’avère que les plateformes ne sont pas toutes égales et viennent avec des avantages et inconvénients forts différents comme nous l’avons vu.

Ainsi, le RPA, bien qu’il s’agisse d’une extension du low-code ou du no-code, ne sera utilisé que lorsqu’il n’est pas possible de faire autrement. Dès qu’il y a la moindre possibilité de lire ou d’interagir avec les systèmes autrement que par du « clic » ou de la lecture visuelle, il est préférable d’éviter de se créer des dépendances avec des éléments interprétables et qui peuvent régulièrement se voir modifier. Il sera, ainsi, fréquent de définir les règles d’utilisation suivantes :

• Les Citizen Developers peuvent utiliser des plateformes en no-code et uniquement celles-ci, tout du moins s’il n’y a pas de supervision de l’informatique 
• Les développeurs ne peuvent utiliser que des plateformes low-code tout en respectant les règles classiques de publication d’applications (gestion des sources et des versions, respect des règles d’intégration et utilisation du déploiement continu) 
• Les développeurs peuvent utiliser du RPA dans le cas où toutes les autres possibilités ont été étudiées et réfutées. Ainsi, s’il est possible de répondre au besoin en accédant à une interface applicative et non une interface graphique, cette première sera choisie.

Selon la plateforme, il se peut que les solutions développées soient transparentes pour l’utilisateur et que le moteur d’exécution est disponible au même endroit que le designer. Dans un tel cas, il reste très important que le département informatique soit en mesure de savoir ce qui est déployé afin d’éviter des solutions fantômes. Dès que le designer et le moteur d’exécution sont des composants totalement séparés, le déploiement des solutions vers les serveurs adéquats doit rester sous le contrôle de l’informatique.

Il en va de même pour les sources utilisées pour construire ces solutions et les packages d’installation. Il existe de nombreux cas où ces actions elles-mêmes sont source de problème, par exemple parce qu’elles permettent de copier de l’information d’un système à l’autre. Il est, ainsi, important de définir la liste des actions utilisables mais aussi de vérifier que seules ces actions soient utilisées.

Quelle que soit la plateforme, le data management prend toute son ampleur puisque des utilisateurs accèdent à des données et les exploitent par eux-mêmes. Celles-ci se doivent d’être sous contrôle. La définition des sources à utiliser mais aussi des droits d’accès aux données s’avèrent critiques pour y parvenir. Le nombre élevé de sources de données qui doivent être sous contrôle peut mener à des difficultés quand il s’agit de les gérer. Des règles de gestion claires se doivent dès lors d’être définies.

Pour supporter l’ensemble, la meilleure approche est de mettre en place un centre de compétences, regroupant des compétences multiples afin de couvrir les aspects techniques mais aussi la gouvernance, l’architecture ou encore le domaine de la stratégie.

Et ensuite ?

Nous pouvons donc résumer les grandes actions à effectuer de la façon suivante:

1. Définir les objectifs et le périmètre d’utilisation 
2. Définir les règles de gouvernance (cas d’utilisation, méthodes de publication des applications, etc.) 
3. Mettre en place un Centre de Compétences 
4. Mettre un cadre pour que la collaboration puisse s’effectuer, tout en laissant de la liberté en ce qui concerne les méthodes de cette collaboration.

Cette approche devrait définir les prémices pour apporter une approche innovante, inclusive, le tout en mode self-service. Avec le temps, la compréhension mutuelle et l’adoption tant des solutions que des bonnes pratiques devraient fortement augmenter. Certains iront jusqu’à l’hyperautomatisation, c’est-à-dire automatiser tout ce qui est possible, notamment en combinant le no-code/low-code avec l’intelligence artificielle. L’hyperautomatisation semble idéale mais clairement doit s’accompagner d’un changement de mentalité. Hyperautomisation ou non, le besoin de former est, comme souvent, bien présent.

Et dans ce cas, le développeur a-t-il toujours un rôle à jouer ? La réponse est évidemment oui mais son rôle évolue d’un simple rôle d’exécutant à celui de conseiller auprès du Citizen Developer. De plus, il continuera à faire des développements mais plus centrés sur la création de méthodes pour permettre les intégrations : du chargement et transformation de données au préalable mais aussi des interfaces applicatives (APIs).

Le futur du no-code/low-code est-il assuré pour autant ? Le no-code/low-code est certainement une révolution dans le quotidien des organisations. Pourtant avec l’émergence des intelligences artificielles génératives, il est probable que celles-ci prendront une place importante dans les prochaines années. Amazon a, d’ailleurs, annoncé il y a quelques jours que son service HoneyCode sera arrêté. Ce service promettait de créer des applications sans aucun code.

Est-ce la fin du no-code pour la cause ? Non, le no-code continuera d’être utilisé au travers d’outils de conception permettant de manipuler des données et bien d’autres activités de la sorte.