Comment connecter votre agent de code IA à vos propres outils avec MCP

Si vous avez passé du temps avec un agent de code IA, vous vous êtes probablement heurté au mur où il vous dit quelque chose comme « Je ne peux pas voir votre base de données » ou « collez ici les détails du ticket. » L'agent est intelligent, mais il est enfermé — il ne connaît que ce qui se trouve dans vos fichiers et ce que vous tapez. Le Model Context Protocol (MCP) est la façon de faire tomber ce mur et de laisser l'agent atteindre vos véritables outils : une base de données, GitHub, un tableau de bord de supervision, un fichier de design.

Ce guide explique ce qu'est le MCP et détaille étape par étape la connexion de votre premier serveur à Claude Code, les mêmes idées s'appliquant à Cursor et Copilot.

Ce qu'est réellement le MCP

Le MCP est une norme ouverte — voyez-le comme un adaptateur universel entre les agents IA et les systèmes que vous utilisez déjà. Plutôt que chaque outil invente sa propre façon de dialoguer avec chaque agent, un outil livre un seul serveur MCP, et n'importe quel agent compatible MCP (Claude, Cursor, Copilot) peut s'y connecter. C'est pourquoi vous avez vu « MCP » partout en 2026 : c'est la tuyauterie qui permet aux agents de faire un vrai travail au lieu de simplement en parler.

Une bonne règle empirique : connectez un serveur dès que vous vous surprenez à copier des données dans la conversation depuis un autre outil. Si vous ne cessez de coller des journaux d'erreurs depuis Sentry ou des détails de tickets depuis Jira, c'est le signe qu'un serveur MCP vous éviterait l'aller-retour.

Les deux types de serveurs

Il existe deux variantes que vous rencontrerez :

• Les serveurs distants (HTTP) s'exécutent dans le cloud et vous vous y connectez par le réseau — Notion, GitHub et la plupart des outils SaaS fonctionnent ainsi. C'est l'option recommandée par défaut.
• Les serveurs locaux (stdio) s'exécutent comme un processus sur votre propre machine — utiles pour ce qui nécessite un accès système direct, comme un pilote de base de données locale.

Ajouter votre premier serveur

La commande centrale est claude mcp add. Voici la forme de base pour un serveur HTTP distant :

claude mcp add --transport http <name> <url>

Un exemple concret — connecter Notion pour que votre agent puisse lire et mettre à jour des pages :

claude mcp add --transport http notion https://mcp.notion.com/mcp

Si le serveur nécessite une authentification, passez un jeton sous forme d'en-tête :

claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Pour un serveur local, tout ce qui suit -- est la commande qui le démarre :

claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

Ce -- est important : il sépare les propres options de Claude de la commande qui lance le serveur, afin qu'un --port destiné au serveur ne soit pas interprété comme une option de Claude.

Une fois ajouté, vérifiez ce que vous avez branché :

claude mcp list        # voir tous les serveurs et leur statut
claude mcp get notion  # détails d'un serveur

Au sein d'une session Claude Code, la commande /mcp affiche l'état des connexions en temps réel et, pour les serveurs qui utilisent OAuth, vous permet de vous connecter.

Choisir la bonne portée

Lorsque vous ajoutez un serveur, décidez qui doit le voir avec l'option --scope :

• local (la valeur par défaut) — seulement vous, seulement ce projet.
• project — partagé avec toute votre équipe via un fichier .mcp.json versionné. Idéal pour l'intégration : un nouveau coéquipier clone le dépôt et l'agent connaît déjà les outils de l'équipe.
• user — disponible pour vous dans tous les projets de votre machine.

Pour une base de données d'équipe ou un gestionnaire de tickets, la portée project est généralement ce que vous voulez. Pour une clé d'API personnelle, conservez local ou user afin qu'elle n'atterrisse jamais dans le dépôt.

Le faire en toute sécurité

Le MCP est puissant précisément parce qu'il donne à un agent une portée réelle — un peu de prudence est donc payante :

• Faites confiance au serveur avant de le connecter. Un serveur qui récupère du contenu externe peut vous exposer à un risque d'injection de prompt, où un texte malveillant présent dans les données récupérées tente de détourner votre agent. Tenez-vous-en aux serveurs officiels d'éditeurs que vous connaissez.
• Restreignez étroitement les identifiants. Donnez au serveur une clé en lecture seule ou à moindre privilège lorsque la tâche ne nécessite que la lecture. C'est exactement le principe que Microsoft a intégré dans son plugin Dataverse pour entreprises — l'agent ne voit jamais que ce que son rôle accordé autorise.
• Gardez les secrets hors de la configuration partagée. Placez les jetons dans des variables d'environnement ou une portée local, jamais dans un fichier .mcp.json à portée project qui finit versionné.
• Passez en revue ce qu'il peut faire. Après la connexion, ouvrez /mcp et parcourez les outils que le serveur expose afin d'éviter les surprises.

Le bénéfice

Une fois un serveur connecté, le changement dans votre façon de travailler est immédiat. Au lieu de « voici le schéma que j'ai collé », vous pouvez demander : « Trouve les 10 inscriptions les plus récentes dans notre base de données Postgres et rédige une invitation à une session de feedback pour chacune. » L'agent interroge la base de données, lit les résultats et rédige les e-mails — le tout d'un seul flux, parce qu'il peut enfin atteindre les systèmes où votre travail réside réellement.

Commencez par un seul serveur, pour l'outil depuis lequel vous copiez le plus. Cette unique connexion rend généralement la valeur évidente plus vite que toute quantité de lecture à son sujet.