Les délais d'expiration empêchent les anciennes approbations d'effectuer de nouvelles actions

Une approbation est l'autorisation d'effectuer une action proposée, à un moment précis. Ce n'est pas un coupon qu'un agent peut utiliser quand cela l'arrange.

Cela semble évident jusqu'au jour où un agent met en file un déploiement en production, une suppression ou une commande SSH pendant qu'une personne est occupée. L'évaluateur voit une demande raisonnable, l'approuve, puis le monde change. Une nouvelle version prend la tête de la file. L'ensemble des cibles évolue. Quelqu'un redirige un alias d'environnement. Un incident modifie les conditions de sécurité. Si l'ancienne approbation peut toujours être exécutée, le système transforme une décision sur l'état d'hier en autorisation sur l'état d'aujourd'hui.

Les délais d'expiration des approbations ne résolvent qu'une partie du problème, mais c'est une partie que les équipes laissent souvent ouverte. Donnez une expiration courte et stricte aux approbations d'actions dont le sens peut changer. Liez ensuite l'approbation à l'action proposée exacte et revérifiez avant l'exécution les conditions susceptibles d'évoluer. Faites les deux. Pris isolément, chacun de ces contrôles laisse une faille.

Une approbation a un budget de fraîcheur

Chaque approbation consomme du temps pendant qu'elle attend son exécution. Plus la cible peut évoluer, plus ce budget doit être réduit.

Une demande de redémarrage d'un worker de prévisualisation éphémère peut rester pertinente pendant une demi-heure. Une demande de promotion d'une version en production peut devenir obsolète en quelques minutes si une autre version, un retour arrière ou une intervention d'incident peut changer la bonne décision suivante. Une commande qui supprime un instantané de sauvegarde nommé devrait expirer rapidement lorsque la liste des instantanés fait l'objet d'un travail actif de rétention. Une commande SSH visant un alias d'hôte modifiable mérite la fenêtre la plus courte de toutes.

La mauvaise solution consiste à choisir un grand nombre unique pour ne pas déranger les équipes. Huit heures semblent accommodantes. En pratique, cela permet aux approbations de s'accumuler pendant la pause déjeuner, la nuit ou un changement d'équipe. Un évaluateur peut approuver un déploiement à 10 h 02, l'oublier, puis découvrir à 16 h 40 qu'un état bien plus récent de la file a utilisé son clic. L'interface d'approbation semblait prudente. Le chemin d'exécution ne l'était pas.

Définissez la fenêtre en posant une question plus précise : combien de temps cette action proposée exacte peut-elle rester une description fidèle de ce qui va se produire ?

Pour la plupart des équipes, une politique de départ utile ressemble à ceci :

• Déploiement ou retour arrière en production : 5 à 15 minutes.
• Suppression destructive : 2 à 10 minutes, selon que l'ensemble d'objets est fixe ou non.
• Commande SSH avec effets d'écriture : 2 à 5 minutes.
• Inspection SSH en lecture seule : pas d'approbation par action, ou une fenêtre plus longue si votre environnement l'exige encore.
• Modifications courantes hors production avec une version figée : 15 à 30 minutes.

Ce sont des valeurs de départ opérationnelles, pas des constantes universelles. Une expiration de cinq minutes est trop longue si une boucle d'automatisation peut modifier la cible toutes les quelques secondes. Elle est trop courte si l'action exige qu'un responsable d'astreinte rassemble d'abord des éléments. La bonne réponse n'est pas de repousser discrètement l'échéance indéfiniment. Donnez à l'évaluateur le contexte nécessaire et permettez-lui de régénérer facilement la demande à partir de l'état actuel.

GitHub Actions établit ici une distinction importante : un job de déploiement peut attendre une revue obligatoire, puis un job en attente qui reçoit l'approbation peut continuer et accéder aux secrets de son environnement. GitHub indique également qu'un job non approuvé peut échouer après 30 jours. Cela empêche les files de rester éternellement ouvertes, mais 30 jours ne constituent pas une fenêtre de fraîcheur utile pour une approbation concernant un déploiement en évolution. Votre propre garde doit considérer l'âge de l'approbation comme une composante de l'autorisation, pas comme une simple gestion de file.

Liez la décision à l'action, pas à une étiquette

Une approbation doit couvrir des données d'action concrètes. « Approuver le déploiement en production » est une étiquette. Elle ne dit presque rien à l'évaluateur sur l'objet qui sera exécuté.

