Le vrai coût d'une erreur détectée trop tard
Une commande qui part alors qu'elle n'aurait pas dû ne coûte pas seulement le temps de la corriger. Elle mobilise plusieurs personnes, elle abîme la relation avec le client à qui il faut expliquer le rétropédalage, et selon le sujet elle vous expose contractuellement.
Le même contrôle, effectué au moment de la saisie, coûte une seconde à l'utilisateur. C'est tout l'intérêt d'un Flow de validation : il déplace le contrôle du moment où l'on répare vers le moment où l'on saisit.
Le contrôle a posteriori a un défaut structurel : il repose sur quelqu'un qui doit y penser. Le jour où cette personne est absente, débordée ou vient d'arriver, le contrôle n'a pas lieu. Une règle inscrite dans l'outil, elle, ne prend pas de congés.
Règle de validation ou Flow, comment choisir
Les deux savent refuser un enregistrement avec un message. Ils ne jouent pas dans la même catégorie, et prendre le mauvais coûte du temps.
La règle de validation est la solution la plus simple dès que le contrôle ne dépend que des champs présents sur l'enregistrement, et éventuellement de son parent immédiat. Elle est rapide, lisible, et il n'y a aucune raison de s'en priver. Refuser une remise supérieure à un seuil, exiger une date de livraison postérieure à la date du jour, imposer un champ selon le type d'enregistrement : c'est son domaine.
Le Flow devient nécessaire dès que la règle dépend d'informations situées ailleurs. Une matrice d'autorisations tenue dans un objet dédié, une vérification sur les lignes de la commande plutôt que sur son en-tête, un contrôle qui croise plusieurs enregistrements liés. Une règle de validation ne sait pas parcourir des données lointaines, un Flow de validation le fait sans difficulté.
Un signal simple : si votre formule de validation commence à ressembler à un programme, vous êtes déjà dans le domaine du Flow.
Le principe qui fait tout tenir, mettre les règles dans les données
C'est le point sur lequel je ne transige pas, et c'est celui qui distingue un dispositif qui vit d'un dispositif qu'il faudra reprendre.
La tentation est d'inscrire les règles dans l'automatisation elle-même : telle marque interdite vers tel pays, écrit en dur dans une condition. Cela fonctionne parfaitement le premier jour. Puis un accord de distribution change, et il faut un intervenant technique pour une modification qui n'a rien de technique.
La bonne architecture stocke les règles dans un objet de paramétrage, une simple table que l'équipe métier tient elle-même. Le Flow ne connaît aucune règle, il sait seulement lire cette table et comparer. Le jour où une combinaison change, quelqu'un met à jour une ligne, et le contrôle suit immédiatement.
C'est exactement le dispositif de conformité export que j'ai mis en place chez un acteur du négoce. Les couples de marque et de pays autorisés vivent dans un objet dédié, mis à jour par l'équipe sans intervention de ma part. Deux ans après, il tourne toujours, et je n'y suis jamais revenu.
Comment cela se construit, concrètement
Le dispositif tient en quatre décisions, et aucune n'est technique au point de vous échapper.
- Le moment du déclenchement. Un Flow déclenché à la création et à la modification de l'enregistrement, avant enregistrement, de façon que le refus intervienne avant toute écriture.
- Les conditions d'entrée. Le Flow ne doit s'exécuter que lorsque c'est pertinent, par exemple quand le statut passe à « à valider », et non à chaque sauvegarde. C'est ce qui évite de ralentir toutes les autres modifications.
- La lecture du paramétrage. Le Flow va chercher, dans l'objet de règles, la ligne correspondant à la situation en cours.
- Le refus, avec un message utile. Si aucune ligne n'autorise la combinaison, le Flow interrompt l'enregistrement avec une erreur personnalisée.
Ce dernier point mérite plus d'attention qu'il n'en reçoit d'habitude, parce que c'est la seule partie que vos utilisateurs verront.
Le message d'erreur est la moitié du travail
Un blocage incompris est un blocage contourné. L'utilisateur qui ne comprend pas pourquoi son enregistrement est refusé va essayer autre chose, saisir une valeur approximative pour passer, ou appeler quelqu'un. Vous aurez protégé la conformité et dégradé la donnée.
Un bon message dit trois choses : ce qui est refusé, pourquoi, et ce qu'il faut faire. « Cette combinaison de marque et de pays de livraison n'est pas autorisée par les accords en vigueur. Vérifiez le pays de livraison, ou demandez une dérogation au service commercial » vaut infiniment mieux que « Erreur de validation ».
Pensez aussi à l'endroit où le message s'affiche. Attaché au champ concerné, il pointe directement ce qu'il faut corriger. Attaché à l'enregistrement entier, il apparaît en haut de la page, ce qui convient quand le refus vient d'une combinaison plutôt que d'un champ isolé.
Prévoir les exceptions, sinon elles se feront contre vous
Aucune règle métier ne survit longtemps sans exception. Si vous ne prévoyez pas la dérogation, quelqu'un finira par la fabriquer avec les moyens du bord, en détournant un champ ou en créant un enregistrement bidon.
La bonne façon de faire tient en trois éléments. Une case de dérogation sur l'enregistrement, dont la modification est réservée à un profil précis par les droits. Un champ de motif, obligatoire dès que la case est cochée. Et un contrôle du Flow qui laisse passer la commande quand la dérogation est valide.
Vous obtenez un dispositif qui bloque par défaut, autorise l'exception à qui de droit, et garde la trace de qui a dérogé, quand, et pourquoi. C'est ce dernier point qui vous servira, le jour où quelqu'un demandera des comptes.
Ce qu'il faut tester avant d'activer
Un contrôle bloquant est l'automatisation la plus sensible qui soit : s'il se trompe, il arrête l'activité. Il se construit donc dans une sandbox, et se teste sur quatre familles de cas.
Le cas conforme, qui doit passer sans que l'utilisateur remarque quoi que ce soit. Le cas non conforme, qui doit être refusé avec le bon message. Le cas dérogé, qui doit passer et laisser une trace. Et surtout le cas des enregistrements créés autrement que par un humain : reprise de données, création par une intégration, mise à jour en masse. C'est là que les contrôles bloquants font le plus de dégâts, en arrêtant un traitement entier pour une ligne fautive.
Prévoyez enfin un chemin d'erreur : si la lecture du paramétrage échoue, décidez explicitement s'il faut bloquer ou laisser passer. Ne pas trancher revient à laisser la plateforme le faire à votre place.
Ce que ce type de dispositif change
Le bénéfice visible est la disparition des commandes non conformes. Le bénéfice qui compte est ailleurs.
Une règle inscrite dans l'outil cesse d'être une connaissance individuelle. Elle ne dépend plus de l'ancienneté d'un commercial ni de la vigilance d'un assistant. Un nouvel arrivant est protégé dès son premier jour, et l'entreprise ne perd plus cette règle quand quelqu'un s'en va.
C'est aussi un gain de qualité des données, parce qu'un contrôle à la saisie empêche l'entrée d'informations incohérentes plutôt que d'avoir à les rattraper ensuite. Un Flow de validation bien conçu ne se voit pas : il ne se manifeste que quand quelque chose ne va pas, et il dit alors exactement quoi faire.
Questions fréquentes
Règle de validation ou Flow, que choisir pour bloquer une saisie ?
La règle de validation dès que le contrôle ne dépend que des champs de l'enregistrement et de son parent immédiat : c'est plus simple et plus rapide. Le Flow devient nécessaire quand la règle dépend de données situées ailleurs, par exemple une matrice d'autorisations tenue dans un objet de paramétrage.
Comment gérer les exceptions à une règle de blocage ?
En les prévoyant dans le paramétrage plutôt que dans l'automatisation. Une case de dérogation sur l'enregistrement, réservée à un profil précis par les droits, permet de laisser passer un cas particulier tout en gardant une trace de qui a dérogé et quand.