Et si vous osiez le No-Code/Low-Code ?

le 25/11/2021 par Sylvain Fagnent, Alain Faure

Tags: Software Engineering, No Code / Low Code, Delivery

1-Introduction

“Previously on the Octo’s Blog” :

Ces 3 articles témoignent que dans un monde où les compétences IT sont rares et chères, lorsqu’on veut innover, tester vite et que l’on a besoin d’IT, l’outillage Low-Code ou No-Code peut être un atout. Ce dernier en particulier ne nécessite que des compétences peu élevées en IT et permet aux innovateurs/collaborateurs de tester vite des concepts tout en ayant accès à des facilités de déploiement sur étagère. En étant préparé et bien guidé, on s’apercevait que les dites plateformes ont pour certaines d’entre elles de nombreux atouts (Les dix commandements d’une plateforme No-Code mature ). Pourtant, tout n’était pas aussi simple et en expérimentant nous mêmes les approches nous nous rendions compte que très vite pour pouvoir faire ce que l’on souhaitait, il fallait aller sur le Low-Code - “No-code ou Low-Code pour une application de gestion développée avec AirTable & Zapier … that is the question !”. Alors certes les compétences nécessaires en IT restent raisonnables mais sans un minimum de notions en conception d’application et en architecture IT, on peut vite tomber dans des chausses trappes. Mais alors, quid des pures plateformes de Low-Code dont l’une des promesses est d’offrir d’avantages par rapport aux plateformes No-Code, comme des possibilités étendues de développement industrielles et accélérées - Les Fake News du Low-Code – Compte-rendu du talk d’Alain Fauré et Sylvain Fagnent à la Duck Conf 2021. Pour aller un cran plus loin nous avons donc comparé 2 plateformes Low-Code standard du marché : Mendix et Outsystems.

2-Que valent les plateformes Low-Code Mendix et Outsystems ?

Nous avons étudié les deux plateformes Low-Code “pure player” leaders du marché depuis quelques années, à savoir Mendix et Outsystems.

2.1-Hypothèses

L’objectif était d’évaluer ce qui les différencie lors de leur mise en œuvre sur une application de gestion de complexité moyenne (en l'occurrence une application de gestion du parc applicatif d'un SI). Par application de gestion de complexité moyenne on entend une application :

qui n’est pas critique (sans exigences 24/7 en terme de disponibilité),
qui a quelques dizaines d’utilisateurs,
qui présente peu d’interaction avec le reste du SI,
qui s’appuie sur un modèle de données d’une quinzaine de tables

Ce type d’application est la cible idéale pour ces outils Low-Code car le développement classique peine à répondre (coûts, délais, ressources disponibles) à ce type de besoin. En outre, les solutions Low-Code doivent commencer par prouver leur valeur avant de pouvoir accéder à des projets avec des enjeux plus importants.

2.2-Démarche

Notre démarche a été de développer la même application sur les deux plateformes avec les mêmes exigences fonctionnelles, mais en s'appuyant sur les assets fournis par chacun des produits.

2.3-Résultats

Mendix a une approche plus “modèle/concept” alors que Outsystems est plus orienté “développeur”, ce qui fait que nous oiseau n’avons pas rencontré les mêmes facilités et difficultés sur les deux plateformes. Cependant, au final force a été de constater que d’un point de vue du développeur le constat est similaire pour les deux plateformes :

(+) La prise en main des plateformes est relativement aisée (tutoriels, documentation),
(+) Le développement d’écrans simples de type “CRUD” est très efficace,
(+) Il est rapide d’avoir une première version opérationnelle de l’application,
(!) Le travail de conception reste important et nécessite du savoir-faire,
(+) Il est possible d’aller très loin dans la customisation pour obtenir des écrans qui correspondent à la logique utilisateur (et non au modèle de données),
(-)…plus on va loin dans la complexité des écrans ou des traitements, plus l’effort tend vers celui d’un développement classique.

2.4-Conclusions & recommandations

Sur ce type d’application de gestion de taille moyenne on privilégiera pour commencer :

Des applications où l’exigence des utilisateurs est suffisamment simple pour que peu d’écrans complexes soient à créer
Des projets à courte durée qui vont favoriser les gains apportés par ces plateformes dès le début du projet...
… mais avec suffisamment de valeur/d’utilisateurs pour justifier un coût de licence mensuel de plusieurs milliers d’euros

Cela ne signifie pas que ces plateformes ne peuvent pas faire plus, mais dans une démarche progressive, elles doivent déjà prouver leur valeur sur ce type de projet avant d’aller sur des domaines où leur avantage compétitif va s’éroder par rapport à du développement classique.

3-Finalement le No/Low-Code même combat ?

3.1-Espace de liberté et d'autonomie pour les employés

