Les règles comme garde-fous

Dans Pathrule, une règle n'est pas une note que l'assistant lira plus tard. C'est un garde-fou qui arrive avant que l'assistant n'agisse. La plupart des documentations vous expliquent ce qui s'est mal passé une fois le code livré. Un garde-fou, lui, peut arrêter la modification avant qu'elle n'atterrisse.

Cette page explique la différence entre un contexte qui éclaire un tour et une règle capable d'en bloquer un. Pour comprendre comment les hooks livrent le contexte, lisez d'abord Fonctionnement des hooks. Cette page porte sur ce que fait une règle stricte une fois ce contexte en place.

Le pull demande, le push arrive

L'ancien modèle est le pull. L'assistant doit penser à demander vos conventions, appeler un outil et lire le résultat avant de modifier quoi que ce soit. S'il oublie, il modifie à l'aveugle, et vous découvrez le problème en revue.

Le modèle des hooks est le push. Sur Claude Code et Codex, le contexte arrive sans que l'assistant ait à le demander, au moment où vous soumettez un prompt et juste avant que l'assistant n'utilise un outil. Cursor et GitHub Copilot n'ont pas de hook à la soumission du prompt : c'est donc le hook de début de session qui porte l'amorçage, et les hooks d'outil qui portent les règles du chemin concerné. Dans tous les cas, au moment où l'assistant s'apprête à écrire un fichier, les règles attachées à ce chemin sont déjà sous ses yeux. Windsurf n'a pas de hooks : il lit le fichier de règles de Pathrule et interroge le serveur MCP local pour en savoir plus. Sur Windsurf, les règles informent donc, mais ne bloquent pas.

Deux niveaux : consultatif et bloquant

Toutes les règles ne doivent pas interrompre l'assistant. Pathrule traite les règles à deux niveaux.

• Les règles consultatives accompagnent le travail comme contexte. Elles apparaissent à côté du fichier que l'assistant s'apprête à toucher, avec leur priorité, pour qu'il puisse en tenir compte. Elles n'arrêtent rien. La plupart des règles sont consultatives, quelle que soit leur priorité.
• Les règles strictes peuvent bloquer. Une règle devient stricte lorsqu'elle porte un motif de blocage approuvé par une personne : une forme interdite dans le contenu (un import, un identifiant, un nom de classe ou une déclaration CSS, par exemple), un emplacement interdit pour un fichier, ou les deux. Lorsque l'assistant s'apprête à modifier ou à écrire un fichier d'une manière qui correspond à ce motif, le hook arrête l'appel d'outil avant que le fichier ne soit écrit et en renvoie la raison. L'assistant la lit et réessaie, cette fois en respectant la contrainte.

Priorité et blocage sont indépendants. La priorité (haute, moyenne, basse) détermine la visibilité d'une règle et les règles retenues quand la place manque. Elle ne décide pas du blocage : toutes les règles strictes du chemin sont vérifiées, quelle que soit leur priorité.

Comment une règle devient stricte

Un assistant ne peut pas activer seul un motif de blocage.

1. La règle est d'abord rédigée en langage courant, par vous ou par un assistant à qui vous l'avez demandé.
2. Un assistant peut lui proposer un motif de blocage via les outils MCP d'écriture et de mise à jour des règles. La forme recommandée désigne le texte interdit exactement tel que la règle l'écrit, avec des exemples réels qui doivent être détectés et des cas voisins qui ne doivent pas l'être. Pathrule construit le motif à partir de ces éléments et le teste sur les deux ensembles ; si l'un des deux tests échoue, la proposition est refusée avec la raison au lieu d'être affaiblie.
3. La proposition est enregistrée avec la règle et n'est pas appliquée.
4. Ce n'est qu'après l'approbation d'une personne que le hook commence à bloquer, et le correctif rédigé pour ce motif devient le « faites plutôt ceci » que voit l'assistant.

Une règle peut aussi porter une vérification obligatoire : une commande de vérification qui doit avoir réussi avant la fin du tour, comme la suite de tests d'un paquet. Comme un motif de blocage, elle est proposée et n'est pas appliquée tant qu'une personne ne l'a pas approuvée. Une fois approuvée, sur Claude Code et Codex, le hook maintient le tour ouvert en indiquant la commande exacte à exécuter, jusqu'à ce qu'elle ait réussi.

Ce que voit l'assistant

