Votre Salesforce est-il prêt pour Claudeforce ?

Avec Claudeforce, Salesforce et Anthropic veulent rendre les données, les processus et les actions Salesforce directement accessibles depuis Claude.

Le premier produit issu de ce partenariat, Salesforce in Claude, doit permettre aux commerciaux de préparer un rendez-vous, analyser une opportunité, revoir leur pipeline ou mettre à jour certaines informations dans Salesforce depuis une conversation. Le plugin arrive avec 37 skills commerciales déjà préparées et s’appuie sur les règles et les processus existants dans Salesforce.

Sur le papier, la connexion peut donc sembler être la partie la plus importante du projet.

Elle ne l’est probablement pas.

Car une fois Claude connecté, une autre question apparaît immédiatement :

Que va-t-il réellement trouver dans votre Salesforce ?

Un pipeline suffisamment fiable pour identifier les opportunités à risque ? Des processus métier clairement structurés ? Le contexte nécessaire pour comprendre un client ? Des automatisations dont les conséquences sont maîtrisées ?

Claudeforce ne reconstruit pas tout cela.

Il s’appuie dessus.

Et c’est précisément pour cette raison que l’arrivée de Claude dans Salesforce ne pose pas seulement une question technologique. Elle pose une question beaucoup plus large sur la maturité du CRM.

Claude peut très bien fonctionner avec un Salesforce qui fonctionne mal

Prenons l’un des cas d’usage mis en avant par Salesforce : l’analyse du pipeline.

Un directeur commercial pourrait demander :

« Quelles opportunités risquent de glisser ce trimestre ? »

Claude peut parcourir les données disponibles, rapprocher différentes informations et présenter les dossiers qui méritent une attention particulière.

Mais imaginons maintenant que, dans Salesforce :

• certaines dates de closing n’ont pas été actualisées depuis plusieurs semaines ;
• les étapes commerciales ne reflètent pas toujours l’avancement réel des dossiers ;
• le champ correspondant à la prochaine action est rarement renseigné ;
• certaines opportunités restent ouvertes alors qu’elles sont en réalité abandonnées ;
• les échanges qui expliquent la situation du client ne remontent pas correctement dans le CRM.

Techniquement, Salesforce in Claude peut fonctionner exactement comme prévu.

Le problème se trouve ailleurs.

La réalité décrite par Salesforce n’est plus suffisamment proche de la réalité commerciale.

Claude ne peut pas deviner qu’une date est obsolète simplement parce qu’elle semble inhabituelle. Il peut éventuellement identifier une incohérence et la signaler, mais il ne dispose pas automatiquement de l’information réelle qui aurait dû être enregistrée à sa place.

Cela paraît évident. Pourtant, cette différence devient beaucoup plus importante dans un fonctionnement agentique.

Avec un CRM classique, un commercial expérimenté peut encore compenser certaines lacunes grâce à ce qu’il sait personnellement de ses dossiers.

Il sait que telle opportunité est plus avancée que ne l’indique Salesforce.

Il se souvient que le client a demandé de reporter le projet.

Il sait que le montant affiché ne correspond plus au périmètre discuté.

Une partie du fonctionnement repose alors sur un mélange entre ce que sait Salesforce et ce que savent les utilisateurs.

Dès qu’un agent entre dans l’équation, cette frontière devient beaucoup plus visible.

Ce que les équipes savent doit progressivement devenir compréhensible par le système

C’est probablement l’un des sujets les plus structurants derrière l’arrivée des agents dans les applications d’entreprise.

Les systèmes ont longtemps été conçus pour des humains capables de combler les trous.

Un utilisateur sait interpréter un champ, comprendre une exception ou replacer une information dans son contexte parce qu’il connaît l’entreprise.

Un agent, lui, a besoin que cette signification soit davantage explicitée.

Salesforce fait le même constat dans ses travaux autour de Data 360 : un agent ne dispose pas spontanément du contexte qu’un analyste ou qu’un collaborateur apporte lorsqu’il interprète une donnée. La signification métier doit donc devenir suffisamment explicite, gouvernée et exploitable par la machine.

Prenons un exemple simple.