Pour un déploiement, liez la décision au condensat immuable de l'artefact ou à l'identifiant du commit, à la destination, au plan de migration s'il existe, à la révision de configuration et à l'opération de mise en production. Pour une suppression, liez-la à une liste d'objets immuable ou à un instantané du résultat de la requête, ainsi qu'au mode de suppression. Pour SSH, liez-la à l'identité vérifiée de l'hôte, à l'utilisateur, au modèle de commande, aux arguments développés, au répertoire de travail s'il est pertinent et à une description limitée des fichiers d'entrée.

Voici la distinction que les équipes brouillent le plus souvent :

• L'approbation d'une intention signifie que l'évaluateur accepte un objectif général, par exemple « supprimer les prévisualisations obsolètes ».
• L'approbation d'une action signifie que l'évaluateur accepte que cet exécuteur supprime ces identifiants d'objet précis, avec cette commande, avant cette échéance.

L'approbation d'une intention a sa place dans la gestion des changements. Elle ne peut pas remplacer une approbation d'exécution lorsqu'un agent peut agir sur un système réel. Si vous approuvez une intention, puis laissez l'agent déterminer les cibles plus tard, vous lui déléguez la partie essentielle de la décision.

L'OWASP le souligne dans un autre domaine dans son Transaction Authorization Cheat Sheet. Selon ce document, la personne qui autorise une transaction doit identifier et reconnaître les données importantes de cette transaction. Il avertit aussi que la modification de données après autorisation crée un problème de type time-of-check to time-of-use. L'exemple est financier, mais la règle s'applique parfaitement ici : les données de l'approbation doivent être protégées contre toute modification, et un changement de données doit invalider l'autorisation existante.

Un condensat fournit à l'exécuteur une valeur précise à comparer. Ne hachez pas un résumé vague en langage naturel en considérant le travail comme terminé. Canonicalisez les champs qui contrôlent l'effet, sérialisez-les de manière déterministe, puis hachez cette forme canonique.

{
  "request_id": "appr_01JX...",
  "action_type": "deploy",
  "action_digest": "sha256:8b1d...",
  "summary": {
    "artifact": "registry.example/app@sha256:4fa2...",
    "environment": "production",
    "operation": "promote",
    "config_revision": "7c0e...",
    "migration": "none"
  },
  "issued_at": "2026-07-22T14:03:00Z",
  "expires_at": "2026-07-22T14:13:00Z",
  "status": "pending"
}

Le summary est destiné à l'humain. L'action_digest est destiné à l'exécuteur. Conservez les deux. Les humains doivent voir des informations utiles, tandis que les services ont besoin d'une comparaison d'égalité exacte. Si l'agent modifie un seul champ lié, il doit envoyer une nouvelle demande et obtenir une nouvelle décision.

L'expiration et l'invalidation traitent des échecs différents

Une échéance empêche les anciennes approbations de rester en attente. L'invalidation supprime une approbation dès que les faits pertinents changent. Il faut les deux, car attendre le minuteur est négligent lorsque le système sait déjà que la demande ne correspond plus à la réalité.

Invalidez une approbation en attente lorsque le condensat de l'action change. Cette règle est impérative. Invalidez-la aussi lorsqu'une dépendance qui modifie le sens de l'action évolue : la révision d'environnement visée par un déploiement, l'ensemble de suppressions sélectionné, une clé d'hôte, le détenteur d'un verrou de mise en production ou l'état d'un ticket de changement obligatoire.

N'invalidez pas l'approbation à chaque événement sans rapport. Si la moindre ligne de journal, le moindre commit indépendant ou la moindre variation anodine d'une métrique tue une approbation, les évaluateurs considéreront les demandes comme peu fiables et commenceront à approuver sans les examiner. La règle doit suivre les faits qui modifient l'effet demandé ou les préconditions de sécurité.

Utilisez trois états, pas deux :

1. pending signifie que la demande exacte peut encore être approuvée avant son échéance.
2. approved signifie qu'un évaluateur l'a approuvée, mais que l'exécuteur ne l'a pas encore consommée.
3. consumed signifie que l'exécution a revendiqué l'approbation exactement une fois.

Ajoutez les états terminaux expired, invalidated, rejected et failed. Une demande rejetée ne doit pas redevenir pending parce qu'un agent a réessayé un appel réseau. Une exécution échouée ne doit pas réutiliser silencieusement la même approbation, sauf si vous pouvez prouver que l'action n'a jamais commencé et qu'aucun état pertinent n'a changé. Dans la plupart des systèmes d'action, demander à l'agent de recommencer est plus sûr et plus facile à expliquer.

