Grounding des agents IA Salesforce : fiabiliser les réponses dans un contexte suisse

Un client demande à un agent IA s’il peut retourner un produit reçu quelques jours plus tôt.

L’agent répond que les retours sont acceptés pendant 30 jours. La réponse semble logique. Elle peut pourtant être inexacte si le produit est personnalisé, si la politique varie selon le pays, si le délai commence à la date d’achat ou si le client dispose d’un contrat spécifique.

Ce type d’erreur apparaît lorsque l’agent répond avec une connaissance générale, sans disposer du contexte réel : profil du client, commande concernée, conditions applicables, historique Salesforce, règles internes ou documentation à jour.

Dans Agentforce, le grounding sert précisément à apporter ce contexte.

Il permet à l’agent IA de construire sa réponse à partir des données de l’entreprise : CRM, articles Knowledge, documents internes, politiques commerciales, contrats, procédures, historiques de support ou informations issues d’un système connecté.

Pour les entreprises suisses, cette logique est essentielle. Les agents IA doivent être capables de répondre vite, tout en respectant les règles métier, les langues, les zones géographiques, les droits d’accès et les exigences de fiabilité propres à chaque organisation.

Qu’est-ce que le grounding dans Agentforce

Le grounding consiste à enrichir la demande transmise au modèle de langage avec les informations utiles pour traiter une situation précise.

Un LLM dispose d’une connaissance générale. Il peut expliquer un concept, rédiger une réponse ou reformuler une information. En revanche, il ne connaît pas spontanément les contrats d’une entreprise, les règles applicables en Suisse, les conditions propres à un client ou la dernière version d’une procédure interne.

Le grounding lui fournit ces éléments au moment de répondre.

Un agent Salesforce correctement groundé peut s’appuyer sur :

• le profil du client ;

• le compte ou le contact Salesforce ;

• la commande, le contrat ou le dossier concerné ;

• l’historique des échanges ;

• les articles Knowledge validés ;

• les règles commerciales applicables ;

• la langue ou le marché concerné ;

• les droits d’accès de l’utilisateur ;

• le contexte déjà partagé dans la conversation.

La réponse devient plus précise, plus personnalisée et plus facile à vérifier.

Grounding et RAG ne couvrent pas exactement le même périmètre

Le RAG, pour Retrieval-Augmented Generation, est une forme de grounding.

Son rôle consiste à rechercher les informations pertinentes dans une base documentaire, puis à les transmettre au modèle de langage pour l’aider à répondre.

Par exemple, si un utilisateur demande :

“Quelle garantie s’applique à ce modèle de serveur ?”

Un mécanisme RAG peut rechercher la documentation correspondant au modèle concerné, récupérer les conditions de garantie et les ajouter au contexte de réponse.

Le grounding couvre un périmètre plus large.

Il peut intégrer des données Salesforce structurées, comme les comptes, opportunités, commandes, contrats ou cases. Il peut aussi intégrer des résultats de Flow, des classes Apex, des prompt templates, des API MuleSoft ou des informations provenant d’un système externe.

Dans un environnement Salesforce suisse, cette distinction compte.

Un agent ne doit pas seulement retrouver un document. Il doit aussi comprendre quel client pose la question, quelle entité est concernée, quelle règle s’applique, quelle langue utiliser et quelle action peut être réalisée.

Comment Agentforce construit une réponse contextualisée

Une réponse Agentforce repose sur plusieurs étapes.

L’agent commence par identifier le bon périmètre de traitement. Dans Agentforce, les capacités sont organisées autour de topics ou de subagents selon les modules utilisés. Chaque périmètre correspond à un travail précis : suivre une commande, traiter une réclamation, rechercher une information produit, qualifier une demande ou mettre à jour un dossier.

Ce périmètre détermine les instructions, les sources et les actions disponibles.

L’agent peut ensuite consulter les données structurées présentes dans Salesforce. Il peut récupérer le compte associé à l’utilisateur, vérifier une commande, analyser un contrat, consulter l’état d’un dossier support ou identifier le niveau de service prévu.

Pour les contenus non structurés, l’agent peut s’appuyer sur des bibliothèques de données, des articles Knowledge, des fichiers importés, des sources web ou des retrievers personnalisés.

Le modèle reçoit alors un contexte plus proche de la situation réelle.

Dans une entreprise suisse, cette contextualisation peut intégrer des éléments très concrets : langue du client, pays de facturation, entité commerciale, politique locale, secteur d’activité, niveau de service, statut contractuel ou règles internes de validation.

Pourquoi les réponses hors contexte apparaissent

Le grounding améliore la fiabilité des agents IA, mais il dépend de plusieurs composants.

Une réponse hors contexte peut apparaître pour des raisons différentes : mauvais périmètre sélectionné, instructions trop vagues, sources obsolètes, recherche documentaire trop large, données CRM incomplètes ou absence de comportement de repli.

Le risque est souvent discret.

L’agent ne donne pas forcément une réponse absurde. Il peut donner une réponse cohérente en apparence, mais inadaptée au cas précis du client.

C’est justement ce qui rend le grounding si important.

