MCP headless sur Salesforce : adopter Headless 360 et mesurer le ROI

Le MCP headless consiste à faire tourner Salesforce comme un ensemble d'outils Model Context Protocol qu'un agent IA appelle directement, sans interface utilisateur dans la boucle. Salesforce le livre sous le nom de Headless 360 : des serveurs MCP hébergés, disponibles en général depuis avril 2026, plus le Headless 360 MCP Server, en bêta depuis juillet 2026. L'agent s'authentifie comme un vrai utilisateur et exécute le travail CRM et de configuration dans la sécurité existante de votre org, si bien qu'une requête en langage naturel devient une opération Salesforce gouvernée. Ce guide couvre ce que c'est, comment ça fonctionne, ce que ça fait aujourd'hui, la sécurité imposée, comment l'adopter sans risque, ce que votre revue de sécurité doit couvrir, comment mesurer le ROI et où se place un partenaire. Tekunda est la première société à livrer Salesforce headless avec MCP en production, et les règles d'adoption ci-dessous sont celles que nous appliquons à chaque déploiement.

Qu'est-ce que le MCP headless sur Salesforce ?

Le Model Context Protocol est un standard ouvert qui permet à un modèle IA de découvrir et d'appeler des outils, des API et des données externes à l'exécution, pour que n'importe quel client compatible parle à n'importe quel serveur compatible sans code de liaison sur mesure. « Headless » signifie qu'il n'y a pas d'écran dans la boucle : le travail passe par la couche API et agent plutôt que par des clics dans l'interface Lightning. Ensemble, une configuration MCP headless permet à Claude, Cursor, Agentforce ou tout client compatible MCP de lire des enregistrements, de lancer des requêtes et d'exécuter des opérations de configuration en appelant directement les outils Salesforce. La personne fixe l'intention ; l'agent trouve la bonne opération et l'exécute.

C'est important parce que la plupart des prototypes agentiques n'atteignent jamais la production. Ils fonctionnent en démo, puis s'effondrent dès qu'ils rencontrent de vraies permissions, de vrais volumes de données et une équipe sécurité. Le MCP headless est le schéma qui comble cet écart, parce que l'agent hérite du contexte et des règles de la plateforme au lieu de les réinventer.

Qu'est-ce que Salesforce Headless 360 ?

Salesforce a présenté Headless 360 à TDX en avril 2026 comme une initiative visant à exposer chaque capacité de la plateforme sous forme d'API, d'outil MCP ou de commande CLI, de sorte que le navigateur devienne optionnel plutôt qu'obligatoire. Selon le blog Salesforce Developers, cela couvre plus de 60 outils MCP, plus de 30 compétences de codage, plus de 4 000 API existantes et plus de 220 commandes CLI.

Distinguez deux couches, car les deux portent le nom Headless 360 :

• Les serveurs MCP hébergés standard gèrent le travail sur les données : SObject All, Reads, Mutations et Deletes, plus Data 360 et Tableau Next. Disponibles en général depuis avril 2026.
• Le Headless 360 MCP Server condense le travail de configuration et d'intégration en quatre outils. En bêta depuis juillet 2026.

Comment fonctionne le Headless 360 MCP Server ?

Son idée maîtresse est la retenue : les agents reçoivent quatre outils, pas quatre mille. Une org compte des milliers de fonctionnalités, et charger chaque endpoint dans le contexte d'un modèle ruine sa prise de décision, alors le serveur présente une surface petite et stable et fait le routage lui-même :

• Discover - recherche sémantique sur un index vectoriel d'API et de compétences, qui renvoie des candidats classés pour la demande.
• Describe - la spécification technique d'une compétence choisie : paramètres, dépendances, étapes ordonnées.
• Dispatch - invoque une compétence, avec contrôle d'accès imposé.
• Dispatch Read Only - exécute des opérations en lecture seule.

La boucle discover-describe-dispatch garde le contexte du modèle réduit pendant que le catalogue derrière grandit. La bêta a démarré avec une centaine de compétences, des milliers étant prévues.

