Clients : IDE, agents et orchestrateurs

Bienvenue

Un serveur MCPMCPIAModel 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 ne fait rien tout seul. Il expose des capacités — outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire, ressources, prompts — mais c'est le client qui décide quand les solliciter, comment présenter les résultats au modèle et surtout ce qu'il autorise à s'exécuter sans confirmation. Comprendre les clients, c'est comprendre la moitié de la sécurité et de l'ergonomie réelles d'un déploiement MCP.

Ce chapitre compare les grandes familles de clients disponibles aujourd'hui — assistants de bureau, IDE augmentés, agentsagentIASystè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 développés en interne — puis détaille les mécanismes de configuration et de permission qui les distinguent. Il se termine par une méthode pour bâtir un catalogue d'outils internes qui reste gouvernable à mesure que le nombre de serveurs augmente.

Les chapitres précédents ont traité la conception et l'exposition des serveurs. Ici, on change de perspective : on se place du côté de l'agent qui consomme ces serveurs, avec ses propres contraintes d'UX, de sécurité et de gouvernance.

Le rôle exact d'un client MCP

Un client MCP remplit quatre fonctions, indépendamment de son interface :

1. Découverte — il se connecte à un ou plusieurs serveurs et récupère la liste des outils, ressources et prompts disponibles.
2. Présentation au modèle — il traduit ces capacités dans le format attendu par le modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire (schémas de fonctions, descriptions, contraintes de paramètres).
3. Arbitrage des appels — quand le modèle décide d'invoquer un outil, le client intercepte cette décision, vérifie les permissions et, selon la politique en vigueur, demande confirmation à l'utilisateur.
4. Exécution et retour — il transmet l'appel au serveur, récupère la réponse, et la réinjecte dans le 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 de la conversation.

Ce découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire explique pourquoi deux clients connectés au même serveur MCP peuvent produire des expériences radicalement différentes : la logique de découverte et d'exécution est standardisée par le protocole, mais l'arbitrage des appels et la présentation restent entièrement à la discrétion du client.

Ne jamais considérer un client MCP comme un tuyau neutre. C'est lui qui décide, par sa politique de permission, si un outil capable de supprimer des fichiers ou d'envoyer des e-mails peut s'exécuter sans confirmation humaine. Deux organisations utilisant les mêmes serveurs peuvent avoir des niveaux de risque très différents selon la configuration du client.

Panorama des clients du marché

Claude Desktop

Claude Desktop est un client grand public pensé pour un usage individuel. La configuration des serveurs se fait via un fichier de configuration local (claude_desktop_config.json ou équivalent selon la plateforme) qui liste les serveurs à lancer au démarrage, avec leur commande d'exécution et leurs variables d'environnement. L'utilisateur voit apparaître les outils disponibles dans l'interface et peut, selon les réglages, être invité à confirmer chaque appel sensible.

Ce client convient bien à l'exploration, au prototypage et aux usages personnels où l'utilisateur maîtrise directement les serveurs qu'il connecte. Il est en revanche mal adapté à un déploiement à l'échelle d'une équipe : la configuration reste locale à chaque poste, sans mécanisme centralisé de distribution ou de révocation.

Claude Code

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 s'adresse aux flux de travail orientés développement. La configuration des serveurs MCP y est déclarée par projet (fichier de configuration versionné) ou par utilisateur, avec une distinction claire entre serveurs de confiance et serveurs à approuver explicitement à la première utilisation. Le mode d'exécution en ligne de commande facilite l'intégration dans des pipelines — un agent Claude Code peut être invoqué depuis un script, une CI, ou un autre agent.

L'un des intérêts pratiques de ce client est que la configuration des serveurs autorisés peut être versionnée avec le code : un changement de politique de permission passe par une revue de pull request, comme n'importe quelle autre modification du dépôt.

Cursor et les IDE augmentés

Cursor et les IDE comparables intègrent MCP directement dans l'environnement de développement. Les serveurs y sont généralement configurés par workspace, ce qui permet d'attacher des outils spécifiques à un projet : un serveur de tickets connecté au dépôt du produit concerné, un serveur de 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 pointant vers l'environnement de développement correspondant. Cette granularité par workspace est précieuse pour éviter qu'un développeur travaillant sur un projet A n'invoque par erreur un outil configuré pour le projet B.

