Un Claude skill est un module d’instructions réutilisable qui apprend à Claude comment raisonner et agir dans un contexte donné — pensez-y comme à une procédure enregistrée. Un serveur MCP est une infrastructure en cours d’exécution qui donne à Claude accès à des données ou des systèmes externes — pensez-y comme à un connecteur. La distinction est importante parce que les responsables opérationnels qui évaluent des outils d’IA confondent souvent les deux, et acheter la mauvaise couche gaspille le budget d’implémentation en tuyauterie alors que vous aviez besoin d’une procédure (ou inversement).
Ce que ce n’est PAS
Un Claude skill n’est pas un service logiciel. Il ne s’exécute pas indépendamment, ne stocke pas de données et ne peut pas appeler des API externes par lui-même. C’est un fichier d’instructions en Markdown (ou un dossier de fichiers) que Claude charge et applique lorsque la tâche correspond. Un skill qui aide votre équipe à examiner des NDA ne se connecte pas à votre référentiel de contrats — c’est un serveur MCP ou une autre intégration qui s’en charge. Si vous n’avez qu’un skill sans connecteur, Claude raisonne bien mais ne travaille qu’avec ce que vous collez dans la conversation.
Un serveur MCP n’est pas de l’intelligence. Il ne sait pas quoi faire avec les données qu’il expose. Si vous connectez le serveur MCP d’un CRM à Claude, celui-ci peut lire vos fiches contact et votre pipeline — mais sans un skill ou un prompt qui encode la logique de qualification de votre équipe, Claude donnera des réponses génériques sur ces données.
Ce que chacun fait
Claude skill : un dossier contenant des instructions, des fichiers de référence et, optionnellement, des scripts. Stocké dans votre installation Claude Code ou partagé via un plugin. Utilise environ 30–50 tokens de contexte au repos ; l’ensemble complet d’instructions ne se charge que lorsque Claude détermine que le skill est pertinent pour la tâche en cours. Un skill code comment Claude doit traiter une tâche — les étapes, les seuils, le format de sortie, les cas d’échec à surveiller. Exemple : un skill de redlining de contrat qui contient votre bibliothèque de clauses de repli et vos règles de négociation.
Serveur MCP : un processus en cours d’exécution (local ou hébergé) qui implémente le Model Context Protocol. Il expose trois catégories de capacité à Claude : les resources (données en lecture seule comme des fichiers, des lignes de base de données, des événements de calendrier), les tools (fonctions que Claude peut appeler — créer un enregistrement, envoyer un message, exécuter une requête) et les prompts (templates de workflow prédéfinis). Le serveur parle JSON-RPC 2.0 sur une couche de transport (stdio pour local, HTTP/SSE pour hébergé). Claude découvre les tools disponibles à partir du manifeste du serveur et les appelle quand ils correspondent à la tâche. Exemple : un serveur MCP HubSpot qui permet à Claude de lire les stages de deals et de mettre à jour les propriétés de contact directement.
Comment ils se composent dans les workflows opérationnels
Aucune couche n’est complète seule. Le pattern qui produit des workflows opérationnels durables combine les deux :
- MCP gère la frontière des données. Votre HubSpot, votre Salesforce, votre référentiel de contrats, votre ATS — chacun se trouve derrière un serveur MCP (fourni par le fournisseur ou auto-hébergé). Claude peut lire et écrire dans ces systèmes via le serveur.
- Un skill gère la couche de raisonnement. Le skill dit à Claude comment interpréter ce qu’il extrait de ces systèmes, quels seuils importent, quel format de sortie l’équipe attend et quand escalader plutôt qu’agir.
Un exemple RevOps concret : un skill de revue de deals instruit Claude d’extraire les champs MEDDICC de Salesforce (via MCP), de signaler toute lacune dans l’economic buyer ou les critères de décision, et de retourner un briefing structuré. Le skill est la logique ; le serveur MCP est le pipeline vers Salesforce. Changez le CRM et vous conservez le skill ; mettez à jour votre méthodologie de qualification et vous conservez le serveur MCP.
Un exemple legal-ops : un skill de risque contractuel contient des positions de repli et des seuils de risque pour votre MSA fournisseur standard. Un serveur MCP connecté à votre système CLM récupère le contrat actif. Ensemble, ils permettent à Claude de produire un résumé des risques par rapport à votre vrai playbook, pas à un template générique.
Quand construire quoi
| Situation | Ce dont vous avez besoin |
|---|---|
| Claude doit lire ou écrire dans un système externe | Serveur MCP (ou utilisez celui fourni par le fournisseur) |
| Claude donne de bonnes réponses quand vous collez des données, mais le travail est répétitif | Skill — encodez la procédure une fois |
| Vous voulez un raisonnement répétable dans toute l’équipe sans ré-expliquer le contexte à chaque session | Skill |
| Un fournisseur dit « nous supportons Claude » en voulant dire qu’il a construit un connecteur | Serveur MCP — évaluez-le en utilisant les questions dans Serveur MCP expliqué |
| Vous avez un long system prompt que vous collez dans chaque session | Convertissez-le en skill — économise du contexte et persiste entre les conversations |
Économie de tokens et pourquoi c’est important
Un setup de cinq serveurs MCP avec 58 tools combinés consomme environ 55 000 tokens de fenêtre de contexte avant que toute conversation commence (source : documentation Anthropic sur l’utilisation des tools ; la fonctionnalité Tool Search d’Anthropic réduit cela de ~85 % en différant la découverte des tools jusqu’à ce qu’ils soient nécessaires). Un skill charge 30–50 tokens au repos, puis ~5 000 tokens à l’activation. Si vous exécutez des workflows agentiques multi-étapes où la profondeur de contexte compte — revues de pipeline, analyse de contrats sur de nombreux documents, séquences de sourcing — le choix architectural affecte directement le débit et le coût.
La règle pratique : appuyez-vous sur les skills pour les patterns de raisonnement que vous avez déjà établis. Appuyez-vous sur les serveurs MCP pour l’accès aux données en temps réel. Quand vous avez besoin des deux, connectez-les via un plugin ou une configuration Claude Code qui enregistre à la fois le serveur et le dossier du skill.
Pièges courants
- Construire un serveur MCP quand un skill suffirait. Si la tâche ne nécessite pas de données externes en temps réel — scorer un CV collé, réviser une clause de contrat collée, générer une séquence outbound — un skill seul est plus rapide à construire et moins coûteux à faire tourner. Beaucoup d’équipes sur-ingénient la couche de données avant même d’avoir codifié une couche de raisonnement.
- Construire un skill sans accès aux données et se demander pourquoi il ne peut pas extraire des enregistrements en temps réel. Un skill ne peut pas appeler votre CRM. Si le workflow nécessite des données de pipeline actuelles, vous avez besoin d’un serveur MCP ou d’une autre intégration qui alimente les données à Claude.
- Évaluer les serveurs MCP uniquement sur leur capacité à se connecter, pas sur ce qu’ils exposent. Un fournisseur peut prétendre avoir un « support MCP » et n’exposer que trois endpoints en lecture seule. Avant de dépendre d’un serveur MCP dans un workflow, vérifiez son manifeste de tools : quels tools existent, si les écritures sont limitées en périmètre et s’il gère le renouvellement de token et le rate limiting en production.
Associé
- Serveur MCP expliqué — un primer complet sur MCP et l’évaluation des revendications MCP des fournisseurs
- Prompt pack vs Claude skill — quand une bibliothèque de prompts sauvegardés suffit vs quand construire un skill
- Claude — l’outil qui exécute les deux couches