Trois raisons qui expliquent pourquoi le battage médiatique autour du low-code est excessif
Je travaille dans l’industrie informatique depuis de nombreuses années et il est parfois difficile de ne pas se lasser de la médiatisation qui entoure les dernières tendances. Le low-code/no-code est l’une de ces tendances dont l’engouement qu’elle suscite peut empêcher de bien comprendre la véritable valeur de cette approche du développement d’applications.
Premièrement, nous sommes déjà passés par là avec différentes initiatives visant à faciliter le développement d’applications. Je me souviens du projet Microsoft Oslo de 2007 par exemple. Un jour, un monde où le besoin de coder est minimal, voire inexistant, pourrait bien arriver, mais franchement, si vous devez générer une couche de logique-métier, vous devez coder.
Deuxièmement, je serais surpris que de nombreuses entreprises disposant d’informations sensibles sur l’entreprise permettent à leurs employés d’accéder librement à ces outils. Ce n’est pas du tout possible chez Unit4. La grande majorité des outils low-code sont des services basés sur le cloud qui sont gérés par plusieurs fournisseurs différents, donc, cela m’étonnerait beaucoup que cela ne déclenche pas la sonnette d’alarme chez votre Chief Information Security Officer (CISO).
Troisièmement, ce que beaucoup de ces outils semblent offrir est une couche d’interface utilisateur au-dessus de vos applications existantes, laquelle ne vous donne pas accès aux données de base dans ces systèmes. Non seulement cela signifie que vous avez besoin de personnes ayant des connaissances en codage pour maintenir ces systèmes clés, mais cela signifie aussi que si vous souhaitez que l’interface utilisateur low-code interagisse avec vos données de base, vous devez savoir comment créer une logique-métier.
La vraie raison pour laquelle le low-code est important
Maintenant que j’ai exprimé ces inquiétudes, je vais avouer que le low-code a de la valeur. Chez Unit4, nous avons passé les dernières années à construire une architecture de microservices pour soutenir notre plateforme ERP de nouvelle génération, car nous avons compris la flexibilité que celle-ci peut apporter à nos clients qui veulent répondre rapidement à leurs propres clients et aux opportunités du marché. Cependant, ce sont nos outils et nous proposons un kit d’extension qui respecte certaines normes et politiques afin que toute nouvelle fonctionnalité ajoutée à notre environnement de base interagisse efficacement et sans perturbation. Je comprends donc parfaitement la valeur que peut offrir le low-code.
Il existe un facteur très réel et pratique en faveur de l’adoption du low-code, à savoir l’énorme pénurie de travailleurs informatiques qualifiés. Logiquement, si les modèles low-code vous permettent d’automatiser des éléments du développement d’applications, tout en économisant du temps et des ressources, l’argument coût-bénéfice est évident. Cela dit, je ne pense pas que le low-code répondra à une demande technique spécifique ou fournira des avantages techniques ; il résoudra plutôt un problème humain très réel.
Soyez discipliné
Si vous souhaitez que le low-code fonctionne, vous devez suivre les mêmes bonnes pratiques que celles attendues dans n’importe quelle autre forme de développement d’applications. Elles exigent le respect d’un processus discipliné et une bonne gouvernance. Cela signifie être strict sur la façon dont les outils interagissent avec votre environnement existant. Évidemment, ils doivent avoir accès aux systèmes de données dans le back-end, mais ils ne doivent pas y avoir accès librement, et ce, pour des raisons évidentes de sécurité.
Si vous craignez que le low-code n’encourage la prolifération des applications, vous devez être discipliné concernant les personnes autorisées à créer une instance et disposer des bons contrôles d’accès/niveaux. Les applications doivent être construites et gérées correctement à l’aide de normes spécifiques et doivent suivre un processus d’approbation et de contrôle qualité.
Du point de vue de la gouvernance, vous devez également vous assurer que vos développeurs low-code ne font pas tourner des instances qui entraînent le stockage des données en local : en plus d’augmenter les coûts de stockage, cela pourrait causer des problèmes en matière de protection des données sur le marché en question.
Le développement sans codage n’est encore qu’un mirage
Je suis Danois et les contes de fées, ça me connaît. Je ne dirais pas que le développement de no-code en est un, mais quiconque vous parle du potentiel de telles approches pourrait tout aussi facilement décrire un royaume lointain…
À mon avis, la raison pour laquelle des histoires telles que Hansel et Gretel ont si bien marché est qu’elles étaient aussi plutôt effrayantes. Loin de moi l’idée de suggérer que quiconque adopte une stratégie low-code/no-code devrait avoir peur, mais il faut se lancer en ouvrant grand les yeux.
En fin de compte, ne croyez pas tout le battage médiatique : le low-code est comme tout autre codage. Vous aurez toujours besoin d’une connaissance du codage pour pouvoir le mettre en œuvre correctement et il faudra de la discipline et une bonne gouvernance si l’on souhaite le mettre en œuvre correctement. Vos équipes informatiques et les personnes choisies dans les départements-métier pour implémenter ces modèles de développement d’applications devront être formées de manière à comprendre ce que l’on attend d’elles et du code qu’elles mettent en œuvre. Il ne constituera pas une panacée pour tous vos besoins en matière de développement d’applications, mais il pourrait contribuer à résoudre le problème bien réel posé par la pénurie de compétences.