Plugin Claude Code : MCP et Skills partagés en équipe

Les Skills de Claude sont la chose la plus simple du monde à écrire. Un fichier texte, quatre lignes d'instructions, et Claude sait faire quelque chose qu'il ne savait pas faire avant.

Et le plus beau ? Vous ne l'écrivez même pas vous-même. Il existe une Skill dont le seul métier est d'écrire des Skills : vous dites ce qu'il vous faut, elle pose deux questions, et c'est prêt à l'emploi. Claude qui rédige ses propres instructions.

Il y en a des milliers à télécharger. Sélectionnées, gratuites, prêtes.

Puis vous en écrivez une. Une vraie, taillée sur votre métier et vos clients. Et l'envie la plus naturelle du monde arrive : la partager avec votre équipe.

C'est là que les ennuis commencent.

Ce qu'il faut pour démarrer

Avant de raconter comment, réglons la question qui bloque tout le reste : combien ça coûte de se mettre en état de le faire.

• Un compte Cloudflare. Gratuit. C'est là que tourne le serveur et que vivent les identifiants.
• Un compte GitHub. Gratuit. C'est le canal de distribution — et c'est aussi le canal de connexion, donc c'est lui qui permet d'identifier l'utilisateur.
• Un abonnement Claude (ou à un autre assistant de code) pour écrire le serveur. Celui-là, vous l'avez sans doute déjà si vous êtes arrivé jusqu'ici.

Aucune infrastructure à acheter. Aucun plan enterprise à activer. Aucun fournisseur à appeler.

Pour une équipe de trois personnes, la facture est de zéro euro par mois. Le vrai coût, c'est un après-midi de boulot.

Comment on s'est fourrés dans ce cauchemar

Je raconte comment c'est né, vous comprendrez le problème tout de suite.

Vous montez votre boîte. Vous avez la pêche. Vous bossez pour un client, puis pour un autre, puis vous passez deux jours à remettre le site en état. Vos associés font à peu près pareil.

En fin de journée vous ouvrez Kimai — l'outil avec lequel on affecte les heures aux projets — vous créez une feuille de temps et vous écrivez que vous avez passé deux heures sur Machin et quatre sur Bidule.

Vous le faites une fois. Vous le faites deux… à la troisième vous vous sentez un homme des cavernes.

Vous travaillez avec l'IA des heures par jour, et le soir vous faites de la saisie manuelle comme en 2010 ?

Inacceptable !

Alors vous ouvrez la doc de l'API Kimai et en une demi-heure vous vous fabriquez votre outil : à partir de maintenant vous dictez les heures à l'agent et c'est lui qui les saisit.

Quelle satisfaction.

Puis vous le donnez à vos associés. Et là vous faites la première bêtise sans même la voir : vous écrivez trois fois exactement le même code, un par personne, parce que chaque copie doit contenir le bon identifiant utilisateur — sinon les heures d'Otoni finissent à mon nom.

Un mois passe. Vous ajoutez Matomo pour surveiller les visites du site. Vous vous faites l'outil de statistiques, vous le branchez à Claude, ça marche à merveille !

Puis vous essayez de programmer une tâche qui vous les envoie tous les lundis matin.

Et ça ne marche plus.

Pourquoi ? Parce que les tâches planifiées tournent dans le bac à sable de Cowork. Et le bac à sable ne voit pas cet outil. Et tant qu'on y est, Claude Code non plus. Même machine, même personne, trois boîtes séparées qui ne se parlent pas.

Pendant ce temps, le token Matomo, il est où ? En clair, dans un fichier sur votre portable.

Alors vous faites quoi ? Vous écrivez une Skill avec le token dedans et vous la passez aux associés. Super, maintenant tout le monde peut demander à Claude comment vont les visites.

Sauf que ce token est désormais en clair sur trois ordinateurs différents.

Côté cybersécurité : magnifique !

Et votre tête malade de développeur ne s'arrête pas pour autant. L'outil pour le SEO. Celui qui génère les PDF d'Arkad. Celui qui scanne les sites clients. L'un après l'autre.

