J'ai testé 10 mods Claude Code : 3 valent le coup

Les mods Claude Code sont des fonctions TypeScript logées dans des plugins, capables de redessiner l'interface de Claude Code ou de réécrire ce qu'il fait. Moins d'un jour après leur lancement début octobre, trois visites vidéo distinctes ont dit aux développeurs d'en installer dix. Deux de ces créateurs admettent à l'écran que certains mods n'économisent rien, et aucun n'en a mesuré un seul. Ce test le fait : chacun des dix mods hypés a tourné sur une vraie semaine de travail, avec un chiffre pour son surcoût, ses économies et un verdict garder ou supprimer. Le résultat en avant-première : seulement trois des dix méritent une place sur la machine d'un développeur au travail, et l'un d'eux dépense discrètement des tokens à chaque réponse.

La définition d'Anthropic tient en une phrase : un mod est une fonction qui s'accroche à un événement, et il peut s'exécuter avant, après, ou à sa place. Un événement, c'est un appel d'outil, un prompt envoyé, ou un morceau d'interface en train d'être dessiné. Les mods sont du TypeScript pur, livré dans un plugin que vous installez comme n'importe quel autre.

Le tweet de lancement a dépassé quatre millions de vues en un jour environ, avec vingt mille likes et plus de signets que de réponses et de reposts réunis. Deux jours après le lancement, un catalogue communautaire avait déjà scanné plus de mille mods publics répartis sur des centaines de dépôts.

Le banc d'essai de ce test est une vraie semaine de travail : 85 sessions sur quatre projets, presque 900 prompts et tout juste moins de 6 000 appels d'outils. Chaque mod est passé par l'audit du validateur, qui liste ce qu'il intercepte et ce qu'il peut toucher, et chaque mod a exécuté la même tâche face à une référence propre, sur la version actuelle, sur la même machine.

Le partage principal : six des dix ne coûtent rien de mesurable à l'exécution, trois coûtent du vrai temps ou de vrais tokens, et un rompt la seule promesse qu'il fait.

Les six discrets restent dans le bruit de la connexion. La jauge d'objectif, la carte thermique du dépôt, l'enregistreur de vol, le routeur de modèle, les signets de session et le relais automatique se situent tous entre un quart de seconde gagné et un cinquième de seconde ajouté, sur une tâche de référence d'environ quatre secondes.

Mod	Écart à l'exécution	Notes
Jauge d'objectif	dans le bruit	volet de décoration
Carte thermique du dépôt	dans le bruit	illumine les fichiers au fil de leur lecture
Enregistreur de vol	dans le bruit	chronologie en direct du tour
Routeur de modèle	dans le bruit	rentable sur les subagents, voir le verdict
Signets de session	dans le bruit	large périmètre de capacités
Relais automatique	~70 ms au repos	écrit un relais à un seuil de contexte

Ils ont fière allure, et rien n'a cassé : chaque exécution de chaque configuration a terminé la tâche correctement. En headless ils ne coûtent rien, puisqu'il n'y a rien à dessiner ; dans un terminal, ces volets se redessinent jusqu'à trente fois par seconde, donc le vrai coût de la catégorie décoration est l'attention plutôt que les tokens.

L'audit du validateur, lui, n'a plus rien de drôle. Le mod de signets peut appeler le modèle, lancer des processus sur votre machine et écrire des fichiers, et il lit vos chemins de configuration dans l'environnement. Rien de tout cela n'est caché et rien n'est malveillant, mais c'est beaucoup de portée pour un signet. Quatre mods sortent ici : la jauge d'objectif, la carte thermique et l'enregistreur de vol, en tant que décoration sans aucun bénéfice mesuré, et le mod de signets parce qu'il demande plus qu'il ne rapporte.

Le moteur de suggestions est le mod que chaque vidéo montre en premier : votre réponse se termine, trois suggestions de prompt apparaissent au-dessus du champ de saisie, vous appuyez sur un chiffre et le brouillon se remplit tout seul. Le mécanisme est documenté par son propre auteur : quand votre tour se termine, il fork la session pour demander ces suggestions à un modèle, et le fork partage le cache de prompt de la session, donc il coûte environ une courte réponse. Les présentations ne mentionnent jamais cette ligne.

Mesuré sur le banc d'essai, cela représente environ 250 tokens de sortie en plus par réponse concernée et près de trois secondes de temps d'attente supplémentaire, et une réponse concernée, c'est presque toutes les réponses : tout ce qui dépasse environ quatre-vingts caractères. Le fork n'a en outre aucune condition sur la surface. Les suggestions ne s'affichent que dans un terminal, mais le fork se déclenche partout, y compris en headless où rien ne peut être affiché.

