Les PLUGINS sur Claude Code : ça devient incontrôlable !!

L'annonce récente des marketplaces dans Claude Code marque une évolution significative, transformant cet environnement en ce que l'on pourrait qualifier de système d'exploitation pour le codage. Cette transformation s'appuie sur l'intégration de commandes slash, d'agents, et maintenant de plugins et de marketplaces. L'objectif principal de cette présentation est d'expliquer comment utiliser efficacement ces nouveaux plugins, comment se connecter aux marketplaces existantes, et, de manière plus avancée, comment concevoir et publier son propre plugin ainsi que sa propre place de marché pour la communauté.

Les plugins supportés par Claude Code sont fondamentalement des collections regroupant des serveurs MCP, des commandes slash, des sous-agents et même des hooks. Cela permet de partager un environnement de travail configuré de manière simple. L'installation de ces paquets se réalise via la commande `/plugin`, actuellement en phase bêta. Cette fonctionnalité est conçue pour permettre l'activation ou la désactivation aisée des configurations créées par d'autres utilisateurs, facilitant ainsi le partage de setups spécifiques.

L'interface de Claude Code révèle une nouvelle commande, `/plugin`, offrant des fonctionnalités pour naviguer (`browse`), installer des plugins, gérer les installations, et ajouter ou gérer des marketplaces. L'utilité première de ces plugins réside dans la capacité à imposer des standards de configuration au sein d'une équipe de développement. Ils sont également précieux pour les mainteneurs de projets open source souhaitant distribuer des outils spécifiques ou des workflows préconfigurés à leur communauté d'utilisateurs.

Pour simplifier l'installation de ces collections de ressources, des marketplaces ont été introduites. N'importe quel utilisateur peut créer sa propre marketplace et la partager publiquement. Pour ce faire, il suffit de disposer d'un dépôt GitHub contenant un fichier nommé `marketplace.json`. L'ajout d'une marketplace se fait via la commande `/plugin marketplace add `.

C'est un peu la communauté et cetera, pouvoir se connecter à des tools et setup des MCP et cetera rapidement et gérer des customisations.

Un exemple est donné en ajoutant la marketplace `cloud code template` en utilisant la commande appropriée. Une fois la marketplace ajoutée, la commande `/plugin` permet de visualiser les plugins disponibles, tels que Git Workflow, Superabase CCO, NextGS Versel Pro, et Security Pro.

Après avoir ajouté la marketplace, l'exécution de `/plugin` affiche les options de navigation. Il est possible de parcourir les différentes marketplaces enregistrées et d'inspecter les plugins disponibles au sein de chacune. Chaque plugin révèle sa composition, incluant les commandes, les agents et les serveurs MCP associés. Cette étape permet de déterminer la pertinence d'un plugin avant de procéder à son installation définitive dans l'environnement de travail.

L'exemple se concentre sur le plugin Security Pro. Après sélection, l'utilisateur confirme l'installation en appuyant sur Entrée. Le système indique alors les composants exacts qui seront ajoutés, comme trois agents et trois commandes spécifiques. L'installation se finalise, et il est ensuite possible de gérer ce plugin via l'option Gérer et désinstaller (`Manage and uninstall`).

Suite à l'installation du plugin Security Pro, il est nécessaire de relancer Claude Code pour que les modifications soient prises en compte dans le projet actif. L'avantage notable est la possibilité de désactiver ou d'activer le plugin via un simple espace dans le menu de gestion. Une fois activé, de nouvelles commandes deviennent accessibles, comme `Security Pro Dependency Audit`.

L'exécution de la commande audit démontre que le plugin utilise ses outils en arrière-plan pour accomplir la tâche demandée, même si la commande spécifique n'est pas jugée révolutionnaire. De même, des agents comme l'agent de test de pénétration Security Pro peuvent être appelés par l'IA. Il est crucial de rester vigilant, car l'ajout de plugins introduit de nouveaux agents et des tokens potentiellement non souhaités dans l'environnement de travail.

La gestion fine de l'activation des plugins est essentielle pour maintenir un environnement propre. Après avoir désactivé Security Pro, un redémarrage est requis pour appliquer les changements. Une fois le redémarrage effectué, le plugin n'est plus visible dans la liste des actifs, et les commandes associées ne sont plus disponibles. Cela illustre la capacité à contrôler précisément quels outils sont injectés dans la session de codage.

Il est possible de constater que le plugin marketplace lui-même contient des ressources. De plus, d'autres outils, comme Websom, peuvent ajouter leur propre dossier `/cloud/plugin` contenant leur propre `marketplace.json`. Cela signifie que plusieurs sources de plugins peuvent coexister et être gérées simultanément via la commande `/plugin add marketplace`.

