Un budget de latence d'approbation pour des actions d'agents plus sûres

Les approbations d'agents échouent de deux façons opposées. Si vous demandez l'avis d'une personne pour chaque action, l'agent passe ses journées à attendre derrière une file de révision. Si vous supprimez le point de décision parce que l'attente est pénible, l'agent reçoit une autorité que personne ne peut réellement superviser.

Un budget de latence d'approbation évite ces deux problèmes. Il indique le temps dont dispose une personne pour décider d'une classe donnée d'action d'agent, mesure où ce temps est consommé et impose une refonte lorsque le travail courant ne peut pas respecter cette limite. Le budget n'est pas un objectif qui obligerait les gens à cliquer plus vite. C'est une contrainte appliquée au flux de travail et à l'autorité confiée à l'agent.

J'ai vu des équipes considérer une invite d'approbation comme une preuve de contrôle, avant de découvrir qu'un développeur approuvait vingt demandes presque identiques tout en essayant de terminer son propre travail. Cette personne ne révise pas réellement les demandes. Elle sert de relais lent. La solution est rarement une meilleure notification de rappel. Il faut généralement une autorité moins ambiguë, moins d'appels inutiles et un chemin d'escalade plus clair pour les actions qui méritent un examen attentif.

Un budget de latence d'approbation fixe une échéance pour la décision humaine

Un budget de latence d'approbation est le délai maximal acceptable entre le moment où une demande peut être examinée et celui où une personne l'autorise ou la refuse définitivement. Il doit varier selon la classe d'action, car la lecture d'une pull request, la création d'une ressource de test temporaire et la modification d'un accès en production n'ont ni la même urgence ni les mêmes conséquences.

Traitez le budget comme une partie du contrat de l'action. Si l'agent a besoin d'une réponse en moins de deux minutes pour poursuivre une tâche interactive, le système doit soit rendre cette action facile à évaluer en deux minutes, soit éviter de la soumettre à approbation pendant le travail ordinaire. Si une tâche peut attendre sans risque jusqu'au matin, ne prétendez pas qu'elle nécessite une interruption immédiate.

Le budget comprend trois éléments :

• Attente en file : temps écoulé entre la création de la demande et son ouverture par un réviseur.
• Temps de décision : temps écoulé entre l'ouverture de la demande et la décision d'autoriser ou de refuser.
• Temps de lancement : temps écoulé entre la décision et le début ou l'échec de l'action.

De nombreuses équipes réunissent ces éléments en un seul nombre appelé délai d'approbation. Cela masque la correction à apporter. Vingt minutes d'attente dans la file appellent des changements de routage, de responsabilité ou de planification. Vingt minutes de décision signifient que la demande manque de contexte, contient trop d'autorité ou demande un jugement qui n'aurait jamais dû parvenir à une personne pressée.

Définissez les budgets en fonction des échéances du travail, et non d'un niveau de sécurité abstrait. Un tableau de départ raisonnable pourrait ressembler à ceci :

Ces valeurs sont des exemples, pas une politique universelle. Une équipe de déploiement avec une rotation d'astreinte peut avoir une fenêtre différente de celle d'un développeur seul. L'essentiel est de nommer l'attente avant que la file ne se forme.

N'utilisez pas un accord de niveau de service à moins de pouvoir fournir les effectifs correspondants. Un budget est une limite de conception. Il vous indique qu'une tâche ne peut pas dépendre d'une décision interactive si les personnes habilitées à décider dorment, sont en réunion ou gèrent un incident. L'agent doit le savoir lui aussi. Il peut préparer la demande, choisir une autre voie sûre ou s'arrêter en donnant une explication compréhensible. Il ne doit pas envoyer la même demande toutes les minutes.

Mesurer le cycle de vie de la demande plutôt qu'un clic

Vous ne pouvez pas réduire les délais d'approbation si vos horodatages commencent au moment où une notification arrive sur un téléphone. Commencez lorsque le système crée une action pouvant être examinée, puis enregistrez chaque changement d'état avec un identifiant de demande qui survit aux nouvelles tentatives et aux actualisations de l'interface.

