Les plugins Claude Code, ou Hubskillz
Claude Code installe des plugins depuis un marketplace, un dépôt Git qui déclare une liste de plugins. Un plugin regroupe des skills, des commandes, des sous-agents, des hooks et des serveurs MCP.
Le plugin est le bon format pour livrer skills, commandes, hooks et serveurs MCP en un bloc, et une organisation Team ou Enterprise peut déployer son marketplace. La version reste celle du paquet, l’auto-update applique la nouvelle sans que personne lise le diff, et rien ne remonte l’état réel des machines. Prenez le plugin pour un outil interne cohérent. Prenez Hubskillz quand chaque skill doit être validé et suivi séparément.
Dernière mise à jour : 30 août 2026
En un coup d’œil
| Critère | Plugins Claude Code | Hubskillz |
|---|---|---|
| Unité distribuée | Un paquet : skills, commandes, sous-agents, hooks, MCP | Un skill à la fois, avec son historique |
| Distribution | Un marketplace Git. Portée perso, projet dans .claude/settings.json, ou imposée par l’organisation | Un catalogue par organisation, posé sur chaque machine par le CLI |
| Mise à jour | Auto-update par marketplace. Désactivé, les machines divergent ; activé, la nouvelle version arrive sans relecture | Une version validée après review, appliquée par hubskillz sync |
| Validation avant diffusion | La pull request sur le dépôt du marketplace | Brouillon, diff et validation dans le navigateur |
| Vue centrale | L’administrateur fixe les marketplaces et les plugins activés. L’état réel des machines ne remonte pas | État par machine et par projet, remonté par le CLI |
| Granularité | Une version par paquet | Une version par skill |
| Portée | Claude Code, y compris en distribution par l’organisation | Claude Code par le CLI, claude.ai par export ZIP |
| Skill modifié en local | Non suivi | Signalé comme modifié, jamais écrasé sans --force |
Ce qu’un plugin résout
Le plugin est le bon format pour livrer un outil complet : le skill, la commande qui l’appelle, le hook qui le déclenche et le serveur MCP dont il dépend arrivent ensemble, en une installation.
Pour une équipe qui publie un outil interne et le fait évoluer lentement, un marketplace privé fait le travail.
Ce que le marketplace ne dit pas
Une organisation Team ou Enterprise peut déployer son marketplace et pré-activer des plugins, et un projet peut les déclarer dans .claude/settings.json. Ce qui reste hors de portée, c’est le constat : rien ne remonte ce que les machines chargent réellement, et la question « qui tourne encore sur la version précédente » n’a pas de réponse dans l’outil.
La version est celle du paquet. Corriger une phrase dans un skill fait avancer le numéro de tous les autres, et le diff que relit le mainteneur mélange des fichiers sans rapport.
L’auto-update tranche entre deux inconforts. Désactivé, chacun met à jour quand il y pense et les machines divergent. Activé, la version suivante d’un skill arrive en tâche de fond, applique de nouvelles instructions à vos agents, et personne n’a lu le diff.
Un skill retouché localement n’existe pour personne, sauf pour la personne qui l’a retouché et qui verra son travail disparaître ou bloquer la mise à jour.
Enfin, un plugin s’installe dans Claude Code. Les collègues qui travaillent sur claude.ai restent en dehors du dispositif.
Quand les plugins suffisent
Un outil interne cohérent, maintenu par une personne, consommé par des développeurs qui vivent dans Claude Code : le plugin est la réponse la plus simple, et elle ne coûte rien.
Le besoin change dès que les skills évoluent chacun à leur rythme, ou que la conformité demande de prouver qui utilise quelle version.
Les deux ensemble
Rien n’oblige à choisir. Le plugin continue de livrer les commandes, les hooks et les serveurs MCP de l’équipe. Hubskillz gouverne les skills : une version validée par skill, un état par machine, une commande pour aligner tout le monde.
Le CLI adopte les skills déjà présents sur une machine avec hubskillz sync --adopt, ce qui évite de tout réinstaller pendant la bascule.
Questions fréquentes
Hubskillz remplace-t-il les commandes et les hooks ?
Non. Le catalogue versionne les skills, c’est-à-dire les dossiers SKILL.md et leurs fichiers annexes. Les commandes, les hooks et les serveurs MCP restent distribués comme aujourd’hui, par un plugin ou par le dépôt du projet.
Peut-on garder un marketplace privé en parallèle ?
Oui. Les deux écrivent dans des endroits différents et le CLI signale simplement un skill qu’il ne connaît pas comme non géré, sans y toucher.
Un .claude/settings.json partagé ne suffit-il pas pour l’équipe ?
Il aligne la configuration, ce qui est déjà beaucoup : mêmes marketplaces, mêmes plugins activés pour qui ouvre le dépôt. Il ne dit pas ce que chaque machine a réellement chargé, ne détecte pas une copie retouchée en local, ne pose aucune étape de relecture avant qu’une nouvelle version d’un skill s’applique, et ne concerne que les personnes qui ouvrent ce dépôt dans Claude Code.
Pour aller plus loin
Autres comparatifs
- Un dépôt Git de skills, ou HubskillzVersionner les skills dans un dépôt, les copier à la main sur chaque machine.
- Alternative à skills.sh, ou complémentInstaller des skills publics depuis un registre, une machine à la fois.
- skills.sh ou les plugins Claude CodeLes deux façons de distribuer des skills sans rien recopier, comparées l’une à l’autre.
- Les alternatives à Hubskillz