Outils MCP et extensions

Pourquoi ce chapitre compte

Jusqu'ici, Claude CodeClaude CodeIAInterface en ligne de commande agentique qui lit, édite et exécute des actions dans un dépôt de code sous contrôle de permissions, par opposition à un simple chat web.Voir dans le glossaire a travaillé avec ce qu'il trouve : les fichiers du projet, l'historique git, les commandes disponibles dans le terminal. C'est déjà beaucoup, mais ça s'arrête à la frontière du dépôt local. Or une bonne partie du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire utile à un développeur vit ailleurs — dans un wiki interne, un outil de tickets, une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire de référence. MCP (Model Context ProtocolMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire) est le mécanisme qui permet de faire traverser cette frontière de façon contrôlée.

Ce chapitre n'est pas un tutoriel d'installation détaillé — les interfaces de configuration évoluent. Il pose les bases conceptuelles stables : à quoi sert MCP, comment il s'articule avec le système de permissions déjà vu, et surtout, à partir de quand une connexion externe devient un risque plus qu'un gain. C'est la question qu'on doit se poser avant de brancher quoi que ce soit, pas après.

MCP étend ce que Claude Code peut lire et parfois écrire en dehors du projet local. Chaque serveur MCP actif est un canal supplémentaire entre l'agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire et un système extérieur — au même titre qu'un accès réseau qu'on accorderait à n'importe quel processus. Le traiter avec la même rigueur qu'une clé d'API n'est pas une précaution excessive, c'est la base.

Qu'est-ce que MCP, concrètement

MCP est un protocole ouvert qui standardise la façon dont un agent comme Claude Code dialogue avec des sources de données ou des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire externes. Avant ce standard, chaque intégration (un connecteur vers tel outil de tickets, tel entrepôt de documentation) demandait un code sur mesure, propre à chaque agent et à chaque service. MCP remplace cette multiplication de connecteurs ad hoc par une interface commune : un serveur MCP expose un ensemble de capacités (des "resources" à lire, des "tools" à invoquer) selon un format partagé, et n'importe quel client compatible — dont Claude Code — peut s'y connecter sans réécrire l'intégration à chaque fois.

Concrètement, un serveur MCP est un petit programme, local ou distant, qui tourne à côté de Claude Code et répond à des requêtes précises : "recherche ce terme dans la documentation", "donne-moi le contenu du ticket PROJ-482", "exécute cette requête SQL en lecture seule". Claude Code ne se connecte jamais directement à la base de données ou à l'API du outil de tickets — il passe par le serveur MCP, qui fait office d'intermédiaire et qui définit lui-même ce qu'il accepte d'exposer.

Cette indirection a une conséquence pratique importante : le serveur MCP est l'endroit où se décide le périmètre d'accès. Un serveur MCP mal écrit qui expose une requête SQL libre plutôt qu'un jeu de requêtes prédéfinies transfère tout le risque d'injection ou de fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire vers l'agent qui l'utilise. Le protocole standardise le format d'échange, pas la prudence de l'implémentation.

Anatomie d'une requête : qui décide quoi

Le flux d'une requête MCP suit toujours le même schéma. Claude Code identifie qu'une information ou une action nécessite un outil externe, formule une requête vers le serveur MCP concerné, et — selon la configuration de permissions du projet — cette requête peut nécessiter une validation explicite avant exécution, exactement comme pour une commande shell ou une modification de fichier vue dans les chapitres précédents sur les modes et les permissions.

Le point de vigilance ici n'est pas MCP en tant que tel, mais le niveau de confiance accordé à chaque serveur. Un serveur qui expose uniquement de la lecture sur une documentation publique peut raisonnablement tourner avec peu de friction. Un serveur qui peut écrire dans un outil de production mérite une validation systématique — jamais d'auto-approbation silencieuse.

Brancher une source : trois cas concrets

Documentation interne. Le cas le plus simple et le plus rentable. Un serveur MCP indexe un wiki, une base Confluence ou un ensemble de fichiers Markdown, et expose une capacité de recherche. Claude Code peut alors répondre à "comment configure-t-on le module d'authentification chez nous" en s'appuyant sur la doc réelle plutôt que sur des conventions génériques. L'accès est en lecture seule par nature : le risque est faible, la valeur immédiate.

Outil de tickets. Un serveur MCP branché sur Jira, Linear ou équivalent permet à Claude Code de lire le contenu d'un ticket référencé ("implémente ce qui est décrit dans PROJ-482") sans copier-coller manuel. Certains serveurs autorisent aussi la création de commentaires ou le changement de statut. C'est là que la prudence commence : la lecture est presque toujours sûre, l'écriture doit rester sous validation explicite, ticket par ticket.

Base de données en lecture. Cas le plus sensible des trois. Un serveur MCP peut exposer un accès en lecture seule à une base — utile pour que Claude Code vérifie un schéma, inspecte des données de test, ou diagnostique un bug en observant l'état réel des tables. Deux règles ne se négocient pas : l'utilisateur de connexion configuré doit être en lecture seule au niveau de la base elle-même (pas seulement "en théorie" côté serveur MCP), et cet accès ne doit jamais pointer vers une base de production contenant des données sensibles ou personnelles.

