Un acheteur prépare une commande pour trois sites. Le portail l’envoie au responsable local, puis à la direction parce que le montant dépasse un seuil. Pendant l’absence du directeur, un administrateur change le statut à « validée ». La commande part, mais personne ne sait si la règle de délégation ou le budget ont réellement été vérifiés.
Le problème touche directement le budget, la marge et la responsabilité : un faux accord engage l’entreprise, tandis qu’un faux refus immobilise l’achat et pousse les équipes à commander hors portail. Les validations par email ou compte partagé suppriment la preuve, ralentissent le support et rendent la séparation de fonctions théorique.
Les grands comptes demandent souvent plusieurs niveaux, plafonds et remplaçants. Copier leur organigramme dans une suite d’étapes crée un workflow fragile : mutations, centres de coûts, catégories et urgences modifient la décision. Une validation n’est pas un email ni un changement de statut ; c’est l’application d’une politique à une version d’un objet.
Le vrai enjeu est de rendre chaque approbation explicable, attribuable et encore valable quand l’objet est exécuté. Le produit doit savoir qui peut décider, sur quel périmètre, avec quelles informations et ce qui se passe si ces informations changent.
Un portail de développement web sur mesure relie politique, droits, notifications et run. Voici comment concevoir une chaîne qui reste lisible sans sacrifier les contrôles.
Transformer la validation en politique
Écrivez d’abord la raison : budget, sécurité, conformité, séparation de fonctions ou engagement contractuel. Une étape sans risque associé devient un délai rituel. Pour chaque politique, nommez le résultat protégé et les preuves nécessaires.
La politique reçoit une demande contextualisée et retourne étapes, valideurs éligibles, obligations et expiration. Elle est versionnée. Une évolution s’applique aux nouvelles soumissions ou selon une règle explicite ; elle ne réécrit pas silencieusement les décisions terminées.
Distinguer avis et approbation
Un avis contribue sans bloquer ; une approbation autorise une action. Une information ou un accusé ne doit pas devenir un niveau. Cette distinction réduit les files et évite qu’une personne consultée soit tenue pour responsable d’une décision qu’elle n’a pas prise.
Fermer le cycle de la politique
La fiche de politique porte propriétaire, objet, finalité, version, date d’effet, périmètres et chemin de retrait. Un changement de seuil passe sur des demandes historiques en simulation. Le métier signe les écarts attendus. Une politique remplacée reste interprétable pour l’audit, mais ne crée plus de tâches. Cette séparation évite qu’une demande ouverte bascule sans explication entre deux logiques.
La revue périodique examine étapes jamais refusées, avis toujours favorables, exceptions fréquentes et temps d’attente. Une étape peut être supprimée si elle ne change aucune décision ; un contrôle peut être rapproché de l’exécution si son information arrive tard. Le workflow évolue à partir des preuves et non des préférences hiérarchiques, tout en maintenant les responsabilités contractuelles du client.
Définir l’objet soumis
La validation porte sur une version immuable de commande, devis, budget ou demande. Le snapshot inclut lignes, montants, devise, sites, centre de coûts et pièces utiles. L’objet de travail peut évoluer, mais toute modification significative invalide ou resoumet selon la politique.
Définissez les champs significatifs. Corriger une faute de commentaire ne relance pas forcément ; changer quantité, bénéficiaire ou prix oui. Une empreinte métier permet de détecter ce changement sans confondre métadonnées et engagement.
Conserver proposition et exécution
Une approbation autorise la version soumise. L’exécution vérifie encore que cette version est active, que les droits et conditions essentielles tiennent et qu’elle n’a pas déjà été consommée. La commande exécutée référence les décisions qui l’ont autorisée.
Modéliser demandeurs et valideurs
Le demandeur agit pour un compte, un site et parfois un centre de coûts. Le valideur possède rôle, périmètre, plafond, catégories et période. Ces attributs ont une source et une fraîcheur. Le système ne déduit pas un valideur du dernier utilisateur ayant cliqué.
La séparation de fonctions empêche une personne de soumettre et approuver sa propre demande lorsque le risque l’exige. Deux comptes techniques ne représentent pas deux personnes. Les identités, délégations et actions sont attribuables.
Appliquer le moindre privilège
Le valideur ne voit que les données nécessaires à sa décision et son périmètre. Le NIST SP 800-162 sur l’ABAC décrit des décisions fondées sur attributs du sujet, de l’objet, de l’opération et de l’environnement. Leur qualité fait partie du contrôle.
Construire une chaîne lisible
Les étapes séquentielles s’emploient lorsque la seconde dépend de la première. Les validations parallèles servent des dimensions indépendantes, comme budget et sécurité. Une règle de quorum est explicite. Le client voit étapes, état, responsable fonctionnel et délai sans exposer des notes privées.
Le workflow possède fins : approuvé, refusé, expiré, annulé ou remplacé. Un refus demande motif structuré et commentaire utile. Une correction crée une nouvelle version ou retourne au demandeur ; elle ne modifie pas l’objet sous une approbation active.
Calculer la prochaine étape
Le moteur évalue la politique après chaque décision et produit les tâches suivantes. Il ne précrée pas forcément toutes les étapes si leurs conditions dépendent d’un résultat. La chronologie conserve pourquoi une étape a été ajoutée ou sautée.
Gérer plafonds et conditions
Un plafond précise devise, assiette, taxes, période et périmètre. Convertir avec un taux non daté rend la règle indéfendable. Les montants cumulés exigent une source de consommation et une stratégie concurrente. Le système explique quelle condition a déclenché l’étape.
Les conditions peuvent porter catégorie, fournisseur, site, urgence ou type de donnée. Limitez leur nombre et fournissez des exemples. Une expression libre dans une interface d’administration crée des politiques impossibles à tester. Utilisez un vocabulaire métier borné.
Qualifier les exceptions
Une urgence ne supprime pas la politique : elle utilise un chemin documenté avec personnes habilitées, motif, durée et revue a posteriori. Les exceptions récurrentes révèlent une règle inadaptée. Elles ont un propriétaire et une date de retrait.
Consommer budget et plafond sans course
Deux demandes peuvent franchir simultanément un plafond cumulé. La décision réserve ou consomme un montant avec version et identifiant, puis libère la réservation à l’expiration ou au refus. Une simple lecture du total avant écriture autorise un dépassement. La réconciliation rapproche réservations, commandes exécutées et annulations ; toute différence bloque les nouvelles consommations sur le périmètre concerné.
La devise est convertie avec une source et une date définies par la politique. L’assiette précise taxes, frais et remises. Les montants affichés au valideur correspondent exactement au snapshot autorisé. Si un taux ou un budget est indisponible, la demande attend ou escalade ; elle n’utilise pas une valeur précédente sans l’indiquer et sans règle acceptée.
Cas concret : commande multi-sites
Un client soumet une commande de 42 000 euros pour trois sites et deux catégories. Chaque responsable local valide ses lignes ; la finance valide le total ; la sécurité intervient uniquement pour une catégorie réglementée. Les avis logistiques restent consultatifs.
La politique crée trois branches parallèles, puis une étape finance. Un responsable absent délègue à un pair sur un site et une période. Si une ligne change après validation, seule sa branche et le total concerné sont recalculés selon la version de politique.
Le pilote couvre soixante demandes et deux cents décisions, avec mutation, double clic, seuil frontalier et devise. Le go local exige zéro auto-approbation, zéro exécution sur version périmée et une explication support depuis la commande. Le délai cible vient du service attendu par ce client, pas d’une moyenne arbitraire.
Pour ce client, toute tâche âgée de plus de 2 jours ouvrés déclenche une escalade fonctionnelle, tandis qu’une délégation expire après la période inscrite et jamais par défaut. Ces seuils proviennent du cycle d’achat et de la capacité des équipes. La recette place deux commandes à 9 900 euros face à un reliquat de 15 000 euros : une seule réservation doit réussir, l’autre revient avec un motif et une prochaine action.
Encadrer délégation et absence
La délégation porte délégant, bénéficiaire, actions, périmètre, début, fin et motif. Le bénéficiaire ne peut déléguer à son tour sauf politique explicite. L’absence peut proposer un remplaçant éligible, mais ne crée pas automatiquement un droit durable.
Une révocation arrête les tâches futures et réévalue les tâches ouvertes. Les décisions déjà prises restent attribuées, avec indication de la délégation. Les sessions et caches sont invalidés selon le délai de risque accepté.
Gérer une file sans valideur
Si aucun valideur n’est éligible, la demande entre dans une file d’administration bornée, sans approbation automatique. Le runbook explique qui répare la structure et comment reprendre. Une escalade désigne une fonction, pas une personne codée en dur.
Implémenter décisions et concurrence
Les entrées sont objet versionné, demandeur, contexte, politique et attributs ; les sorties sont tâches, décision globale, motifs et obligations. Le moteur évalue sans effet externe. L’exécution de la commande validée reste une étape idempotente séparée.
La journalisation conserve version, politique, attributs déterminants et corrélation. Le monitoring suit tâches âgées, refus, expirations, délégations et exécutions en échec. Le retry ne double ni décision ni commande. Le rollback restaure une politique précédente sans effacer les historiques.
Les entrées de décision sont sujet, objet figé, relations, plafonds, budget et instant ; les sorties sont tâches, obligations, expiration et motifs. La responsabilité du moteur se limite au calcul, celle du domaine à l’exécution. Les dépendances possèdent seuils et modes dégradés. La journalisation enregistre l’empreinte du snapshot. Le monitoring détecte les trous de version. Le rollback change la politique active ; le retry rejoue une commande idempotente sans créer deux approbations.
Un fichier de simulation versionné contient cas, attributs, politique et résultat attendu. Avant déploiement, les sorties anciennes et nouvelles sont comparées. Les divergences ont un propriétaire métier. Les tests couvrent refus, séparation, quorum et absence. Une validation technique vérifie que pages, API, notifications et workers utilisent la même commande. Aucun statut ne peut être posé directement sans passer par le domaine.
Protéger la transaction autorisée
L’OWASP Transaction Authorization Cheat Sheet recommande notamment une autorisation côté serveur, distincte de l’authentification et liée aux données significatives de la transaction. L’interface confirme clairement ce qui est approuvé.
Prouver et exploiter le workflow
La chronologie répond à qui, quoi, sur quelle version, selon quelle politique et avec quel résultat. Elle sépare décision, notification et exécution. Les commentaires sensibles suivent des droits distincts. La conservation est définie selon les usages et obligations réels.
Contre-intuitivement, réduire le nombre de niveaux peut renforcer le contrôle : les valideurs comprennent mieux leur responsabilité et les décisions arrivent avant l’expiration. Mesurez attente par étape, retours, changements après soumission, exceptions et décisions annulées.
Pour qui ces validations sont utiles
La démarche convient aux clients avec achats décentralisés, budgets, sites, centres de coûts ou obligations de séparation. Elle mobilise acheteurs, finance, sécurité, produit, développeurs, IAM et support.
Un petit compte avec un seul décideur n’a pas besoin d’un workflow complexe. Une confirmation renforcée ou un plafond simple peut suffire. La chaîne se dimensionne par la décision, pas par la taille commerciale du client.
Erreurs fréquentes des approbations
Reproduire l’organigramme
L’organigramme ne porte ni plafond ni relation à la ressource. Modélisez rôle, périmètre et politique. Les mutations n’obligent pas à redessiner chaque workflow.
Modifier sous validation
Une décision sur un objet mouvant n’est pas défendable. Figez la version et resoumettez les changements significatifs. L’interface montre clairement l’écart.
Donner un bouton administrateur
Le saut d’étape contourne preuves et effets. Une réparation utilise une commande bornée, un motif et une revue. L’administrateur ne devient pas valideur universel.
Décision : simplifier ou renforcer
Priorisez les validations qui protègent budget, droit ou sécurité. Supprimez les avis transformés en étapes. Ajoutez parallélisme si les décisions sont indépendantes. Différez une règle sans source d’attribut. Refusez l’approbation automatique quand aucun valideur n’est éligible.
Si l’objet change significativement, alors invalidez ou resoumettez. En revanche, une correction non engageante peut rester attachée. À éviter : ajouter un niveau pour compenser une mauvaise qualité de donnée.
- Commencer par une politique et une version d’objet.
- Documenter rôles, seuils, délégations et fins.
- Tester concurrence, absence et modification.
- Élargir après mesure des attentes et exceptions.
Plan d’action sur six semaines
Semaines un à trois : reconstruire les décisions
Choisissez trente demandes récentes, dont retours et urgences. Notez risque, objet, version, décideurs et preuves. Séparez avis et approbations. Écrivez une politique bornée avec rôles, relations, plafonds, dates et exceptions.
Modélisez délégation, révocation et absence de valideur. Préparez les tests avec seuils, devises, sites, auto-approbation et changement d’objet. Fermez les notifications, délais, erreurs et journal. Le métier signe les scénarios négatifs.
Semaines quatre à six : simuler et ouvrir
Exécutez la politique en observation sur les demandes réelles. Comparez étapes proposées et décisions actuelles. Corrigez les divergences. Activez ensuite un compte et une catégorie, avec rollback vers le workflow précédent pour les nouvelles soumissions.
Provoquez deux décisions concurrentes, changement après approbation, délégation expirée, file sans valideur et exécution interrompue. Vérifiez idempotence, motifs et reprise. Le support explique le statut depuis l’identifiant métier.
Après un cycle, mesurez attente, resoumissions, exceptions et faux niveaux. Étendez si les décisions restent attribuables et l’exécution liée à la bonne version ; sinon, simplifiez la chaîne ou corrigez les attributs avant d’ajouter des clients.
Clôturez par une revue de quinze demandes prises au hasard. Un auditeur fonctionnel reconstruit l’objet, les étapes, les délégations et l’exécution depuis la chronologie. Le support traite une tâche sans valideur et une réservation bloquée avec le runbook. Toute correction directe de statut est interdite : elle devient une commande de réparation avec motif. Le client signe la lisibilité des notifications et les personnes habilitées, puis le produit documente les limites avant l’extension.
- Nommer le risque et figer l’objet.
- Écrire politique, acteurs et délégations.
- Tester concurrence, absence et reprise.
- Observer un compte puis étendre.
Approfondir droits et workflows
Gouverner les modèles par client
Un socle commun décrit soumission, tâches, décisions, délégation et exécution. Les différences grand compte restent des politiques de données, pas des branches de code copiées. Chaque variante possède contrat, propriétaire et tests. Lorsqu’une règle apparaît chez plusieurs clients, elle peut rejoindre le socle après analyse de sa sémantique ; le nom identique d’une étape ne suffit pas à prouver un besoin commun.
Le retrait d’un client ou d’une politique conserve les historiques selon la durée applicable, révoque les délégations et ferme les tâches. Les exports remis au client utilisent un schéma stable et des identifiants canoniques. Une procédure vérifie qu’aucune notification planifiée ni réservation ne survit. Cette sortie fait partie du produit : sans elle, chaque nouveau contrat augmente une dette invisible dans le moteur.
Le reporting distingue délai de décision, délai d’exécution et temps hors contrôle du valideur. Une moyenne globale masque les demandes retournées et les tâches créées pendant une absence. Segmentez par politique, étape et motif. Un indicateur n’est retenu que s’il commande une action : retirer un niveau, corriger un attribut, augmenter la capacité ou revoir un délai client. Cette discipline protège le workflow contre l’empilement de contrôles qui paraissent rigoureux mais n’améliorent aucune décision.
Les notifications reprennent l’identifiant, le montant, le périmètre, l’échéance et un lien vers la version courante, sans contenir de secret complet. Un ancien email ne permet pas d’approuver une tâche remplacée. Le serveur réévalue identité, délégation et statut au clic. Les relances sont idempotentes et cessent après décision. Cette frontière évite que la messagerie devienne une interface parallèle moins contrôlée que le portail.
Fermer les périmètres des valideurs
Le guide sur les droits par compte, site ou filiale complète rôles, relations, attributs et tests négatifs.
Tester les chemins d’exception
Poursuivez avec les tests de workflows à exceptions et leur observabilité métier.
- Un objet figé.
- Une politique versionnée.
- Une décision attribuable.
Conclusion : faire valider une décision
Un workflow grand compte ne doit pas reproduire des boîtes email. Il applique une politique à une version d’objet, avec des personnes éligibles et des conditions explicables. Chaque étape protège un risque nommé.
Les délégations datées, la séparation de fonctions et l’idempotence protègent l’exécution. La chronologie donne au client et au support un statut fidèle, sans saut administrateur opaque.
Commencez par la validation qui produit le plus d’attente ou de contournements. Rejouez ses décisions, retirez les avis inutiles et figez l’objet. Cette première politique servira de base aux autres comptes.
- Une version approuvée.
- Un valideur éligible.
- Une exécution liée.
Dawap peut accompagner ce workflow de développement web sur mesure : cadrage, politiques, droits, portail, notifications, tests, audit et run.
