Intégration Agentforce : prérequis de données, cas d’usage et déroulé

La démonstration s’est bien passée, la décision de principe est prise. Reste la question pratique : que faut-il préparer pour qu’Agentforce fonctionne chez vous, par où commencer, et qui peut le faire ?

La réponse commence par ce que l’agent va lire. Il ne connaît de votre entreprise que ce que contient votre org Salesforce, et il le restitue avec aplomb : si la fiche indique un contrat actif alors qu’il a été résilié, il le dira au client sans hésiter. Cet article part donc des données.

Ce que recouvre une intégration Agentforce

Agentforce se branche sur votre org, pas à côté

Les agents vivent dans votre org et utilisent ses objets, ses droits et ses automatisations. Ce qu’ils savent faire est décrit sur notre page consacrée à Agentforce ; ici, on s’intéresse à leur mise en place chez vous.

Un agent se configure par sous-agents — les tâches qu’il prend en charge, appelées « rubriques » jusqu’en avril 2026 — et par actions — ce qu’il peut faire : retrouver une commande, créer une requête. Ces actions s’appuient sur ce qui existe déjà dans l’org : flows, code Apex, modèles de prompt. Intégrer, c’est relier un agent à des données et à des processus que vous avez déjà.

Ce que fait une agence d’intégration

• Le cadrage. Le processus confié à l’agent, et sa limite.
• Les données. Repérer les objets que l’agent lit, mesurer leur état, corriger avant l’ouverture.
• Les actions. Relier chaque action à un flow ou à une règle existante, plutôt que de recréer la logique dans l’agent.
• Les tests. Rejouer des demandes réelles et ajuster les instructions.
• La mise en production. Ouvrir petit, lire les conversations, élargir.

Ce qu’elle ne remplace pas

Le responsable métier du processus. L’agence écrit les instructions, mais ne peut pas décider seule de ce qu’un client a le droit d’obtenir ni du moment où un conseiller reprend la conversation. Sans responsable nommé, l’agent hérite des zones grises du processus et les tranche au hasard des formulations.

Les prérequis de données

Les objets que l’agent lit selon le cas d’usage

• Suivi d’une demande. Les requêtes, les comptes et contacts rattachés, et les articles de connaissance qui expliquent délais et procédures.
• Qualification de leads. Les leads, les comptes existants et les règles d’attribution.
• Prise de rendez-vous. Les contacts, les agendas et les règles de disponibilité.
• Mise à jour de dossier. L’objet modifié lui-même, et les champs qui déclenchent des automatisations en aval.

Un agent ne lit jamais « Salesforce » en général, mais une poignée d’objets et de champs : la préparation porte sur ce périmètre, pas sur toute la base.

Quatre défauts qui font répondre faux

• Le champ vide. La date de fin de contrat manque : l’agent ne répond pas, ou déduit une réponse d’un autre champ.
• Le champ périmé. Le statut est resté « Actif » après la résiliation : l’agent annonce un contrat en cours.
• Le doublon. Deux comptes pour le même client : l’agent lit le premier et ignore les requêtes ouvertes sur le second.
• Le droit trop large. L’agent voit une remise négociée ou une note interne, et rien ne l’empêche de la citer.

Vos équipes contournent ces défauts tous les jours. L’agent ne contourne pas : il lit.

Un conseiller se méfie d’une fiche suspecte, un agent la récite.

Droits et périmètre de l’agent

Un agent de service client agit avec les droits d’un utilisateur dédié, créé avec un accès minimal, auquel on attribue des ensembles d’autorisations. C’est le levier pour borner ce qu’il voit et modifie : un agent de suivi des demandes n’a aucune raison de lire les opportunités. La règle par défaut : le minimum, élargi à la demande.

Les garde-fous de Salesforce, comme l’absence de conservation des données par le fournisseur du modèle ou la piste d’audit, ne remplacent pas ce réglage : ils protègent la conversation, pas votre modèle de droits. Le masquage des données sensibles, lui, est désactivé pour les agents.

Le rôle de Data 360, l’ex-Data Cloud

Salesforce demande que Data 360 — le nouveau nom de Data Cloud — soit provisionné dans l’org avant d’activer Agentforce. Tant que l’agent répond à partir des objets Salesforce et de vos articles de connaissance, l’enjeu reste la qualité de ces objets. Data 360 prend un rôle central quand l’agent s’appuie sur des sources plus larges : des documents, des données d’un ERP, l’historique d’un client réparti entre plusieurs systèmes. Ce que votre contrat inclut dépend de vos licences et évolue : vérifiez-le auprès de Salesforce.

Data 360 unifie les données, il ne les corrige pas : une adresse fausse dans l’ERP reste fausse une fois remontée.

Un socle de données avant l’agent

C’est le métier de turnK, la société de notre groupe dédiée à la fiabilisation des données. Chez Mirakl, l’équipe a nettoyé les doublons et les informations obsolètes, corrigé la synchronisation entre HubSpot et Salesforce, puis posé des règles de gouvernance durables. Ce n’était pas un projet Agentforce, mais c’est exactement le socle qu’un agent suppose.

Vos données Salesforce ne sont pas prêtes ? turnK les fiabilise.

Choisir le premier cas d’usage

Le module en tête d’article fait ce choix pour votre situation. Voici le raisonnement qui le sous-tend.

