DE BELLES PROMESSES EN PERSPECTIVE.
On entend parler de plus en plus de l’avènement du NoCode et LowCode, permettant pour tout un chacun de se passer des compétences d’une agence web pour créer une application, un site ou tout autre objet numérique. Mais qu’en est-il vraiment ?
NO CODE
Comme son nom l’indique, le NoCode permet sans connaître une ligne de code de pouvoir réaliser à partir d’une interface graphique un formulaire, un chatbot, un site, une application, etc. En soi, le principe est simple, et la prise en main rapide. Cependant, pour les non-initiés ou réfractaires à l’outil informatique, des micros ateliers dynamiques d’une demi-journée existent.
Simple, car une fois que vous avez choisi votre plateforme, vous pouvez commencer directement à mettre vos éléments en place par simple glisser-déposer à partir d’une bibliothèque prédéfinie. Relier les éléments entre eux, gérer les interactions, modifier les couleurs, les formes et toutes autres actions minimales sur un élément.
LOW CODE
Le LowCode fonctionne de la même manière que le NoCode, tout aussi simple, interface graphique, glisser-déposer, mais offre au développeur dans un espace bridé la possibilité d’apporter environ 10% de code. Si le code doit être plus important, nous sortons de la logique de LowCode.
Néanmoins, le LowCode implique un minimum d’expertise et de construire une logique métier, mais pas d’inquiétude, comme pour le NoCode des ateliers d’initiation existent.
ANOTHER BRICK IN THE WHOLE
Toutes les plateformes existantes aujourd’hui proposent des briques et briques métiers (commerçant, RH, affairiste, architecte, etc.) et c’est là que ça complique, car même si ces briques sont pléthoriques, toutes les spécificités métiers ne sont pas encore développées. Pire, car même si vous tombez pile-poil dans un secteur métier présent, elles ne prennent pas en compte les caractéristiques propres à chacun. Si la personnalisation de votre App est rendue possible, l’architecture quant à elle reste rigide, dû au canevas définis par la plateforme et les coûts explosent dès lors que vous demandez à modifier la structure ou fonctionnalités supplémentaires. De plus, ils sont difficilement quantifiables en amont.
LOW CODE MAIS PAS LOW TECH !
C’est un point intéressant pour tout un chacun qui s’intéresse à l’éco-conception.
Le fait de rendre une techno plus accessible, moins gourmande en production ou permettant l’efficacité des ressources mises en place, favorise bien entendu sa diffusion. À ce stade, on se dit chouette, moins de temps, plus d’efficacité, moins d’impact.
Oui……….. mais Non.
C’est tout le problème de la surconsommation d’une techno qui devient gourmande de fait. C’est le fameux effet rebond ou paradoxe de Jevons. Pas tout jeune ce paradoxe, ça date de 1865.
Passons et revenons au code. Et oui forcément, pour générer des applications, sites en NoCode ou LowCode, il y a du code. L’invisibilité de la complexité technique mise en place par le NoCode/LowCode pour faciliter certaines tâches, impacte aussi l’environnement et le social.
Dans le rapport du Dimensional Research pour Sourcegraph*, 9 développeurs sur 10 considèrent que le volume de code a considérablement augmenté ces 10 dernières années et 51% d’entre eux considèrent que ce volume a été multiplié par 100.
Ils sont également 9 sur 10 à reconnaître des pressions dans la fréquence de livraison applicative. Et pour 57% et 51% d’entre eux, cela impacte le haut niveau de qualité et évidemment la sécurité.
Alors oui, ces plateformes se targuent de réduire les difficultés et temps de mise en œuvre de projets, mais à quel prix. Le volume est certainement la plus grande problématique à gérer.
Pour mieux comprendre ce qui guette ces plateformes, reprenons le principe des « 4 V » qui définit ce qu’est le BigCode selon Zdnet :
- Volume : « il y a eu une augmentation exponentielle du nombre de codes créés ».
- Variété : « la complexité des langages, des outils et des processus utilisés pour la livraison des logiciels continue de se multiplier. »
- Vélocité : « l’accélération des cycles de livraison signifie que le code change plus vite que jamais, et est livré pratiquement tous les jours. »
- Valeur : « la refonte des modèles et des pratiques commerciales par le biais de logiciels de haute qualité a considérablement augmenté la valeur du code au sein de l’entreprise. »
Sans compter que ces technos NoCode/LowCode sont basées sur du cloud. À la base moins énergivore et polluante. (petit UP sur le paradoxe de Jevons)
Le cloud, c’est quand même l’agrégation de milliers de datacenter représentant 15%** des émissions GES liées au numérique, et la tendance est à la hausse. Certes, c’est beaucoup moins que la fabrication du matériel informatique (smartphone, ordinateur, serveur,…) qui représente 50% à 75% de l’empreinte carbone du numérique.
Rappelons aussi que le Cloud grand public est dominé par les GAM (Google 9%, Amazon 40% et Microsoft 19%) qui ne sont pas des modèles dès plus vertueux.
« Lorsque la mémoire était comptée, les développeurs informatiques avaient l’habitude d’écrire du code synthétique et efficace »
Prenons un exemple pour souligner les propos ci-dessus d’Anne-Cécile Orgerie chercheuse en informatique au CNRS pour le très bel article du siècle digitale Cloud Pollution.
Nous l’avons vu un peu plus haut, le NoCode/LowCode est basé sur des briques de base et des briques métiers. Les éditeurs essayant de remplir à max ce fourre-tout pour capter le maximum d’utilisateurs. De fait, ces plateformes ne prennent pas en compte vos contraintes. Elles génèrent donc des données mal dimensionnées ou dont tout simplement, vous n’avez pas besoin, alourdissant le code, les requêtes serveurs et provoquant une surconsommation d’énergie inutile.
Pour l’utilisateur lambda, c’est une nébuleuse. En voulant gagner en rapidité de mise en place, l’entreprise ayant recours au NoCode et LowCode risque également de compromettre sa stratégie green.
À QUI PROFITE LE CODE
Concernant les données utilisées sur ces plateformes, les entreprises en reste propriétaires.
La problématique des données réside dans le contrat établit avec ces plateformes, comme le souligne le ThinkTank l’Institut Rousseau** :
« en cas de panne système, en cas de litige ou de dysfonctionnement : qui est responsable de quoi ? En cas de panne, quelles sont les causes incluses et les incidents exclus dans le contrat d’accord de niveau de service ? Le taux de disponibilité de serveur annoncé concerne-t-il l’ensemble des services ou des modules précis ? Quelles garanties sur la localisation des datacenters ? Comment sont répliquées les applications par l’éditeur, etc. »
En parallèle, la mise en place il y a quelques années du RGPD pose inévitablement la problématique des données personnelles sur ces plateformes. Le cloisonnement pour une entreprise des données sensibles devient un enjeu crucial pour les DSI ou les personnes en charge de ce volet.
Un autre point plus qu’important, c’est l’interopérabilité.
Aujourd’hui, chaque plateforme produit un code propriétaire. Ce qui est actuellement un argument commercial serait en effet une problématique si vous deviez changer de plateforme pour x raisons. Y compris si celle-ci ferme ses portes.
À ce jour, vous ne le pouvez pas, aucune passerelle n’existe entre ces plateformes concurrentes.
Au mieux, sur certaines d’entre elles, vous pourrez récupérer vos données, mais dans tous les cas, vous serez obligés de vous re-familiariser avec la nouvelle plateforme et de reconstruire votre projet.
Là aussi, vous êtes dépendant de l’éditeur de la plateforme.
Mais la dépendance ne s’arrête pas là, vous n’aurez pas le droit de cité sur les mises à jour des briques ni sur l’évolution de leur politique de confidentialité ni sur l’évolution des prix.
Prenons un exemple concret avec l’appMaker*** de Google qui a fermé sa plateforme, ce n’est pas vieux, cela date de janvier 2021. Google en a informé ses utilisateurs et bien communiqué par la suite sur leur nouvel outil qu’il venait de racheter AppSheet. Seulement, aucun client appMaker n’a pu migrer sur une autre plateforme. Google leur notifiant simplement la procédure des services prenant en charge les bases de données CloudSQL. Pas top quand ça vous tombe dessus.
Alors oui, le principe de NoCode/LowCode est génial, innovant, pratique, intéressant pour s’acheter une présence rapide sur le web, une automatisation de tâches simples (identification, validation de formulaire, etc.) ou créer des prototypages pour générer de l’adhésion par exemple. À condition de ne pas se focaliser sur les questions éthiques, sociétales et environnementales de ce type de plateformes.
Mais si vous voulez déployer des projets complexes, éthiques, éco-conçus, fonctionnels ou sécurisés, vous pouvez passer votre chemin, ce n’est pas pour demain.
D’autres alternatives existent sans passer pour autant et obligatoirement par un codage total de votre projet digital. Le plus souvent en open source, ce qui vous permet d’en rester propriétaire, de le faire évoluer par qui bon vous semble et surtout de ne pas perdre d’énergie à disséquer les dépendances auxquelles vous obligent les plateformes NoCode/LowCode actuelles.
VOIR LOIN
La réflexion autour du choix de la plateforme doit tenir compte des évolutions et de l’interopérabilité de cette dernière. Ne pas se focaliser uniquement sur l’outil est fondamental.
Le NoCode venant remplacer le développement construit et réfléchi, n’est pas pour demain.
Un projet quel qu’il soit doit s’inscrire dans une approche contextualisée et systémique.
source: *Silicon, ** 2020 Institut Rousseau, *** Silicon, Le journal de l’informatique