Je suis sceptique à l’égard du low-code

• Je suis sceptique à l’égard du low-code
• En travaillant dans le conseil logiciel, je rencontre souvent des clients attirés par les promesses publicitaires du low-code : des temps de développement rapides et de faibles coûts de maintenance
• Il existe plusieurs raisons pour lesquelles les clients ne sont pas satisfaits

Limites des fonctionnalités sur mesure

• Les solutions low-code couvrent environ 80 % des besoins d’une entreprise, mais les 20 % restants ne peuvent pas être résolus avec les fonctionnalités de base
• Les marketeurs des outils low-code affirment que les 20 % restants se résolvent facilement, mais en réalité cela nécessite une personnalisation importante, et c’est parfois impossible
• L’entreprise doit choisir si les fonctionnalités de base de l’outil sont suffisamment proches de ses besoins, ou si elle va tenter de bricoler l’outil pour l’adapter exactement à son cas d’usage

Limites du vivier de développeurs

• Les entreprises essaient parfois de bricoler un outil low-code pour couvrir 100 % de leurs besoins
• Résultat : elles écrivent beaucoup de code personnalisé dans un outil spécifique ou dans un langage propriétaire, que très peu de développeurs sont capables de comprendre
• L’entreprise doit alors trouver un mainteneur très spécialisé sur cet outil, au lieu de recruter dans le vaste vivier de développeurs de langages open source largement utilisés

Problèmes liés aux mises à niveau de la plateforme

• Lorsqu’on met à niveau un logiciel, il est difficile d’éviter que les intégrations associées ne cassent pas
• Les outils low-code doivent gérer du code arbitraire pour des cas d’usage pour lesquels ils n’ont pas été conçus
• Cela devrait pouvoir être géré via des contrats d’API stricts, mais en pratique on voit souvent du code personnalisé faire toutes sortes de bidouillages internes

Chaos dans la structure de la base de données

• On voit des entreprises utiliser des outils low-code pour des processus où une analyse fine est indispensable
• Pourtant, lorsqu’on regarde le modèle de données sous-jacent, il devient incompréhensible : que signifie user_attribute_47 ? Si l’on déplace un champ de la page 1 à la page 2 de l’application, les données se retrouvent dans un champ séparé ?

Avis de GN⁺

• Le low-code est un outil prometteur pour accélérer le développement et réduire les coûts de maintenance, mais dans la pratique, des problèmes inattendus peuvent survenir.
• En particulier, lorsque des fonctionnalités sur mesure sont nécessaires ou que l’on dépend d’un langage de développement propre à un outil low-code donné, le vivier de développeurs se réduit et la maintenance devient plus difficile.
• Les mises à niveau des outils low-code et la complexité de la structure de la base de données sont des points essentiels à prendre en compte dans la gestion des projets à long terme.
• Cet article offre un éclairage intéressant en soulignant les points de vigilance liés à l’usage des outils low-code et en recommandant une évaluation prudente des cas d’usage adaptés.

[ats62]

Je pense que jusqu’à présent, le concept du no-code ne s’applique que de manière limitée dans certains domaines.

Si un service bien conçu utilisant des LLM apparaît, j’ai le sentiment qu’il faudrait d’abord que la tendance ? le courant ? l’évolution ? enfin, bref, que le concept même du no-code change.

[quack337]

Je connais un cas, il y a une dizaine d’années, où MS Access a été utilisé de manière utile.

Dans le système d’information de l’organisation, il y avait une base de données relativement bien conçue et implémentée sur MS Sql Server,
et les opérations OLTP courantes étaient elles aussi relativement bien mises en œuvre.

Mais le mécontentement s’accumulait face à la réponse lente et peu proactive du service informatique aux demandes inhabituelles de consultation de données et d’impression de rapports.

Un employé du service métier, qui maîtrisait bien MS Excel et Access, a montré qu’en important dans Access les données Excel téléchargées depuis le système d’information, il était possible de mettre en place en seulement quelques heures, sans codage, les fonctions nécessaires de consultation de données et d’impression de rapports.

[quack337]

Le service métier a demandé à pouvoir se connecter directement à la base de données depuis Access, tandis que l’équipe IT s’est opposée à l’exposition de la base du système d’information sur un réseau externe. Cependant, comme la demande du métier était forte, une base distincte ne contenant qu’un miroir d’une partie des données a été créée et rendue accessible.

Les employés qui maîtrisaient bien les fonctionnalités de données d’Excel ont commencé à utiliser Access dans leur travail après seulement quelques jours de formation.

[tequila]

Je me reconnais dans cet article. À titre personnel,
quand on utilise une syntaxe spécifique -> il faut une courbe d’apprentissage et la maintenance devient plus difficile
quand l’UI ne fait que remplacer simplement le code -> dans bien des cas, coder directement est tout simplement plus pratique
quand cela devient un outil totalement no-code -> il y a beaucoup de contraintes, et cela pousse les utilisateurs à bidouiller. La fréquence des usages non prévus augmente fortement
Résultat : cela devient un outil qui ne satisfait personne.
L’écart entre la conception, le développement et les utilisateurs est trop grand, donc c’est un domaine bien plus difficile à réussir qu’on ne l’imagine.