Quelques semaines plus tard vous regardez derrière vous et vous trouvez ça : un fatras de Skills, avec des tokens en clair dedans, qui marchent dans un environnement et pas dans l'autre, en versions différentes entre vous et vos associés.

Vous me suivez ? Voilà, c'est là que j'ai compris qu'il fallait s'arrêter et réfléchir à une solution.

Sur la table, cinq obstacles :

1. Distribution — comment mes Skills arrivent jusqu'à mes associés.
2. Mise à jour — comment ils savent s'ils ont la dernière révision.
3. Secrets — où je mets un token sans l'éparpiller partout.
4. Portabilité — comment je le fais fonctionner dans trois environnements qui ne se parlent pas.
5. Identité — comment le serveur sait lequel des trois est en train de l'utiliser.

Prenons-les un par un.

Connecteur MCP et Claude Skills : ce qui les sépare

Il faut une distinction. C'est elle qui débloque tout le reste.

Un connecteur MCP (Model Context Protocol) est un service qui expose des fonctions exécutables. Il n'explique rien : il fait. Il interroge une base, appelle une API, écrit dans un CRM.

Une Skill, c'est l'inverse. Un fichier texte avec des instructions. Elle dit à Claude comment on fait une chose : quelle procédure suivre, dans quel ordre, avec quelles précautions, ce qu'il ne faut jamais faire. Elle n'exécute rien. C'est du savoir, pas des bras.

Les connecteurs agissent. Les Skills instruisent.

Ça a l'air d'une subtilité de manuel. C'est en fait la clé de tout : les deux voyagent ensemble mais doivent rester séparés — et vous verrez plus loin que c'est précisément de cette séparation que naît l'économie de contexte.

Au-dessus des deux, il y a le contenant. Un plugin est un paquet qui tient Skills et connecteurs dans une seule unité versionnée : on l'installe avec une commande et on la met à jour avec une autre.

Les Skills et les connecteurs sont les pièces. Le plugin, c'est le carton avec lequel vous les expédiez.

Le même plugin sur Claude Desktop, Claude Code et Cowork

Je commence par le problème le plus douloureux, la portabilité, parce que la solution est presque gênante tellement elle est simple.

Un connecteur MCP distant ne vit pas sur votre ordinateur. Il vit sur un serveur — dans notre cas un Worker sur Cloudflare, gratuit jusqu'à des volumes que trois personnes n'atteignent même pas par hasard.

Et comme il vit sur internet et non dans votre dossier utilisateur, tous les environnements le voient de la même façon.

Vous le branchez à Cowork et vous le retrouvez identique dans Claude Code. Vous ouvrez le bureau et il est là. Les tâches planifiées le trouvent. Et comme le protocole est ouvert, ce même serveur peut être utilisé par n'importe quel autre client qui parle MCP — ChatGPT, par exemple.

Je n'ai pas résolu le problème en configurant mieux les trois environnements. Je l'ai résolu en sortant des trois la chose à configurer.

Premier obstacle abattu. ✊

Secrets et OAuth : où finissent vraiment les tokens

Le deuxième tombe presque par conséquence. Mais il mérite un regard de près, parce que c'est celui qui convainc les clients les plus prudents.

Si le serveur est sur Cloudflare, le token Matomo vous le chargez une seule fois, comme secret du Worker. À partir de là il vit là-bas : chiffré, hors des portables, hors des messageries, hors des mails. Aucun de mes associés ne l'a jamais vu. Et il n'a pas besoin de le voir.

Quand je le fais tourner, je le change à un seul endroit. Il n'y a pas d'autres endroits d'où le retirer, parce qu'il n'a jamais été ailleurs.

Et les associés, ils entrent comment, s'ils n'ont pas le token ?

Avec OAuth. Le serveur demande à celui qui se connecte de s'identifier et lui donne en échange un accès propre, traçable, révocable individuellement. C'est le mécanisme avec lequel vous entrez dans une application en utilisant votre compte Google.

