Le hook est le mécanisme de garantie, pas le prompt

Votre agent a maintenant des mains. Il exécute des commandes, édite des fichiers, appelle des APIs, envoie des e-mails, déplace l'argent. Posez donc la question qui devrait vous rendre légèrement nerveux : qu'est-ce qui l'empêche d'utiliser ces mains mal ? Pour la plupart des équipes, la réponse est le bon jugement du modèle — un système probabiliste qui, selon la façon dont vous avez formulé le prompt, pourrait décider qu'aujourd'hui est le jour où il lance la commande de nettoyage sur le mauvais dossier. Le guide de juillet 2026 sur les Claude Code hooks de Professor Glitch sur askglitch.com nomme la solution : un hook est du code déterministe qui se déclenche à un point fixe de la boucle de l'agent, et le modèle ne peut pas le contourner. La propriété qui vous importe est garantie par le mécanisme, pas en demandant au modèle d'être prudent.

Un hook, c'est le Théorème 3 en code

Un hook est du code déterministe qui s'exécute automatiquement à un point fixe de la boucle de l'agent — avant qu'un outil ne s'exécute, après qu'il a terminé, quand l'agent déclare fini, quand la session se termine. Il ne fait pas partie du raisonnement du modèle. Il se tient hors du cerveau, et il tourne. Le guide de hooks de juillet 2026 de Professor Glitch sur askglitch.com pose la distinction clairement : le modèle est probabiliste, chaque instruction est une suggestion qu'il suivra probablement ; un hook est du code qui tourne à chaque fois, au même point, avec les mêmes règles, et le modèle ne peut pas l'oublier, le sauter ni le contourner.

[ORIGINAL DATA] C'est le Théorème 3 des 21 papers : une propriété est garantie exactement lorsque son mécanisme est implémenté et mesure. Le hook est ce mécanisme. « Les tests passent avant que l'agent déclare fini » est une propriété. Un hook Stop qui lance la suite et sort avec le code 2 sur un échec est le mécanisme implémenté et mesurant. Retirez le hook et vous avez un vœu. Gardez le hook et vous avez une garantie — non parce que le modèle est devenu plus intelligent, mais parce que le chemin d'échec est désormais physiquement impossible.

Le prompt dit « lancez toujours les tests avant de finir ». C'est une suggestion que le modèle honorera probablement. Le hook refuse le stop jusqu'à ce que la suite soit verte. C'est une règle. La différence entre une suggestion et une règle est la différence entre espérer et savoir, et cette différence est toute la discipline. Imaginez le modèle comme la foule et le hook comme le videur à la porte, écrit Professor Glitch : la foule peut être charmante autant qu'elle veut, le videur vérifie tout le monde, à chaque fois, sans exception.

Le modèle est probabiliste ; la frontière est déterministe

Mécaniquement, selon la documentation officielle des hooks, un hook Claude Code est une commande shell que vous enregistrez dans un fichier de configuration. Quand l'événement se déclenche, Claude Code lance votre commande, envoie un payload JSON décrivant l'événement dans stdin — le nom de l'outil, l'entrée exacte, l'identifiant de session, le répertoire de travail — et lit votre verdict depuis le code de sortie et stdout. Sortie 0 signifie continuer. Sortie 2 signifie bloquer, et ce que vous avez imprimé sur stderr est renvoyé au modèle comme raison. Vous les écrivez dans ce que vous voulez : Bash, Python, un binaire compilé. S'il lit stdin et renvoie un code de sortie, c'est un hook.

[UNIQUE INSIGHT] C'est « the space is the router » à la frontière de l'agent. Dans Everythink, la topologie network→community→room route une requête avant que quoi que ce soit réponde — l'espace décide à qui on s'adresse, pas le répondant. Un hook PreToolUse est le même motif un niveau plus bas : le hook route l'appel d'outil avant que l'outil ne s'exécute. L'agent ne choisit pas si sa lecture de .env continue ; la frontière décide. Le routage précède la récupération, et à la frontière de l'outil le hook précède l'exécution.

