MCP Server SFMC vs QAiry : pourquoi l'architecture metadata est plus sûre

Avec la release Summer '26, Salesforce Marketing Cloud Engagement (SFMC Engagement) ouvre l'accès aux MCP Servers — le protocole Model Context Protocol standardisé par Anthropic qui permet à des assistants IA comme Claude ou Gemini de piloter SFMC en langage naturel. Une avancée stratégique pour l'automatisation et l'exploration de données, mais qui pose des questions concrètes côté sécurité et conformité. Dans cet article, nous comparons l'architecture MCP Server à celle de QAiry, l'assistant IA natif AppExchange dédié à SFMC Engagement, pour comprendre pourquoi une approche metadata-only réduit nettement la surface d'exposition pour les équipes marketing soumises au RGPD ou à des contraintes de gouvernance fortes.

Ce que change réellement le MCP Server pour SFMC Engagement

En quelques étapes (création d'un Installed Package, configuration d'une API Integration de type Public App, génération d'un Client ID et d'un Tenant ID), un client comme Gemini CLI ou Claude Code peut se connecter à l'endpoint Salesforce mai-mce-mcp-cdp1 (US ou EU) et exécuter des outils : création de Data Extensions, identification de journeys, lecture d'emails, manipulation d'automations.

Le flux ressemble à :

Utilisateur ──prompt──> Claude / Gemini ──MCP──> Salesforce MCP Server


APIs SFMC Engagement


Data Extensions, Journeys,Subscribers, Activities, etc.                          

Le bénéfice est immédiat : un opérateur SFMC pilote la plateforme en langage naturel et automatise des tâches répétitives. Mais ce gain de productivité s'accompagne d'un changement structurel de la surface d'exposition qui mérite d'être analysé pas à pas.

Trois angles morts à regarder en face

1. Où passent réellement vos données ?

Avec le MCP Server, l'IA externe (Claude, Gemini) reçoit les réponses des API SFMC pour pouvoir agir dessus. Selon les outils utilisés (par exemple retrieveSubscribers, queryDataExtension), ces réponses peuvent contenir des données personnelles : adresses email, identifiants, attributs profil, contenu de campagnes. Ces données quittent l'environnement Marketing Cloud pour être traitées par un fournisseur LLM tiers — généralement aux États-Unis (Anthropic, Google), ce qui réactive immédiatement les questions Schrems II et le risque de transfert de données personnelles hors UE.

QAiry, à l'inverse, fonctionne selon un principe affirmé sur sa page sécurité et confidentialité : l'IA ne voit que des métadonnées — noms de Data Extensions, noms de champs, types de champs. Aucun enregistrement subscriber n'est exporté. Le SQL généré s'exécute à l'intérieur de SFMC via les Query Activities. La donnée client ne quitte jamais l'environnement Salesforce.

La différence n'est pas philosophique mais architecturale : avec le MCP Server, l'IA est en aval des données ; avec QAiry, l'IA reste en amont. Cette inversion change tout pour les équipes conformité.

2. Qui a fait quoi, et comment le prouver ?

L'auditabilité d'une action déclenchée via MCP Server suppose de croiser au moins trois journaux : le journal de prompts côté Claude ou Gemini (souvent non rétention), les logs OAuth de l'Installed Package, et les logs d'API côté SFMC. Le lien entre l'intention exprimée en langage naturel et l'action exécutée n'est pas natif ; il faut le reconstruire.

QAiry trace les prompts utilisateur dans son propre périmètre, à des fins explicites de traçabilité. L'authentification se fait par SSO SFMC, sans identifiants séparés à provisionner ou révoquer. Le chemin « utilisateur SFMC → prompt → SQL → exécution dans SFMC » reste linéaire et auditable de bout en bout.

3. À quoi l'IA a-t-elle vraiment droit ?

Le tutoriel  souligne avec raison : « Do not grant more permissions to AI than necessary. » C'est un excellent réflexe, mais il repose entièrement sur la rigueur de la personne qui configure l'Installed Package. Les scopes SFMC restent assez gros : Data Extensions Read/Write, Automations Read/Write, etc. Une fois accordée la permission d'écrire, l'IA peut techniquement créer ou modifier n'importe quel objet de cette catégorie.

QAiry expose un modèle d'autorisations plus granulaire : les scopes peuvent être adaptés par déploiement — par exemple autoriser la création de Query Activities tout en désactivant la création d'Automations. Pour une équipe gouvernance, c'est la différence entre une clé qui ouvre une porte et un trousseau différencié par cas d'usage.