Un mauvais périmètre sélectionné

Deux topics ou subagents trop proches peuvent créer une ambiguïté.

Une demande sur un produit déjà commandé peut relever à la fois du suivi de commande, de la fiche produit, du contrat ou du support après-vente.

Si le périmètre sélectionné est trop général, l’agent risque de répondre à partir d’une documentation produit sans consulter la commande réelle du client.

Les descriptions doivent donc être précises.

Elles doivent indiquer les demandes couvertes, les exclusions, les données à vérifier et les situations qui doivent être transférées vers un autre périmètre.

Pour une organisation suisse avec plusieurs marchés, plusieurs langues ou plusieurs entités, cette précision devient encore plus importante.

Des instructions trop vagues

Les instructions guident le comportement de l’agent.

Une consigne comme “Aide le client avec sa commande” laisse trop de place à l’interprétation.

Une instruction plus utile donne un chemin clair :

“Identifie d’abord la commande concernée. Vérifie son statut dans Salesforce. Consulte ensuite la politique de livraison applicable au pays du client. Demande une précision si plusieurs commandes correspondent.”

Cette formulation encadre la réponse.

Elle indique l’ordre des vérifications, les sources à utiliser et les cas où l’agent doit poser une question complémentaire.

Pour les entreprises suisses, les instructions doivent aussi préciser les règles liées à la langue, au marché, à la confidentialité, aux droits d’accès et aux actions nécessitant une validation humaine.

Des sources obsolètes ou contradictoires

Un agent peut retrouver une information et produire malgré tout une mauvaise réponse.

Ce problème apparaît lorsqu’une bibliothèque documentaire contient plusieurs versions d’une même procédure, une ancienne grille tarifaire, des conditions expirées, des règles locales non identifiées ou des documents sans date de validité.

Dans un contexte suisse, le risque peut être renforcé par la coexistence de plusieurs langues, entités ou marchés.

Une politique en français, une version allemande plus récente et une procédure interne non archivée peuvent créer des contradictions.

La gouvernance documentaire devient donc une condition de fiabilité.

Chaque contenu utilisé par l’agent doit idéalement avoir un propriétaire, une date de mise à jour, un périmètre d’application, une langue, un statut de validité et une règle d’archivage.

Une recherche documentaire trop large

Un retriever qui consulte toute la documentation peut récupérer une information exacte, mais inadaptée au cas traité.

La réponse devient alors hors contexte.

Pour éviter cela, les sources doivent être filtrées avec des métadonnées utiles :

• pays ;

• langue ;

• entité ;

• produit ;

• segment B2B ou B2C ;

• type de client ;

• date de validité ;

• politique interne ou publique ;

• niveau de confidentialité.

Ces filtres aident l’agent à rechercher dans le bon périmètre.

Pour une entreprise active en Suisse romande, en Suisse alémanique et à l’international, cette structuration permet d’éviter qu’une réponse destinée à un marché soit appliquée à un autre.

Un découpage documentaire mal pensé

Les documents utilisés par un agent sont souvent découpés en passages, ou chunks, avant d’être indexés.

Ce découpage influence directement la qualité du grounding.

Si une règle et son exception se trouvent dans deux passages séparés, l’agent peut récupérer seulement une partie de l’information.

Par exemple :

“Les retours sont acceptés pendant 30 jours. Les produits personnalisés et les articles déjà utilisés sont exclus.”

Si seule la première phrase remonte dans le contexte, l’agent risque de produire une réponse incomplète.

Les documents doivent donc être structurés avec des titres clairs, des sections cohérentes, des exceptions proches des règles concernées et des formulations faciles à interpréter.

Cette exigence vaut aussi pour les articles Knowledge, les FAQ, les documents PDF, les conditions commerciales et les procédures internes.

Associer données CRM et documentation

Le grounding devient plus fiable lorsque l’agent combine deux types d’informations.

Les données structurées décrivent la situation réelle du client.

Les contenus non structurés apportent les règles à appliquer.

Pour traiter une demande de retour, l’agent peut par exemple combiner :

• la date de livraison récupérée dans Salesforce ;

• la catégorie du produit ;

• le pays ou la langue du client ;

• le type de contrat ;

• la politique de retour issue de la documentation validée.

La réponse ne se limite alors pas à une règle générale.

Elle s’applique à une situation concrète.

Cette combinaison est particulièrement utile pour les entreprises suisses qui utilisent Salesforce comme socle CRM, avec des données clients, commerciales, support et contractuelles réparties dans plusieurs objets ou systèmes connectés.

Définir une hiérarchie entre les sources

Un agent doit savoir quelle source privilégier lorsque plusieurs informations sont disponibles.

Les instructions peuvent préciser que :

• le contrat du client prime sur les conditions générales ;

• la version publiée la plus récente doit être utilisée ;

• les documents internes validés priment sur les contenus externes ;

• une information contradictoire doit être signalée ;

• une politique locale prime sur une règle générique ;

• une action sensible nécessite une validation humaine.

Cette hiérarchie évite les réponses construites à partir d’un document secondaire, ancien ou trop général.

