Low-Code, No-Code : l'offre avance, pas la gouvernance

Airtable, Bubble, AppSheet, PowerApps, Honeycode... les outils low-code / no-code prolifèrent. Et pour cause, ils offrent énormément de possibilités aux utilisateurs non développeurs pour créer des applications répondant spécifiquement à leurs besoins. Après des grands noms comme AWS, Google ou Microsoft, SAP vient d'ailleurs d'annoncer le sien : SAP Build.

Toutefois, derrière le discours d'émancipation des utilisateurs (le fameux "empowerement"), l'entreprise doit aussi voir la réalité des choses. Une prolifération incontrôlée de tels outils comporte son lot de risques : fuite de données, absence de support et de documentation, dimensionnement potentiellement inadapté, non respect de chartes d'ergonomie ou, pire, de sécurité...

Quelle attitude adopter ?

1) Ne pas chercher à interdire les outils low-code / no-code

Interdire le low-code / no-code dans une organisation aurait le mérite de se préserver des risques. Mais cela présente deux inconvénients majeurs.

• C'est inefficace : le low-code / no-code est le dernier avatar d'un phénomène bien connu : le shadow IT. Qu'on cherche à l'éviter est compréhensible, mais vouloir s'en prémunir est illusoire. Les "utilisateurs avancés" chercheront toujours à simplifier, automatiser certaines de leurs actions. Il fallait auparavant écrire des macros, des lignes de code relativement simples ; les outils low-code / no-code progicialisent cette approche, à destination de ce que les éditeurs appellent désormais les "citizen developers".
• C'est contre-productif : donner aux collaborateurs les moyens de bien réaliser leur travail est essentiel pour contribuer aux objectifs de l'entreprise. Or les DSI, avec la meilleure volonté du monde, ne peuvent fournir l'ensemble des outils répondant aux besoins spécifiques de tel collaborateur ou groupe de collaborateurs. Si les outils low-code / no-code peuvent aider les employés à créer de la valeur, il faut au contraire les y encourager en encadrant la pratique.

2) Encadrer la pratique du low-code / no-code

"Puisque ces mystères me dépassent, feignons d'en être l'organisateur." Reprenons cette sage maxime de Jean Cocteau, mais avec un aspect volontariste, en définissant des règles et en cherchant à organiser les choses.

• Des règles claires : les collaborateurs doivent savoir à quoi s'en tenir de manière simple et claire, sans avoir à se plonger dans des tonnes de documentation écrite ou de tutoriels vidéos. La documentation est bienvenue pour expliciter, détailler tel ou tel point, mais l'approche initiale doit être rapide. En quelques minutes, un "citizen developer" doit comprendre quel outil il peut utiliser ou non, ce qu'il a le droit de faire avec, ce qu'il ne peut pas faire, et quand il doit demander une autorisation spécifique.
• Une gestion du cycle de vie : le respect des règles doit être suivi dans le temps, car les applications peuvent évoluer (périmètre, nombre d'utilisateurs, type de data, etc.). Des applications qui ne sont plus utilisées devraient être proprement archivées. Celles qui continuent de rendre service et restent dans le cadre d'un usage raisonnable ont vocation à perdurer. Des applications qui deviennent critiques et/ou font l'objet d'un usage intensif doivent faire l'objet d'une attention particulière : par définition, si une application devient critique, c'est que le besoin doit être pris en compte et géré par l'IT.
• Des communautés de pratique : au sein d'une organisation, de nombreux collaborateurs peuvent travailler sur les mêmes sujets, se retrouver confrontés aux mêmes problématiques et devront monter en compétence sur les mêmes outils. Sachant que l'IT n'a pas vocation à réaliser de support pour les applications créées avec de tels outils, et que ces applications peuvent rapidement devenir importantes pour certains processus, il devient essentiel que les "citizen developers" s'organisent entre eux, au sein de communautés. Ce seront aussi de bons interlocuteurs pour le dialogue avec la DSI. Ainsi que des vecteurs d'acculturation au sein des équipes métiers, sur le modèle des Centers of Excellence (ou plutôt, comme on dit chez Wenvision, des Centers For Excellence).

3) Instaurer une politique outillée de gestion des accès à la donnée

L'essentiel de ce qu'on demande aux outils low-code / no-code consiste à manipuler de la donnée. Si on veut vraiment aider les collaborateurs à créer de la valeur pour l'entreprise tout en minimisant les risques, il faut aller largement au-delà d'un étiquetage ou d'une classification C0, C1, C2, C3.

• Permettre aux collaborateurs de trouver et comprendre la donnée. La création de produits data par les utilisateurs eux-mêmes est un levier puissant de création de valeur : automatisation d'actions, prévisions plus justes, analyses poussées, information contextualisée... Le problème étant de savoir que la donnée nécessaire existe, d'être capable d'y accéder et de comprendre le contenu des jeux de données et comment les manipuler. Qu'on utilise un data catalog ou un autre système, l'essentiel est donc de faire en sorte que la donnée au sein de l'entreprise soit "découvrable" et explicite.
• Automatiser et fiabiliser la gestion des accès. Impossible pour une DSI de gérer l'ensemble des demandes des collaborateurs d'accéder à telle ou telle donnée, cela demanderait trop de temps. Il est tout aussi impossible de tout ouvrir sans condition, cela présente trop de risques. Impossible enfin de tout fermer, surtout quand l'injonction de la direction générale est de favoriser les initiatives data driven. Il faut donc responsabiliser les data owners au sein de chaque métier, définir un ensemble de règles communes (en fonction d'attributs, de personas, etc.) et chercher à automatiser la grande majorité des droits d'accès.