Vos équipes n'utilisent pas Salesforce à fond ? On garde Salesforce comme backend de données et on ajoute Claude comme interface conversationnelle. L'utilisateur parle, Claude orchestre.
Intégrer Claude avec Salesforce, c'est connecter Claude aux objets, workflows et permissions du CRM via l'API Salesforce et le protocole MCP : Claude lit comptes, opportunités et comptes rendus, rédige et met à jour le CRM, qui reste le système de référence. Koneetiv le fait avec Salesforce Headless, sous gouvernance LOOP™, avec l'expertise Salesforce de Reej Consulting (Groupe Reej).
Salesforce embarque 80% des fonctionnalités dont vos commerciaux ont besoin. Mais l'interface est trop dense, la configuration trop lourde, et l'adoption ne suit jamais.
Vous gardez Salesforce comme système de référence : données, gouvernance, sécurité. Vous mettez Claude en surface : conversation naturelle, contexte enrichi, gestes commerciaux fluides. Les fonctionnalités Salesforce dormantes deviennent enfin actionnables.
Trois phases. On démarre sur un cas pilote et un cloud, on industrialise, puis on étend à Sales, Service et Platform.
Analyse de l'adoption Salesforce actuelle et identification du cas pilote à plus forte valeur.
Architecture des skills Claude connectés à l'API Salesforce et build des agents conversationnels.
Lancement utilisateurs, mesure de l'adoption et de la consommation, extension progressive aux autres clouds.
On mesure l'adoption réelle de Salesforce, on cartographie les frictions utilisateurs et on identifie le cas pilote à plus forte valeur : Sales, Service ou Platform.
Usage réel par module, taux de complétion des champs, écarts entre process et pratique.
Entretiens terrain : où les équipes décrochent, ce qu'elles contournent, ce qu'elles abandonnent.
Sélection du cloud et du cas d'usage à plus forte valeur pour démarrer (Sales / Service / Platform).
On conçoit l'architecture des skills Claude × API Salesforce, on développe les agents conversationnels et leurs intégrations MCP, et on valide gouvernance et sécurité avant la mise en main.
Mapping des objets Salesforce, des workflows et des permissions vers des skills Claude.
Connexion de Claude à Salesforce et aux sources métier (Drive, mail, outils de conversation).
Zones de confiance LOOP™, validation humaine sur les actions sensibles, red teaming.
On lance les utilisateurs, on suit adoption et consommation, on forme en continu, puis on étend le périmètre de Sales à Service à Platform.
Embarquement de l'équipe pilote, formation aux usages conversationnels, support rapproché.
Dashboard d'usage par utilisateur, suivi de la consommation Claude, ROI par cas d'usage.
Réplication du modèle Sales → Service → Platform, nouveaux cas d'usage ajoutés en continu.
L'utilisateur s'adresse à Claude en langage naturel. Claude lit, raisonne et met à jour Salesforce en arrière-plan.
Côté serveur, des agents Claude travaillent en continu sur Salesforce. Agent invisible, impact visible : ils lisent, raisonnent et mettent à jour, sans geste utilisateur.
Mesuré sur les cas d'usage pilotes Salesforce Headless.
Salesforce Headless n'est pas un habillage générique. Chaque secteur a son goulot d'étranglement propre entre le front conversationnel et le CRM, hérité de son historique d'outils, de sa réglementation ou de la saisonnalité de son activité. Voici comment l'architecture Claude par-dessus Salesforce s'adapte à quatre contextes B2B mid-market et grand compte représentatifs de nos clients, avec pour chacun le problème métier de départ, la réponse apportée par l'architecture headless et les connecteurs MCP mobilisés, et ce que ce changement représente concrètement pour les équipes qui l'utilisent au quotidien.
Dans une DSI du secteur assurance, les conseillers jonglent entre Salesforce Financial Services Cloud, l'outil de gestion des sinistres et l'outil de conformité KYC, avec une saisie manuelle à chaque étape. Un dossier de souscription mobilise en moyenne trois écrans différents, et la moindre relance client oblige à ressaisir un contexte déjà présent quelque part dans le CRM. Le risque n'est pas seulement la lenteur : c'est l'erreur de saisie qui remonte en audit de conformité six mois plus tard, ou l'information de scoring risque consultée dans le mauvais outil au mauvais moment. À cela s'ajoute la pression réglementaire : chaque échange avec le client doit pouvoir être reconstitué a posteriori, ce qui pousse souvent les équipes à documenter en double, dans le CRM et dans un tableur de suivi parallèle, par prudence plus que par choix d'organisation.
L'architecture headless place Claude en interface conversationnelle unique par-dessus Salesforce et les systèmes tiers connectés via MCP (outil de sinistres, référentiel réglementaire interne, moteur de scoring risque). Le conseiller décrit sa demande en langage naturel, Claude interroge les objets Salesforce pertinents, croise avec les règles de conformité définies dans le référentiel LOOP™, et prépare le dossier avec la traçabilité exigée par l'audit, sans jamais écrire dans Salesforce sans validation humaine sur les actions sensibles. Le même agent peut aussi détecter qu'une pièce justificative manque au dossier avant de le faire avancer, plutôt que de laisser ce contrôle reposer sur la vigilance du conseiller en fin de parcours. La gouvernance LOOP™ définit précisément quelles actions Claude peut exécuter seul (relecture, synthèse, préparation) et lesquelles restent soumises à validation humaine explicite (décision de souscription, dérogation tarifaire), ce qui rassure la fonction conformité sans figer l'usage au quotidien.
Les équipes de souscription arrêtent de naviguer entre outils pour reconstituer un dossier : elles posent la question et reçoivent une synthèse sourcée, objet par objet, avec le lien vers chaque enregistrement Salesforce d'origine. La fonction conformité gagne une piste d'audit complète sur chaque interaction agent, ce qui simplifie les contrôles internes périodiques sans ralentir le conseiller au quotidien. Le double suivi en tableur parallèle, qui existait par prudence, devient inutile puisque la traçabilité vit nativement dans Salesforce et dans les journaux d'agent LOOP™, consultables à tout moment par un auditeur interne ou externe.
Un conseiller souscription tape simplement : « Prépare le dossier de renouvellement du contrat Dupont, vérifie si les pièces KYC sont à jour et signale tout écart avec le dernier scoring risque. » Claude interroge l'objet Opportunity et les pièces jointes dans Salesforce, croise avec le référentiel de conformité connecté via MCP, identifie qu'une attestation domicile date de plus de trois ans, et prépare une synthèse avec la liste des pièces manquantes, prête à être relue par le conseiller avant tout envoi au client. Rien n'est écrit dans Salesforce sans validation explicite sur les champs sensibles du dossier.
Une enseigne retail mid-market gère son service client sur Salesforce Service Cloud, mais les informations de stock, de commande et de logistique vivent dans des systèmes séparés du CRM. Un conseiller client qui doit répondre à une réclamation sur une commande en retard doit ouvrir successivement l'outil de gestion de stock, le tracking transporteur et Salesforce pour retrouver l'historique client, avant de pouvoir formuler une réponse cohérente. Multiplié par des centaines de tickets par jour, ce temps de bascule entre outils pèse directement sur le délai de réponse, et sur la satisfaction client aux pics saisonniers, quand le volume de sollicitations double ou triple sans que l'équipe grossisse dans les mêmes proportions.
En architecture headless, Claude devient le point d'entrée unique du conseiller : une même conversation interroge en parallèle, via MCP, l'objet Case et l'historique client dans Salesforce, l'état de stock dans le système logistique, et le statut transporteur. Claude compose une réponse contextualisée et propose l'action Salesforce correspondante (remboursement partiel, renvoi, avoir), que le conseiller valide avant exécution. Les règles métier de l'enseigne (seuils de remboursement, politique de retour) sont encodées dans les skills Claude et appliquées de façon cohérente, quel que soit le conseiller qui traite le ticket, y compris pendant les pics de recrutement saisonnier où de nouveaux conseillers arrivent sans avoir encore intégré toutes les subtilités de la politique commerciale.
Le conseiller ne change plus d'onglet pour instruire un dossier : il obtient en une requête une vue consolidée qui aurait demandé plusieurs minutes de navigation. La cohérence des réponses s'améliore d'un conseiller à l'autre, puisque les règles métier sont appliquées par Claude et non reconstituées de mémoire, et l'équipe qualité retrouve dans Salesforce la trace complète de chaque décision assistée. Aux périodes de forte charge, l'enseigne absorbe le pic sans dégrader le temps de réponse dans les mêmes proportions qu'avant, parce que le temps gagné sur la recherche d'information se reporte directement sur le volume de tickets traités.
Un conseiller service client tape : « La commande 48213 devait arriver hier, le client est mécontent, que s'est-il passé et que puis-je lui proposer ? » Claude croise en une requête l'historique client dans Salesforce, le statut transporteur et l'état de stock de l'article concerné, identifie un retard logistique confirmé, et propose un avoir conforme à la politique de l'enseigne, avec la justification associée. Le conseiller valide l'action, Claude l'exécute dans Salesforce et journalise la décision, sans que personne n'ait eu à ouvrir successivement trois outils différents pour y arriver.
Chez un industriel qui pilote sa relation client et ses contrats de maintenance dans Salesforce, les techniciens terrain remontent leurs comptes rendus d'intervention avec un décalage de plusieurs jours, parce que la saisie mobile dans Salesforce reste lourde sur le terrain et que les données de diagnostic machine vivent dans un outil de supervision industrielle distinct. Le service client, lui, doit croiser manuellement l'historique des interventions Salesforce et les données de supervision pour anticiper une panne récurrente, ce qui retarde la détection des dérives sur un parc d'équipements. Ce délai se paie en disponibilité machine : une panne qui aurait pu être anticipée à partir de signaux faibles n'est traitée qu'une fois devenue un arrêt de ligne, avec les coûts de production associés.
L'architecture headless permet au technicien de dicter ou de décrire son intervention en langage naturel à Claude, qui structure l'information et met à jour l'objet Salesforce correspondant (contrat, équipement, ticket d'intervention) via l'API. En parallèle, Claude interroge par MCP l'outil de supervision industrielle pour rapprocher les codes d'alerte machine de l'historique d'interventions Salesforce, et signale les schémas de panne récurrents à l'équipe de maintenance préventive avant qu'ils ne deviennent des arrêts de production. La saisie ne dépend plus d'un formulaire complet à remplir sur un écran de smartphone dans des conditions terrain difficiles, mais d'une conversation courte que Claude structure ensuite dans le bon format Salesforce, avec les bons champs et la bonne catégorisation.
La saisie terrain devient conversationnelle plutôt que formulaire, ce qui réduit le décalage entre l'intervention et sa trace dans Salesforce. Les équipes de maintenance préventive disposent d'un rapprochement automatique entre données machine et historique CRM qu'elles devaient auparavant reconstituer secteur par secteur, à la main, dans un tableur. Les responsables maintenance passent moins de temps à consolider des données dispersées et davantage à décider des priorités d'intervention, avec une base d'information plus fraîche et plus complète qu'avant.
Un technicien termine son intervention et dicte à Claude, depuis son téléphone : « Remplacé le capteur de pression sur la ligne 3, code alerte E204 déjà vu deux fois ce mois-ci sur cette machine. » Claude structure l'information, met à jour le ticket d'intervention et l'objet équipement dans Salesforce, puis interroge l'historique via MCP pour confirmer la récurrence du code E204 sur cet équipement précis. Si le seuil de récurrence défini avec l'équipe maintenance est dépassé, Claude signale l'équipement à l'équipe de maintenance préventive avec l'historique complet, sans attendre le prochain arrêt de ligne pour que l'alerte remonte.
Dans une société de conseil ou de services B2B, les équipes commerciales et delivery utilisent Salesforce comme référentiel d'opportunités et de comptes, mais le reporting consolidé (pipeline, marge par mission, charge des consultants) implique des extractions manuelles vers des tableurs, mises à jour de façon irrégulière. Un manager qui prépare une revue de pipeline hebdomadaire passe souvent plus de temps à assembler les chiffres qu'à les analyser, et les écarts entre le tableur et Salesforce finissent par créer de la défiance sur les chiffres eux-mêmes. Chaque manager finit par avoir sa propre version du tableur, avec ses propres règles de calcul, ce qui rend toute comparaison entre équipes difficile lors des comités de pilotage.
Avec Claude en interface headless, le manager formule sa demande de reporting directement en langage naturel : Claude interroge les objets Opportunity, Account et les champs personnalisés Salesforce via l'API, applique les règles de calcul de marge définies avec l'équipe finance, et restitue une synthèse à jour au moment de la demande, sans extraction intermédiaire. Les agents autonomes gouvernés par LOOP™ peuvent aussi générer automatiquement une synthèse hebdomadaire envoyée aux managers, avec les écarts significatifs mis en avant. Comme la règle de calcul de marge est centralisée et appliquée par Claude de façon identique pour tous les managers, la question de savoir quelle version du chiffre est la bonne ne se pose plus : il n'y a plus qu'une seule source, Salesforce, interrogée de la même façon par tout le monde.
Le reporting cesse d'être un travail de reconstitution manuelle pour devenir une question posée à Claude, avec une réponse toujours alignée sur l'état réel de Salesforce. Les revues de pipeline se concentrent sur la décision plutôt que sur la vérification des chiffres, et la gouvernance LOOP™ garde la traçabilité de ce qui a été calculé, sourcé et transmis. Les comités de pilotage inter-équipes redeviennent possibles sur des bases comparables, puisque chaque manager part du même calcul plutôt que de sa propre feuille de route bureautique.
Un manager commercial tape avant sa revue de pipeline : « Donne-moi le pipeline pondéré par consultant sur la période en cours, avec la marge estimée par mission et les écarts de plus de 15 % par rapport au budget. » Claude interroge les objets Opportunity et Account dans Salesforce, applique les règles de calcul de marge validées avec la finance, et restitue un tableau de synthèse directement exploitable en réunion, sourcé jusqu'à l'enregistrement Salesforce d'origine pour chaque ligne. Le manager arrive en revue avec des chiffres déjà vérifiés plutôt qu'avec un tableur à reconstituer la veille au soir.
Ces quatre exemples, banque et assurance, retail, industrie, services B2B, n'épuisent pas la liste des cas d'usage possibles pour une DSI qui envisage une architecture Salesforce Headless. Ils partagent cependant un principe structurant, indépendant du secteur : Claude ne remplace jamais Salesforce comme système de vérité, il devient l'interface conversationnelle qui interroge, croise et prépare l'information avant qu'une décision ne soit prise ou qu'une action ne soit exécutée dans le CRM. Les connecteurs MCP mobilisés changent d'un secteur à l'autre, référentiel réglementaire pour l'assurance, outil logistique pour le retail, supervision industrielle pour la manufacture, moteur de calcul financier pour les services, mais l'architecture reste la même : deux couches, un pont MCP, et une gouvernance LOOP™ qui définit précisément ce qu'un agent peut exécuter seul et ce qui reste soumis à validation humaine. C'est ce socle commun, pas une promesse générique de productivité, qui permet à une équipe Salesforce déjà en place d'adopter Claude sans reconstruire son système d'information existant. Le choix des connecteurs et des skills à activer en priorité dépend toujours du contexte propre à chaque DSI, ce qui justifie un cadrage initial avant tout déploiement, plutôt qu'une configuration standard plaquée sur tous les secteurs de la même façon. C'est précisément l'objet des trois phases de déploiement décrites plus haut : cadrer les connecteurs MCP et les cas d'usage prioritaires avant de les industrialiser secteur par secteur.
Notre lecture honnête : Agentforce a sa place, Claude a la sienne. Les deux peuvent cohabiter dans le même Sales Cloud.
On démarre par un audit de votre usage Salesforce et l'identification du cas pilote à plus forte valeur.