Mods Claude Code : ce que ces plugins peuvent faire, et tout ce qu'ils peuvent atteindre

Anthropic a ouvert le 1er octobre 2026 Claude Code, son agent de programmation, aux mods : de petits programmes en JavaScript ou en TypeScript qui s'exécutent à l'intérieur de l'outil et peuvent en modifier l'interface, les commandes et le comportement. Ils sont activés par défaut depuis la version 2.1.287, dans le terminal comme dans l'onglet Code de l'application de bureau.

L'annonce tombe dans un calendrier chargé. Le 17 septembre, des chercheurs rendaient publique une faille qui permettait à un plugin d'exécuter un autre code que celui qui avait été vérifié. Le 23, Anthropic ouvrait le Claude Marketplace et ses plus de 2 000 connecteurs et plugins. Pour une entreprise, installer une extension de Claude Code revient désormais à installer un logiciel tiers sur le poste d'un salarié, avec tous ses droits.

Qu'est-ce qu'un mod Claude Code ?

Un mod est un plugin de Claude Code composé de gestionnaires d'événements écrits en JavaScript ou en TypeScript. Claude Code les appelle quand un événement se produit (un appel d'outil, un prompt envoyé, un élément d'interface à dessiner) et chacun peut observer l'événement, le modifier ou y répondre à la place de l'outil, d'après la documentation officielle des mods.

Anthropic a commencé par ses propres fonctions. La commande /diff, qui affiche dans un panneau les modifications faites par Claude, est désormais un mod intégré, tout comme la prise en charge des fichiers AGENTS.md. L'éditeur publie aussi trois mods d'exemple, fournis sans support : token-weather affiche au-dessus du prompt une prévision du remplissage de la fenêtre de contexte, blast-radius retient une commande risquée, une suppression récursive ou un envoi forcé sur un dépôt, et montre ce qu'elle changerait avant de proposer de la valider ou de l'annuler, replay-theater ajoute une commande /replay qui rejoue une à une les modifications de fichiers du dernier échange.

Pour une équipe, Anthropic cite dans son annonce un panneau qui suit l'état des déploiements, une confirmation exigée avant toute modification de la production et un journal d'audit des actions de l'agent.

En quoi un mod diffère-t-il d'un skill, d'un hook ou d'un serveur MCP ?

Par l'endroit où il s'exécute. Les hooks déclarés dans les réglages, les skills et les serveurs MCP agissent depuis l'extérieur de Claude Code : ils lancent un script, donnent du texte à lire à Claude ou lui fournissent des outils. Un mod tourne dans le processus même de Claude Code, ce qui lui permet de dessiner dans l'interface et de prendre la main sur un événement avant que l'outil n'agisse.

Ce tableau reprend la comparaison publiée par Anthropic. Le mot « plugin » désigne l'emballage installable, et un même plugin peut contenir un mod, des skills, des hooks et des serveurs MCP. Le mod est la pièce la plus puissante du paquet : un skill ne fait que donner des consignes, un mod exécute du code.

Faut-il savoir coder pour créer un mod ?

Non, pour un premier mod. Il suffit de le décrire en langage courant dans une session Claude Code, par exemple « un mod qui affiche la branche git en cours au-dessus du prompt », et Claude l'écrit à l'aide d'un skill intégré, plugin-authoring, qui lui indique les événements et les fonctions disponibles dans la version installée.

Le mod ne se charge qu'après approbation. Claude Code demande d'abord s'il faut activer le rechargement à chaud pour la session ; une fois accepté, le mod se charge à la fin de l'échange, puis se recharge à chaque modification. Il reste rangé dans un dossier propre à la session, sous ~/.claude/dev-mods/, ne fonctionne que dans celle-ci et disparaît avec le nettoyage automatique des anciennes sessions. Pour le garder, il faut copier son dossier ailleurs et le charger avec l'option --plugin-dir, ou le publier dans une place de marché.

La facilité a sa contrepartie. Un mod écrit par Claude reste du code qui s'exécute avec les droits de l'utilisateur, et la demande en langage courant ne dit rien de ce que le code fait réellement. La vérification décrite plus bas s'applique à lui comme à un mod téléchargé.

Les mods Claude Code sont-ils dangereux ?

Ils le sont autant que leur auteur le permet : un mod malveillant ou mal écrit dispose de tout ce qu'il faut pour nuire, parce que rien ne l'isole du reste de la machine. La documentation énumère ce qu'un mod chargé peut faire :