La différence, je la résumerais ainsi : le secret ne se conserve pas en trois exemplaires, il s'écrit une fois pour toutes sur le serveur.

Deuxième obstacle abattu. Tope là 🖐️ !

Hé serveur, c'est Fabrizio : le problème de l'identité

Maintenant la partie que personne ne raconte, et qui est selon moi la vraie raison d'écrire son propre MCP.

Aujourd'hui chaque fournisseur a son connecteur. Google Drive a le sien. Gmail a le sien. Notion a le sien. Il en sort un nouveau chaque semaine. Alors pourquoi en écrire un ?

Parce que le connecteur officiel résout le cas facile : son service, votre compte, un à la fois. En dehors de ça, trois cas restent à découvert, et ce sont ceux sur lesquels je suis tombé.

Le connecteur n'existe pas. Votre outil interne, le script que vous vous êtes écrit sur l'API d'un logiciel de gestion, la base de données maison : aucun fournisseur n'écrira jamais le connecteur de votre outil personnel.

Il vous faut deux comptes du même service. Aujourd'hui chaque connecteur n'en tient qu'un : vous branchez votre Gmail et la boîte contact@ de l'entreprise reste dehors.

En amont il y a une seule clé pour tout le monde. L'accès fonctionne très bien, mais le système d'en face voit un utilisateur unique pour toute l'équipe. L'accès est réglé. Qui vous êtes, non.

Prenez Kimai, le système avec lequel on suit les heures sur les projets clients. Le serveur a un token administrateur : un seul, très puissant, capable d'écrire les heures de n'importe qui. Pratique pour le serveur. Inutile pour nous.

Parce que si j'enregistre trois heures sur un projet, ces trois heures doivent apparaître à mon nom. Pas au nom de l'associé qui a configuré le token en premier. Pas au nom d'un utilisateur générique « Arkad ».

Ça s'appelle la traçabilité. Sans elle, le registre des heures est du papier mâché : vous ne savez pas qui a fait quoi, vous ne facturez pas avec précision, vous ne comprenez pas où part le temps de l'équipe.

Comment on résout ça d'habitude ? Mal. Trois clés API différentes, une par associé, chacune à garder, chacune à faire tourner, chacune à reconfigurer dans trois environnements. Retour à la case départ, multiplié par trois.

La voie propre qu'on a choisie : chacun s'authentifie avec son propre compte GitHub, à l'intérieur d'une organisation GitHub à laquelle nous seuls avons accès.

Deux choses en découlent :

1. Le mur. Seuls les membres de l'organisation peuvent utiliser le connecteur. Qui n'est pas dedans n'entre pas — et le jour où quelqu'un quitte l'équipe, vous le sortez de l'organisation et il a perdu l'accès à tout. Un seul geste, pas une chasse aux clés éparpillées.
2. Le nom. Le serveur sait qui vous êtes à chaque appel. Donc quand j'enregistre mes heures je n'ai pas à lui dire que je suis Fabrizio : il le sait déjà, et il met mon nom au bon endroit tout seul.

Aucun de nous trois n'a de clé API Kimai. On n'en a pas besoin. On s'authentifie une fois avec GitHub et le serveur fait le reste, en sachant exactement qui a demandé quoi.

Et puisque le serveur, c'est vous qui l'écrivez, vous empochez un second avantage. Le connecteur officiel d'un fournisseur vous fait entrer quarante outils et des permissions larges : vous les chargez tous, toujours, même quand vous en utilisez deux. Le vôtre en expose six, en lecture seule, avec les règles écrites côté serveur. Moins de contexte occupé — j'y reviens plus loin — et une surface bien plus petite à défendre. Pour un client prudent, ce n'est pas un détail technique : c'est un argument de vente.

Troisième obstacle abattu.

Voilà, en gros, à quoi ressemble notre système d'authentification MCP.

Comment on installe le plugin depuis un marketplace GitHub

