Claudeforce : que peut réellement voir et modifier Claude dans Salesforce ?

Salesforce et Anthropic viennent d’annoncer Claudeforce, un partenariat qui doit permettre de rapprocher Claude des données, des processus et des actions disponibles dans Salesforce.

Le premier produit issu de ce partenariat, Salesforce in Claude, prend la forme d’un plugin avec 37 compétences commerciales déjà préparées. Depuis Claude, un commercial pourra par exemple analyser son pipeline, préparer un rendez-vous, examiner la santé d’une opportunité ou mettre à jour certaines informations dans Salesforce.

L’intérêt est qu’une partie du travail réalisé aujourd’hui dans l’interface du CRM peut directement passer par la conversation.

Mais cette nouvelle façon d’accéder à Salesforce pose immédiatement une question : si Claude peut consulter et modifier le CRM, jusqu’où peut-il réellement aller ?

Peut-il accéder à toutes les données de l’entreprise ? Voir des informations normalement masquées à l’utilisateur ? Modifier un enregistrement en contournant une règle Salesforce ?

Sur ce point, l’architecture annoncée par Salesforce apporte une réponse assez claire : Claude ne reçoit pas un accès général au CRM. Il agit avec les droits de l’utilisateur qui l’utilise.

Et cette nuance est essentielle pour comprendre Claudeforce.

Claude n’entre pas dans Salesforce avec un passe-partout

La connexion entre Claude et Salesforce ne fonctionne pas comme un compte technique auquel l’entreprise donnerait accès à une grande partie du CRM.

Les appels réalisés vers Salesforce sont associés à l’utilisateur authentifié. Salesforce continue ensuite d’appliquer ses propres règles pour déterminer ce que cette personne est autorisée à consulter ou à modifier.

Concrètement, si un commercial ne peut voir que les opportunités de son équipe dans Salesforce, passer par Claude ne doit pas lui permettre d’accéder à celles d’une autre entité.

Même logique pour les champs.

Un utilisateur peut avoir accès à une fiche client sans avoir le droit de consulter certaines informations sensibles qu’elle contient. Cette restriction continue de s’appliquer lorsque Claude interroge Salesforce.

Salesforce confirme que les permissions sur les objets, les droits au niveau des champs, les règles de partage, les profils et les Permission Sets continuent de s’appliquer aux opérations réalisées par l’intermédiaire de ses serveurs MCP.

Autrement dit, Claude ne décide pas de ce qu’un utilisateur est autorisé à voir. Salesforce continue de le décider.

Ce qui change, c’est la manière d’accéder à l’information

C’est là que le sujet devient plus intéressant qu’une simple question de permissions.

Un commercial pouvait déjà disposer de centaines de comptes, d’opportunités, de tâches et d’activités dans Salesforce. Théoriquement, toutes ces informations lui étaient accessibles.

Mais avoir accès à une donnée ne signifie pas forcément qu’elle est facile à exploiter.

Pour préparer un rendez-vous, il peut aujourd’hui être nécessaire d’ouvrir le compte, parcourir les opportunités, retrouver les dernières activités, relire certains échanges et vérifier les prochaines étapes.

Salesforce in Claude change cette mécanique.

L’utilisateur peut simplement demander :

« Prépare-moi mon rendez-vous avec ce client. »

Claude peut alors rechercher les informations Salesforce auxquelles cet utilisateur a accès, les mettre en contexte et produire une synthèse.

Salesforce va même plus loin dans les usages annoncés. Le plugin peut exploiter le contexte du commercial provenant de Salesforce, mais aussi de Slack et des autres connecteurs disponibles dans Claude afin de générer des vues adaptées à son activité, avec ses comptes, son pipeline et ses données à jour.

Le périmètre d’accès de l’utilisateur n’est donc pas nécessairement plus large.

En revanche, l’effort nécessaire pour exploiter ce périmètre peut devenir beaucoup plus faible.

C’est une différence importante.

