Comment installer un serveur MCP Salesforce dans votre workflow DevOps

Reponse courte : mettre en place un serveur MCP Salesforce demande trois decisions et une dizaine de minutes de configuration. Choisissez le serveur (Salesforce DX en local, un endpoint Salesforce heberge, ou celui de votre plateforme DevOps), pointez votre client IA dessus avec une liste explicite d'orgs autorisees, puis reduisez les toolsets au strict necessaire. Ce qui prend plus de dix minutes, et que la plupart des guides sautent, c'est de decider quelles actions l'agent peut executer seul et lesquelles restent derriere un humain.

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

Le Model Context Protocol est un standard ouvert qui expose des outils a un client IA. Un serveur MCP pour Salesforce transforme des operations habituellement lancees en CLI ou dans une interface en outils appelables par un assistant : interroger une org, recuperer des metadonnees, lancer des tests Apex, ouvrir une pull request, planifier un deploiement. Le client decide quoi appeler, le serveur decide ce qui existe et qui a le droit de l'appeler.

Pour le DevOps, ce cadrage compte. Le serveur est votre frontiere de politique. Tout ce que vous exposez, le modele finira par l'essayer.

Quel serveur MCP Salesforce choisir ?

Salesforce DX MCP Server. Fonctionne en local avec les identifiants deja autorises via la CLI Salesforce. Ideal pour les developpeurs travaillant metadonnees, donnees et tests. Package : @salesforce/mcp.
Serveurs MCP Salesforce heberges. 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 deploiement vit la, 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 a Claude, Cursor, Windsurf, Codex, Cline, GitHub Copilot et Agentforce.

La plupart des equipes finissent avec deux serveurs : un pour l'org, un pour la release. Ils repondent a des questions differentes.

Comment installer le serveur MCP Salesforce DX ?

Autorisez d'abord les orgs. Lancez sf org login web pour chaque org. Le serveur MCP n'atteint que les orgs deja connues de la CLI : c'est votre premier controle, et le moins cher.
Ajoutez le serveur a la config de votre client. Une entree minimale ressemble a ceci : {"mcpServers":{"Salesforce DX":{"command":"npx","args":["-y","@salesforce/mcp","--orgs","DEFAULT_TARGET_ORG","--toolsets","orgs,metadata,data"]}}}
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 derniere valeur comme etant a utiliser avec prudence. Ecoutez-la.
Reduisez les toolsets. --toolsets selectionne des groupes fonctionnels plutot 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 deconseille : chaque outil charge consomme du contexte que le modele pourrait utiliser pour reflechir.
Laissez les outils non GA desactives. Les outils sont marques GA ou non GA, et ces derniers exigent --allow-non-ga-tools. N'activez pas ce flag dans un depot que d'autres clonent.

Comment gerer l'authentification ?

Les serveurs locaux heritent des identifiants de la CLI, ce qui est pratique et signifie que le rayon d'action de l'agent egale celui du developpeur. Les serveurs heberges utilisent OAuth avec PKCE via une External Client App, le bon modele quand vous voulez une identite distincte avec ses propres scopes.

La regle qui tient dans les deux cas : l'identite MCP ne doit pas etre un admin partage. Donnez-lui son propre utilisateur, son propre permission set, et pas plus d'acces objet que n'en exigent les outils actives. Si votre agent peut appeler un outil de donnees, supposez qu'un jour il le fera.

Quelles actions doivent rester derriere une approbation humaine ?

C'est le point a debattre en equipe, pas a recopier d'un blog. Une base de travail :

Automatisable sans risque : lire des metadonnees, decrire des objets, executer du SOQL sur des sandboxes, lancer des tests Apex, generer un plan de deploiement, ouvrir une pull request, publier un resume.
Toujours approuve par un humain : deployer en production, publier une version de package, operations de donnees en masse, supprimer ou ecraser des metadonnees, resoudre un conflit d'une facon qui detruit le changement d'un collegue.
Jamais expose : gestion des identifiants, provisioning d'utilisateurs, tout ce qui touche une org de production sans chemin de retour arriere.

Le point de conception essentiel : l'approbation doit vivre dans le serveur, pas dans le prompt. Un modele a qui l'on demande de demander d'abord demandera presque toujours, et "presque toujours" n'est pas un controle. Le serveur MCP de Serpent execute des controles prealables et exige une approbation humaine avant qu'un deploiement ne s'execute, de sorte que la frontiere est appliquee par la plateforme et non par la politesse.

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

Une boucle typique : le developpeur demande a l'assistant de preparer 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 trouves. Un humain lit ce plan et l'approuve. L'agent declenche le pipeline, le surveille et rapporte le resultat. Chaque ecriture est auditable, et l'humain y a passe deux minutes au lieu de quarante.

Commencez par un depot et une sandbox. N'elargissez les toolsets que lorsqu'une vraie tache echoue faute d'outil. D'autres guides Salesforce DevOps couvrent en detail 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 heberges passent par OAuth et n'exigent aucune installation locale.

Un serveur MCP peut-il deployer en production ?

Techniquement oui, et c'est precisement pourquoi il ne doit pas le faire sans surveillance. Gardez les deploiements de production derriere une approbation imposee 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 eprouvee.

MCP convient-il aux environnements reglementes ?

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