Mods Claude Code : et si votre session pouvait se piloter elle-même ?

Aujourd'hui, tout le monde parle des skills. Les utilisateurs de Claude Code commencent à bien les connaître : des instructions réutilisables pour expliquer à l'agent comment réaliser une tâche.

Mais une autre possibilité existe depuis ce mois d’octobre et mérite qu'on s'y arrête : les mods.

Ils ne sont pas une énième manière de donner des instructions à Claude. Ils changent l'endroit où l'on peut intervenir : au cœur même de la session, et plus seulement autour d'elle.

Dans cet article, nous allons voir ce qu'est un mod, comment en créer ou en installer un, puis explorer deux usages : le routage automatique de modèle et la mémoire entre sessions. Avec une première question en tête : pourquoi mobiliser le modèle le plus puissant pour une demande qui n'en a pas besoin ?

Qu'est-ce qu'un mod, précisément ?

Un mod est un plugin Claude Code dont le code enregistre des gestionnaires d'événements, appelés hooks. Lorsque l'événement se produit (démarrage de session, appel d'un outil, lancement d'un sous-agent…), Claude Code exécute la fonction correspondante. [1]

Concrètement, un petit mod tient en trois fichiers : le manifeste du plugin, un fichier hooks.json qui pointe vers le code, et un module JavaScript ou TypeScript qui déclare les événements à écouter. [1]

La différence avec ce que nous connaissons déjà est dans l'endroit où le code tourne :

les hooks « classiques » sont configurés dans un fichier de paramètres et lancent une commande shell, une requête HTTP ou un prompt les skills et les serveurs MCP fonctionnent depuis l'extérieur : ils donnent à Claude du texte ou des outils ; un mod s'exécute à l'intérieur de Claude Code, ce qui lui permet de faire des choses que les autres ne peuvent pas faire. [1]

Pour reprendre une image : un skill, c'est la fiche de procédure que l'on remet à Claude. Un mod ressemble plutôt à un chef de salle qui voit passer chaque commande et peut intervenir en plein service.

Cette analogie a une limite : un mod n'est pas un conseiller, c'est du code. Il tourne avec les mêmes permissions que vous. Nous y reviendrons.

Quelques exemples d’utilisation des mods

Premier exemple : le routage automatique de modèle

Choisir son modèle en fonction de la tâche est une bonne habitude. Mais si ce choix se faisait automatiquement ? Et si, au sein d'une même session, chaque nouvelle demande pouvait être confiée au modèle le plus adapté ?

Le principe du routage est simple : choisir, pour chaque demande ou chaque sous-agent, le modèle le moins cher qui reste suffisant.

Plusieurs implémentations existent, avec des philosophies différentes :

un routage à chaque tour, conditionné par un modèle de coût qui tient compte du cache de prompt [3] un routage par paliers sur les sous-agents : léger vers Haiku, standard vers Sonnet, profond vers Opus, la session principale ne changeant jamais de modèle pour préserver son cache [5] un routage au lancement des sous-agents éligibles, où le mod interroge Jev sur le niveau de jugement et la quantité de travail nécessaires, puis ajuste le modèle et l'effort. La version actuelle de cette implémentation demande Claude Code v2.1.308 minimum et une clé TypeSafe ou OpenRouter. [6]

Le dernier exemple n'est pas anodin. Choisir entre un nombre limité de modèles est une décision de classification, un cas d'usage des modèles « System One », comme nous le voyons dans notre article sur Jev. L'idée : évaluer la tâche pour décider de son routage, plutôt que produire une longue réponse pour choisir qui répondra. [6]

Attention toutefois à ne pas confondre modèle moins cher et requête moins chère. Le routage a lui-même un coût, et changer de modèle peut rendre nécessaire un nouveau cache pour le contexte. C'est précisément ce que l'implémentation de schwepps cherche à prendre en compte, tandis que celle de blackmath88 conserve le modèle de la session principale. Les économies restent à mesurer sur vos propres tâches, sans sacrifier la qualité des résultats. [3] [5]

