Appsheet, Microsoft Power Platform, Zapier, AWS HoneyCode, Glide, Airtable, Siberian… il ne vous aura sans doute pas échappé que cette année 2020 aura été celle du low code / no code !

Bien sûr, en tant que Developpeur.se, la première réaction face à ces nouvelles méthodes de développement est souvent beuurk…

Mais en tant que développeur.se, notre métier ne consiste-t-il pas à perpétuellement se remettre en cause afin de proposer la meilleure solution technique au client.e ?

C’est en tout cas ce que je pense, et c’est pourquoi je considère que le low-code / now-code à tout à fait sa place dans mon offre 🙂

Mais d’abord, de quoi parlons nous?

Pour moi, l’idée maitresse du low code est de pouvoir produire, relativement facilement et rapidement, des outils métiers qui déchargent les entreprises des tâches à faible valeur ajoutée, ou qui permettent d’améliorer leur flux de travail.

Le mot clé étant à mon avis « rapidement ».

Même si le terme est relativement nouveau, Excel par exemple fait ça depuis très longtemps via les macros.

La différence est que maintenant, on peut faire communiquer entre eux différents logiciels, par exemple grâce à Zapier, et créer de véritables applications mobiles qui se synchronisent avec des classeurs Excel ou Suite.

Pour moi, on peut aussi les CMS modernes comme Word Press d’outils no code. Pouvoir créer des applications mobiles de cette façons était donc la suite logique.

El alors, comment ça marche ?

En ce qui concerne le développement d’applications mobiles low code, j’ai déployé des applications réalisées avec Siberian (voir cet article) et avec Appsheet (article à venir).

Siberian ayant déjà été décrit, je vais un peu détailler le fonctionnement d’Appsheet.

Tout commence par une base de données… sous forme de tableur. Il est bien sûr recommandé d’utiliser Google Sheet, mais cela fonctionne aussi très bien avec excel via Onedrive. Une fois ce classeur créé et murement réfléchi, tout se passe via l’interface graphique d’Appheet, via des formules de tableur.

Le développement de l’application fera l’objet d’un article complet… mais c’est justement à ce niveau qu’il conviendrait de préciser à qui se dessine réellement le développement low-code…

Les données étant synchronisées dans un tableur (par exemple Excel), on a ensuite toute latitude pour développer une application Office de traitement des données, par exemple en Visual Basic…

Pour avoir plus d’idées de ma conception du développement low code, et plus généralement de l’automatisation de tâches, vous pouvez aussi jeter un oeil à la présentation que j’avais faite pour le Club d’affaires Proteine : https://youtu.be/WcZ7hZ-2fYE.

Mais concrètement, ça sert à quoi ?

Pour moi, toute cette mouvance du low code / no code correspond à une véritable attente des entreprises. En effet, l’automatisation des ta^ches (APR : automatisation de processus robotiques) permet de libérer les employés des tâches répétitives afin qu’il.elles puissent se concentrer sur des tâches à forte valeur ajoutée.

Tout comme pour les CMS, le low-code permet de donner accès aux entreprise à des technologies récentes (machine learning…), tout en pouvant prototyper et itérer rapidement, puisque les briques logicielles de base sont faites.

On peut alors envisager la création d’application métier personnalisées, à des tarifs plus abordables pour les PME par exemple, ou développer rapidement une application pour un service particulier dans une grande entreprise (ex : service maintenance).

Oui mais… en tant que dev, t’en dis quoi ?

Pour moi, il n’y a pas lieu d’opposer le low code / no code au développement « traditionnel ». C’est juste 2 pratiques différentes.

Il est en effet pour moi illusoire de penser qu’une cadre, qu’un.e manager, qu’un.e dirigeant.e, si non passionné.e d’informatique, va investir du temps pour se former à ces nouvelles pratiques. Il suffit de voir le niveau moyen d’utilisation d’Excel en Entreprise pour s’en convaincre.

De plus, sans un bon background technique, il sera impossible de réaliser autre chose qu’une « usine à gaz », impossible à maintenir dans la durée.

Qu’on le veuille ou non, il faut un bagage de développeur pour faire de bonnes applications no code. Mais on peut maintenant faire de très bonnes applications métier avec ce système, avec des performances tout à fait correctes.

Je pense que dans le cas de prototype, ou de développement d’applications aux fonctionnalités « classiques », se pencher sur du low code est une bonne idée. Inutile de ré-inventer la roue ! C’est d’ailleurs un peu la base du développement orienté objet ! Le gain de temps est énorme, et, en tant que freelance, cela me permet de réaliser des projets pour des clients motivés, mais qui n’auraient de toutes façons pas eu les dizaines de millier d’euros à investir d’un coup dans une développement traditionnel.

Par contre, cela ne m’empêche pas de développer en cross-platform si on a besoin de fonctionnalités plus poussées, voir même en iOS Natif si nécessaire. C’est juste pas le même type de projets, et pas les mêmes client.es.

En fait, j’ai même certains projets développés en low code sur Appsheet qui sont voués à terme à évoluer en projet Flutter, lorsque le modèle commercial de l’entreprise aura fait ses preuves.

En résumé, c’est pour moi une opportunité business, et non une guerre entre 2 méthodes de développement. Vu la conjoncture actuelle, vu les acteurs en jeu et vu l’engouement des entreprises pour l’automatisations des tâches, il s’agit d’une tendance qui ne peut que se développer. Alors à nous de ne pas rester sur le quai !