Salesforce a lancé un serveur MCP de première partie pour Marketing Cloud Engagement (MCE) en mai 2026, et LinkedIn en a rapidement perdu la tête. Un publication sur deux est une démonstration enflammée d’un agent qui bâtit un parcours à partir d’une invite d’une seule ligne. Alors, avant d’en connecter un à votre instance de production : holà, minute papillon. La technologie est réellement utile et vaut la peine d’être adoptée. Le but de cet article n’est pas de dire « ne l’utilisez pas ». Le but est de la comprendre, puis de l’utiliser intelligemment, parce que SFMC punit les erreurs d’une manière que le CRM de base ne fait pas.
Le cadrage dans le matériel de lancement propre à Salesforce est tout à fait exact : un serveur MCP est un pont, pas un cerveau. Il traduit l’intention d’un assistant IA en appels API MCE, et l’aperçu officiel est d’une franchise admirable : les assistants IA peuvent produire des résultats inexacts ou préjudiciables, et vous êtes responsable des résultats. Cette honnêteté mérite des garde-fous à la hauteur.
Cet article s’adresse à deux publics. Les architectes doivent comprendre pourquoi SFMC est un endroit particulièrement impitoyable où pointer un agent autonome, et quels contrôles le contiennent réellement. Les marketeurs doivent savoir quels garde-fous ils possèdent personnellement au quotidien. La version courte : l’histoire de la prévention de Salesforce est raisonnable, son histoire d’attribution dans SFMC est faible, et le modèle de portée possède une porte dérobée dont la plupart des commentaires de lancement n’ont pas parlé.
Pourquoi les enjeux sont plus élevés dans SFMC que dans le CRM de base
Une mauvaise écriture dans Sales Cloud est généralement récupérable; on corrige l’enregistrement. SFMC ne fonctionne pas de cette façon. Un envoi est irréversible : une fois qu’un courriel part, il n’y a pas d’annulation, pas de retour en arrière, pas de rappel. Une mauvaise requête SQL contre une extension de données de plusieurs millions de lignes écrase silencieusement. Les changements d’état d’abonnement et de consentement entraînent une exposition à la LCAP et au CAN-SPAM, pas seulement un risque de qualité des données. Et dans une instance multi-unités d’affaires (BU), le rayon d’impact d’une seule erreur s’étend à chaque BU que l’identité en cours d’exécution peut atteindre.
Un agent est rapide, infatigable et ne comprend pas les conséquences. Cette combinaison est la raison entière pour laquelle les garde-fous ne sont pas une friction optionnelle ici. Ils sont ce qui se dresse entre vous et un envoi irréversible à deux millions de vraies personnes.
Les garde-fous que Salesforce vous donne, et leurs limites
- Intersection de portées via l’OAuth du package installé. Le serveur MCP s’authentifie en tant que package installé, et les permissions effectives de l’agent sont l’intersection des portées du package et de celles de l’utilisateur. Si le package n’a pas de portée d’envoi, l’agent ne peut pas envoyer via l’API MCP. C’est un contrôle réel, et c’est la bonne fondation.
- Annotations d’opérations destructives. Salesforce signale les outils destructifs (envois, suppressions) afin qu’un modèle bien élevé puisse les faire ressortir avant de les exécuter. Utile, mais à titre indicatif. Cela repose sur le fait que le modèle choisisse de faire une pause.
- « Prévisualiser avant d’exécuter ». Salesforce recommande de demander à l’assistant ce qu’il va changer, combien d’enregistrements sont affectés, et de montrer le SQL en premier. Également à titre indicatif, et ne vaut que ce que vaut l’humain qui le lit.
Le modèle à travers ces trois éléments : la prévention à la porte d’entrée est solide; tout ce qui se trouve en aval dépend du bon comportement du modèle et de l’humain. C’est là que le reste de ces garde-fous entre en jeu.
Un cadre de garde-fous pratique
Contrôles de la plateforme (la couche de l’architecte)
Découpez les packages par tâche; ne bâtissez jamais un package unique « omnipotent ». Un seul package avec une portée large est l’erreur la plus facile à commettre et la plus difficile à annuler. Créez plutôt des packages aux portées restreintes, un par fonction, et décidez délibérément de l’emplacement de chacun. Le modèle qui contient le plus de risques : bâtissez tout dans le sandbox, donnez à la production un package en lecture seule uniquement, et promouvez tout ce qui doit s’exécuter en production manuellement via le Gestionnaire de packages afin qu’un humain se trouve au milieu de chaque déploiement.
La règle sous le tableau : la production porte la lecture seule, point final. Tout ce qui crée, met à jour ou exécute est bâti et testé dans le sandbox, puis un humain le déploie en production via le Gestionnaire de packages. Cette promotion manuelle est votre intermédiaire humain : l’agent peut proposer et assembler, mais une personne décide de ce qui atteint réellement l’instance en direct.
Verrouillez qui peut créer des packages. C’est là que la plupart des instances échouent silencieusement. La plupart des BU de SFMC ne maintiennent jamais correctement les rôles, de sorte que chaque développeur finit par être administrateur, ce qui signifie que chaque développeur peut créer des packages installés et connecter un serveur MCP avec les portées qu’il souhaite. Cela ne devrait pas être le cas. Il devrait y avoir un seul administrateur. Les développeurs ne devraient pas du tout être en mesure de créer des packages installés. L’hygiène des permissions n’est pas de la bureaucratie ici; c’est le contrôle sur lequel tout le reste s’appuie.
Ne partagez pas les identifiants à l’échelle de l’équipe. L’ID client et le secret d’un package installé sont les clés de tout ce que ce package peut faire. Si cinq développeurs partagent les identifiants d’un seul package, vous avez détruit l’attribution avant même qu’une seule action ne s’exécute; aucun journal ne peut vous dire quel humain a soumis quelle invite. Traitez les identifiants MCP comme vous le feriez pour n’importe quel secret de production : à portée limitée, minimaux et non collés dans un document partagé.
Comprenez qu’il n’y a pas d’arrêt ferme sur l’envoi. C’est la vérité inconfortable, et cela vaut la peine d’être précis parce qu’il est facile de se tromper. Le sandbox et la production dans SFMC partagent généralement le même compte d’envoi (SAP) et la même infrastructure d’envoi. Un sandbox dans SFMC n’est pas un environnement isolé de la même manière qu’un sandbox Sales Cloud l’est; il n’y a pas de niveau de courrier hors production séparé. Un courriel déclenché à partir d’une BU « sandbox » sort pour de vrai, vers de vraies boîtes de réception, sur la même réputation d’envoi. Vous ne pouvez donc pas garantir architecturalement qu’un envoi hors production n’atteindra pas une vraie personne.
Refuser la portée d’envoi à un package réduit les chances qu’un agent déclenche un envoi via l’API MCP, mais cela ne fait rien contre le contournement décrit ci-dessous et rien contre le SAP partagé. Les listes d’exclusion suppriment des adresses spécifiques mais n’arrêtent pas l’envoi lui-même. Aucun de ces éléments n’est un filet de sécurité. Les seules choses qui limitent réellement le rayon d’impact sont opérationnelles : restreignez les audiences hors production aux données de test et d’amorce uniquement, et exigez une approbation humaine sur tout ce qui envoie. Vous ne pouvez pas contrôler l’infrastructure, vous devez donc contrôler l’audience et l’approbation.
Contrôles opérationnels (la couche de tout le monde)
Imposez l’intervention humaine sur chaque écriture, comme règle, pas comme espoir. La recommandation « prévisualiser avant d’exécuter » de Salesforce dépend de la décision du modèle de demander. Transformez cela en une instruction explicite : une règle ou un fichier de compétence qui exige que chaque écriture ou appel d’outil destructif fasse une pause pour une approbation humaine explicite avant l’exécution. C’est la couche que les marketeurs peuvent posséder directement, et c’est celle qui transforme « le modèle demande généralement » en « le modèle a pour instruction de ne jamais écrire sans une confirmation humaine ».
Soyez honnête sur ce que c’est : un contrôle, pas un mur. Une compétence peut être ignorée par un modèle ou retirée par un utilisateur déterminé. Et cela ne fonctionne que si l’humain comprend réellement ce qu’il approuve plutôt que de faire de l’approbation aveugle, ce qui importe énormément pour le contournement décrit ci-après.
Exigez les décomptes et le SQL avant que quoi que ce soit ne s’exécute. Pas d’écriture sans que l’agent ne déclare d’abord le nombre d’enregistrements et ne montre la requête exacte. Pas de boucles autonomes en production.
Le contournement qui brise « si le package ne peut pas écrire, l’agent ne peut pas écrire »
Voici la partie que les publications de lancement manquent, et c’est la chose la plus importante de cet article. Le modèle de portée régit ce que la session de l’API MCP peut faire directement. Il ne régit pas le code que l’agent écrit et qui est ensuite exécuté à l’intérieur du propre environnement d’exécution de SFMC.
Le contournement par contexte de script. Supposez qu’un package possède les portées de création et d’exécution d’automatisation, mais aucune portée d’élément ou de parcours. L’agent peut rédiger une activité de script contenant du SSJS qui crée un courriel, une page d’atterrissage ou un parcours via WSProxy, puis l’exécuter. Le script s’exécute dans l’environnement d’exécution de SFMC avec les privilèges de ce qui l’invoque, et non dans les portées déclarées du package MCP. Il en va de même pour une CloudPage publiée, qui s’exécute sous la portée de création d’éléments utilisée pour bâtir des pages d’atterrissage. Ainsi, « si le package ne peut pas écrire, l’agent ne peut pas écrire » est faux dès l’instant où l’agent possède la portée de création d’éléments ou de création et d’exécution d’automatisation. C’est un contournement complet, et il n’a pas besoin d’humain dans la boucle.
La question inter-BU. Les unités d’affaires ajoutent une complexité. Le WSProxy SSJS expose setClientId({“ID”: targetMID}), ce qui fait basculer le contexte d’exécution vers le MID d’une autre BU; à partir de là, un script peut exécuter Create, Update ou Delete contre ce MID. L’inquiétude est qu’un package dont la portée est limitée à une BU puisse pivoter vers une autre et y agir.
La plateforme applique la hiérarchie, et cela limite le risque. Le pivot est restreint par la portée de l’identité en cours d’exécution dans l’arbre des BU, et non par les portées déclarées du package. Une BU parente s’étend vers ses enfants par conception, de sorte que le code s’exécutant sous une identité parente ou Enterprise peut pivoter vers n’importe quel enfant en dessous d’elle. L’inverse ne fonctionne pas : le code s’exécutant dans une BU enfant ne peut pas pivoter vers le parent ni latéralement vers une BU sœur. La plateforme le refuse.
La traduction pratique est la ligne que chaque architecte doit internaliser : si le package installé MCP a accès à une BU parente, il peut atteindre chaque BU enfant en dessous d’elle, même si le package n’a jamais reçu de portée explicite pour ces BU enfants. Un package créé au niveau parent ou Enterprise étend effectivement la portée de l’agent à l’ensemble de l’arbre. Un package créé à la BU nécessaire la plus basse est contenu, parce que la plateforme ne le laissera pas monter. La solution est concrète : placez les packages MCP à la BU la plus basse de la hiérarchie, jamais au niveau Enterprise ou parent. Combinée à l’hygiène des rôles ci-dessus, la préoccupation inter-BU se ferme d’elle-même dans une large mesure, parce que Salesforce l’applique pour vous.
L’écart d’attribution
Rassurer en disant que le nom de l’humain apparaît dans le journal d’audit décrit la propagation d’identité du CRM de base. SFMC est différent. Le serveur MCP s’authentifie en tant qu’utilisateur API du package installé, de sorte que les actions déclenchées par API sont couramment attribuées à cette identité d’intégration, et non à l’individu qui a soumis l’invite à l’agent. Le journalisage de SFMC est également fragmenté : le journal d’audit doit être activé délibérément, sa rétention est limitée, et il doit être exporté via SFTP ou extraction de données pour conserver l’historique; les journaux d’audit de parcours vivent derrière une API distincte par parcours. Il n’y a pas de surface unique, complète et interrogable pour savoir « qui a fait quoi ».
Les contrôles compensatoires aident : planifiez des extractions du journal d’audit vers une extension de données ou un SFTP, interrogez les journaux d’audit de parcours et superposez une surveillance externe sur les automatisations et les envois. Mais le constat honnête est que SFMC vous donne des éléments d’analyse faibles après une erreur d’agent, ce qui est précisément la raison pour laquelle la prévention et l’intervention humaine comptent plus ici que dans le CRM.
L’essentiel
Le serveur MCP est un outil utile, et Salesforce a bâti des contrôles de porte d’entrée raisonnables. Utilisez-le. Comprenez simplement ce qu’il protège et ne protège pas. L’intersection des portées ne protège qu’une seule porte : le code conçu par l’agent qui s’exécute dans le propre environnement d’exécution de SFMC s’exécute en dehors des portées déclarées du package, de sorte que « si le package ne peut pas écrire, l’agent ne peut pas écrire » est faux dès l’instant où l’agent peut créer et exécuter des automatisations ou bâtir des CloudPages. L’isolation des BU tient le coup, de sorte qu’un package placé bas dans la hiérarchie ne peut pas monter; le risque est de créer des packages au niveau parent ou Enterprise. Et parce que le sandbox et la production partagent la même infrastructure d’envoi, il n’y a pas d’arrêt de la plateforme sur un envoi réel accidentel, ce qui fait reposer tout le poids sur le contrôle de l’audience et la règle d’intervention humaine. L’agent ne comprendra jamais qu’un envoi est pour toujours. Vos garde-fous le doivent. Minute papillon, puis bâtissez quelque chose de bon.
