Pourquoi les serveurs de compétences compilés surpassent la distribution par fichiers plats pour les déploiements IA en entreprise
Cet article décrit un modèle architectural que nous avons développé et utilisons en interne. C’est un point de départ pour la discussion — pas une spécification de produit. L’approche est nouvelle et les compromis décrits sont propres à notre contexte de déploiement.
Résumé
Les flux de travail IA d'entreprise reposent sur deux types de connaissances : les outils (ce que le modèle peut faire) et les compétences (comment le modèle doit se comporter dans un domaine spécifique). Les outils sont bien servis par les serveurs MCP. Les compétences ont généralement été distribuées sous forme de fichiers Markdown sur le système de fichiers local de chaque utilisateur — une approche qui charge l'intégralité du contenu dans la fenêtre de contexte au début de chaque conversation, qu'il soit nécessaire ou non.
Ce document décrit un modèle architectural que nous avons développé pour résoudre ce problème : intégrer les compétences procédurales directement dans un serveur MCP, en les servant à la demande selon un modèle de chargement à plusieurs niveaux. Le résultat élimine la distribution manuelle de fichiers, synchronise les mises à jour de compétences avec les versions d'outils, réduit la consommation de contexte pour les conversations qui n'invoquent pas la compétence, et fournit un degré pratique de protection de la propriété intellectuelle. Ces avantages s'accompagnent de compromis réels que ce document reconnaît directement.
1. Le problème : distribution par fichiers plats
Le modèle dominant pour distribuer des instructions de flux de travail aux assistants IA est simple : créez un fichier Markdown décrivant la procédure et placez-le à l'endroit où votre assistant IA le lira au démarrage. Dans Claude.ai, cela signifie généralement /mnt/skills/user/. Dans Claude Code, cela signifie CLAUDE.md. Le fichier est chargé dans le contexte au début de chaque conversation.
Pour un flux de travail simple d'une page, c'est acceptable. Pour une procédure d'entreprise complexe couvrant l'analyse de contrats, le mappage fiscal, les règles de division par destination, sept codes d'articles structurés, et les cas limites des modifications — un tel fichier peut facilement dépasser 2 500 tokens. Ces tokens sont consommés dans chaque conversation, y compris celles qui concernent des tâches sans rapport. La compaction de contexte se produit plus tôt. Les conversations longues perdent des informations cruciales.
Il y a un second problème : la distribution. Si votre flux de travail encode des connaissances institutionnelles — les nuances spécifiques que votre équipe a affinées sur des années d'opération dans un domaine — distribuer ces connaissances à chaque employé en tant que fichier Markdown lisible sur un système de fichiers local n'est ni efficace ni sécurisé.
2. L'approche : compétences comme outils MCP
Le Model Context Protocol expose trois primitifs : les Outils (fonctions appelables par le modèle), les Ressources (données lisibles par le modèle) et les Invites (modèles de prompt réutilisables). Notre approche utilise le primitif Outils pour implémenter un serveur de compétences avec trois opérations :
Renvoie un inventaire des noms et descriptions des compétences disponibles. Charge minimaliste — quelques dizaines de tokens. Appelé en premier pour découvrir ce qui est disponible.
Renvoie un résumé compact (~500 tokens) contenant les règles essentielles, les étapes du flux de travail et les paramètres clés. Conçu pour couvrir la majorité des cas d'utilisation sans charger la référence complète.
Renvoie la référence détaillée complète, optionnellement filtrée par section nommée. Appelé uniquement lorsque le résumé compact est insuffisant pour la tâche en cours.
Le contenu des compétences est stocké sous forme de constantes de chaînes TypeScript dans le dépôt du serveur MCP — organisées en un résumé compact et en sections de détail nommées. Le serveur compile en JavaScript et se distribue comme n'importe quel autre paquet npm.
Chargez le minimum d'abord, chargez plus seulement si nécessaire. La plupart des conversations qui utilisent un flux de travail complexe n'ont besoin que du résumé compact. Le détail complet — des exemples de code, des tableaux de référence exhaustifs, des règles de cas limites — n'est récupéré que lorsqu'une ambiguïté spécifique l'exige.
3. Analyse des avantages
Efficacité du contexte
Dans Claude.ai, les fichiers de compétences dans /mnt/skills/user/ sont injectés dans l'invite système au début de chaque conversation. Un fichier de 2 500 tokens consomme cette capacité dans chaque session, quelle que soit la tâche. Avec le serveur MCP, rien n'est chargé au départ — le modèle appelle get_skill uniquement lorsqu'une tâche de domaine est invoquée, chargeant ~500 tokens au lieu de 2 500.
Zéro frais de distribution
Chaque employé qui installe le paquet npm du serveur MCP reçoit automatiquement les compétences — aucune copie de fichier séparée, aucun répertoire à gérer, aucun processus d'intégration incluant des instructions d'installation de fichiers Markdown. La compétence et les outils qu'elle référence voyagent ensemble dans le même paquet.
Synchronisation des versions
Le contenu des compétences et l'implémentation des outils partagent un numéro de version. Lorsqu'un nouvel outil Xero est ajouté et que la compétence de flux de travail est mise à jour pour le référencer, ils sont publiés ensemble. Les employés exécutant npm update reçoivent les deux modifications de manière atomique. Il n'y a pas d'état possible où une compétence référence un outil qui n'existe pas encore dans la version installée.
Protection de la propriété intellectuelle
Un fichier Markdown sur le système de fichiers d'un employé peut être lu dans n'importe quel éditeur de texte. Le JavaScript compilé distribué via npm est sensiblement moins lisible. Les connaissances institutionnelles encodées dans la logique des compétences — les nuances spécifiques au domaine que votre équipe a développées — sont obscurcies pour les utilisateurs finaux tout en restant pleinement lisibles par l'IA qui les sert.
4. Compromis et faiblesses
Cette approche comporte des inconvénients réels que tout praticien devrait évaluer avant de l'adopter.
| Dimension | Fichier plat (Markdown) | Serveur de compétences MCP |
|---|---|---|
| Mise à jour du contenu | Modifier le fichier directement, aucune compilation | Modifier le .ts, compiler, publier |
| Lisible par l'employé | Entièrement lisible dans n'importe quel éditeur | JS compilé — obscurci mais non chiffré |
| Efficacité dans Claude Code | Chargé via CLAUDE.md ou référence @ | Appel d'outil charge le même contenu — même empreinte |
| Efficacité dans Claude.ai | Injecté dans le prompt système au démarrage | Chargé uniquement à la demande, chargement par niveaux |
| Courbe d'apprentissage | Markdown — tout le monde peut l'écrire | TypeScript, MCP SDK, outillage npm requis |
| Distribution | Copie manuelle par employé | Automatique via npm install |
| Synchronisation des versions | Aucune — outils et compétences découplés | Atomique — même version de paquet |
Dans les sessions Claude Code, appeler get_skill via l'outil MCP charge le contenu dans la fenêtre de contexte exactement comme lire un fichier local le ferait. L'avantage d'efficacité s'applique principalement aux conversations Claude.ai de bureau, où les compétences ont été précédemment pré-chargées dans l'invite système depuis le système de fichiers local. Si votre flux de travail est principalement piloté par Claude Code, l'avantage en tokens est limité.
5. L'alternative : le primitif Invites MCP
Le Model Context Protocol définit trois primitifs de première classe. Nous avons implémenté notre serveur de compétences en utilisant le primitif Outils, mais le primitif Invites est en fait plus idiomatique pour ce cas d'utilisation. Les invites MCP permettent aux serveurs d'exposer des modèles de prompts nommés et réutilisables qui s'intègrent nativement dans les interfaces de l'assistant IA.
Dans Claude.ai, les invites MCP apparaissent sous forme de commandes slash — /dnd-xero-workflow — invocables directement depuis l'interface de discussion sans que le modèle ait besoin d'appeler un outil de découverte. L'approche Invites est plus propre du point de vue du protocole, mais elle offre moins de contrôle sur le chargement par niveaux. Le primitif Outils que nous utilisons permet le modèle résumé/détail-par-section que le chargement basé sur les Invites rend plus difficile à implémenter.
Chargement par niveaux flexible
Contrôle total sur la granularité : résumé compact d'abord, sections spécifiques à la demande. Nécessite des appels d'outils explicites pour découverte et chargement. Fonctionne dans n'importe quel client compatible MCP.
Intégration native de l'interface
Les compétences apparaissent comme des commandes slash dans Claude.ai. Découverte et invocation sans outil de découverte séparé. Moins de flexibilité dans la granularité de chargement — la compétence charge généralement en entier.
6. Implications pratiques
Ce modèle est le plus précieux dans les cas qui réunissent plusieurs conditions. Si votre organisation répond à la plupart de ces critères, l'investissement de mise en œuvre vaut probablement le coût :
- Flux de travail complexes et volumineux. Les compétences d'une page dans CLAUDE.md sont de la sur-ingénierie. Les procédures de plusieurs milliers de tokens qui s'appliquent à certaines sessions mais pas à toutes sont le cas d'utilisation cible.
- Équipe distribuée. Un employé. Un système de fichiers. Un fichier Markdown. C'est gérable. Dix employés avec des mises à jour de compétences non synchronisées est le problème que ce modèle résout.
- Connaissances institutionnelles propriétaires. Si la logique de flux de travail représente de la propriété intellectuelle que vous ne souhaitez pas exposer en texte clair sur les machines des employés, le compilé est préférable au Markdown.
- Couplage outil-compétence fort. Lorsque les compétences référencent des outils spécifiques par nom — et que ces outils changent avec les versions — la livraison atomique empêche la dérive de version.
- Utilisation principalement de Claude.ai (pas Claude Code). L'avantage d'efficacité du contexte ne s'applique qu'aux environnements où les compétences étaient précédemment pré-chargées depuis le système de fichiers.
Conclusion
La distribution par fichiers plats fonctionne jusqu'à ce qu'elle ne fonctionne plus. Pour les déploiements à utilisateur unique avec des compétences simples, un fichier Markdown reste l'approche correcte — moins de complexité, édition directe, aucun cycle de compilation. Pour les déploiements en équipe avec des flux de travail complexes et propriétaires et des environnements Claude.ai de bureau, l'approche du serveur de compétences MCP résout plusieurs problèmes simultanément.
Ce n'est pas un modèle largement adopté. Nous n'avons pas trouvé d'art antérieur direct dans la littérature publique sur les serveurs MCP — la plupart des serveurs de compétences existants servent des faits (compétences de mémoire) ou de la documentation de référence (compétences de ressources), pas des connaissances procédurales de flux de travail. Le modèle de chargement par niveaux en particulier — résumé compact d'abord, section à la demande ensuite — est notre propre contribution à ce problème.
Comme pour tout choix architectural, la bonne décision dépend du contexte. Ce document a été écrit pour aider les praticiens à évaluer ce contexte de manière honnête.
Une compétence dans un fichier plat est une connaissance que vous distribuez. Une compétence dans un serveur MCP est une connaissance que vous déployez. La différence — contrôle de version, livraison atomique, protection IP, chargement à la demande — ne compte que lorsque la distribution devient un problème. Construisez en conséquence.