Utilisez une petite fiche d'événement comme celle-ci. Les champs sont volontairement ordinaires. Des enregistrements ordinaires se trient, se joignent et résistent à l'examen d'un incident.

{
  "request_id": "req_7f31",
  "run_id": "run_241",
  "action_class": "bounded_write",
  "target": "issue tracker/project-amber",
  "created_at": "2025-03-08T14:02:01Z",
  "presented_at": "2025-03-08T14:02:03Z",
  "opened_at": "2025-03-08T14:09:18Z",
  "decided_at": "2025-03-08T14:10:06Z",
  "decision": "allow",
  "executed_at": "2025-03-08T14:10:07Z",
  "outcome": "success"
}

Avec cette structure, calculez l'attente en file comme opened_at - presented_at, le temps de décision comme decided_at - opened_at et le temps de lancement comme executed_at - decided_at. Conservez aussi created_at. Ce champ révèle un défaut plus discret : un intermédiaire qui retient une demande avant que quiconque puisse la voir.

Une requête suffit à exprimer ces mesures sans infrastructure analytique complexe :

SELECT
  action_class,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p50_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p95_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY decided_at - opened_at) AS p95_decision_time,
  count(*) FILTER (WHERE decision = 'deny') AS denied,
  count(*) AS total
FROM approval_requests
WHERE created_at >= current_timestamp - interval '14 days'
GROUP BY action_class;

La syntaxe exacte des percentiles varie selon les bases de données. La mesure, elle, ne change pas. Présentez p50 et p95 pour chaque classe d'action, avec le nombre de demandes et le taux de refus. Une moyenne peut faire paraître acceptable une expérience de cinq secondes à côté de quelques demandes restées quatre-vingt-dix minutes en attente. Le p95 indique si la longue traîne perturbe les tâches réelles.

Enregistrez aussi si l'agent a annulé, réessayé ou abandonné la tâche avant l'arrivée de la décision. Une approbation tardive qui s'exécute après que l'agent a choisi une autre voie est pire qu'un refus ordinaire. Elle crée une action qui ne correspond plus au travail du développeur.

Ne récompensez pas les réviseurs uniquement pour avoir réduit le temps de décision. Vous transformeriez les refus réfléchis en problème apparent de performance. Examinez ensemble la répartition des autorisations, des refus, des expirations et des retraits. Une chute soudaine des refus accompagnée de temps de lecture très courts signifie souvent que les gens ont compris qu'un clic sur « Autoriser » suffit à faire disparaître une gêne.

Le temps d'attente et le temps de révision indiquent des défauts différents

L'attente en file et le temps de décision avancent sur la même horloge, mais leurs causes et leurs responsables diffèrent. Les traiter comme une seule mesure conduit à de mauvaises corrections.

L'attente en file augmente lorsque les demandes arrivent à la mauvaise personne, que plusieurs personnes supposent que quelqu'un d'autre décidera, que les notifications arrivent en dehors des heures de travail ou qu'un réviseur n'a aucune raison d'interrompre sa tâche actuelle. Ajouter des notifications aggrave souvent le problème. La même responsabilité ambiguë est alors diffusée à davantage de personnes.

Le temps de décision augmente lorsque la fiche oblige le réviseur à reconstituer l'intention de l'agent. Une demande telle que « POST /v1/resources » ne peut pas être examinée correctement. Le réviseur doit connaître la destination, l'opération, le nombre d'objets, l'autorité utilisée et la conséquence visible. Il ne devrait pas avoir à ouvrir un terminal, inspecter le code source et déterminer si la demande crée un brouillon ou envoie un message aux clients.

Une bonne fiche d'approbation répond simplement à cinq questions :