En donnant des espaces de libertés à tous les employés dont les compétences IT sont moins élevées qu’à la DSI, on peut offrir un catalogue de solutions No-Code / Low-Code leur permettant de tester/développer rapidement des applications par eux-mêmes. Ainsi on peut schématiquement résumer les approches comme suit :

MVP / POC simple en No-Code :
1. Complexité à implémenter : simple
2. Prérequis : des employés formés à des outils No-Code sélectionnés
3. Coûts d’investissement : quelques jours
MVP / POC / Application d’efficacité opérationnelle avec complexité fonctionnelle plus importante en Low-Code :
- Complexité à implémenter : plus importante que ce que permettrait nativement les outils No-Code
- Prérequis : des employés formés à des outils Low-Code sélectionnés + soutien par des experts externes sur les plateformes
- Coûts d'investissement : quelques mois + coûts récurrents des licences

Note : Il est important de garder à l’esprit que l’utilisation d’une plateforme de Low-Code fait changer d’ordre de grandeur par rapport au No-Code. Que ce soit dans les coûts de licences, les profils des modeleurs (développeurs en No-Code/Low-Code) ainsi que leur formation et le support nécessaire.

3.2-Bon ok ! Mais si je me lance quels sont les prérequis ?

Identifiez et sélectionnez quelques plateformes NoCode et/ou LowCode
1. Approximativement moins de 5 pour rester dans un écosystème maîtrisable dans la durée et c’est largement suffisant pour couvrir les besoins évoqués.
2. A vous de voir si une solution Low-Code est utile dans votre contexte. Compte tenu d’une plus grande complexité et besoin en expertise sur ce type de plateforme, nous conseillons d’en choisir une unique. Cela vous permettra, une meilleure optimisation de vos ressources et des normes et standards autour de ladite plateforme.
Accélérer l’emboarding sur chaque plateforme en prévoyant
1. Une grille d’analyse rapide pour aider à choisir une plateforme. Dites ce qu’elles peuvent faire et ne pas faire.
2. Un QuickStart dans le cadre de votre entreprise en incluant un éventuel “do/don’t” de la plateforme dans votre environnement.
3. Une FAQ contextuelle à votre entreprise en complément de la FAQ de l’éditeur.
4. Une mailing liste/forum interne en complément des communautés externes.
5. Plus tard, prévoyez des sessions de partage et de retours d’expérience en interne.
Formez ou autorisez les collaborateurs à se former à une ou plusieurs plateformes No/Low-Code
1. Il existe de nombreux modules/tutoriaux en ligne que les éditeurs mettent à disposition et des organismes dispensent des formations de découverte des outils No-Code.
2. Les plateformes Low-Code fournissent aussi des tutoriaux, mais ils s’adressent à des personnes qui ont des compétences en informatique et nécessitent plusieurs semaines de formation
Voir points d’attention “RGPD” et “Accès aux données personnelles”

3.3-Et si je donne accès à ce type de plateforme qu'est-ce qu'on va y gagner ?

En synthèse : Côté employés, c’est donner un cadre et un espace de libertés aux collaborateurs pour développer une application par eux mêmes. C’est améliorer la collaboration avec la DSI qui elle limite l'apparition de “shadow IT” anarchiques. Côté DSI c'est améliorer son image, optimiser ses coûts de développement et ses ressources pour davantage se consacrer à des applications stratégiques.

Limiter le shadow IT : en faisant le choix d'outils No/Low-Code encadrés par la DSI on évite le shadow IT. Les éventuelles reprises en main des applications No/Low Code sont plus simples car cadrées en solution et techniquement.
Donner des espaces de libertés : Des collaborateurs une fois formés à ces outils ont accès à un espace de libertés pour faire / tester par eux-mêmes. Des frustrations internes disparaissent.
Dérisquer l’usage : Avant de se lancer dans des développements coûteux, on dé-risque l’usage de la solution à mettre en place en assemblant le plus possible des outils et briques développées en No/Low-Code permettant de rendre le service attendu sur un nombre réduit d’utilisateurs.
Faciliter la reprise par la DSI : Si l’application est un succès, elle peut être reprise par les équipes de la DSI - dans une technologie maîtrisée par les équipes et pour en assurer une scalabilité à coûts maîtrisés, avec une expression de besoin parfaitement cadrée - l’application développée en No/Low-Code faisant office de spécification détaillée.
Économiser les ressources IT : On économise ses ressources IT classiques internes pour libérer et laisser la DSI développer des applications plus stratégiques sur des technologies qu’elle maîtrise.
Améliorer l’image de la DSI : De telles collaborations améliorent l’image de la DSI. Cette dernière passe moins pour un acteur castrateur rempli de contraintes dont la roadmap trop chargée interdit le moindre développement de plus petites applications ou prototypes. Ces dernières pourtant nécessaires et utiles sont trop rarement considérées comme stratégiques.
Maîtriser les coûts : Les coûts de développements et d’exploitation sont globalement mieux maîtrisés soit parce que les profils utilisés sont moins chers que les profils développeurs/exploitants actuels dont les coûts et la rareté explosent, soit parce que les solutions No/Low-Code apportent des éléments clés en main à coûts et délais plus modiques et maîtrisés (déploiement, stockage, hébergement).

