N-Gage Formation Claude

Skills, MCP & Routines

MCP - Model Context Protocol (concept et écosystème)

Statut : stable Plan minimum : Pro Démo : 8-12 min Vérifié le : 2026-05-17

Source officielle : https://www.anthropic.com/news/model-context-protocol

MCP - Model Context Protocol

TL;DR

MCP est un protocole ouvert publié par Anthropic en novembre 2024 pour standardiser la connexion entre Claude et des outils ou des sources de données externes. La métaphore qui marche le mieux : c'est l'USB-C de l'IA. Une seule prise pour brancher Claude sur des outils internes, des bases de données, des SaaS métier, sans recoder une intégration sur mesure à chaque fois. Côté utilisateur, ce que l'on voit dans claude.ai sous Customize > Connectors, ce sont des serveurs MCP déjà prêts à brancher en quelques clics.

Pour qui c'est utile

Comprendre MCP est utile dès que la question « est-ce que Claude peut parler à mes outils ? » se pose. Cette fiche est conceptuelle, pas un tuto de déploiement. Elle s'adresse à toute personne qui veut savoir comment Claude s'imbrique dans une stack existante.

Profils types :

  • Dirigeants et DSI qui évaluent jusqu'où Claude peut s'intégrer dans le SI sans projet IT lourd, et quelle gouvernance prévoir.
  • Chefs de projet IA qui veulent arbitrer entre une intégration MCP, un Connector du catalogue ou un Skill métier avant d'engager un budget.
  • Consultants et formateurs qui doivent expliquer en 5 minutes à un comité de direction pourquoi MCP change la donne par rapport aux intégrations API classiques.
  • Profils techniques (développeurs internes, intégrateurs) qui auront ensuite à brancher ou à exposer un serveur MCP côté éditeur ou côté SI.

Comprendre MCP (la mécanique sous le capot)

MCP est un protocole client/serveur, au même titre que HTTP pour le web ou IMAP pour la messagerie. Le principe est simple : un côté pose des questions et exécute des actions (le client), l'autre côté répond et expose des capacités (le serveur).

Schéma de base :

Claude (client MCP)  <-->  Serveur MCP  <-->  Outil externe ou source de données

Concrètement, Claude n'appelle jamais directement l'API d'un outil métier. Il parle au serveur MCP qui, lui, sait comment traduire la demande de Claude en appels API vers l'outil cible, récupérer la réponse, et la remettre dans un format standard que Claude sait lire.

Un serveur MCP peut exposer trois types de capacités :

  • Tools : des actions que Claude peut exécuter (créer un ticket, envoyer un message, lancer une requête SQL, déclencher un workflow).
  • Resources : des contenus que Claude peut lire (un document, une page d'un wiki interne, une ligne d'une base de données, un fichier sur un Drive).
  • Prompts : des modèles de prompts pré-écrits que le serveur propose à Claude, utiles pour guider Claude vers la bonne façon d'utiliser l'outil.

Côté déploiement, deux modes coexistent :

  • MCP local : le serveur tourne sur la machine de l'utilisateur (Claude Desktop, Claude Code). C'est le cas des Desktop Extensions et des serveurs ajoutés via la CLI. Utile pour accéder à des fichiers locaux, à un terminal, à des outils installés sur le poste.
  • MCP remote : le serveur tourne dans le cloud, hébergé par l'éditeur de l'outil. C'est le cas des Connectors visibles dans claude.ai (Customize > Connectors). L'authentification se fait par OAuth, jamais par mot de passe.

Point important sur l'ouverture du standard : MCP a été publié par Anthropic en open source en novembre 2024, avec une spécification publique et des SDK officiels. Ce n'est pas un format propriétaire. D'autres éditeurs d'IA peuvent l'implémenter, et de fait l'écosystème de serveurs disponibles dépasse largement Anthropic. C'est cette ouverture qui explique pourquoi MCP est devenu en quelques mois la norme de fait pour brancher un LLM sur le reste du SI.

Quand MCP est pertinent vs quand un Connector ou un Skill suffit

MCP est puissant, mais ce n'est pas la première brique à tirer pour chaque besoin. La règle de tri tient en trois questions.

