Aller au contenu
Pratique agentique

Échec fermé ou échec ouvert

Quand un hook plante ou dépasse son délai, il faut décider s'il bloque (échec fermé) ou laisse passer (échec ouvert). Les secrets et l'irréversible bloquent ; le formatage laisse passer.

  • fail-closed
  • fail-open
  • échec fermé
  • échec ouvert
  • timeout
  • hooks

Syntaxe

Modèle
Échec fermé (fail-closed) : en cas d'erreur, l'action est refusée → git push, lecture de secrets, productionÉchec ouvert (fail-open)  : en cas d'erreur, l'action continue et l'erreur est journalisée → formatage, rappelsToujours : un filet indépendant du hook (permission deny) pour les actions critiques

Exemple

Exemple concret
Hook « bloquer git push --force », Node absent sur le poste d'un stagiaire :  écrit en échec ouvert : le script plante, le push forcé passe          ← à éviter  écrit en échec fermé  : un wrapper shell refuse si le script ne répond pasHook « prettier après édition », délai dépassé :  la sauvegarde continue, l'erreur est journaliséeRésultat attendu : aucune panne d'outillage ne laisse passer un push forcé,et aucune panne du formateur ne bloque le travail.

À retenir

  1. Vérifiez le comportement par défaut de votre outil : dans Claude Code, un hook qui plante avec un code d'erreur ordinaire ne bloque pas ; seuls le code de sortie 2 ou une décision deny explicite bloquent. L'échec fermé se programme.
  2. Journalisez chaque refus avec son motif : sans trace, impossible de comprendre pourquoi l'agent a été bloqué.
  3. Réglez un délai adapté : un délai trop court sur un hook en échec fermé bloque toute l'équipe à la première lenteur.
  4. Piège : un try/catch global qui traite toutes les erreurs de la même façon. Il rend tous les hooks ouverts, ou tous fermés ; décidez hook par hook.

Voir aussi