Commencer par une demande fréquente, encadrée, réversible

• Fréquente. Elle revient assez souvent pour qu’un pilote produise vite des conversations à lire.
• Encadrée. La bonne réponse est écrite quelque part — une procédure, un statut, une règle — et ne dépend pas d’un jugement.
• Réversible. Si l’agent se trompe, l’erreur se corrige sans dommage : une information à rectifier, un rendez-vous à déplacer, pas un remboursement émis.

Critère souvent oublié : à valeur comparable, prenez le cas d’usage dont les fiches sont déjà tenues à jour.

Service client : le suivi d’une demande en cours

« Où en est ma demande ? » L’agent retrouve la requête, lit son statut et explique la suite à partir d’un article de connaissance. À contrôler : le statut des requêtes, le rattachement au bon contact, les articles sur les délais. La question décisive : le statut est-il mis à jour à chaque étape, ou seulement à la clôture ? Dans le second cas, l’agent répondra « en cours » jusqu’au dernier jour.

Ventes : qualifier les leads entrants et prendre rendez-vous

Un lead arrive par un formulaire. L’agent pose les questions de qualification, vérifie si l’entreprise est déjà cliente et propose un créneau au bon commercial. Le défaut le plus coûteux est le doublon : un client existant requalifié comme prospect reçoit un discours de découverte, et son commercial n’en sait rien.

Ce qu’il vaut mieux garder pour plus tard

• Les actions irréversibles. Rembourser, résilier, supprimer : tant que l’agent n’a pas fait ses preuves, un humain valide.
• Les gestes commerciaux. Une remise engage l’entreprise, et sa règle est rarement assez écrite.
• Les données sensibles. Santé, banque, RH : le cadre juridique se tranche avant le pilote.

Le déroulé d’une intégration

Deux pistes en parallèle, les données et l’agent, qui se rejoignent avant l’ouverture aux clients.

Cadrer le processus et la limite d’action de l’agent

Quelques décisions écrites : le processus confié à l’agent, les demandes qu’il refuse, les actions qu’il exécute, le moment où il passe la main. C’est ce document que l’on relit quand une réponse surprend.

Contrôler et corriger les données qu’il mobilise

On liste les objets et les champs lus par l’agent, puis on les mesure : remplissage, date de dernière mise à jour, doublons, droits. Ce qui est faux est corrigé ; ce qui se dégrade est confié à un responsable. Un statut que personne n’est chargé de tenir redeviendra faux.

Construire les actions à partir des flows existants

Si un flow crée déjà une requête ou reprogramme une intervention, l’action de l’agent doit l’appeler, pas le réécrire : quand la règle change, l’agent et les conseillers changent ensemble. Repérez au passage les automatisations obsolètes, à désactiver avant qu’un agent ne les déclenche.

Tester sur des conversations réelles et prévoir l’escalade

On teste sur des demandes réellement reçues, avec leurs fautes de frappe et leurs changements de sujet, pas sur les scénarios de la démonstration. Pour chaque réponse : la donnée lue, l’action déclenchée, le ton. L’escalade se teste aussi : quand l’agent ne sait pas, la conversation arrive dans une file identifiée, avec son historique.

Piloter sur un périmètre réduit, puis élargir

Premier lancement en interne, pour les conseillers, ou sur un seul canal et un seul type de demande. On lit les conversations, on corrige, puis on ouvre aux clients. On élargit ensuite sujet par sujet, en refaisant chaque fois le passage par les données.

On n’ouvre pas l’agent aux clients tant que ses données ne sont pas contrôlées.

Choisir une agence Agentforce

Les démonstrations des agences se ressemblent, leurs méthodes beaucoup moins.

Les questions à poser

1. Que faites-vous de nos données avant de construire l’agent ? Une réponse sérieuse cite des objets, des champs et une méthode de contrôle.
2. Sur quelles conversations testez-vous ? Les vôtres, réellement reçues, ou des scénarios écrits pour l’occasion.
3. Qui garde la main sur les réponses ? Qui modifie les instructions après la mise en production.
4. Comment mesurez-vous ? Quels indicateurs, relevés avant le lancement, permettront de comparer après.

Les signaux d’alerte

• Une démo sans vos données. Elle ne dit rien de ce que l’agent fera sur votre org.
• Aucun plan sur les données. Le planning passe du cadrage à la construction : la préparation est supposée faite, ou laissée à votre charge.
• Un gain chiffré promis d’avance. Personne ne peut annoncer un taux de résolution avant d’avoir regardé vos demandes et vos fiches.

Chez StackEasy, nous accompagnons des projets Agentforce en commençant par là : les objets que l’agent lira, leur état, ce qu’il faut corriger. Quand le chantier de données dépasse l’agent, turnK prend le relais.

Par où commencer

Pas par le choix des licences. Par un seul processus et un état des lieux court : la demande la plus fréquente de votre service client ou de vos ventes, les objets qu’elle mobilise, leur état réel, et la personne qui reprendra la main quand l’agent ne saura pas. Ce travail rend le projet chiffrable et protège le lancement contre une réponse sûre d’elle appuyée sur une fiche périmée.

Pour aller plus loin : ce qu’est un agent IA et comment il fonctionne en entreprise, comment corriger les doublons sans recréer le problème, ou parcourez notre page Salesforce.