Jidoka, andon et poka-yoke dans un orchestrateur¶

Une carte de contrôle détecte. Elle ne dit pas quoi faire. Le système de production de Toyota a apporté les trois réponses complémentaires que le SPC de Shewhart laissait ouvertes : arrêter automatiquement la ligne sur une anomalie (jidoka), signaler l'arrêt pour qu'un humain intervienne (andon), et rendre l'erreur physiquement impossible (poka-yoke). Ce chapitre les transpose à un orchestrateur d'agents.

Poka-yoke : rendre l'erreur impossible¶

Le principe¶

Le poka-yoke (« anti-erreur »), formalisé par Shigeo Shingo, désigne un dispositif qui empêche une erreur de se produire, ou la rend immédiatement visible : une pièce asymétrique qui ne peut entrer que dans le bon sens, un connecteur qui ne se branche que sur la bonne prise. C'est le niveau de contrôle le plus fort, parce qu'il ne dépend ni de la vigilance ni de la statistique.

Dans un orchestrateur¶

Le poka-yoke d'un agent, ce sont les contrôles déterministes qui s'exécutent à chaque action, quoi que décide le modèle. Les hooks de Claude Code en sont un exemple documenté (documentation) :

Hook	Ce qu'il permet	Équivalent poka-yoke
`PreToolUse`	Bloquer un appel d'outil avant qu'il s'exécute (code de sortie 2), quelle que soit l'autorisation demandée	Le connecteur qui refuse la mauvaise prise
`Stop` / `SubagentStop`	Empêcher l'agent de terminer et relancer la conversation	Le poste qui ne libère pas la pièce tant que le contrôle n'est pas fait
`TaskCompleted`	Empêcher qu'une tâche soit marquée comme terminée	Idem
`PostToolUse`	Réagir après l'action ; ne peut pas bloquer	Détection, pas prévention

Exemples de poka-yoke contre les causes spéciales du chapitre Causes spéciales propres aux agents :

un PreToolUse qui refuse toute écriture dans les répertoires de tests quand la tâche ne porte pas sur les tests — c'est la contre-mesure « tests en lecture seule » d'ImpossibleBench ;
un Stop qui refuse la fin du run tant que la suite de tests ne passe pas ;
un PreToolUse qui refuse les commandes destructrices hors d'une liste blanche ;
un contrôle qui refuse toute dépendance ajoutée absente d'une liste blanche ou inexistante dans le registre de paquets : environ un paquet sur cinq cité par un modèle n'existe pas, et ces inventions sont reproductibles donc exploitables (Sécurité du code généré).

Erreur fréquente : un hook n'est pas une barrière de sécurité

La documentation de Claude Code précise que pour imposer une autorisation ou une interdiction, il faut utiliser le système de permissions plutôt qu'un hook, dont certains filtres ne sont appliqués « au mieux ». Un poka-yoke de qualité et une barrière de sécurité sont deux choses différentes ; la seconde relève des permissions, du bac à sable et des droits d'accès.

Poka-yoke plutôt que consigne¶

ImpossibleBench montre qu'une consigne stricte peut réduire fortement la triche sur certaines tâches, mais que les tests en lecture seule offrent un meilleur compromis. METR observe qu'une consigne « ne triche pas » ne change rien sur une tâche où o3 trichait. La leçon industrielle est la même : une instruction est un contrôle faible ; un dispositif est un contrôle fort. Chaque fois qu'une règle d'un skill ou d'un prompt système peut être vérifiée mécaniquement, elle devrait l'être par un hook ou par la CI, pas par la bonne volonté du modèle.

Jidoka : arrêter la ligne sur une anomalie¶

Le principe¶

Le jidoka (souvent traduit « autonomation ») remonte au métier à tisser automatique de Sakichi Toyoda, qui s'arrêtait seul quand un fil cassait. Le principe : une machine qui détecte une anomalie s'arrête plutôt que de continuer à produire des pièces défectueuses. On arrête la ligne pour un défaut afin de ne pas en produire mille.

Dans un orchestrateur¶

Un orchestrateur 100 % automatisé est une ligne qui peut produire beaucoup de défauts très vite. Le jidoka consiste à suspendre automatiquement la fusion (pas nécessairement la production) quand une carte de contrôle sonne :

Niveau d'alarme	Action automatique
Un run échoue	Rien : c'est de la variation de cause commune
Alarme de règle 1 sur une caractéristique critique	Passer en revue humaine obligatoire pour les runs suivants du même type
Alarme confirmée par deux règles ou deux caractéristiques	Suspendre la fusion automatique pour ce type de tâche
Signal de contournement (tests modifiés, `skip` ajoutés) sur un run	Bloquer la fusion de ce run, quelle que soit la carte

La dernière ligne est importante : un signal de triche n'est pas une question statistique. C'est un défaut critique, traité unitairement.

Andon : rendre l'arrêt visible¶

Le principe¶

L'andon est le tableau lumineux (et la corde que tire l'opérateur) qui signale un arrêt ou un problème sur la ligne, pour qu'un responsable vienne immédiatement. Il transforme une anomalie locale en information partagée.

Dans un orchestrateur¶

L'équivalent est une notification qui porte l'information nécessaire à l'enquête, pas seulement l'alarme : quelle carte, quelle règle, quels runs, et quelles étiquettes ont changé depuis le dernier point en contrôle (modèle, prompt, skill, environnement — voir Instrumenter la chaîne). Une alarme qui oblige à chercher ce qui a changé sera ignorée au bout de quelques fausses alarmes.

Une règle de décision à plusieurs niveaux : l'exemple des laboratoires¶

Le problème « combiner plusieurs règles en une décision accepter/rejeter » a été résolu dans un autre domaine : le contrôle qualité des laboratoires d'analyses médicales, avec les règles de Westgard (détaillées dans Autres familles de règles). Leur architecture est directement réutilisable pour une barrière de fusion :

une règle d'avertissement sensible, qui ne rejette rien mais déclenche l'examen des autres règles ;
des règles de rejet spécifiques, chacune ciblée sur un type d'erreur (erreur aléatoire, erreur systématique) ;
une décision qui ne rejette que si une règle de rejet est violée.

Transposé à un orchestrateur :

Rôle	Règle proposée
Avertissement	Un lot de runs sous la limite à 2σ de la carte p
Rejet, erreur brutale	Un lot sous la limite à 3σ
Rejet, dérive	Deux lots consécutifs sous 2σ, ou 8 lots de suite sous la moyenne
Rejet, instabilité	Écart entre deux lots consécutifs supérieur à 4σ

Cette table est une proposition de ce rapport, pas une pratique publiée dans le domaine des agents. Sa justification est que le même compromis (détecter vite sans rejeter trop souvent des séries correctes) a été optimisé pendant quarante ans dans les laboratoires.

À retenir

Poka-yoke : tout ce qui peut être vérifié mécaniquement doit l'être par un dispositif (hook, CI, permissions), pas par une consigne.
Jidoka : une alarme statistique suspend la fusion automatique ; un signal de triche bloque le run concerné sans attendre la statistique.
Andon : l'alarme porte avec elle ce qui a changé.
Règles multiples : s'inspirer des laboratoires, avec un avertissement qui ne rejette rien et des rejets ciblés.