Que peut faire le MCP headless dans Salesforce aujourd'hui ?

Au lancement, le Headless 360 MCP Server couvre :

• La gestion des utilisateurs, y compris la création et la désactivation d'utilisateurs, la réinitialisation des mots de passe et l'attribution des permissions.
• Le développement de triggers Apex.
• Les intégrations événementielles via Change Data Capture, platform events et event relays.
• La configuration des named credentials.

Au-delà de la configuration, les serveurs de données hébergés permettent à un agent de lister des leads, de lancer du SOQL et de mettre à jour des champs en langage naturel, et la surface MCP de Data 360 expose plus de 200 API pour qu'un agent construise, mappe et interroge des données unifiées avec des demandes en langage courant. Le même schéma s'étend aux systèmes autour de Salesforce : une intégration téléphonique qui synchronise les journaux d'appels avec les enregistrements, ou une conversation WhatsApp, devient un ensemble supplémentaire d'actions gouvernées qu'un agent déclenche, Salesforce restant le système de référence. Plutôt qu'un connecteur sur mesure pour chaque surface IA, vous exposez un serveur gouverné et tout client compatible MCP y accède.

Salesforce a de nouveau élargi Headless 360 le 19 août 2026, en ajoutant un client MCP Slackbot aux côtés du serveur Data 360 et plus de 100 nouvelles compétences d'agent, et le même changement apparaît aussi sur le marché des outils DevOps : Agentia de Copado a ajouté son propre mode MCP headless en septembre 2026. Prévoyez la bêta, pas la disponibilité générale, pendant votre évaluation : le Headless 360 MCP Server lui-même est encore en bêta au moment de la rédaction, même si des éléments adjacents comme Data 360 et le client Slackbot avancent plus vite.

Le MCP headless est-il sécurisé ?

Un agent capable de créer des utilisateurs et de déployer de l'Apex est exactement aussi dangereux que les permissions derrière lui, c'est donc la question qui compte. Ce qui rassure, c'est que Headless 360 n'invente pas de nouveau modèle de confiance ; il s'appuie sur celui que Salesforce impose déjà. Chaque transaction s'exécute en tant qu'utilisateur authentifié, délimitée par une external client app avec le scope mcp_api et OAuth 2.0 avec PKCE, et chaque action est bornée par quatre couches :

• Identité - l'agent agit en tant qu'utilisateur authentifié, jamais au-dessus.
• Accès - profils, permission sets, org-wide defaults, règles de partage et sécurité au niveau des champs s'appliquent toujours.
• Périmètre d'invocation - seules les compétences explicitement exposées peuvent être appelées.
• Gouvernance - règles de validation, transaction security policies, chaînes d'approbation et governor limits se déclenchent toujours.

Le modèle fournit l'intelligence. La plateforme fournit l'identité, l'accès, les capacités et la gouvernance, le contexte qui rend l'intelligence utile.

Si une personne ne peut pas le faire dans Salesforce, son agent ne peut pas le faire via MCP non plus. Salesforce livre aussi les serveurs standard désactivés, et sépare la lecture, la création/mise à jour et la suppression dans des serveurs distincts, pour que vous n'accordiez jamais la suppression par accident. Activez-la délibérément, car « supprimer tous les leads » n'est qu'à une requête une fois que c'est fait. L'accès MCP hébergé de base exige Enterprise Edition ou supérieur et n'est pas verrouillé derrière une licence Agentforce.

Comment adopter le MCP headless en production sans risque ?

Les démos sont faciles. C'est en production que les équipes se brûlent. Les règles que nous appliquons chez Tekunda à chaque déploiement :