Un Connector officiel suffit si l'outil cible figure déjà dans le catalogue de Customize > Connectors (Google Drive, GitHub, Notion, Linear, Slack, Jira et autres). Pas de projet technique, juste un flow OAuth de 30 secondes.

Un Skill suffit si le besoin est de standardiser une production récurrente (un type de document, un format de réponse, un process métier) sans appel à une donnée externe en temps réel. Le Skill embarque le savoir-faire ; il n'a pas besoin de tirer une ligne dans une base SQL.

MCP devient pertinent dans trois cas précis :

  • Vous voulez brancher Claude sur un outil interne ou un SaaS non listé dans le catalogue des Connectors.
  • Vous voulez exposer une base de données ou une API interne à Claude, avec un contrôle fin de ce que Claude peut lire ou modifier.
  • Vous voulez fédérer plusieurs outils (CRM, ERP, intranet, base documentaire) sous une seule passerelle MCP, plutôt que de gérer N intégrations séparées.

Dit autrement : Connector pour le grand public, Skill pour le savoir-faire, MCP pour l'accès au SI.

Pas à pas détaillé

L'objectif de ce pas à pas est de voir concrètement où vivent les Connectors MCP dans claude.ai et de comprendre ce qui se passe en arrière-plan.

  1. Connectez-vous sur claude.ai. En bas à gauche, cliquez sur le cercle de vos initiales, puis sur Settings.
  2. Dans la sidebar de Settings, cliquez sur Customize puis sur Connectors. Vous arrivez sur la liste des connecteurs officiels.
  3. Parcourez la liste sans cliquer : Google Drive, Gmail, Google Calendar, GitHub, Notion, Linear, Slack, Jira, Asana, Zapier, Pappers, Canva, PubMed, etc. Chaque ligne correspond à un serveur MCP hébergé par l'éditeur de l'outil ou par Anthropic.
  4. Choisissez un connecteur lié à un outil que vous utilisez vraiment (par exemple Google Drive si vous travaillez dans la suite Google). Cliquez sur Connect.
  5. Un flow OAuth s'ouvre dans un nouvel onglet : vous vous authentifiez sur l'outil cible, vous validez les permissions demandées, vous revenez sur claude.ai. À aucun moment vous ne donnez votre mot de passe à Claude.
  6. Vérifiez le statut : le connecteur passe de Connect à Connected avec la date du dernier rafraîchissement.
  7. Revenez dans un chat libre et posez une question qui force Claude à utiliser le connecteur, par exemple : « cherche dans mon Drive le dernier compte rendu de comité que j'ai partagé. » Claude appelle le serveur MCP, le serveur interroge l'API de l'outil, la réponse remonte au chat.
  8. Pour comprendre ce qui se passe en arrière-plan : Claude n'a jamais ouvert votre Drive directement, il a parlé au serveur MCP de Google Drive, qui a parlé à l'API Drive avec le token OAuth délivré à l'étape 5. Si vous révoquez le connecteur, le token est invalidé, et Claude perd l'accès immédiatement.

Cas d'usage avec exemples concrets

Intégration d'un outil métier interne Une société dispose d'un outil de suivi de production développé en interne, accessible via une API REST. Plutôt que de coller des extraits dans Claude à la main, un serveur MCP est exposé sur l'API. Claude peut alors lire l'état d'une commande, le planning de production ou les alertes en cours, et restituer un point d'avancement dans le ton attendu par la direction.

Accès à une base de données interne Une équipe data publie un serveur MCP en lecture seule sur l'entrepôt de données. Les analystes interrogent Claude en langage naturel : « donne-moi le chiffre d'affaires des 5 derniers mois par zone géographique. » Claude traduit la question en SQL, le serveur MCP exécute la requête, le résultat revient en tableau. La sécurité est portée par le serveur (lecture seule, périmètre limité aux tables autorisées), pas par Claude.