• agir sur le poste comme l'utilisateur : lire et écrire des fichiers partout où son compte le peut, lancer des programmes, envoyer des requêtes sur le réseau ;
• lire ses secrets : variables d'environnement et fichiers de réglages, y compris une clé d'API qui s'y trouverait ;
• voir toute la session, chaque prompt envoyé et chaque appel d'outil ;
• la modifier : réécrire un prompt ou un appel d'outil, soumettre un prompt comme si l'utilisateur l'avait tapé ;
• agir sans demander, en approuvant un appel d'outil avant que la question ne soit posée ;
• consommer l'abonnement, en appelant un modèle sur le forfait ou la clé d'API de l'utilisateur.

Anthropic ne le cache pas. Sa documentation l'écrit en tête de la page d'installation :

Un mod est du code qui s'exécute avec vos permissions. Il peut lire et écrire vos fichiers, lancer des processus et faire des requêtes réseau. N'installez de mods que depuis des auteurs et des places de marché de confiance.

Le bac à sable de Claude Code ne change rien à ce constat : il isole les commandes que lance Claude, et un programme démarré par un mod s'exécute en dehors. Un seul élément d'interface échappe aux mods, la fenêtre de demande d'autorisation, qu'aucun mod ne peut redessiner pour en changer le contenu.

«

Un mod installé voit chaque prompt et chaque appel d'outil, et peut les réécrire.

Deux épisodes récents montrent que le risque n'a rien de théorique. En février 2026, l'éditeur de sécurité Snyk a analysé 3 984 skills publiés sur deux catalogues tiers, ClawHub et skills.sh. Son étude ToxicSkills en a trouvé 76 contenant une charge malveillante confirmée, vol d'identifiants, accès à distance, exfiltration de données, et 91 % d'entre eux combinaient du code malveillant avec des consignes cachées destinées à l'agent.

Le second épisode touche le mécanisme même de confiance. Les places de marché épinglent chaque plugin sur un commit précis, l'empreinte d'une version du code qui a été relue. La faille Plugin4Shell, rendue publique le 17 septembre 2026 par la société Air Security, montrait que Claude Code, Codex, GitHub Copilot et Gemini CLI demandaient bien ce commit, sans vérifier qu'ils l'avaient obtenu. Le propriétaire d'un dépôt pouvait créer une branche portant le même nom que l'empreinte, et git choisissait la branche. Combinée à la mise à jour automatique des plugins, l'attaque ne demandait aucune action de l'utilisateur. Anthropic a corrigé Claude Code dès juin, dans la version 2.1.179, et OpenAI Codex en août ; au moment de la publication, Copilot n'avait pas de correctif et Gemini CLI, en fin de vie, ne devait pas en recevoir.

La leçon dépasse la faille. La documentation de Claude Code rappelle que, lorsque la mise à jour automatique est active pour une place de marché, les fichiers que l'on a relus peuvent changer sur le disque. Une vérification faite à l'installation ne vaut que pour la version installée.

Comment vérifier un mod avant de l'installer ?

En listant ce qu'il fait sans l'exécuter. Après avoir récupéré les fichiers du plugin, par exemple en clonant son dépôt, la commande claude plugin validate suivie du chemin de son dossier affiche deux lignes : hooks:, les événements que le mod écoute, et calls:, les fonctions qu'il appelle pour agir hors de son propre code.

Ce listage est fiable pour une raison de conception. Un mod ne peut lire un fichier, lancer un programme ou contacter un serveur qu'en passant par l'interface des mods, notée $ dans son code, et Claude Code refuse de charger un mod qui l'utilise d'une façon que l'analyse ne sait pas lire. La page d'administration des mods signale les appels à surveiller :

Côté événements, tool.call et prompt.submit signifient que le mod voit et peut modifier chaque appel d'outil et chaque prompt, et tool.check qu'il peut approuver ou refuser une action avant la demande d'autorisation.

La lecture se fait ensuite au bon sens. Un mod qui affiche une jauge de consommation n'a aucune raison d'appeler $.process.run. Un mod qui lit les variables d'environnement et envoie des requêtes sur le réseau réunit les deux gestes d'une fuite de secrets, et son code mérite une lecture ligne à ligne, même si l'usage est peut-être légitime. Le coût des appels de modèle se surveille aussi : selon le modèle appelé, mille petites tâches coûtent de quelques centimes à plusieurs dollars, comme le détaille notre analyse de Claude Haiku 5.5.

La commande a ses limites. Elle dit ce qu'un mod peut appeler sans rien révéler de ce qu'il fait des données obtenues, et elle ne lit pas les consignes d'un skill livré dans le même plugin, qui agit par le texte et non par le code. Pour savoir si un mod déjà installé cause un problème, l'option --safe-mode lance une session sans aucun mod installé.

Comment encadrer les mods dans une entreprise ?

Par les réglages gérés de Claude Code, que l'administrateur déploie par fichier, par un outil de gestion des appareils ou depuis la console d'administration de claude.ai. Sans réglage particulier, les mods sont actifs et un garde-fou intégré, sec-default, se charge avant ceux des utilisateurs : il protège ce que l'organisation impose (ses hooks, ses consignes, ses serveurs MCP) et fait primer les règles de refus sur les mods des utilisateurs. Pour le reste, les mods des utilisateurs gardent toute latitude.

