No-code/low-code : les trois bonnes raisons de s'y mettre

Dans notre précédent article, "Le low code comment ca marche" , nous avons expliqué comment les outils de low-code/no-code permettent de construire des applications de manière interactive en utilisant des modelers visuels.

Dans cet article, nous allons présenter comment ces outils peuvent être regroupés en trois familles de solution no-code/low-code qui répondent aux besoins de trois profils d’utilisateurs bien distincts : l’entrepreneur, le collaborateur, le développeur professionnel . Pour chacun des cas nous présenterons les opportunités amenées par chaque famille d'outils et répondrons à deux questions cruciales : est-ce qu’il faut y aller et comment y aller.

En tant qu'entrepreneur, collaborateur ou développeur, n'attendez plus et découvrez les trois raisons de vous mettre au no-code/low-code !

l'habit fait le moine

Arbitrage entre facilité d’utilisation et la finesse de contrôle sur l’application

Tous les outils de no-code/low-code s’appuient sur les mêmes principes mais ce qui va faire qu’un outil correspond à un profil d’utilisateur plutôt qu'à un autre est l’arbitrage qui aura été fait par les concepteurs de la plate-forme entre la finesse de contrôle sur l’application réalisée et la facilité d’utilisation. Ce choix est structurel et explique en partie le nombre élevé de solutions de no-code/low-code sur le marché : il y a des solutions adaptées à différents usages.

continuum des produits no-code vers du low-code

L'évaluation d'un outil et son choix doit se toujours se faire par rapport à l’usage attendu et les outils de no-code/low-code ne dérogent pas à cette règle. Prenons l'exemple des moyens de transports, le vélo n'est pas meilleur ou moins bon que le train dans l'absolu : il est plus adapté aux courtes distances, et moins adapté aux distances plus longues.

Les trois cas d’utilisation du no-code/low-code

Partant de ce constat nous avons établi trois Personas qui illustrent les trois cas principaux d’utilisation du no-code. Nous verrons que chacun de ces Personas a des objectifs et des contraintes complètement différents, voire opposés. Pas étonnant qu’un outil de no-code qui est bon pour l’un ne le soit pas pour les autres :  tout le monde n’est pas un pilote de course au volant d’une F1 !

Typologie des utilisateurs

Joelle

Notre première Persona s’appelle Joëlle. Joëlle est une innovatrice, elle recherche à expérimenter et tester son idée. Pour cela elle doit réaliser des prototypes puis un MVP fonctionnel qui permettra de valider l’appétence des premiers utilisateurs. Joëlle n’a ni le temps, ni les moyens de fabriquer une application évoluée, elle doit s’en sortir avec des « bouts de ficelles ». Elle n’a pas non plus intérêt à investir massivement tant qu’il y a peu de certitudes sur la viabilité du concept, d’autant plus qu’il n’est pas exclu qu’elle doive faire pivoter son offre. En résumé Joëlle a besoin d’outils simples lui permettant, à elle ou à son équipe, de créer un produit logiciel très rapidement sans avoir de connaissances pointues sur le design et le développement d’application.

Tom

Tom est notre second persona, il est salarié d’une entreprise et son principal problème est le manque de temps. Il se rend bien compte qu’il en perd beaucoup sur des tâches qui sont faites manuellement et qui pourraient être automatisées. Il utilise de nombreux tableaux Excel qui l’aident déjà beaucoup, mais ces tableaux ne peuvent pas être remplis par ses collaborateurs en mobilité sur le terrain. De plus quand il n’est pas là personne n’ose les utiliser de peur de se tromper. Tom a déjà regardé les progiciels sur le marché, mais ils ne sont pas adaptés au fonctionnement de son service ; il a aussi demandé à la DSI de faire une application mobile, mais c’était l’équivalent du budget annuel du service : impossible à amortir. En résumé Tom a besoin d’un outil qui lui permette d’être autonome pour automatiser des workflows ou créer des applications de partage d’information avec ses collaborateurs ou les clients du service. Tom maîtrise déjà la bureautique avancée et n’a pas de problème à écrire un peu de code. De plus l__a sécurité est un point absolument crucial__ : il faut que ces outils soient intégrés avec les annuaires d’entreprise pour gérer les accès de manière absolument sécurisée.

Paul