1. Quelle exécution d'agent a créé la demande et quel processus signé a lancé cette exécution ?
2. Quelle cible externe recevra l'action ?
3. Qu'est-ce qui changera, ou quelles données quitteront la machine ?
4. Quelle autorité limitée l'autorise ?
5. Que se passe-t-il si le réviseur la refuse ou ne fait rien ?

Ne confondez pas davantage de détails et meilleur contexte. Un contenu brut complet peut enfouir le seul champ qui compte. Affichez d'abord une conséquence concise, puis laissez le réviseur consulter la commande, le point d'accès, les en-têtes dont les secrets ont été retirés et la charge utile si nécessaire. Pour approuver une suppression, il doit voir les noms des objets concernés. Pour approuver une lecture HTTP, il doit voir l'hôte, le chemin et la portée de la requête. Chaque action a besoin d'éléments qui correspondent à son risque.

L'erreur récurrente consiste à réduire l'attente en accordant une approbation large de session alors que le réviseur était lent parce que l'action n'était pas claire. Un problème de contexte devient alors un problème d'autorité. Corrigez d'abord la description de la demande et la limite de l'action.

L'erreur inverse existe aussi : certaines équipes exigent une confirmation distincte pour chacune des cent lectures ordinaires parce que la file leur paraît dangereuse. La file est dangereuse parce qu'elle crée une accoutumance. Des invites répétées et peu risquées apprennent au réviseur à approuver selon la forme et le moment, plutôt que selon le contenu. Cette habitude reste présente lorsqu'une demande importante apparaît.

Une file de révision montre que le flux doit changer de forme

Une file ne fait pas que retarder le travail. Elle modifie le comportement de l'agent et de l'humain. L'agent réessaie, découpe une tâche en appels plus petits ou conserve un plan incomplet. L'humain voit une pile grandir et commence à la vider par lots. Chaque réponse rend la file moins alarmante, jusqu'à ce qu'une demande inhabituelle se cache parmi les demandes familières.

Prenons un échec courant. On demande à un agent de préparer une note de version à partir des données d'un outil de suivi des tickets. Il commence par lire la liste des projets, récupère chaque ticket, lit les commentaires des tickets sélectionnés, puis crée une note en brouillon. Un flux qui exige une approbation pour chaque appel HTTP transforme une tâche modeste en dizaines d'invites.

À 9 h 30, un développeur approuve attentivement les premières lectures. À 9 h 45, il part en réunion. À 10 h 30, l'agent a mis en file des nouvelles tentatives et des appels associés. Le développeur revient, voit un mur de demandes vers le même service et les approuve rapidement. L'une d'elles crée un commentaire public au lieu d'une note en brouillon, car le point d'accès et le résultat prévu étaient enfouis dans le texte brut de la requête. Le développeur n'avait aucune chance réaliste de la distinguer dans cette file.

La mauvaise décision a commencé avant le commentaire public. Le flux obligeait les lectures courantes à entrer en concurrence avec une écriture visible. Il obligeait aussi l'humain à conserver le contexte pendant une longue interruption. C'est un défaut de conception, pas un échec du réviseur.

Réparez le problème en regroupant le travail selon une intention significative. Une session de lecture peut couvrir un service nommé et la durée d'une tâche si son autorité ne peut rien modifier. La création d'un brouillon peut demander une décision explicite avec son emplacement et son audience. La publication publique doit rester séparée, car ses conséquences changent la question soumise à révision.

Ne résolvez pas ce problème avec une consigne générale disant qu'un agent peut « utiliser l'outil de suivi des tickets ». Cette phrase cache trop de choses. Elle ne précise pas si l'agent peut lire des tickets privés, modifier des étiquettes, commenter publiquement ou supprimer des données. Les noms des périmètres doivent correspondre à des actions que les personnes peuvent reconnaître plus tard.

La même logique s'applique à SSH. Une demande d'inspection d'un journal de service et une demande d'exécution d'une migration peuvent passer par la même connexion, mais elles n'appartiennent pas à la même classe d'approbation. L'identité de la connexion n'est pas l'identité de l'action.

