Un plugin capable de modifier les prompts, d’intercepter les appels d’outils et de redessiner l’interface transforme Claude Code en plateforme extensible. Anthropic ouvre désormais ses Mods aux développeurs, sous la forme de fonctions JavaScript ou TypeScript exécutées au cœur d’une session. La personnalisation gagne en profondeur, mais la frontière de confiance devient aussi beaucoup plus large.
Le premier plugin officiel, « You Should Know », illustre cette nouvelle approche : un agent séparé signale des informations importantes que l’utilisateur pourrait manquer. Derrière cette fonction pratique se joue une évolution plus importante pour les équipes de développement : les extensions ne se contentent plus d’ajouter une commande, elles peuvent agir sur le comportement de l’agent, ses permissions, ses sorties et son interface.
Des extensions qui interviennent au cœur de Claude Code
Les Mods sont de petites fonctions JavaScript ou TypeScript qui réagissent aux événements internes de Claude Code. Ils peuvent observer une action, la modifier, la bloquer, la remplacer ou exécuter du code avant et après son traitement normal.
Cette architecture rapproche Claude Code d’un système de middleware. Un Mod peut intervenir lors de l’envoi d’un prompt, d’un appel d’outil, d’une demande de permission ou du rendu de l’interface. Il devient ainsi possible d’adapter l’agent à un environnement de travail précis, sans attendre une fonctionnalité intégrée par Anthropic.
Anthropic indique notamment qu’un Mod peut :
- réécrire un prompt avant son envoi au modèle ;
- bloquer ou relancer un appel d’outil ;
- approuver ou refuser une demande de permission ;
- filtrer ou masquer des informations dans la sortie d’un outil ;
- ajouter des commandes et des éléments d’interface ;
- remplacer une fonction intégrée par une implémentation personnalisée.
Les Mods sont distribués à l’intérieur de plugins et s’installent avec le système de plugins existant, notamment via la commande /plugin. La fonctionnalité est disponible dans l’interface en ligne de commande et dans l’application de bureau de Claude Code.
La version 2.1.287 ou une version ultérieure est requise pour utiliser ce système. Cette contrainte place les Mods dans une logique de déploiement logiciel classique : les équipes doivent gérer la version du client, la compatibilité des extensions et l’ordre de chargement.
Le vrai changement pour les développeurs : contrôler le comportement, pas seulement les outils
Jusqu’à présent, l’extension d’un agent de développement reposait surtout sur des instructions, des skills, des commandes personnalisées ou des connexions à des outils externes. Les Mods descendent à un niveau plus profond : ils peuvent modifier le déroulement même de la session.
Pour un développeur, cette différence est importante. Une instruction peut orienter le modèle, mais elle ne constitue pas nécessairement une règle d’exécution. Un Mod, lui, peut intercepter un événement et appliquer une logique programmée avant que Claude Code ne poursuive son action.
Des garde-fous adaptés au dépôt
Une équipe peut utiliser un Mod pour appliquer des règles propres à son dépôt. Il peut, par exemple, vérifier le contexte d’une commande, empêcher certaines opérations ou ajouter des informations à un prompt avant qu’il ne soit transmis au modèle.
L’intérêt n’est pas uniquement de bloquer. Un Mod peut aussi enrichir la session en injectant des conventions de code, en affichant un panneau de contexte ou en mettant en évidence les changements sensibles. L’extension devient alors une couche d’orchestration entre le développeur, le modèle et les outils du projet.
Cette possibilité modifie la répartition entre configuration et développement. Les règles les plus simples peuvent rester dans les fichiers de configuration ou les instructions du projet. Les règles qui doivent observer, transformer ou interrompre des événements peuvent être confiées à un Mod.
Une interface adaptée aux usages internes
Les Mods peuvent également modifier l’interface dans le terminal ou l’application de bureau. Une entreprise peut ainsi afficher des indicateurs propres à son environnement, des alertes de sécurité ou des informations issues de ses systèmes internes.
Cette capacité rapproche Claude Code d’un environnement de développement configurable. Elle peut servir à afficher l’état d’une tâche, la branche Git active, des avertissements liés à un dépôt ou des informations liées à la conformité.
Mais cette souplesse crée aussi une exigence de lisibilité. Plus une extension modifie l’interface et le comportement de l’agent, plus l’utilisateur doit savoir ce qui est natif et ce qui provient d’un plugin. Sans cette distinction, une action produite par un Mod peut être attribuée à tort à Claude Code lui-même.
Le point de sécurité décisif : les Mods ne sont pas isolés
Le principal enjeu n’est pas le langage utilisé, mais le niveau d’accès accordé au code. Anthropic précise que les Mods s’exécutent avec les mêmes permissions que Claude Code et qu’ils ne sont pas isolés dans une sandbox.
Installer un Mod revient donc à exécuter du code provenant de son éditeur avec les privilèges disponibles dans la session. La question ne se limite plus à la qualité de la fonction affichée ou à la pertinence de son interface. Elle concerne également les opérations que le code peut effectuer sur la machine et dans le contexte de travail.
À retenir : un Mod n’est pas un simple thème d’interface. Il s’exécute avec les accès de Claude Code et peut intervenir sur des événements sensibles, notamment les outils et les permissions.
Cette architecture offre une grande puissance, mais elle élargit la surface de confiance. Un plugin peut être conçu pour remplir une fonction légitime tout en contenant une logique inattendue. Une mise à jour peut aussi modifier son comportement après l’installation initiale.
Pourquoi l’ordre de chargement compte
Lorsque plusieurs Mods écoutent le même événement, ils s’exécutent dans leur ordre de chargement. Le premier Mod chargé voit l’événement en premier et reçoit le résultat final après les autres étapes.
L’ordre devient donc une composante de sécurité et de fonctionnement. Deux extensions qui interviennent sur un même appel d’outil peuvent produire des résultats différents selon leur position dans la chaîne. Un Mod de filtrage placé trop tard pourrait ne pas contrôler la donnée qu’un autre Mod a déjà transformée ou transmise.
Cette logique introduit une forme de dépendance entre extensions. Les équipes doivent connaître les points d’intervention de chaque plugin, leurs priorités et les conséquences d’un changement de configuration.
Dans un environnement professionnel, la gestion des Mods devrait donc inclure une liste approuvée, un contrôle des versions et une procédure de validation avant déploiement. Le code de l’extension devient un composant du poste de développement, au même titre qu’une dépendance logicielle.
Les contrôles d’organisation limitent le risque, sans le supprimer
Anthropic prévoit des mécanismes permettant aux organisations de contrôler les plugins et les Mods qui se chargent dans Claude Code. Les administrateurs peuvent autoriser ou bloquer des marketplaces de plugins.
Sur les offres Team et Enterprise, ainsi que sur les machines utilisant des paramètres administrés, un Mod intégré appelé sec-default est chargé en premier. Il empêche notamment les Mods installés par les utilisateurs d’outrepasser certaines règles de refus de permission.
| Niveau de contrôle | Fonction | Enjeu pour l’équipe |
|---|---|---|
| Marketplace de plugins | Autoriser ou bloquer des sources de plugins | Réduire l’installation d’extensions non approuvées |
| Paramètres administrés | Appliquer des règles depuis l’environnement géré | Centraliser la configuration de Claude Code |
Mod sec-default | Charger un garde-fou de sécurité en premier | Préserver certaines règles de refus |
| Ordre de chargement | Déterminer quelle extension voit l’événement en premier | Éviter les conflits entre Mods |
Ces mécanismes donnent aux équipes un levier de gouvernance. Ils ne transforment toutefois pas les Mods en code isolé : l’extension conserve le niveau d’accès de Claude Code, et sa logique doit rester vérifiable.
Le rôle de sec-default est particulièrement important parce que les Mods peuvent agir sur les demandes de permission. Une extension mal configurée ne doit pas pouvoir neutraliser une règle de sécurité imposée par l’organisation. La présence d’un Mod chargé en premier répond à ce risque précis.
Anthropic indique aussi que les administrateurs qui remplacent l’ordre de chargement par défaut doivent conserver explicitement ce Mod de sécurité pour maintenir ses restrictions. La configuration devient ainsi un élément critique : modifier la séquence peut modifier le niveau de protection.
Une gouvernance proche de celle des dépendances internes
Pour les équipes, la bonne question n’est pas seulement « ce Mod est-il utile ? ». Il faut aussi savoir qui le maintient, quelles données il peut lire, quels événements il intercepte, quelle version est utilisée et comment ses mises à jour sont contrôlées.
Un registre interne des extensions peut répondre à ces besoins. Il peut associer chaque Mod à son propriétaire, à son dépôt, à une version approuvée et à une liste d’événements autorisés. Cette discipline est particulièrement importante pour les projets qui traitent du code propriétaire, des secrets ou des données de production.
L’installation d’un plugin devrait également être séparée de son approbation. Un développeur peut tester un Mod dans un environnement isolé du dépôt principal, tandis qu’une équipe responsable de la sécurité valide ensuite son utilisation dans l’environnement de travail partagé.
« You Should Know » montre la direction prise par Anthropic
Le premier plugin officiel présenté par Anthropic, « You Should Know », utilise un agent séparé pour signaler des informations importantes que l’utilisateur pourrait manquer. Cette fonction ne se contente pas d’ajouter une commande : elle intervient dans l’expérience de travail pour attirer l’attention sur certains éléments.
Le choix de ce premier exemple est révélateur. Anthropic met en avant un Mod qui complète l’agent principal plutôt qu’une simple intégration à un service externe. Le système peut ainsi jouer le rôle d’une seconde paire d’yeux dans une session de développement.
Pour les développeurs, l’intérêt potentiel est concret : attirer l’attention sur une conséquence d’une modification, un détail d’une sortie ou une information pertinente dans le déroulement d’une tâche. La valeur dépend toutefois de la précision des alertes. Un système qui signale trop d’éléments risque de créer une fatigue d’attention et de réduire l’impact des avertissements réellement importants.
Cette fonction illustre aussi une nouvelle architecture de collaboration entre agents. Claude Code peut être entouré de Mods spécialisés qui observent certains événements et ajoutent un contrôle ou un commentaire. La session ne repose plus uniquement sur un modèle principal, mais sur un ensemble de composants coordonnés.
Mods, skills et MCP : des rôles différents dans une même pile
Les Mods ne remplacent pas toutes les autres méthodes d’extension. Ils se distinguent des skills, qui regroupent des instructions ou des capacités réutilisables, et de MCP, qui permet de connecter Claude Code à des outils ou à des sources de données externes.
Un skill agit principalement sur la manière dont l’agent accomplit une tâche. Une connexion MCP expose des outils ou des ressources. Un Mod, lui, peut intervenir dans le cycle interne de Claude Code, notamment avant ou après un appel d’outil, lors d’une demande de permission ou pendant le rendu de l’interface.
| Mécanisme | Rôle principal | Type d’intervention |
|---|---|---|
| Skill | Décrire une méthode ou une capacité réutilisable | Instructions et procédures |
| MCP | Connecter l’agent à des outils ou des données | Accès à des services et ressources |
| Mod | Modifier le comportement de Claude Code | Interception d’événements et interface |
| Plugin | Distribuer un ensemble d’extensions | Installation et partage de composants |
Cette distinction aide à choisir le bon niveau d’extension. Une procédure stable et lisible a intérêt à rester un skill. Une intégration avec un système externe relève plutôt de MCP. Une règle qui doit filtrer un appel ou modifier une permission nécessite la puissance d’un Mod.
Le risque augmente avec la profondeur d’intervention. Plus une extension se rapproche du moteur d’exécution, plus elle doit être traitée comme un composant logiciel sensible. Un Mod qui modifie uniquement l’affichage n’a pas le même profil qu’un Mod capable d’approuver une demande ou de transformer la sortie d’un outil.
Ce que les équipes doivent changer dans leur pratique
L’arrivée des Mods impose surtout de revoir la gestion des extensions. Le téléchargement d’un plugin ne peut plus être assimilé à l’installation d’un simple ajout cosmétique.
Une politique interne efficace peut s’appuyer sur plusieurs règles :
- vérifier le code et l’éditeur avant installation ;
- limiter les sources de plugins autorisées ;
- tester chaque Mod sur un dépôt de démonstration ;
- documenter les événements interceptés ;
- figer les versions validées ;
- contrôler les changements de l’ordre de chargement ;
- maintenir les règles administrées et le Mod
sec-default; - retirer les extensions inutilisées ou non maintenues.
La revue de code doit porter sur les effets réels du Mod, pas seulement sur son fichier principal. Il faut examiner les dépendances, les appels réseau, la lecture de fichiers, l’écriture sur le disque et les processus lancés par l’extension.
Les tests doivent aussi couvrir les interactions entre Mods. Une extension qui fonctionne seule peut se comporter différemment lorsqu’elle partage un événement avec un autre plugin. Les équipes doivent notamment tester les refus de permission, les erreurs d’outil, les sorties contenant des secrets et les mises à jour de version.
Le prompt devient une surface de contrôle
La possibilité de réécrire un prompt avant son envoi au modèle crée un point de contrôle puissant. Elle peut servir à ajouter un contexte utile, à appliquer une convention ou à retirer une information sensible.
Elle peut aussi modifier le sens de la demande sans que l’utilisateur le voie immédiatement. Les équipes doivent donc rendre visibles les transformations importantes, notamment lorsque le Mod ajoute des instructions ou supprime une partie du contexte.
La traçabilité devient essentielle. Un journal interne peut indiquer quel Mod a modifié un événement, dans quel ordre et avec quel résultat. Sans cette information, le diagnostic d’un comportement inattendu peut devenir difficile, surtout lorsque plusieurs extensions agissent sur la même session.
Les permissions ne doivent pas être déléguées sans contrôle
Un Mod capable d’approuver ou de refuser une permission intervient directement dans le modèle de sécurité de Claude Code. Cette capacité peut réduire les interruptions dans un flux de travail, mais elle peut également autoriser une action que l’utilisateur ou l’organisation voulait bloquer.
Le principe le plus important consiste à séparer les permissions de confort des permissions critiques. Une automatisation peut accélérer certaines opérations répétitives, tandis que les actions sensibles doivent rester soumises à une règle administrée ou à une validation explicite.
Le chargement prioritaire de sec-default répond à une partie de ce problème pour les environnements concernés. La protection dépend cependant du maintien de ce Mod dans la configuration et du respect de l’ordre prévu.
Une plateforme plus programmable, avec une responsabilité plus large
Les Mods font évoluer Claude Code d’un assistant configurable vers une plateforme programmable. Les développeurs peuvent désormais intervenir sur les prompts, les outils, les permissions, les sorties et l’interface à partir de code JavaScript ou TypeScript.
Cette évolution peut accélérer la création d’expériences internes adaptées à chaque équipe. Elle permet aussi de transformer des règles de développement en contrôles exécutables, plutôt qu’en recommandations uniquement documentées.
La contrepartie est claire : un Mod possède une capacité d’action comparable à celle de l’agent auquel il s’ajoute. Sa sécurité dépend donc de la confiance accordée à son code, de la gouvernance des plugins et de la visibilité donnée à ses interventions.
À retenir : les Mods apportent à Claude Code une couche d’extension profonde, mais leur installation doit être gérée comme l’exécution de code avec les privilèges de l’agent.
Notre avis : les Mods seront utiles aux équipes qui savent les gouverner
Les Mods constituent une avancée importante pour les développeurs qui veulent adapter Claude Code à leurs processus sans attendre une fonction native. Leur capacité à intercepter les événements rend possibles des contrôles précis, des interfaces internes et des garde-fous adaptés à chaque dépôt.
Notre avis est tranché : les équipes individuelles peuvent expérimenter les Mods sur des projets non sensibles, mais les entreprises doivent les intégrer à leur politique de plugins, à leur revue de code et à leur gestion des versions. Le bénéfice ne vient pas de la quantité d’extensions installées, mais de la maîtrise de celles qui ont accès au cycle d’exécution.
Dans les six prochains mois, la question centrale sera moins la créativité des Mods que leur industrialisation. Les équipes devront déterminer quelles extensions deviennent des composants approuvés, lesquelles restent expérimentales et comment rendre leurs effets visibles pendant une session de développement. Claude Code gagnera-t-il alors un véritable écosystème de Mods fiables, ou la puissance de ces extensions imposera-t-elle des politiques aussi strictes que celles des dépendances de production ?