L'exécuteur doit effectuer ces vérifications dans une transaction ou une opération atomique de comparaison et de modification :

if now >= expires_at: reject as expired
if status != approved: reject as unavailable
if stored_digest != supplied_digest: reject as changed
if live_preconditions fail: reject as stale
atomically change status from approved to consumed
execute the action

Ne marquez pas l'approbation comme consommée après le début de l'action. Deux workers peuvent entrer en concurrence, observer tous deux approved et exécuter tous deux l'action. Consommez-la d'abord avec une transition d'état atomique, puis enregistrez le début de l'exécution. Si le processus s'arrête après la consommation, considérez le résultat comme inconnu jusqu'à ce que l'exécuteur puisse déterminer s'il a atteint la cible. C'est contraignant. Une opération destructive en double est pire.

Les approbations de déploiement doivent suivre l'artefact

Une demande de déploiement devient obsolète lorsque son artefact, sa destination, son plan de mise en production ou sa position dans la file change. Les noms de branches et les tags mobiles ne suffisent pas.

L'invite de déploiement doit identifier un artefact immuable. Il peut s'agir d'un condensat d'image, du hachage d'un bundle de version signé ou d'un enregistrement de build immuable. Elle doit également indiquer si l'exécuteur lancera des migrations de base de données, modifiera la configuration de fonctionnalités, redémarrera des instances ou remplacera un déploiement précédent. Ces informations influencent l'approbation. Les cacher derrière un bouton générique « déployer » encourage les approbations automatiques.

Un contrat solide d'approbation de déploiement comprend :

• L'identifiant immuable du build et la révision source.
• L'environnement cible exact ainsi que l'identité du compte ou du cluster.
• L'opération de mise en production, par exemple une promotion, un retour arrière ou un redéploiement.
• Les révisions de configuration et de migration qui seront appliquées.
• Un jeton de concurrence ou une génération de déploiement.

Le jeton de concurrence compte lorsqu'une modification ultérieure remplace une demande précédente. Supposons que le build A attende une approbation. Le build B se termine, passe les contrôles et devient la version que vous voulez désormais livrer. Si la demande du build A reste valide, un évaluateur peut accidentellement publier l'ancienne version. Lorsque le build B entre dans la même voie de mise en production, invalidez l'approbation en attente du build A. Ne comptez pas sur les évaluateurs pour remarquer les horodatages dans une file chargée.

La documentation de déploiement de GitHub sépare la protection des environnements de la concurrence des workflows. Les contrôles de concurrence peuvent annuler les tâches en attente d'un groupe, tandis que l'approbation de l'environnement détermine si un job peut continuer. Cette séparation est utile : la politique de file peut décider quelle exécution est actuelle, tandis que la garde d'approbation peut décider si cette exécution exacte peut démarrer. Les combiner sans précaution produit l'échec classique où la bonne personne approuve la mauvaise exécution.

L'exécuteur doit revérifier les éléments avant le déploiement. Une vérification préalable pratique peut confirmer que l'artefact demandé existe toujours, que l'environnement correspond toujours à l'identité cible attendue, qu'aucune version plus récente ne détient la voie de mise en production et que le plan de migration correspond toujours au condensat approuvé. Si un contrôle échoue, marquez la demande comme invalidée et affichez à l'évaluateur une nouvelle demande. Ne remplacez jamais silencieusement le build A par le build B parce que le build A a été approuvé. Il s'agit d'une autre action.

Évitez un schéma répandu mais faible : approuver une pull request et considérer cette approbation comme une autorisation de production. La revue de code répond à la question de savoir si une modification proposée a sa place dans le code. Elle ne dit pas si ce build doit être exécuté en production maintenant, après l'incident actuel, avec les migrations et l'état des cibles actuels. Gardez ces décisions séparées.

Les demandes de suppression ont besoin d'un ensemble d'objets figé

Les approbations de suppression deviennent dangereuses lorsque la demande contient une requête au lieu des objets résolus. « Supprimer les sauvegardes de plus de 30 jours » peut désigner un ensemble différent à chaque minute.