Le piège qui attrape presque tout le monde, tiré de la documentation : seul le code de sortie 2 bloque. Le code de sortie 1 — le code d'échec conventionnel d'Unix — est traité comme une erreur non bloquante et l'action continue quand même. Si votre script de garde plante avec la sortie 1, le videur vient de laisser passer toute la foule. Écrivez vos hooks pour que le chemin d'échec soit explicite, et préférez la forme de sortie JSON (permissionDecision: "deny" sur stdout avec sortie 0) quand la décision doit être sans ambiguïté. Une barrière qui échoue silencieusement en ouvert est pire qu'aucune barrière, parce qu'elle vend le sentiment de sécurité sans le mécanisme. Le Théorème 3 est impitoyable ici : un mécanisme implémenté mais qui ne mesure pas ne garantit pas la propriété. Un hook qui plante en ouvert ne mesure pas.

Travail un : rendre certains échecs impossibles

Professor Glitch liste trois barrières qu'il utilise réellement, par ordre croissant de ce qu'elles lui ont sauvé. Le motif à travers les trois est le même : vous ne rendez pas le modèle plus intelligent ni plus prudent. Vous rendez certains échecs impossibles. Ce sont des problèmes d'ingénierie différents, et le second est bien plus facile à résoudre.

Bloquer les lectures du fichier de secrets

Un hook PreToolUse voit chaque appel d'outil avant qu'il ne s'exécute, avec l'entrée complète. Si l'agent est sur le point de lire .env ou quoi que ce soit sous secrets/, le hook sort avec 2 et la lecture n'arrive jamais. Froid. Peu importe combien la justification de l'agent était raisonnable, ou si une injection de prompt enfouie dans une page web a demandé poliment. Le videur ne débat pas.

Bloquer les commandes destructives

Le même événement, associé à l'outil Bash. Le hook inspecte la chaîne de commande dans tool_input.command avant qu'elle ne lance — rm -rf pointant vers quelque chose de sensible, un force push, un DROP TABLE, ce que ressemble votre liste personnelle de cicatrices. Niez-le en code et c'est tout simplement impossible, peu importe où le modèle reasoning mène.

Rejeter « fini » jusqu'à ce que les tests passent

C'est celui qui compte le plus, et il utilise un événement différent. Claude Code déclenche un événement Stop quand l'agent finit de répondre. Votre hook tourne à ce moment. S'il sort avec 2, l'agent est empêché de s'arrêter ; votre message stderr retourne au modèle, et il retourne au travail. L'agent dit « c'est bon, j'ai livré la fonctionnalité ». Le hook Stop lance silencieusement la suite de tests. Trois échecs. Le hook sort avec 2 avec la sortie d'échec. L'agent ne peut pas déclarer fini. Il est renvoyé dans la boucle avec le bug en main.

Le stop refusé est la garantie qui compte

Tout le monde comprend que les hooks peuvent bloquer une mauvaise action. Le geste sous-estimé, c'est qu'un hook peut bloquer un mauvais stop. C'est ici que l'argument de la source et le Théorème 3 se rencontrent le plus clairement.

« Lancez toujours les tests avant de finir » dans votre prompt est une suggestion. Un hook Stop qui refuse le stop est une règle. L'agent ne peut littéralement pas déclarer victoire tant que la suite est rouge. Deux notes pratiques du guide : gardez la vérification rapide et déterministe, parce qu'elle tourne à chaque stop ; et assurez-vous qu'un échec réel produise un message réparable, parce que ce texte stderr est la seule orientation que reçoit l'agent. « Tests échoués » l'envoie errer. La sortie réelle de l'échec l'envoie droit au bug.

[PERSONAL EXPERIENCE] La HAI Engine tourne en production depuis 2016, et la leçon de ces années est la même : les propriétés que nous garantissons — probabilités normalisées en exactement un endroit, scénarios triés descendant, entropie en nats — vivent dans le code d'ensemble de l'Oracle, pas dans un prompt demandant aux Sisters d'être prudentes. Les Sisters imaginent ; l'Oracle fusionne. La normalisation est le hook. Elle tourne à chaque fois, au même point, avec les mêmes règles, et aucune Sister ne peut la convaincre de livrer un cône dont les probabilités somment à 1,05. C'est le Théorème 3 : la propriété tient parce que le mécanisme est implémenté et mesure.