La validation indépendante : AppExchange ou rien

Le MCP Server Salesforce est une fonctionnalité native de SFMC ; sa sécurité côté serveur est portée par Salesforce. Mais le maillon faible n'est jamais le serveur — c'est l'écosystème côté client. Claude Code, Gemini CLI, les plugins MCP tiers, l'environnement de l'utilisateur (poste personnel, BYOD, partages d'écran) ne font l'objet d'aucune revue de sécurité Salesforce.

QAiry est listée sur l'AppExchange. Cela suppose d'avoir passé la Salesforce Security Review : scans automatisés OWASP, tests d'intrusion manuels (injection SQL, XSS, faiblesses d'authentification), et re-vérifications périodiques pour rester listée. Ce n'est pas un label marketing : c'est une obligation continue, contrôlée par un tiers indépendant. Pour un service achats ou une DSI, c'est un signal concret de maturité sécurité.

Hébergement et résidence des données

L'endpoint MCP Server existe en deux variantes (US sfdc-yfeipo et EU sfdc-yzvdd4) mais la résidence des données traitées par l'IA dépend in fine du fournisseur LLM. Si vous utilisez Claude via l'API Anthropic depuis l'UE, vos prompts et tool outputs transitent par l'infrastructure Anthropic aux États-Unis. Idem pour Gemini.

QAiry est hébergé par défaut sur AWS Paris (eu-west-3), avec chiffrement en transit et au repos, et la possibilité de déploiements régionaux spécifiques. La donnée subscriber, elle, ne sort jamais de SFMC — donc même la question du transit hors UE ne se pose plus pour les enregistrements clients. Le calcul de conformité RGPD devient considérablement plus simple à documenter.

Risque opérationnel : quand l'IA hallucine sur votre prod

Un LLM peut se tromper. Le tutoriel  en donne déjà un exemple involontaire : lors de la création d'une Data Extension via Gemini, le champ EmailAddress est devenu required sans que l'utilisateur l'ait demandé. Sur un environnement de test, c'est anecdotique. Sur un environnement de production, un même type d'erreur sur une Automation de routage transactionnel peut bloquer des envois critiques.

Le MCP Server n'introduit pas de garde-fou métier : si l'IA appelle un outil d'écriture, l'écriture a lieu. QAiry réduit ce risque structurellement : l'IA ne propose pas d'opérations destructives sur des données client, elle génère du SQL qui s'exécute dans le bac à sable SFMC habituel, avec les mêmes garde-fous que ceux dont vous disposez aujourd'hui pour vos Query Activities.

Comment choisir selon votre contexte

Le MCP Server SFMC n'est pas « dangereux » ; c'est une brique puissante qui convient bien à certains contextes — équipes techniques avancées, environnements de sandbox, exploration de cas d'usage IA. QAiry vise un autre besoin : rendre l'IA exploitable en production par des équipes marketing, dans le respect d'une gouvernance enterprise.

Un cadre de décision rapide : si vous traitez des données personnelles soumises au RGPD, si votre DPO exige une cartographie complète des transferts hors UE, ou si vos audits internes demandent des preuves de revue de sécurité tierce, l'architecture metadata-only de QAiry vous donnera un dossier de conformité bien plus simple à défendre que le combo « MCP Server + LLM externe ».

À retenir

1. MCP Server expose la donnée subscriber à un LLM tiers. Les réponses d'API SFMC traversent Claude ou Gemini, ce qui réintroduit la question Schrems II.

2. QAiry fonctionne en metadata-only. L'IA ne voit que les noms et types de champs ; le SQL s'exécute dans SFMC, la donnée client reste à l'intérieur.

3. AppExchange = validation indépendante. QAiry a passé la Salesforce Security Review et la maintient. Le MCP Server, lui, ne couvre pas la chaîne côté client.

4. Scopes granulaires vs scopes larges. QAiry adapte les permissions par déploiement ; les scopes OAuth d'un Installed Package restent volontiers globaux.

5. Hébergement EU par défaut. AWS Paris pour QAiry vs résidence dépendante du fournisseur LLM côté MCP Server.

Vous évaluez l'arrivée du MCP Server dans SFMC et souhaitez positionner QAiry dans votre roadmap IA avec un dossier de conformité solide ? Échangeons sur votre contexte. CGC-Agency accompagne les équipes marketing francophones sur l'évaluation, le déploiement et la gouvernance d'assistants IA pour Salesforce Marketing Cloud.

A voir: