Tu te souviens des mods sur Minecraft ou sur Skyrim ? Tu prenais le jeu et tu changeais ce que tu voulais : les règles, l'interface, tout. C'est maintenant possible avec Claude Code, et ça s'appelle Claude Mods.
Tu branches ton propre code à l'intérieur de Claude Code pour bloquer ce qu'il fait, le modifier ou ajouter des éléments à son interface. Et tu n'écris pas le code : tu décris ton mod en une phrase, Claude l'écrit, et il se recharge à chaud dans ta session. Dans la vidéo, on en construit deux en live : un garde du corps et un cockpit.
Le 3 septembre 2026, une proposition intitulée « Mods - make Claude 10x more extensible » est publiée sur le GitHub de Claude Code pour recueillir l'avis de la communauté. Une mise à jour du 9 septembre annonce que, côté produit, la fonctionnalité s'appellera Claude Mods. Puis, le 1er octobre : « We're live! ».
Le changelog officiel le confirme : Claude Code 2.1.287, sorti le 1er octobre 2026, ajoute Claude Mods, en résumant que les plugins peuvent désormais modifier Claude Code plus en profondeur. La documentation précise que les mods demandent la v2.1.287 ou plus récente et qu'ils sont activés par défaut.
Claude Code émet des événements en permanence : l'utilisateur envoie un prompt, Claude veut appeler un outil, le tour est terminé, l'écran doit être redessiné… Un mod, c'est une fonction que tu branches sur l'un de ces événements. Elle reçoit trois choses :
e, l'événement : par exemple, la commande que Claude veut lancer ;next, la suite : tu l'appelles, Claude Code continue normalement ; tu ne l'appelles pas, il ne se passe rien, tu as bloqué ;$, le moteur : c'est par lui que tu fais tout, afficher une notification, ouvrir un panneau, lire un fichier.
Ton mod peut donc agir avant Claude Code, après, ou à sa place, comme un middleware Express. La documentation le dit avec ses mots : un hook peut observer l'événement, le réécrire, ou y répondre lui-même, par exemple en refusant une commande.
Techniquement, un mod est un plugin dont le code déclare sur quels événements ses fonctions tournent.
Claude Code avait déjà des hooks, déclarés dans settings.json : une commande shell, une requête HTTP ou un prompt lancé sur un événement. La documentation les appelle désormais « settings hooks ». La différence, selon la vidéo :
- un mod, c'est du TypeScript typé (ou du JavaScript) qui tourne dans Claude Code ;
- il se branche sur presque tout ;
- il se recharge à chaud ;
- et surtout, il peut dessiner dans l'interface.
La vidéo cite quatre emplacements : un panneau à côté de la conversation, un bandeau au-dessus du prompt, une ligne de statut en dessous, et des toasts, les petites notifications en haut à droite.
Le point de départ : un projet de test avec un .env rempli de faux secrets. Sans protection, Claude affiche son contenu quand on le lui demande.
On lui demande donc, en une phrase, de se construire son propre garde-fou :
Crée-moi un mod Claude Code "garde-du-corps" : il bloque toute lecture ou modification des fichiers .env, ainsi que les commandes Bash dangereuses (rm -rf, git push --force, git reset --hard, DROP TABLE). Quand il bloque quelque chose, affiche un toast, et garde dans la status line un compteur des actions bloquées.
Claude charge alors une skill intégrée à Claude Code, plugin-authoring, qui sert justement à écrire des mods. Il vérifie l'API, puis écrit le module, ses règles et un test.
Dès qu'il enregistre le premier fichier, Claude Code pose une question : activer le rechargement à chaud pour cette session ? C'est toi qui réponds, pas Claude. On choisit « Enable for this session ».
Il vérifie ensuite le mod avec claude plugin validate, lance ses tests et la vérification de types : dans la vidéo, la validation passe, les quatre tests passent et la vérification de types ne remonte aucune erreur. Le mod se charge à la fin du tour, sans redémarrer, et la ligne de statut affiche le compteur à zéro.
Détail utile : le code n'est pas écrit dans le dossier courant, mais dans ~/.claude/dev-mods/ suivi de l'identifiant de la session. Selon la documentation, un mod écrit par Claude ne se charge que dans cette session : pour le réutiliser, copie son dossier ailleurs.
Le test : on redemande le .env. Bloqué, avec un toast qui l'annonce. Plus tard dans la vidéo, un rm -rf sur le dossier dist est lui aussi bloqué.
Deux remarques de Claude méritent d'être relevées :
- les modèles comme
.env.example, .env.sample ou .env.template restent accessibles, ce qui est logique : ils ne contiennent pas de secrets ;
- Claude prévient lui-même que la détection des commandes Bash repose sur des motifs de texte : une commande volontairement déguisée, via une variable ou un script externe, peut passer. Le mod protège contre les accidents, pas contre une tentative délibérée de contournement.
Tu pourrais écrire dans ton CLAUDE.md : « ne lis jamais le .env ». Mais une consigne, Claude peut l'oublier au fil du temps. Un mod, c'est du code qui s'exécute avant l'outil : il ne peut pas l'oublier. Dans le code généré, on retrouve d'ailleurs le ($, e, next) : un switch sur l'outil appelé, et si la règle s'applique, le mod renvoie un refus au lieu d'appeler next.
Le premier mod changeait ce que Claude fait. Le second change ce que Claude Code affiche : un tableau de bord en direct à côté de la conversation. Nouvelle phrase, nouveau mod, cette fois sans question, puisque le rechargement à chaud est déjà activé pour la session.
Claude écrit le panneau et ses tests, les valide, et ajoute une commande /cockpit pour ouvrir le panneau. On y voit le nombre de tours, d'appels d'outils et de tokens, les outils les plus utilisés, la durée des tours et les derniers fichiers modifiés. On lui donne ensuite un vrai travail sur le projet de test, et le panneau se remplit au fil des outils.
Sans redémarrer, on demande d'ajouter au cockpit le modèle sélectionné, le pourcentage de contexte, la consommation de tokens et le coût en dollars. Claude regarde ce que l'API expose, modifie le mod, et le panneau s'actualise dans la même session, avec une nouvelle section en haut.
Un mod a beaucoup de pouvoir. La vidéo pose trois règles :
- Lis le code avant d'installer. Un mod, c'est du code qui tourne dans Claude Code : il voit tes prompts, tes outils, tes fichiers. Installe uniquement des mods dont tu as lu le code. La documentation va dans le même sens : un mod tourne avec tes permissions, il peut lire et écrire tes fichiers, lancer des programmes, faire des requêtes réseau, et il n'est pas sandboxé. Avant d'installer,
claude plugin validate sur le dossier du mod liste les événements qu'il écoute et ce qu'il demande à Claude Code, sans l'exécuter.
- L'API bouge encore. La documentation le précise : les événements et les méthodes peuvent changer d'une version à l'autre. Un mod qui marche aujourd'hui peut devoir être corrigé après une mise à jour. D'où l'intérêt des tests et de
claude plugin validate.
- Un garde-fou, pas un coffre-fort. Le garde du corps bloque les cas évidents, mais une règle à base de motifs ne pense pas à tout. Tes vraies clés de prod n'ont rien à faire sur ton environnement de dev.
Et c'est pour ça que la question du rechargement à chaud s'adresse à toi, et uniquement à toi : selon la vidéo, aucun mode de permission, aucune règle, aucun hook ne peut y répondre à ta place.
Les deux mods de la vidéo sont en accès libre sur GitHub, dans le dépôt claude-code-mods-fr, sous licence MIT. Dans Claude Code, deux commandes suffisent pour un mod :
/plugin marketplace add Para-FR/claude-code-mods-fr
/plugin install garde-du-corps@claude-code-mods-fr
Remplace garde-du-corps par cockpit pour le second. Le dépôt indique aussi que, pour afficher le cockpit en barre latérale, il faut mettre "tui": "fullscreen" dans ton settings.json.
La vidéo cite des idées de la communauté : un boss en pixel art que tu bats en faisant passer tes tests, un tamagotchi qui réagit à ton code, un commentateur sportif de tes sessions avec le bruit de la foule.
Le conseil de la vidéo : pars de ton irritant, le truc qui t'agace tous les jours dans Claude Code. Décris-le en une phrase, et laisse Claude écrire le mod.
- Claude Mods arrive avec Claude Code 2.1.287, le 1er octobre 2026, activé par défaut.
- Un mod est une fonction
($, e, next) branchée sur un événement : elle peut observer, réécrire ou bloquer.
- Deux mods construits en une phrase chacun : un garde du corps (
.env, rm -rf, git push --force) et un cockpit (/cockpit).
- Avant d'installer le mod d'un inconnu : lis le code, garde en tête que l'API peut changer, et ne le prends pas pour un coffre-fort.
