Un agent IA peut répondre vite, résumer un dossier et déclencher une action. Il ne sait pourtant pas deviner qu’un contact a quitté son entreprise, qu’un produit porte trois noms différents ou qu’une procédure PDF n’est plus valable. Si ces incohérences existent dans Salesforce, Agentforce les reçoit comme du contexte. Il peut alors produire une réponse fluide, mais fondée sur une donnée fausse.
La bonne question n’est donc pas seulement « quel agent voulons-nous construire ? ». Elle est aussi : « quelles données cet agent doit-il pouvoir croire, pour quelle décision, avec quel niveau de fraîcheur et sous quels droits ? »
Ce guide propose une méthode concrète pour évaluer la préparation de Salesforce avant un projet Agentforce. L’objectif n’est pas de nettoyer tout le CRM. Il est de fiabiliser le petit ensemble de données, de connaissances et d’actions nécessaires au premier cas d’usage.
Pourquoi Agentforce révèle les défauts du CRM
Un utilisateur expérimenté compense souvent les défauts d’un CRM. Il connaît le champ qui n’est plus utilisé, vérifie une information dans Outlook et demande à un collègue si la procédure est encore valable. Un agent exécute ce qui lui a été donné. Plus il travaille vite, plus il peut reproduire vite une incohérence.
Salesforce classe d’ailleurs les problèmes de données parmi les causes courantes de réponses Agentforce incomplètes ou peu pertinentes : valeurs absentes ou anciennes, relations incohérentes entre enregistrements, synchronisations en retard et mauvais mappings. Son guide de résolution des erreurs Agentforce recommande de contrôler la complétude, les mappings et l’état des flux de données.
Le risque ne se limite pas à une mauvaise réponse. Une donnée incertaine peut aussi provoquer :
- une action lancée sur le mauvais compte ;
- une recommandation fondée sur un statut périmé ;
- un doublon créé au lieu de mettre à jour la bonne fiche ;
- l’exposition d’une information à un utilisateur qui ne devait pas la voir ;
- une réponse client qui cite une procédure obsolète.
Le premier bénéfice d’un chantier Agentforce est parfois de rendre visibles des problèmes que les équipes contournaient depuis des mois.
Les trois couches de contexte à contrôler
La « qualité des données » ne se résume pas aux champs obligatoires. Un agent Salesforce s’appuie généralement sur trois couches différentes.
1. Les données structurées du CRM
Ce sont les comptes, contacts, opportunités, dossiers, contrats, cas et objets spécifiques. Pour chaque champ utilisé par l’agent, il faut connaître sa définition, son propriétaire, sa source et son délai acceptable de mise à jour.
Un champ rempli à 98 % n’est pas forcément fiable. S’il est saisi librement alors qu’il pilote une action, deux orthographes peuvent suffire à créer deux comportements. À l’inverse, un champ rempli à 60 % peut convenir si l’agent sait traiter explicitement la valeur absente.
2. Les connaissances non structurées
Les articles Knowledge, documents, procédures et fichiers servent à répondre à des questions plus complexes. La documentation Salesforce sur les bibliothèques de données Agentforce insiste sur la structure des documents, les champs d’identification, les droits d’accès et l’état de l’index de recherche.
Une bibliothèque n’est pas une archive. Elle doit contenir des contenus exacts, lisibles, datés et sans contradiction. Deux procédures valides à des périodes différentes doivent annoncer clairement laquelle s’applique aujourd’hui.
3. Les actions et les permissions
Un agent peut lire juste et agir faux si le Flow, l’API ou la règle métier qu’il appelle n’est pas maîtrisé. Il faut tester le parcours avec l’utilisateur technique réellement attribué à l’agent, pas seulement avec un administrateur. Le guide officiel de context engineering pour Agentforce rappelle que données, permissions, actions, prompts et sources RAG doivent rester cohérents, puis être testés ensemble.
Cette troisième couche change le niveau de risque. Un agent qui suggère une réponse peut tolérer une validation humaine. Un agent qui modifie une adresse de facturation exige une donnée de référence, des permissions minimales, un contrôle et une trace.
Les six indicateurs d’une donnée prête pour un agent
Avant tout développement, construisez un tableau de bord limité aux données du cas d’usage.
- Complétude : les champs indispensables sont-ils présents ? Mesurez par segment pertinent, pas seulement sur toute la base.
- Unicité : combien de doublons potentiels existent sur les personnes, sociétés ou dossiers que l’agent manipulera ?
- Fraîcheur : quelle part des enregistrements a été vérifiée dans le délai utile au processus ?
- Cohérence : les statuts, relations et valeurs se contredisent-ils entre objets ou systèmes ?
- Traçabilité : sait-on qui produit la donnée, quand elle a changé et quelle source prévaut ?
- Actionnabilité : la donnée permet-elle de choisir une action déterministe ou seulement de formuler une hypothèse ?
Ces indicateurs doivent être reliés à une conséquence métier. « 12 % de téléphones manquants » est une observation. « L’agent ne peut pas proposer un rappel sur 12 % des dossiers prioritaires » est un risque exploitable.
Pour mesurer plus largement la santé de l’org, notre grille sur les indicateurs de dette technique Salesforce complète ce diagnostic ciblé.
Une méthode en sept étapes avant le premier pilote
Étape 1 : définir une décision observable
Évitez « répondre aux clients » ou « aider les commerciaux ». Choisissez une transition précise : qualifier une demande entrante, proposer un article de connaissance, préparer un résumé de compte ou créer une tâche après validation.
Décrivez aussi ce que l’agent ne doit jamais faire. Cette frontière détermine les données, les permissions et le niveau de contrôle requis.
Étape 2 : cartographier le contexte minimal
Listez les champs, objets, documents et systèmes nécessaires à cette seule transition. Pour chaque élément, notez : source, propriétaire, fréquence de mise à jour, sens métier et règle en cas de contradiction.
Cette cartographie évite un projet de nettoyage infini. L’agent n’a pas besoin de toutes les données de l’entreprise. Il a besoin de données suffisantes et fiables pour son mandat.
Étape 3 : mesurer une baseline
Créez des rapports Salesforce qui exposent les valeurs absentes, doublons, statuts anciens et relations orphelines. Prélevez aussi un échantillon de dossiers réels. Un taux global peut masquer un segment critique, par exemple les comptes stratégiques ou les cas urgents.
Conservez cette baseline : elle servira à prouver que le pilote améliore réellement le processus.
Étape 4 : corriger et prévenir
Corrigez d’abord les erreurs qui changeraient la décision de l’agent. Ajoutez ensuite les contrôles qui empêchent leur retour : listes de valeurs, règles de validation proportionnées, contrôles de doublons, écrans simplifiés et responsabilité de mise à jour.
Le chantier doit améliorer le travail humain même si le pilote IA s’arrête. C’est un bon test de valeur.
Étape 5 : curer la connaissance
Retirez les documents périmés, séparez les sujets, ajoutez une date de validité et désignez un propriétaire. Préférez plusieurs contenus courts et cohérents à un classeur historique impossible à interpréter.
Salesforce recommande une connaissance précise, complète, actuelle, organisée et cohérente pour améliorer la récupération de contexte. Un fichier séduisant mais ambigu reste une mauvaise source.
Étape 6 : tester les droits et les actions
Attribuez à l’utilisateur de l’agent uniquement les accès nécessaires. Testez chaque action en bac à sable avec des cas normaux, des valeurs absentes, des doublons, un accès refusé et une indisponibilité d’intégration.
Le test doit vérifier le refus propre, pas seulement le succès. Un agent fiable sait dire qu’il ne peut pas conclure et transmettre le dossier avec le contexte utile.
Étape 7 : construire un jeu de tests métier
Préparez des questions et dossiers représentatifs avant la mise en production. Pour chaque cas, définissez la réponse attendue, les sources autorisées, l’action permise et le motif d’escalade.
Le Testing Center d’Agentforce et les analyses de conversations servent ensuite à vérifier les régressions lorsque les prompts, modèles, sources ou automatisations changent.
Exemple : un agent qui prépare le traitement d’un dossier client
Imaginons un agent chargé de résumer un dossier et de proposer la prochaine action au responsable du compte. Son contexte minimal peut comprendre :
- le compte et ses contacts actifs ;
- les demandes ouvertes et leurs priorités ;
- le dernier échange significatif ;
- le contrat ou périmètre applicable ;
- les procédures internes validées ;
- les tâches déjà planifiées.
Avant le pilote, l’équipe mesure la part de contacts sans rôle, de demandes sans priorité, de tâches en doublon et de documents sans date de validité. Elle crée ensuite 30 cas de test : dossier complet, contact parti, deux comptes homonymes, contrat expiré, pièce inaccessible, demande contradictoire et intégration indisponible.
Le succès n’est pas « la réponse semble intelligente ». Il se mesure ainsi : sources correctement utilisées, absence d’action non autorisée, taux d’escalade pertinent, réduction du temps de préparation et zéro modification sur le mauvais enregistrement.
Faut-il nettoyer tout Salesforce avant de commencer ?
Non. Attendre une base parfaite retarde indéfiniment le projet. Déployer sur une base non mesurée transforme en revanche le pilote en démonstration fragile.
Le bon compromis consiste à choisir un cas d’usage borné, calculer la qualité du contexte correspondant et corriger ce qui influence réellement la décision. Cette approche rejoint notre retour sur les prérequis d’Agentforce dans une PME et notre guide pour choisir un premier cas d’usage Agentforce.
Si plusieurs sources doivent être rapprochées, la question de Data 360 peut ensuite se poser. Mais un outil d’unification ne remplace ni la définition des données, ni les règles de rapprochement, ni la gouvernance. Il rend ces décisions exécutables à plus grande échelle.
Les métriques à suivre après le lancement
Suivez peu d’indicateurs, mais reliez-les au résultat attendu :
- taux de réponses correctes sur le jeu de tests ;
- taux de réponses sans source ou avec source inadéquate ;
- taux d’escalade vers un humain ;
- actions proposées, validées, refusées et annulées ;
- temps humain économisé, corrections comprises ;
- erreurs créées ou évitées ;
- fraîcheur et complétude des données critiques ;
- coût par dossier réellement traité.
Une automatisation qui rédige en dix secondes puis exige dix minutes de vérification n’a pas encore créé de gain. Le calcul doit toujours intégrer la relecture et le rework.
Commencer par un diagnostic utile
Agentforce n’exige pas un grand programme de données avant chaque pilote. Il exige une définition claire du résultat, un contexte maîtrisé et des tests qui reflètent la réalité.
Cloud Girafe peut réaliser un audit Salesforce centré sur le cas d’usage Agentforce : données critiques, connaissances, droits, actions, risques et plan de pilote. Vous obtenez une liste priorisée de ce qu’il faut corriger avant d’investir dans la configuration, sans transformer le projet en nettoyage général du CRM.
