Le secteur des outils de type High-Productivity Application Platform as a Service (qu’on va se contenter d’appeler “Low-code” pour simplifier…) est en plein boom. En effet, les environnements de développement d’applications se sont toujours bien vendus, mais, en ce moment, la mode est à ceux qui promettent une approche de type “coding léger” (voir pas de coding du tout) et qui ont les faveurs des organisations.

Dans cette chronique, nous allons voir quels sont les critères à privilégier lors d’un choix d’un outil de ce type. Mais, tout d’abord et comme d’habitude, un petit rappel historique s’impose afin de voir le chemin parcouru dans ce domaine…

Des L4G au Low-code en passant par le RAD client-serveur

Historiquement donc, c’est à la fin des années soixante que sont apparus ce qu’on appelait alors les L4G pour “langage de quatrième génération”. L’ancêtre de tous serait Mapper de Sperry Univac (1969). D’abord disponibles uniquement sur grands systèmes, ces produits se sont rapidement multipliés (avec le trio bien connu Ramis/Focus/Nomad) grâce à des éditeurs indépendants comme Information Builders (Focus). Ces environnements ont initialement connu un grand succès avant de rétrograder, car les organisations se sont vite rendu compte que les applications développées avec ces L4G étaient très gourmandes en ressources système !

Le livre de James Martin sur les L4G. James Martin était le consultant qui a contribué à populariser le concept des L4G aux USA…

Relégués et même confinés au domaine de l’infocentre, les L4G (renommés alors RAD pour Rapid Application Development) ont ensuite profité d’une seconde jeunesse dans les années quatre-vingt-dix grâce à la vague du “client Windows/serveur SQL” avec une autre génération de produits comme Microsoft Access, Delphi ou Powerbuilder. Une petite décennie plus tard, le Web a été l’occasion d’un énième renouveau et d’une génération supplémentaire (comme ColdFusion et une myriade d’outils basés sur Java).

Avec ces itérations diverses et variées, le but initial des L4G s’est un peu perdu en route : offrir un environnement de développement simple et ne demandant qu’un recours minimum au coding.

Heureusement, la nouvelle vague “Low-code” est venue relever le défi et remettre la facilité de développement au gout du jour. C’est un analyste de Forrester Research qui a, le premier (en 2014), forgé le nom de cette catégorie avec Low-code development platforms dont le marché naissant peut-être tracé depuis 2011.

Pourquoi cette énième itération de cette histoire à épisodes serait-elle digne d’intérêt ?
Pour deux raisons : vitesse et plateformes.

La vitesse de développement : un horizon hors de portée ?

Le temps nécessaire pour développer les applications s’est révélé être un problème depuis que les organisations se sont lancées dans le développement d’applications !

Et, depuis tout ce temps, on peut dire que tout a été essayé afin de résoudre ou, au moins, d’atténuer ce problème : méthodes, langages, approches, outils, etc.

Car la vitesse de développement n’est pas seulement souhaitable (qui peut se réjouir de devoir attendre son application pendant des années ?), c’est aussi nécessaire. Tous ceux qui ont travaillé sur des grands projets savent bien que la durée de développement influe beaucoup sur son aboutissement : plus un projet de développement est long et moins il a de chance de voir le jour, finalement…

Car des nombreux syndromes s’accumulent : le syndrome du comité (les spécifications de la future application sont définies par de trop nombreuses personnes qui ont du mal à se mettre d’accord entre elles), le syndrome de l’effet tunnel (le développement dure des mois voire des années et quand il est enfin achevé, la situation initiale a tellement changé que l’application développée n’est plus pertinente) et, enfin, le syndrome du trou noir (le projet capte tout -ressources, budget- sans produire de résultat et est finalement annulé). Rares sont les grands projets s’étalant sur des années qui parviennent à survivre à tout cela. Donc, pour aboutir, il vaut mieux faire vite.

Mais développer rapidement (très rapidement : dans ce cas, on parle de semaines voire de jours, pas de mois !) ne suffit pas, encore faut-il le faire pour la bonne cible…

On saute de plateforme en plateforme depuis quarante ans