Mod	Coût mesuré	Quand il se déclenche
Moteur de suggestions	~250 tokens de sortie + ~2,9 s par réponse concernée	chaque réponse de plus de ~80 caractères, y compris en headless
Gardien de cache	~1,5 s par tour, plus des appels au modèle en mode préchauffage	à chaque tour, préchauffage pendant des heures

Le gardien de cache a la même forme : environ une seconde et demie par tour, avec un mode préchauffage qui dépense de petits appels au modèle pendant des heures pour éviter que votre cache de prompt ne refroidisse. Sur un abonnement, la fenêtre de cache est déjà d'une heure, donc vous payez des pings pour résoudre un problème que l'abonnement a en grande partie réglé. Ce sont deux conceptions honnêtes aux coûts documentés, deux taxes sur chaque tour que les listes d'installation ne chiffrent jamais, et les deux sortent de la machine.

Claude Code avait déjà des hooks : un script shell dans vos réglages qui se déclenche sur les mêmes événements. La documentation tranche le choix en une ligne de tableau : un mod sert à l'interface et à la réécriture d'événements ; un hook sert à bloquer, autoriser ou journaliser avec un script que vous avez déjà.

La différence mesurable, c'est le lancement de processus. Un hook de réglages démarre un processus neuf à chaque appel d'outil. Chronométré sur cette machine, un hook shell qui ne fait rien coûte environ 8 ms et un hook qui démarre Node environ 43 ms, à chaque appel, avant même que le script ne fasse quoi que ce soit. Sur les 5 993 appels d'outils de la semaine du banc d'essai, cela fait plus de quatre minutes de pur démarrage d'interpréteur. Un mod n'en paie aucune : son handler s'exécute dans le processus du moteur, et le journal du moteur montre le saut se régler en environ une milliseconde.

Handler	Coût par appel	Une semaine de 5 993 appels
Hook shell (sans effet)	~8 ms	~48 s
Hook Node (sans effet)	~43 ms	~4,3 min
Mod (dans le processus)	~1 ms	~6 s

Le seul vrai retour de migration dans la nature dit la même chose : vingt-sept hooks shell réduits à cinq mods, et le lancement de processus à chaque appel a disparu avec eux. La règle qui survit : interface ou réécriture d'événements, mod ; bloquer, autoriser ou journaliser avec un script de confiance, hook (le coût du lancement ne compte qu'à des milliers d'appels) ; un savoir que vous répétez, skill. Un hook que vous avez lu vaut mieux qu'un mod que vous n'avez pas lu.

Le mod de sécurité le plus simple possible est un garde qui surveille chaque commande shell, et celui-ci a été écrit pour planter. On a demandé à Claude Code de créer un fichier témoin ; le garde a levé une exception ; la commande s'est exécutée quand même et le fichier est apparu. Ce n'est pas un bug mais le comportement par défaut documenté : quand un hook lève une exception, dépasse son délai ou renvoie la mauvaise forme, Claude Code le saute et continue. Une décoration cassée ne doit pas bloquer une session, mais un garde cassé échoue en ouvert, en silence, avec une seule ligne dans un journal de debug que personne ne lit.

Le correctif tient en un catch handler qui renvoie un refus. Le même garde qui plante, avec le catch, refuse la commande et nomme l'échec. Une ligne décide si un garde échoue en ouvert ou en fermé, la documentation fournit exactement ce schéma, et presque personne ne l'installe.

Une équipe de la communauté a rejoué les cas sur la version actuelle, en jugeant d'après des fichiers témoins plutôt que d'après ce que disait le modèle. Le schéma du catch a échoué en fermé trois fois sur trois, et un chemin reste silencieusement cassé : un refus renvoyé après que l'appel a déjà été transmis n'arrête pas l'outil. Le fichier a atterri trois fois sur trois alors que le modèle a été informé que l'écriture avait échoué.

Le retour de terrain qui a nommé ce problème a fait tourner pendant des jours un garde qui était activé, chargé, et ne faisait rien, parce qu'un drapeau périmé l'avait désactivé en dessous : trois pastilles d'état vertes au-dessus d'un compteur bloqué à zéro. Un silence qui ressemble exactement à la bonne santé.

Le garde-collision décroche le premier « garder ». Il résout un vrai problème, deux conversations ouvertes qui éditent le même fichier, et son mode d'échec est bruyant : il demande dans une boîte de dialogue et n'autorise jamais en silence. Il coûte environ une demi-seconde sur les éditions et n'ajoute rien au prompt. Installez-le, et donnez-lui quand même le catch handler.

