Chapitre 7.2 — Les hooks utiles

⏱️ TL;DR — Trois hooks couvrent 90 % du besoin : formater après édition (PostToolUse → prettier), linter après édition (feedback immédiat, souvent en auto-fix), et tester à la conclusion (Stop → refuse de finir si les tests cassent). La règle d’or : les hooks doivent rester rapides — on formate à chaque édition (léger), mais on lance la suite de tests à la fin (Stop), pas après chaque frappe. Bien dosés, ils transforment tes consignes répétées en garanties invisibles.

🎯 Objectifs

• Mettre en place les trois hooks de base (format, lint, test).
• Placer chaque hook sur le bon événement pour rester rapide.
• Comprendre le pattern auto-fix vs blocage.
• Éviter les hooks qui ralentissent le travail.

1. Formater après édition

Le plus simple et le plus rentable. Après chaque Edit/Write, on formate — le code reste propre sans que personne n’y pense.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npx prettier --write ." }]
      }
    ]
  }
}

Effet : fini les diffs pollués par des histoires de formatage, fini « n’oublie pas de formater » dans le CLAUDE.md (tu peux même supprimer cette ligne — 3.2). C’est la couche « imposer » qui allège la couche « énoncer ».

💡 Réflexe d’architecte — Cible le formatage sur ce qui a changé quand c’est possible (formater le fichier édité plutôt que tout le repo), pour rester rapide. Un hook lent, c’est un hook qu’on finit par désactiver. Vitesse = pérennité du hook.

2. Linter après édition (souvent en auto-fix)

Le lint attrape les vraies erreurs (variable inutilisée, any, import interdit). Deux modes :

• Auto-fix : eslint --fix corrige ce qui est corrigeable automatiquement. À privilégier — l’agent n’a même pas à s’en occuper.
• Signalement : le lint remonte les erreurs non auto-fixables ; l’agent les voit et corrige dans la foulée.

{
  "matcher": "Edit|Write",
  "hooks": [{ "type": "command", "command": "npx eslint --fix ." }]
}

C’est là que ta règle no-any (P3/P4) devient une garantie : le lint la vérifie mécaniquement, à chaque édition. La convention ne repose plus sur l’attention du modèle.

3. Tester à la conclusion (Stop)

Le plus puissant pour la justesse : un hook Stop qui lance les tests quand l’agent s’apprête à conclure. S’ils échouent, l’agent ne peut pas finir sur du cassé — il voit l’échec et corrige.

{
  "hooks": {
    "Stop": [
      { "hooks": [{ "type": "command", "command": "npm test" }] }
    ]
  }
}

C’est la matérialisation de « exiger la preuve » (5.4) : « les tests passent » n’est plus une affirmation de l’agent, c’est vérifié par le harness avant qu’il ait le droit de conclure.

⚠️ Piège — Lancer toute la suite de tests à chaque PostToolUse (après chaque édition). Sur un projet réel, c’est insupportablement lent : l’agent édite dix fois, tu attends dix fois la suite complète. La bonne place des tests longs, c’est Stop (une fois, à la fin). Réserve PostToolUse au léger (format, lint du fichier).

Le bon dosage : léger souvent, lourd à la fin

La logique : ce qui est rapide et local va sur PostToolUse ; ce qui est lent et global va sur Stop. Tu obtiens un feedback immédiat sur le trivial et une garantie de fin sur le sérieux, sans jamais ramer.

Ce que ça change dans ton CLAUDE.md

Rappelle-toi les marqueurs [futur hook] du CLAUDE.md de TaskFlow (3.5). Une fois ces hooks en place, tu peux alléger : la ligne « lance lint + test + build avant de conclure » est désormais garantie par les hooks Stop/PostToolUse. Tu la gardes en rappel léger, ou tu la supprimes — la garantie est ailleurs. Durcir l’application permet d’alléger l’énoncé (3.3).

🧭 Sur TaskFlow — En 7.4, on met exactement cette chaîne : prettier + eslint —fix en PostToolUse, npm test en Stop. À partir de là, toute contribution à TaskFlow — la tienne, un agent en autonomie (5.3), un collègue — est forcément formatée, lintée, et testée verte. Le filet de sécurité qui autorise plus d’autonomie (5.3) est en place.

✏️ Exercices

Exercice 1 — La chaîne de base. Sur un projet, ajoute les deux hooks légers (prettier + eslint —fix en PostToolUse) et le hook lourd (npm test en Stop). Vérifie qu’une édition déclenche le format et qu’une tentative de conclure sur un test rouge est bloquée.

Exercice 2 — Allège le CLAUDE.md. Repère dans ton CLAUDE.md les lignes désormais garanties par un hook (format, lint, tests). Supprime-les ou réduis-les à un rappel. Le fichier a-t-il maigri ?

🧠 Quiz de révision

Chapitre suivant : Garde-fous & sécurité — bloquer ce qui ne doit jamais passer.