Free cookie consent management tool by TermsFeed

mercredi 19 avril 2017

Le retour du développement sans code

Robot
Depuis presque aussi longtemps que j'ai débuté dans l'informatique, j'entends les promesses – jamais tenues – du développement sans code, accessible aux néophytes de la programmation logicielle. Après les vagues AGL, L4G et autres MDD, sa dernière incarnation se dénomme « low code ». Faut-il donc y croire, cette fois ?

Les raisons de l'engouement pour le renouvellement de cette tendance reprennent des arguments connus – désir d'autonomie, exaspération face aux délais et aux coûts des projets traditionnels, capacité de persuasion des sirènes éditeurs… – auxquels s'ajoutent désormais des préoccupations plus globales. En particulier, l'intrusion massive du logiciel au cœur de toutes les activités de l'entreprise induit des besoins de talents qu'il devient de plus en plus difficile de satisfaire dans un contexte de pénurie généralisée.

En parallèle, les conditions se sont faites plus favorables au développement d'applications en dehors du cadre standardisé de la DSI. Bien sûr, les outils spécialisés n'ont jamais cessé d'évoluer, notamment pour la création d'interfaces graphiques, web et mobiles. Mais, surtout, l'introduction d'API au sein des systèmes d'information – initialisée avec les plates-formes hébergées dans le cloud – ouvre (très) progressivement la voie à des approches véritablement intégrées avec les métiers de l'entreprise.

Il faut souligner, en outre, que les tenants du « low code » se sont passablement assagis par rapport à leurs prédécesseurs. Ainsi, il n'est plus vraiment question d'éliminer tout effort de programmation ni de cibler toutes sortes de logiciels. Au contraire, il est plus ou moins admis aujourd'hui que ce sont des solutions relativement simples – formulaires de saisie, applications mobiles basiques, prototypes… – qui peuvent être conçues et réalisées sans nécessiter le recours à des professionnels chevronnés… et débordés.

Tous les facteurs convergent ainsi vers l'émergence des « développeurs citoyens », ces employés qui, bien que ce ne soit ni leur métier ni leur mission, prennent leurs problèmes logiciels à bras-le-corps, apprenant par eux-mêmes à réaliser les outils dont ils ont besoin pour faciliter leur quotidien. Pour connaître les responsables informatiques des institutions financières, j'imagine que la plupart d'entre eux lèvent les bras au ciel en psalmodiant « pas de ça chez nous, pas de ça chez nous… ». Il faudra pourtant s'y faire.

Comme avec les autres tendances à la prise d'autonomie des utilisateurs (BYOD – « Bring Your Own Device » – et BYOA – « Bring Your Own Application »), toujours aussi conflictuelles dans la plupart des grands groupes, le mouvement est irréversible, du moins tant qu'aucune alternative n'est proposée. Or il est difficile d'imaginer comment les DSI, dont 70 à 80% des ressources sont consacrées à faire fonctionner l'existant et qui ont de plus en plus de difficultés à recruter, pourraient apporter une réponse.

Il ne faut pourtant pas idéaliser le phénomène des « développeurs citoyens » car il a également ses limites. Risques de sécurité, dérives éthiques, difficultés à assurer la maintenance et à supporter des évolutions, fragilité des applications… ne peuvent être écartés. Alors, plutôt que de faire l'autruche, en croyant que la vague peut être stoppée, les responsables doivent définir les politiques applicables, dont, entre autres, les périmètres de mise en œuvre acceptables et les contraintes essentielles à respecter, sans étouffer les initiatives qui soulageront utilement la pression actuelle sur les DSI.

Développement logiciel

1 commentaire:

  1. Bien d'accord avec toi Patrice... tant sur le constat, que sur l'analyse des lignes Maginot que certaines DSI mettent en oeuvre pour bloquer toute initiative venant d'un utilisateur "fou", persuadées qu'elles sont de pouvoir faire mieux... en oubliant de préciser que c'est généralement plus cher et moins rapide, mais elle oublie de le dire... sans compter celles qui ne comprennent pas la nécessité de disposer de véritables environnements de recettes et/ou d'homologation, considérant que c'est une perte de temps, d'argent, et, font tout pour limiter la production sur de tels environnements

    RépondreSupprimer

Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)