Agentforce et qualité des données Salesforce : le guide de préparation avant votre premier agent IA

Un agent Agentforce n'ignorera pas poliment vos données douteuses, il agira dessus avec assurance. Si un contact a quitté l'entreprise il y a deux ans, si un produit porte trois noms différents, si une procédure PDF n'est plus valable, vos commerciaux expérimentés contournent l'incohérence sans le dire. Un agent IA, lui, ne contourne rien. Il lit le CRM comme une vérité, répond en quelques secondes et peut déclencher une action réelle sur le mauvais enregistrement avant que personne ne s'en aperçoive. La bonne première question d'un projet Agentforce n'est donc pas « quel agent construisons-nous ? », elle est « quelles données cet agent doit-il pouvoir croire, pour quelle décision, avec quelle fraîcheur, sous quelles permissions ? »

Ce guide décrit la méthode concrète que nous utilisons chez Digital Stratify pour vérifier si une org Salesforce est prête pour un pilote Agentforce, sans transformer le projet en programme de nettoyage CRM de deux ans.

Pourquoi Agentforce révèle sans pitié la dette du CRM

Les utilisateurs expérimentés compensent chaque jour les défauts d'un CRM. Ils savent quel champ n'est plus utilisé, vérifient dans Outlook, demandent à un collègue si la procédure est toujours valable. Un agent exécute ce qu'on lui donne. Plus il travaille vite, plus il reproduit vite une incohérence, à l'échelle.

Salesforce classe d'ailleurs les problèmes de données parmi les causes principales de réponses Agentforce incomplètes ou peu pertinentes : valeurs absentes ou anciennes, relations incohérentes entre enregistrements, synchronisations en retard, mauvais mappings. Le risque ne se limite pas à une réponse fluide mais fausse. Un mauvais contexte peut produire :

• Une action déclenché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
• Une information exposée à un utilisateur qui ne devait pas la voir
• Une réponse client qui cite une procédure obsolète

Le premier bénéfice, parfois inconfortable, d'un chantier Agentforce est de rendre visibles des problèmes que les équipes contournaient depuis des mois. C'est une bonne nouvelle, à condition de les détecter avant la mise en production.

Les trois couches de contexte qu'il faut vraiment 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, et chacune échoue différemment.

1. Les données structurées du CRM

Comptes, contacts, opportunités, dossiers, contrats, commandes, objets personnalisés. Pour chaque champ que l'agent lira, vous devez pouvoir répondre à quatre questions : définition, propriétaire, source de vérité, délai acceptable de mise à jour.

Un champ rempli à 98 % n'est pas automatiquement fiable, s'il est en saisie libre et qu'il pilote une action, deux orthographes suffisent à créer deux comportements. À l'inverse, un champ rempli à 60 % peut convenir, à condition que l'agent sache explicitement quoi faire quand la valeur est absente.

2. Les connaissances non structurées

Articles Knowledge, PDF, procédures, notes internes et fichiers alimentent les réponses de l'agent sur les 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 la santé de l'index.

Une base de connaissances n'est pas une archive. Elle doit contenir des contenus exacts, lisibles, datés et non contradictoires. Quand deux procédures sont techniquement valides, l'une héritée, l'autre à jour, la bibliothèque doit indiquer 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 strictement maîtrisé. Testez le parcours de bout en bout avec l'utilisateur technique réellement attribué à l'agent, pas avec un profil System Administrator qui voit tout.

Cette troisième couche change la catégorie de risque. Un agent qui suggère une réponse tolère une validation humaine. Un agent qui modifie une adresse de facturation exige des données de référence, des permissions minimales, un contrôle et une piste d'audit. Confondez ces deux cas et vous livrerez un incident, pas un assistant.

Les six indicateurs d'une donnée « prête pour un agent »

Avant d'écrire un prompt, construisez un tableau de bord limité aux données du cas d'usage. Six chiffres comptent :

1. Complétude, les champs indispensables sont-ils présents ? Mesurez par segment pertinent (comptes stratégiques, cas urgents), pas seulement en moyenne globale.
2. Unicité, combien de doublons potentiels existent sur les personnes, sociétés ou dossiers que l'agent manipulera ?
3. Fraîcheur, quelle part des enregistrements a été vérifiée dans le délai utile au processus ?
4. Cohérence, les statuts, relations et valeurs se contredisent-ils entre objets ou systèmes ?
5. Traçabilité, sait-on qui produit chaque donnée, quand elle a changé et quelle source prévaut en cas de conflit ?
6. Actionnabilité, la donnée permet-elle de choisir une action déterministe, ou seulement de formuler une hypothèse ?

Chaque indicateur doit être relié à une conséquence métier. « 12 % de téléphones manquants » est une observation. « L'agent ne peut pas proposer de rappel sur 12 % des dossiers prioritaires » est un risque exploitable. Pour une vision plus large de la santé de votre 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

Fuyez les briefs vagues du type « aider les commerciaux » ou « répondre aux clients ». Choisissez une transition précise : qualifier une demande entrante, proposer un article Knowledge, préparer un résumé de compte, ou créer une tâche après validation humaine. Décrivez aussi ce que l'agent ne doit jamais faire, cette frontière détermine les données, les permissions et les contrôles requis.

Étape 2, Cartographier le contexte minimal

Listez chaque champ, objet, document et système 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 empêche le projet de dériver en 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 étroit.

É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 d'enregistrements réels, un taux global peut masquer un segment critique comme les comptes stratégiques ou les cas urgents. Conservez cette baseline : elle prouvera après go-live que le pilote a réellement amélioré le processus.