Lors de la création de la demande, résolvez la requête en identifiants d'objet et enregistrez un marqueur d'instantané. L'écran d'approbation doit afficher le nombre, quelques identifiants représentatifs, le fondement de la rétention et le mode de suppression exact. L'exécuteur doit utiliser cet ensemble figé, pas relancer la requête générale après l'approbation.

Si l'ensemble est trop volumineux pour être affiché intégralement, donnez à l'évaluateur un identifiant de manifeste stable et un récapitulatif concis. Ne réduisez pas la demande à « Supprimer 8 421 éléments » sans autre limite. Un nombre ne permet pas de savoir si la liste contient le mauvais locataire, des sauvegardes actuelles ou un préfixe inattendu.

Considérez cette demande :

{
  "action_type": "delete_objects",
  "scope": "archive/preview/",
  "selection": {
    "manifest_digest": "sha256:19e7...",
    "object_count": 184,
    "newest_object_at": "2026-06-19T03:11:00Z",
    "oldest_object_at": "2025-11-02T18:24:00Z"
  },
  "mode": "permanent",
  "expires_at": "2026-07-22T14:08:00Z"
}

Au moment de l'exécution, confirmez que le manifeste existe toujours et que chaque identifiant d'objet correspond encore à la version attendue. Si le système de stockage gère le versionnage, liez la suppression aux versions plutôt qu'aux noms. Les noms peuvent être réutilisés. Un nouvel objet écrit au même chemin après l'approbation ne doit pas hériter de la condamnation à mort de l'ancien objet.

Une échéance courte est particulièrement importante lorsque la demande repose sur l'âge ou sur un inventaire en temps réel. Plus la demande attend, plus il est probable qu'un objet nouvellement éligible, un élément restauré ou un enregistrement reclassé modifie l'ensemble prévu. Si le système ne peut pas figer l'ensemble, il ne doit pas permettre à une seule approbation d'autoriser une requête de suppression générale. Demandez plutôt une requête récente et ciblée.

La suppression réversible et la suppression définitive méritent des invites et des fenêtres d'expiration différentes. Une suppression réversible peut être annulée, mais cette possibilité ne justifie pas des approbations vagues. La récupération est souvent lente, incomplète ou dépend de permissions que la personne qui demande la suppression ne contrôle pas.

Les approbations SSH deviennent obsolètes plus vite qu'on ne le pense

SSH est particulièrement sensible au contexte obsolète, car les noms, les sessions, les variables d'environnement et les répertoires de travail peuvent changer sous le même texte de commande.

systemctl restart api semble précis jusqu'à ce qu'on demande quelle machine le reçoit, ce que api désigne sur cette machine, quel déploiement est actif et si un incident ultérieur a changé la raison de redémarrer quoi que ce soit. rm -rf /srv/tmp/job-123 peut être sans danger sur un hôte et catastrophique sur un autre si un alias, un montage ou une expansion du shell change.

Pour une action SSH, approuvez une demande de commande structurée, pas une transcription de terminal. La demande doit contenir l'identité vérifiée de l'hôte, l'utilisateur cible, un modèle de commande fixe, les arguments autorisés entièrement développés, le répertoire de travail déclaré et le condensat de toute entrée attendue. Si l'agent a besoin d'un shell, limitez la commande du shell à une charge utile explicite au lieu d'autoriser une session interactive ouverte.

Une carte d'approbation raisonnable pourrait se présenter ainsi :

Host: prod-api-03, host key SHA256:K4f...
User: deploy
Command: /usr/local/bin/release-health --release 2026.07.22.4 --repair-cache
Directory: /srv/api
Effect: writes cache state, may restart one service
Expires: 14:08 UTC

Cela ne prouve toujours pas que la commande est sûre. C'est toutefois assez d'informations pour qu'un humain reconnaisse ce qu'il autorise. L'exécuteur se reconnecte ensuite, vérifie à nouveau l'identité de l'hôte, confirme le condensat de la commande et l'exécute avant l'échéance.

Ne laissez jamais l'approbation d'une commande sur prod-api autoriser son exécution après que le DNS, l'inventaire ou une correspondance de bastion a résolu ce libellé vers un autre hôte. Liez-la à l'identité cryptographique de l'hôte lorsque la configuration de la connexion le permet. Si une rotation légitime de clé d'hôte intervient pendant l'attente de l'approbation, invalidez la demande. Cela peut sembler gênant pendant une maintenance. C'est préférable à l'approbation d'une commande pour une machine puis à son envoi vers une autre.