Paul est DSI d’une entreprise. Il arrive à gérer correctement les gros projets et la mise en place de l’agilité a beaucoup contribué à améliorer cela. Cependant il a deux autres problèmes. Tout d’abord quand un service a besoin d’une petite application interne on lui dit que ce qu’il propose est trop cher et trop compliqué à mettre en œuvre et que finalement cela ne sera jamais finançable pour un si petit nombre d’utilisateur. Le second problème de Paul est le recrutement. Il a besoin de nombreux spécialistes pour ses équipes : développeurs front (Angular, Vue, React…), back (Java, Node JS, .net…), bases de données (PostgreSQL, Oracle, MySqL, Elastic search, mongo db…), sans compter les OPS, les spécialistes Kubernetes et sécurité. Par ailleurs, il a des personnes qui sont sur des technologies qui sont en voie d’obsolescence, mais qui ont du mal à migrer vers toutes ces nouvelles technologies. Il est facile de reconvertir des personnes qui ont déjà des compétences de développeur à l’utilisation de plateformes low-code pour développeurs. Avec ces plateformes low-code et les ressources nouvellement formées il est possible de créer une filière alternative au développement traditionnel pour créer des applications.

JoelleLes solutions no-code pour Joëlle, l’entrepreneuse digital

Joëlle a besoin de solutions prêtes à l’emploi avec un minimum de paramétrage. Par voie de conséquence chacune de ces solutions va être focalisée sur la résolution d’un problème particulier, par exemple faire un site WEB, gérer des données, gérer des rendez-vous, présenter des données sous forme d’API créer une application mobile simple, gérer des workflow… Ces solutions sont en quelque sortes des progiciels techniques. La frontière avec des solutions dites SaaS peut être parfois ténue comme pour les outils de gestion de rendez vous.

Parce que chaque solution ne couvre q'une partie du besoin, Joëlle va devoir assembler plusieurs de ces solutions de no-code ou de solutions SaaS et cela au moyen d’autres solutions elles-mêmes de type no-code (de type Zappier).

Est-ce qu’il faut y aller ?

Dans ce contexte d’utilisation les outils ne no-code sont des accélérateurs importants et leurs limites ne sont pas un problème. Il serait criminel de ne pas mettre à profit ces nouveaux outils !

Comet, une start-up qui met en relation des free-lance avec des entreprises est passé de 0 ) 500K€ en n'utilisant que des outils no-code/low-code. Ecoutez l'interview inspirante de son CEO, Charles Thomas par Alexis Kovalenko de Contournement

Comment y aller ?

La difficulté est de choisir les solutions no-code qui correspondent à ses besoins dans un écosystème qui est en constante évolution, par exemple Google a acheté AppSheet en janvier et annoncé dans la foulée qu’il allait arrêter sa propre solution noCode appelée AppMaker.

On peut citer les produits les plus connus suivant les domaines :

  • Site web : Weebly, Squarespace, Wix, Webflow

  • Application mobile : Glide, AppSheet, dalo

  • Application : Bubble

  • Gestion de données : Airtable, QuickBase, Caspio

  • Automatisation de flux : Zappier

Vous trouverez des listes plus exhaustive sur le site de >contournement https://www.contournement.io/ et sur https://www.nocoders.fr/ et https://www.nocode.tech/tools.

Nous vous proposons en synthèse les critères de choix de ces outils et les conseils Octo.

Critères de choix des outils

  • L’hébergement de type SaaS : dans une approche prêt à l’emploi, il est important de ne pas avoir à assumer les contraintes d’exploitation (hébergement, maintien en condition opérationnelle …) on ne veut pas s’ennuyer avec de la gestion de serveur.
  • La possibilité de tester gratuitement : pour valider que la solution envisagée, possède les fonctionnalités prérequises pour couvrir les besoins identifiés qui nous sont obligatoires.
  • La qualité des tutorials : pour disposer de l’autonomie nécessaire à l’appropriation de la solution ces outils se prennent en main par auto-formation.
  • L’activité de la communauté : pour trouver aide et exemples à même de dépasser les potentielles difficultés rencontrées.
  • La facilité de mise en oeuvre et la robustesse : pour accélérer la mise en oeuvre tout en étant assuré qu’aucune anomalie ou autre bug vienne perturber les développements et l’utilisation par les acteurs ciblés pas question d’avoir un site qui buggue lors du développement ou pour les utilisateurs.
  • La capacité à assembler cette solution avec d’autres services ou d’autres solutions : pour garantir la possibilité d'interagir avec un écosystème élargi, par export ou import de données, mais aussi appels ou fourniture d’API