Étape 4, Corriger, puis 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, règles de doublons, layouts simplifiés, propriétaire nommé pour les mises à jour. Si le travail humain s'améliore même en cas de pause du pilote IA, le test de valeur est passé.

É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 par article. 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, un PDF bien mis en page mais ambigu reste une mauvaise source.

Étape 6, Tester les droits et les actions

N'attribuez à l'utilisateur de l'agent que les accès nécessaires. En sandbox, testez chaque action avec des cas normaux, des valeurs absentes, des doublons, un accès refusé et une indisponibilité d'intégration. Le test doit valider le refus propre, pas seulement le succès. Un agent fiable sait dire « je ne peux pas conclure » et transmet le dossier avec le contexte utile.

Étape 7, Construire un jeu de tests métier

Préparez des questions et enregistrements 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 déclencheur d'escalade. Le Testing Center d'Agentforce et les analyses de conversations permettent ensuite de rejouer ce jeu à chaque changement de prompt, de modèle, de source ou d'automatisation, et de détecter les régressions avant vos clients.

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, et 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 prépare 30 cas de test : dossier complet, contact parti, deux comptes homonymes, contrat expiré, pièce inaccessible, demande contradictoire, intégration indisponible.

Le succès ne se mesure pas à « la réponse a l'air intelligente ». Il se mesure ainsi : sources correctement citées, zéro action non autorisée, taux d'escalade pertinent, réduction du temps de préparation, et, surtout, zéro écriture sur le mauvais enregistrement.

Faut-il tout nettoyer avant de commencer ? Non.

Attendre une base parfaite retarde le projet indéfiniment. Mais lancer sur une base non mesurée transforme le pilote en démonstration fragile. Le bon compromis consiste à borner un cas d'usage, mesurer la qualité du contexte dont il a réellement besoin, et corriger ce qui changerait la décision de l'agent, ni plus, ni moins.

Si plusieurs sources doivent être rapprochées, la question de Salesforce Data Cloud (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 à grande échelle. Pour aller plus loin, voir notre guide sur l'implémentation de Salesforce Data Cloud.

Les métriques à suivre après le lancement

Suivez peu d'indicateurs, mais reliez chacun à un résultat métier :

• Taux de réponses correctes sur le jeu de tests métier
• 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 vs erreurs évitées
• Fraîcheur et complétude des champs critiques
• Coût par dossier réellement résolu

Une automatisation qui rédige en dix secondes et exige ensuite dix minutes de relecture n'a pas encore créé de gain. Intégrez toujours le rework, c'est la métrique que vous demandera un directeur financier.

Spécificités régionales pour déployer Agentforce en Europe et en Amérique du Nord

• France : la CNIL est l'une des autorités les plus actives d'Europe et a publié des recommandations spécifiques sur la transparence des IA ; la consultation du CSE est standard quand l'agent touche des processus impliquant les salariés. Voir notre page Salesforce France.
• Allemagne : l'application de la DSGVO est décentralisée et rigoureuse, et les comités d'entreprise interviennent typiquement sur tout workflow assisté par IA. Voir Salesforce Allemagne.
• Belgique & Luxembourg : les acteurs du secteur financier superposent les régulations sectorielles (BNB, CSSF) au RGPD, les cas d'usage Agentforce touchant des données clients requièrent une documentation formelle d'externalisation et de risque IA. Voir Belgique et Luxembourg.
• Suisse : la nLPD révisée reflète étroitement le RGPD et ajoute des attentes spécifiques sur la décision automatisée, prévoyez des parcours de revue humaine explicites. Voir Suisse.
• États-Unis & Canada : des régimes locaux (California CPRA, Colorado AI Act) et la Loi 25 du Québec imposent déjà des obligations de transparence et d'opt-out sur les décisions assistées par IA. Voir États-Unis et Canada.

Partout où vous déployez, le même principe s'applique : l'AI Act européen et ses équivalents régionaux ajoutent des obligations de transparence et de documentation en plus de la protection des données. Concevez pour les deux dès le départ, les rétrofiter après lancement, c'est là que la plupart des projets Agentforce perdent leur sponsor.

Questions fréquentes

Faut-il Salesforce Data Cloud pour déployer Agentforce ?

Non. Beaucoup de premiers pilotes tournent uniquement sur le CRM cœur et une bibliothèque de connaissances curée. Data Cloud (Data 360) prend de la valeur quand l'agent doit rapprocher plusieurs systèmes source dans une vue unique, mais il ne remplace pas les définitions de données, règles de rapprochement et gouvernance qu'il faut encore poser.

Quel score de qualité des données faut-il pour Agentforce ?

Il n'y a pas de seuil universel. Ce qui compte, c'est la qualité du petit ensemble de champs, enregistrements et documents que l'agent spécifique va réellement lire. Un cas d'usage étroit sur des données à 90 % de qualité bat systématiquement un cas large sur des données à 60 %.

Combien de temps prend un audit de préparation Agentforce ?

Un audit de préparation ciblé sur un cas d'usage prend généralement deux à quatre semaines : baseline, revue des connaissances, tests de permissions, liste priorisée de corrections. Il est conçu pour précéder, pas retarder, le pilote.

Quelle est la plus grosse erreur des équipes sur Agentforce ?

Cadrer le cas d'usage trop largement. « Aider les commerciaux » n'est pas un cas d'usage ; « résumer les 90 derniers jours d'activité sur les comptes stratégiques avant la QBR » en est un. Une décision étroite et observable est ce qui rend la qualité des données mesurable et le succès démontrable.

Commencez par un audit de préparation, pas par un prompt

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é. Notre audit Salesforce peut être cadré spécifiquement pour la préparation 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. Réservez un appel stratégique gratuit de 30 minutes pour cadrer le vôtre.