L'UX de permission de ces IDE suit en général un modèle proche de celui des extensions : une première autorisation explicite par serveur, puis des réglages fins par outil (lecture seule, écriture, exécution de commandes).

Agents custom

Les agents développés en interne — pour automatiser un processus métier, alimenter un chatbot support, ou orchestrer une chaîne de traitement — sont des clients MCP à part entière dès lors qu'ils utilisent le protocole pour consommer des outils. Ils offrent le plus haut niveau de contrôle : politique de permission programmable, journalisation sur mesure, restriction des serveurs accessibles selon l'identité de l'appelant.

Cette flexibilité a un coût : toute la logique d'arbitrage des appels, normalement fournie « prête à l'emploi » par un client comme Claude Desktop ou Claude Code, doit être conçue et maintenue par l'équipe qui développe l'agent.

Une équipe support construit un agent custom connecté à trois serveurs MCP : un serveur CRM en lecture seule, un serveur de base de connaissances, et un serveur de création de tickets. L'agent est configuré pour n'autoriser la création de tickets qu'après confirmation explicite de l'agent humain qui supervise la conversation, alors que la lecture du CRM et de la base de connaissances est automatique. Cette asymétrie reflète le risque réel de chaque opération : lire n'engage rien, créer un ticket déclenche une action visible par un client externe.

Configuration des serveurs autorisés

Quel que soit le client, la configuration d'un serveur autorisé répond à trois questions :