Les commandes en lecture seule méritent leur propre catégorie. Les équipes imposent souvent une approbation pour chaque appel SSH parce qu'elles disposent d'un seul contrôle et l'appliquent partout. Cela crée une fatigue d'approbation, puis les évaluateurs valident des commandes qu'ils ne peuvent pas comprendre. Séparez les inspections inoffensives des actions qui écrivent, redémarrent, modifient les accès ou exposent des données sensibles. Utilisez une approbation par appel lorsque les effets de la commande le justifient et gardez l'invite assez compacte pour être lue.

L'écran d'approbation doit rendre les changements visibles

Un contrat backend précis ne sert à rien si l'évaluateur ne voit qu'une phrase rédigée par l'agent. L'écran doit afficher les champs susceptibles de modifier la réponse.

Commencez par l'effet : déployer ce condensat dans cet environnement ; supprimer définitivement ce manifeste figé ; exécuter cette commande sur cet hôte vérifié. Placez l'échéance là où l'évaluateur la verra avant d'approuver et affichez l'heure dans un fuseau horaire non ambigu. Un compte à rebours n'est qu'une aide. L'horodatage côté serveur de l'exécuteur décide de la validité.

Lorsqu'une demande change, ne remplacez pas l'ancien contenu sur place en laissant le bouton d'approbation actif. Marquez-la comme invalidée. Créez une nouvelle demande avec une explication visible, comme « l'artefact a changé » ou « l'inventaire des cibles a changé ». Un évaluateur qui a approuvé la version précédente doit prendre une nouvelle décision. Ce clic supplémentaire est précisément le but recherché.

NIST SP 800-63B-4 décrit l'intention d'authentification comme une intervention de l'utilisateur confirmant qu'un demandeur souhaite s'authentifier ou se réauthentifier. L'approbation d'une action exige la même discipline, de façon plus ciblée. Une pression du doigt ou un clic de confirmation doit exprimer une intention pour l'opération affichée, et non une volonté générale de laisser un agent continuer.

Évitez les invites qui transforment la pression du temps en piège. Une fenêtre de deux minutes pour une suppression complexe oblige l'évaluateur à choisir entre une approbation aveugle et l'expiration. La demande doit être prête à examiner avant d'arriver à l'évaluateur. Utilisez une échéance d'exécution courte après lui avoir donné un contexte suffisant, pas une échéance de décision précipitée qui pénalise une lecture attentive.

Un champ de commentaire peut être utile lorsque l'évaluateur doit expliquer pourquoi une action inhabituelle est acceptable. Ne rendez pas le commentaire obligatoire pour les opérations courantes. Les formules imposées produisent du texte que personne ne lit. Exigez-le pour les dérogations, les prolongations exceptionnelles ou les actions qui dépassent un périmètre d'impact défini.

L'exécuteur est responsable de l'application des règles

Le système qui détient l'autorité d'effectuer l'action doit appliquer l'expiration, la liaison et la consommation unique. Une interface de workflow, un bot de discussion ou un framework d'agent peut demander une approbation, mais ne peut pas être l'arbitre final si un autre composant peut le contourner.

C'est pourquoi une passerelle d'action constitue une frontière utile. L'agent envoie un appel HTTP ou une commande SSH. La passerelle vérifie que la demande possède une approbation actuelle, injecte l'identifiant si nécessaire, effectue l'opération et renvoie le résultat. L'agent n'a jamais besoin d'un identifiant réutilisable qui lui permettrait de contourner ultérieurement le chemin d'approbation.

Sallyport suit cette logique pour les API HTTP et SSH : l'agent se connecte par l'intermédiaire de son shim MCP, tandis que les identifiants restent dans le coffre chiffré de l'application, qui exécute l'action au lieu de remettre les secrets à l'agent. Ses clés par appel sont un emplacement naturel pour exiger une confirmation récente lorsque le contexte change rapidement. La logique de délai et de liaison à l'action doit toutefois être explicite dans le chemin de la requête ; une confirmation dépourvue de ces vérifications peut vieillir jusqu'à produire le même problème.

Conservez l'état de l'approbation à proximité de l'exécuteur, ou rendez-le vérifiable cryptographiquement par celui-ci. Un jeton d'approbation signé peut convenir s'il inclut l'identifiant de la demande, le condensat de l'action, l'heure d'émission, l'expiration, l'identité de l'évaluateur et un nonce. L'exécuteur doit tout de même vérifier la révocation et consommer le nonce une seule fois. Un jeton signé qui reste valide après l'invalidation d'une demande n'est qu'une approbation obsolète bien signée.