Consulter Salesforce depuis Claude est une chose. Le modifier en est une autre.

Salesforce in Claude n’est pas uniquement conçu pour répondre à des questions.

Parmi les usages annoncés, Claude pourra aussi agir sur Salesforce : mettre à jour un pipeline, enregistrer une activité ou déclencher certaines actions liées au travail commercial.

C’est précisément à ce moment que la gouvernance Salesforce devient importante.

Une demande faite dans Claude n’est pas transformée en modification directe et incontrôlée dans la base CRM.

Les actions passent par Salesforce avant d’être exécutées.

Salesforce peut donc continuer d’appliquer la logique déjà présente dans l’organisation : droits de modification, règles de validation, automatisations, processus d’approbation ou autres contrôles associés à l’action.

La documentation de Headless 360 est particulièrement claire sur ce point : les règles de validation, triggers et chaînes d’approbation continuent de s’exécuter, quel que soit le point d’entrée utilisé pour appeler Salesforce.

Prenons un exemple simple.

Un commercial termine un rendez-vous et indique à Claude :

« Le client souhaite avancer. Passe l’opportunité à l’étape suivante et fixe la prochaine action à vendredi. »

Claude peut comprendre la demande et préparer l’action.

Mais Salesforce reste derrière.

Si l’utilisateur n’a pas le droit de modifier cette opportunité, l’action ne doit pas pouvoir être exécutée.

Si une règle Salesforce impose qu’une information soit renseignée avant de passer à l’étape suivante, cette règle continue également de s’appliquer.

L’intérêt de Claudeforce n’est donc pas de contourner le fonctionnement du CRM.

C’est de permettre à Claude d’utiliser ce fonctionnement sans obliger l’utilisateur à passer par chaque écran qui le matérialise aujourd’hui.

Claude ne peut pas non plus tout faire simplement parce qu’il est connecté

C’est un autre point important.

Connecter Claude à Salesforce ne signifie pas que toutes les capacités de l’organisation deviennent immédiatement disponibles dans la conversation.

Salesforce in Claude démarre avec 37 compétences commerciales préconfigurées, développées conjointement par Salesforce et Anthropic. Elles couvrent notamment la préparation de rendez-vous, l’analyse des opportunités, la revue du pipeline, la planification de compte, la qualification de leads ou encore certains usages liés à l’hygiène du CRM.

Plus largement, cette approche s’inscrit dans la logique Headless 360 développée par Salesforce, qui vise à rendre certaines données, actions et capacités de la plateforme accessibles à des agents et applications externes via MCP. 

Salesforce résume cette logique autour de quatre éléments qui accompagnent chaque appel : l’identité de l’utilisateur, ses accès, les capacités rendues disponibles à l’agent et les règles de gouvernance Salesforce.

Ce fonctionnement évite une confusion assez fréquente lorsqu’on parle d’agents connectés à un système d’information.

Il ne suffit pas qu’une donnée ou qu’un processus existe quelque part dans Salesforce pour que Claude puisse automatiquement l’utiliser.

Il faut à la fois que l’utilisateur en ait le droit et que la capacité concernée soit accessible à l’agent.

L’entreprise garde la main sur ce que Claude peut faire seul

Il existe également une différence entre autoriser une action et permettre à Claude de l’exécuter sans validation humaine.

Salesforce prévoit également des mécanismes permettant de conserver une validation humaine sur certaines actions. 

L’entreprise donne notamment l’exemple d’un email destiné à une personne extérieure à l’organisation. Claude peut être configuré pour demander confirmation avant l’envoi, puis éventuellement être autorisé à envoyer directement ce type de message lorsque l’entreprise estime le fonctionnement suffisamment maîtrisé.

Salesforce précise aussi que lorsqu’une mise à jour d’enregistrement est annoncée par Claude, seuls les champs annoncés doivent être modifiés.

Ce point est important parce qu’il évite de mettre tous les usages dans la même catégorie.