L'ajout d'une seconde marketplace, comme `cloud code workflow`, suit le même processus : copier le nom du dépôt et l'ajouter. Une fois cette nouvelle source intégrée, les plugins qu'elle contient deviennent visibles et disponibles à l'installation. L'objectif principal de cette modularité est de distribuer facilement des ensembles de paramètres et de configurations entre différents projets ou utilisateurs.

Lorsqu'un plugin est installé, le système effectue un clonage littéral du dépôt source dans la structure locale de l'utilisateur. Ce processus crée un dossier `.cloud` contenant les sous-dossiers pour les commandes et les agents spécifiques à cette installation. C'est cette injection directe des fichiers dans la structure locale qui explique le temps nécessaire à l'installation, car le système doit localiser et rendre accessibles ces nouvelles ressources.

L'analyse révèle que l'installation d'un plugin, comme celui de `cloud code templates`, résulte en l'installation des agents et commandes correspondants dans la structure locale. Le système parvient à lire ce fichier de configuration et à injecter les agents et commandes nécessaires dans l'environnement de travail. Cette compréhension de la structure locale est fondamentale pour ceux qui souhaitent créer ou modifier des plugins.

Pour créer un plugin, il est recommandé de commencer par un projet existant contenant déjà des commandes ou des configurations utiles, comme l'exemple du CLI AI Blueprint. La structure interne du plugin doit respecter un certain patron : un dossier contenant les sous-dossiers `commands`, `agent`, et optionnellement `hook`. Ces dossiers sont automatiquement détectés par le système.

La création d'une marketplace nécessite la définition d'un fichier `marketplace.json` à la racine du dépôt de la marketplace. Ce fichier doit spécifier le nom de la marketplace (ex: IBlueprint), le propriétaire (`owner`), et ensuite définir les plugins qu'elle référence. Pour définir un plugin, il faut lui donner un nom (ex: AIBP base) et spécifier la source relative au projet contenant les configurations réelles.

Une fois cette structure en place, le système est capable de récupérer automatiquement les fichiers de commandes, d'agents et de hooks. Pour rendre cette création accessible, il faut ensuite ajouter le dépôt de cette nouvelle marketplace via la commande `/plugin add marketplace` en spécifiant le chemin du dépôt.

L'installation du plugin nouvellement créé se fait ensuite via l'interface `/plugin browse and install plugin`. Contrairement aux plugins installés depuis un dépôt Git distant, celui-ci est installé directement à partir du chemin local spécifié. Après l'installation, un redémarrage de Claude Code est nécessaire pour que les nouveaux composants soient intégrés correctement.

La confirmation du bon fonctionnement s'obtient en vérifiant la liste des commandes, des agents et des hooks disponibles après le redémarrage. L'exécution de `/hook` permet de visualiser si le hook défini dans le plugin a été correctement activé. Enfin, l'invocation directe des commandes personnalisées (ex: AIBP base) prouve que le plugin est opérationnel et utilisable par n'importe quel développeur.

La création d'un plugin repose sur l'établissement d'une structure de dossiers adéquate contenant les hooks, les commandes et les agents. L'alternative à la structure de dossiers est de pointer directement vers les fichiers, bien que cette méthode soit jugée plus verbeuse et moins maintenable, car les ajouts futurs de fichiers ne seraient pas automatiquement détectés. Une fois la structure validée, il suffit de référencer le dossier source dans le fichier `marketplace.json`.

Tu vois que c'est assez simple finalement. Alors au début ça m'a un peu pris la tête parce que j'avais voulu le faire sans lire la doc mais quand tu lis la doc on s'y retrouve.

Une fois le plugin créé, il est possible de le rendre accessible en committant le fichier `marketplace.json` et en partageant le lien GitHub pour une installation par d'autres utilisateurs.

L'avis personnel est que l'implémentation des marketplaces introduit une complexité superflue dans le processus d'ajout d'outils. Il serait préférable d'avoir une commande plus directe, telle que `/plugin add ` ou `/plugin add `, similaire au fonctionnement de ChatCNUI avec son registre JSON. L'approche actuelle force l'utilisateur à gérer des dépôts entiers pour installer une seule fonctionnalité.

Le principal danger réside dans l'installation non maîtrisée de nombreux plugins. L'accumulation de commandes et d'agents, souvent utilisés une seule fois, conduit à une pollution du contexte qui diminue la performance et la clarté des appels d'IA. Il est conseillé aux utilisateurs de privilégier l'intégration manuelle des commandes spécifiques nécessaires plutôt que d'installer des suites logicielles complètes si le contrôle est privilégié.