Les politiques déterminent comment les opérations régies s'exécutent : immédiatement, ou après examen par d'autres Membres. Chaque workflow est associé à une seule politique, définie une fois pour l'ensemble de l'Organisation. Cet article décrit le cycle de vie des demandes, les paramètres de politique et le verrouillage. Pour savoir qui peut initier et approuver des demandes, consultez Rôles, profils et autorisations.
Les politiques sont associées aux workflows, jamais aux comptes. Il n'existe qu'une seule politique de demande de retrait pour l'Organisation, et non une par compte. Pour définir qui peut effectuer un retrait depuis quel compte, utilisez les autorisations de mouvement de fonds dans les Rôles de compte ; pour ajuster le niveau de contrôle des retraits, vous disposez d'un seul paramètre pour l'ensemble du workflow.
Toute opération régie suit le même parcours, qu'elle déplace des fonds ou modifie la configuration de l'Organisation :
1 - Initiation. Un Membre dont le Profil de workflow dispose du droit Initier (ou Exécuter) sur le workflow soumet une demande. Pour les retraits et les transferts, il doit également disposer de l'autorisation de mouvement de fonds correspondante sur les comptes concernés.
2 - Vérification d'exécution immédiate. Si le Membre dispose du droit Exécuter et que le paramètre "Toujours exiger une approbation" du workflow est désactivé, la demande s'exécute immédiatement. Terminé. Une exception : toute demande de modification d'une politique verrouillée est soumise à approbation, quel que soit le niveau du demandeur. Voir "Verrouillage des politiques" ci-dessous.
3 - File d'approbation. Dans le cas contraire, la demande est mise en attente d'examen. Les Membres disposant du droit Approuver sur ce workflow la voient apparaître dans leur file.
4 - Résolution. Lorsque le nombre requis d'approbations indépendantes est atteint, la demande s'exécute et prend effet. Tout approbateur peut à la place la rejeter, ce qui met fin à la demande sans effet.
Les demandes finalisées sont enregistrées en tant qu'événements de sécurité, liés à la demande et à son historique d'approbation.
Un Membre ne peut pas approuver sa propre demande. Le système applique cette règle sur chaque workflow, et aucune autorisation, aucun profil ni aucune configuration de politique ne peut la contourner.
Le seul moyen pour un Membre d'exécuter seul une opération régie est de disposer du droit Exécuter, et uniquement lorsque la politique du workflow autorise l'exécution immédiate.
La politique de chaque workflow comporte deux paramètres :
Paramètre | Effet |
|---|---|
Approbations requises | Nombre de membres distincts devant approuver une demande avant qu'elle soit finalisée. Les approbateurs proviennent des membres disposant du droit Approve sur ce workflow ; l'initiateur est toujours exclu de l'approbation de sa propre demande. |
Toujours demander l’approbation | Lorsque ce paramètre est ACTIVÉ, chaque demande passe par la file d'approbation, y compris les demandes des membres disposant du droit Execute. Lorsqu'il est DÉSACTIVÉ, les membres disposant du droit Execute finalisent les demandes immédiatement. |
Interaction entre Execute et "Toujours exiger une approbation" :
Profil du membre sur le workflow | Toujours demander l’approbation | Résultat |
|---|---|---|
Initiate, sans Execute | DÉSACTIVÉ ou ACTIVÉ | La demande est soumise à approbation |
Initiate + Execute | DÉSACTIVÉ | La demande est finalisée immédiatement |
Initiate + Execute | ON | La demande est soumise à approbation, Execute est inactif |
Execute n'est jamais supprimé par une politique : il reste associé au profil, signalé comme inactif lorsque "Toujours exiger une approbation" est ACTIVÉ, et reprend effet si ce paramètre est ultérieurement DÉSACTIVÉ.
Les modifications de politiques sont elles-mêmes des opérations régies par le workflow Gérer les politiques. Si ce workflow requiert une approbation, votre modification est placée dans la file d'attente comme toute autre demande.
Chaque politique conserve également son propre historique des modifications : chaque mise à jour, verrouillage et déverrouillage y est consigné avec la demande d'approbation correspondante, ce qui vous permet de toujours savoir ce qui a changé, qui l'a demandé et qui l'a validé. Les modifications finalisées sont également enregistrées en tant qu'événements de sécurité.
Les membres ne peuvent pas approuver leurs propres demandes : comptez les approbateurs du point de vue de celui qui initie la demande. Un approbateur qui n'initie jamais de demandes est comptabilisé pour tous ; un approbateur qui en initie également ne peut pas être comptabilisé pour les siennes. Deux approbations sont satisfaites par deux approbateurs qui n'approuvent que, mais pas par deux approbateurs qui initient également des demandes. Le système bloque toute configuration qu'aucun membre ne pourrait satisfaire, et l'éditeur de politiques affiche les approbateurs disponibles à côté du nombre requis.
Le verrouillage est l'étape d'engagement de la gouvernance. Il exige une approbation indépendante pour toute modification future de la politique de ce workflow, qu'il s'agisse de changer le nombre d'approbations requises, de modifier le paramètre "Toujours exiger une approbation" ou de le déverrouiller.
Toute modification de politique est traitée comme une demande Gérer les politiques, que la politique cible soit verrouillée ou non : le verrou ne change pas le circuit de la demande, seulement la façon dont elle s'exécute :
Une fois verrouillé, aucune personne seule ne peut affaiblir la gouvernance du workflow. Les modifications restent routinières : tout membre dont le profil de workflow accorde l'approbation sur Gérer les politiques peut les examiner et les approuver, mais elles nécessitent toujours au moins deux personnes.
Le verrouillage est propre à chaque workflow. Verrouiller Demande de retrait n'a aucune incidence sur Demande de transfert ni sur aucun autre workflow : vous renforcez un workflow à la fois, à votre propre rythme. Consultez Déploiement de la gouvernance pour la progression recommandée.
Le verrouillage et le déverrouillage sont aussi des demandes
Trois types de demandes relèvent du workflow Manage Policies. Vous les retrouverez dans la file d'approbation, dans l'historique des modifications de chaque politique et dans les événements de sécurité :
Demander | Effet |
|---|---|
Mise à jour de politique | Modifie les paramètres d'une politique : le nombre d'approbations requises ou "Always require approval" |
Verrouillage de la politique | Verrouille une politique |
Déverrouillage de politique | Déverrouille une politique verrouillée |
Le verrouillage n'échappe pas à ses propres règles : une demande de verrouillage suit le même cycle de vie que toute autre demande Manage Policies. Si vous disposez d'Execute sur Manage Policies et que le paramètre "Always require approval" est désactivé, le verrouillage prend effet immédiatement ; sinon, la demande reste en file d'attente et la politique demeure déverrouillée jusqu'à son approbation.
Comment une modification de politique aboutit
Résultat de toute demande Manage Policies, selon les paramètres en vigueur :
Politique cible | Niveau du demandeur sur Manage Policies | "Always require approval" sur Manage Policies | Résultat |
|---|---|---|---|
Verrouillé | Tous niveaux, y compris Execute | Activé ou désactivé | En attente d'approbation – le verrou décide |
Déverrouillé | Initiate, sans Execute | Activé ou désactivé | En attente d'approbation |
Déverrouillé | Exécutez | ON | En attente d'approbation – Execute est inactif |
Déverrouillé | Exécutez | DÉSACTIVÉ | S'exécute immédiatement |
Deux façons de contrôler les modifications de politique
Contrôle | Portée | Effet |
|---|---|---|
Verrouillage de la politique | La politique d'un workflow unique | Toute modification de cette politique requiert une approbation indépendante ; les autres workflows ne sont pas affectés. |
"Toujours exiger une approbation" dans Manage Policies | Toutes les politiques | Toute modification de politique, sur chaque workflow, est soumise à approbation. Un interrupteur de gouvernance global. |
Les deux contrôles sont complémentaires et ne se contredisent jamais : dès que l'un ou l'autre s'applique, la modification attend une approbation, et activer les deux ensemble ne change rien de plus. Utilisez le verrouillage pour un renforcement progressif ; utilisez le paramètre Manage Policies lorsque vous souhaitez que toutes les modifications de politique soient examinées en même temps.
Verrouillage de Manage Policies
Manage Policies est un workflow comme les autres : il possède sa propre politique, et cette politique dispose de son propre verrou. Le verrouiller constitue l'engagement final d'un déploiement de gouvernance. Une fois la politique Manage Policies verrouillée, toute modification des règles au sein de l'Organisation – y compris le déverrouillage de n'importe quelle politique et le déverrouillage de Manage Policies lui-même – requiert une approbation indépendante. À partir de ce moment, aucune personne seule ne peut assouplir la gouvernance via le produit.
C'est également pour cette raison que vous devez confirmer la procédure de déverrouillage avant de verrouiller, comme décrit dans la section "Protections" ci-dessous. Rien dans le produit ne vous empêche de verrouiller une politique dans un état que personne ne peut modifier. Consultez Déploiement de la gouvernance pour savoir quand franchir cette étape.
Vérifiez que le déverrouillage reste possible avant de verrouiller. Le déverrouillage est une demande Manage Policies portant sur une politique verrouillée : Execute ne peut donc pas l'accélérer. Vous avez besoin d'un Membre pouvant initier une demande Manage Policies, ainsi que d'autant d'autres Membres titulaires d'Approve sur Manage Policies que le workflow l'exige, tous vérifiés et actifs. Le système n'effectue pas cette vérification à votre place : une politique verrouillée sans voie d'approbation disponible nécessite l'intervention du support Kraken pour être débloquée.
Prévention des blocages. Une modification est refusée si elle laisse un workflow sans aucun Membre en mesure de finaliser les demandes qui y sont initiées. Les Membres ne pouvant pas approuver leurs propres demandes, ce cas se présente dès que le nombre d'approbations requis dépasse ce qu'un initiateur peut obtenir pour ses propres demandes. La vérification s'applique dans les deux cas : lorsque vous modifiez une politique, et lorsque vous changez le Workflow Profile d'un Membre ou un Account Role.
Avertissement de désactivation. Vérifiez la couverture en approbateurs avant de désactiver un Membre titulaire d'Approve. La désactivation s'applique même si elle fait passer un workflow sous son nombre d'approbations requis ; les demandes en attente restent soumises au seuil en vigueur au moment de leur création.
Une fois les politiques en place, Déploiement de la gouvernance vous guide pour les introduire en toute sécurité : configurez, validez, puis verrouillez, un workflow à la fois, avec des exemples concrets.
Le paramètre "Toujours exiger une approbation" est activé pour ce workflow. Execute est inactif tant que ce paramètre est activé ; chaque demande passe par la file d'attente pour approbation indépendante. Pour rétablir la finalisation immédiate, désactivez ce paramètre dans Policies – cette action relève de Manage Policies et peut elle-même nécessiter une approbation.
Si la demande concernée est une modification de politique, vérifiez également la politique cible : les modifications apportées à une politique verrouillée attendent toujours une approbation, quelle que soit la valeur d'Execute. C'est le verrouillage qui fonctionne normalement.
Le verrouillage est lui-même une demande Manage Policies. Si "Toujours exiger une approbation" est activé pour Manage Policies, ou si votre Workflow Profile ne dispose pas d'Execute sur ce workflow, la demande de verrouillage attend une approbation indépendante comme toute autre demande. La politique reste déverrouillée jusqu'à l'approbation de la demande de verrouillage ; vous la trouverez dans la file d'attente des approbations, puis dans l'historique des modifications de la politique une fois finalisée.
Comptez les Membres actifs disposant de l'autorisation Approuver sur ce flux de travail, en vous excluant. Seuls les Membres ayant accepté leur invitation et finalisé leur vérification sont pris en compte pour les approbations : un Membre invité ne compte pas tant que ces deux étapes ne sont pas accomplies, même s'il apparaît dans votre liste d'équipe. Si un approbateur a été désactivé après la création de la demande, les approbateurs restants peuvent ne plus atteindre le nombre requis. Une demande en attente reste soumise au seuil en vigueur au moment de sa création, même si la politique a été modifiée depuis. Réactivez le Membre ou accordez l'autorisation Approuver à un autre Membre actif pour le débloquer.
Vérifiez votre Profil de flux de travail : le verrouillage nécessite l'autorisation Initier ou Exécuter sur le flux de travail Gérer les politiques. Si la demande de verrouillage a été créée sans qu'aucune modification ne soit intervenue, elle est en attente d'approbation et non refusée – consultez le point ci-dessus.
La plateforme ne refuse pas une demande de verrouillage faute d'approbateur indépendant. Vérifiez donc vous-même la procédure de déverrouillage avant de verrouiller : il vous faut un Membre pouvant initier une demande Gérer les politiques, ainsi qu'autant d'autres Membres disposant de l'autorisation Approuver sur ce flux de travail que celui-ci l'exige.
Le nombre d'approbations requises dépasse ce que certains Membres qui initient des demandes peuvent réunir, personne ne pouvant approuver ses propres demandes. L'éditeur de politique indique la cause : un ou plusieurs Membres disposent à la fois des autorisations Initier et Approuver, si bien que chacun d'entre eux se retrouve avec un approbateur de moins que le total. Réduisez le nombre d'approbations requises, ou accordez l'autorisation Approuver à un autre Membre qui n'initie pas de demandes sur ce flux de travail.