Les conseils Octo

  • Renseignez vous sur les outils : forum d’entrepreneurs, meet-up no-code, formations, conseil, références en fin de cet article
  • Expérimentez l’outil afin de bien évaluer le niveau de compétence requis. Par exemple Bubble demandera plus d’investissement que Weebly pour faire un site simple
  • Une fois l’outil choisi, n’hésitez pas à passer aux versions payantes : la plupart des outils ont une approche freemium mais les versions payantes apportent de nombreuses fonctionnalités pour une somme modique en comparaison au temps économisé …et c’est une manière de pérenniser le modèle !
  • Faites-vous accompagner : si la prise en main des outils vous paraît difficile, bénéficiez de quelques jours d’un accompagnement d’un expert afin de concevoir l’application ensemble. On apprend beaucoup en faisant et c’est plus facile de faire évoluer quelque chose que de le construire.
  • N’hésitez pas à changer d’outil si ce dernier devient limitant. Nous sommes dans la catégorie d’outils qui ont privilégié la facilité d’utilisation au contrôle sur ce qui est produit.

TomLes solutions de low-code pour Tom, le collaborateur augmenté

Les premiers cas d’usages sont l’automatisation de workflow simples. Il est possible aussi de créer des applications au-dessus de feuilles de calcul. Par exemple pour permettre à des collaborateurs de faire des saisies sans avoir à manipuler une feuille de calcul.

Enfin, il est possible de développer les applications dont les utilisateurs ont toujours rêvé et qui n’ont jamais été réalisées car trop coûteuses à développer et exploiter suivant le processus industrialisé des DSI.

Les outils de low-code permettant cela demandent un minimum de connaissance en développement : écriture de formules de calculs, notion de widget graphique, notion d’évènements, compétences en modélisation de données comme les relations. Acquérir ces connaissances sur le tas peut être long et fastidieux voire carrément décourageant. Une formation à ces outils et aux notions manipulées est nécessaire pour les personnes sans connaissances en développement.

La mise en place d’une solution no code pour les collaborateurs doit être pilotée au niveau de l’entreprise car elle doit être intégrée au SI bureautique de l’entreprise et en particulier au système d’authentification.

Est-ce qu’il faut y aller ?

La mise en place d’un tel programme est une décision stratégique de l’entreprise. Elle doit répondre à des douleurs des équipes opérationnelles qui peuvent se matérialiser par une faible productivité ou la présence importante de shadow IT. Vous trouverez en référence l'exemple de la SNCF qui a formé 150 collaborateur experts sur la plate-forme PowerApps de Microsoft et qui a ainsi abouti à la création de dizaines d'applications métiers par ses collaborateurs.

Comment y aller ?

Les fournisseurs privilégiés sont les grands éditeurs comme Microsoft (PowerApps, Power Automate, Power BI), Google (Google Script, Appsheet), Appian, ServiceNow (Now Platform App Engine)…

Nous vous proposons en synthèse les critères de choix de ces outils et les conseils Octo.

Critères de choix des outils

  • Intégration avec les outils et la bureautique de l’entreprise : annuaires, répertoires partagés
  • Mode de licencing : Certains mode de tarification (à l’application, à l’utilisateur, au “développeur”, forfaitaire, à l’utilisation) seront plus adaptés que d’autres suivant la taille de l’entreprise et l’usage.

Les conseils Octo

  • Animer une communauté de développeurs « business » sur cette plate-forme
  • Mettre en place une offre formation initiale à la plate-forme
  • Proposer un accompagnement permettant d’épauler les apprentis développeurs dans la mise en place de leur première application.
  • Proposer un service de support pour ne pas laisser les collaborateurs seuls face aux potentielles difficultés rencontrées
  • Proposer une formation avancée pour découvrir la richesse de l’écosystème - principes de conception, technique de debuggage, connaissance du catalogue de fonctions ….

PaulLes solutions de low-code pour la DSI

