Documentation

Gating par confiance et escalade vers un humain

La page précédente soutenait que le code doit posséder le seuil. Cette page porte sur ce que le seuil sépare — les trois bandes de part et d’autre.

Trois bandes, pas deux

Les vrais projets en font rarement « automatique ou non ». Trois bandes, c’est la forme courante :

Bande Condition Action
Automatique Confiance au-dessus du seuil haut et vérifications supplémentaires réussies Fais-le, tout simplement
Escalade Tombe au milieu Passe à un humain
Rejet Confiance sous le seuil bas Ne fais rien, et ne dépense pas non plus l’attention d’un humain

La troisième bande est facile à négliger et c’est la moins chère des trois. « Non regardé » et « une personne y jette un œil » diffèrent d’un humain.

Une implémentation de triage est typique : alerter seulement quand P(SEV1) + P(SEV2) ≥ 0.80 ; rejeter sous 0.20 seulement quand une vérification de l’actionnabilité n’est pas d’accord non plus ; envoyer la bande intermédiaire à un humain.

La bande intermédiaire, c’est là que vivent les vrais problèmes

Une fois les trois bandes en place, chaque question difficile se déplace dans celle du milieu :

C’est de la capacité humaine, pas de la capacité disponible. Plus la bande est large, plus il y a d’escalades, plus une personne en traite. Un taux d’escalade de 9% semble bas — jusqu’à ce que le taux de base soit de plusieurs milliers par jour.

Il lui faut un filet de sécurité, sinon elle se coince silencieusement. Une fois que tu confies une décision à un humain, rien ne se passe tant qu’un humain ne regarde pas. Sur un tableau de bord, cela ressemble exactement à « tout va bien ». La réponse de l’outil de triage est brutale : sans accusé de réception sous 15 minutes, alerte quand même. Mieux vaut réveiller quelqu’un que laisser un P1 s’empiler dans une file.

La condition d’escalade elle-même peut échouer. Une barrière d’autonomie dans un agent ne continue que si un Choice dépasse 0.6 et qu’un Noul de sûreté d’autonomie dépasse 0.5, rendant sinon la main à l’humain. Les deux nombres doivent passer — parce que « que dois-je faire » et « est-ce sûr » sont des questions distinctes, et une seule confiance ne peut pas honnêtement répondre aux deux.

Fixer le seuil : mesurer d’abord

Choisir 0.8 au hasard est l’approche la plus courante et celle qui a le plus de chances de devenir du bruit trois mois plus tard. L’approche reproductible consiste à mesurer, sur tes propres données étiquetées, le seuil nécessaire pour atteindre ta précision cible.

Un exemple public : avec 0.7 comme barrière de basse confiance, une passe sur n=130 a attrapé 3 sur 3 mauvaises classifications à un taux d’escalade de 9%. L’échantillon est petit. Sa valeur n’est pas le 0.7 — c’est que voilà comment un tel nombre devrait être rapporté : taille d’échantillon, taux d’escalade, et ce qui a été attrapé.

La latence est le risque sous-estimé

Les chiffres mesurés de l’outil de triage méritent leur propre tableau :

Mesure Valeur
p50 418 ms
p95 1477 ms
Coût environ 0.04 $ par millier
Appel le plus lent à 151 ms de son propre délai d’expiration de 2 secondes

Le p95 est 3.5× le p50. Cela signifie que la queue compte plus que la moyenne — parce que la politique de délai se déclenche dans la queue, et quand elle se déclenche tu es sur la branche de repli, pas sur celle que tu avais conçue. L’appel le plus lent est arrivé à 151 ms du délai d’expiration, autrement dit le déterminisme du système dépendait d’une pièce qui s’est trouvée ne pas mal tomber.

Donc les systèmes de gating échouent en général non pas en « jugeant mal » mais en expirant et prenant le repli. Teste le repli indépendamment du chemin principal.

Deux directions de repli, toutes deux correctes

Quand quelque chose échoue, les implémentations publiques se divisent en deux camps, et les deux ont raison :

  • fail-closed : un juge de permissions refuse en cas de délai dépassé ou d’erreur. Une barrière de sûreté doit fonctionner ainsi — une barrière de sûreté fail-open est un trou silencieux.
  • fail-open : un hook Stop de Claude Code autorise en cas d’erreur. Une barrière d’efficacité doit fonctionner ainsi — une barrière d’efficacité fail-closed bloque tout le flux.

Le critère n’est pas « lequel est plus sûr » mais quel coût est le plus grand : un faux blocage ou un blocage manqué. Et il faut le décider au moment d’écrire le code, parce que ce qu’il détermine c’est le chemin d’exception, pas le chemin principal.

En une phrase

Dans une conception à trois bandes, le travail est dans la bande du milieu : sa largeur est un coût, son filet de sécurité est une propriété de fiabilité. Conçois les deux explicitement plutôt que par défaut.