Le périmètre d'approbation doit suivre la conséquence, pas le transport

Une bonne limite d'approbation décrit ce à quoi une personne consent. HTTP ou SSH, commande ou appel d'API, processus local ou distant sont des détails de transport. Ils comptent pour l'implémentation, mais ne disent pas au réviseur si l'action est réversible, externe ou coûteuse.

Commencez par les classes de conséquences. Les opérations de lecture peuvent divulguer des données, donc « lecture » ne signifie pas automatiquement « sans danger ». Les écritures diffèrent elles aussi : créer un brouillon privé, modifier un paramètre de production et envoyer un message modifient tous l'état, mais exigent des niveaux d'examen différents. Séparez ces cas avant de décider quelles interactions peuvent partager une approbation.

Limitez ensuite le périmètre selon les dimensions qu'un réviseur peut vérifier :

• Cible : hôte, dépôt, projet ou environnement nommé.
• Opération : lire, créer un brouillon, modifier un champ précis ou exécuter une famille de commandes nommée.
• Ensemble d'objets : enregistrements, fichiers ou services concernés.
• Durée : une action, une exécution d'agent ou une courte fenêtre planifiée.
• Conséquence : privée, réversible, visible à l'extérieur ou destructive.

Évitez les périmètres fondés sur des détails d'implémentation. « Autoriser les requêtes POST » est une règle de transport, pas une limite d'approbation. Une requête POST peut créer un brouillon ou supprimer un compte. « Autoriser l'accès à la ligne de commande » présente le même défaut. Elle accorde un moyen d'action plutôt qu'un résultat compréhensible.

On justifie souvent une approbation large de session par les interruptions des demandes individuelles. L'observation est juste, mais le remède ne convient pas lorsque la session peut mélanger des opérations sans rapport. Une session ne convient que si sa cible et ses conséquences autorisées restent lisibles pendant toute sa durée. Si l'agent passe de la collecte de notes de version à la modification des permissions d'un dépôt, il a besoin d'une nouvelle décision.

Utilisez une confirmation par action lorsque la conséquence reste importante, même au sein d'une exécution autrement fiable. La publication, la suppression, la rotation d'informations d'accès, la modification de l'accessibilité réseau et l'envoi d'informations hors de l'équipe appartiennent généralement à cette catégorie. N'utilisez pas la confirmation par action comme sanction pour le travail inhabituel. Réservez-la aux cas où chaque occurrence exige un jugement humain.

Repenser le travail courant avant d'assouplir les contrôles

Lorsque la latence d'approbation dépasse son budget, commencez par supprimer les demandes qui n'auraient jamais dû devenir interactives. Cela ne signifie pas autoriser n'importe quelle action. Il s'agit de rendre le travail courant suffisamment limité pour que l'humain puisse approuver l'exécution ou la tâche, plutôt que chaque sous-appel mécanique.

Traitez une classe lente dans cet ordre :

1. Échantillonnez les demandes au p95 et lisez la séquence complète autour de chacune. Comptez séparément les nouvelles tentatives, les appels en double et les appels nécessaires.
2. Repérez la première action où la conséquence change. C'est souvent le bon endroit pour prendre une décision explicite.
3. Regroupez les lectures déterministes dans une portée de tâche étroite, avec une cible connue et une expiration à la fin de l'exécution.
4. Séparez la publication externe, la suppression, les changements d'autorisation et l'exportation de grands volumes de données.
5. Retestez la tâche avec un vrai réviseur qui n'a pas conçu le flux. S'il ne peut pas énoncer le résultat attendu avant d'approuver, réduisez encore la demande.

Le regroupement n'aide que si le lot lui-même peut être examiné. « Créer ces quatre tickets en brouillon dans le projet Amber » est un lot raisonnable si la fiche nomme les quatre tickets et leur destination. « Effectuer tout le travail de version restant » n'est pas un lot. C'est une délégation sans limite.