Elle aide aussi les équipes à mieux contrôler la logique de réponse de l’agent.

Prévoir les informations manquantes

Une demande utilisateur ne contient pas toujours assez d’éléments pour répondre correctement.

Dans ce cas, l’agent doit poser une question ciblée au lieu de produire une réponse approximative.

Il peut demander :

• “De quelle commande parlez-vous ?”

• “Dans quel pays le contrat a-t-il été signé ?”

• “Pouvez-vous préciser la référence du produit ?”

• “S’agit-il d’un achat professionnel ou particulier ?”

• “Souhaitez-vous une réponse en français, allemand ou anglais ?”

Une demande de précision est parfois la réponse la plus fiable.

Elle évite de construire une réponse sur une hypothèse non vérifiée.

Organiser un comportement de repli

Un agent doit aussi savoir quoi faire lorsqu’il ne trouve pas la bonne information.

Ses instructions peuvent prévoir plusieurs étapes :

1. rechercher une seconde source ;

2. demander une précision ;

3. indiquer que les informations disponibles restent insuffisantes ;

4. proposer un transfert vers un conseiller ;

5. bloquer une action sensible sans confirmation ;

6. tracer la situation pour amélioration future.

Ce comportement de repli est essentiel pour préserver la qualité de la relation client.

Un agent fiable ne cherche pas à répondre à tout prix. Il sait reconnaître les limites du contexte disponible.

Tester les situations réellement problématiques

Un agent peut très bien répondre à une question simple et échouer lorsque la formulation change.

Les tests doivent donc aller au-delà des scénarios évidents.

Il faut tester les demandes ambiguës, les questions incomplètes, les références erronées, les politiques expirées, les sources contradictoires et les cas qui nécessitent une intervention humaine.

Une campagne de test utile peut inclure :

• une question couverte par la documentation ;

• la même demande formulée avec d’autres mots ;

• une question dont la réponse est absente ;

• une demande qui mélange plusieurs sujets ;

• une référence produit incorrecte ;

• une politique expirée ;

• deux sources contradictoires ;

• une demande nécessitant des droits particuliers ;

• une tentative de contournement des instructions ;

• un cas qui doit être transféré à un collaborateur.

Ces tests permettent d’identifier si l’erreur vient du périmètre sélectionné, des actions exécutées, des sources récupérées ou de la génération finale.

Suivre la qualité après le déploiement

Le grounding ne se règle pas une seule fois.

Les usages réels font apparaître des formulations, exceptions et cas particuliers que la phase de conception ne couvre jamais entièrement.

Après le déploiement, il faut suivre la qualité des interactions.

Les indicateurs utiles peuvent inclure :

• demandes non résolues ;

• taux d’escalade vers un humain ;

• réponses signalées comme incorrectes ;

• sources absentes ou insuffisantes ;

• questions qui reviennent souvent ;

• sujets mal orientés ;

• actions bloquées ;

• satisfaction client ou collaborateur.

Ces informations alimentent ensuite l’amélioration continue : ajustement des instructions, mise à jour des documents, ajout de métadonnées, correction d’un topic, amélioration d’un Flow ou enrichissement d’une bibliothèque.

Le grounding devient alors un cycle continu :

observer, identifier les écarts, corriger les sources ou les règles, tester, redéployer.

Un enjeu clé pour les entreprises suisses

Les entreprises suisses qui déploient des agents IA Salesforce doivent concilier automatisation, qualité de service, confidentialité, multilingue et maîtrise des processus.

Le grounding joue un rôle central dans cet équilibre.

Il permet à l’agent de répondre à partir des bonnes données, dans le bon contexte, avec les bonnes règles.

Cette fiabilité demande un travail structuré sur plusieurs dimensions :

• qualité des données CRM ;

• gouvernance documentaire ;

• structuration des articles Knowledge ;

• définition des topics ou subagents ;

• instructions précises ;

• filtres de recherche ;

• règles de priorité entre les sources ;

• tests positifs et négatifs ;

• supervision après déploiement.

Un agent bien groundé peut répondre, poser une question complémentaire, préparer une action, exécuter une tâche autorisée ou transférer la demande à un collaborateur.

Il agit dans un cadre clair, avec une meilleure capacité à gérer les cas réels.

Construire des agents Salesforce fiables avec SIWAY Suisse

Le grounding donne aux agents IA Salesforce le contexte nécessaire pour produire des réponses utiles et cohérentes.

Sa qualité dépend autant de la technologie que de la préparation métier : données fiables, sources actualisées, règles explicites, périmètres clairs, tests représentatifs et supervision continue.

Pour les entreprises suisses, cette préparation est indispensable avant tout déploiement à grande échelle.

Chez SIWAY Suisse, nous accompagnons les organisations dans la mise en place d’agents IA Salesforce : cadrage des cas d’usage, structuration des données, configuration Agentforce, intégration CRM, gouvernance documentaire, tests et déploiement progressif.

Vous souhaitez sécuriser vos premiers cas d’usage Agentforce ?
Échangeons sur vos données, vos processus et les réponses que vos agents IA doivent être capables de produire.