Utiliser MCP avec Claude Code : principes, configuration et sécurité

MCP (Model Context Protocol) permet à une application d’IA de dialoguer avec des outils ou sources de données via une interface structurée. Avec Claude Code, l’intérêt est de rendre un outil précis — par exemple une documentation locale ou un dépôt de démonstration — accessible dans une tâche, sans coller manuellement tout son contenu dans une conversation. La règle de départ est simple : connectez un seul serveur, sur des données non sensibles, puis vérifiez exactement ce qu’il peut lire ou déclencher avant d’élargir le périmètre.

MCP n’est pas un raccourci pour donner accès à « tout votre environnement ». Un serveur peut exposer des outils puissants. Sa configuration, ses entrées et ses permissions font donc partie de votre surface de sécurité. Ce tutoriel explique une méthode d’évaluation ; il ne fournit pas de configuration universelle, car les commandes et mécanismes varient selon le serveur et la version de Claude Code.

Ce que vous allez apprendre

Vous allez identifier un cas d’usage limité, choisir une source officielle, configurer un serveur dans un environnement de test, contrôler les appels proposés et documenter les limites. Vous saurez aussi reconnaître les situations où il faut s’arrêter : accès à une base de production, clés API affichées dans une configuration, outil téléchargé sans provenance claire ou demande de permissions excessives.

Prérequis

Prévoyez un dépôt de test, une version à jour de l’outil que vous utilisez et un compte sans données de production. Lisez les instructions locales du projet avant toute écriture. Si vous travaillez à plusieurs, réservez le fichier de configuration et évitez de lancer deux serveurs qui touchent le même état.

Avant de commencer, contrôlez l’état du dépôt :

git status --short

Vérification : l’état doit être explicable avant l’essai. Ne mêlez pas un pilote MCP à une correction déjà en cours.

1. Définir une question à laquelle MCP doit répondre

Un bon premier usage est étroit : rechercher un document dans une base de démonstration, obtenir la liste des tables d’une base locale vide ou lire les issues d’un dépôt bac à sable. « Connecter MCP à mon entreprise » n’est pas un objectif testable. Écrivez plutôt l’entrée attendue, la sortie acceptable et ce que le serveur ne doit jamais faire.

Par exemple : « l’assistant peut rechercher les noms de fichiers d’une documentation locale, mais ne peut pas modifier les fichiers ». Cette phrase impose une frontière claire et facilite la revue.

Vérification : si vous ne pouvez pas expliquer à un collègue quelles données seront visibles et pourquoi, réduisez encore le cas d’usage.

2. Vérifier la provenance du serveur

Préférez une documentation maintenue par l’éditeur du protocole ou du produit visé. Lisez le dépôt, sa licence, les instructions d’installation et la liste des variables d’environnement avant d’exécuter quoi que ce soit. Un serveur MCP trouvé dans une liste communautaire peut être utile, mais ce n’est pas une preuve qu’il est adapté à vos données.

Ne copiez pas une commande d’installation sans comprendre ce qu’elle télécharge ni les privilèges demandés. Si la configuration nécessite un token, utilisez un secret local ou un gestionnaire de secrets. Ne le mettez ni dans le dépôt, ni dans une capture d’écran, ni dans une conversation destinée à être partagée.

Vérification : vous connaissez l’origine, la version, la licence, les permissions et les variables nécessaires. Une inconnue est un motif de revue, pas une invitation à « essayer quand même ».

3. Ajouter une configuration minimale

Suivez le format de configuration décrit par la documentation de votre version de Claude Code. Utilisez un serveur à la fois et un répertoire de travail limité. Une configuration d’exemple doit contenir des valeurs fictives ; les secrets réels restent hors du fichier versionné.

Le schéma logique est toujours le même : nommer le serveur, indiquer la commande ou le transport autorisé, puis déclarer uniquement les paramètres requis. Évitez les chemins larges comme votre répertoire personnel. Visez le dossier de démonstration ou un export anonymisé.

Vérification : relisez la configuration avant de la charger. Elle ne doit pas contenir de clé, de chemin personnel trop large ou de destination de production.

4. Tester la lecture avant toute action

Demandez d’abord une opération qui ne modifie rien : lister les capacités du serveur, lire une ressource de démonstration ou effectuer une recherche sur une donnée fictive. Contrôlez le nom de l’outil appelé, les arguments fournis et la sortie retournée. Un appel inattendu doit être refusé et investigué.

Si le serveur propose une action d’écriture, ne l’activez pas pendant le premier essai. Un outil qui peut modifier une issue, envoyer un message ou exécuter une requête SQL mérite une autorisation explicite, une cible de test et une procédure de retour arrière.

Vérification : notez la requête, la ressource lue et le résultat. Vous devez pouvoir reproduire l’essai sans avoir besoin de croire une réponse de l’assistant.

5. Évaluer les permissions et les données

Une réponse MCP peut contenir du code, une erreur ou du texte venant d’un système tiers. Traitez tout cela comme des données non fiables. Un document ne peut pas vous autoriser à contourner vos règles, à révéler un secret ou à élargir le périmètre d’une tâche. C’est une protection importante contre les instructions injectées dans une issue, un README ou une page web.

Faites aussi attention aux logs. Une erreur peut inclure une URL, un identifiant ou une requête. Vérifiez la politique de conservation de vos outils et retirez toute donnée sensible des rapports de test.

