No code - 2 erreurs à éviter pour des solutions fiables et évolutives

Introduction

Le No code permet des développements de produits rapides et agiles. Pourtant, s'il est mal mis en œuvre, il peut amener à des solutions non fiables ou très peu évolutives.

Nous avons défini chez Gojob nos standards de développements, mettant en lumière les étapes clés et points d'attention à porter lors de développements en No code. Focus sur 2 erreurs à éviter !

Erreur 1 : Ne pas fiabiliser ses solutions ni préempter les erreurs

L'objectif de tout produit étant de livrer la valeur qu'il est supposé apporter à son utilisateur, le No code n'échappe pas à cette règle. Pour que le No code puisse suivre le comportement souhaité, il est nécessaire de préempter les cas d'erreurs en se posant 6 questions clés que nous illustrerons sur un scénario Integromat simple : envoi de SMS à partir d'une recherche de contacts dans une base de données Airtable.

1 / Que se passe-t-il si mes données d'entrée changent ? Est-ce que je maîtrise leur format et leur qualité ?

Pour fiabiliser ses développements No code, il est utile de se demander si la solution No code peut fonctionner avec des données d'entrée qui changent. Dans le scénario ci-dessus, le module d'envoi de messages est à risque d'erreurs si les numéros de téléphones ne sont pas au bon format ou sont vides suite à la recherche dans la base de données Airtable.

Dans ce cas, il faut ajouter un module de préemption d'erreur sur le module d'envoi de SMS ou bien forcer le champ "numéro de téléphone" de la table Airtable à un format standard.

Plus généralement, nous conseillons d'inclure des "chemins d'erreurs" sur tous les modules sensibles : par exemple sur les modules d'envoi de mail (préempter les adresses mails invalides), les calls HTTP (avoir un comportement spécifique pour traiter les réponses d'erreurs en status code 4xx et 5xx)

2 / Comment se comporte mon scénario lorsque les données d'entrée sont vides ?

Une faille se situe dans l'exemple ci-dessus. Lorsqu'aucune ligne Airtable ne correspond au critère de recherche, le module "Envoyer un message" sera également en erreur car le numéro de téléphone le sera également. Un filtre entre les deux modules "Total number of Bundles different of 0" permet de s'assurer de préempter ce cas d'erreur en coupant le scénario dans ce cas précis.

3 / Est-ce que si je relance deux fois de suite mon scénario, le comportement réalisé sera celui souhaité?

Dans l'exemple ci-dessus, deux itérations successives du scénario vont envoyer les mêmes SMS aux mêmes contacts, ce qui n'est probablement pas le comportement souhaité.

Un des leviers pour s'assurer de ne pas avoir des doublons de traitement serait de rajouter un module, suite à celui de l'envoi du SMS, pour reporter les succès d'envoi de SMS dans la table Airtable (par exemple dans une colonne "SMS envoyé" où on viendrait indiqué "oui" ou bien la date). Ensuite, dans le premier module Airtable de recherche des personnes à contacter, ajouter le filtre {SMS envoyé}!="" (SMS envoyé différent de vide) permettrait d'être sûr de ne pas générer des doublons d'envoi.

4 / Comment m'assurer que tous les cas que je souhaite traiter le seront ? Ai-je le moyen de surveiller et capter lorsque une entrée n'a pas été traitée alors qu'elle aurait dû l'être ?

Un des enjeux peu simple à appréhender en No code est celui de l'exhaustivité du comportement final souhaité. Est-ce que toutes les personnes que je souhaite contacter dans l'exemple ci-dessus ont bien été contactées ?