3.4-Attention, tout n'est pas rose : les points d'attention & recommandations

RGPD et Cloud Act

“Le Cloud Act, (Clarifying Lawful Overseas Use of Data Act), a vu le jour sous l’impulsion de Donald Trump, afin d’autoriser les autorités américaines à utiliser des données étrangères. Avec l’adoption du Cloud Act, les opérateurs numériques et les prestataires de service américains sont tenus dans l’obligation de divulguer les données personnelles de leurs utilisateurs, dès lors que les autorités américaines (police, justice et administration) le leur demandent. Cette divulgation se fait sans devoir en passer par les tribunaux et sans même que les utilisateurs concernés soient mis au courant. La particularité du Cloud Act résidant dans le fait que les informations personnelles doivent être transmises aux autorités américaines et ce même lorsqu’elles sont stockées en dehors du territoire national - par exemple en Europe. - Le Cloud Act, ratifié le 23 mars 2018, vient donc heurter de plein fouet le RGPD” (src: https://donnees-rgpd.fr/donnees-personnelles/cloud-act-anti-rgpd/).
1. “Face à cette ingérence juridique, les acteurs européens tentent de trouver des parades pour s’affranchir du Cloud Act, afin de garantir à leurs utilisateurs l’entière confidentialité de leurs données personnelles.” La solution la plus simple à ce jour étant de se tourner vers les sociétés européennes offrant des alternatives souveraines, c’est-à-dire des entreprises d’hébergement et de services implantées en France ou en Europe et qui respectent impérativement le droit français ou européen.” (src: https://donnees-rgpd.fr/donnees-personnelles/cloud-act-anti-rgpd/).
  1. Pas si simple pour les solutions No/Low-Code les plus avancées qui s’appuient sur les géants américains du Cloud.
2. Recommandations : rester dans le prototype et basculer sur des infrastructures souveraines ou internes le besoin fonctionnel une fois approuvé et re-développé en interne DSI. Ne stocker que les données utiles et nécessaires, si possible chiffrer les données avec une clé privée, purger les données dès que possible, limiter le stockage des données sensibles. Explorer les offres No-Code Européennes même si elles sont encore rares et limitées en termes de fonctionnalités. Notez que ce n’est pas le cas pour les plateformes Low-Code qui permettent des hébergements on-premise et autorisent donc de s’affranchir des hébergeurs américains.

Sécurité, accès et aux données personnelles : bien que les plateformes offrent de base des mécanismes de sécurité élevés, un coup d'œil par votre RSSI peut permettre de vous assurer que tout est ok pour identifier et protéger l’accès à des données personnelles par exemple. Chiffrer si possible les données pour vous apporter un peu plus de sérénité.
- Le chiffrement par la base de données : la base de données encrypte les données avant qu’elles soient persistées. Ce mécanisme est à la main de la solution de No-Code qui peut s’appuyer sur les fonctionnalités offertes par la base de données sous-jacente.
- Le chiffrement applicatif : l'application chiffre avant de donner à la base de données. Ce mécanisme est assez compliqué à faire en No-Code (il faudrait passer par un service tiers de chiffrement).

On évitera le stockage des données sensibles dans des infrastructures No/Low-Code de fournisseurs US (voir point RGPD et Cloud Act).

La réversibilité est coûteuse voire impossible : Partir sur du No/Low-Code c’est un choix produit tout comme un progiciel - utiliser des produits logiciel est quelque chose qui est commun dans les entreprises (SAP, Salesforce, Outlook, suite MS Office, mais aussi pour du développement : Dev sur les technologies MS (.net), move to cloud AWS et ses services managés, core banking pour les acteurs bancaires…). Ça peut bien se passer ou pas, la contractualisation et la relation avec l’éditeur est importante. Le marché est en ébullition, il y a donc beaucoup d’acteurs qui ne sont pas encore matures et qui essaient de prendre leur place. Pour mitiger les risques :
1. Contractualisation (Négociation des licences et du support sur le long terme, obtention des droits d’utilisation du produit en cas d’arrêt, gestion des montée de versions et des migrations
2. Gouvernance (arbitrage sur des projets qui auront une durée de vie plus courte)
3. Privilégier un éditeur avec un écosystème riche, répandu et ouvert pour pouvoir s’appuyer sur l’écosystème et limiter le risque qu’il soit arrêté sans repreneur
4. Architecture hybride de type API permettant de limiter l’étendue des développements en no/low code (par exemple API et données en spécifique, IHM et logique applicative en No/low code)
Monitoring des usages : administrez les applications pour monitorer leurs usages (et donc leurs coûts), afin de recenser les applications en cours, celles qui sont inactives et celles qui sont potentiellement en train de passer à l’échelle. Rappel : ces solutions ont des coûts qui peuvent devenir élevés dès lors que l’on passe à une échelle supérieure (ex. lors d’une augmentation du nombre d’utilisateurs authentifiés, ou des exécutions de tâches automatisées, …).
UX et conception : Si besoin, au moment de la conception des experts en UX (“User Experience”) aideront à désigner les applications en dé-risquant les principales hypothèses et ainsi éviteront de tomber à côté du besoin ‘profond’ des utilisateurs. Ils optimisent ainsi les ressources mises en jeu et évitent les investissements dans une ‘solution’ inutile.

4-Conclusion & take away

Il est impossible, aujourd'hui, d'avoir une approche exhaustive de tous les outils No/Low-Code tant le marché est en effervescence, cependant on peut déterminer ce pour quoi ils sont adaptés et ce pour quoi ils n'apportent pas de valeur.

Take away – (src : https://www.ohmyneon.com/)

Ainsi on peut schématiquement résumer les approches comme suit :

MVP / POC simple en No-Code :
- Complexité à implémenter : simple
- Prérequis : des employés formés à des outils No-Code sélectionnés
- Coûts d’investissement : quelques jours
MVP / POC / Application d’efficacité opérationnelle avec complexité fonctionnelle plus importante en Low-Code :
- Complexité à implémenter : plus importante que ce que permettrait nativement les outils No-Code
- Prérequis : des employés formés à des outils Low-Code sélectionnés + soutien par des experts externes sur les plateformes
- Coûts d'investissement : quelques mois + coûts récurrents des licences

Il faut par ailleurs garder à l’esprit que l’utilisation d’une plateforme de Low-Code fait changer d’ordre de grandeur par rapport au No-Code. Que ce soit dans les coûts de licences, les profils des modeleurs (développeurs en No-Code/Low-Code) ainsi que leur formation et le support nécessaire. Sur les gains, on peut dire que pour les collaborateurs, ces plateformes donnent un cadre et un espace de libertés aux collaborateurs pour développer une application par eux-mêmes. Elles permettent d’améliorer la collaboration avec la DSI qui de son côté limite l'apparition de “shadow IT” anarchiques. Côté DSI c'est aussi améliorer son image, optimiser ses coûts de développement et ses ressources pour davantage se consacrer à des applications stratégiques. En prérequis et pour faciliter la vie des employés, identifiez et sélectionnez quelques plateformes No-Code et/ou une en Low-Code, pensez à accélérer leur emboarding en prévoyant des guides, grilles d’analyse, une FAQ contextualisée à votre environnement, des quickstarts par plateforme voire une mailing liste communautaire. Enfin, formez ou autorisez les collaborateurs à se former à une ou plusieurs plateformes No/Low-Code que vous aurez mises à votre catalogue. Et enfin, sur le côté moins rose de ces solutions:

Partir sur du No/Low-Code c’est un choix produit tout comme un progiciel et la réversibilité est loin d'être évidente. Pour mitiger les risques, pensez à négocier l'engagement et à la c__ontractualisation__ avec l'éditeur surtout si vous pensez vous engager sur du long terme; gouverner et arbitrer en faveur de projets qui auront une durée de vie plus courte, privilégier un éditeur avec un écosystème riche, répandu et ouvert, enfin favoriser une a****rchitecture hybride de type API
En l’état actuel les plateformes No-Code (ce n’est pas le cas pour les plateformes Low-Code qui permettent des hébergements on-premise) présentent un inconvénient majeur car les plus avancées s’appuient sur les géants américains du Cloud…..qui sont RGPD incompatibles.

5-Rappel et pour aller plus loin

“Les fake news du LowCode” à la Duck Conf 2021

Articles

```
  1. [Le Low\-Code comment ça marche](https://blog.octo.com/le-low-code-comment-ca-marche/)
```

Duck Conf

  1. [Les fake news du LowCode](https://www.youtube.com/watch?v=sQZqyB-EZro)

Formations OCTO Academy

  1. [Développer une application sans savoir coder](https://www.octo.academy/formations/formation/79/developper-une-application-sans-savoir-coder/)

Inititaion aux outils No-Code

Guide autour de l’outillage No-Code

  1. [https://quels\-outils\-nocode\.fr/](https://quels-outils-nocode.fr/)

Ceci n'est pas un canard en caoutchouc jaune sur fond bleu.