Automatisation en entreprise : quand une règle ne doit PAS partir

Presque tous les textes sur l’automatisation expliquent ce qu’une règle peut déclencher. La question difficile est l’inverse : quand vaut-il mieux qu’elle ne fasse rien. Une règle qui part trop souvent écrit à des clients qui n’attendent rien, et deux semaines plus tard quelqu’un la désactive. Voici la structure qui l’évite, et comment savoir ensuite si une règle travaille vraiment ou en donne seulement l’air.

Une règle tient en quatre morceaux

Le nom. C’est la partie la plus sous-estimée. Dans six mois, il figurera dans une liste avec vingt autres, et celui qui le lira devra comprendre sans réfléchir ce que fait la règle. « Notification 3 » ne le dit pas.

L’événement. Une règle n’attend pas une heure : elle attend qu’il se passe quelque chose dans l’activité, à savoir qu’un enregistrement soit créé, modifié ou supprimé. Avec l’événement va l’endroit : « un ticket est ouvert » n’est pas la même chose que « un devis change ».

Les conditions. Le cœur, et la partie qu’on saute le plus volontiers. Sans condition, la règle part à chaque événement. Avec « priorité égale à haute », elle part sur les tickets qui comptent. La différence entre une automatisation utile et une automatisation qu’on finit par éteindre se joue presque toujours là.

Les actions. Ce qui se passe ensuite : un e-mail, un avis à l’équipe, un message WhatsApp, une tâche, un champ mis à jour, une ligne dans l’historique. Plusieurs à la suite sont permises.

Avant de l’activer : l’essai à vide

Avant qu’une règle ne passe en production, elle mérite un essai à vide. L’essai évalue les conditions et indique si elles auraient été remplies et combien d’actions seraient parties, sans que personne ne reçoive quoi que ce soit. C’est le bouton qui enlève la peur d’activer, et la seule façon sérieuse de tester une règle qui envoie des e-mails à de vrais clients.

Pourquoi « ignorée » n’est pas une panne

Au bout de quelques jours, la question intéressante n’est plus de savoir si la règle est active, mais ce qu’elle a réellement fait. Cela demande un journal, et ce journal doit distinguer trois issues :

• Réussie — le travail est fait : l’e-mail est parti, l’avis est arrivé.
• Ignorée — l’événement était là, mais la condition n’était pas vraie, ou l’enregistrement n’avait tout simplement pas l’information (un ticket pris par téléphone, sans adresse e-mail du client). La règle ne devait pas partir.
• Erreur — quelque chose a mal tourné, et la raison est écrite : aucun destinataire indiqué, identifiants invalides, un champ qu’une automatisation ne peut pas modifier.

Beaucoup de systèmes ne connaissent que « exécutée » et « échouée ». Résultat : le journal d’une règle parfaitement saine se remplit de lignes rouges parce que la condition n’était pas remplie sur vingt tickets, et la seule vraie erreur au milieu n’est plus visible pour personne. Quand vous évaluez un logiciel, posez précisément cette question : une condition non remplie est-elle présentée comme une décision ou comme une panne ?

Ce qu’une automatisation ne devrait pas toucher

Une règle autorisée à écraser n’importe quel champ est un risque, pas un outil. Ce qui fonctionne, c’est une liste fixe de champs modifiables : statut, responsable, priorité, une note. Les totaux, les stocks, les valeurs comptables et les clés n’en font pas partie : ceux-là, c’est une personne qui les change, ou une opération avec un document derrière.

Tout aussi important : une règle qui écrit ne doit pas pouvoir se déclencher elle-même. Sans frein, une automatisation qui met à jour un champ se rappelle en boucle sans fin.

L’approche de Blina Desk

Dans Blina Desk, les quatre étapes se remplissent sur un seul écran, dans cet ordre, avec l’essai à vide à la fin. Les actions forment une liste fermée plutôt qu’un accès libre à la base de données, et les champs modifiables sont arrêtés d’avance.

Le journal sépare réussie, ignorée et erreur, avec le motif écrit en clair : on voit d’un coup d’œil si une règle ne travaille pas ou si elle n’avait tout simplement pas à le faire. Et comme les automatisations appartiennent à l’entreprise et non à une personne, c’est la direction qui décide quelles règles sont actives et qui peut les adapter.

Au bout du compte, le test de tout logiciel d’automatisation est le même : non pas le nombre de modèles livrés, mais votre capacité, deux mois plus tard, à comprendre encore pourquoi une règle n’est pas partie un mardi matin.