Le même motif fonctionne un niveau plus bas : SubagentStop se déclenche quand un sous-agent finit, donc le travail délégué peut être tenu au même standard que la boucle principale. En termes Everythink, c'est pourquoi the space is the router — une room route vers le bon sous-agent, et le stop du sous-agent est gated par la même frontière qui gâte le parent. La garantie se compose à travers la topologie. Une network route vers une community, une community vers une room, une room vers un sous-agent, et à chaque frontière la même discipline s'applique : le mécanisme garantit la propriété, pas le jugement du répondant.

Travail deux : le journal de fin de poste

Les barrières sont ce pour quoi tout le monde utilise les hooks. Il y a un second travail dont presque personne ne parle : les hooks sont comment la mémoire d'un agent s'écrit.

Votre agent lit déjà la mémoire ; la récupération tire les faits pertinents dans la fenêtre quand une tâche commence. Mais quelque chose doit classer les nouveaux faits — la préférence que vous avez exprimée, l'approche qui a fonctionné, l'erreur qu'il vaut mieux ne pas répéter. Ce quelque chose est un hook. Claude Code déclenche SessionEnd quand une session se termine. Il ne peut rien bloquer ; sa sortie est ignorée ; il existe purement pour les effets de bord. Ce qui est exactement ce qu'est une écriture de mémoire : prend le chemin du transcript depuis stdin, distille la conversation, ajoute le durable à votre stock.

C'est le journal de fin de poste, sauf que le journal s'écrit lui-même, chaque poste, parce que c'est une règle et pas une humeur. La prochaine session, l'agent entre en sachant déjà ce que celle-ci lui a appris.

Deux règles empêchent que cela devienne un jouet. Gâtez l'écriture : la plupart des messages sont « merci » et « compris », donc écrivez en fin de session et laissez le prompt finir par « si rien n'est durable, n'écrivez rien ». Tout stocker n'est pas de la mémoire, c'est du fouillis. Et utilisez le modèle bon marché : distiller un transcript en un paragraphe n'est pas du raisonnement difficile. Le modèle senior pense pendant la session ; le stagiaire rédige le compte-rendu après.

Cela correspond à une discipline que nous maintenons dans les 21 papers : une mesure qui n'est pas gated est du bruit. L'Oracle ne journalise pas chaque brouillon de Sister — il journalise l'ensemble normalisé, l'entropie, la trace de calibration. Le hook SessionEnd est la même porte à la frontière de la mémoire : écrivez le fait durable, jetez le bruit. Un système de mémoire qui stocke tout ne se souvient de rien.

La carte des événements

Claude Code expose une trentaine d'événements. Ceux que vous atteignez en premier, selon la documentation :

• PreToolUse — avant qu'un appel d'outil ne s'exécute ; peut bloquer ; garde des secrets, filtre de commandes destructives.
• PostToolUse — après qu'un appel d'outil a terminé ; retour seulement ; auto-format après les éditions, journaliser chaque commande.
• UserPromptSubmit — quand vous soumettez un prompt ; peut rejeter le prompt ; injecter du contexte, filtrer les prompts.
• Stop — quand l'agent finit de répondre ; peut refuser le stop ; lancer les tests avant d'accepter « fini ».
• SubagentStop — quand un sous-agent finit ; peut bloquer ; tenir le travail délégué à la même barre.
• SessionStart — quand une session commence ; ne peut pas bloquer, ajoute du contexte ; charger l'état du jour dans la fenêtre.
• PreCompact — avant la compactation du contexte ; peut bloquer ; sauver l'état avant que la fenêtre ne soit comprimée.
• SessionEnd — quand une session se termine ; effets de bord seulement ; l'écriture de mémoire.

Notez la symétrie : SessionStart injecte du contexte, SessionEnd écrit l'apprentissage. Cette paire seule est un système de mémoire fonctionnel — et c'est un système de mémoire fait de règles, pas d'humeurs. L'événement PreCompact est la frontière qui empêche la fenêtre de jeter l'état silencieusement : sauvez le jeu de travail avant la compression, et l'agent reprend depuis le fait, pas depuis le résumé.

Ce qu'Everythink garantit ainsi

La HAI Engine ✅ est le système de production que cette discipline produit. Les Sisters ✅ sont les imagineuses ; l'Oracle ✅ est le fusionneur ; la normalisation de l'ensemble est le hook qui garantit que les probabilités somment à un. World Monitor ✅ route des géo-signaux en direct via une passerelle qui borne le volume d'appels en amont par notre calendrier, pas par le nombre de clients — un hook de rate-limit au niveau de l'architecture. Social ✅, Campaigns ✅ et Whitelabel Network ✅ sont les modules où les règles de routage d'une network sont appliquées en code, pas dans une directive de marque.

