Les mods sont tout récents : Anthropic les a annoncés le 1ᵉʳ octobre 2026. Je me suis d'abord demandé ce que c'était, et surtout à quoi ils pouvaient servir. Avec les commandes, les skills et les hooks, on pouvait déjà beaucoup personnaliser Claude Code. J'ai donc demandé à Claude de me l'expliquer, puis de me proposer des usages à partir de ma façon de travailler et de mes projets. J'en ai retenu cinq, chacun sur une capacité différente : afficher une information, mesurer, bloquer une action, exécuter une commande, lire l'état de la machine. Je les ai construits et utilisés dans ma session de travail, captures à l'appui. Un sixième vient de ma mission actuelle chez un client : il affiche l'état du front et du back selon le worktree, et les lance d'un clic.
Le premier mod que j'ai écrit n'apportait presque rien : il affichait surtout des chiffres que ma status line montrait déjà. Les mods utiles sont ceux qui interviennent au bon moment : une alerte quand un seuil est franchi, un refus quand l'agent s'apprête à faire une erreur, une commande qui s'exécute sans passer par le modèle, un serveur lancé d'un clic. Deux autres constats ressortent : on corrige un mod dans la conversation même où Claude l'écrit, et un mod se teste comme n'importe quel code, parce qu'il tourne avec vos droits.
Un mod Claude Code, c'est quoi par rapport aux hooks et aux skills
Avant les mods, Claude Code se personnalisait déjà de plusieurs façons. Les hooks de settings lancent un script sur un événement (avant un appel d'outil, à la fin d'un tour). Les skills donnent des instructions à Claude. Les serveurs MCP lui ajoutent des outils. Tous agissent de l'extérieur : un script lancé à côté, ou du texte et des outils donnés au modèle.
Un mod tourne à l'intérieur de Claude Code. C'est un plugin qui contient un module JavaScript ou TypeScript : Claude Code appelle ses fonctions à chaque événement (un appel d'outil, un prompt envoyé, un élément d'interface à dessiner). Chaque fonction peut laisser passer l'événement, le modifier, ou y répondre elle-même. Comme il tourne dans Claude Code, il peut aussi dessiner dans l'interface, ce qu'aucune des autres options ne sait faire.
| Mod | Hook de settings | Skill | Serveur MCP | |
|---|---|---|---|---|
| Ce que c'est | Des fonctions exécutées dans Claude Code | Un script lancé sur un événement | Des instructions en Markdown | Un processus externe qui fournit des outils |
| Ce qu'il peut changer | Appels d'outils, prompts, commandes, interface | Laisser passer, bloquer ou modifier un appel, ajouter du contexte | Ce que Claude sait faire | Les outils disponibles |
| Peut dessiner dans l'interface | Oui | Non | Non | Non |
| Langage | JavaScript ou TypeScript | Au choix (script) | Markdown | Au choix |
L'affichage n'existe que dans le terminal et dans l'onglet Code de l'application Desktop. Dans l'extension VS Code ou en mode claude -p, les fonctions d'un mod s'exécutent, mais rien ne s'affiche. Pour ma part, j'utilise Claude Code uniquement en ligne de commande : tous les mods de cet article ont été construits et testés dans le terminal.
Écrire un mod Claude Code sans quitter la session
Je n'ai pas écrit ces mods à la main. Claude Code embarque un skill dédié, plugin-authoring, qui connaît l'API de la version installée : on décrit le mod voulu, Claude l'écrit. Un mod tient en trois fichiers :
usage-band/
├── .claude-plugin/plugin.json # nom, version, description
└── hooks/
├── hooks.json # pointe vers le module
└── register.tsx # les fonctions appelées sur chaque événementLe plus intéressant est le chargement. Au premier fichier écrit, Claude Code pose une question, une seule fois par session : activer le rechargement à chaud pour cette session ? Seul l'utilisateur peut y répondre, aucune règle de permission ne le fait à sa place. Une fois accepté, le mod se charge à la fin du tour, sans redémarrer Claude Code, et chaque modification le recharge. On écrit le mod, on le voit tourner, on demande une correction, et on la voit au tour suivant.
Deux commandes servent de filet de sécurité. claude plugin validate lit le mod sans l'exécuter et liste les événements qu'il intercepte et ce qu'il demande à Claude Code (lire un fichier, lancer un processus, faire une requête réseau). claude plugin test lance ses tests, dans un environnement qui simule Claude Code.
Six mods Claude Code, six usages
Afficher au bon moment : la bande d'usage
Le premier mod affichait une bande au-dessus du prompt : remplissage du contexte, fenêtres de quota sur 5 heures et sur 7 jours avec leur heure de réinitialisation, coût de la session. Une fois les tests passés, il fonctionnait. Mais en le voyant, le constat était évident : ma status line affichait déjà le contexte. Seules les fenêtres de quota étaient une information nouvelle.
La deuxième version ne s'affiche plus que si une fenêtre dépasse 50 % ou si le contexte dépasse 70 %, et elle ne montre que ce qui dépasse. Le reste du temps, elle est invisible. Une notification s'ajoute quand une fenêtre franchit 80 %, puis 95 %. Les chiffres sont envoyés par Claude Code après chaque tour : le mod n'interroge rien.
Le passage d'une version à l'autre s'est fait en un échange, sans redémarrer.
Mesurer : les tokens de chaque outil
/context montre la répartition du contexte par catégorie, pas par outil. Le deuxième mod ajoute la commande /tool-tokens, qui ouvre un panneau : pour chaque outil, le volume des résultats renvoyés au modèle, le nombre d'appels et le plus gros appel. Les sous-agents sont exclus, puisque leurs résultats restent dans leur propre contexte.
Sur la session de test, environ 17 800 tokens de résultats d'outils en 93 appels. Grep et Bash en représentent 73 %, Read seulement 15 %. On soupçonne plutôt Read, qui charge des fichiers entiers. Une réserve : l'API des mods n'expose pas de compteur de tokens pour un texte quelconque, le panneau estime donc à raison de quatre caractères par token. C'est un ordre de grandeur, pas une mesure au token près comme dans mon article sur la réduction des tokens.
Bloquer : pas de média dans le vault
Je range mes notes dans un vault Obsidian : un simple dossier de fichiers Markdown, que Claude Code lit et modifie comme n'importe quel dépôt. Ce vault ne doit contenir que des notes. Les images et vidéos que je génère vont dans le dossier du projet concerné. La règle était écrite dans mes instructions, et l'agent l'avait déjà oubliée une fois, en y rangeant 141 Mo de vidéos de prévisualisation.
Le troisième mod intercepte les écritures de fichiers, y compris celles faites en ligne de commande, et refuse tout média qui atterrirait dans le vault. À la place du résultat de l'outil, il affiche un encadré rouge dans le transcript. Le modèle reçoit la raison du refus et l'endroit où ranger le fichier : il peut se corriger seul.
Le même refus s'affiche aussi en notification, sous le nom du mod. Elle reste affichée dix secondes, le temps de la voir même si on fait autre chose.
Une nuance : un hook de settings PreToolUse sait déjà bloquer un appel d'outil. Ce que le mod ajoute, c'est l'affichage, et un code qu'on teste dans la session même où on l'utilise. Avec un simple hook, le refus apparaît comme une erreur d'outil parmi les autres. Avec le mod, l'encadré rouge se repère tout de suite. C'est la même idée que dans mon article sur les tests E2E filmés : quand un garde-fou bloque, il le dit clairement.
Exécuter sans le modèle : une commande en code
Je garde dans mon vault un registre des sessions Claude Code à reprendre. Jusqu'ici, j'écrivais "enregistre cette session pour tel projet" : Claude lisait le registre, ajoutait la ligne et répondait. Un tour de modèle complet pour écrire une ligne dans un tableau.
Le quatrième mod ajoute la commande /session-id <projet> [note]. La ligne est écrite par le code du mod : il lit l'identifiant de la session, l'heure, et met à jour le tableau, ou remplace la ligne si la session y est déjà. Aucun tour de modèle n'est lancé, et la commande peut même, si on la déclare comme telle, s'exécuter pendant que Claude travaille.
C'est la différence la plus utile à retenir entre deux commandes qui se tapent de la même façon : une commande classique, écrite en Markdown, est un prompt envoyé au modèle ; une commande de mod est du code. Seule la ligne de confirmation entre dans le transcript, et le modèle la lira avec le message suivant.
Lire l'état de la machine : la charge du GPU
Je génère des images en local, sur une RTX 4090. Pendant un rendu, je surveillais la charge du GPU dans une autre fenêtre. Le cinquième mod l'affiche dans la status line de Claude Code, rafraîchie toutes les cinq secondes : charge, mémoire vidéo, température, consommation.
Le mod lance nvidia-smi lui-même, sur un minuteur : rien ne passe par le modèle. Quand le GPU repasse au repos après au moins une minute de calcul, une notification signale que le rendu est probablement terminé.
Piloter son environnement : front et back selon le worktree
Sur le projet client où je suis en mission, je travaille souvent dans plusieurs worktrees Git en parallèle, un par sujet. Une erreur revenait : demander une vérification à Claude alors que le front ou le back n'était pas lancé, ou tournait depuis un autre worktree.
Le sixième mod affiche une bande au-dessus de la zone de prompt : le front est-il lancé, le back est-il lancé, pour le worktree où je me trouve. À côté de chacun, un bouton le démarre directement depuis Claude Code, sans ouvrir un autre terminal.
Les mods venant de sortir, je ne l'utilise que depuis peu, mais c'est celui qui devrait m'éviter le plus de manipulations. Il répond aussi à un piège que je décrivais dans l'article sur les tests E2E filmés : un front lancé depuis un autre worktree affiche une autre branche que celle qu'on croit tester.
Ce que ces mods Claude Code m'ont appris
Le premier enseignement est venu du premier mod. Recopier un chiffre déjà visible ailleurs n'apporte rien, aussi bien présenté soit-il. Ceux que j'ai gardés ont un point commun : ils m'évitent une manipulation, ou interviennent quand quelque chose change (un seuil franchi, une écriture interdite, un rendu terminé).
Le deuxième est plus pratique. Le rechargement à chaud n'a rien de nouveau en développement, mais dans Claude Code il évite de relancer la session à chaque modification : Claude écrit le mod, je le vois tourner, je demande une correction dans la même conversation. C'est ce qui a permis de corriger la bande d'usage dès qu'elle s'est révélée peu utile.
Le troisième : un mod est du code, et il a des bugs de code. Sur la bande d'usage, le mod lisait un mauvais nom de champ pour les quotas : la bande aurait affiché un pourcentage vide. Les tests l'ont détecté avant que je la voie à l'écran. Ces tests, c'est Claude qui les écrit aussi, en simulant ce que Claude Code renvoie. Ils permettent de faire confiance à un mod qui tourne avec vos droits.
Un mod Claude Code tourne avec vos droits
C'est le point à ne pas négliger. Un mod n'est pas isolé du système : il s'exécute avec les droits de votre compte. Il peut lire et écrire vos fichiers, lancer des programmes, faire des requêtes réseau et lire vos variables d'environnement. Il voit chaque prompt et chaque appel d'outil, et peut même approuver un appel d'outil à votre place. La seule chose qu'il ne peut pas modifier, d'après la documentation, c'est la demande de permission elle-même.
Avant d'installer un mod écrit par quelqu'un d'autre, lancez claude plugin validate sur son dossier : la sortie liste les événements qu'il intercepte et ce qu'il demande à Claude Code. En cas de doute sur une session, claude --safe-mode démarre sans les mods installés.
Le garde-fou a d'ailleurs bloqué une demande légitime : je demandais à Claude de ranger des captures d'écran dans le vault. Il refuse les écritures de l'agent, pas les miennes, j'ai donc copié les fichiers moi-même. Il s'est aussi trompé une fois : une commande lancée depuis le vault, qui supprimait des fichiers ailleurs, a été refusée parce qu'elle citait un nom d'image sans chemin complet. Le mod ne peut pas savoir où atterrit un nom relatif, il refuse par précaution. Un garde-fou de ce type protège contre une erreur de l'agent, et laisse la décision à l'utilisateur.
Ce qu'il faut retenir
- Commencez par ce que Claude Code n'affiche pas encore. Un mod qui recopie votre status line ne sert à rien.
- Préférez un mod qui intervient à un mod qui affiche : une alerte au-delà d'un seuil, un refus visible, une notification de fin de tâche.
- Utilisez une commande de mod pour les actions mécaniques. Le code s'exécute sans tour de modèle.
- Testez et validez chaque mod comme du code.
claude plugin testattrape les erreurs de champ,claude plugin validatedit ce qu'un mod fait avant que vous l'installiez.
Ces six mods ne couvrent qu'une partie de ce que j'ai essayé, et de ce qu'on peut faire. Le dernier l'a montré : un mod sait dans quel dépôt et dans quel worktree il tourne. Il peut afficher d'autres informations, appliquer d'autres règles ou proposer d'autres commandes selon le projet ouvert. Comme tout plugin, un mod peut aussi être activé pour un seul dépôt : la ligne qui l'active va dans le .claude/settings.json du projet, que l'on commite, et chaque collaborateur l'installe une fois de son côté. Chaque projet a ses propres besoins, et c'est souvent en travaillant dessus qu'ils apparaissent. Le plus simple pour trouver les vôtres reste de faire comme moi : demander à Claude de partir de votre façon de travailler.