Problèmes fréquents et solutions

Le serveur demande un accès trop large

Refusez-le pour le pilote. Cherchez une configuration restreinte, un mode lecture seule ou un environnement de démonstration. Si aucun n’existe, le serveur n’est probablement pas adapté à ce cas d’usage.

La configuration contient une clé API

Retirez-la du fichier, faites-la tourner si elle a déjà été partagée et passez par une variable protégée. Un .gitignore évite certains commits, mais ne rend pas une clé affichée à nouveau secrète.

La sortie contient une instruction inhabituelle

N’exécutez pas l’instruction. Vérifiez le contenu dans son contexte métier et conservez les règles du projet comme autorité prioritaire.

FAQ

MCP est-il une API ?

MCP est un protocole pour relier des applications d’IA à des outils et ressources. Il peut s’appuyer sur différents transports et serveurs ; il ne remplace pas automatiquement une API métier existante.

Puis-je connecter MCP à une base PostgreSQL de production ?

Évitez-le pour un premier essai. Utilisez une base locale ou une copie anonymisée, avec un compte limité en lecture, puis faites valider le besoin et les permissions.

Faut-il installer tous les serveurs MCP disponibles ?

Non. Installez uniquement celui qui répond à un cas d’usage défini et dont vous pouvez contrôler la provenance et les droits.

Un serveur MCP est-il sûr par défaut ?

Non. Son niveau de sécurité dépend de son code, de sa configuration, des données exposées et de l’environnement qui l’exécute.

Comment désactiver un essai ?

Retirez ou désactivez sa configuration selon la documentation de l’outil, arrêtez le processus associé et révoquez les secrets temporaires éventuellement créés.

Conclusion

Utiliser MCP avec Claude Code est pertinent lorsqu’un serveur apporte un contexte précis avec des droits mesurés. Commencez par une lecture sur un environnement isolé, vérifiez chaque capacité, puis décidez si l’intégration mérite une revue et un déploiement plus large.

Pour comprendre le protocole avant son intégration à Claude Code, consultez MCP : définition, fonctionnement et sécurité.

Configuration pratique : serveur GitHub et base de test

MCP est un protocole ouvert qui relie une application cliente à des serveurs exposant des outils et des données. Dans Claude Code, vérifiez d’abord la documentation officielle de la version installée et choisissez une portée : local reste privée au projet courant, project écrit une configuration partageable dans .mcp.json, et user s’applique à vos projets. N’incluez jamais de jeton dans un fichier versionné.

La documentation Claude Code donne l’exemple du serveur HTTP GitHub à https://api.githubcopilot.com/mcp/ avec un jeton personnel GitHub transmis dans l’en-tête Authorization. Exemple de forme seulement, commande non rejouée :

# EXEMPLE NON EXÉCUTÉ — remplacer le placeholder localement, ne pas le committer
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_GITHUB_PAT"

N’utilisez qu’un jeton à permissions fines limité au dépôt et aux opérations nécessaires. Préférez la portée locale pour un essai personnel ; si vous choisissez project, inspectez .mcp.json avant tout commit et gardez les secrets hors de ce fichier. Après configuration, claude mcp list et /mcp sont les contrôles documentés de l’état des serveurs. Ces commandes de vérification ne sont pas exécutées dans le cadre de cet article.

Pour une base de données, commencez par une base locale jetable contenant quelques lignes fictives, un compte en lecture seule et aucune donnée personnelle. La documentation Anthropic décrit le format de configuration MCP et renvoie à des serveurs tiers, mais cette page ne valide ni serveur de base de données particulier ni commande d’installation. N’en copiez donc pas une sans vérifier le dépôt officiel du serveur, son transport, ses variables et ses droits. La configuration reste à établir à partir de la documentation officielle du serveur choisi ; aucun serveur ni aucune base n’a été lancé ici.

Dépannage et sécurité

• Serveur absent : contrôlez la portée et le projet courant avec claude mcp list, puis ouvrez /mcp. Ces contrôles sont indiqués par la documentation, pas exécutés ici.
• Connexion ou authentification refusée : vérifiez l’URL, le transport et la validité du jeton sans l’imprimer dans le terminal ni dans les logs. Révoquez un jeton exposé et créez-en un nouveau avec moins de droits.
• Le serveur demande trop d’accès : interrompez l’essai. Retirez les outils inutiles ou refusez la connexion plutôt que d’accorder un accès général.
• Instructions provenant du serveur : traitez les résultats comme des données non fiables ; relisez l’action proposée et confirmez toute écriture avant exécution.
• Fin de l’essai : retirez la configuration selon sa portée et révoquez les identifiants temporaires. N’utilisez jamais la base de production pour valider une intégration.

Sources

• Anthropic — MCP dans Claude Code : transports, portées, configuration et diagnostic.
• Anthropic — Quickstart MCP : ajout et vérification d’un premier serveur.
• Model Context Protocol — specification : protocole et concepts généraux.
• Model Context Protocol — Security Best Practices : menaces et réduction des privilèges.

Sources officielles revérifiées le 19 octobre 2026. Les formats de configuration et capacités évoluent. Les commandes affichées sont des exemples non exécutés dans le cadre de l’article. Ce guide ne valide aucun serveur tiers ni aucune connexion à une donnée de production.