Les modules Partial ⚠️ — Matchmaking, Marketplace, Calendar — sont mesurés mais pas encore fully hardened ; nous le disons. Les modules Roadmap 🔵 — Wallet & Token, Super App, Community Credit — sont pre-revenue et soumis à la révision Howey ; nous ne promettons pas de résultats pour eux, et aucun hook que nous livrons ne peut changer cette honnêteté. Un hook peut garantir une propriété ; il ne peut pas garantir un marché.

La souveraineté du client est la version la plus profonde de ce motif. Votre network, votre marque, vos données — les règles de routage sont vôtres parce qu'elles vivent dans du code que vous contrôlez, pas dans le prompt d'un fournisseur. L'éthique du périmètre — usage civil et défensif seulement — est elle-même un hook : une politique écrite à la frontière, pas l'espoir que le modèle refuse le mauvais travail. L'inclusion par conception — multilingue, multimodal, faible connectivité — est une injection SessionStart : le locale et la bande passante façonnent le premier contexte que voit l'agent, avant qu'il ne réponde.

Points-clés

• Un hook est du code déterministe à un point fixe de la boucle de l'agent ; le modèle est probabiliste et ne peut pas le contourner. La propriété est garantie par le mécanisme, pas par le prompt.
• Le stop refusé est le Théorème 3 en code : « les tests passent avant fini » est une propriété ; le hook Stop qui sort avec 2 sur l'échec est le mécanisme implémenté et mesurant.
• Sortie 2 bloque ; sortie 1 échoue en ouvert. Une barrière qui plante en ouvert est pire qu'aucune — elle vend le sentiment de sécurité sans le mécanisme.
• SessionEnd écrit la mémoire pour que SessionStart puisse la lire. La paire est un système de mémoire fait de règles, pas d'humeurs ; gâtez l'écriture ou stockez du fouillis.
• Le hook est « the space is the router » à la frontière de l'outil : le routage précède l'exécution, et la frontière décide, pas le répondant.

Questions fréquentes

Qu'est-ce qu'un hook Claude Code exactement ? Une commande shell que vous enregistrez dans un fichier de configuration. Quand un événement fixe de la boucle de l'agent se déclenche — avant qu'un outil ne lance, quand l'agent déclare fini, quand une session se termine — Claude Code envoie un payload JSON à votre script et lit le verdict depuis le code de sortie. Sortie 0 continue, sortie 2 bloque.

Pourquoi un hook est-il plus sûr qu'une instruction de prompt ? Une instruction de prompt est une suggestion qu'un modèle probabiliste suivra probablement. Un hook est du code qui tourne à chaque fois, au même point, avec les mêmes règles. Le modèle ne peut pas l'oublier, le sauter ni le discuter. « Espérer qu'il se comporte bien » devient « savoir qu'il le fera ».

Que signifie « refuser le stop » ? L'événement Stop se déclenche quand l'agent finit de répondre. Un hook sur cet événement peut sortir avec 2 pour empêcher l'agent de s'arrêter, renvoyant le message stderr au modèle. Lancez la suite de tests là, et l'agent ne peut littéralement pas déclarer victoire tant que la suite est rouge.

Comment cela se relie-t-il au Théorème 3 ? Le Théorème 3 dit qu'une propriété est garantie exactement lorsque son mécanisme est implémenté et mesure. Le hook est ce mécanisme : implémenté en code, mesurant en code de sortie. Retirez-le et vous avez un vœu ; gardez-le et vous avez une garantie.

Everythink utilise-t-il des hooks ? La même discipline fait tourner la HAI Engine ✅ : la normalisation de l'ensemble de l'Oracle est le hook qui garantit que les probabilités somment à un, en code, à chaque exécution. Aucune Sister ne peut la convaincre de livrer un cône non normalisé.

Sources

Professor Glitch, « Claude Code Hooks: The Guardrails Your Agent Can't Talk Past », askglitch.com, 7 juillet 2026 — https://www.askglitch.com/blog/claude-code-hooks

Claude Code hooks reference, code.claude.com — https://code.claude.com/docs/en/hooks

Créez votre network.