Dans Salesforce, une opportunité porte le statut Qualification.

Pour un commercial, ce statut peut implicitement signifier :

le besoin du client a été identifié, un budget crédible existe, un décideur a été identifié et le calendrier du projet est suffisamment précis.

Mais ces critères apparaissent-ils réellement quelque part ?

Si la réponse est non, Claude dispose du statut Qualification, mais pas nécessairement de ce que l’entreprise entend réellement par « opportunité qualifiée ».

C’est là qu’apparaît une distinction importante : avoir la donnée ne signifie pas forcément avoir le contexte métier nécessaire pour l’interpréter correctement.

Un Salesforce prêt pour les agents n’est donc pas uniquement un Salesforce dans lequel les champs sont remplis.

C’est un Salesforce dans lequel les informations importantes ont suffisamment de sens pour être utilisées sans dépendre constamment de connaissances détenues uniquement par les équipes.

Votre CRM stocke-t-il vos processus ou les comprend-il réellement ?

Le même problème se retrouve dans les règles métier.

Dans beaucoup d’entreprises, Salesforce accompagne le processus sans nécessairement en porter toute la logique.

Les équipes savent par exemple que :

une remise importante doit être validée par un manager ;

une opportunité ne doit pas atteindre une certaine étape avant qu’un élément contractuel soit confirmé ;

certains clients doivent faire l’objet d’un contrôle supplémentaire avant qu’une action soit engagée ;

un dossier particulier doit être transmis à une autre équipe lorsqu’une condition précise est rencontrée.

Ces règles peuvent être formalisées dans Salesforce à travers le modèle de données, des validations, des automatisations, des approbations ou d’autres mécanismes.

Mais elles peuvent aussi simplement exister dans les habitudes de travail.

Et tant que l’utilisateur exécute personnellement chaque étape, ce modèle peut parfois fonctionner.

Il connaît la règle.

Il sait qu’il faut appeler telle personne.

Il se souvient de l’exception.

Il sait que dans ce cas précis, le processus habituel ne s’applique pas.

L’arrivée des agents rend cette dépendance aux connaissances implicites beaucoup plus difficile à ignorer.

Salesforce développe justement Headless 360 autour du principe que les capacités de la plateforme (données, logique métier, actions et workflows) puissent être utilisées par des agents depuis d’autres interfaces.

Plus une entreprise souhaite aller dans cette direction, plus une question devient importante :

quelle partie de notre fonctionnement métier existe réellement dans le système, et quelle partie repose encore sur ce que les collaborateurs savent faire naturellement ?

Il ne s’agit évidemment pas de transformer chaque habitude humaine en règle Salesforce.

Mais les règles nécessaires à une décision ou à une action confiée à un agent doivent être suffisamment explicites pour que celui-ci puisse travailler dans le bon cadre.

La qualité d’une automatisation devient aussi la qualité de l’expérience avec Claude

Il existe ensuite un deuxième niveau.

Ce que Claude demande à Salesforce peut paraître très simple.

« Passe cette opportunité à l’étape suivante. »

Mais dans une organisation Salesforce réelle, modifier un champ peut déclencher beaucoup plus qu’une mise à jour à l’écran.

Un Flow peut créer une tâche.

Un autre peut envoyer une notification.

Une intégration peut transmettre une information à un système externe.

Une règle peut mettre à jour plusieurs autres champs.

Un processus peut être déclenché dans une autre équipe.

Ce fonctionnement existe déjà aujourd’hui.

Ce que Claudeforce peut changer, c’est la friction nécessaire pour déclencher l’action.

Un utilisateur qui devait auparavant ouvrir Salesforce, retrouver l’opportunité, modifier les informations et enregistrer peut désormais simplement formuler son intention dans Claude.

C’est précisément l’un des intérêts de cette nouvelle interface.

Mais moins une action demande d’effort à déclencher, plus il devient important que ce qui se passe derrière soit prévisible.

Une automatisation historiquement fragile ne devient pas plus robuste parce qu’un agent l’appelle.

Au contraire, une action qui devient plus simple à demander peut rendre ses conséquences beaucoup plus visibles.