Anthropic le dit en toutes lettres le jour du lancement : les mods s'exécutent avec le même accès à votre machine que Claude Code lui-même. Ils ne sont pas isolés dans un sandbox ; installez-les comme vous installeriez n'importe quel code sur votre ordinateur. Concrètement, un mod peut agir sur votre machine en tant que vous : lire votre environnement et vos réglages, où vivent les clés d'API ; voir chaque prompt et chaque appel d'outil ; les réécrire ; approuver un appel d'outil avant même qu'on vous le demande ; et dépenser l'usage de votre abonnement en appels au modèle qui lui sont propres.

Deux pièges prennent même les utilisateurs prudents. Les règles de permission encadrent les appels d'outils de Claude, pas les appels propres du mod : refusez un fichier d'environnement à Claude, et un mod peut quand même lire ce fichier directement avec son propre accès aux fichiers, ou lancer un programme qui le fait. La politique réseau a le même défaut : coupez le trafic web et les appels fetch du mod sont refusés, mais un processus enfant lancé par le mod accède au réseau sans restriction. Il existe un mod garde intégré qui se charge avant tout le reste, mais seulement sur les machines gérées et pour les sièges Team ou Enterprise ; un siège solo sur un abonnement personnel n'en a aucun.

Rien de tout cela n'est théorique. Un utilisateur a publié une preuve de concept quelques jours après le lancement : un mod dont le bouton lance un programme et écrit dans le répertoire personnel, installé depuis le catalogue sans aucun avertissement, et son argument tient : le catalogue ressemble à un app store, ce qui suggère une vérification qui n'existe pas. Un bug de hook distinct a cassé l'isolation des subagents pendant une journée ; le mainteneur l'a qualifié de grosse bévue et l'a corrigé une version plus tard.

Le scan du catalogue sur plus de mille mods publics : plus de quatre cents lancent des processus hôtes, près de quatre cents lisent des fichiers, et plus de trois cents voient chaque appel d'outil. La réserve du catalogue est le bon cadrage : c'est une empreinte, pas un verdict ; un suivi de PR doit bien exécuter git. La discipline coûte deux minutes : lancez le validateur avant d'activer quoi que ce soit, et connaissez les sorties de secours : le mode sans échec pour une session, un réglage pour arrêter définitivement tous les hooks installés.

Sur les dix, trois méritent leur place : le garde-collision, le routeur de modèle et le relais automatique.

Mod	Verdict	Le chiffre derrière
Garde-collision	garder	~0,5 s sur les éditions, échoue bruyamment, rien ajouté au prompt
Routeur de modèle	garder	subagent facturé au modèle économique, un tiers du prix
Relais automatique	garder	70 ms de rien, une écriture de relais au seuil de contexte
Moteur de suggestions	supprimer	~250 tokens de sortie + ~2,9 s à chaque réponse concernée
Gardien de cache	supprimer	~1,5 s par tour, pings de préchauffage contre une fenêtre de cache d'1 heure
Mode enregistrement	supprimer	masque l'écran mais pas le disque
Jauge d'objectif	supprimer	décoration, aucun bénéfice mesuré
Carte thermique du dépôt	supprimer	décoration, aucun bénéfice mesuré
Enregistreur de vol	supprimer	décoration, aucun bénéfice mesuré
Signets de session	supprimer	portée bien au-delà de son rôle

Le routeur de modèle a un reçu : une session sur le gros modèle a lancé un subagent, et le relevé d'usage de l'exécution a montré le subagent facturé au modèle économique, un tiers du prix pour le même petit travail. Sur des semaines chargées en subagents, c'est de l'argent réel. Le relais automatique ne coûte rien jusqu'au moment où il rapporte : soixante-dix millisecondes de surcoût au repos, et passé un seuil de contexte il écrit le relais pour le démarrage à froid, une seule fois. L'un des créateurs de la vague admet que le bouton de relais manuel ne fait pas vraiment gagner de temps ; en écriture automatique à un seuil, il en fait gagner.

La discipline qui survit au test : lisez l'audit du validateur avant d'activer quoi que ce soit, donnez à chaque garde son catch handler pour qu'il échoue en fermé, et enregistrez vos démos en mode sans échec plutôt que de faire confiance à un mod de masquage. Les limites sont réelles : une semaine, une machine, une charge de travail, trois exécutions par point sur le petit modèle. Vos trois peuvent différer, mais maintenant vous savez comment les trouver.