Gérez les horloges avec soin. Utilisez l'horloge d'un service de confiance pour les décisions d'expiration, stockez les horodatages en UTC et refusez les approbations à l'instant d'expiration ou après celui-ci. L'horloge locale de l'agent et le compte à rebours du navigateur servent à l'affichage. Ce ne sont pas des éléments d'autorisation.

Les journaux doivent expliquer pourquoi l'exécution a eu lieu ou non

Lorsqu'une approbation expire, les équipes ont besoin d'une trace qui dit plus que « refusée ». Elles doivent savoir si l'évaluateur n'a jamais répondu, si la demande a changé après l'approbation, si l'exécuteur a trouvé une précondition défaillante ou si un autre worker avait déjà consommé l'approbation.

Écrivez une trace d'événements immuable reliant la proposition, le résumé affiché, la décision d'approbation, l'invalidation ou l'expiration, les vérifications préalables, la tentative d'exécution et le résultat. Stockez le condensat de l'action dans chaque événement. Si la demande a été régénérée, enregistrez l'identifiant de la demande de remplacement sans laisser entendre que l'approbation précédente a été conservée.

Une structure d'événement utile ressemble à ceci :

{
  "event": "approval.invalidated",
  "request_id": "appr_01JX...",
  "action_digest": "sha256:8b1d...",
  "reason": "release_lane_superseded",
  "replaced_by": "appr_01JY...",
  "recorded_at": "2026-07-22T14:06:22Z"
}

Enregistrez aussi les tentatives de consommation d'approbations expirées. Elles révèlent les agents qui réessaient aveuglément, les workers dont l'horloge est incorrecte et les parcours d'interface qui n'ont pas été actualisés. Elles permettent également à l'équipe chargée d'un incident de distinguer une demande expirée d'une action qui a réellement atteint la production.

Le journal Sessions et le journal Activity de Sallyport sont dérivés d'un journal d'audit chiffré et chaîné par hachage. Sa commande sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré. Ce type de trace n'est utile que si le vocabulaire des événements reste honnête. Incluez les événements d'expiration, d'invalidation et d'échec des vérifications préalables, pas seulement les appels réussis qui donnent au tableau de bord une apparence irréprochable.

Ne confondez pas auditabilité et prévention. Une trace parfaite d'une ancienne approbation exécutée sur un nouvel état est la preuve d'un échec. Le contrôle préventif doit s'exécuter avant que l'exécuteur n'envoie la requête ou n'ouvre le canal SSH.

Rendez les demandes expirées faciles à remplacer

Les fenêtres courtes ne fonctionnent que lorsqu'une nouvelle demande est plus simple que de discuter avec l'ancienne. Si la régénération exige de ressaisir un numéro de ticket, de reconstruire une commande à la main et de solliciter trois personnes, les équipes vous demanderont d'allonger chaque délai jusqu'à le rendre inutile.

L'agent doit pouvoir soumettre à nouveau une demande à partir de l'état actuel, mais il doit afficher clairement les nouveaux faits. Si seule l'expiration a changé et que tous les champs liés restent identiques, une nouvelle demande peut conserver le même résumé lisible tout en recevant un nouvel identifiant et une nouvelle échéance. Si un champ d'action ou une précondition réelle a changé, indiquez lequel. Ne demandez pas à l'évaluateur de comparer des condensats opaques.

Considérez toute prolongation comme une exception. Si vous en proposez une, exigez que l'exécuteur relance toutes les vérifications préalables et que l'évaluateur revoie le résumé actuel. Un bouton « prolonger de 30 minutes » qui renouvelle l'ancien jeton est un contournement de l'approbation avec une typographie plus agréable.

Commencez par mesurer quatre éléments : la fréquence d'expiration des approbations, la fréquence d'invalidation des actions approuvées avant leur exécution, le temps d'attente des demandes et les types d'actions qui génèrent des tentatives répétées. Ces résultats indiquent si l'échéance est trop courte, si la file est trop lente ou si l'agent crée des demandes avant de disposer d'entrées stables.

Une approbation obsolète doit échouer discrètement et précisément : l'exécuteur la refuse, le journal indique la raison et l'agent demande une décision actuelle si le travail reste pertinent. Ce petit refus est ce qui rattache le contrôle humain à l'action qui se produit réellement.