Ne jamais brancher un serveur MCP avec des identifiants qui autorisent plus que ce que la tâche exige. Un accès "lecture seule" configuré côté serveur MCP mais reposant sur des identifiants qui ont, eux, les droits d'écriture en base, n'est pas une protection — c'est une illusion de protection. La restriction doit exister au niveau du système cible, pas seulement dans la configuration de l'intermédiaire.

Extensions IDE vs agent CLI : deux logiques différentes

Claude Code existe sous plusieurs formes d'intégration, et il est utile de ne pas les confondre :

L'extension IDE est pensée pour des interactions courtes et localisées : on sélectionne un bloc de code, on demande une explication ou une réécriture, la portée reste contenue au fichier ou à la sélection. L'agent CLI, à l'inverse, est conçu pour des sessions où l'agent explore, exécute des commandes, modifie plusieurs fichiers et — potentiellement — dialogue avec des serveurs MCP. C'est dans ce second contexte que MCP prend tout son sens : une extension d'éditeur qui se contente de réécrire une fonction n'a généralement pas besoin d'interroger un outil de tickets externe.

Les deux modes d'intégration partagent le même moteur, mais pas la même surface d'action. Choisir l'un ou l'autre dépend de la tâche : édition ciblée → extension ; tâche qui traverse plusieurs systèmes → agent CLI avec, éventuellement, des serveurs MCP configurés.

Risques et surface d'attaque

Chaque serveur MCP ajouté élargit ce que l'agent peut atteindre, et donc ce qui peut mal tourner — par erreur de configuration, par bug dans le serveur, ou par contenu malveillant injecté depuis la source externe elle-même. Ce dernier point mérite d'être détaillé : si un serveur MCP lit du contenu externe (un ticket, une page de documentation) et que ce contenu est ensuite interprété par l'agent comme des instructions, on ouvre la porte à une forme d'injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire. Un ticket rédigé par un tiers malveillant pourrait, en théorie, contenir un texte formulé pour ressembler à une instruction système.

Les points de vigilance à retenir :

• Identifiants dédiés — un serveur MCP branché sur un outil externe doit utiliser un compte de service avec des droits minimaux, jamais les identifiants personnels d'un compte administrateur.
• Aucune écriture par défaut — configurer les serveurs en lecture seule tant qu'un besoin d'écriture n'est pas explicitement identifié et validé.
• Provenance du serveur — n'installer que des serveurs MCP dont la source est connue et le code auditable ; un serveur MCP tiers non vérifié a un accès potentiel à tout ce que Claude Code peut lui transmettre.
• Séparation des environnements — ne jamais connecter un serveur MCP à une base ou un système de production dans un contexte d'expérimentation ou d'apprentissage.
• Revue humaine active — garder les validations d'outils activées pour les serveurs qui touchent à des systèmes sensibles, plutôt que d'accorder une confiance automatique.

Une équipe branche un serveur MCP en lecture seule sur son système de tickets pour que Claude Code puisse résumer l'historique d'un bug avant de proposer un correctif. Le compte de service utilisé n'a accès qu'au projet concerné, pas à l'espace de travail entier. Résultat : un gain de temps réel sur le diagnostic, sans exposition du reste de l'organisation.

Quand rester simple

MCP n'est pas une case à cocher systématique. Beaucoup de tâches n'ont besoin de rien de plus que le système de fichiers local, git, et un bon CLAUDE.md qui documente les conventions du projet — déjà vu dans un chapitre précédent. Ajouter un serveur MCP a un coût : configuration, maintenance, et surtout surface de risque supplémentaire.

Quelques signaux qui indiquent qu'un branchement MCP est justifié :

• La même information externe est recopiée manuellement, encore et encore, dans les invites données à Claude Code.
• Une tâche récurrente nécessite de croiser systématiquement le code avec un système externe (tickets, documentation vivante).
• Plusieurs personnes de l'équipe referaient la même intégration ad hoc si elle n'existait pas de façon centralisée.

À l'inverse, si le besoin est ponctuel, un simple copier-coller du contexte pertinent dans l'invite reste souvent plus rapide à mettre en place et plus facile à auditer qu'un serveur MCP dédié. La complexité d'intégration doit être proportionnée à la fréquence et à la valeur du besoin réel.

Avant de configurer un serveur MCP, demandez-vous si un simple export ponctuel (un fichier texte collé dans le contexte, un extrait de documentation copié dans le projet) ne suffirait pas. MCP est fait pour l'usage récurrent, pas pour la commodité d'une seule tâche.

Checklist avant d'activer un serveur MCP

1. Le besoin est-il récurrent, ou une copie ponctuelle suffirait-elle ?
2. Le serveur MCP utilise-t-il un compte de service à droits minimaux, distinct de tout compte personnel ?
3. L'accès est-il en lecture seule, sauf besoin d'écriture explicitement justifié ?
4. La source du serveur MCP (code, éditeur) est-elle connue et fiable ?
5. La validation humaine des appels d'outils reste-t-elle active pour ce serveur ?
6. Le serveur pointe-t-il vers un environnement de test ou de développement plutôt que vers la production, sauf nécessité clairement identifiée ?

Cette liste n'est pas là pour ralentir l'adoption de MCP, mais pour éviter de découvrir un problème d'exposition après coup, une fois le serveur en place depuis plusieurs semaines. Le réflexe à retenir pour la suite de la formation : chaque capacité ajoutée à Claude Code — outil, extension, serveur MCP — doit être évaluée avec la même question simple : qu'est-ce que ça permet de faire, et à qui.