Idée principale

Un point d'accroche nommé Stop évoque une fin : on l'imagine déclenché quand on ferme l'outil, une fois par session. Il se déclenche en réalité à la fin de chaque tour — après chaque réponse complète de l'assistant, qu'elle tienne en une phrase ou qu'elle ait enchaîné quinze appels d'outils. Entre l'idée qu'on s'en fait et ce qu'il fait, le facteur est de plusieurs dizaines.

L'écart n'est pas un détail de documentation, il change ce qu'on peut brancher dessus. Un traitement conçu pour tourner une fois par jour — une synthèse coûteuse, un envoi de courriel, une écriture massive — devient inutilisable à cette cadence. Inversement, un mécanisme qui a besoin de voir chaque échange serait vide s'il n'était déclenché qu'à la fermeture.

La fréquence réelle est donc la première chose à établir devant un point d'accroche, avant même de savoir quelles données il reçoit. Le nom est une indication d'intention, pas une spécification.

Pourquoi c'est important

L'erreur ne se voit pas à l'écriture : le code branché fonctionne, il fonctionne simplement bien plus souvent que prévu. Elle se paie ensuite en coût, en lenteur ou en volume de données produites, et le lien avec le malentendu de départ est rarement fait.

Plus généralement, dans toute intégration, la granularité d'un événement est une donnée à vérifier au même titre que son format.

Nuances et limites

La fréquence réelle dépend aussi de l'usage : le même point d'accroche se déclenche vingt fois dans une session de travail intense et deux fois dans une session courte. Ce n'est pas une constante qu'on peut établir une fois pour toutes.

Et le nom n'est pas toujours trompeur : le problème est de le prendre pour une spécification, pas le fait qu'il évoque quelque chose.

Questions ouvertes

• Comment vérifier la fréquence réelle d'un événement avant d'y brancher un traitement, autrement qu'en l'observant en production ?