A l’époque des premiers L4G, il fallait juste pouvoir tourner sur les grands systèmes. D’abord ceux d’IBM puis, éventuellement, ceux des “autres”. Puis, il fallut prendre en compte la grande diversité des mini-ordinateurs. Et quand le PC devient crédible grâce aux réseaux et au client-serveur, il devint la cible prioritaire (avec une interface utilisateur sous Windows bien sûr). Puis, le Web s’est imposé et il fallut le prendre en compte. Aujourd’hui, ce sont les plateformes mobiles qui comptent le plus : IOS et Android. Développer pour le Web est encore nécessaire, mais plus suffisant : il faut aussi que les smartphones de vos utilisateurs puissent accéder à vos applications sur leurs smartphones et en mode natif de préférence… Et, bien sûr, il faut que le déploiement soit possible sur le cloud !

Bref, on l’a compris, la liste d’exigences pour les outils low-code est bien précise et ne s’encombre pas d’à-peu-près. Et il y a des candidats dans ce cadre ?

Quels produits dans la short liste ?

En fait, il y a une pléthore de produits qui se revendique “Low-code” !

Pour faire simple, jetons d’abord un oeil sur les acteurs mis en avant par le Gartner, soit :

  • Salesforce Lightning
  • Outsystems
  • Mendix
  • Appian
  • ServiceNow
  • Caspio
  • QuickBase
  • MIOsoft
  • Kintone
  • Zoho Creator
  • AuraPortal

Plutôt que de monter le “cadran magique” du Gartner une fois de plus, voyons plutôt ce schéma de Forrester sur le même sujet… On retrouve plus ou moins les mêmes noms !

Cette liste est déjà fournie, mais elle est loin d’être suffisante. Car, en plus des quelques nouvelles vedettes du secteur mises en avant par Gartner (comme Appian, OutSystems et Mendix), il faut aussi penser à ajouter Powerapps de Microsoft et QuickBase (très populaire aux USA). On constate qu’avec Salesforce, Microsoft (quasiment en dernier avec le récent Powerapps) et Google (avec Zoho Creator, mais qui vient aussi de mettre en avant App Maker intégré à sa G Suite), il ne manque que deux des très grands acteurs dans cette liste : rien du côté d’Oracle ni d’Amazon (qui pourrait être intéressé à intégrer un outil dans son offre AWS). Mais un rachat est vite arrivé avec ces géants aux poches profondes…


Google avait déjà Zoho Creator mais décide de doubler la mise (comme Microsoft) avec App Maker, preuve de l’intérêt des grands pour ce marché…

Beaucoup de noms nouveaux et peu connus dans cette liste déjà longue. Mais les anciens ne renoncent pas pour autant… Powerbuilder, par exemple, est encore là !

Ballotté de rachat en rachat (Sybase puis SAP) il est désormais commercialisé par Appeon et se positionne toujours dans la catégorie “client riche” même si tous les buzzwords à la mode sont présents dans sa description (y compris le cloud donc). Pareil pour MS Access (encore que, Microsoft désormais préfère mettre en avant un nouveau produit -Powerapps- plus “au gout du jour”) et FileMaker (ainsi que ColdFusion, Omnis et j’en passe, la liste des anciens qui sont sur les rangs est longue !).

Low-code ou no-code ?

Ces nouvelles plateformes de développement se présentent comme si facile à utiliser qu’elles ne demandent pratiquement pas de coder pour développer. Dans la plupart des cas, c’est bien vrai, mais cela veut-il dire qu’on peut se passer de développeurs avec ?

Cette question agite les esprits puisque, aux USA au moins, on commence à parler de “citizen developers”… Cela ressemble largement aux illusions du temps des premiers L4G !

Soyons clairs, aussi faciles qu’elles soient, ces plateformes demandent quand même des compétences techniques non négligeables. Le fait de ne pas devoir coder n’est que la partie émergée de l’iceberg, comme toujours. Des connaissances en matière de base de données et de design d’interface utilisateur sont indispensables afin d’aboutir à quelque chose d’utilisable.

En revanche et ce qui est bien plus important que l’absence de coding, c’est la capacité à aller vite dans le cycle de développement. Au lieu de demander des mois, ces plateformes vont vous permettre de mettre des applications dans les mains de vos utilisateurs en quelques semaines voire en quelques jours. Cette démarche rapide n’a que des avantages : elle permet le prototypage en de multiples phases si c’est nécessaire. On évite ainsi à la fois “l’effet comité” et “l’effet tunnel” si néfaste à la survie des projets.

Personnalisable, mais jusqu’à un certain point