Restent la distribution et la mise à jour, qui sont le même problème vu à deux moments différents.

La réponse est un dépôt GitHub configuré en marketplace : un registre qui liste les plugins disponibles. Dedans il y a tout : le catalogue, un plugin par famille d'outils, et — depuis qu'on a fusionné les deux dépôts — le code du Worker aussi. La Skill et l'outil changent dans le même commit.

arkad-marketplace/
├── .claude-plugin/
│   └── marketplace.json      # le catalogue : nom, propriétaire, liste des plugins
├── plugins/
│   ├── arkad-documents/      # plugin de Skills seules : pas de MCP, pas de secrets
│   │   └── skills/arkad-documents/
│   │       ├── SKILL.md
│   │       └── assets/       # gabarits et logos voyagent dans la Skill
│   └── arkad-tools/          # plugin avec connecteur : un MCP, dix Skills
│       ├── .claude-plugin/
│       │   └── plugin.json   # nom et version — la version est l'interrupteur de publication
│       ├── .mcp.json         # quatre lignes : type http et URL. Aucun token.
│       └── skills/           # arkad-connect, arkad-seo, arkad-kimai…
├── arkad-tools.plugin        # le zip du plugin : c'est comme ça que Cowork l'installe
└── gateway/                  # le Worker Cloudflare, dans le même dépôt
    ├── src/index.js          # l'OAuth qui enveloppe le gestionnaire MCP
    ├── src/github-auth.js    # connexion GitHub et liste blanche de l'organisation
    ├── src/mcp.js            # JSON-RPC : initialize, tools/list, tools/call
    ├── src/tools/            # un fichier par famille : matomo, seo, kimai…
    └── wrangler.toml         # le binding KV et la liste des secrets

Notez arkad-documents : pas de .mcp.json. Ce ne sont que des instructions et des gabarits, ça ne touche aucun système — et ça ne coûte donc rien en contexte tant que vous ne l'invoquez pas.

Un associé ajoute le marketplace une fois et installe le plugin. À partir de là, le cycle est celui-ci : je modifie une Skill, je corrige le code et je pousse sur GitHub. Il lance la mise à jour et il a la dernière version. Toutes les Skills, le connecteur, tout ensemble. Sans que je lui envoie quoi que ce soit.

Le numéro de version n'est pas une étiquette décorative : c'est ce à quoi Claude Code reconnaît qu'il y a du neuf à télécharger.

Et comme tout est sur Git, l'historique des modifications reste. On voit qui a changé quoi.

Les deux derniers obstacles tombent ensemble.

Après quelques mois d'usage réel, l'effet composé est celui-là : plus personne ne demande toi, tu l'as configuré comment ?. La question a cessé d'avoir un sens.

Et on s'est débarrassés de l'autre habitude : s'envoyer les fichiers sur WhatsApp, parce que c'est là qu'on se parle. L'un le téléchargeait, l'autre non. Trois semaines plus tard, celui qui ne l'avait pas téléchargé vous écrivait que le lien avait expiré et qu'il lui en fallait un autre — et entre-temps vous en étiez déjà à la version six.

Le plugin est unique, la version est unique, les identifiants appartiennent à chacun, les Skills sont écrites une seule fois et l'agent sait se servir des outils correctement sans que personne ne lui explique quoi que ce soit.

MCP n'est pas mort : le vrai coût en contexte

Arrive alors l'objection. Et elle arrive toujours avec un certain aplomb : MCP c'est mort, ça bouffe du contexte, maintenant on fait des Skills.

Il y a un fond de vrai. Un connecteur charge la description de ses outils dans la fenêtre de contexte au démarrage. Toujours, que vous vous en serviez ou non. Une Skill, elle, n'est chargée qu'au moment utile. Là-dessus, celui qui le dit a raison.

Mais de là à dire que c'est mort, il y a de la marge.

La consommation de contexte est une conséquence de la façon dont vous écrivez les descriptions. Et l'astuce est entièrement là.

