Comment installer un serveur MCP Salesforce dans votre workflow DevOps

Réponse courte : mettre en place un serveur MCP Salesforce demande trois décisions et une dizaine de minutes de configuration. Choisissez le serveur (Salesforce DX en local, un endpoint Salesforce hébergé, ou celui de votre plateforme DevOps), pointez votre client IA dessus avec une liste explicite d'orgs autorisées, puis réduisez les toolsets au strict nécessaire. Ce qui prend plus de dix minutes, et que la plupart des guides sautent, c'est de décider quelles actions l'agent peut exécuter seul et lesquelles restent derrière un humain.

Qu'est-ce qu'un serveur MCP Salesforce ?

Le Model Context Protocol est un standard ouvert qui expose des outils à un client IA. Un serveur MCP pour Salesforce transforme des opérations habituellement lancées en CLI ou dans une interface en outils appelables par un assistant : interroger une org, récupérer des métadonnées, lancer des tests Apex, ouvrir une pull request, planifier un déploiement. Le client décide quoi appeler, le serveur décide ce qui existe et qui a le droit de l'appeler.

Pour le DevOps, ce cadrage compte. Le serveur est votre frontière de politique. Tout ce que vous exposez, le modèle finira par l'essayer.

Quel serveur MCP Salesforce choisir ?

• Salesforce DX MCP Server. Fonctionne en local avec les identifiants déjà autorisés via la CLI Salesforce. Idéal pour les développeurs travaillant métadonnées, données et tests. Package : @salesforce/mcp.
• Serveurs MCP Salesforce hébergés. Endpoints cloud accessibles en OAuth, pour ceux qui ne veulent pas installer la CLI. Voir l'annonce Salesforce sur le support MCP pour l'ensemble de la pile, y compris les serveurs Heroku et MuleSoft.
• Le serveur MCP de votre plateforme DevOps. C'est celui qui compte pour le travail de release, car le déploiement vit là, pas dans l'org. Le serveur MCP natif de Serpent expose des actions de pipeline comme plan_deploy, create_pull_request, resolve_metadata_conflict et trigger_pipeline à Claude, Cursor, Windsurf, Codex, Cline, GitHub Copilot et Agentforce.

La plupart des équipes finissent avec deux serveurs : un pour l'org, un pour la release. Ils répondent à des questions différentes.

Comment installer le serveur MCP Salesforce DX ?

1. Autorisez d'abord les orgs. Lancez sf org login web pour chaque org. Le serveur MCP n'atteint que les orgs déjà connues de la CLI : c'est votre premier contrôle, et le moins cher.
2. Ajoutez le serveur à la config de votre client. Une entrée minimale ressemble à ceci : {"mcpServers":{"Salesforce DX":{"command":"npx","args":["-y","@salesforce/mcp","--orgs","DEFAULT_TARGET_ORG","--toolsets","orgs,metadata,data"]}}}
3. Cadrez les orgs explicitement. Le flag --orgs est obligatoire. Il accepte DEFAULT_TARGET_ORG, DEFAULT_TARGET_DEV_HUB, des noms d'utilisateur ou alias explicites, et ALLOW_ALL_ORGS. La documentation Salesforce signale cette dernière valeur comme étant à utiliser avec prudence. Écoutez-la.
4. Réduisez les toolsets. --toolsets sélectionne des groupes fonctionnels plutôt que de tout charger. Il y en a plus de quinze, dont orgs, metadata, data, users, testing, devops et code-analysis. Activer all fonctionne mais est déconseillé : chaque outil chargé consomme du contexte que le modèle pourrait utiliser pour réfléchir.
5. Laissez les outils non GA désactivés. Les outils sont marqués GA ou non GA, et ces derniers exigent --allow-non-ga-tools. N'activez pas ce flag dans un dépôt que d'autres clonent.

Comment gérer l'authentification ?

Les serveurs locaux héritent des identifiants de la CLI, ce qui est pratique et signifie que le rayon d'action de l'agent égale celui du développeur. Les serveurs hébergés utilisent OAuth avec PKCE via une External Client App, le bon modèle quand vous voulez une identité distincte avec ses propres scopes.

La règle qui tient dans les deux cas : l'identité MCP ne doit pas être un admin partagé. Donnez-lui son propre utilisateur, son propre permission set, et pas plus d'accès objet que n'en exigent les outils activés. Si votre agent peut appeler un outil de données, supposez qu'un jour il le fera.

Quelles actions doivent rester derrière une approbation humaine ?

C'est le point à débattre en équipe, pas à recopier d'un blog. Une base de travail :

• Automatisable sans risque : lire des métadonnées, décrire des objets, exécuter du SOQL sur des sandboxes, lancer des tests Apex, générer un plan de déploiement, ouvrir une pull request, publier un résumé.
• Toujours approuvé par un humain : déployer en production, publier une version de package, opérations de données en masse, supprimer ou écraser des métadonnées, résoudre un conflit d'une façon qui détruit le changement d'un collègue.
• Jamais exposé : gestion des identifiants, provisioning d'utilisateurs, tout ce qui touche une org de production sans chemin de retour arrière.

Le point de conception essentiel : l'approbation doit vivre dans le serveur, pas dans le prompt. Un modèle à qui l'on demande de demander d'abord demandera presque toujours, et "presque toujours" n'est pas un contrôle. Le serveur MCP de Serpent exécute des contrôles préalables et exige une approbation humaine avant qu'un déploiement ne s'exécute, de sorte que la frontière est appliquée par la plateforme et non par la politesse.

À quoi cela ressemble-t-il dans un vrai pipeline ?

Une boucle typique : le développeur demande à l'assistant de préparer une release. L'agent lit le diff, appelle l'outil de planification et revient avec les composants, les tests qu'il va lancer et les risques trouvés. Un humain lit ce plan et l'approuve. L'agent déclenche le pipeline, le surveille et rapporte le résultat. Chaque écriture est auditable, et l'humain y a passé deux minutes au lieu de quarante.

Commencez par un dépôt et une sandbox. N'élargissez les toolsets que lorsqu'une vraie tâche échoue faute d'outil. D'autres guides Salesforce DevOps couvrent en détail le volet pipeline.

FAQ

Faut-il la CLI Salesforce pour utiliser MCP ?

Pour le serveur local Salesforce DX, oui, car il utilise les identifiants de la CLI. Les serveurs MCP hébergés passent par OAuth et n'exigent aucune installation locale.

Un serveur MCP peut-il déployer en production ?

Techniquement oui, et c'est précisément pourquoi il ne doit pas le faire sans surveillance. Gardez les déploiements de production derrière une approbation imposée par le serveur, pas par le prompt.

Quels toolsets activer en premier ?

Commencez par orgs, metadata et data. Ajoutez testing quand vous voulez que l'agent lance des tests Apex, et l'outillage devops une fois la boucle en lecture seule éprouvée.

MCP convient-il aux environnements réglementés ?

Oui, si l'agent a sa propre identité, des droits minimaux, une piste d'audit et une porte humaine sur les écritures. Traitez-le comme n'importe quel utilisateur d'intégration, car c'en est un.