Idée principale

Un hook branché sur la fin d'un tour de conversation, et dont le travail consiste précisément à appeler l'assistant pour lui faire résumer l'échange, se déclenche lui-même : l'appel qu'il émet se termine à son tour, et cette fin réveille le hook. La boucle n'est pas un accident d'implémentation, elle est la conséquence directe du montage — l'automate emploie l'outil dont il surveille la fin.

Le remède ne consiste pas à éviter l'appel, mais à rendre l'automate capable de distinguer les déclenchements qu'il a provoqués de ceux qui viennent du travail réel. Claude Code passe pour cela un indicateur stop_hook_active dans les données envoyées au script, et le script sort immédiatement quand il le voit, avant tout traitement.

Ce test se place en premier, avant la lecture du transcript et avant tout appel de modèle. Un garde-fou placé après le travail coûteux ne protège de rien : la boucle serait déjà en train de consommer.

Pourquoi c'est important

C'est une panne qu'on ne découvre pas en concevant, mais en payant — en temps d'exécution, en appels facturés, en sessions qui ne rendent plus la main. Savoir qu'elle est structurelle permet de la traiter à la conception.

Et le motif se retrouve partout où un système réagit à ses propres effets : un déclencheur de base qui écrit dans la table qu'il surveille, une intégration continue qui pousse un commit, une règle de messagerie qui répond dans le fil qu'elle observe.

Nuances et limites

La distinction n'est possible que si l'environnement la fournit. Sans un signal de ce genre, il faut la fabriquer — un verrou, un marqueur, une fenêtre de temps — et ces substituts échouent dès que deux exécutions se chevauchent.

Et sortir sur ce signal a un coût : l'échange interne, lui, n'est jamais consigné.

Questions ouvertes

• Comment détecter qu'une automatisation réflexive tourne en boucle, si sa sortie est justement de ne rien écrire ?