Salesforce recommande déjà dans son framework Well-Architected de concevoir les automatisations avec une logique claire, une bonne gestion des erreurs et des mécanismes permettant de préserver l’intégrité des données.

Claudeforce ne crée donc pas un nouveau principe d’architecture.

Il donne davantage d’importance à un principe existant :

avant de rendre une action plus facile à déclencher, il faut comprendre précisément ce qu’elle déclenche.

Pour certaines organisations Salesforce construites depuis plusieurs années, cette vérification peut être plus importante que la connexion de Claude elle-même.

Le contexte dont Claude a besoin ne se trouve pas forcément uniquement dans Salesforce

Préparer Salesforce aux agents ne signifie pas non plus essayer de faire rentrer toutes les informations de l’entreprise dans le CRM.

Dans la plupart des systèmes d’information, le contexte utile est naturellement distribué.

Salesforce peut contenir la relation commerciale.

L’ERP contient la facturation et les commandes.

Une plateforme e-commerce connaît les achats réalisés en ligne.

L’outil de support conserve les incidents en cours.

Slack contient certains échanges internes.

D’autres applications portent encore des informations propres au métier.

Salesforce indique d’ailleurs que Salesforce in Claude peut exploiter le contexte du commercial provenant de Salesforce, mais aussi de Slack et des autres connecteurs disponibles dans Claude.

Cela déplace légèrement la question.

Il ne faut plus seulement demander :

« Avons-nous cette information dans Salesforce ? »

Mais :

« Pour prendre cette décision, de quelles informations Claude a-t-il besoin, où se trouvent-elles et laquelle fait foi ? »

Imaginons que l’on demande :

« Quels clients devrais-je contacter en priorité cette semaine ? »

La réponse peut dépendre du pipeline Salesforce.

Mais elle peut également dépendre :

des commandes réalisées récemment ;

du chiffre d’affaires réellement facturé ;

d’un incident critique toujours ouvert ;

de la participation du client à une campagne ;

ou encore d’un comportement observé sur un canal digital.

Dans ce cas, disposer d’un CRM bien tenu ne suffit pas nécessairement.

Le véritable sujet devient la capacité à fournir le bon contexte métier au bon moment.

Salesforce poursuit d’ailleurs cette logique avec Data 360 et son serveur MCP : l’objectif est notamment de rendre des données unifiées, la résolution d’identité, les segments et les insights calculés accessibles à des agents. Salesforce résume lui-même le problème de manière assez directe : les agents ne peuvent être meilleurs que le contexte auquel ils ont accès.

C’est un point essentiel.

Préparer Salesforce à Claudeforce, ce n’est donc pas centraliser toutes les données. C’est maîtriser suffisamment leur architecture pour savoir quel contexte doit alimenter chaque usage.

Il ne faut surtout pas chercher à rendre tout Salesforce « agent-ready » d’un seul coup

C’est probablement là qu’une approche pragmatique devient nécessaire.

La mauvaise question serait :

« Notre Salesforce est-il globalement prêt pour Claudeforce ? »

Une organisation Salesforce peut être très mature sur certains processus et beaucoup moins sur d’autres.

Les données nécessaires à la préparation d’un rendez-vous peuvent être excellentes.

Celles nécessaires à une prévision commerciale peuvent être trop irrégulières.

Le processus de création d’une opportunité peut être parfaitement maîtrisé.

Une autre automatisation plus ancienne peut être devenue difficile à maintenir.

Il est donc beaucoup plus pertinent d’évaluer la préparation cas d’usage par cas d’usage.

Prenons la préparation d’un rendez-vous.

Il faut identifier les informations que Claude devra mobiliser :

• qui est le client ;
• quelles opportunités sont en cours ;
• quelles interactions ont eu lieu ;
• quels sujets sont ouverts ;
• quelles actions sont prévues ;
• quelles autres informations peuvent changer la compréhension du compte.

Puis regarder leur qualité réelle.

Même exercice pour une revue de pipeline.

Même exercice pour la mise à jour d’une opportunité.

Même exercice demain pour un processus plus complexe impliquant plusieurs outils.

