Connectors vs Skills vs MCP

TL;DR

Trois mécanismes complémentaires, pas concurrents. Les Connectors branchent Claude sur un outil tiers (Drive, Gmail, Notion, CRM). Les Skills lui apprennent à produire un livrable récurrent à votre format. Les MCP sont le protocole standard qui rend tout ça possible : un Connector officiel est techniquement un serveur MCP managé par Anthropic. Le bon réflexe : partir du besoin métier, choisir ensuite la surface la plus simple qui répond, et combiner les trois quand c'est pertinent.

Pour qui c'est utile

Quatre profils tirent immédiatement parti de cette comparaison :

• Dirigeants et cadres qui veulent rationaliser leur stack IA sans empiler des outils en double, et savoir si tel besoin justifie un développement custom ou un simple toggle.
• Consultants et formateurs qui doivent expliquer la différence à leurs clients et choisir, pour chaque cas, la surface la moins chère à mettre en place.
• Fonctions support (RH, juridique, communication, finance) qui voient passer des demandes du type « il faudrait connecter Claude à notre SIRH » et veulent savoir si une Skill ou un Connector existant suffit.
• CIO et RSSI qui doivent arbitrer une feuille de route IA, comprendre où sont les vrais coûts (build, run, sécurité) et formaliser une stack défendable devant la direction.

Comprendre les trois mécanismes (la mécanique sous le capot)

Un Connector est une intégration packagée qui branche Claude à un outil tiers en lecture et parfois en écriture. Anthropic en maintient un catalogue officiel (Google Drive, Gmail, Calendar, Slack, GitHub, Notion, Asana, Linear, etc.) que l'utilisateur active en un clic OAuth. Sur les plans Pro et au-dessus, il est aussi possible d'ajouter des Connectors « custom » qui pointent vers un serveur MCP externe. L'utilisateur ne voit qu'un toggle et un écran de connexion, toute la mécanique est invisible.

Une Skill est un dossier (avec un fichier SKILL.md et éventuellement des scripts ou des templates) qui apprend à Claude à exécuter une procédure précise et à produire un livrable régulier au bon format. Une Skill ne se déclenche pas en permanence : Claude lit son nom et sa description dans toutes les conversations, et la charge en mémoire uniquement quand la demande de l'utilisateur correspond. Anthropic publie un catalogue de Skills publiques (PPTX, DOCX, PDF, XLSX). Sur Pro et au-dessus, vous pouvez créer les vôtres via le Skill Creator.

