Les plateformes low-code s’adressent d’abord aux équipes métier et aux développeurs occasionnels. Elles sont pourtant tout aussi utiles aux développeurs professionnels, qui y créent rapidement des applications capables de se connecter à de nombreuses sources de données.

Reste à savoir comment y appliquer une méthode agile, puisque ces plateformes changent le rythme du projet. Voici six conseils.

L’équipe de notre CRM automatisable et flexible vous dit tout.

Low-code et développement classique : ce qui change

Un développement classique exige un travail important de conception et de définition des interfaces en amont. Sur une plateforme low-code, ces étapes vont plus vite, mais vous êtes tributaire des limites de la plateforme.

Les outils de développement classiques couvrent tous les cas de figure, de la petite application à deux développeurs au système d’envergure porté par une équipe complète. Les plateformes, elles, sont conçues pour qu’un individu ou une petite équipe livre rapidement une application de gestion.

Toutes ne se valent pas, en particulier sur deux points : les possibilités d’extension par le code, et les capacités de documentation. C’est le premier critère à examiner avant de choisir.

1. Ne jamais sauter l’analyse des besoins

Faire de l’agile ne signifie pas supprimer les étapes de projet. L’analyse des besoins reste indispensable avant tout paramétrage.

Une fois les besoins listés, vérifiez que la plateforme retenue y répond. Sinon, identifiez précisément ce qui devra être développé en complément.

La règle à retenir est celle du ratio 80/20 : 80 % des besoins fonctionnels doivent être couverts par le standard de la plateforme, 20 % au maximum par du spécifique. Au-delà, vous avez probablement choisi le mauvais outil, ou le mauvais périmètre.

2. Raccourcissez vos itérations

Puisque le maquettage est plus rapide que sur un développement classique, la durée des cycles peut être réduite en conséquence. Des itérations de deux semaines constituent un rythme courant sur ce type de plateforme.

L’intérêt n’est pas la vitesse en soi, c’est la fréquence des retours. Un cycle court signifie une correction de trajectoire tous les quinze jours plutôt que tous les deux mois.

3. Concentrez-vous sur l’usage réel

Présentez les écrans très tôt, d’autant que vous êtes techniquement contraint par la plateforme : autant découvrir ces contraintes avec les utilisateurs plutôt qu’après.

Et mettez l’accent sur la valeur métier plutôt que sur la prouesse technique. Un utilisateur ne juge pas votre architecture, il juge le nombre de clics qu’il lui faut pour faire son travail.

4. Déployez souvent

Optez pour des cycles de déploiement courts et des mises en production régulières, en particulier si la plateforme ne gère pas nativement les versions. Cette approche présente deux avantages.

• Les nouveautés arrivent régulièrement chez les utilisateurs, ce qui entretient leur adhésion au projet.
• L’équipe ne maintient que deux états à un instant donné : la production et le développement en cours. Cela réduit le travail de fusion et accélère la correction des anomalies.

5. Faites valider par les utilisateurs

N’escamotez pas les tests de recette utilisateur. Ce sont eux qui garantissent que l’avancement correspond à l’attente, itération après itération.

Cela vaut aussi après la mise en production, à chaque correction et à chaque nouvelle fonction. Une anomalie corrigée sans validation revient très souvent sous une autre forme.

6. Documentez à chaque déploiement

Une nouvelle personne dans l’équipe, une fonction à modifier deux ans après sa création : c’est là que la documentation se rentabilise. Perdez un peu de temps maintenant pour en gagner beaucoup plus tard.

Beaucoup d’équipes croient que faire de l’agile revient à réduire l’effort de documentation. C’est une erreur coûteuse : modèle de données, spécifications techniques, schémas d’architecture doivent être tenus. Nous développons ce point dans notre article sur les limites des méthodes agiles.

Ces conseils s’adaptent à toutes les plateformes, dont les capacités techniques varient beaucoup. Et quelle que soit la méthode retenue, le temps consacré au choix de la plateforme reste le meilleur investissement du projet.

Vos questions sur l’agilité en low-code

Faut-il un chef de projet dédié ?

Sur une petite application, non. Dès que plusieurs métiers sont concernés, il faut quelqu’un pour arbitrer le périmètre, sans quoi chaque service ajoute ses demandes et le projet s’étire indéfiniment.

Que faire si le besoin dépasse les capacités de la plateforme ?

Vérifiez d’abord si le besoin est réel ou hérité d’une habitude. Beaucoup de demandes hors standard reproduisent un fonctionnement existant que personne n’a réinterrogé depuis dix ans.

Combien de temps pour une première version utilisable ?

Quelques semaines sur un périmètre restreint. C’est précisément l’intérêt du low-code : obtenir vite quelque chose de tangible, que les utilisateurs peuvent critiquer utilement.

Comment gérer les demandes qui arrivent en cours de projet ?

En les inscrivant dans une liste priorisée plutôt qu’en les traitant au fil de l’eau. Accepter une demande hors cycle ouvre la porte à toutes les suivantes, et c’est ainsi qu’un projet de trois mois en prend douze.

Faut-il documenter autant qu’un développement classique ?

Pas le code, qui est en grande partie généré, mais autant sinon plus le paramétrage et les règles métier. Ce sont elles qui deviennent incompréhensibles au bout de deux ans si rien n’est écrit.