Les cols blancs adorent l’idée d’outils « low-code ». Pour eux, moins de code c’est moins de travail, donc des projets plus rapides, une meilleure satisfaction, des budgets moindres, et finalement de plus gros bonus qui seront redistribués entre ces mêmes cols blancs. Mais de leur côté, les développeurs ne sont pas très friands de cette technologie. L’idée est alléchante, certes – qui ne voudrait pas moins travailler ? – mais les codeurs savent qu’entre la théorie et la pratique où les outils ne fonctionnent pas comme prévu au moment d’une échéance proche, il n’y a qu’un pas.

Les solutions low-code ont leur place. Les programmeurs savent que ces outils peuvent produire un process pouvant rechercher, trier, et jongler avec les données tabulaires. Mais ces professionnels craignent également de devoir jongler avec ce que ces outils ne maîtrisent pas. Et finalement devoir passer plus de temps à gérer des problèmes et trouver comment les contourner, qu’à écrire leur propre stack. Voici donc neuf raisons pour lesquelles les développeurs sont frustrés par les outils low-code.

Frustration n°1 : La maintenance peut être difficile

La partie la plus délicate dans l’utilisation d’une solution low-code intervient quelques années après l’intégration. L'ancien système est déployé et fonctionne bien, mais tout le monde a des demandes de corrections et d'améliorations. Et ces demandes ne sont jamais faciles à mettre en œuvre avec une architecture low-code. Avec le code source de la plateforme, il serait éventuellement possible de plonger dans ses méandres pour en reconstruire une partie, mais les développeurs n’y ont pas accès. Si les concepteurs avaient été conscient de ce besoin, peut-être auraient-il ouvert leur code. Mais ils ne l’ont pas fait et les programmeurs sont donc enfermés dans ces architectures.

Frustration n°2 : Tout le monde obtient la même chose

Toutes celles et tous ceux qui mangent dans un fast-food ne sont finalement jamais surpris de ce qu’elles et ils y trouvent. Le business modèle est basé sur l’offre d’un menu standard, dans des restaurants agencés de la même manière, pour un prix abordable. L’expérience est cohérente mais cela ne la rend pas plus fun. Le low-code donne la même sensation. Un bon développeur avec un peu d’expérience arrive souvent à identifier les outils sous-jacents de la plateforme en quelques clics. Quel que soit le nombre d’options de configurations, d’écrans d’accueil ou d’habillages CSS personnalisés, le mécanisme en arrière-plan est le même et ça se voit. Réconfortant pour quelqu’un qui n’aime pas le changement ; mais pas du tout surprenant et novateur pour un programmeur créatif.

Frustration n°3 : Une taille unique ne convient pas

Les fabricants de produits aiment des articles de taille uniforme parce que le pipeline n’en est que plus simple. Les clients ? Eux exècrent les tailles uniques et s’en plaignent régulièrement. Idem pour le low-code. Il n’y a tout simplement pas beaucoup de choses personnalisables, dont le code est modifiable, le professionnel est donc coincé avec ces modèles. A part bidouiller quelques choses de ressemblant, il n’est pas possible de répondre entièrement à des demandes de développement très précises.

Frustration n°4 : Parfois coder est plus simple que configurer

Les développeurs ont fait une erreur stratégique en minimisant le travail de configuration des logiciels. Peut-être parce que les cols blancs comparent toujours le coût de création d’un nouveau code avec le prix d’achat d’un produit standardisé ? Dans tous les cas, les développeurs aiment prétendre que changer les paramètres de configurations d’une plateforme ou d’une application n’est pas un problème.

Les plateformes low-code prétendent la même chose : « vous ne codez pas quand vous spécifiez les algorithmes, connectez une base de données ou remplissez des paramètres. » Ce n’est que de la configuration et tout le monde sait que la configuration peut se faire depuis son smartphone dans un bar à l’happy hour. Mais en réalité, il faut parfois manipuler ces boutons pendant des jours jusqu’à ce qu’ils fassent ce qu’ils sont censés faire. Il ne faut pas considérer cela comme du travail, même si ces tâches prennent plus de temps que le temps de travail de développement…

Frustration n°5 : Avancer à l’aveugle

