Un workflow d’approbation indique qui peut décider, dans quel état se trouve la demande et quelles règles s’appliquent quand le dossier change.
Une approbation par courriel devient difficile à suivre dès que plusieurs personnes interviennent. Le message peut rester sans réponse, un fichier peut être remplacé ou deux responsables peuvent prendre des décisions différentes. Un workflow dans le logiciel rend l’état visible et conserve les éléments nécessaires à la suite du traitement.
Le workflow ne doit pas reproduire toute l’organisation de l’entreprise. Il doit représenter les décisions qui bloquent une action ou qui créent une responsabilité. Commencez par un parcours concret, comme la validation d’un devis, d’une dépense ou d’une demande d’achat.
Décrire les états et les transitions
Listez les états réellement utiles : brouillon, soumis, en revue, approuvé, refusé et annulé peuvent suffire pour un premier parcours. Pour chaque transition, indiquez l’action, le rôle autorisé et le résultat produit. Une demande refusée peut-elle être corrigée et soumise à nouveau ? La réponse doit apparaître dans la règle.
Évitez de multiplier les états qui ne changent aucun comportement. Un état visible doit expliquer ce que l’utilisateur peut faire ensuite. Si deux états donnent les mêmes droits et les mêmes messages, réunissez-les ou documentez la différence métier.
Le workflow doit aussi préciser les conditions d’entrée. Un devis incomplet ne devrait pas apparaître dans la file d’approbation. Le serveur vérifie ces conditions au moment de la soumission, même si l’interface les contrôlait déjà.
Choisir les approbateurs
L’approbateur peut être une personne, un rôle, une équipe ou le responsable du dossier. Une règle fondée sur une liste de personnes doit prévoir le remplacement lors d’une absence ou d’un départ. Une règle fondée sur un rôle doit indiquer ce qui arrive lorsqu’aucun membre ne remplit ce rôle.
Les seuils de montant peuvent conduire vers des approbateurs différents. Écrivez la règle avec des bornes sans ambiguïté, notamment lorsque le montant est égal au seuil. Si le montant change pendant la revue, le logiciel doit recalculer la décision ou bloquer la modification jusqu’à une nouvelle soumission.
Un approbateur ne devrait pas valider son propre dossier lorsque la séparation des rôles l’interdit. Contrôlez le lien entre le créateur, le bénéficiaire et la personne qui décide. Une exception peut exister, mais elle doit être visible et journalisée.
Gérer les commentaires et les pièces
Une décision peut exiger une justification. Demandez un commentaire lorsque le refus ou la demande de correction doit être compris par l’équipe suivante. Évitez de rendre un commentaire obligatoire pour chaque clic si personne ne le lit ensuite.
Les pièces jointes doivent être liées à la version soumise. Si l’utilisateur remplace un document pendant la revue, créez une nouvelle version et remettez le workflow dans un état cohérent. Un approbateur doit savoir quel fichier il accepte, avec sa date et son identifiant.
Les données affichées doivent correspondre à celles contrôlées par la règle. Un total calculé à l’écran mais modifié à l’enregistrement crée une approbation sans valeur. La validation côté serveur doit recalculer les valeurs sensibles et conserver le résultat retenu.
Prévoir les actions répétées et concurrentes
Un utilisateur peut cliquer deux fois ou relancer une demande après un délai réseau. La transition doit être idempotente lorsque cela est possible. Le système doit produire un seul changement d’état et une seule notification pour la même action métier.
Deux approbateurs peuvent ouvrir la demande en même temps. Le premier peut approuver alors que le second tente de refuser. Vérifiez l’état enregistré avant chaque transition et affichez un message clair lorsque la décision est déjà prise. Ce scénario rejoint les contrôles de concurrence et les critères de recette utilisateur.
La notification peut arriver après la décision. L’écran doit afficher l’état actuel et la date de traitement. Une alerte ancienne ne doit pas permettre d’appliquer une transition devenue invalide.
Suivre les délais et les relances
Une file d’approbation doit montrer l’âge de chaque demande, son responsable et la prochaine action. Les relances peuvent être automatiques, mais leur fréquence doit rester raisonnable. Indiquez quand une relance a été envoyée et évitez de créer une nouvelle demande à chaque tentative.
Un délai dépassé ne signifie pas toujours un refus. Le système peut relancer, réassigner ou escalader selon la règle choisie. Une personne autorisée doit pouvoir reprendre une demande bloquée, avec une trace de l’intervention.
Les indicateurs utiles sont le nombre de demandes en attente, l’âge de la plus ancienne et la durée entre soumission et décision. Séparez les délais dus à une donnée incomplète des délais d’attente d’un approbateur. Une moyenne unique donne peu d’aide pour agir.
Tester le parcours complet
Préparez des cas pour chaque rôle, seuil, refus, correction et absence d’approbateur. Testez la modification du dossier pendant la revue, l’indisponibilité du service de notification et la répétition d’un clic. Vérifiez les écrans, les emails, les journaux et les exports.
Le journal d’audit doit permettre de retrouver la soumission, la décision et les changements de version. Les droits doivent empêcher une personne de lire ou modifier un dossier auquel elle n’est pas rattachée.
Un workflow réussi décrit une décision que les équipes prennent déjà, puis rend son état, son responsable et son historique accessibles. Chaque règle ajoutée doit faciliter une action ou éviter une ambiguïté observable.
Sources : Atlassian, critères d’acceptation, OWASP, autorisation.