Low code / no code : accélérateur de transformation digitale

Par Olivier Eyraud, Business solution manager, Hardis Group.

Avec les plateformes low code / no code, les utilisateurs peuvent concevoir eux-mêmes des applications métiers. Une façon d’accélérer la transformation digitale… Dans quels contextes ces outils sont-ils recommandés ? Sont-ils adaptés à toutes les situations ? Quel rôle la DSI doit jouer pour encadrer la démarche et accompagner les métiers ?

Les plateformes low code / no code visent les « citizen developers », c’est-à-dire les utilisateurs métier n’ayant aucune compétence en programmation. Elles leur permettent de concevoir eux-mêmes des applications, tout en respectant les standards établis par la DSI. Une façon de lutter contre le shadow IT. La différence entre les deux ? En no code, l’utilisateur développe intégralement l’application mais doit se limiter aux possibilités offertes dans la solution. Le low code permet en revanche d’injecter du code complémentaire, pour la conception de quelques fonctionnalités spécifiques.

L’approche low code / no code vise à autonomiser les utilisateurs pour le développement d’applications liées à leurs cas d’usages très spécifiques. Il s’agit donc principalement d’applications de productivité (réservation de salle de réunion…), de workflows simples (validation de congés, de RTT…) ou encore de portails self-service pour les clients ou partenaires, souhaitant connaître l’état de leur commande, leurs informations de compte, etc. Dans la majorité des cas, ces applications s’appuient sur des données déjà existantes : mails, fichiers Excel, etc.

Le low code / no code peut également être utilisé dans un contexte de « proof-of-concept », pour valider une idée d’application, laquelle sera ensuite développée de manière traditionnelle, avant d’être déployée à plus grande échelle dans l’entreprise. Quel que soit son contexte d’usage, le low code / no code s’inscrit parfaitement dans une démarche d’accélération de la transformation digitale : il combine en effet agilité (conception rapide d’applications, tests fonctionnels sans tests unitaires), absence de déploiement (hébergement cloud), évolutions et redéploiements rapides, et aucun budget TMA à prévoir.

Si l’objectif est d’autonomiser les utilisateurs dans la conception d’applications, un minimum de gouvernance est requis, notamment pour l’inventaire du portefeuille applicatif, afin, par exemple, d’éviter les doublons ou au contraire purger les applications devenues obsolètes ou inutiles.

Une gestion du cycle de vie des applications low code / no code par la DSI qui est également l’occasion d’identifier les applications particulièrement sollicitées, dont les limites sont atteintes ou qui pourraient être améliorées par l’ajout de code, le développement de

fonctionnalités spécifiques ou une amélioration de l’ergonomie. Ou qui nécessiteraient un redéveloppement traditionnel. Car il ne faut pas oublier que les plateformes low code / no code proposent un modèle de licence qui peut s’avérer coûteux et que les capacités de personnalisation des interfaces comme des fonctionnalités restent faibles.

De façon générale, la mise en place d’un « centre d’excellence », ou quel que soit le nom qu’on lui donne, piloté par la DSI est fortement conseillé. C’est cette équipe qui sera en mesure d’accompagner les « citizen developers » dans l’identification des cas d’usages éligibles, dans les méthodes de conception et dans l’animation globale de la démarche au sein de l’organisation : partage des expériences, mise à disposition ou partage de templates, etc.

La démarche low code / no code validée, reste à définir la plateforme à utiliser pour sa mise en œuvre. Les choix ne manquent pas, notamment auprès d’éditeurs spécialisés, pour beaucoup issus du secteur du Business Process Management.

Mais aujourd’hui, ce sont surtout les éditeurs de workplaces qui se sont emparés du sujet, avec Power Apps intégrée à la suite Microsoft Office 365 ou AppSheet au sein de la plateforme Google. Ou encore, plus récemment, des opérateurs de cloud public, tel qu’Amazon Web Services, qui a lancé Honeycode au printemps 2020. Ces plateformes ayant bien sûr l’avantage de pouvoir s’appuyer nativement sur un environnement global préexistant : gestion des identités et des déploiements facilitée, connecteurs déjà existants (SSO, hébergement, BI…), utilisation des serveurs cloud existants, etc. En d’autres termes, l’ensemble du processus est porté par la plateforme, depuis l’idée jusqu’au déploiement opérationnel.

Une simplicité apparente qui souffre tout de même d’une série de bémols importants. À commencer par un risque substantiel de dépendance à l’éditeur : il est en effet impossible de migrer des applications Power Apps vers AppSheet, et inversement. En cas de changement de plateforme, toutes les applications sont à développer de nouveau ! Sans compter que face à une telle dépendance, ces grands éditeurs pourraient être tentés de monter progressivement leurs tarifs.

Quant au choix d’éditeurs spécialisés, le risque est assez similaire : avant de signer, mieux vaut s’assurer de la pertinence de la solution et de la pérennité de l’éditeur, pour éviter une nouvelle fois de tout recommencer depuis le début.

Dans tous les cas, la démarche low code / no code n’a pas vocation à créer des applications stratégiques, qui sont à réserver à la roadmap traditionnelle, mais doit se concentrer sur des applications très opérationnelles et ciblées, sans forte complexité. En cas de doute, un bon indicateur est la durée prévisionnelle de développement : au-delà de 30 jours / homme, un développement classique est préférable car il ne faut pas oublier que l’idée de la démarche est avant tout d’accélérer la transformation digitale, sans risquer de retomber à zéro au moindre problème.

À découvrir sur le même sujet : VIDÉO – Comment la crise actuelle a dopé l’adoption du low code, no code ?