L’annonce du support MCP (Model Context Protocol) dans Agentforce 3, couplée à l’expansion d’AgentExchange, est présentée par Salesforce comme une ouverture vers l’interopérabilité. Pour les ESN françaises, c’est autre chose : une opportunité de repositionnement commercial qui n’existait pas il y a six mois.
La question d’Agentforce souveraineté n’est pas nouvelle sur le marché français. Ce qui change avec MCP, c’est qu’elle devient actionnable.
Ce que MCP change réellement dans l’architecture Agentforce
MCP est un protocole ouvert qui permet à un agent Agentforce de consommer des outils et des contextes exposés par des serveurs tiers, sans que ces serveurs soient hébergés chez Salesforce. Concrètement : un agent peut appeler un serveur MCP qui tourne sur l’infrastructure d’un client, dans un datacenter souverain, ou sur un cloud européen certifié HDS.
Ce n’est pas une intégration API classique. La différence architecturale est significative. Avec les External Services ou les Apex callouts traditionnels, Agentforce orchestre depuis Hyperforce et appelle des endpoints externes. Avec MCP, le serveur de contexte peut être co-localisé avec les données sensibles, et l’agent ne reçoit que ce que le serveur MCP décide d’exposer. Le contrôle du flux de données s’inverse partiellement.
Pour une DSI française qui gère des données de santé, des données financières soumises à la directive DORA, ou simplement des données personnelles sous RGPD avec des clauses contractuelles strictes, cette distinction n’est pas anodine. L’agent Agentforce n’a plus besoin d’accéder directement aux systèmes sources. Il consomme une surface d’exposition contrôlée, définie et auditée par l’ESN ou le client.
L’Atlas Reasoning Engine continue de tourner chez Salesforce. C’est un point non négociable dans l’architecture actuelle. Mais la couche de contexte, elle, peut être souveraine.
Le modèle de monétisation que les ESN françaises ratent
La plupart des ESN abordent Agentforce 3 comme elles ont abordé les versions précédentes : en vendant des jours d’implémentation sur des Topics, des Actions et des Prompt Builder templates. C’est une position de sous-traitance, pas une position de valeur.
MCP ouvre un modèle différent. Une ESN peut construire et opérer des serveurs MCP spécialisés par secteur, puis les distribuer via AgentExchange ou en licence directe. Ce n’est plus de l’intégration ponctuelle, c’est un actif logiciel récurrent.
Prenons un exemple concret. Une ESN spécialisée dans le secteur bancaire français connaît les structures de données des principaux core banking systems utilisés en France. Elle peut construire un serveur MCP qui expose, de façon normalisée et auditée, les contextes nécessaires aux agents Agentforce : soldes, historiques de transactions, scoring interne, alertes réglementaires. Ce serveur MCP tourne dans l’infrastructure du client ou dans un cloud souverain. L’ESN le maintient, le fait évoluer, et le facture en SaaS.
Le client bénéficie d’une intégration Agentforce sans exposer ses données brutes à Hyperforce. L’ESN sort du cycle projet-par-projet et entre dans un modèle de revenus récurrents. AgentExchange devient un canal de distribution, pas seulement une vitrine.
Dans les organisations avec des contraintes de localisation des données fortes, ce modèle est souvent le seul qui passe les comités de sécurité. Les ESN qui l’ont compris avant les autres auront un avantage de 12 à 18 mois sur leurs concurrentes.
Les trois erreurs d’architecture à éviter
Confondre MCP et API gateway. Un serveur MCP n’est pas un proxy API avec un habillage protocolaire. Il doit implémenter la sémantique MCP correctement : gestion des ressources, des outils, des prompts exposés, et du cycle de vie de la session. Une implémentation bâclée produit un serveur qui fonctionne en démo mais qui échoue sous charge ou lors de sessions longues avec l’Atlas Reasoning Engine. La spécification MCP est précise sur la gestion des états de contexte. Respectez-la.
Négliger la gouvernance des données exposées. Le serveur MCP contrôle ce que l’agent voit. C’est un avantage, mais c’est aussi une responsabilité. En pratique, les ESN qui construisent ces serveurs doivent implémenter une couche de filtrage basée sur les rôles Salesforce et les politiques RGPD du client. Un agent qui a accès à un Topic “Service Client” ne devrait pas, via le serveur MCP, pouvoir remonter des données médicales ou des informations salariales. La granularité du contrôle d’accès au niveau du serveur MCP est souvent sous-estimée lors des phases de conception.
Sous-estimer la complexité opérationnelle. Opérer un serveur MCP en production, c’est opérer un service. Disponibilité, latence, versioning du protocole, compatibilité avec les mises à jour Agentforce. Les ESN habituées à livrer des projets et à passer la main aux équipes internes du client doivent développer une capacité d’opération managée. C’est un changement de modèle opérationnel, pas seulement technique. Les DSI des ETI françaises n’ont généralement pas les équipes pour opérer ces serveurs elles-mêmes. C’est précisément là que l’ESN crée de la valeur durable.
Pour aller plus loin sur les patterns d’intégration entre Agentforce et les systèmes externes, l’article sur l’implémentation Agentforce pour les entreprises détaille les choix d’architecture qui conditionnent la scalabilité.
Comment structurer une offre MCP souveraine
L’architecture qui fonctionne dans ce contexte s’articule en trois couches.
La première couche est le serveur MCP lui-même, hébergé dans l’infrastructure souveraine choisie par le client. OVHcloud, Scaleway, ou l’infrastructure on-premise du client selon les contraintes. Ce serveur implémente les connecteurs vers les systèmes sources (ERP, core banking, DPI hospitalier) et expose des outils MCP typés et documentés.
La deuxième couche est la couche de gouvernance des données. Elle implémente les règles de filtrage, d’anonymisation et d’audit. Chaque appel du serveur MCP est loggué avec l’identité de l’agent appelant, le Topic Agentforce concerné, et les données effectivement retournées. Cette couche est ce qui permet de répondre aux exigences RGPD et aux audits de conformité.
La troisième couche est l’intégration Agentforce côté Salesforce : les Actions qui pointent vers le serveur MCP, les Instructions qui définissent comment l’agent utilise les outils exposés, et les Data Graphs qui peuvent être enrichis par les Calculated Insights remontés depuis le serveur MCP via Data Cloud si l’architecture l’inclut.
Ce découplage est la clé. L’ESN peut faire évoluer le serveur MCP indépendamment des cycles de release Salesforce. Elle peut tester de nouveaux connecteurs sans toucher à la configuration Agentforce. Et elle peut proposer le même serveur MCP à plusieurs clients Salesforce, ce qui est le fondement du modèle SaaS.
Pour les organisations qui évaluent Data Cloud comme couche de médiation entre les systèmes sources et Agentforce, l’article sur l’architecture Data Cloud présente les patterns de Data Streams et de Data Graphs qui s’articulent avec cette approche.
Ce que les DSI doivent exiger de leurs ESN
La question pratique pour une DSI qui évalue une offre Agentforce avec MCP est simple : où tournent les données de contexte pendant l’inférence ?
Si l’ESN ne peut pas répondre précisément à cette question, l’architecture n’est pas souveraine, quelle que soit la rhétorique commerciale. La réponse acceptable est : “Les données de contexte sont traitées sur notre serveur MCP, hébergé ici, avec ces garanties contractuelles. L’Atlas Reasoning Engine chez Salesforce reçoit uniquement les éléments que notre serveur MCP décide d’exposer, selon ces règles de filtrage.”
Les DSI des secteurs régulés (santé, finance, assurance) doivent également exiger une cartographie des flux de données entre le serveur MCP et Hyperforce. Cette cartographie est nécessaire pour les analyses d’impact RGPD (AIPD) et pour les audits de conformité DORA dans le secteur financier.
Enfin, le contrat avec l’ESN doit distinguer clairement la prestation d’implémentation initiale de l’opération récurrente du serveur MCP. Confondre les deux dans un contrat de projet classique expose le client à une dépendance non contractualisée.
Points Clés
- MCP dans Agentforce 3 permet de co-localiser la couche de contexte agent dans une infrastructure souveraine, sans modifier l’Atlas Reasoning Engine qui reste chez Salesforce.
- Les ESN françaises peuvent construire des serveurs MCP sectoriels (banque, santé, industrie) et les distribuer via AgentExchange ou en licence directe, créant un modèle de revenus récurrents distinct des projets d’implémentation.
- Un serveur MCP souverain doit implémenter une couche de gouvernance des données avec filtrage par rôle, anonymisation et audit complet des appels, pour satisfaire les exigences RGPD et les audits sectoriels.
- La question de qualification pour une DSI est précise : où tournent les données de contexte pendant l’inférence ? Une réponse vague invalide toute prétention de souveraineté.
- Les ETI françaises sans équipes internes pour opérer ces serveurs représentent le segment cible naturel pour une offre MCP managée par une ESN spécialisée.
