Déployer Salesforce depuis Claude, Cursor et Agentforce : ce que change un serveur MCP natif

Réponse courte : un serveur MCP natif permet à un client IA comme Claude, Cursor ou Agentforce d'appeler les vraies actions de release de votre plateforme DevOps : planifier un déploiement, ouvrir une pull request, résoudre un conflit de métadonnées, déclencher un pipeline. C'est une catégorie différente d'une IA qui écrit de l'Apex dans un fichier. Serpent exploite le seul serveur MCP natif du DevOps Salesforce, et tout déploiement lancé par un agent passe malgré tout par un contrôle préalable 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 à des outils et à des sources de données. Salesforce a annoncé le support de MCP sur l'ensemble de sa pile en juin 2025, en commençant 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 exploité par la plateforme elle-même, sur sa propre API, et expose les actions qu'elle exécute déjà au quotidien. Un script qui se contente d'appeler la CLI n'a rien à voir : il ignore vos projets, vos environnements, vos règles d'approbation et votre piste d'audit.

En quoi déployer avec un agent diffère-t-il de coder avec un agent ?

Dans l'écosystème Salesforce, la conversation sur l'IA porte surtout sur la génération. Un assistant rédige un trigger, un LWC ou une classe de test, et un humain le relit avant que quoi que ce soit ne parte. Si le modèle se trompe, la revue de code le rattrape.

Le travail de release n'a pas ce filet. Un déploiement est un changement d'état dans une org vivante, et le rayon d'impact ce sont des processus métier, pas un commentaire de pull request. La vraie question n'est donc pas de savoir si un modèle écrit du bon Apex. Elle est de savoir si les outils confiés à l'agent sont sûrs à appeler, et ce qui se dresse entre l'intention de l'agent et la production.

C'est une question d'outillage, pas de modèle, et c'est exactement là qu'une plateforme DevOps doit se trouver dans la boucle.

Que peuvent réellement faire Claude, Cursor ou Agentforce ?

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

• plan_deploy : déterminer ce qui partirait, de quelle branche vers quelle org, et montrer le delta avant toute exécution.
• create_pull_request : ouvrir la PR sur la bonne branche, avec la modification rattachée à un work item.
• resolve_metadata_conflict : traiter les collisions de profils, de permission sets et de flows qui rendent les merges Salesforce pénibles.
• trigger_pipeline : lancer le pipeline une fois qu'un humain a approuvé.

Le même serveur répond à Claude, Cursor, Windsurf, Agentforce, Codex, Cline et GitHub Copilot, car MCP est indépendant du client. Vous n'achetez pas un assistant. Vous donnez à l'assistant que votre équipe utilise déjà un jeu d'outils de release qu'il a le droit d'appeler.

Où s'arrête le support MCP de Salesforce lui-même ?

Salesforce a avancé vite, et les serveurs de la plateforme sont réellement utiles. Les Salesforce Hosted MCP Servers permettent à un client de lire et d'écrire des sObjects, d'exécuter des invocable actions et de lancer des flows sans installation locale, et Agentforce dispose de son propre client MCP.

Ce que ces serveurs décrivent, 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 déjà franchis.
• Si l'org cible a dérivé depuis le dernier déploiement.
• Qui a approuvé, et sur quel work item.
• Comment revenir en arrière en cas de problème.

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 empêche un agent de déployer ce qu'il ne devrait pas ?

Quatre choses, volontairement ennuyeuses :

• Le préalable d'abord. Un déploiement est planifié et validé avant d'être exécuté, donc l'agent propose un change set concret plutôt qu'une phrase.
• Approbation humaine obligatoire. Aucun appel MCP ne promeut seul en production. Cette porte d'approbation n'est pas un réglage 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 complète. Chaque action est attribuée et journalisée, chiffrée au repos et en transit en AES-256. Un déploiement lancé par un agent est aussi vérifiable que celui d'un humain.

Comment le mettre en route ?

1. Connectez vos orgs et votre dépôt à un workspace Serpent.
2. Ajoutez le serveur MCP Serpent à la configuration MCP de votre client, comme n'importe quel autre serveur.
3. Authentifiez-vous avec un jeton d'accès personnel : c'est lui qui rattache chaque action d'agent à un utilisateur nommé.
4. Demandez en langage courant : planifie le déploiement d'UAT vers la production pour ce work item.
5. Lisez le plan, approuvez-le, et laissez le pipeline s'exécuter.

Le serveur MCP est inclus dans tous les plans, y compris l'offre gratuite Essentials, donc aucune option à acheter avant de vérifier si les releases pilotées par agent conviennent à votre équipe. Découvrez ce que fait Serpent.

FAQ

L'IA déploie-t-elle en production toute seule ?

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

Faut-il connaître Git pour l'utiliser ?

Non. Serpent fait tourner Git en arrière-plan, et les outils MCP parlent en work items, environnements et déploiements plutôt 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 indépendant du client.

Est-ce la même chose que le Salesforce DX MCP Server ?

Non, et les deux sont complémentaires. Les serveurs Salesforce agissent sur une org : enregistrements, métadonnées, 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 périmètre de votre propre security review.