Demander à Claude de résumer un compte client n’a pas le même niveau de risque que lui demander de modifier une opportunité.

Modifier une opportunité n’a pas non plus le même impact qu’envoyer un message externe ou lancer un processus qui déclenche ensuite plusieurs actions dans le système d’information.

La question à poser n’est donc pas simplement :

« Est-ce que Claude peut écrire dans Salesforce ? »

Mais plutôt :

« Pour quelles actions sommes-nous prêts à le laisser agir directement, et pour lesquelles souhaitons-nous conserver une validation humaine ? »

Cette distinction sera probablement centrale dans les premiers déploiements.

Les actions réalisées depuis Claude restent rattachées à l’utilisateur

Un autre point devient particulièrement important dès que Claude commence à agir dans Salesforce : savoir qui est à l’origine de l’action.

Là encore, Salesforce conserve l’identité de l’utilisateur.

La documentation de Headless 360 indique que les transactions sont exécutées comme l’utilisateur authentifié et que la piste d’audit attribue l’action à cet utilisateur.

C’est très différent d’une intégration fonctionnant derrière un compte générique partagé entre plusieurs personnes.

Pour une entreprise, cette continuité est importante : le canal change, mais l’action reste rattachée à l’identité Salesforce qui l’a demandée.

Cela permet notamment de conserver une lecture cohérente de ce qui se passe dans le CRM, même lorsque l’utilisateur n’est plus directement dans l’interface Salesforce.

Il n’y a donc pas un deuxième modèle de sécurité à reconstruire

C’est probablement l’un des choix les plus structurants de Salesforce in Claude.

Salesforce indique qu’un administrateur connecte le service au niveau de l’organisation et que l’authentification et les permissions restent gérées de manière centralisée. Il n’est pas nécessaire de reconstruire un nouveau système de droits utilisateur par utilisateur simplement parce qu’une nouvelle interface est utilisée.

Le principe est assez simple :

Salesforce reste le système de référence. Claude devient une nouvelle porte d’entrée.

C’est aussi ce qui différencie cette approche d’une intégration dans laquelle les données du CRM seraient copiées dans un autre système, avec une nouvelle logique d’accès à maintenir en parallèle.

L’utilisateur change d’interface, mais l’entreprise continue de s’appuyer sur les règles déjà présentes dans Salesforce.

Mais cela ne veut pas dire qu’il n’y a plus rien à vérifier

Salesforce met naturellement en avant cette continuité comme un avantage : pas de nouveau modèle de permissions à construire et pas de droits à redéfinir compte par compte.

Pour autant, l’arrivée de Claude crée une bonne occasion de regarder les permissions existantes avec un œil neuf.

Car Claude hérite aussi des accès qui sont peut-être devenus trop larges avec le temps.

Dans une organisation Salesforce installée depuis plusieurs années, un utilisateur peut avoir changé d’équipe, récupéré différents Permission Sets ou conservé certains accès historiques qui ne correspondent plus totalement à son rôle actuel.

Ce problème existait déjà.

Mais l’interface conversationnelle peut lui donner une nouvelle importance.

Un accès excessif était auparavant exploitable en naviguant dans Salesforce, en ouvrant des rapports ou en recherchant manuellement des données.

Avec Claude, le même utilisateur peut potentiellement demander directement une synthèse couvrant une grande quantité d’informations accessibles.

L’IA ne crée pas nécessairement le mauvais droit. Elle peut rendre beaucoup plus simple l’exploitation d’un mauvais droit qui existait déjà.

Salesforce formule d’ailleurs lui-même cette vigilance dans sa documentation destinée aux administrateurs : lorsqu’un agent agit pour un utilisateur, il peut faire ce que cet utilisateur est autorisé à faire. Le modèle de permissions devient donc encore plus important lorsqu’on ouvre Salesforce à des systèmes externes et à des agents.

C’est probablement l’un des principaux sujets à anticiper avant un déploiement à grande échelle.