Le développement d’une filière low-code au sein de la DSI permet d’améliorer la réactivité à la création d’applications peu complexes. Les solutions low-code de développement professionnel agissent sur deux leviers pour aboutir à ce résultat. Le premier levier est la fourniture une plate-forme industrialisée, prête à l’emploi qui gère tout le cycle de vie. Le second levier est l’opportunité de former relativement facilement des personnes au développement sur cette plate-forme.

Est-ce qu’il faut y aller ?

La question est ici plus complexe car les enjeux et les risques sont multiples. Les enjeux principaux sont la  productivité, le time to market, la facilité à travailler en proximité avec le métier et l’opportunité de reconversion de collaborateurs sur ces technologies. Les risques sont les mêmes que pour l’utilisation d’un progiciel : engagement sur une technologie pour de nombreuses années (enfermement propriétaire/vendor lock-in), pérennité de la solution, disponibilité des compétences, support éditeur, capacité de la plate-forme à supporter les exigences fonctionnelles et techniques.

Il ne faut pas confondre low-code et low-cost ! La notion de réduction des coûts de développement mise en avant par les plate-forme low-cost est une réalité, cependant elle doit être mitigée. Tout d’abord, cette réduction des coûts s’applique principalement sur la partie développement pur, qui est en général estimé à environ ⅓ du total d’un projet. Ainsi les gains de x6 annoncés par certaines études comme celle de PEGA ne concernent que la partie codage. Ensuite, cette réduction des coûts est principalement due à une accélération en début du projet permise par l’utilisation d’une solution clé en main là où un développement classique nécessite du temps pour toutes les “premières” et tout ce qui est du “set-up” (premier écran de saisie, première liste, premier batch, automatisation de l’usine de développement, de la partie devops). De ce fait le gain de productivité est beaucoup plus grand pour un développement court qu’un long projet.

Afin de maximiser les gains (pas que financiers) et de minimiser les risques il est pertinent de commencer à développer la filière low-code sur des applications petites ou moyennes non critiques car :

  • C’est là qu'il va y avoir les gains les plus importants en terme de Time to Market et de productivité

  • Cela permet de monter en compétence sur la plate-forme de manière sereine

  • Le risque dû à la non pérennité de la solution est faible

  • Les premiers retours d’expérience, notamment en terme de connaissance des limites de la plate-forme, de support, et disponibilité des compétences permettront de déterminer comment la cible des applicatifs éligibles peut être élargie.

Comment y aller ?

Les fournisseurs se divisent en deux grandes catégories. D’une part les fournisseurs d’ERP comme salesforce, servicenow, Appian, PegaSystems. D’autre part les ‘pure player, principalement Mendix ou Outsystems. Gartner et Forrester produisent des études (références en annexe) qui classent les principaux fournisseurs. Cet études permettent d'identifier les sociétés présentes sur le marché, mais ne permettent pas de choisir en fonction du contexte de l'entreprise.

Nous vous proposons en synthèse les critères de choix de ces outils et les conseils Octo.

Critères de choix des outils

  • La pérennité de la solution et en particulier son niveau d’adoption
  • Le niveau de support de l’éditeur : documentation, auto-formation, communauté, support spécifique par l’éditeur ou des SEN certifiées
  • Le mode de commercialisation et les coûts associés, que ce soit en terme de développement et de run
  • La possibilité d’exécuter la solution on-premise ou sur son cloud
  • Evaluer les termes de sortie :  d’un point de vue contractuel et technique (récupération de données, caractère open-source de la solution).
  • Les modes d’intégration au SI : connecteurs, support API entrant/sortant

Les conseils Octo

  • Choisir un pure-player ou capitaliser sur un fournisseur d’ERP fournissant une solution low-code et déjà présent dans l’entreprise
  • Utiliser un projet peu risqué pour mettre en place la filière et valider les promesses de l’outil
  • Commencer avec des développeurs confirmés sur la plate-forme choisie qui seront à même d’utiliser l’outil suivant sa philosophie. La principale cause d’échec de projets low-code est la mauvaise utilisation de l’outil.

Perspectives

Perspectives

Les solutions de no-code/low-code apportent des réponses ciblées à chacun des trois cas d’utilisations principaux: entrepreneuriat, productivité personnelle ou d’équipe et enfin le développement d’application du niveau entreprise.

Ces plateformes sont matures et il serait dommage de s’en passer. Attention toutefois à sélectionner avec soin les projets dans le cadre de développement d’applications d’entreprise.

Références