Hooks utiles

Les hooks de Claude Code peuvent corriger des faiblesses courantes du développement assisté par IA, et ces faiblesses se manifestent surtout sur les gros projets, là où plus personne n’a l’ensemble du code en tête. Les deux hooks présentés ici répondent à deux symptômes que vous rencontrerez tôt ou tard : le changement incomplet et la fonctionnalité écrite en double.

Hook de vérification de types TypeScript

L’un des hooks les plus utiles adresse un problème fondamental : quand Claude modifie la signature d’une fonction, il ne met pas toujours à jour tous les endroits où cette fonction est appelée dans votre projet.

L’exemple est banal. Vous demandez à Claude d’ajouter un paramètre verbose à une fonction dans schema.ts. Il modifie consciencieusement la définition de la fonction, mais risque de manquer le site d’appel dans main.ts, un fichier qu’il n’avait aucune raison d’ouvrir. Cela crée des erreurs de type que Claude ne détecte pas immédiatement — et que vous ne découvrirez peut-être qu’au prochain build, plusieurs tâches plus tard, quand le contexte de la modification se sera évaporé.

La solution est un hook PostToolUse qui lance le compilateur TypeScript après chaque édition :

{
  "PostToolUse": [
    {
      "matcher": "Write|Edit|MultiEdit",
      "hooks": [
        {
          "type": "command",
          "command": "node ./hooks/typecheck.js"
        }
      ]
    }
  ]
}

Le script typecheck.js exécute tsc --noEmit pour vérifier les erreurs de type, capture les erreurs trouvées et les renvoie à Claude immédiatement. Claude corrige alors les problèmes dans les autres fichiers, dans la foulée de sa modification initiale, sans que vous ayez eu à intervenir. Le compilateur tient ici le rôle du collègue qui connaît tout le projet par cœur et lève la main tout de suite.

Ce hook fonctionne pour tout langage typé. Pour les langages non typés, vous pouvez implémenter une fonctionnalité similaire en utilisant des tests automatisés : le principe reste identique, un outil extérieur constate la casse et la signale pendant que la correction est encore facile.

Hook de prévention de duplication de requêtes

Dans les gros projets avec de nombreuses requêtes de base de données, Claude crée parfois des fonctionnalités en doublon au lieu de réutiliser le code existant. Ce n’est pas de la négligence : il ne peut réutiliser que ce qu’il a vu, et une fonction enfouie dans un fichier qu’il n’a pas ouvert n’existe pas de son point de vue.

Supposez que vous lui demandiez : « Crée une intégration Slack qui alerte sur les commandes en attente depuis plus de 3 jours ». Claude pourrait écrire une nouvelle requête au lieu d’utiliser la fonction getPendingOrders() qui existe déjà. Le code fonctionnera, personne ne s’en apercevra en revue, et votre projet comptera désormais deux définitions de la même chose à maintenir en parallèle.

Le hook de prévention de duplication répond à cela d’une manière inhabituelle : il fait relire Claude par Claude. Il se déclenche quand Claude modifie des fichiers dans le répertoire ./queries, puis lance une instance séparée de Claude Code de façon programmatique. Cette seconde instance reçoit pour consigne de vérifier les changements et de chercher des requêtes similaires existantes ; si des doublons sont trouvés, elle fournit le feedback à l’instance originale, qui supprime alors le doublon et utilise la fonctionnalité existante. Toute l’astuce tient à cette seconde instance : elle arrive sans le contexte de la conversation en cours et va donc réellement explorer le répertoire au lieu de se fier à sa mémoire de la session.

Considérations d’implémentation

Ce second hook a un coût qu’il faut regarder en face. Le bénéfice est réel — une base de code plus propre, moins de duplication, une dette qui cesse de s’accumuler en silence — mais chaque modification surveillée déclenche du temps de calcul et une consommation API supplémentaires, ce qui se ressent immédiatement si vous l’appliquez à l’ensemble du projet. La recommandation est donc de ne surveiller que les répertoires critiques, ceux où la duplication fait réellement mal, afin de minimiser l’overhead.

Ces deux exemples illustrent deux principes transposables à vos propres hooks. Le premier consiste à utiliser la sortie du compilateur ou du linter comme source de feedback immédiat : l’outil existe déjà, il suffit de le brancher au bon moment du cycle. Le second, plus ambitieux, consiste à implémenter de véritables processus de revue de code en utilisant des instances IA séparées. Dans les deux cas, concentrez la surveillance sur les répertoires à haute valeur et équilibrez les bénéfices de l’automatisation avec ses coûts de performance.