Pour installer le routeur de schwepps

Commencez par vérifier votre version dans le terminal :

Puis, dans le prompt d'une session Claude Code en terminal, lancez :

Acceptez l'ajout du marketplace et choisissez la portée d'installation : la portée utilisateur charge le plugin dans toutes vos sessions. Si nécessaire, rechargez les plugins :

La commande /route permet ensuite de consulter l'état du routage et les économies annoncées par le mod. Évitez d'activer plusieurs routeurs en même temps pour un premier essai : vous voulez savoir lequel prend la décision. [3]

Dans l'app Desktop, le README propose de passer par le bouton +, puis Plugins, Add marketplace, avec schwepps/claude-mods, avant d'ajouter le plugin. [3]

Second exemple : construire une mémoire entre sessions

Vous passez d'un projet à l'autre, puis revenez sur un sujet quelques jours plus tard. Le code est toujours là, mais pas nécessairement le raisonnement qui l'a fait évoluer : pourquoi avoir écarté cette bibliothèque ? Quelle contrainte explique cette architecture ? Qu'est-ce qui a déjà été essayé sans succès ?

Tenir un journal aide, mais encore faut-il le mettre à jour et retrouver le bon passage au bon moment. Le principe d'une mémoire automatisée est de boucler ce travail : retrouver le contexte pertinent avant de répondre, puis conserver les nouveaux enseignements après le travail. Cela ne reconstitue pas une fenêtre de contexte identique ; cela sélectionne des informations utiles dans une base persistante.

CortexDB avec le mod cortexdb-live : le plugin stocke mémoire et graphe de connaissances dans une base SQLite, locale par défaut. Le mod prépare une recherche à partir du prompt, affiche les éléments rappelés et, après 90 secondes d'inactivité, fait extraire les informations durables de la nouvelle portion de conversation par Haiku. Il s'appuie sur l'accès aux modèles de Claude Code, ce qui consomme de l'usage même sans clé API supplémentaire. [8]

Pour installer CortexDB et son mod

Dans le prompt de Claude Code en terminal :

Le plugin cortexdb fournit la mémoire cortexdb-live est une couche complémentaire, pas un remplacement. Rechargez les plugins ou ouvrez une nouvelle session après l'installation. [8]

Le README demande aussi d'autoriser trois outils précis pour que le mod puisse rappeler et enregistrer des souvenirs. Ajoutez-les à la liste permissions.allow existante de ~/.claude/settings.json, sans écraser vos autres règles :

La bande au-dessus du prompt permet de voir les éléments rappelés ; la ligne de statut indique la base utilisée ou les autorisations manquantes. Pour tester l'intérêt de cette mémoire, faites enregistrer une décision de projet non sensible, puis vérifiez dans une nouvelle session si elle est retrouvée et correctement contextualisée. [8]

La promesse n'est pas de « tout retenir ». Une mémoire utile doit aussi distinguer un fait d'une hypothèse, remplacer une décision devenue obsolète et éviter d'injecter du contexte sans rapport. Avant de l'activer sur des projets professionnels, vérifiez ce qui est capturé, où les données sont stockées et quels fournisseurs reçoivent le contenu. Stockage local ne veut pas dire traitement intégralement local : les appels aux modèles peuvent transmettre les informations à un service distant.

Comment créer un mod ?

Le plus simple est de demander directement à Claude Code de créer un mod, en décrivant précisément le comportement attendu. Par exemple :

Crée un mod qui affiche le nom de la branche Git au-dessus du prompt et le met à jour quand elle change.

Claude écrit les fichiers nécessaires. Lorsqu'il enregistre le premier fichier, Claude Code propose d'activer le rechargement à chaud pour la session : si vous l'autorisez, le mod se charge à la fin du tour, puis se recharge après chaque modification. Selon le mode de permissions, la création des fichiers demande aussi une approbation. Ce n'est donc pas seulement du texte ajouté au contexte : vous autorisez l'exécution de code. [7]