• Commencez en lecture seule. Donnez aux agents Dispatch Read Only ou le serveur SObject Reads avant qu'un chemin d'écriture soit actif.
• Délimitez un permission set dédié. L'agent hérite de l'accès de son utilisateur, alors donnez-lui son propre utilisateur au moindre privilège, pas un login admin.
• Exigez une approbation pour les écritures. Gardez le mode de permission du client sur « approbation requise » pour la création, la mise à jour et la suppression tant que vous ne faites pas confiance au flux.
• Journalisez chaque dispatch. Capturez quelle compétence a tourné, en tant que qui, et sur quels enregistrements, pour qu'une action d'agent soit aussi auditable qu'une action humaine.
• Répétez dans un sandbox. Ne laissez jamais une nouvelle compétence toucher des données de production à sa première exécution.

La sécurité imposée par Salesforce est un plancher, pas une stratégie. Le risque n'est pas le protocole ; ce sont des permissions trop larges sur l'utilisateur connecté, et un agent agissant comme cet utilisateur peut toujours faire de gros dégâts, vite. Si vous reliez plusieurs agents, ou voulez une surface d'action unique qui couvre Salesforce et l'ERP, la téléphonie et les appareils autour, la conception des passages de relais compte autant que les permissions - voir exécuter les actions CRM depuis un seul hub agentique et ce qui fait fonctionner les passages de relais entre agents en production. Quand vous voulez ce déploiement conçu et gouverné correctement, notre équipe de services Salesforce fait exactement ce travail.

Que doit contenir une checklist de revue de sécurité pour les apps connectées à MCP ?

Si vous packagez un logiciel pour l'AppExchange, exposer des capacités via MCP ne vous dispense pas de la revue de sécurité AppExchange ; cela relève l'enjeu. Notre version courte, tirée de notre propre passage par la revue :

1. Imposez CRUD, FLS et partage dans chaque point d'entrée Apex qu'un agent peut atteindre, pas seulement l'interface.
2. Éliminez l'injection SOQL avec des variables de liaison, jamais de SOQL dynamique construit par chaînes.
3. Chiffrez les données en transit avec TLS 1.2 ou supérieur et au repos avec AES-256.
4. Limitez les named credentials et les connected apps au minimum, et prouvez-le.
5. Définissez les en-têtes de sécurité et les drapeaux de cookies (X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Secure et HttpOnly).
6. Scannez avant de soumettre avec Salesforce Code Analyzer plus un scanner comme Checkmarx, OWASP ZAP ou Burp Suite, et documentez chaque faux positif.
7. Documentez le stockage des données, l'authentification et chaque intégration externe utilisée par l'agent.

Les surfaces agentiques ajoutent une ligne à cette liste : confirmez qu'aucun outil ne peut escalader au-delà des permissions de l'utilisateur en cours. Une surface headless retire l'humain qui était le dernier contrôle, donc les propres contrôles de l'org doivent porter ce poids. Traitez l'agent comme un client authentifié de plus : si chaque dispatch passait la revue tout seul, la couche headless au-dessus la passera aussi.

Pour ces contrôles dans l'ordre qui compte, parcourez notre checklist de revue de sécurité Salesforce, et quand les scanners signalent des points que vous avez déjà traités, notre guide sur la documentation des faux positifs les empêche de bloquer votre soumission.

Comment mesurer le ROI d'un déploiement MCP headless ?

Mesurez-le avant de construire. Salesforce publie un calculateur de ROI Agentforce qui projette les économies et l'efficacité sur trois ans et estime les Flex Credits qu'un cas d'usage consommera, l'unité de consommation dans laquelle Salesforce facture l'usage des agents. C'est un point de départ honnête, mais il repose sur des hypothèses génériques, et un modèle défendable utilise vos chiffres.