Au fil du temps, les développeurs ont créé des outils de débogage élaborés pour faciliter l’arrêt d’un logiciel à des endroits arbitraires et permettre d’examiner en profondeur toutes les structures de données et l’état algorithmique pour savoir exactement d’où vient le problème. Les outils low-code cachent cela exprès en pensant faire une faveur aux développeurs. Dans le cas où ces outils fonctionnent de la manière escomptée, tout est beau dans le plus merveilleux des mondes. Mais quand les choses tournent mal, les programmeurs se retrouvent coincés sans aucun moyen de trouver d’où vient le problème. Ils avancent à l’aveugle, sans outils adéquats pour avoir un aperçu de la situation.

Frustration n°6 : Les tâches les plus simples deviennent des casse-têtes

Quiconque a écrit un logiciel sait que la moitié du travail consiste à écrit le petit bout de code qui viendra maintenir la circulation des données, tout en filtrant les problèmes. Parfois les dates sont au format ISO 8601, parfois selon des préférences locales. Parfois, les nombres sont des entiers alors qu’ils devraient être des chaînes de caractère, et vice versa.

Les outils low-code proposent des filtres ou des commutateurs pour assumer ces tâches et souvent ils sont suffisants. Si non, pas de chance ! Certains fournisseurs de produits low-code ont essayer de laisser les développeurs insérer des blocs de code arbitraires par endroits. Mais il suffit que quelqu’un trouve le moyen de les utiliser à mauvais escient pour qu’une faille massive de sécurité se produise. Drupal a, par exemple, supprimé cette option d’inclusion de bits de PHP par endroits pour combler une faille de sécurité potentielle et augmenter les performances du cache.

Frustration n°7 : Le low-code n’est souvent pas efficace

La promesse de ces outils est de savoir ce dont le développeur a besoin et de l’offrir comme par magie. Le coût de cette lecture mentale, cependant, est une épaisse pile de code qui traite toutes les configurations étranges et les courbes bizarres qui pourraient se présenter. Si vous avez écrit le code, vous savez peut-être que votre entreprise n'a stocké ses données que dans des fichiers CSV. L'équipe au sein du QG de la plateforme low-code, cependant, doit planifier toutes les éventualités et cela signifie travailler avec JSON, YAML, et XML, les deux versions 1.0 et 1.1. Il existe des douzaines de formats et l'équipe de vente de l’entreprise low-code veut s'assurer que son outil peut les traiter tous. Il s'agit de cocher les cases de la matrice de caractéristiques.

Le résultat est une pièce d'ingénierie impressionnante, tout autant que le navire de guerre cuirassé du XXe siècle Dreadnought. Le résultat est à l’épreuve des balles mais tout est plus lent et moins efficace. Si vos délais ne sont pas trop serrés et que votre ensemble de données pas trop volumineux, vous pouvez le masquer en injectant plus de puissance de calcul dans la pile. Mais finalement, ce sera la facture qui devrait être plus salée.

Frustration n°8 : Recherche d’une expérience

La plupart des principales plateformes open source sont construites dans des langages populaires qui sont enseignés dans les écoles. Il existe un vaste écosystème de talents qui peuvent démonter et reconstruire des piles construites dans les principaux langages comme Java, JavaScript, Python ou PHP. Le low-code n'est généralement pas enseigné parce que, eh bien, on n’est pas censé avoir besoin d'instruction dans ce domaine. Les passionnés souligneront que les outils sont souvent écrits dans des langages communs, mais ce n'est pas le réel défi des développeurs. Le challenge réside dans la structure supplémentaire intégrée au framework low-code. C'est ce pour quoi les clients paient et c'est aussi sur quoi les équipes doivent passer du temps à apprendre si elles veulent réviser ou étendre la plateforme.

Frustration n°9 : Être enfermé

Parfois, le démarrage d'une de ces plateformes donne l'impression de rejoindre le reste du monde. C'est facile d’y revenir mais difficile de le quitter. Le prix à payer pour faire moins de travail et s’appuyer sur les géants est de devenir redevable à ces géants. S’ils bougent, on bouge avec eux. S’ils s'arrêtent ou s'effondrent, les ennuis ne seront pas loin.