Claude Code lance les mods, qui réécrivent prompts et interface

Le 1er octobre, Anthropic a ajouté à Claude Code un mécanisme d'extension appelé mods. Selon le blog officiel, un mod est une courte fonction TypeScript qui s'accroche aux événements de Claude Code et peut réécrire les prompts, ajouter des éléments d'interface, remplacer des fonctions intégrées, ou simplement ajouter une fonction entièrement nouvelle. La CLI et l'application de bureau sont toutes deux prises en charge, à condition de disposer de Claude Code 2.1.287 ou supérieur.

La distribution passe par le système de plugins existant : installation depuis le marketplace de plugins Claude, ou en exécutant /plugin pendant la session. Pour partager un mod maison avec d'autres personnes, il suffit de l'empaqueter en plugin et de le soumettre au marketplace.

Les points où il peut intervenir

Dans Claude Code, chaque appel d'outil, chaque demande de permission, chaque rendu d'une zone de l'écran déclenche un événement ; un mod peut s'exécuter avant ou après cet événement, ou le remplacer entièrement. La liste officielle des capacités comprend :

  • réécrire le prompt qui arrive au modèle ;
  • intercepter, réécrire ou relancer les appels d'outils ;
  • approuver ou refuser les demandes de permission ;
  • retirer une partie du résultat d'un outil avant que Claude ne le lise ;
  • ajouter des boutons et des champs de saisie à l'interface.

Le tutoriel d'introduction du blog développeurs a été rédigé par Addy Osmani et détaille davantage le traitement par le modèle. Chaque hook est un maillon d'une chaîne de middleware et peut s'écrire de trois façons : appeler d'abord next(e) pour laisser passer, puis examiner le résultat, c'est observer ; transmettre plus bas un événement dont on a modifié des champs, c'est réécrire ; ne pas appeler next() et renvoyer directement {deny: "reason"}, c'est répondre. Les événements couverts incluent les appels d'outils, l'envoi de prompts, le début et la fin d'un tour, les commandes slash et le rendu de l'interface.

L'exemple du tutoriel est un mod d'environ 80 lignes nommé Token Weather. Il dessine au-dessus du champ de saisie une sorte de « météo du contexte » : il change d'icône météo selon le taux d'occupation de la fenêtre de contexte, affiche le nombre actuel de tokens avec son pourcentage, accompagné d'un mini-graphique en ligne des 12 derniers tours, et indique de combien la valeur a augmenté par rapport au tour précédent. La partie interface utilise le composant AbovePrompt.

Des hooks aux mods

Claude Code disposait déjà de settings hooks : chaque événement lance une commande shell, échangeant du JSON via stdin et stdout. C'est simple, mais au prix d'un nouveau processus à chaque fois, qui ne garde aucun souvenir de ce qui s'est passé avant.

Les mods se chargent une seule fois au démarrage de la session, puis restent résidents. Le tutoriel liste trois différences : ils peuvent conserver un état, afficher une interface qui évolue dynamiquement, et appeler les fonctions propres de Claude Code, comme ouvrir un panneau ou enregistrer une commande. Pour dessiner son graphique sur 12 tours, Token Weather s'appuie justement sur cet état résident ; avec un shell hook, il faudrait écrire ces données sur disque soi-même.

En reculant encore, l'extensibilité de Claude Code s'est construite couche par couche : d'abord CLAUDE.md et les settings hooks, puis le marketplace /plugin, et il y a quelques jours à peine, la prise en charge d'AGENTS.md a elle aussi été implémentée via un plugin intégré. Les mods transforment le hook, qui n'était jusqu'ici qu'« un script externe accroché », en « du code qui tourne directement dans le processus », ce qui élargit considérablement la portée des modifications possibles.

Limites de sécurité

Plus la portée est large, plus le risque grandit. Le blog officiel le dit sans détour :

Mods run with the same access to your machine as Claude Code itself. They aren't sandboxed, and you should only install mods from sources you trust.

(Les mods disposent du même accès à votre machine que Claude Code lui-même. Ils ne tournent pas dans un bac à sable, et vous ne devriez installer des mods que depuis des sources de confiance.)

Le tutoriel décrit l'environnement d'exécution dans un autre passage : le module tourne dans son propre environnement isolé, sans DOM et sans Node, et toute opération vers l'extérieur doit passer par l'interface $. En rapprochant les deux passages, on comprend que ce qui est isolé, c'est le runtime, pas les permissions. Il suffit qu'un mod reçoive un événement de permission pour pouvoir cliquer sur « approuver » à la place de l'utilisateur.

Les offres Team et Enterprise, ainsi que les machines dotées de paramètres gérés, chargent d'abord un mod intégré nommé sec-default, qui bloque les actions à haut risque des mods installés par l'utilisateur, comme écraser les règles de refus de permission ; les administrateurs peuvent en outre limiter, depuis la console enterprise, quels marketplaces peuvent être installés. Les comptes individuels ne disposent pas de ce filet par défaut. Pour les équipes en Chine continentale, où la barrière de compte et de réseau pour utiliser Claude Code est déjà élevée, les mods ressemblent à court terme davantage à un outil de personnalisation supplémentaire pour les équipes qui utilisent déjà le produit ; la vitesse à laquelle l'écosystème de mods tiers pourra se développer dépendra du degré de permissivité de l'examen du marketplace.

Sources : blog officiel Anthropic Claude, tutoriel d'introduction du blog développeurs Claude, CocoLoop ; le tutoriel officiel a été vérifié quant aux exigences de version, aux types d'événements et au nombre de lignes du code d'exemple.