Ancrez-le avec un cadre simple, tout normalisé en montant mensuel : (heures économisées par processus x volume mensuel x taux horaire chargé) - (dépense mensuelle en Flex Credits + coût de construction réparti sur l'horizon de retour + gouvernance mensuelle). Convertissez les Flex Credits en coût monétaire pour que chaque terme soit de l'argent par mois. Le MCP headless déplace surtout le côté « heures économisées » sur les tâches répétitives et multi-étapes de configuration et de données, le travail qui signifiait une douzaine de clics sur plusieurs écrans, parce qu'il supprime la taxe d'interface : le travail qui n'avait jamais besoin d'écran tourne désormais en appel direct. Le même calcul vaut pour les agents vocaux IA sur une intégration téléphonique : modélisez les minutes déviées et les heures libérées des conseillers par le volume, la durée de traitement et les Flex Credits consommés par chaque interaction automatisée.

Où se place un PDO Salesforce ou un partenaire Agentforce ?

Adopter le MCP headless sans risque est autant un projet de gouvernance qu'un projet de construction. Un PDO Salesforce (Product Development Outsourcer) construit des apps commerciales sur la plateforme, les package correctement et les accompagne à travers la revue de sécurité AppExchange. Ces compétences s'appliquent directement au MCP headless : un ISV qui expose son produit sous forme d'outils MCP a besoin de quelqu'un capable de concevoir la surface d'outils, d'imposer le modèle d'utilisateur en cours et de passer la revue du premier coup. Un partenaire Agentforce fait de même pour un agent interne, en câblant les quatre outils à une vraie logique métier plutôt qu'à une démo. Au moment d'évaluer l'un ou l'autre, pesez trois choses :

1. Conçoivent-ils le modèle de permissions d'abord, ou l'ajoutent-ils après que la démo fonctionne ?
2. Peuvent-ils montrer un vrai travail d'agent headless sur une org gouvernée, pas des slides ?
3. Prennent-ils en charge l'intégration, le packaging et la revue de sécurité, ou vous lâchent-ils à mi-chemin ?

Cette combinaison de profondeur plateforme et de discipline de gouvernance est ce que Tekunda apporte aux projets headless, et nous la faisons tourner en production aujourd'hui, pas sur une feuille de route. Notre équipe MCP headless trace le chemin sûr pour votre org, de la surface d'outils à la revue de sécurité.

FAQ

Le MCP headless est-il la même chose qu'Agentforce ?

Non. Agentforce est le produit d'agents de Salesforce ; le MCP headless (Headless 360) est la surface d'outils qu'un agent appelle. Vous pouvez la piloter depuis Agentforce ou depuis un client externe comme Claude ou Cursor.

Le Headless 360 MCP Server est-il disponible en général ?

Non. Il est entré en bêta en juillet 2026, avec une centaine de compétences au lancement, sur des serveurs MCP hébergés devenus disponibles en général en avril 2026. Pilotez avant d'y confier des flux critiques.

Un agent utilisant le MCP headless contourne-t-il la sécurité Salesforce ?

Non. Il s'exécute en tant qu'utilisateur authentifié avec le scope mcp_api, et CRUD, sécurité au niveau des champs, règles de partage et permission sets sont tous imposés. Donnez à l'agent un utilisateur au moindre privilège.

Faut-il une licence Agentforce pour utiliser le MCP headless ?

L'accès MCP hébergé de base exige Enterprise Edition ou supérieur et n'est pas conditionné à une licence Agentforce, même si les conditions de facturation peuvent changer avec préavis.

Faut-il une revue de sécurité séparée pour une app connectée à MCP ?

Les packages AppExchange passent toujours par la revue de sécurité standard. MCP n'ajoute aucun processus séparé, mais élargit la surface, donc CRUD, FLS, partage et accès au moindre privilège doivent tenir à chaque point d'entrée.

Faut-il du code pour l'adopter ?

Pas pour un usage de base. Vous activez le serveur MCP hébergé dans Setup et connectez un client compatible MCP. La gouvernance en production est là où la planification paie.

Par où commencer ?

Activez d'abord un serveur en lecture seule, connectez-le à un seul client, vérifiez que le modèle de permissions se comporte comme prévu, puis élargissez le périmètre. Faites appel à un partenaire si la gouvernance n'est pas la compétence centrale de votre équipe.

Le MCP headless est la voie par laquelle le travail piloté par des agents atteint Salesforce, et il est déjà en bêta. Si vous voulez que cette surface avance vite sans élargir votre surface d'attaque, c'est le travail de construction et de sécurité que Tekunda fait chaque jour. Réservez un court appel de cadrage.