Ne laissez pas l'agent choisir la limite d'un lot uniquement pour des raisons pratiques. Donnez-lui un objet de tâche comprenant la cible, le résultat demandé, les sources de données autorisées et l'expiration. L'agent peut réunir les appels sous cet objet, mais un changement de cible ou de conséquence doit fermer le lot. Cela facilite aussi l'examen des incidents, car le journal reflète une véritable unité de travail plutôt qu'un long flux de demandes anonymes.

Le travail planifié demande une autre refonte. Si une personne doit approuver une maintenance nocturne pendant la nuit, l'équipe a créé un échec prévisible. Planifiez une fenêtre d'examen avant l'exécution, attribuez un responsable d'astreinte avec un budget adapté ou reportez le travail. Ne présentez pas une approbation sans surveillance comme de l'automatisation.

La possibilité de réessayer mérite une attention particulière. L'agent doit réutiliser le même identifiant de demande en attente lorsque l'action sous-jacente n'a pas changé. Créer une nouvelle fiche pour chaque nouvelle tentative gonfle artificiellement la file et détruit le fil de compréhension du réviseur. Si la cible, la charge utile, l'autorité ou la conséquence prévue change, créez une nouvelle demande et indiquez ce qui a changé.

L'écran d'approbation doit faciliter la bonne décision

Le réviseur a besoin d'une déclaration concise de l'intention, pas d'une invitation à reconstituer une exécution d'agent. Concevez l'écran autour de la décision à prendre maintenant, puis proposez des éléments plus détaillés sans l'obliger à les chercher.

Placez d'abord le résultat de l'action : « Créer une note de version privée en brouillon dans le projet Amber » en dit plus qu'une méthode et un chemin. Affichez la cible à côté. Indiquez si l'action lit, modifie, supprime ou envoie des données. Si elle utilise SSH, nommez l'hôte et affichez la commande de façon à rendre visibles les redirections, les écritures de fichiers et les changements de privilèges.

Affichez aussi le contexte d'autorité. Le réviseur doit savoir si la demande vient d'un nouveau processus d'agent ou d'une exécution déjà approuvée, et si cette action exige une confirmation particulière. L'identité du processus compte, car l'approbation d'un processus d'agent ne doit pas autoriser silencieusement un autre processus qui utilise le même protocole.

Sallyport utilise pour cela une échelle de décision fixe : un coffre-fort verrouillé refuse toute action, un nouveau processus d'agent reçoit par défaut une autorisation de session et un identifiant peut exiger une approbation à chaque utilisation. La première fiche de session met en avant l'autorité de signature du code du processus, ce qui est le bon détail à présenter à une personne qui doit vérifier qu'il s'agit bien de l'exécution qu'elle souhaitait lancer.

Ne transformez pas l'écran en éditeur de règles. Face à une échéance, le réviseur doit pouvoir approuver, refuser ou examiner une demande concrète. Si une équipe demande régulièrement une exception, repensez la portée de la tâche ou la limite de l'identifiant en dehors du moment d'interruption. Placer un mini-langage de règles dans le parcours d'approbation revient à demander à des personnes fatiguées de programmer des décisions de sécurité sous pression.

Un refus doit être explicite. Renvoyez une catégorie de motif sur laquelle l'agent peut agir, comme expirée, mauvaise cible, portée à réduire ou examen humain requis. Par défaut, ne transmettez pas à un agent non fiable les commentaires privés du réviseur. L'agent a besoin de suffisamment d'informations pour arrêter ses nouvelles tentatives ou choisir une autre tâche sûre, pas d'une transcription des délibérations internes.

Définir la responsabilité et l'escalade avant l'urgence

Un budget d'approbation sans responsable reste un simple souhait. Chaque classe d'action a besoin d'une personne ou d'une rotation responsable de la décision pendant la période où elle peut s'exécuter. Une équipe peut déléguer l'examen, mais elle ne peut pas déléguer le fait que quelqu'un doit décider.