Dans ce cas, un deuxième scénario Integromat, qui tournerait à fréquence moins élevée, pourrait aller chercher dans la base Airtable toutes les personnes que l'on n'a pas réussi à contacter (ou qui ne l'ont pas été) pour résoudre la problématique.

5 / Est ce que mon processus de management des erreurs est bien mis en place ?

Nous nous sommes posés la question chez Gojob : comment s'organiser en équipe pour bien s'assurer de traiter les erreurs qui perdurent même après toutes les bonnes précautions. Une astuce : sur Integromat, nous incluons dans le nom de nos scénarios les initiales du créateur, de manière à ce que l'erreur lui soit directement redirigée.

Lorsque nous pré-emptons les erreurs, nous les explicitons en les redirigeant vers les bons interlocuteurs (l'exemple du module Slack dans l'exemple ci-dessus), en incluant le lien du scénario et le contexte de l'erreur. Certaines erreurs portent sur un périmètre d'utilisation et nous les dirigeons vers nos utilisateurs, d'autres plus techniques sont dirigées vers l'équipe No code.

6 / Est ce que mon développement No code a été revu et testé par des pairs techniques et des utilisateurs ?

Le No code étant du développement de produits, nous adoptons chez Gojob les mêmes rituels de vérification et validation de la qualité. Des sessions de "QA techniques" consistent à faire éprouver sa conception No code, avant de la mettre en production, par un autre No codeur, avec un accent mis sur la fiabilité et scalabilité de la solution développée. Réalisées avec les futurs clients/utilisateurs, les "QA business" permettent de valider l'expérience utilisateur et le bon fonctionnement par rapport au besoin exprimé.

Sur notre exemple précédent, voici à quoi le scénario ressemble une fois fiabilisé :

Erreur 2 - Implémenter une architecture non scalable

Une des erreurs typiques dans les développements No code consiste à négliger la phase de conception pour se lancer directement (et trop vite) dans les développements. Cela peut conduire à des solutions qui ne répondent que partiellement au besoin ou bien à des solutions non scalables car l'architecture d'ensemble n'a pas été réfléchie.

Sur l'exemple ci-dessous, la simple vision d'ensemble du scénario, dont l'objectif est d'envoyer un email à partir de données d'une table Airtable, donne des frissons. L'objectif initial du scénario : envoyer un email à des contacts, différents (car personnalisés) en fonction du job de la personne que l'on souhaite contacter.

Pour chaque contenu de mails à envoyer, le concepteur du scénario a intégré un "Router" vers un module spécifique d'envoi, car la variable qui constitue le corps du mail à envoyer est différente. Le problème : à chaque nouveau job rencontré (donc à chaque nouveau type de mail personnalisé), une action manuelle est requise pour aller rajouter des modules Gmail dans le scénario.

Développer des architectures scalables passe souvent par la mise en place de bases de données de paramétrage (accessibles aux utilisateurs ou administrateurs) pour remplacer toute logique métier que l'on pourrait mettre dans l'Integromat.

Dans notre exemple, nous pourrions rajouter une table Airtable qui contiendrait, selon le job, le contenu du mail personnalisé à envoyer. Un module additionnel Airtable "Search Rows" permettrait d'aller chercher le bon message à envoyer selon le job trouvé. Lorsque ce module de paramétrage renvoie un message personnalisé, nous pouvons l'indiquer comme une variable dans notre module Gmail : finis les Routeurs, un seul chemin sur notre scénario Integromat.

Et lorsque notre module de paramétrage Search Rows ne trouve pas de messages à envoyer, c'est que le job n'a pas été paramétré : nous pouvons donc directement avertir l'administrateur business (avec un message Slack personnalisé) d'aller rajouter le message personnalisé à envoyer pour le nouveau job ! Dans cet exemple, le no code maker est désormais dispensé d'ajouter de nouveaux messages personnalisés car il a rendu la fonctionnalité accessible à ses utilisateurs.

Sur notre exemple précédent, voici donc à quoi le scénario ressemble une fois les enjeux de scalabilité intégrés :

Si vous cherchez à rejoindre l'équipe de Product Managers ou de No codeurs Gojob, n'hésitez pas à consulter nos offres ici et à nous contacter ou postuler. Si vous souhaitez plus d'informations sur les standards de développement No code mis en place chez Gojob, n'hésitez pas à contacter l'équipe !