Cela dit, la rapidité de développement n’est qu’un des aspects de la question : à quoi sert de développer vite si on est limité dans le type d’application que l’on peut produire ?

La profondeur de développement et la personnalisation des interfaces utilisateurs sont donc tout aussi importantes que la rapidité de design de ces applications Low-code. Or, c’est souvent un reproche fait à ces environnements : on peut produire très vite des interfaces utilisateurs attrayantes, mais quand il s’agit de les personnaliser (ou, par exemple, de les adapter à un usage sur mobile), on tombe parfois sur un mur. Donc, le potentiel de développement (ou sa profondeur) va se révéler être un autre critère-clé dans le choix d’un environnement Low-code.

Connectivité et cloud

S’ils veulent être pris au sérieux, ces environnements doivent proposer de s’interfacer avec l’extérieur. REST est le candidat habituel pour cela, mais nécessite un effort d’intégration non négligeable. L’autre voie est d’utiliser les “connecteurs du cloud” que sont Zapier, Tray.io ou Workato !

Ces outils permettent d’interfacer votre application avec les services web connus comme PayPal, Gdocs ou autres et tout en restant dans l’esprit Low-code : il s’agit plus de design et de paramétrage que de coding (on est loin d’une intégration de type REST…). Bien entendu, la possibilité de s’interfacer directement avec un outil de BI comme Tableau ou un ERP du marché pèse aussi dans la balance.

Enfin, on doit aussi tenir compte des possibilités de déploiement : propriétaire seulement (l’application développée est obligatoirement hébergée par le fournisseur de la plateforme), propriétaire ou externe au choix ou externe seulement (la plateforme n’est qu’un outil de développement et le déploiement doit se faire sur un fournisseur de cloud tiers).

Les freins à l’adoption

Les outils Low-code sont séduisants, mais cela ne veut pas dire que les entreprises vont se précipiter dessus sans réfléchir. Le développement d’applications est toujours une affaire sérieuse (et le fait que la plupart des éditeurs cités plus haut sont récents n’est pas vraiment rassurant vis-à-vis de leur pérennité). De plus, certains pensent que la tendance Low-code va encore renforcer le phénomène de shadow IT qui est présent dans toutes les grandes organisations. Sur ce dernier point, je pense au contraire qu’adopter ce type d’environnement de développement ne peut qu’améliorer les relations entre les départements et le service informatique en réduisant la complexité de la mise en oeuvre des projets.

L’autre aspect sensible, c’est le fait que ces environnements combinent souvent développement et exécution… En clair, ils ne peuvent fonctionner qu’en reposant sur leurs propres couches logicielles et sont donc dépendants d’un « run-time », comme les générations précédentes des L4G…

Pour éviter cette contrainte qui peut être vécue comme très limitative, il vaut mieux privilégier les solutions capables de générer du code “standard” qu’on pourra alors installer sur l’environnement de son choix, sur le cloud ou sur site. Bien entendu, faire de ce critère une priorité va sévèrement restreindre vos choix possibles (au moins dans le contexte actuel, sans doute moins au fur et à mesure que ce marché va gagner en maturité)…

Le portrait-robot de l’environnement idéal

Résumons-nous, l’outil Low-code “idéal” présenterait le profil suivant : il permet de développer vite (en une semaine maxi, vous avez déjà quelque chose d’utilisable), mais aussi de personnaliser l’interface en profondeur si nécessaire (en particulier sur plateforme mobile).

IDE, mais aussi générateur de code afin d’éviter l’écueil du  run-time. L’environnement de développement n’est pas isolé puisqu’il est interfacé avec Zapier et permet le déploiement sur le cloud de votre choix. Bref, c’est le choix idéal !

Existe-t-il ?

Une étude comparative pour faire la part des choses

Pour mesurer les produits actuels sur cette grille de critères, une étude comparative serait la bienvenue !

Et c’est justement ce que Redsen est en train de préparer : une étude comparative de ces environnements avec une sélection significative du marché actuel. Avec tous les outils sélectionnés, une application-cible sera mise en œuvre (toujours la même) permettant de mesurer tant la facilité/rapidité de développement que la profondeur du potentiel de chaque environnement. Cette étude permettra d’éclairer ce marché en effervescence qui va largement attirer attention et convoitise pour les années qui viennent !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Voir plus
scroll to top