• Quel serveur — son identité (nom, commande de lancement ou URL, version attendue).
• Avec quels droits — les identifiants ou jetons transmis au serveur, qui déterminent ce qu'il peut lui-même atteindre en aval.
• Sous quelle politique de confiance — le serveur est-il « de confiance » (ses outils s'exécutent sans confirmation) ou « à approuver » (chaque appel, ou chaque appel sensible, requiert une validation) ?

La tentation la plus fréquente est de déclarer tous les serveurs internes comme « de confiance » pour fluidifier l'expérience. C'est une erreur de raisonnement : la confiance accordée à un serveur ne doit pas dépendre de qui l'a développé, mais de la nature réelle des actions que ses outils déclenchent.

Un serveur écrit par l'équipe plateforme n'est pas automatiquement sûr à exécuter sans confirmation. Si l'un de ses outils peut modifier des données de production ou envoyer des communications externes, il doit rester soumis à confirmation même s'il provient d'une source interne réputée fiable. La confiance se mesure au risque de l'action, pas à l'origine du code.

Un tableau simple aide à formaliser cette politique lors de la mise en place d'un client dans une organisation :

L'UX des permissions

L'expérience de permission d'un client détermine directement si les utilisateurs comprennent ce qu'ils autorisent. Trois écueils reviennent régulièrement :

La fatigue de confirmation. Si chaque appel d'outil, y compris les plus anodins, déclenche une boîte de dialogue, les utilisateurs prennent l'habitude de cliquer « autoriser » sans lire. Le mécanisme de protection devient alors un théâtre de sécurité : il existe, mais ne protège plus rien. La parade consiste à réserver la confirmation explicite aux catégories d'actions réellement sensibles, comme indiqué dans le tableau ci-dessus.

Le manque de granularité. Certains clients ne proposent qu'une autorisation « tout ou rien » par serveur. Un serveur qui mélange des outils de lecture et des outils d'écriture force alors l'utilisateur à choisir entre une confiance excessive ou une confirmation permanente même pour les opérations bénignes. Privilégier des serveurs dont le périmètre d'outils est homogène en niveau de risque facilite grandement la configuration des permissions.

L'opacité du contexte transmis. Une confirmation qui affiche seulement le nom de l'outil, sans les paramètres réels de l'appel, ne permet pas à l'utilisateur de juger. Une bonne UX de permission montre les arguments effectifs — quel fichier, quel destinataire, quel montant — avant l'exécution.

Orchestrateurs multi-serveurs

Au-delà d'un client unique connecté à quelques serveurs, une organisation finit souvent par déployer un orchestrateur : un composant qui agrège plusieurs serveurs MCP, résout les conflits de noms d'outils, applique une politique de permission centralisée, et journalise l'ensemble des appels avant de présenter une interface unifiée à l'agent final.

L'orchestrateur répond à trois problèmes qui apparaissent dès qu'on dépasse une poignée de serveurs :

• Collision de noms. Deux serveurs indépendants peuvent exposer chacun un outil search. L'orchestrateur doit soit les préfixer automatiquement (crm.search, docs.search), soit imposer une convention de nommage aux serveurs qu'il agrège.
• Politique de permission hétérogène. Chaque serveur peut avoir été conçu avec ses propres hypothèses de confiance. L'orchestrateur impose une grille commune, quitte à durcir la politique par défaut d'un serveur individuellement plus permissif.
• Observabilité transverse. Sans point central, tracer un incident implique d'interroger chaque serveur séparément. Un orchestrateur qui journalise tous les appels, avec leur origine et leur résultat, réduit considérablement le temps de diagnostic.

Tant qu'une équipe utilise deux ou trois serveurs stables, un orchestrateur ajoute plus de complexité qu'il n'en retire. Le seuil de bascule se situe généralement autour d'une dizaine de serveurs actifs, ou dès qu'apparaît un vrai besoin d'audit centralisé — obligation réglementaire, incident de sécurité, multiplication des équipes consommatrices.

Un orchestrateur bien conçu se comporte lui-même comme un serveur MCP vis-à-vis du client final : il expose une surface d'outils agrégée, tout en restant lui-même un client vis-à-vis des serveurs qu'il fédère. Cette double casquette « client d'un côté, serveur de l'autre » est un motif d'architecture courant, à ne pas confondre avec un simple proxy réseau : l'orchestrateur prend de vraies décisions de permission, il ne relaie pas aveuglément.

Construire un catalogue d'outils internes

À mesure que le nombre de serveurs MCP déployés augmente, l'absence de catalogue central devient le principal frein à l'adoption : les équipes redéveloppent des serveurs déjà existants, faute de savoir qu'ils existent, ou pire, connectent des agents à des serveurs non maintenus.

Une stratégie de catalogue efficace repose sur quatre éléments :

1. Un registre unique, même minimal, qui liste chaque serveur avec son propriétaire, son périmètre fonctionnel, son niveau de sensibilité et son statut (actif, déprécié, expérimental).
2. Une convention de nommage appliquée dès la création d'un serveur, pour limiter les collisions et faciliter la recherche dans le registre.
3. Un processus de revue avant mise en production, comparable à une revue de code, qui vérifie notamment que la classification de risque des outils exposés correspond à la réalité.
4. Un mécanisme de dépréciation, car un catalogue qui ne retire jamais rien devient aussi peu fiable qu'une absence de catalogue.

Un registre qui se contente de lister des noms de serveurs sans documenter leur niveau de risque ne résout pas le problème central : celui de savoir, pour chaque outil, quelle politique de permission appliquer. Le catalogue doit porter cette information, sans quoi chaque équipe consommatrice devra la redécouvrir par elle-même.

En pratique, ce catalogue peut être un simple fichier structuré versionné dans un dépôt partagé, avant même d'envisager un outillage dédié. Ce qui compte est moins la sophistication de l'outil que la discipline de mise à jour : un catalogue périmé est plus dangereux qu'une absence de catalogue, car il inspire une confiance non méritée.

Points de vigilance transverses

Quelques principes reviennent quel que soit le client retenu :

• Ne jamais confondre la facilité d'installation d'un serveur avec la légitimité de lui accorder une confiance étendue.
• Documenter, pour chaque client déployé en production, la liste exacte des serveurs autorisés et la justification de leur niveau de confiance.
• Prévoir un canal de révocation rapide : si un serveur est compromis ou présente un comportement anormal, sa désactivation ne doit pas dépendre d'un déploiement complet.
• Auditer périodiquement les journaux d'appels d'outils, pas seulement au moment d'un incident.

Ce qu'il faut retenir

Le client MCP n'est pas un détail d'intégration : c'est le point où se joue l'essentiel de la sécurité et de l'ergonomie d'un déploiement. Claude Desktop, Claude Code, Cursor et les agents custom répondent à des besoins différents — usage individuel, flux de développement, intégration IDE, automatisation métier — mais partagent tous la même responsabilité d'arbitrer les appels d'outils selon une politique de permission réfléchie plutôt que par défaut. Dès qu'une organisation dépasse quelques serveurs, un orchestrateur devient pertinent pour centraliser la permission et l'observabilité, et un catalogue d'outils internes devient indispensable pour éviter la redondance et la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire silencieuse des niveaux de confiance accordés.