Depuis quelques années, nous ne pouvons que constater le retour en force du low-code dans l’écosystème des solutions de développement d’applications : SalesForce, Outsystems, Microsoft, Mendix, Oracle... nouveaux acteurs et acteurs historiques proposent de plus en plus de plateformes de low-code. “Retour ?” me direz-vous. “Pourtant le terme low-code ne date que de 2014 !”. Vous auriez raison. C’est bien Forrester qui utilise dans une de ses études pour la première fois le terme de low-code en 2014. Pourtant, le concept de création d’applications avec peu ou pas de lignes de code existe depuis bien plus longtemps : Oracle Forms, MS Access, Delphi, Excel ... furent autant de solutions que l’on peut qualifier de Low-code et qui firent partie des solutions utilisées pour développer des briques d’un SI. Mais qu’en est-il aujourd’hui ? Les éditeurs de logiciels de low-code promettent qu’avec leurs solutions il n’est plus nécessaire de faire du développement sur mesure en s’appuyant sur “les ténors d’autrefois” que sont Java, .Net, node… Tremblez craftsmen de tout bord ! Plus rapides, plus forts, en un mot les meilleurs, quelle place les solutions de low-code doivent-elles réellement prendre dans un SI ? Après une présentation des avantages et inconvénients du low-code, je proposerai une place à ce dernier dans la réalisation de la mission des DSI : accélérer la création de valeur pour l’entreprise.
Les cas d’usage du low-code
Le low-code fait référence à l’utilisation d’une plateforme où, soit par drag and drop, soit au travers d’un nombre limité de lignes de code, il est possible de créer une application. Forrester utilise ce terme pour désigner les progiciels ou SaaS permettant de faire rapidement et simplement des applications. Ce sont d’ailleurs les qualités mises en avant par les éditeurs de telles solutions, qualités exprimées sous la forme de ces quatre principaux engagements du low-code :
- Être efficace dans la création d’une application en proposant une interface simple et intuitive avec un nombre de composants limités mais qui correspondent à la majorité des besoins,
- Faciliter les changements en permettant de créer ou de modifier des applications correspondant à de nouveaux besoins et usages sans passer par un service tiers de développement,
- Augmenter la productivité en évitant des cycles de développement centralisés autour des capacités de production de la DSI ou de sous-traitants,
- Et finalement, en compilant les deux avantages précédents, diminuer les coûts de création d’une application.
Pour utiliser un vocabulaire plus orienté création de valeur, le low-code permet d’insuffler de la flexibilité dans les cycles de développement grâce à sa simplicité d’utilisation et la vitesse de réalisation d’applications. Chaque service de l’entreprise, chaque employé, se retrouve alors autonome dans l’expérimentation de ses nouveaux besoins fonctionnels, de leur collecte à l’évaluation de leur pertinence.
Outre sa capacité à rendre accessible la création d’application à une population non-initiée, les citizen developers, ou aux TPE/PME, le low-code, sous contrôle de la DSI et de la SSI, peut être utilisé comme outil de régulation du Shadow IT (le Shadow IT est un terme fréquemment utilisé pour désigner des systèmes d'information et de communication réalisés et mis en œuvre au sein d'organisations sans approbation de la DSI - wikipedia).
La création d’applications sans passer par une DSI, et sans sa validation, existe depuis longtemps. La pratique du Shadow IT est souvent l’expression de la frustration amenée par de trop grandes contraintes ou un trop grand délai entre l’expression d’un besoin et sa réalisation par une DSI. Cette frustration amène à trouver une solution de contournement qui ne prend évidemment pas en compte la mission d’harmonisation du patrimoine applicatif de la DSI, ni la mission de contrôle et de sécurisation du SI de la SSI. Cependant, il ne faut pas privilégier la mission de la DSI et de la SSI au détriment de l’innovation business.
“Il est indispensable de prendre en compte les besoins des métiers et de leur permettre de rester agiles. Les utilisateurs se servent aujourd’hui d’une myriade de services, le plus souvent gratuits, sans en référer à la DSI… au SSI” - « Rapport Shadow IT France 2017 »
On touche donc ici à une autre utilisation du low-code, fournir aux citizen developers et aux métiers, en même temps que la capacité de faire leurs applications, un cadre, une gouvernance qui permet à la DSI de reprendre le contrôle technique des développements et de s’assurer du bon usage des outils et des pratiques de sécurité et ainsi permettre l’exploration contrôlée et sécurisée de nouveaux territoires business.
Le revers de la médaille
Cependant, les plateformes de low-code ne sont pas exemptes de défauts, et aussi utiles soient-elles pour contrôler la prolifération du Shadow IT et pour favoriser l’innovation business, elles viennent avec des contraintes et surtout, des cas d’usages pour lesquelles elles ne sont pas du tout faites, n’en déplaise aux éditeurs de ces solutions…
Tout d’abord, adressons le sujet de l’enfermement dans la plateforme, le vendor lock-in. La peur d’être locked-in, la peur d’être complètement dépendant de la plateforme qu’on utilise au point que le fait d’en sortir coûte une fortune, est sûrement l’argument le plus utilisé par les détracteurs du cloud. Le propos ici n’est pas de savoir si c’est à bon escient ou non, mais plutôt de dire que le lock-in existe aussi pour le low-code et que son importance, le coût de sortie de la plateforme, doit être étudié et doit rentrer dans le calcul du retour sur investissement de son utilisation. Il faut souligner aussi que les plateformes de low-code ont tendance à se spécialiser dans des domaines métiers ou techniques pour devenir de plus en plus performantes et adaptées aux besoins de leurs utilisateurs. La conséquence sera la multiplication des plateformes et, logiquement, l’augmentation de l’adhérence du SI à des acteurs externes.
Deuxième effet de l’enfermement dans une plateforme, la gestion des compétences de personnalisation. Si développer une application autonome du SI est facilitée par le low-code, créer une application, qui au contraire interagit avec celui-ci, nécessite la création d’adapters ou de composants custom. Les compétences nécessaires à ces développements sont rares sur le marché. Se pose alors la question de choisir entre dédier des membres de la DSI, une fois formés, à ce type d’activités, renforçant le lock-in, ou trouver un sous-traitant spécialisé, créant une dépendance supplémentaire à un acteur dont on ne contrôle ni la disponibilité, ni le coût.
Le dernier point d’attention à avoir, si la décision est prise de réaliser de tels composants spécifiques, c’est évidemment la dépendance à une version donnée de la plateforme. Souvent un développement spécifique va faire appel à une version donnée des API de la plateforme. Pour pouvoir profiter des montées de version de la plateforme au rythme proposé par les éditeurs, il faudra alors s’assurer de la compatibilité des extensions créées spécifiquement. Cela pourrait impliquer une réécriture complète ou partielle, engendrant des coûts supplémentaires, qui, si elle n’est pas faite, obligera à rester sur des versions de plateformes compatibles et rapidement obsolètes. Voire pire, cette situation pourrait figer une partie du SI qui n'évoluera plus afin de préserver les passerelles avec le low-code.
Du low-code dans le SI ?
Maintenant que les principaux avantages et inconvénients ont été abordés, demandons-nous si le low-code peut transcender ses limites et déterminons quelle position il peut avoir dans un SI. Je n’ai volontairement pas parlé de quatre limitations majeures des applications low-code dans le paragraphe précédent afin de les aborder ici :
- elles ne permettent pas d’avoir un code optimisé et performant avec de grands volumes d’information,
- elles ne permettent pas d’implémenter nativement des cas métiers complexes,
- elles ne sont pas faites pour supporter de grands systèmes complexes et
- elles ne permettent pas de s’intégrer facilement dans une stratégie de déploiements automatisés déjà en place dans une entreprise.
Ces quatre arguments, adossés aux limitations précédentes, suffisent à disqualifier l’utilisation du low-code dans le cadre d’applications stratégiques d’une entreprise, appelé domaine principal en DDD (ou core domain). Un domaine principal est ce qui rend une organisation, une entreprise, spéciale et différente des autres organisations. Le domaine principal est si important qu'il doit bénéficier de la plus grande qualité, de la meilleure maîtrise des risques, du développement à la production. On n’est clairement pas dans le cas d’usage du low-code ici : mettre en risque la pérennité et la stabilité des applications supports à la croissance d’une entreprise est un pari bien trop dangereux au vu des gains de productivité amenés par le low-code.
Cette conclusion est presque une évidence et on commence déjà à voir des sociétés ayant fait le pari du tout low-code faire marche arrière et bannir ces solutions de la liste des outils supportés par la DSI. Je trouve cette démarche trop excessive. Autant ne pas utiliser le low-code pour développer leur domaine principal est logique, autant se priver de cet outil dans le cadre de l’exploratoire métier ou dans le cadre de l’accélération de la création de sous-domaines serait vraiment dommage. Un sous-domaine de soutien (support subdomain) est un sous-domaine nécessaire à la réussite de l'organisation, mais il n'entre pas dans la catégorie des domaines principaux. Un sous-domaine générique (generic subdomain) est un sous-domaine qui ne contient rien de spécial pour l'organisation, mais qui est toujours nécessaire pour que la solution globale fonctionne. Généralement, les sous-domaines génériques sont constitués de logiciels/progiciels achetés par l’entreprise. On peut tout à fait utiliser le low-code pour créer les sous-domaines de soutien, à la condition que le risque pris soit maîtrisé et que la réécriture des sous-domaines de soutien soit étudiée régulièrement. Il en est de même pour tous les projets réalisés par et laissés à la main des citizens developers et des métiers. Concernant les sous-domaines génériques, l’étude doit être faite de manière plus rigoureuse : Sous quelles conditions et avec quel ROI est-il plus judicieux d’utiliser une plateforme de low-code pour recréer des logiciels qu’on pourrait acheter indépendamment ?
En conclusion, il est nécessaire de considérer le low-code comme il se doit : ce n’est pas une baguette magique, une solution miracle qui révolutionne le monde du développement logiciel. C’est un outil qui permet la création d’applications sous contrôle et en suivant les règles de la DSI/SSI. Ces applications ne doivent pas faire partie du domaine principal de l’entreprise et doivent régulièrement être étudiées afin de savoir s’il y a du sens à les réécrire sans low-code et, bien évidemment, en respectant la philosophie du software craftsmanship ! Comme corollaire à cette conclusion, une DSI moderne doit offrir et supporter une palette d'outils et solutions en distinguant ce qui relève du core domain et du reste. Le low-code peut très légitimement s’occuper de cette dernière partie.
