Salesforce headless et MCP : exécuter les actions CRM depuis un seul hub agentique

Réponse courte : Salesforce headless signifie que les données, la logique et les workflows de la plateforme sont appelables sans l'interface Lightning, et un serveur MCP est la façon standard d'exposer ces appels à un client IA. Ensemble, ils donnent une surface d'action unique : un agent, un fil Slack ou votre propre front end peut exécuter une action CRM et une action ERP dans la même étape. Salesforce a officialisé cela au TrailblazerDX du 15 avril 2026 avec Headless 360, et ses serveurs MCP hébergés sont devenus généralement disponibles le même mois pour Enterprise Edition et au-delà.

Que veut dire Salesforce headless aujourd'hui ?

Que le navigateur devient optionnel. Chaque capacité est joignable comme API, outil MCP ou commande CLI, donc le système de référence peut être piloté par autre chose qu'une page Lightning. C'était exactement le cadrage du TrailblazerDX 2026, avec plus de 60 nouveaux outils MCP et une couche d'expérience qui restitue des composants dans Slack, Teams, le mobile et les clients compatibles MCP.

Deux précisions, car les deux se confondent souvent :

• Headless ne veut pas dire sans interface. Cela veut dire que l'interface est un choix et non une dépendance. La plupart de nos projets headless ont encore un écran, simplement ce n'est pas l'org.
• Headless ne veut pas dire tout remplacer. Vos objets, flows, règles de validation et modèle de partage restent exactement où ils sont. Ce qui change, c'est qui a le droit de les appeler.

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

Un serveur MCP publie une liste d'outils qu'un client IA peut appeler, avec des entrées typées et un modèle de permissions derrière. En pratique, vous en rencontrerez trois types :

• Les serveurs MCP hébergés par Salesforce, généralement disponibles depuis avril 2026 pour Enterprise Edition et au-delà, qui exposent les données de l'org, les Flows, les actions invocables Apex, les méthodes AuraEnabled et les requêtes nommées.
• Le serveur MCP Salesforce DX, destiné aux flux de développement comme le déploiement de métadonnées et l'exécution de tests Apex.
• Votre propre serveur MCP, où se trouve le travail intéressant, car c'est le seul capable de couvrir Salesforce et tout ce qui l'entoure.

Le modèle de sécurité mérite d'être retenu. Le serveur hébergé authentifie par utilisateur avec OAuth 2.0 et PKCE, et l'agent agit dans les permissions de cet utilisateur, avec CRUD, sécurité au niveau des champs et règles de partage toujours appliquées. Un agent n'est pas un superutilisateur.

Pourquoi la valeur est-elle une surface d'action unique plutôt qu'une meilleure interface ?

C'est ici que se situe le manque dans presque tout ce qui s'écrit sur le sujet. L'essentiel décrit Salesforce exposant Salesforce. C'est utile, et ce n'est pas là que la douleur se trouve.

Le travail opérationnel réel ne reste pas dans un seul système. "Valider cette exception de crédit, libérer la commande et prévenir le client" fait trois systèmes et une seule intention. Aujourd'hui, cette intention est exécutée par une personne qui bascule entre le CRM, l'ERP et une console de téléphonie, et qui traduit à la main. Chacune de ces traductions est une occasion de se tromper.

Une surface d'action unique réduit ce va-et-vient à une seule action appelable :

• L'agent, ou le front end, appelle un seul outil.
• L'outil orchestre l'écriture CRM, l'appel ERP et la notification.
• Le contrôle des permissions se fait une fois, à un endroit auditable.
• Une défaillance sur un maillon est une seule défaillance, pas un processus à moitié fait dont personne n'est responsable.

Une implémentation headless qui n'expose que le CRM a déplacé les boutons. Celle qui expose des intentions a supprimé la chaise pivotante.

À quoi ressemble un hub d'actions couvrant le CRM et les systèmes voisins ?

1. Salesforce reste le système de référence. Objets, partage et validation restent intacts.
2. Une couche MCP publie des intentions, pas des tables. release_order, pas update_order_record.
3. Des connecteurs se placent derrière chaque intention : ERP, finance, téléphonie, planification, objets connectés. Nous le faisons sur plus de 70 systèmes d'entreprise.
4. Un seul modèle d'identité. Les permissions de l'appelant décident de ce que fait l'outil, dans chaque système touché.
5. Les clients sont interchangeables. Claude, Cursor, Agentforce, une application Slack ou votre propre front end appellent les mêmes outils.
6. Chaque appel est enregistré comme événement métier, pas seulement comme un appel d'API.

Tekunda construit cette forme depuis avant qu'elle porte un nom de produit, et à notre connaissance nous sommes le premier cabinet à livrer du CRM headless avec des hubs d'actions MCP en production.

Qu'est-ce que la plupart des équipes ratent ?

• Publier des objets au lieu d'actions. Un outil par objet donne à un agent mille façons de faire des dégâts. Un outil par intention métier lui en donne une bonne.
• Négliger l'idempotence. Les agents réessaient. Si release_order n'est pas idempotent, un réessai expédie la commande deux fois.
• Laisser l'agent porter la permission. Exécutez au nom de l'utilisateur, pas d'un compte d'intégration qui peut tout faire.
• Aucune validation sur les actions irréversibles. Lisez librement. Écrivez avec un contrôle sur tout ce qui est financier ou visible du client.
• Traiter cela comme un projet d'intégration. C'est un projet de conception d'interface qui se trouve nécessiter de l'intégration.

Par où commencer ?

1. Choisissez un workflow qui traverse déjà deux systèmes et agace quelqu'un chaque semaine.
2. Écrivez les trois ou quatre intentions qu'il contient, sous forme de verbes.
3. Implémentez-les en outils MCP, avec entrées typées, authentification par utilisateur et une ligne d'audit chacune.
4. Branchez-y deux clients différents, par exemple un agent et une action Slack, pour prouver que la surface est réellement partagée.
5. Élargissez le catalogue seulement ensuite.

FAQ

Salesforce headless veut-il dire renoncer à l'interface Lightning ?

Non. Cela rend l'interface optionnelle. La plupart des implémentations gardent Lightning pour ceux qui l'apprécient et ajoutent d'autres points d'entrée pour les autres.

Le serveur MCP hébergé par Salesforce suffit-il à lui seul ?

Il suffit pour laisser un client IA travailler dans votre org. Il ne suffit pas pour des actions qui couvrent l'org et d'autres systèmes, et c'est là qu'intervient une couche MCP sur mesure.

Un agent doté d'un accès MCP est-il un risque de sécurité ?

Il porte le risque de l'identité sous laquelle il s'exécute. Avec OAuth par utilisateur, CRUD, sécurité au niveau des champs et règles de partage continuent de s'appliquer : la réponse est de cadrer l'utilisateur, pas de faire confiance à l'agent.

Faut-il Agentforce pour faire cela ?

Non. MCP est un standard ouvert, donc Claude, Cursor et vos propres applications peuvent appeler les mêmes outils. Agentforce est un client parmi d'autres.

Tekunda construit des implémentations Salesforce headless et des hubs d'actions MCP couvrant CRM, ERP, téléphonie et objets connectés. Si votre équipe passe d'onglet en onglet pour un processus qui devrait être une seule action, c'est le workflow par lequel commencer.