Branchement sur un SI propriétaire Une PME utilise un ERP métier ancien avec une API SOAP peu engageante. Un serveur MCP fait la traduction : il expose à Claude des actions claires (« lister les clients en retard de paiement », « créer une facture brouillon »), et masque la complexité technique. Les utilisateurs métier travaillent en langage naturel, le serveur fait le sale boulot d'adaptation.

Fédération de plusieurs outils internes Une direction commerciale combine CRM, base de connaissances et outil de devis. Trois intégrations séparées seraient un cauchemar de maintenance. Un seul serveur MCP fédérateur expose à Claude les trois sources comme des Tools et Resources logiques. Pour l'utilisateur, c'est transparent : il pose une question, Claude pioche dans la bonne source via le bon Tool. Pour la DSI, il n'y a qu'un point de contrôle, un journal d'accès, une politique de sécurité.

À retenir

  • MCP est un protocole ouvert publié par Anthropic en novembre 2024, pas un produit propriétaire ni un outil à installer.
  • La métaphore qui parle à tous : MCP = USB-C de l'IA. Une seule prise standard pour brancher Claude sur tout type d'outil.
  • Trois capacités exposées par un serveur MCP : Tools (actions), Resources (contenus lus), Prompts (modèles d'usage).
  • Deux modes : local (Claude Desktop, Claude Code, Extensions) et remote (Connectors claude.ai, OAuth, cloud éditeur).
  • Côté utilisateur final, MCP est invisible. Ce que l'on voit, ce sont les Connectors : un catalogue, un bouton Connect, un flow OAuth.
  • Connector = grand public et catalogue officiel. Skill = savoir-faire embarqué. MCP = accès au SI et aux outils non listés.

Pièges à éviter

  • Sécurité et serveurs non fiables : un serveur MCP que vous installez vous-même a accès à ce que vous lui ouvrez. Ne branchez que des serveurs publiés par des éditeurs identifiés ou écrits par votre propre équipe. Un serveur tiers mal audité peut introduire du prompt injection (instructions malveillantes glissées dans des données que Claude va lire).
  • OAuth qui expire : les tokens OAuth ont une durée de vie limitée. Si un Connector cesse de répondre, c'est presque toujours le token qui doit être rafraîchi. Cliquez sur Reconnect dans Customize > Connectors plutôt que de chercher un bug.
  • Confondre MCP et Connector : un Connector est l'interface visible côté claude.ai. Le serveur MCP est la mécanique côté éditeur. Vous activez un Connector, vous ne « configurez » pas le serveur MCP qui tourne derrière.
  • Croire que MCP installe quelque chose sur claude.ai : en mode remote (claude.ai), rien n'est installé chez vous. Le serveur tourne dans le cloud de l'éditeur, claude.ai parle juste à son URL.
  • Ouvrir trop large les scopes OAuth : à chaque connexion, vérifiez les permissions demandées. Un connecteur de lecture de calendrier n'a pas besoin du droit d'envoyer des e-mails.
  • Penser MCP avant d'avoir cadré le besoin : MCP est une réponse technique. Si le besoin réel est un Skill ou un Connector existant, lever la complexité MCP est inutile.

Exercice 1 minute

Ouvrez Settings > Customize > Connectors. Parcourez la liste et notez mentalement deux connecteurs qui correspondent à vos outils du quotidien. Activez le plus utile, validez le flow OAuth, et posez à Claude une question qui force l'usage du connecteur. Vérifiez que la réponse cite bien un contenu issu de l'outil cible, et pas une réponse générique. Si oui, vous avez utilisé MCP sans écrire une ligne de code.

Variantes par plan

  • Free : accès limité aux Connectors officiels, généralement avec un quota de connecteurs personnels actifs.
  • Pro : self-service complet sur le catalogue des Connectors, OAuth personnel, possibilité d'ajouter des serveurs MCP custom via Claude Desktop et Claude Code.
  • Max : équivalent Pro, marges d'usage plus généreuses.
  • Team : les Owners poussent une liste de connecteurs validés au workspace, gouvernance centralisée, contrôle des connecteurs disponibles pour les membres.
  • Enterprise : SSO obligatoire, contrôle fin des scopes OAuth, audit complet des accès, possibilité de bloquer les connecteurs non validés par la DSI.

Liens internes