Définissez ce qui se passe à chaque limite du budget. À la moitié du budget, le système peut avertir une fois le réviseur désigné si la demande n'a pas encore été consultée. À la limite, une demande à faible conséquence peut expirer. Une demande importante doit expirer et prévenir le responsable de la tâche ou la rotation d'astreinte, plutôt que rester en attente indéfiniment. Le moment exact compte moins que le fait de rendre l'état visible et fini.

Soyez honnête sur les heures ouvrées. Si un développeur exécute un agent localement la nuit et que l'action nécessite l'approbation d'un collègue, la tâche devra peut-être attendre. C'est acceptable. L'échec survient lorsque l'interface laisse croire à une progression immédiate, puis laisse l'agent réessayer face à une file sans surveillance.

Une escalade ne doit jamais élargir l'autorité. Une demande escaladée est transmise à un réviseur mieux placé, pas à un chemin d'autorisation automatique. Cette distinction compte pendant les incidents, lorsque l'urgence pousse à vouloir contourner tous les contrôles. Des procédures d'urgence préapprouvées peuvent exister, mais elles doivent décrire une action étroite, un responsable nommé et un examen ultérieur. « La production est en panne » n'est pas une portée d'approbation.

Examinez le coût humain autant que le délai de l'agent. Si un seul développeur reçoit presque toutes les invites, l'équipe a un problème de routage même lorsque la latence médiane est bonne. Si chaque réviseur voit chaque demande, l'équipe a créé une boîte de réception partagée avec des étiquettes de sécurité. Ces deux modèles produisent de la fatigue et une responsabilité faible.

Examiner la file comme une suite de décisions

Une piste d'audit utile permet de reconstituer davantage que l'action finale. Elle doit montrer l'exécution de l'agent, la demande présentée au réviseur, la décision, l'appel externe réel, ainsi que les annulations et les nouvelles tentatives. Sans cette séquence, l'équipe ne peut pas déterminer si une approbation tardive a provoqué une action obsolète ou si l'agent a changé de plan après un refus.

Reliez les éléments de preuve de l'approbation et de l'action avec des identifiants, mais ne les confondez pas. L'approbation répond à la question de savoir qui a autorisé une intention formulée. L'enregistrement de l'action répond à la question de savoir ce qui a réellement été tenté et ce que la cible a renvoyé. L'enquêteur a besoin des deux lorsqu'une demande d'agent échoue à mi-parcours ou qu'un service distant interprète une charge utile de façon inattendue.

Sallyport produit un journal Sessions et un journal Activité à partir d'un même journal d'audit chiffré et chaîné par hachage. Sa commande sp audit verify vérifie hors ligne la chaîne sur le texte chiffré sans nécessiter la clé du coffre-fort. C'est utile lorsqu'il faut tester l'intégrité du journal sans ouvrir les identifiants des agents.

Utilisez le journal d'audit lors d'un examen hebdomadaire des exceptions, plutôt que comme un entrepôt de données que personne ne lit. Extrayez les demandes expirées, les exemples de p95 les plus lents, les actions refusées et les actions exécutées après une longue attente. Pour chacune, posez une question concrète : le délai venait-il de la responsabilité, d'une intention floue, d'une portée trop large ou d'une tâche qui aurait dû être planifiée autrement ?

Ne mesurez pas les personnes à leur vitesse d'approbation. Évaluez le flux selon sa capacité à placer une décision compréhensible entre les mains d'une personne responsable avant l'échéance de la tâche. Si une révision répétée ne produit que des autorisations machinales, supprimez cette répétition. Si une action rare demande une réflexion attentive, donnez-lui le temps, le contexte et la responsabilité nécessaires.

Commencez par recueillir une semaine d'horodatages du cycle de vie. Choisissez la classe d'action dont l'attente en file au p95 est la plus mauvaise, examinez dix séquences complètes de demandes et modifiez la limite qui a créé le plus d'invites en double. Ce travail vous apprendra davantage qu'un nouveau tableau de bord.