Low-code : le Cigref pose la question des coûts

Le développement low code et no code, d’abord une question de coûts ? Cet aspect occupe en tout cas une place importante dans la réflexion du Cigref.

Son dernier rapport sur le sujet en témoigne. Dès l’introduction. Le premier des enseignements cités est le suivant :

Les approches low code / no code sont de véritables opportunités, y compris pour la DSI elle-même : dans un contexte de contraintes financières, elles peuvent permettre de faire du développement à faible coût […]

Même constat au chapitre gouvernance. Premier objectif mentionné :

Contrôler les coûts, notamment à cause des modèles type freemium

Idem pour ce qui est des critères de sélection des plates-formes. Au premier rang, « le coût des licences et leur modèle ». Sur ce point, le Cigref explique :

La prédictibilité des coûts vis-à-vis des usagers visés n’est pas toujours aisée. Il faut de plus bien délimiter le périmètre des usages et s’interroger sur le choix de licence fait en fonction du nombre d’utilisateurs ou du nombre de développeurs […]

À l’image de l’introduction, le chapitre « Opportunités » s’ouvre ainsi :

Les approches low code / no code permettent de développer ou d’enrichir des plates-formes de développement à moindre coût dans un contexte de contraintes financières.

Concernant le contrôle des coûts, le Cigref fait remarquer que les applications développées en low-code / no-code « peuvent devenir très complexes voire critiques au fil du temps ». Et « in fine coûter plus cher qu’une application développée plus classiquement ».

De coûts, il est aussi question à propos des options dont la DSI dispose pour soutenir les métiers. Soit les accompagner sans se doter d’une entité dédiée à condition de bien cibler les populations, soit mettre à leur disposition un pool de développeurs… ce qui a un coût.

Réutiliser ses API

Quand opter pour du no-code plutôt que du low-code ? Le Cigref reprend l’analyse d’Octo Technology. Au prototypage et à l’automatisation des tâches bureautiques, il ajoute la création de deux types d’apps : communication et événementiel.

Que les utilisateurs-développeurs choisissent l’un ou l’autre, ils veilleront à s’en tenir à des applications de faible complexité qui ne concernent pas les domaines métiers critiques. Le Cigref leur recommande aussi, entre autres :

– D’éviter des fonctionnalités redondantes avec celles déjà présentes dans une application « régalienne »
– D’utiliser les API existantes pour alimenter les applications
– De partager des retours d’expérience, par exemple via une marketplace

Du côté des équipes IT, on s’assurera effectivement d’une réutilisation des API existantes. Et, s’il n’est pas possible d’en utiliser, on mettra en œuvre des contrôles d’accès, la configuration de l’application et la définition des rôles et responsabilités. Par ailleurs, on :

– Définira des zones sécurisées (identifier ce qui est hors du cadre des utilisateurs-développeurs)
– Aura des cas d’utilisation identifiés (conception de formulaires, apps de collecte de données…) ; les apps qui n’y entrent pas exigeront consultation de la DSI
– Respectera la classification des données imposée en interne

Le low-code ne dispense pas de documenter

De là à gagner du temps avec le no-code, le Cigref relativise. Certains DSI constatent que seule la phase de développement est réellement accélérée. On gagne peu de temps sur l’ensemble du process, à cause de la complexité plus ou moins grande à connecter les flux, selon l’environnement choisi.

Autre point de vigilance : les modèles low code / no code qui n’embarquent pas leur propre base de données. Cela nécessite d’exposer les données de l’entreprise et de mettre en place des API pour sécuriser les requêtes.

La notion de réversibilité est également prégnante : une fois mon offre no code / low code résiliée, comment puis-je continuer à utiliser mes applications ? Les réponses du Cigref sont au nombre de trois. Premièrement, exiger une documentation, au même niveau que celle des développements spécifiques. Deuxièmement, utiliser des frameworks standard. Troisièmement, opter pour des plates-formes open source.

Photo d’illustration générée par IA