Le MCP (Model Context Protocol) est la norme ouverte qui standardise la façon dont Claude (et d'autres assistants) parlent à des outils externes. C'est l'équivalent d'un USB-C pour les assistants IA. Un serveur MCP est un programme qui expose des « tools » (actions), des « resources » (lectures) et des « prompts » (gabarits). Les Connectors officiels sont des serveurs MCP. Les Connectors custom pointent vers des serveurs MCP que vous ou un éditeur tiers maintenez. Concrètement, le MCP est l'infrastructure, le Connector est la prise murale, la Skill est la recette de cuisine.

Ces trois mécanismes ne sont pas concurrents. Un cas réel typique combine les trois : une Skill rédige un livrable, en s'appuyant sur des fichiers récupérés via un Connector Google Drive, qui sous le capot interroge un serveur MCP officiel. L'utilisateur final ne voit que le résultat.

Arbre de décision « par quoi je commence ? »

Posez ces questions dans l'ordre :

1. Avez-vous besoin que Claude voie l'écran complet, clique dans une interface, fasse glisser un fichier ? Oui : Computer Use ou agent Claude Code, ce n'est ni un Connector ni une Skill ni un MCP au sens classique.
2. Le service à brancher est-il déjà dans le catalogue Connectors officiel d'Anthropic ? Oui : activez le Connector officiel, c'est gratuit, immédiat et maintenu.
3. Le besoin est-il « produire un livrable récurrent au même format » (CR, propale, rapport, mail type) ? Oui : créez une Skill via le Skill Creator.
4. Avez-vous besoin de lire ou modifier des données dans un outil maison (CRM interne, base SQL, ERP custom) ? Oui : il faut un serveur MCP custom, puis l'exposer en Connector custom.
5. Le besoin est-il bien identifié et stable, ou en cours d'exploration ? En exploration : restez sur un prompt bien rédigé, n'industrialisez pas tout de suite.
6. Le besoin se répète-t-il plus de trois fois par mois ? Non : un bon prompt suffit. Oui : industrialisez avec une Skill, un Connector, ou un Project.
7. Plusieurs personnes vont-elles utiliser la même mécanique ? Oui : passez sur Team ou Enterprise pour pousser la Skill ou le Connector custom au workspace.
8. Avez-vous une équipe technique pour maintenir un serveur MCP custom ? Non : restez sur Connectors officiels et Skills, n'engagez pas un build MCP que vous ne pourrez pas faire vivre.

Pas à pas détaillé

Besoin « accéder à un outil tiers grand public » (Drive, Gmail, Slack, GitHub, Notion) : Settings > Connectors > activez le Connector officiel > OAuth > testez en posant une question à Claude qui force l'usage du Connector. Mise en place : 30 secondes à 2 minutes.

Besoin « produire un livrable récurrent à mon format » (CR, devis, fiche client, post LinkedIn) : ouvrez le Skill Creator, décrivez le livrable attendu, les contraintes (ton, structure, format de sortie), donnez 1 à 3 exemples validés. Le Skill Creator génère le SKILL.md, vous le testez, vous itérez deux ou trois fois. Mise en place : 1 à 4 heures par Skill.

Besoin « lire ou modifier les données d'un outil maison » : commencez par regarder si l'outil expose une API REST documentée. Si oui, un développeur construit un serveur MCP léger qui expose 3 à 5 actions clés (la majorité du besoin), puis vous l'ajoutez en Connector custom dans Settings. Mise en place : 2 à 10 jours selon la complexité de l'API et les contraintes de sécurité.

Besoin « automatiser une tâche manuelle sans API disponible » : explorez d'abord si Claude Code avec Computer Use peut faire la tâche en pilotant l'interface. Sinon, regardez si un outil tiers (Make, n8n, Zapier) peut faire le pont vers une API plus standard, que vous brancheriez ensuite via MCP. Le build d'un MCP n'est justifié que si la tâche se répète massivement et qu'il n'existe aucun pont existant.

Dans tous les cas, le réflexe N-Gage est le même : commencer par le plus simple (prompt, puis Connector officiel, puis Skill, puis MCP custom en dernier recours).

Cas d'usage avec exemples concrets

Cas 1, brancher Claude sur Drive pour interroger les documents existants. Le besoin : pouvoir demander à Claude « résume-moi le dossier client X dans Drive ». La bonne réponse : Connector Google Drive officiel, gratuit, OAuth en 30 secondes. Ne créez pas de Skill pour ça, ne montez pas un MCP custom. Mise en place : 1 minute. Maintenance : aucune.

Cas 2, industrialiser un livrable récurrent (compte rendu de copil au format de l'entreprise). Le besoin : produire un CR de copil avec la charte graphique, les sections fixes, le ton consultant. La bonne réponse : une Skill créée via le Skill Creator, qui contient le SKILL.md (procédure), un template Word de référence, et éventuellement un script Python pour la mise en forme finale. Mise en place : 3 à 6 heures la première fois, puis quelques minutes par mois pour ajuster. La Skill se déclenche dès qu'on demande « fais le CR du copil avec [nom du client] ».

Cas 3, connecter un CRM maison (pas dans le catalogue officiel). Le besoin : interroger les leads, créer une note, mettre à jour un statut. La bonne réponse : un serveur MCP custom (200 à 400 lignes de Python ou TypeScript) qui expose 4 à 6 actions correspondant aux usages réels, déployé sur un serveur sécurisé, puis ajouté en Connector custom dans Settings. Mise en place : 3 à 7 jours pour la première version, plus la conformité (SSO, secrets, logs). Maintenance : suivre les évolutions de l'API CRM et celles du protocole MCP.

Cas 4, automatiser une tâche manuelle sans API (saisie dans une application métier sans interface programmatique). Le besoin : reporter les données d'un mail vers une application web sans API. La bonne réponse : ce n'est ni un Connector ni un MCP classique, c'est un agent Computer Use ou un workflow Make / n8n qui simule les clics. Quand l'outil métier expose finalement une API, alors un Connector ou un MCP devient pertinent. Tant qu'il n'y a pas d'API, le MCP n'apporte rien.

À retenir

• Connectors, Skills et MCP répondent à trois questions différentes : accéder à un outil tiers, produire un livrable récurrent, standardiser la prise. Ils se combinent.
• Le réflexe est toujours « le plus simple d'abord » : prompt, puis Connector officiel, puis Skill, puis Connector custom (donc MCP), enfin Computer Use si rien d'autre ne marche.
• Un Connector officiel est techniquement un serveur MCP managé par Anthropic. L'utilisateur ne le voit pas, mais c'est utile à savoir pour comprendre le coût réel d'un Connector custom (vous prenez en charge ce qu'Anthropic fait pour vous gratuitement sur les officiels).
• La Skill est le bon outil quand le besoin est « produire un livrable », pas quand le besoin est « accéder à des données ». Confondre les deux fait perdre du temps.
• Le MCP n'est pas une fonctionnalité utilisateur mais une infrastructure. Si vous parlez à un dirigeant non technique, parlez-lui de Connectors et de Skills, et gardez le mot « MCP » pour les discussions techniques.
• Avant de lancer un build MCP custom, vérifiez systématiquement si un Connector officiel ou une Skill couvrirait 80 % du besoin.
• Sur les plans Team et Enterprise, ces trois surfaces sont gouvernées par l'admin du workspace, ce qui change la façon de planifier un déploiement.
• La maintenance est souvent sous-estimée : un Connector custom et un serveur MCP demandent un propriétaire identifié dans l'organisation.

Pièges à éviter

• Confondre les trois mécanismes : parler de « notre MCP » alors qu'on parle en réalité d'un Connector custom, ou inversement. Cette confusion coûte cher en discussions techniques et en arbitrage budgétaire.
• Vouloir tout faire en MCP : monter un serveur MCP pour Drive ou Gmail alors que les Connectors officiels existent et sont gratuits. C'est de la sur-ingénierie, ça coûte du build et de la maintenance pour zéro gain.
• Ignorer les Connectors officiels : un dirigeant qui demande « comment je connecte Slack à Claude » mérite la réponse « toggle Settings, 30 secondes », pas la réponse « il faut un build de 5 jours ».
• Sur-Skill quand un prompt suffit : créer une Skill pour un livrable que vous ferez deux fois dans votre vie. La règle de la troisième répétition reste valable : industrialisez à partir du moment où la tâche revient au moins trois fois.
• Confondre Skill et Project : un Project ajoute du contexte à toutes les conversations qui y vivent. Une Skill se déclenche partout dès que la situation s'y prête. Pour un livrable récurrent qui peut survenir n'importe où, c'est une Skill. Pour un sujet à isoler, c'est un Project.
• Construire un MCP custom sans propriétaire identifié : un serveur MCP qui n'a pas de mainteneur dans l'organisation est un risque opérationnel. Avant de lancer le build, identifiez la personne ou l'équipe qui le fera vivre.
• Oublier la sécurité sur les Connectors custom : un Connector custom passe par votre serveur MCP, donc vos règles de sécurité, vos secrets, vos logs. Les Connectors officiels héritent du cadre Anthropic, les customs non.

Exercice 1 minute

Listez trois besoins métier actuels et mappez-les sur la bonne surface :

1. « Je veux que Claude puisse répondre à partir de mes documents Drive » : Connector officiel Google Drive.
2. « Je veux que Claude produise toujours mes CR de copil au format de mon cabinet » : Skill créée via le Skill Creator.
3. « Je veux que Claude lise et modifie les fiches client de mon CRM maison » : serveur MCP custom plus Connector custom.

Si vous hésitez sur l'un de vos besoins, repassez par l'arbre de décision plus haut.

Variantes par plan

• Free : Connectors officiels limités, Skills publiques accessibles, pas de création de Skill ni de Connector custom, pas de MCP custom.
• Pro : Connectors officiels et custom, création de Skills illimitée, ajout de serveurs MCP custom via Connector. Stack complète disponible en self-service.
• Max : équivalent Pro avec limites d'usage plus généreuses, utile quand un serveur MCP custom est très sollicité.
• Team : tout Pro plus gouvernance partagée, Skills et Connectors poussés au workspace par l'admin, audit des usages côté admin.
• Enterprise : tout Team plus SSO, SCIM, audit logs, validation préalable des Connectors custom et des Skills, contrôles de rétention.

Liens internes

• Feature liée : skills-mcp/01-skills-publics-anthropic (SK1, catalogue des Skills publiques)
• Feature liée : skills-mcp/02-skill-creator (SK2, créer ses propres Skills)
• Feature liée : skills-mcp/03-mcp-concept (SK3, comprendre le protocole MCP)
• Feature liée : skills-mcp/04-mcp-builder (SK4, construire un serveur MCP custom)
• Feature liée : modules/web/09-connectors.md (W9, gérer les Connectors côté Web)
• Feature liée : modules/desktop/03-connectors-desktop.md (D3, Connectors côté Desktop et Cowork)