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.