Les fichiers qui ralentissent un assistant

Certains fichiers sont plus difficiles à manipuler que d'autres pour un assistant, et la raison tient rarement au code lui-même. Un chemin cité dans votre documentation qui a changé. Un fichier généré qu'on ne peut pas modifier sans risque. Un répertoire qui exige une permission dont l'agent ne dispose pas. Vous savez déjà, à peu près, de quels fichiers il s'agit, pour vous y être heurté. Pathrule l'enregistre avec précision.

Ce qui est enregistré

Lorsqu'un outil appelé par un assistant échoue, trois éléments sont stockés : le type d'outil, le fichier sur lequel il travaillait et un code court indiquant la nature de l'échec. file_not_found, permission_denied, timeout, rate_limit, token_limit, syntax_error, ou unknown lorsque l'échec est réel mais qu'aucune règle ne le reconnaît.

C'est tout ce qui est enregistré. Pas la commande. Pas le message d'erreur. Pas le fichier. Un compteur et un code, rattachés à un chemin. Sur un espace de travail Cloud, ces compteurs et ces codes sont stockés avec l'espace de travail dans Pathrule Cloud.

L'échec est observé, pas signalé. Le hook d'outil de Pathrule surveille l'appel lui-même : le compteur ne dépend donc pas du fait que l'assistant remarque sa propre erreur, se souvienne d'une session ou appelle quoi que ce soit ensuite. Un assistant qui échoue en silence et passe à autre chose est enregistré exactement comme un assistant qui l'annonce. La durée de l'appel fait partie de la même observation, ce qui permet de distinguer une commande restée bloquée d'une commande refusée. Cela s'applique aux clients pour lesquels Pathrule dispose de hooks d'outil : Claude Code, Codex, Cursor et GitHub Copilot. Windsurf n'a pas de hooks Pathrule, ses appels d'outil ne sont donc pas observés de cette façon.

Le chemin est d'abord normalisé sous une forme relative à l'espace de travail, ce qui compte plus qu'il n'y paraît. Sur un ordinateur portable, un chemin absolu ressemble à /Users/<name>/…, et ce nom n'a rien à faire dans des connaissances partagées. Les chemins relatifs permettent aussi de regrouper correctement un même fichier au sein d'une équipe, au lieu de le compter une fois par machine.

À quoi cela sert

Une vue des endroits où le travail se bloque. Au fil du temps, les échecs sont regroupés par fichier, par outil et par code. Le résultat est une courte liste plutôt qu'un graphique : les fichiers dans lesquels un assistant échoue le plus, et de quelle manière. Un fichier qui revient sans cesse sous file_not_found correspond généralement à un chemin obsolète quelque part dans vos propres instructions. Un fichier sous syntax_error est généralement un fichier réellement délicat à modifier. Un fichier sous permission_denied signale généralement un problème de configuration que vous pouvez corriger une fois pour toutes.

L'apprentissage de la récupération. Si un tour a reçu des connaissances de Pathrule et a malgré tout rencontré des échecs, ces connaissances reçoivent un signal négatif, et certains types d'échec pèsent plus lourd qu'un simple raté, car ils indiquent souvent que les consignes ont envoyé l'assistant vers un endroit inaccessible. Ce signal rejoint la boucle décrite dans comment la récupération trouve les bonnes connaissances. Les connaissances qui reviennent régulièrement dans des tours qui se passent mal ont progressivement moins de chances d'être choisies, sans que personne ait besoin de les revoir.

Ce que le signal ne peut pas voir

Cette partie dépend de l'assistant que vous utilisez, et le comportement n'est pas uniforme.

Les outils de fichiers signalent correctement leurs échecs. Une lecture, une modification ou une écriture qui échoue arrive avec son message, est classée et rattachée au bon fichier. C'est le cas qui compte, car c'est le chemin du fichier qui rend un compteur exploitable.

Les commandes shell, souvent, non. Certains assistants ne transmettent aucun code de sortie, si bien qu'une commande qui échoue et une commande qui réussit arrivent sous une forme identique. Pathrule ne déduit pas un échec du texte de sortie : un résultat de recherche peut tout à fait contenir les mots « no such file or directory », et un faux échec rattaché à un fichier est pire qu'un échec manquant. Lorsque l'assistant ne signale pas d'échec, rien n'est enregistré, et lorsqu'il en signale un qu'aucune règle ne reconnaît, le code est unknown plutôt qu'une supposition.

Ce que cela ne fait pas

Enregistrer un échec ne bloque pas l'appel d'outil et n'apparaît pas dans le contexte de l'assistant. Un échec est un fait concernant votre base de code, enregistré après coup. Il ne modifie pas ce que l'assistant a le droit de faire, et un fichier au mauvais historique n'est pas pour autant considéré comme interdit. Rien ici ne constitue une note attribuée à une personne : l'enregistrement porte sur les fichiers, pas sur les personnes qui y travaillaient.