Deployer Salesforce depuis Claude, Cursor et Agentforce : ce que change un serveur MCP natif

Reponse courte : un serveur MCP natif permet a un client IA comme Claude, Cursor ou Agentforce d'appeler les vraies actions de release de votre plateforme DevOps : planifier un deploiement, ouvrir une pull request, resoudre un conflit de metadonnees, declencher un pipeline. C'est une categorie differente d'une IA qui ecrit de l'Apex dans un fichier. Serpent exploite le seul serveur MCP natif du DevOps Salesforce, et tout deploiement lance par un agent passe malgre tout par un controle prealable et une approbation humaine avant d'atteindre la production.

Qu'est-ce qu'un serveur MCP natif en DevOps Salesforce ?

Model Context Protocol est un standard ouvert qui relie les applications IA a des outils et a des sources de donnees. Salesforce a annonce le support de MCP sur l'ensemble de sa pile en juin 2025, en commencant par le Salesforce DX MCP Server, le Heroku Platform MCP Server et le MuleSoft MCP Server.

Natif est le mot qui porte tout. Un serveur MCP natif est construit et exploite par la plateforme elle-meme, sur sa propre API, et expose les actions qu'elle execute deja au quotidien. Un script qui se contente d'appeler la CLI n'a rien a voir : il ignore vos projets, vos environnements, vos regles d'approbation et votre piste d'audit.

En quoi deployer avec un agent differe-t-il de coder avec un agent ?

Dans l'ecosysteme Salesforce, la conversation sur l'IA porte surtout sur la generation. Un assistant redige un trigger, un LWC ou une classe de test, et un humain le relit avant que quoi que ce soit ne parte. Si le modele se trompe, la revue de code le rattrape.

Le travail de release n'a pas ce filet. Un deploiement est un changement d'etat dans une org vivante, et le rayon d'impact ce sont des processus metier, pas un commentaire de pull request. La vraie question n'est donc pas de savoir si un modele ecrit du bon Apex. Elle est de savoir si les outils confies a l'agent sont surs a appeler, et ce qui se dresse entre l'intention de l'agent et la production.

C'est une question d'outillage, pas de modele, et c'est exactement la qu'une plateforme DevOps doit se trouver dans la boucle.

Que peuvent reellement faire Claude, Cursor ou Agentforce ?

Serpent expose ses actions de release sous forme d'outils MCP. Les quatre essentiels :

• plan_deploy : determiner ce qui partirait, de quelle branche vers quelle org, et montrer le delta avant toute execution.
• create_pull_request : ouvrir la PR sur la bonne branche, avec la modification rattachee a un work item.
• resolve_metadata_conflict : traiter les collisions de profils, de permission sets et de flows qui rendent les merges Salesforce penibles.
• trigger_pipeline : lancer le pipeline une fois qu'un humain a approuve.

Le meme serveur repond a Claude, Cursor, Windsurf, Agentforce, Codex, Cline et GitHub Copilot, car MCP est independant du client. Vous n'achetez pas un assistant. Vous donnez a l'assistant que votre equipe utilise deja un jeu d'outils de release qu'il a le droit d'appeler.

Ou s'arrete le support MCP de Salesforce lui-meme ?

Salesforce a avance vite, et les serveurs de la plateforme sont reellement utiles. Les Salesforce Hosted MCP Servers permettent a un client de lire et d'ecrire des sObjects, d'executer des invocable actions et de lancer des flows sans installation locale, et Agentforce dispose de son propre client MCP.

Ce que ces serveurs decrivent, c'est une org. Ce dont une release a besoin, c'est la couche au-dessus :

• Sur quelle branche vit cette modification, et quels environnements elle a deja franchis.
• Si l'org cible a derive depuis le dernier deploiement.
• Qui a approuve, et sur quel work item.
• Comment revenir en arriere en cas de probleme.

Aucun serveur au niveau de l'org ne porte ce contexte, parce qu'il ne vit pas dans l'org. Il vit dans le pipeline.

Qu'est-ce qui empeche un agent de deployer ce qu'il ne devrait pas ?

Quatre choses, volontairement ennuyeuses :

• Le prealable d'abord. Un deploiement est planifie et valide avant d'etre execute, donc l'agent propose un change set concret plutot qu'une phrase.
• Approbation humaine obligatoire. Aucun appel MCP ne promeut seul en production. Cette porte d'approbation n'est pas un reglage que l'agent peut contourner par la conversation.
• Aucune empreinte dans l'org. Serpent n'installe rien dans votre org Salesforce et se connecte uniquement via les API standard.
• Une piste d'audit complete. Chaque action est attribuee et journalisee, chiffree au repos et en transit en AES-256. Un deploiement lance par un agent est aussi verifiable que celui d'un humain.

Comment le mettre en route ?

1. Connectez vos orgs et votre depot a un workspace Serpent.
2. Ajoutez le serveur MCP Serpent a la configuration MCP de votre client, comme n'importe quel autre serveur.
3. Authentifiez-vous avec un jeton d'acces personnel : c'est lui qui rattache chaque action d'agent a un utilisateur nomme.
4. Demandez en langage courant : planifie le deploiement d'UAT vers la production pour ce work item.
5. Lisez le plan, approuvez-le, et laissez le pipeline s'executer.

Le serveur MCP est inclus dans tous les plans, y compris l'offre gratuite Essentials, donc aucune option a acheter avant de verifier si les releases pilotees par agent conviennent a votre equipe. Decouvrez ce que fait Serpent.

FAQ

L'IA deploie-t-elle en production toute seule ?

Non. Toute promotion en production exige une approbation humaine, quel que soit le client MCP a l'origine de la demande.

Faut-il connaitre Git pour l'utiliser ?

Non. Serpent fait tourner Git en arriere-plan, et les outils MCP parlent en work items, environnements et deploiements plutot qu'en branches et rebases.

Quels clients IA sont pris en charge ?

Claude, Cursor, Windsurf, Agentforce, Codex, Cline et GitHub Copilot. Tout client compatible MCP peut se connecter, car le protocole est independant du client.

Est-ce la meme chose que le Salesforce DX MCP Server ?

Non, et les deux sont complementaires. Les serveurs Salesforce agissent sur une org : enregistrements, metadonnees, flows. Serpent agit sur la release : plans, pull requests, conflits et pipelines.

Cela installe-t-il quelque chose dans mon org ?

Non. Serpent passe par les API standard de Salesforce et n'installe aucun package, donc rien ne s'ajoute au perimetre de votre propre security review.