Vous pouvez aussi partir de mods publics disponibles sur GitHub. Deux exemples illustrent bien ce qu'ils apportent :

model-router, dans le dépôt schwepps/claude-mods, choisit le modèle à chaque tour et pour les sous-agents, en tenant compte du coût du cache [3]session-link, dans r1305/claude-mods, permet à des sessions parallèles d'échanger des messages et de partager des décisions dans un tableau commun. Il s'agit de coordination entre sessions, pas d'une mémoire durable : les entrées du tableau expirent au bout de sept jours. [4]

Deux usages complémentaires : adapter les ressources mobilisées et faire circuler l'information entre sessions.

Ce que l'API des mods permet

La documentation décrit une API qui permet à un mod d'ajouter des commandes pour l'utilisateur et des outils pour Claude appeler un modèle de son propre chef, hors de la conversation, pour une petite tâche de tri ou de résumé exécuter du travail sur un minuteur, entre les tours envoyer des messages à d'autres sessions ou sous-agents accéder aux fichiers, aux processus et au réseau.

Côté prérequis, les mods sont activés par défaut. Dans le terminal, la documentation indique Claude Code v2.1.287 minimum dans l'onglet Code de l'app Desktop, le support commence avec la version embarquée v2.1.286. Certains mods utilisent des API plus récentes et demandent davantage : vérifiez toujours leur README. [1]

Un point à ne pas négliger : la confiance

Un mod s'exécute avec vos permissions : il peut accéder aux fichiers et aux secrets accessibles à votre compte, lancer des processus, faire des requêtes réseau et consommer votre usage des modèles. Les mods ne sont pas isolés par le sandbox des commandes Bash de Claude Code. Installer un mod, c'est accorder sa confiance à du code, pas simplement ajouter des instructions. [1]

Avant un essai, lisez le code et les instructions du dépôt. Sur une copie locale du plugin, la commande claude plugin validate ./chemin-du-plugin permet aussi de lister les hooks et les appels à l'API détectés sans exécuter le mod. Ce contrôle est utile, mais ne remplace pas une revue de sécurité. [1]

Conclusion

Les skills disent à Claude comment faire. Les mods nous laissent intervenir dans le déroulement même de la session : quel modèle répond, quand une information est rappelée, ce qui est affiché.

Personnellement, c'est le routage de modèle qui me semble le meilleur point d'entrée : simple à comprendre et testable sans bouleverser ses habitudes. Son intérêt se mesure sur le coût réel des requêtes ou sur l'usage du forfait, mais aussi sur la qualité et le temps de réponse. Il faudra le tester sur nos propres usages avant de parler de révolution, mais la question qu'il pose est déjà pertinente : avons-nous besoin du modèle le plus puissant pour chaque demande ? (Mention spéciale à Mahé qui me demandait d’arrêter d’utiliser Opus pour tout)

Et maintenant que nous savons que nos sessions peuvent accueillir du code, nous aurons de plus en plus d'idées de mods à écrire.

Sources

Anthropic, « Mods overview » : https://code.claude.com/docs/en/plugins/mods/overview

Anthropic, « Utiliser l'API mods » : https://code.claude.com/docs/fr/plugins/mods/api

schwepps/claude-mods : https://github.com/schwepps/claude-mods

r1305/claude-mods : https://github.com/r1305/claude-mods

blackmath88/routing-mod-claude : https://github.com/blackmath88/routing-mod-claude

Akurganow/model-router : https://github.com/Akurganow/model-router

Anthropic, « Create a mod » : https://code.claude.com/docs/en/plugins/mods/create.md

CortexDB, présentation et mod cortexdb-live : https://github.com/liliang-cn/cortexdb

Cognee, « Cognee Plugin for Claude Code » : https://docs.cognee.ai/integrations/claude-code-integration