[GN⁺]

Avis sur Hacker News

• Divers points de vue sur le low-code

  • Point de vue d’un développeur de plateformes low-code

    Le low-code est facile à vendre. La stratégie consiste à faire porter le problème sur les départements IT et à exploiter les frustrations existantes. Les démos montrent des tâches simples exécutées rapidement. Mais il vaut mieux ne pas intégrer la logique métier centrale dans le low-code. On part du principe que les tâches complexes seront déportées vers des systèmes spécialisés. C’est utile, dans les grandes entreprises, pour des équipes qui ont des connaissances techniques mais peu d’autorité côté IT. Le low-code résout beaucoup de problèmes avec des outils simples, mais passe mal à l’échelle et doit fonctionner avec un système central robuste.

  • Point de vue d’un SRE (ingénieur en fiabilité des sites)

    Sceptique vis-à-vis du low-code. La gestion du code source est insuffisante et la documentation est médiocre. Il faut beaucoup de code personnalisé, mais avec peu de réutilisabilité. Exigences de runtime propriétaire, supervision difficile. En pratique, il n’a jamais vu des ingénieurs faire le travail pendant que des non-ingénieurs utilisent réellement le système. Des outils comme Looker peuvent s’intégrer au code source, mais restent tout de même utilisés par des ingénieurs. Cela compresse la complexité, mais il préfère des plateformes qu’on peut personnaliser et étendre selon les besoins.

  • Point de vue sur la plateforme low-code de Microsoft

    Intérêt initial pour la plateforme low-code de MS, mais elle semble être un empilement complexe construit au-dessus de O365 et Azure. L’interface utilisateur est médiocre et, à long terme, les pertes dues aux problèmes d’utilisabilité pourraient dépasser les économies de coûts.

  • Expérience business de migration de solutions base de données/formulaires MS-Access

    Création d’une activité consistant à transformer des solutions MS-Access conçues par des non-développeurs/utilisateurs finaux sans passer par le département IT en véritables applications client/serveur .net. Les solutions low-code sont utiles pour résoudre certains problèmes ou faire fonctionner un POC, mais elles peuvent poser problème quand il faut passer à l’échelle ou s’adapter.

  • Point de vue d’un développeur du constructeur de sites web SQLPage

    Les solutions low-code devraient offrir une porte de sortie pour interagir avec des API externes « high-code ». SQLPage fournit cela via sqlpage.exec. Les mises à niveau des plateformes low-code peuvent casser les implémentations personnalisées. La plupart des outils low-code prennent les données en otage, mais SQLPage ajoute une couche au-dessus d’une base de données que l’utilisateur garde entièrement sous son contrôle.

  • Avis opposé aux outils low-code de niveau entreprise

    Opposition aux outils low-code utilisés par les grandes entreprises. Les grandes entreprises devraient pouvoir assumer une équipe de développement correcte, de la planification et de l’organisation. Ce n’est pas le code qui génère des coûts, mais de mauvais développeurs utilisant de mauvais outils pour prendre de mauvaises décisions.

  • Point de vue sur le low-code et les couches d’abstraction

    Le « low-code » réduit la surface du code avec laquelle on peut interagir directement, mais en réalité une grande quantité de code reste cachée. Les couches d’abstraction sont puissantes quand elles correspondent bien à leur objectif, mais peuvent causer des problèmes lorsqu’elles fuient ou sont mal adaptées. En général, le low-code abstrait du code conçu pour des usages précis, mais il exige malgré tout une réelle expérience du domaine.

  • Expérience de création d’un MVP avec Bubble/Airtable

    Des devis avaient été demandés à une équipe ukrainienne pour construire un MVP, mais un stagiaire a été recruté et le produit a été réalisé avec Bubble/Airtable en deux mois, puis des clients payants ont été acquis en moins de six mois. Pendant près de deux ans, aucune raison n’a été trouvée de migrer vers une stack plus traditionnelle.

  • Histoire d’horreur autour du développement d’un cursus de formation low-code

    Une entreprise importante a utilisé un package logiciel low-code de création de parcours de formation pour développer des cours internes destinés aux équipes marketing et commerciales. Quelques années plus tard, il a fallu mettre les cours à jour, mais le logiciel utilisé pour le développement ainsi que les outils permettant d’effectuer ce travail n’étaient plus disponibles, ce qui a créé un problème.

  • Question sur la possibilité de versionner des implémentations low-code

    Questionnement sur la possibilité de placer des implémentations low-code sous gestion de versions, d’identifier la cause d’un problème lorsqu’il survient et de revenir à un commit précis avec des outils gratuits. Dans la plupart des cas, ces fonctionnalités n’existent pas, ce qui rend ces solutions inadaptées à un usage sérieux.