Workflow d'approbation : choisir entre une machine a etats generique et du code dedie

SOMMAIRE

1. Introduction
   1. Le workflow des demandes de partenariat
   2. Pourquoi les demandes d'adhesion ne suivent pas ce modele
   3. Ce qu'un Workflow generique aurait coute ici
   4. Le meme arbitrage chez les acteurs specialises du workflow
2. Conclusion
3. Voir aussi

1. Introduction

Des qu'un processus metier demande une approbation (une demande qui passe par plusieurs statuts avant d'etre acceptee ou refusee), une question de conception se pose : faut-il modeliser ce processus avec un moteur de workflow generique (une machine a etats), ou ecrire du code dedie pour cette approbation precise ? C'est un arbitrage classique en conception logicielle, que l'on retrouve aussi bien face aux moteurs de workflow generiques inclus dans certains frameworks que face a des outils dedies comme les machines a etats gerees (par exemple AWS Step Functions) ou les moteurs de business process management (comme Camunda). La reponse depend de ce que l'approbation doit reellement accomplir, pas uniquement de la disponibilite d'un outil generique dans la pile technique utilisee.

Frappe, le framework libre sur lequel repose la plateforme IREX, propose justement un objet natif pour ce genre de besoin : le Workflow. Il definit des etats, des actions qui font passer un document d'un etat a l'autre, et les roles autorises a declencher chaque action. Habituellement, un tel workflow se cree une fois dans l'interface d'administration, puis s'exporte comme fixture qui s'installe automatiquement sur chaque nouvel environnement. Sur la plateforme IREX, aucune fixture de ce type n'existait a copier. Cet article explique comment ce workflow a ete construit directement en code, et pourquoi un processus d'approbation different, celui des adhesions, ne suit pas du tout le meme modele, une illustration concrete de la question de conception posee plus haut.

1.1 Le workflow des demandes de partenariat

Une demande de partenariat suit quatre etats possibles, avec des transitions precises entre eux.

Image 1 : les etats et transitions du workflow Demande Partenaire.

Plutot que de creer ce workflow une fois via l'interface graphique puis d'esperer que l'export et l'import de la fixture fonctionnent correctement sur chaque environnement, l'ensemble de sa definition (etats, actions, transitions, roles autorises) est ecrit directement en code, sous forme de listes simples, et applique automatiquement a chaque migration du site. Cette fonction commence par verifier si le workflow existe deja avant de recreer quoi que ce soit.

Cette verification est ce qui rend l'operation sure a repeter. Sans elle, chaque migration ulterieure tenterait de recreer le meme workflow et echouerait, ou pire, creerait des doublons. Le resultat final se comporte exactement comme un workflow cree a la main dans l'interface : les boutons d'action apparaissent dans l'interface d'administration, les transitions non autorisees sont bloquees, l'historique des changements d'etat est conserve par le framework lui-meme.

1.2 Pourquoi les demandes d'adhesion ne suivent pas ce modele

Il serait naturel de supposer qu'une demande d'adhesion, elle aussi une forme de demande a approuver, suit le meme mecanisme de Workflow. Ce n'est pas le cas. Son approbation passe par une fonction dediee, appelee directement par le bouton "Approuver" de l'interface de gestion des adhesions, qui modifie un simple champ de statut.

Ce choix n'est pas un raccourci mais une consequence directe de ce que l'approbation d'une adhesion doit accomplir, bien au-dela d'un changement d'etat : activer le compte utilisateur, verifier qu'un paiement en attente a bien ete confirme, provisionner un compte Keycloak, envoyer un courriel de bienvenue different selon le cas. Un objet Workflow generique sait faire passer un document d'un etat a l'autre, mais ne sait pas naturellement enchainer une sequence d'actions metier aussi specifique. Le code dedie permet d'ecrire cette sequence explicitement, avec ses propres verifications a chaque etape, la ou un Workflow generique aurait demande des detours bien plus complexes pour le meme resultat.

1.3 Ce qu'un Workflow generique aurait coute ici

Forcer l'approbation d'une adhesion dans un objet Workflow classique serait techniquement possible, mais au prix d'un contournement pour chaque effet de bord necessaire. Un Workflow ne fait qu'ecrire une nouvelle valeur dans le champ d'etat du document, il ne sait pas nativement appeler une API externe comme Keycloak, ni verifier une condition metier comme un paiement confirme avant d'autoriser une transition. Il aurait fallu ajouter un second hook a cote du Workflow pour porter cette logique, exactement le mecanisme deja utilise pour les partenariats, mais desormais duplique et desynchronise du systeme de transitions lui-meme : le Workflow autoriserait ou bloquerait un changement d'etat sur des criteres de roles, pendant qu'un code separe deciderait, lui, si le paiement a reellement ete confirme. Deux sources de verite pour une seule decision d'approbation, c'est precisement le genre de complexite que le choix d'une fonction dediee evite des le depart.

Image 2 : les deux approches cote a cote, chacune adaptee a un besoin different.

1.4 Le meme arbitrage chez les acteurs specialises du workflow

Cet arbitrage n'est pas propre a Frappe ni a IREX. AWS Step Functions, le service d'orchestration de workflows d'Amazon Web Services, existe justement parce que des equipes entieres ont besoin d'un moteur de machine a etats dedie, avec ses propres outils de visualisation et de reprise sur erreur, des que l'orchestration depasse un simple changement de statut.

Image 3 : schema officiel d'une machine a etats AWS Step Functions, avec un etat de decision (Choice state) qui aiguille l'execution vers des taches differentes selon la condition. Source : docs.aws.amazon.com.

Camunda, un moteur de gestion de processus metier (BPM) largement utilise en entreprise, illustre l'autre bout du spectre avec un exemple publie directement comparable au cas des demandes de partenariat : un processus d'approbation a deux etages, avec des points de decision explicites entre chaque etape.

Image 4 : exemple officiel Camunda d'un processus d'approbation a deux etages ("four eyes principle"), avec des points de decision explicites entre chaque etape d'approbation. Source : camunda.com.

2. Conclusion

Le workflow des partenariats convient parce que ses transitions sont simples et son besoin est essentiellement celui d'une machine a etats classique. L'approbation des adhesions, elle, declenche une chaine d'effets de bord qui depasse largement un changement de statut. Utiliser l'objet Workflow pour le premier cas et une fonction dediee pour le second n'est pas une incoherence dans la plateforme, mais le reflet de deux besoins reellement differents, chacun traite avec l'outil qui lui correspond. Le principe se generalise a toute conception d'approbation : la disponibilite d'un outil generique dans un framework ne dispense pas de se demander si le besoin reel s'y prete.

3. Voir aussi

• Integration SSO : provisionner automatiquement un compte d'identite lors d'une approbation metier
• Architecture multi-applications : mutualiser une base technique entre plusieurs applications independantes