Les réglages vont du plus ouvert au plus fermé :

Avec allowManagedModsOnly, aucun mod apporté par un utilisateur ne s'exécute, qu'il vienne d'une place de marché, d'un dossier local ou d'une session où Claude l'a écrit, et l'utilisateur ne peut pas lever l'interdiction depuis ses propres réglages. Les mods intégrés à Claude Code continuent de fonctionner, chacun avec son propre interrupteur.

Une petite entreprise où chacun utilise un abonnement individuel n'a souvent aucun réglage géré : la règle repose alors sur les personnes. Quatre habitudes en tiennent lieu. Désigner qui décide d'installer un plugin. Passer chaque mod à la commande de validation et lire le code de ceux qui touchent aux fichiers, aux programmes, au réseau ou aux secrets. Couper la mise à jour automatique des places de marché tierces, pour que le code relu reste celui qui tourne. Et ne pas garder de clés de production dans l'environnement d'un poste où l'on essaie des extensions.

EVOZIA, qui développe ses automatisations et ce site avec Claude Code, applique une règle écrite dans les consignes de chacun de ses projets : aucun skill, plugin ou sous-agent communautaire n'est installé sans lecture préalable de son code source, à la recherche de code malveillant, de fuite d'identifiants ou de consignes cachées. L'agent lui-même n'a pas le droit d'ouvrir les fichiers qui contiennent des secrets. Ces réflexes ne relèvent pas de la seule équipe technique : dès que des salariés utilisent un agent, ils font partie de ce qu'une formation à l'IA doit transmettre.

Cet article est publié par EVOZIA, qui accompagne les PME dans l'adoption de l'IA comme référent IA externalisé, du choix des outils aux règles qui les encadrent. Pour faire le point sur les outils d'IA déjà installés chez vous et sur ceux qui méritent de l'être, le diagnostic IA gratuit est sans engagement.

Questions fréquentes

Les mods Claude Code fonctionnent-ils dans VS Code ?

En partie. Dans le panneau de discussion de l'extension VS Code, les mods s'exécutent mais n'affichent rien : pas de panneau, pas de bandeau, pas d'élément d'interface redessiné. Lancé depuis le terminal intégré de l'éditeur, Claude Code fonctionne en revanche comme dans n'importe quel terminal, affichage compris. Même logique pour l'exécution sans interface et le kit de développement d'agents, où les mods tournent sans rien dessiner. Seule exception notable : dans une session WSL de l'application de bureau, les plugins ne sont pas disponibles, donc aucun mod ne se charge.

Comment désactiver les mods de Claude Code ?

Trois niveaux existent. Pour un seul mod, on désactive ou désinstalle son plugin dans l'onglet des plugins installés de la commande /plugin. Pour tous les mods installés le temps d'une session, on lance Claude Code avec l'option --safe-mode, qui coupe aussi les autres personnalisations. Pour tous les mods installés dans toutes les sessions, on ajoute le réglage "disableAllHooks": true dans le fichier de réglages de l'utilisateur, ce qui arrête aussi les hooks des réglages et la ligne d'état personnalisée. Les mods intégrés à Claude Code échappent à ces réglages et se coupent un par un dans /plugin.

Qu'est-ce que la faille Plugin4Shell ?

C'est une faille d'installation des plugins révélée le 17 septembre 2026 par Air Security, qui touchait Claude Code, OpenAI Codex, GitHub Copilot et Gemini CLI. Les places de marché épinglent chaque plugin sur un commit relu ; les agents demandaient ce commit sans vérifier qu'ils l'avaient obtenu, et une branche portant le même nom pouvait lui être substituée. Avec la mise à jour automatique, du code non relu s'installait sans aucune action de l'utilisateur. Claude Code est corrigé depuis la version 2.1.179, publiée en juin 2026 : vérifier sa version avec claude --version suffit à savoir si l'on est protégé.

Les plugins du Claude Marketplace sont-ils vérifiés par Anthropic ?

Les soumissions passent par un processus de revue, mais Anthropic ne garantit pas le contenu des plugins. L'avertissement affiché avant chaque installation le dit en toutes lettres : l'éditeur ne contrôle pas les serveurs, fichiers et logiciels qu'ils contiennent et ne peut pas vérifier qu'ils ne changeront pas. Le nom d'une place de marché indique qui publie le catalogue, pas ce que fait chaque plugin ; seuls les noms officiels d'Anthropic sont réservés à ses propres dépôts. La documentation recommande donc de relire un plugin avant de l'installer, quelle que soit sa provenance.