Le modèle de marketplace de plugins a un argumentaire séduisant : installez ce dont vous avez besoin, ignorez le reste, contribuez le vôtre. Ça a fonctionné pour les navigateurs, pour VS Code, pour WordPress. Il semblait naturel d'appliquer le même modèle aux agents IA. Puis ClawHub est arrivé — 41,7 % des skills publiés contenaient des vulnérabilités, des centaines étaient carrément malveillants, et tout le modèle de confiance s'est effondré sous le poids d'une chaîne d'approvisionnement que personne ne pouvait auditer.
NanoClaw a regardé cet échec et posé une question différente : et si l'extensibilité ne nécessitait pas de marketplace du tout ? Et si ajouter une nouvelle capacité à votre assistant IA était aussi simple que de dire à Claude Code ce que vous voulez, et de le laisser modifier le code source directement ?
C'est le modèle des skills Claude Code. Et il s'avère être à la fois plus simple et plus sécurisé que n'importe quel système de plugins.
Comment les skills fonctionnent concrètement
Un skill Claude Code est une commande slash — comme /add-telegram ou /add-discord — que vous exécutez dans une session Claude Code. Quand vous invoquez un skill, Claude Code lit le code source de NanoClaw, comprend l'architecture existante et écrit la nouvelle intégration directement dans la base de code. Il n'installe pas un package depuis un registre. Il ne télécharge pas de code depuis internet. Il génère du code qui correspond à votre instance spécifique de NanoClaw, relu par vous avant son exécution.
Le skill /add-telegram, par exemple, n'installe pas un package npm Telegram pour le câbler via une interface de plugin. Il ajoute un listener de bot Telegram à la boucle de messages de NanoClaw, en utilisant la bibliothèque node-telegram-bot-api, avec le même modèle d'isolation par conteneur et de sécurité que WhatsApp utilise déjà. Le code généré suit les mêmes patterns que la base de code existante parce que Claude Code peut voir la base de code existante et reproduire son style.
C'est fondamentalement différent d'un système de plugins de trois manières. Premièrement, le code est visible. Vous pouvez lire chaque ligne ajoutée, comprendre ce qu'elle fait et la modifier si vous le souhaitez. Il n'y a pas de binaire compilé, pas de bundle minifié, pas de package opaque auquel vous faites confiance aveuglément. Deuxièmement, le code est local. Il vit dans votre dépôt, sous votre contrôle de version, soumis à votre processus de revue. Il ne communique pas avec un serveur distant, ne se met pas à jour automatiquement, ne change pas de comportement à votre insu. Troisièmement, le code est intégré. Il ne tourne pas dans un sandbox de plugin séparé avec une API limitée — il fait partie de l'application, avec un accès complet aux patterns et utilitaires que le reste de la base de code utilise. ## Pourquoi c'est plus sécurisé que les plugins
L'argument sécuritaire est simple, mais il vaut la peine d'être détaillé car c'est l'inverse de ce que la plupart des développeurs attendent.
Dans un système de plugins, la sécurité repose sur la confiance. Vous faites confiance à l'auteur du plugin, vous faites confiance au processus de revue de la marketplace, vous faites confiance au fait que le package n'a pas été compromis depuis sa revue, et vous faites confiance au fait que ses dépendances n'ont pas été compromises non plus. Chacune de ces hypothèses de confiance est un point de défaillance potentiel, et ClawHub a démontré qu'elles peuvent toutes échouer simultanément.
Dans le modèle des skills, la sécurité repose sur la visibilité. Quand Claude Code génère une intégration Telegram, vous pouvez voir exactement ce qu'elle fait avant de l'exécuter. Vous pouvez relire le code, le tester, le modifier ou le rejeter entièrement. La frontière de confiance n'est pas « est-ce que je fais confiance au package npm de ce développeur inconnu ? » — c'est « est-ce que ce code que je peux lire fait ce que je veux qu'il fasse ? »
Il n'y a pas non plus de chaîne d'approvisionnement à attaquer. Un acteur malveillant ne peut pas uploader un skill trojanisé sur une marketplace parce qu'il n'y a pas de marketplace. Il ne peut pas faire du typosquatting sur un nom de package populaire parce qu'il n'y a pas de packages. La surface d'attaque qui a permis des centaines de skills malveillants sur ClawHub n'existe tout simplement pas dans ce modèle.
Le compromis est que les skills nécessitent Claude Code pour les générer, ce qui signifie que vous avez besoin d'une clé API Anthropic et d'une session Claude Code. Vous ne pouvez pas parcourir un catalogue et cliquer sur « installer ». Mais pour un projet dont les utilisateurs sont des développeurs à l'aise avec un CLI, ce compromis est à peine perceptible — et les bénéfices en matière de sécurité sont substantiels.
Les skills qui existent aujourd'hui
NanoClaw est livré avec WhatsApp intégré. Tout le reste est ajouté via des skills. L'ensemble actuel de skills couvre les intégrations les plus demandées : /add-telegram pour le support de bot Telegram, /add-discord pour l'intégration de la gateway Discord, /add-slack pour l'API Events de Slack, et /add-signal pour la messagerie Signal.
Chaque skill génère environ 100 à 300 lignes de code, selon la complexité de l'API du canal. Le code généré inclut le listener du canal, le formatage des messages, le routage vers les conteneurs et la configuration — tout ce qui est nécessaire pour que l'intégration fonctionne de bout en bout. Il inclut aussi les déclarations de variables d'environnement et les instructions de configuration, pour que vous sachiez exactement quels tokens et identifiants vous devez fournir.
Au-delà des intégrations de canaux, les skills peuvent ajouter des outils et des capacités. Un skill /add-web-search pourrait ajouter un outil de recherche web que les agents peuvent utiliser dans les conteneurs. Un skill /add-calendar pourrait s'intégrer avec Google Calendar pour la planification. Le pattern est le même : Claude Code lit la base de code, comprend l'architecture et génère du code qui s'y intègre.
La philosophie fork-friendly
Il y a une philosophie plus profonde derrière le modèle des skills qui mérite d'être articulée. NanoClaw est conçu pour être forké. Pas dans le sens hostile de « prendre le code et concurrencer » — dans le sens collaboratif de « prendre le code et le faire vôtre ».
Quand vous exécutez /add-telegram, vous n'installez pas une dépendance qui vous lie au cycle de release de NanoClaw. Vous ajoutez du code à votre fork que vous possédez entièrement. Si l'upstream de NanoClaw change d'une manière qui ne vous plaît pas, votre intégration Telegram fonctionne toujours. Si vous voulez modifier le formatage des messages Telegram, vous éditez le code directement — pas de limitations d'API de plugin, pas d'attente que l'upstream expose un nouveau hook.
C'est l'opposé du verrouillage de plateforme que les marketplaces de plugins créent. Les plugins WordPress vous lient à WordPress. Les extensions VS Code vous lient à VS Code. Les skills ClawHub vous liaient à OpenClaw. Les skills NanoClaw génèrent du TypeScript standard qui fonctionne avec l'architecture de NanoClaw mais ne dépend d'aucun runtime de plugin ni d'aucune infrastructure de marketplace.
Le résultat est un projet qui gagne en capacités au fil du temps — non pas parce qu'une marketplace grandit, mais parce que le fork de chaque utilisateur accumule exactement les capacités dont il a besoin, générées par une IA qui comprend suffisamment bien la base de code pour l'étendre correctement. C'est de l'extensibilité par la compréhension, pas par l'abstraction.