Tout ce qu'un débutant doit savoir sur Claude : les applications, les modèles, les Projects, la mémoire, les connecteurs, les skills, Cowork, les modes de Claude Code, les plugins et les mods.
Les skills changent ce que Claude sait. Les hooks réagissent à ce qu'il fait. Les serveurs MCP lui donnent des outils. Aucun ne touche à l'interface de Claude Code. Les mods, si. Un mod peut ajouter un panneau à côté de la conversation, afficher un compteur à côté de l'indicateur d'activité, intercepter une commande dangereuse et vous montrer ce qu'elle ferait avant de la lancer. C'est la fonction la plus récente et la moins connue de Claude Code.
Un mod est un plugin qui contient du code JavaScript ou TypeScript. Ce code enregistre des fonctions, appelées hooks, que Claude Code appelle quand un événement se produit : un appel d'outil, un message envoyé, une partie de l'interface à dessiner. Chaque fonction peut observer l'événement, le modifier, ou le prendre en charge à la place de Claude Code.
La différence avec les hooks classiques, ceux de settings.json : un hook classique lance un script externe, une commande shell ou une requête HTTP. Un mod tourne à l'intérieur de Claude Code. C'est ce qui lui permet de dessiner.
Les mods fonctionnent dans le terminal, dans l'onglet Code de l'application Desktop et dans l'extension VS Code, à partir de Claude Code v2.1.287 pour le terminal. Ils sont actifs par défaut.
| Capacité | Exemple |
|---|---|
| Dessiner une interface | Un panneau qui trace l'occupation du contexte après chaque requête |
| Redessiner l'interface existante | Changer l'affichage d'un appel d'outil ou de l'indicateur d'activité |
| Intervenir sur un appel d'outil | Bloquer un git push --force et demander confirmation avec un aperçu |
| Ajouter une commande | Un /replay qui rejoue les modifications du dernier tour, sans appeler le modèle |
| Partager des données entre hooks | Compter les appels d'outils dans un hook, afficher le compte dans un autre |
Une limite volontaire : un mod peut redessiner presque toute l'interface, sauf la demande d'autorisation. Ce que vous montre une demande de permission ne peut pas être maquillé.
Une partie de Claude Code est elle-même écrite sous forme de mods. Tapez /plugin, onglet Installed : ils sont listés sous Built-in.
| Mod intégré | Rôle |
|---|---|
cc-plugin-diff | Dessine le panneau de la commande /diff |
cc-plugin-agents-md | Charge le fichier AGENTS.md comme instructions de projet |
cc-plugin-plugin-authoring | Fournit le skill qui aide Claude à écrire des mods |
cc-plugin-you-should-know | Affiche des suggestions au-dessus de la zone de saisie, désactivé par défaut |
Leur code source est public, dans le dossier mods du dépôt anthropics/claude-code. C'est la meilleure documentation qui soit : des mods complets, avec leurs tests.
Anthropic publie des mods d'exemple dans le dépôt anthropics/claude-code-playground :
token-weather affiche une « météo » de votre fenêtre de contexte au-dessus de la zone de saisie ;blast-radius retient une commande risquée comme rm -rf ou un push forcé, montre ce qu'elle changerait, avec des boutons pour continuer ou annuler ;replay-theater ajoute une commande /replay qui rejoue pas à pas les modifications du dernier tour.Pour en tester un le temps d'une session :
git clone https://github.com/anthropics/claude-code-playground.git
claude --plugin-dir ./claude-code-playground/claude-code/mods/blast-radiusCes exemples sont fournis tels quels, sans support. Lisez-les avant de les lancer, comme tout code.
Un petit mod tient en trois fichiers :
premier-mod/
├── .claude-plugin/
│ └── plugin.json
└── hooks/
├── hooks.json
└── register.jsplugin.json est le manifeste vu au module 7. hooks.json pointe vers le fichier de code. register.js contient le code, appelé module de hooks.
Voici un register.js complet, tiré de la documentation officielle. Il compte les appels d'outils de Claude et affiche le compte à côté de l'indicateur d'activité, sous la forme Thinking · tool calls: 3… :
// Le compteur, partagé par les deux hooks
let calls = 0
// Claude Code appelle cette fonction une fois, au chargement du mod
export function register(on) {
// S'exécute chaque fois que Claude va utiliser un outil
on('tool.call', async ($, e, next) => {
calls += 1
// Demande à Claude Code de redessiner l'interface
$.ui.invalidate('ui.render')
// Laisse l'outil s'exécuter normalement
return next(e)
})
// S'exécute chaque fois que Claude Code dessine l'indicateur d'activité
on('ui.render', { component: 'Spinner' }, async ($, e, next) => {
// Garde l'indicateur d'origine et ajoute le compteur après son texte
return next({ ...e, props: { ...e.props, suffix: ' · tool calls: ' + calls + '…' } })
})
}Tout le principe est là. on(événement, fonction) enregistre un hook. La fonction reçoit $, l'API des mods, e, l'événement, et next, qui passe la main à la suite normale. Appeler next(e) sans rien changer, c'est observer. Appeler next avec un événement modifié, c'est réécrire. Ne pas appeler next et renvoyer autre chose, c'est prendre la main.
Pour faire quoi que ce soit hors de son propre code, dessiner, lire un fichier, appeler un modèle, faire une requête réseau, un hook doit passer par l'API $. C'est ce qui permet à Claude Code de lister ce qu'un mod fait avant même de l'exécuter.
Vous n'êtes pas obligé d'écrire le code vous-même. Décrivez ce que vous voulez dans une session :
Écris-moi un mod qui affiche au-dessus de la zone de saisie le nombre de fichiers
modifiés depuis le début de la session, et qui ajoute une commande /fichiers
qui les liste.Claude charge le skill plugin-authoring, fourni par un mod intégré, et écrit le plugin. Vous le testez avec --plugin-dir, vous ajustez, puis /reload-plugins recharge vos modifications.
Un mod s'installe comme n'importe quel plugin, depuis une marketplace :
/plugin install token-chart@mon-orgPour savoir quels mods une session a chargés, ouvrez /plugin : une ligne grisée sous les onglets indique par exemple 1 mod active · premier-mod.
C'est le point à ne pas survoler. Un mod n'est pas isolé. Une fois chargé, il peut :
Même le bac à sable de Claude Code ne le protège pas : il isole les commandes Bash que Claude lance, pas les processus qu'un mod démarre.
Avant d'installer un mod, récupérez ses fichiers et faites-les analyser :
claude plugin validate ./un-modLes lignes hooks: et calls: du résultat listent les événements que le mod intercepte et ce qu'il demande à Claude Code de faire. Un mod qui prétend afficher la météo du contexte et qui demande l'accès au réseau mérite une explication.
Trois niveaux, selon le besoin :
| Portée | Comment |
|---|---|
| Un seul mod | Le désactiver dans l'onglet Installed de /plugin |
| Tous les mods, pour une session | Lancer claude --safe-mode, qui coupe aussi vos autres personnalisations |
| Tous vos mods, partout | "disableAllHooks": true dans ~/.claude/settings.json, ce qui coupe aussi vos hooks classiques |
--safe-mode est le bon réflexe quand Claude Code se comporte bizarrement. Si le problème disparaît, c'est une personnalisation qui le cause.
Ces quatre mécanismes se recouvrent. Le tableau de décision que j'utilise :
| Je veux | J'utilise |
|---|---|
| Que Claude applique une méthode | Un skill |
| Bloquer, autoriser ou journaliser une action avec un script existant | Un hook dans settings.json |
| Que Claude accède à un système externe | Un serveur MCP |
| Un panneau, une commande instantanée, modifier l'interface | Un mod |
Commencez toujours par le plus simple. Un skill s'écrit en Markdown, un hook en quelques lignes de shell. Le mod est l'outil des cas où les autres ne suffisent pas. Les exemples concrets de l'article sur les cas d'usage des hooks Claude Code montrent jusqu'où on va déjà sans mod.
Vous avez fait le tour : les surfaces, les Projects, la mémoire, les connecteurs, les skills, Cowork, les modes de Claude Code, les plugins et les mods. Personne n'a besoin de tout utiliser. L'important est de savoir que chaque pièce existe, pour reconnaître le jour où elle résout votre problème. Pour la suite côté développeur, la formation Claude Code approfondit CLAUDE.md, les agents parallèles et l'automatisation.