Une demande d’achat affiche « validation niveau 2 en attente ». La demandeuse ne sait pas qui doit agir, le manager ignore pourquoi le niveau 1 a accepté et la finance découvre qu’une délégation a expiré. Après cinq jours, un administrateur remplace directement l’état par « approuvé ». La commande part, mais aucune preuve ne permet d’expliquer l’autorité qui a réellement engagé l’entreprise.
Les workflows multi-niveaux deviennent illisibles lorsqu’ils recopient la hiérarchie, empilent des seuils et utilisent un numéro comme seul vocabulaire. Ils se rigidifient aussi lorsque chaque exception ajoute une branche. L’équipe finit par autoriser des sauts administrateur, précisément au moment où la décision demande le plus de traçabilité.
Le vrai enjeu est de protéger une décision par les bonnes autorités, pas d’accumuler des approbations. Chaque étape doit répondre à un risque distinct, produire un verdict et laisser une sortie. Contre-intuitivement, deux validations parallèles et indépendantes peuvent être plus lisibles que trois niveaux séquentiels, si le métier comprend qui juge budget, conformité et nécessité.
Dans une démarche de développement web sur mesure, le workflow relie règles, rôles, données et reprise. Ce guide détaille les modèles, l’interface, les exceptions et le run afin que chaque dossier reste explicable même après une absence, une réponse perdue ou une modification de seuil.
Partir de la décision à protéger
Nommer le risque couvert par chaque validation
Une approbation peut contrôler budget, conformité, sécurité, capacité ou cohérence commerciale. Si deux étapes répondent à la même question avec les mêmes informations, l’une est peut-être inutile. L’équipe écrit entrée, critère, autorité, verdict et conséquence avant de dessiner les flèches.
La gravité, la réversibilité et la détectabilité commandent le contrôle. Une remise facilement annulable n’exige pas la même preuve qu’un virement. Une étape supplémentaire n’est pas automatiquement plus sûre : elle peut diffuser la responsabilité jusqu’à ce que chacun suppose que l’autre a vérifié.
Définir les sorties, y compris le refus
Chaque étape accepte, refuse, demande une information ou escalade selon des règles claires. Un refus possède motif et prochaine action. « Rejeté » sans possibilité de correction pousse à recréer la demande et perd l’histoire. Une demande modifiée revient aux autorités réellement affectées, pas systématiquement au début.
Modéliser étapes, règles et verdicts
Le dossier de validation possède identifiant, ressource, version, politique applicable et décisions. Une étape est une instance liée à un rôle, une échéance et un ensemble de preuves. Le verdict est immuable ; une correction produit une nouvelle décision reliée. L’état courant se calcule depuis les étapes sans écraser leur chronologie.
La politique est versionnée et datée. Une demande ouverte conserve la politique qui la gouverne, sauf migration explicite. Changer un seuil ne doit pas modifier silencieusement les dossiers en attente. Le produit indique si une nouvelle règle s’applique aux créations, aux reprises ou à tous les dossiers après une décision métier.
Séparer statut métier et statut de transport
Une approbation peut être attendue tandis qu’une notification est en retry. L’utilisateur voit l’attente métier ; l’exploitation voit la panne de distribution. Une notification perdue ne crée pas une seconde étape. Le même identifiant corrèle message, décision et ressource.
Attribuer l’autorité sans copier l’organigramme
Le workflow demande une capacité dans un périmètre, pas un nom figé. « Approbateur budget de la filiale » survit mieux qu’une personne. La résolution du titulaire tient compte des délégations et dates. Si aucun titulaire n’existe, le dossier crée une exception visible plutôt que d’attendre dans une boîte vide.
La séparation des fonctions empêche l’auteur de valider sa propre demande lorsque le risque l’exige. Un rôle technique n’accorde pas automatiquement l’autorité métier. Les permissions sont vérifiées au moment du verdict sur le serveur, conformément aux principes de validation systématique de l’OWASP Authorization Cheat Sheet.
Garder les délégations bornées
Une délégation porte capacité, périmètre, début, fin et motif. Elle peut exiger une seconde validation pour les montants sensibles. Son expiration n’annule pas les décisions déjà prises, mais empêche les nouvelles. Les accès temporaires et comptes partagés ne remplacent pas ce modèle.
Choisir séquence, parallèle ou quorum
La séquence convient lorsqu’une décision prépare réellement la suivante : le métier confirme le besoin, puis la finance engage le budget. Le parallèle convient lorsque les autorités examinent des risques indépendants. Il réduit l’attente mais demande une règle si l’une refuse pendant que l’autre accepte.
Un quorum sert une décision collective, à condition de définir population, abstention, égalité et expiration. « Deux avis sur trois » reste incomplet si les trois personnes n’ont pas la même autorité. Le verdict doit expliquer qui était éligible à la date du vote.
Éviter les branches par exception
Une variation légitime devient une politique ou une étape conditionnelle nommée. Une anomalie rejoint une file de correction. Une dérogation crée un dossier d’exception avec preuve. Ajouter une flèche pour chaque client ou pays transforme le workflow en catalogue impossible à tester.
Borner portée, durée et délégation
Un verdict s’applique à une ressource, une version et parfois une période. L’approbation d’un plafond ne vaut pas pour toute modification future. Si les champs déterminants changent, le système invalide ou rouvre les étapes concernées. La matrice nomme ces dépendances.
Les autorisations permanentes sont distinguées des décisions ponctuelles. Un manager peut approuver dans un périmètre, tandis qu’une dérogation ne vaut que pour une commande. L’écran montre cette portée avant confirmation. Une décision trop large est refusée ou scindée.
Versionner les preuves
Le document, le montant et le contrat vus par l’approbateur sont figés ou référencés avec leur version. Une modification concurrente déclenche un conflit. L’interface ne présente pas la valeur actuelle comme celle qui a fondé une décision ancienne.
Expliquer état et prochaine validation
Le dossier affiche le but, les étapes nécessaires, les verdicts obtenus, le rôle attendu et l’échéance. Il ne révèle pas les détails sensibles aux personnes non autorisées. « En attente de conformité Europe » est plus utile que « niveau 3 ». La cause et l’action restent proches.
L’approbateur voit les données qui changent son verdict, les avis précédents et les conséquences. Il peut demander une information sans choisir un faux refus. Après décision, le résultat est annoncé et la prochaine étape est visible. Une réponse asynchrone ne doit pas inviter à cliquer deux fois.
Montrer le parallélisme sans diagramme technique
Des groupes indiquent budget et conformité en cours, acceptés ou refusés. La page résume la règle de clôture. Le diagramme complet peut rester dans l’administration ou la documentation ; l’utilisateur reçoit une progression orientée vers son action.
Cas concret : approuver un achat exceptionnel
Cas hypothétique : un site industriel demande un équipement au-dessus de son plafond. La politique exige besoin métier, budget régional et sécurité. L’ancien workflow lance trois niveaux dans l’ordre et attend douze jours. La sécurité découvre tardivement que la fiche technique manque.
La cible vérifie la complétude avant entrée. Le manager confirme le besoin, puis budget et sécurité travaillent en parallèle. Une délégation régionale expire après deux semaines. Si la référence ou le montant change, les étapes affectées sont rouvertes avec motif ; l’avis métier reste valable si sa question n’a pas changé.
Le pilote couvre vingt demandes, dont quatre refus, trois modifications et une absence. Les seuils locaux exigent zéro décision sans autorité, zéro commande créée deux fois et une attente sans titulaire détectée avant l’échéance. Le support doit reconstruire la politique, les preuves et le verdict depuis l’identifiant d’achat.
Relire le verdict et son effet
Par exemple, si le budget accepte mais que la sécurité refuse, alors aucune commande n’est créée et le dossier revient avec les conditions de correction. Si la réponse du fournisseur se perd après création, le retry retrouve la commande par sa clé idempotente au lieu d’en produire une seconde.
La preuve de lisibilité vient d’une revue avec quatre demandeurs et trois approbateurs, pas du seul délai moyen. Chacun doit nommer la prochaine autorité, la donnée encore attendue et l’effet d’une modification de montant sans ouvrir la documentation technique. Sur les vingt demandes du pilote, toute erreur sur ces trois questions suspend l’extension et déclenche une correction du libellé ou de la politique. Ce seuil local est volontairement strict parce que l’achat crée un engagement financier ; un workflow consultatif pourrait accepter un autre niveau de contrôle.
Traiter refus, absence et changement
Un refus final ferme la décision mais n’efface pas les avis. Une correction crée une nouvelle version de demande. Une absence déclenche délégation ou escalade selon la politique. Un rôle sans titulaire est un incident de gouvernance, pas un motif pour accorder un admin global.
Une dépendance indisponible peut suspendre l’étape avec un mode dégradé décidé : attendre, utiliser une preuve alternative ou refuser. Le délai et le propriétaire sont visibles. Un bouton « forcer » n’est jamais la stratégie générale.
Réconcilier les effets
La balance rapproche validations terminales, commandes créées, refus et compensations. Toute décision sans effet attendu ou effet sans décision rejoint une file. Une correction est traçable et ne modifie pas directement l’état pour faire disparaître l’écart.
Mettre en œuvre un moteur reprenable
Contractualiser entrées et sorties
Les entrées sont ressource, version, politique, acteur et preuves ; les sorties sont étapes, verdicts et commande suivante. Les dépendances sont explicites. La journalisation conserve règle, corrélation et délégation. L’instrumentation relie chaque décision à l’effet.
Le monitoring suit attentes, rôles absents, conflits, notifications, retries et écarts de balance. Le runbook attribue les responsabilités. Un rollback ferme une nouvelle politique sans effacer les verdicts valides. Le retry idempotent retourne la décision existante.
Implémenter les transitions sans exposer le moteur
Le composant Workflow de Symfony fournit places, transitions, guards et événements. Le domaine nomme les décisions en vocabulaire métier. Les tests unitaires couvrent politiques et invariants ; les tests d’intégration provoquent concurrence, réponse perdue et message hors ordre.
Dans l’application PHP, l’API reçoit l’identifiant, la version et la commande de verdict. Le service Symfony recharge la politique applicable et Doctrine verrouille la version avant d’écrire décision et message de boîte de sortie. Un worker publie l’effet ; sa clé d’idempotence empêche une seconde commande d’achat. Le cache sert uniquement la lecture et ne décide jamais de l’autorité. La CI exécute les scénarios par version de politique, puis le déploiement active le nouveau graphe pour une entité. Logging, instrumentation et monitoring relient demande, transition, retry et effet ; le runbook donne les responsabilités et le repli.
Mesurer attentes et qualité des décisions
Le tableau suit temps par étape, dossiers sans titulaire, demandes d’information, refus, réouvertures et corrections. La moyenne masque les longues attentes ; les distributions et causes restent visibles. Une étape rapide qui provoque davantage de reprises n’est pas efficace.
Chaque mesure déclenche une action : retirer une étape redondante, améliorer la complétude, revoir la délégation ou financer une capacité. Le comité n’ajoute pas de niveau pour répondre à un incident isolé. Il vérifie d’abord règle, preuve et responsabilité.
Arbitrer délai, preuve et indépendance
Les arbitrages restent explicites. Paralléliser budget et sécurité réduit l’attente, mais augmente le nombre d’avis à invalider si un champ déterminant change. Un quorum accélère une décision, mais n’est pertinent que si les autorités couvrent le même risque ; il serait trompeur entre finance et sécurité. Une relance automatique améliore la visibilité, mais ne remplace ni titulaire ni délégation. Le tableau met donc côte à côte délai gagné, réouvertures et décisions infirmées, afin que la vitesse ne masque pas la qualité.
La gouvernance conserve également le motif des demandes d’information. Si la même pièce manque dans plusieurs dossiers, l’équipe déplace le contrôle avant l’entrée plutôt que d’accélérer les relances. Si un approbateur rend presque toujours le même verdict sans utiliser de donnée propre, alors son étape est revue : elle peut devenir un contrôle automatisé, un avis facultatif ou disparaître. En revanche, un faible taux de refus ne suffit pas à supprimer une autorité qui couvre un risque rare et majeur. La décision combine fréquence, impact et capacité de détection.
Ces évolutions sont versionnées comme le workflow. Le comité compare une période avant et après avec les mêmes populations, puis recherche les décisions rouvertes ou corrigées. Une réduction de deux jours n’est retenue que si les preuves et les effets restent réconciliés. Ce cadre évite d’optimiser un délai visible au prix d’un travail de réparation reporté sur les achats, la comptabilité ou le support.
Pour qui ce workflow devient-il nécessaire ?
Il concerne achats, remises, contrats, accès, conformité et autres décisions où plusieurs autorités couvrent des risques distincts. Produit, métier, finance, sécurité, développement, support et exploitation participent.
Une petite décision réversible peut rester à un niveau. Lorsque montant, droits, séparation de fonctions ou multi-entités apparaissent, le modèle devient utile. Le nombre de managers ne justifie pas seul une chaîne ; la conséquence et l’indépendance des contrôles commandent.
Erreurs fréquentes des validations
La première erreur copie l’organigramme. La deuxième numérote les niveaux sans nommer le risque. La troisième relance tout après chaque modification. La quatrième laisse une délégation sans fin. La cinquième autorise un saut admin. La sixième confond notification et décision.
Autres pièges : séquence inutile, quorum mal défini, refus sans correction, politique non versionnée ou preuve actuelle affichée pour une ancienne décision. Enfin, ajouter un approbateur ne compense pas une donnée absente.
Décider du niveau de contrôle
Bloc de décision. Ajoutez une étape si elle couvre un risque distinct avec une autorité et un verdict. Lancez en parallèle les contrôles indépendants. Gardez en séquence les décisions réellement dépendantes. Automatisez un contrôle déterministe, mais conservez preuve et explication. Retirez une étape si personne n’utilise son verdict.
- Nommer le risque avant le rôle.
- Borner portée, durée et champs déterminants.
- Tester refus, absence, modification et retry.
- Refuser tout contournement sans décision explicite.
Le coût complet inclut attente, support, maintenance et friction. Une validation apporte de la valeur si elle change une décision ou réduit un risque, pas parce qu’elle rassure visuellement.
Plan d’action sur six semaines
Semaines 1 et 2 : cartographier les décisions
Rejouez vingt dossiers acceptés, refusés et modifiés. Pour chaque étape, notez risque, données, autorité, verdict et effet. Identifiez doublons, validations de confort et rôles absents. Écrivez les politiques et leurs champs déterminants.
Semaines 3 et 4 : prototyper et perturber
Construisez un parcours avec contrôle initial puis deux branches parallèles. Testez auteur, délégation, refus et demande d’information. Provoquez modification concurrente, notification perdue et approbateur absent. Le support suit la chronologie.
Semaines 5 et 6 : intégrer et ouvrir
Branchez les effets via boîte de sortie et idempotence. Ajoutez monitoring, balance et runbook. Ouvrez à une entité, observez un cycle et exécutez le rollback de politique. Les seuils de poursuite sont qualifiés avec les métiers.
Le bilan vérifie temps par étape, refus utiles, dossiers sans titulaire et corrections directes. D’abord, fermer l’autorité ; ensuite, stabiliser la preuve ; puis étendre. Si le verdict dépend encore d’un message privé, le workflow revient en cadrage.
La revue de passage réunit achat, finance, sécurité, support et exploitation autour de cinq chronologies tirées au sort. Pour chacune, elle vérifie la version de politique, les champs déterminants, le mandat de l’approbateur, le verdict et l’effet terminal. Elle compare aussi une demande nominale, un refus, une modification, une absence et une réponse perdue. Les dépendances, seuils, responsabilités de reprise et conditions de rollback sont consignés. Le groupe suivant ne s’ouvre que si aucune décision orpheline ne subsiste et si le support peut expliquer le dossier sans accès administrateur global.
- Nommer chaque risque et chaque verdict.
- Choisir ordre, parallélisme et délégation.
- Tester exceptions, reprise et effets.
- Étendre depuis les décisions réellement explicables.
Guides complémentaires pour les workflows
Rendre les règles visibles
Le guide de visibilité des règles structure états, causes et prochaines actions.
Traiter les dérogations
La gestion des exceptions évite que les validations rares envahissent le nominal.
- Une étape protège un risque distinct.
- Un verdict garde preuve et portée.
- Une reprise ne fabrique pas une seconde décision.
Conclusion : rendre l’autorité explicable
Un workflow multi-niveaux reste lisible quand chaque étape porte une question, une autorité et un verdict. La séquence exprime une dépendance réelle ; le parallèle protège des risques indépendants ; les délégations restent bornées.
La version de politique, les preuves et l’idempotence maintiennent la chronologie. Les exceptions, refus et changements possèdent une sortie. Le support reconstruit la décision sans saut administrateur.
Dawap peut accompagner ce cadrage et son implémentation dans une stratégie de développement web sur mesure. L’objectif est que chaque personne sache qui décide, sur quelle preuve et comment reprendre sans rendre l’autorité opaque.