Gardez les descriptions des outils MCP au strict minimum : ce que fait la fonction, quels paramètres elle attend, point. Tout le reste — quand s'en servir, dans quel ordre, comment lire le résultat, quelles erreurs sont normales — vous le déplacez dans une Skill du même plugin, qui n'est chargée qu'au moment où ça sert vraiment.

Fait ainsi, sur mes plugins le poids en contexte tourne autour de 1 %. Vous pouvez le mesurer vous-même avec un simple /context dans Claude Code.

1 % pour avoir un accès direct à mes systèmes depuis n'importe quel environnement, ce n'est pas un prix. C'est un arrondi.

Ce qui vaut pour nous trois, et ce qui va changer

Une dernière chose, parce que je ne veux pas vendre cette architecture pour plus qu'elle n'est.

GitHub n'est pas la réponse. C'est notre réponse.

On l'a choisi pour une raison banale : on est trois, on a tous déjà un compte GitHub et une organisation à nous sur GitHub où l'on met nos projets, donc il n'y avait rien à créer et rien à expliquer. Mais le serveur sur Cloudflare se configure exactement de la même façon avec Google, ou avec n'importe quel fournisseur d'identité que l'entreprise utilise déjà.

Le pattern n'est pas « utilisez GitHub ». Le pattern, c'est : appuyez-vous sur l'annuaire que vous avez déjà, quel qu'il soit. Le jour où entre en jeu une personne qui n'écrit pas de code, ou le jour où l'on installe cette architecture chez un client non technique, GitHub est le mauvais choix et Google Workspace est le bon. Le fournisseur change, le dessin ne change pas.

Et puis il y a une limite honnête à déclarer.

Aujourd'hui nous avons tous des permissions identiques : n'importe lequel d'entre nous peut utiliser n'importe quel outil. Le serveur n'a donc qu'une seule chose à savoir, qui vous êtes, et il la sait. Ça suffit largement.

Le jour où l'on donnera l'accès à un salarié, ça ne suffira plus. Il faudra définir des rôles sur le serveur, associer chaque rôle à un ensemble d'outils, et attribuer un rôle à celui qui se connecte selon sa position dans l'organisation. Qui a le bon rôle voit l'outil, les autres non.

Les choses vont se compliquer. Je ne le cache pas.

Mais c'est un problème qu'on aura quand on l'aura. En attendant, cette solution nous a vraiment changé la vie, et dans ce domaine tout bouge si vite que la seule promesse sensée est celle-là : quand il faudra changer, on changera.

En bref

• Les Skills sont faciles à écrire et impossibles à tenir synchronisées à la main en trois exemplaires.
• Skills et connecteurs MCP ne sont pas la même chose : les premières instruisent, les seconds agissent. Les tenir séparés, c'est ce qui fait respirer le contexte.
• Un connecteur distant est visible de la même façon depuis Claude Code, Cowork et les tâches planifiées, parce qu'il ne vit sur aucun des trois.
• Les secrets restent chiffrés sur le serveur, à un seul endroit. Chacun s'authentifie pour son propre compte.
• Avec l'authentification via organisation GitHub vous obtenez deux choses d'un coup : dehors ceux qui ne sont pas de l'équipe, et un serveur qui connaît le nom de celui qui appelle. Fini les clés API une par associé.
• Un marketplace GitHub porte chaque mise à jour à toute l'équipe avec une commande, et garde l'historique de qui a changé quoi.
• MCP n'est pas mort. Dans un plugin soigné, ça coûte environ 1 % de la fenêtre de contexte, et ça achète la seule chose que les Skills seules ne donnent pas : la capacité d'agir.
• GitHub est notre instance du pattern, pas le pattern : à sa place, Google ou n'importe quel annuaire d'entreprise existant fait l'affaire. Et tant que les permissions sont identiques pour tous, l'identité suffit ; avec un salarié, il faudra les rôles.

Il faut un après-midi. Il faut deux comptes gratuits.

Et après, on ne revient plus en arrière.

Bon après-midi, alors. À bientôt 👋