Et que deviennent les données envoyées à Claude ?

La question des droits Salesforce ne couvre pas à elle seule tous les enjeux de sécurité.

Une fois qu’une donnée autorisée est transmise à Claude pour répondre à une demande, il faut aussi s’intéresser aux conditions dans lesquelles elle est traitée.

Sur la page Claudeforce actuelle, Salesforce annonce notamment une absence de rétention des données pour Sonnet, Opus et Haiku dans le cadre de cette expérience. Salesforce et Anthropic indiquent également travailler sur des contrôles supplémentaires concernant la localisation des données, les accès et la détection automatisée de problèmes avant qu’ils n’atteignent les utilisateurs.

Ces éléments sont importants, mais ils doivent être replacés dans le contexte du lancement.

Salesforce in Claude est aujourd’hui disponible auprès de clients pilotes sélectionnés et son ouverture en bêta est prévue en septembre 2026. Certaines garanties, modalités de disponibilité ou conditions contractuelles peuvent donc encore évoluer selon les offres et les régions.

Pour une entreprise, la validation d’un usage en production devra donc porter sur deux niveaux distincts : les droits appliqués par Salesforce, mais aussi les conditions de traitement des données une fois Claude appelé.

Ce qu’il faut regarder avant d’ouvrir Salesforce à Claude

La bonne nouvelle est qu’il n’est pas nécessaire de repartir de zéro.

Mais avant de généraliser Salesforce in Claude, quatre questions méritent d’être posées :

1. Les droits Salesforce actuels correspondent-ils encore aux fonctions réelles des utilisateurs ? Une revue des profils, Permission Sets, règles de partage et accès aux données sensibles peut éviter de reproduire dans Claude des droits devenus trop larges.
2. Quels usages doivent rester uniquement consultatifs ? Résumer un compte, analyser un pipeline ou préparer un rendez-vous peuvent constituer des premiers cas d’usage avec un niveau de risque limité.
3. Quelles actions doivent conserver une validation humaine ? Une mise à jour CRM, une communication externe ou le déclenchement d’un processus ne nécessitent pas forcément le même niveau d’autonomie.
4. Quelles autres sources Claude pourra-t-il croiser avec Salesforce ? Salesforce in Claude peut également utiliser le contexte provenant de Slack et d’autres connecteurs. La gouvernance doit donc être pensée au niveau du parcours complet de l’information, pas uniquement du CRM.

Cette réflexion dépasse finalement Claudeforce.

Elle oblige à définir plus clairement ce qu’un utilisateur peut consulter, ce qu’un agent peut exécuter pour lui et à quel moment l’humain doit reprendre la main.

Claude ne remplace pas les règles Salesforce. Il les rend accessibles autrement.

C’est probablement la manière la plus simple de comprendre Salesforce in Claude.

Claude apporte le raisonnement et une interface conversationnelle capable de comprendre une demande, de retrouver du contexte et de proposer ou d’exécuter une action.

Salesforce continue de fournir la donnée de référence, l’identité, les permissions, les règles métier et les processus qui encadrent cette action. Claude peut donc faire beaucoup plus avec Salesforce sans pour autant disposer de plus de droits que l’utilisateur.

Et c’est précisément ce qui rend Claudeforce intéressant.

Le changement ne consiste pas à ouvrir davantage le CRM.

Il consiste à rendre ce qui était déjà accessible dans Salesforce beaucoup plus facile à interroger et, progressivement, à piloter.

Pour les entreprises, l’enjeu des prochains mois ne sera donc pas seulement de décider si elles souhaitent tester Claude avec Salesforce.

Il sera de définir ce qu’elles veulent rendre accessible depuis la conversation, quelles actions elles souhaitent déléguer et quelles règles doivent continuer à imposer une intervention humaine.

Salesforce in Claude est actuellement disponible auprès de certains clients pilotes. La bêta ouverte est annoncée pour septembre 2026, avec les usages commerciaux comme premier périmètre.