En entreprise, le No code offre des opportunités croissantes d’automatisations ou de mise à disposition de nouvelles fonctionnalités. Grâce à un temps de développement accéléré, il peut offrir rapidement et itérativement de la valeur aux utilisateurs.

Pourtant, sans expertise de scalabilité ou de fiabilisation et sans outils de suivi dans la durée, la maintenance d'automatisations No code peut s’apparenter à un vrai cauchemar.

Comment fiabiliser les automatisations No code ? Comment créer une culture Tech dans laquelle les Product Builders délivrent un usage durable autour de leurs automatisations ? Notre solution chez Gojob : une delivery fiable et un monitoring par la data.

1- Délivrer des automatisations fiables : un objectif nécessaire mais non suffisant

Première condition nécessaire à une valeur durable du No code, la livraison d’automatisations scalables et fiables. Les phases de conceptions de projets No code incluent une réflexion sur ces deux piliers (voir notre article qui illustre le sujet au travers de deux exemples détaillés : 2 erreurs à éviter pour des solutions fiables et évolutives)...

… sur la scalabilité, en s’assurant que nos bases de données ne soient pas “trop” divergentes en taille ou encore que la maintenance de premier niveau (ajouter une fonctionnalité de plus par exemple, ou un utilisateur supplémentaire) puisse être assurée par l'utilisateur métier. … sur la fiabilité, en questionnant la robustesse de la donnée tout au long du scénario via 6 questions clés. (1) Que se passe-t-il si mes données d'entrée changent ? (2) Est-ce que je maîtrise leur format et leur qualité ? (3) Comment se comporte mon scénario lorsque les données d'entrée sont vides ? (4) Est-ce que si je relance deux fois de suite mon scénario, le comportement réalisé sera celui souhaité ? (5) Comment m'assurer que tous les cas que je souhaite traiter le seront ? (6) Ai-je le moyen de surveiller et capter lorsqu’une entrée n'a pas été traitée alors qu'elle aurait dû l'être ?

Kanban de monitoring des erreurs Make

Pour une fiabilité à 100% et récupérer les erreurs non préemptées par les questions précédentes, nous avons décidé chez Gojob de mettre en place un kanban de monitoring des erreurs Make (ex-Integromat). Dès qu’une erreur apparaît, elle génère automatiquement une action dans le Kanban (voir image ci-dessus). L’objectif pour le Product Builder n’est pas seulement de corriger l’erreur mais sa source afin de ne plus l’avoir dans le futur. Sinon le Product Builder n’apprend pas et le nombre de failles dans ses scénarios augmente.

2- L’enjeu pour nos Product Builders : délivrer de l’usage et de la valeur davantage que des scénarios

Délivrer des scénarios fiables et scalables est une compétence nécessaire mais non suffisante pour nos Product Builders chez Gojob : “si je créé un scénario qui automatise la prise de rendez-vous pour les visites médicales de mes utilisateurs, mon objectif n’est pas seulement d’avoir 0 erreurs dans mes scénarios Integromat.”

En effet, l’enjeu derrière cette automatisation n’est pas seulement technique, mais plutôt de savoir si les demandes de visites médicales continuent à s’effectuer semaines après semaines (et si non pourquoi), si les utilisateurs gagnent effectivement du temps lors de chaque demande, si les utilisateurs sont satisfaits ou s’il faut de nouvelles fonctionnalités pour saisir l’impact escompté ou encore de savoir s’il faut désactiver l’automatisation car elle est devenue obsolète, etc.

Ainsi, aider les Product Builders à dépasser les enjeux techniques pour délivrer un usage et une valeur durable via le No code a été un objectif d’apprentissage et de culture Tech à instaurer pour nous chez Gojob.

3- La solution : un pilotage automatisé de l’usage des scénarios

Comment aider les Product Builders à s’assurer de la valeur durable apportée par leurs automatisations ? Chez Gojob, nous avons mis en place des débuts de solution : en leur permettant d’avoir une visualisation simple de l’usage métier derrière leurs automatisations.

Pour cela, nous avons mis en place un outil de pilotage automatisé de l’usage (métier et non technique) des scénarios. Sous la forme d’un Google Sheet, il contient l’ensemble de nos indicateurs de suivi de l’usage de nos automatisations. D’un coup d'œil, le Product Builders peut suivre les “résultats” apportés par ses automatisations.

Dashboard de suivi des indicateurs No code

Le premier onglet contient les lignes brutes des KPIs et le second (image ci-dessus) permet une visualisation synthétique et automatique de ces indicateurs semaine après semaine.

Pour les visites médicales, savoir le nombre de rendez-vous de visites médicales prises par semaine et la satisfaction associée à l’outil permet (1) de détecter des situations inhabituelles qui ne seraient pas remontées par une gestion d’erreur (0 rdv pris en une semaine, est-ce normal), (2) de suivre les tendances long terme et les besoins de fonctionnalités sur l’outil, (3) de savoir quand désactiver l’automatisation si nécessaire.

4- Le moyen : un monitoring automatisé de chaque scénario

(1) Module de suivi d’indicateurs dans les scénarios Make

Pour alimenter notre outil de suivi de ces indicateurs métier, nous incluons (en plus de la gestion d’erreur que vous pouvez apercevoir dans les modules du bas du scénario) un module sur Make qui ajoute une ligne dans notre Google Sheet de suivi. Chaque ligne ajoutée dans l’onglet “raw data” contient (image ci-dessous) le nom de l’indicateur, la semaine concernée et le nombre associé à l’indicateur.

(2) Alimentation de l’outil de suivi des indicateurs No code

A partir des données brutes, nous concevons notre dashboard de suivi de ces indicateurs sur un second onglet qui agrège les données brutes à partir de formules à base de “SOMME.SI”.

(3) Création du dashboard synthétique de suivi des indicateurs

Chaque semaine, nos Product Builders s’appuient sur ce dashboard pour consulter l’usage et les performances de leurs automatisations et prendre si besoin des actions en conséquence.

Cette première version de pilotage de l’activité No code basé sur la Data ayant montré ses preuves, nous cherchons désormais à en implémenter une v2 qui passerait par un outil nativement conçu pour le monitoring (exemple Grafana…) en lieu et place de notre première version basée sur Google Sheet. Des idées à nous partager ?


Si vous souhaitez plus d’informations sur ces bonnes pratiques No code, n’hésitez pas à contacter l’équipe !