Une modification bloquée revient avec le nom de la règle, un court aperçu de la règle, le correctif approuvé et un renvoi vers la règle complète. Pour une règle nommée « No direct database client in UI components », cela donne ceci :

Pathrule blocked: "No direct database client in UI components"

UI components never import the database client. Data goes through the data layer hooks.

Do this instead: call the data layer hook for this resource.

Your edit matches this rule's forbidden pattern. Read the full rule via pathrule_read_rule(<id>) and retry without the violation.

Claude Code, Codex, Cursor et GitHub Copilot reçoivent ce message sous la forme d'un refus de l'appel d'outil, dans le format de hook propre à chaque client. Windsurf n'a pas de hooks, donc rien n'y est bloqué. Le blocage s'applique aux modifications et aux écritures de fichiers ; une commande shell reçoit toujours la règle comme contexte.

Cette séparation est voulue. Bloquer une modification sans enjeu gaspille le tour de l'assistant, et le vôtre. Le blocage est réservé aux règles dont la violation constitue une vraie régression, et pour lesquelles quelqu'un a validé précisément ce qui en constitue une.

Avant et après

Prenons une règle qui interdit de placer des secrets dans des fichiers commités, avec un motif de blocage approuvé pour le format de clé utilisé par votre fournisseur.

Le même principe s'applique à toute règle qu'une équipe a apprise à ses dépens en production : une politique d'accès aux données qui doit filtrer par utilisateur, une convention de migration, un fichier généré qui ne doit pas être modifié à la main. La règle cesse d'être un commentaire dont on espère que l'assistant l'a lu, et devient une vérification exécutée avant que la modification n'atterrisse. Un motif de blocage détecte les formes pour lesquelles il a été approuvé : il complète donc la revue, sans la remplacer.

Le nom de fichier fait remonter la bonne mémoire

Vous n'avez pas toujours à attendre un appel d'outil. Sur Claude Code et Codex, lorsque votre prompt nomme un fichier qui fait l'objet d'une mémoire attachée, le hook de prompt peut faire remonter le contenu de cette mémoire avant même que l'assistant n'ouvre quoi que ce soit. Nommer le fichier sur lequel vous travaillez suffit souvent à placer le bon contexte devant l'assistant dès le premier tour. Lorsque plusieurs mémoires correspondent au même nom de fichier, le hook affiche les candidates au lieu de deviner.

Permissif en cas d'échec, par conception

Un garde-fou qui casse votre flux de travail quand il tombe en panne est pire que pas de garde-fou du tout. Pathrule est permissif en cas d'échec. Si le hook ne peut pas évaluer une règle, rencontre une erreur ou dépasse son délai, il ne bloque pas votre travail. La modification passe. L'application des règles est un filet de sécurité, pas une barrière derrière laquelle vous pourriez rester coincé.

Vous gardez la main. Si vous voulez un jour désactiver complètement les hooks, un seul fichier suffit.

Vérifiez par vous-même

Inutile de croire ce comportement sur parole.

Pour voir quels hooks votre client IA a enregistrés, lisez son fichier de configuration. Pour Claude Code, Pathrule enregistre ses hooks dans le projet :

cat .claude/settings.json

Cursor utilise .cursor/hooks.json, Codex utilise .codex/hooks.json et GitHub Copilot utilise .github/hooks/pathrule.json.

Pour désactiver instantanément tous les hooks Pathrule (l'interrupteur d'arrêt d'urgence), créez un fichier :

touch ~/.pathrule/kill-hooks

L'appel d'outil suivant passe directement, sans aucune intervention de Pathrule. Supprimez le fichier pour réactiver les hooks :

rm ~/.pathrule/kill-hooks

Pour vérifier qu'une règle est bien attachée à un chemin, exécutez pathrule rule list dans le dossier, ou ouvrez dans votre éditeur la vue de contexte Pathrule de l'assistant. La règle y apparaît avec sa priorité avant que l'assistant n'agisse sur ce chemin, et une règle stricte affiche son blocage la première fois qu'une modification y correspond.

Pour aller plus loin

• Fonctionnement des hooks pour les mécanismes de livraison et le comportement en l'absence de contenu.
• Rédiger des règles pour savoir comment écrire une règle qui mérite d'être appliquée.
• Présentation du MCP pour la voie approfondie qu'emprunte l'assistant quand le hook ne suffit pas.