Cette approche évite de transformer Claudeforce en gigantesque programme de remise à plat du CRM avant même d’avoir identifié les usages qui créent réellement de la valeur.

Elle permet aussi de détecter beaucoup plus rapidement les vrais blocages.

Pour un cas d’usage donné :

• Avons-nous les bonnes données ?
• Ont-elles suffisamment de sens ?
• Le processus est-il formalisé ?
• Les automatisations associées sont-elles maîtrisées ?
• Le contexte nécessaire existe-t-il ailleurs ?

C’est seulement après ces questions que l’on peut réellement déterminer si Salesforce est prêt à servir de socle à l’agent.

Claudeforce peut devenir un révélateur de la maturité de votre CRM

Au fond, l’un des aspects les plus intéressants de Claudeforce est peut-être qu’il remet en lumière des sujets qui existaient bien avant l’arrivée de Claude.

• La qualité des données.
• La manière dont les processus sont modélisés.
• La cohérence entre les différents systèmes.
• La maintenabilité des automatisations.
• La capacité du CRM à représenter correctement le fonctionnement réel de l’entreprise.

Pendant longtemps, certaines imperfections pouvaient être absorbées par les utilisateurs.

Ils savaient où chercher.

Ils connaissaient les exceptions.

Ils corrigeaient mentalement une information obsolète.

Ils savaient quelle action réaliser même lorsqu’elle n’était pas explicitement prévue par le système.

Les agents rendent progressivement cette dépendance au savoir implicite beaucoup plus visible.

Et c’est probablement pour cette raison que préparer Salesforce à Claudeforce ne consiste pas à ajouter une nouvelle couche « IA » au-dessus du CRM.

Il s’agit plutôt de vérifier que le socle que l’on souhaite mettre à disposition de Claude représente suffisamment bien la réalité de l’entreprise.

Les organisations qui disposent déjà de données fiables, de processus clairs, d’automatisations maîtrisées et d’une architecture cohérente disposent donc d’un avantage important parce qu’elles ont déjà construit ce dont les agents ont besoin pour être réellement utiles.

À l’inverse, Claudeforce peut rapidement mettre en évidence les zones où Salesforce repose encore trop fortement sur des approximations, des données peu fiables ou des connaissances détenues uniquement par les équipes.

Préparer Salesforce à Claudeforce : par où commencer ?

Avant de chercher à connecter Claude à Salesforce, il est utile de partir des usages que l’entreprise souhaite réellement lui confier.

Préparation de rendez-vous, analyse du pipeline, mise à jour d’opportunités, recherche d’informations clients : chaque cas d’usage nécessite des données, du contexte et des processus différents.

Chez SIWAY, notre rôle est précisément d’analyser ce qui existe déjà dans Salesforce et de déterminer ce qui doit être fiabilisé, structuré ou connecté pour rendre ces usages possibles. Cela peut passer par : 

• l’identification des cas d’usage pertinents, en fonction des processus métiers et des tâches réellement réalisées par les équipes ;
• l’analyse des données nécessaires à ces usages, de leur qualité et de leur disponibilité dans Salesforce ou dans les autres systèmes de l’entreprise ;
• la revue des processus et automatisations Salesforce, afin de vérifier que les actions que l’on souhaite rendre accessibles à un agent reposent sur une logique maîtrisée ;
• la structuration du contexte métier, lorsque certaines règles ou connaissances restent aujourd’hui implicites ou dispersées entre plusieurs outils ;
• l’évolution des intégrations et de l’architecture Salesforce, lorsque Claude doit disposer d’informations provenant de l’ERP, du e-commerce, du support ou d’autres applications.

L’objectif n’est pas de rendre l’ensemble de Salesforce « prêt pour l’IA » en une seule fois.

Il est de partir d’un besoin métier concret, d’identifier ce dont Claude aura réellement besoin pour y répondre et de s’assurer que le socle Salesforce est suffisamment fiable pour lui permettre de le faire correctement.

Claudeforce ouvre une nouvelle manière d’utiliser Salesforce. Notre travail reste le même : faire en sorte que les données, les processus et les outils qui se trouvent derrière répondent réellement aux besoins de l’entreprise.