Déployer Agentforce dans Salesforce : méthode complète pour structurer un agent IA d’entreprise

Déployer un agent IA dans Salesforce ne consiste pas à activer une fonctionnalité.

Ce n’est pas non plus ajouter un chatbot sur un site web.

Le guide officiel de Salesforce montre quelque chose de beaucoup plus structuré : il propose une méthodologie complète de développement d’agent IA, pensée pour l’entreprise.

Et cette différence change tout.

Dans cet article, nous allons voir ensemble les cinq étapes définies par Salesforce afin de comprendre ce que chaque étape implique réellement, pourquoi elle est indispensable et comment l’aborder intelligemment.

Pourquoi Agentforce n’est pas un chatbot classique

Avant d’entrer dans les étapes, clarifions un point essentiel.

Salesforce définit un agent comme étant un assistant autonome orienté objectif capable d’exécuter des tâches, d’interagir avec des données métier et de respecter des garde-fous de sécurité.

Un agent Agentforce peut donc :

• peut initier une séquence d’actions,
• interroger des objets Salesforce,
• exécuter des flows,
• générer des réponses contextualisées,
• transférer une conversation vers un humain selon des règles définies.

Il ne suit pas un script conversationnel figé.

Il opère dans un cadre structuré :

• Topics → ce qu’il est autorisé à faire
• Actions → comment il le fait
• Guardrails → ce qu’il ne doit jamais faire

C’est une architecture d’orchestration IA + logique métier.

Étape 1 – Concevoir : cadrer le projet avant d’ouvrir Setup

Salesforce insiste lourdement sur cette phase. Et ce n’est pas anodin.

La majorité des projets IA échouent ici :

On commence par la technologie au lieu de commencer par le travail à déléguer.

Définir le “Job To Be Done”

Décrivez précisément le travail que l’agent va accomplir.

Exemple :

• Répondre aux FAQ produit
• Rechercher une requête
• Résumer une requête
• Ajouter un commentaire
• Créer une nouveau requête

Chaque tâche est listée explicitement.

Pourquoi cette granularité est importante ?

Parce qu’un agent ne doit pas être “généraliste”.
Il doit être conçu pour accomplir un périmètre défini.

Commencer petit : pourquoi un agent ne doit pas tout faire dès le départ

Quand on parle d’IA, la tentation est forte : autant tout automatiser tout de suite.

C’est précisément ce qu’il faut éviter.

Un agent IA apprend et s’ajuste.
Plus son périmètre est large dès le début, plus il devient difficile :

• à tester,
• à encadrer,
• à sécuriser,
• à mesurer.

L’approche la plus saine consiste à commencer par un périmètre volontairement limité.

Par exemple :

Au lieu de couvrir toutes les demandes support, on peut commencer par répondre aux questions fréquentes sur un seul produit.

Une fois que cela fonctionne correctement (réponses fiables, escalades maîtrisées, données bien exploitées) on élargit progressivement :

• à une gamme complète,
• puis à d’autres familles de produits,
• puis à des actions plus complexes.

Cette progression a trois avantages concrets :

1. La valeur est mesurable rapidement.
   On peut observer le taux de résolution ou le volume de demandes traitées.
2. Les risques restent contrôlables.
   Si un problème apparaît, il concerne un périmètre limité.
3. La gouvernance reste simple.
   Moins de sujets = moins de zones d’ambiguïté.

Un agent trop ambitieux dès le départ devient difficile à piloter. Il multiplie les exceptions, les cas limites et les interactions imprévues.

Commencer petit n’est pas une contrainte technique. C’est une stratégie de maîtrise.

Évaluer la "Data Readiness" : 

Salesforce demande explicitement : La donnée est-elle prête ?

Ce n’est pas une formalité. Ils insistent sur :

• la qualité
• la complétude
• l’accessibilité
• la gouvernance
• et la conformité

Un agent qui répond à partir d’un PDF mal structuré ou d’un CRM mal maintenu produira des réponses instables. Agentforce ne corrige pas une mauvaise data. Il l’expose.

Anticiper les risques avec le framework People / Business / Technology / Data

Avant de construire un agent IA, il faut se poser une question simple :

Qu’est-ce qui pourrait mal se passer ?

Un agent ne se contente pas de répondre à des questions.

Il interagit avec des clients, manipule des données et peut déclencher des actions dans le CRM. Son impact est réel.

Ignorer les risques en amont revient à déplacer le problème en production.

Pour structurer la réflexion, il est utile d’analyser les risques sous quatre angles.

1. L’impact humain

Un agent peut être techniquement performant… et mal accepté.

Certains clients préfèrent parler à un humain.

Certaines équipes peuvent percevoir l’IA comme une menace ou une remise en question de leur rôle.

Si cette dimension est négligée, l’adoption sera faible.

Cela suppose de prévoir :

• une présentation claire de l’agent (transparence sur le fait qu’il s’agit d’une IA),
• une possibilité simple de basculer vers un humain,
• un accompagnement interne pour clarifier son rôle.

2. L’impact organisationnel

Un agent modifie les flux de travail.

Si une partie des demandes est automatisée :

• les KPI évoluent,
• la charge des équipes change,
• la responsabilité en cas d’erreur doit être définie.

Un projet IA peut échouer non pas pour des raisons techniques, mais parce qu’il perturbe des équilibres organisationnels.

3. Les limites technologiques

Un agent génératif n’est pas déterministe.

Il peut :

• reformuler différemment une même réponse,
• manquer de précision,
• mal interpréter un contexte ambigu.

Tout ne doit pas être laissé au modèle.

Certaines actions (comme créer ou modifier un enregistrement) doivent rester strictement encadrées par des règles métier (flows, validations, permissions).

L’IA doit compléter la logique métier, pas la remplacer.

4. La protection des données

Un agent agit avec un utilisateur Salesforce dédié.

Il doit respecter :

• les permissions objet,
• les règles de partage,
• les contraintes réglementaires,
• les politiques de confidentialité.

Sans contrôle précis, il peut exposer des informations sensibles ou accéder à des données qu’il ne devrait pas voir.

C’est souvent le risque le plus sous-estimé.

Étape 2 – Construire : une architecture hybride, pas un simple assistant IA

Une fois le périmètre défini, la construction peut commencer.

Mais Agentforce ne consiste pas à “brancher un modèle d’IA”. Il repose sur une architecture précise, intégrée au cœur de Salesforce.

C’est cette architecture qui rend l’agent exploitable en contexte entreprise.

Avant même de créer un agent, certains éléments doivent être activés :

• Lightning Experience
• Einstein Generative AI
• Data Cloud

Les fondations techniques : pourquoi Agentforce n’est pas isolé

Ce point est important : Agentforce ne fonctionne pas seul.

Il s’appuie sur :

• Data Cloud pour gérer la couche de données, les journaux d’événements et le suivi de consommation.
• Einstein Trust Layer pour encadrer la sécurité et la gouvernance.
• Prompt Templates pour orchestrer la génération de contenu.

Autrement dit, l’agent n’est pas un composant externe. Il s’inscrit dans l’architecture Salesforce existante.

Topics : définir clairement ce que l’agent est autorisé à faire

Un agent Agentforce est structuré autour de “topics”.

Un topic représente un domaine d’intervention. Par exemple : support FAQ, gestion des requêtes, escalade.

Chaque topic contient :

• un nom clair,
• une description permettant à l’agent d’identifier quand l’utiliser,
• un périmètre précis (ce qu’il peut ou ne peut pas faire),
• des instructions détaillées,
• une liste d’actions associées.

Les instructions jouent un rôle central.

Elles définissent :

• le ton des réponses,
• les limites à ne pas dépasser,
• les situations nécessitant une escalade,
• les exceptions.

Un topic mal défini ne crée pas un petit dysfonctionnement. Il crée un agent imprévisible.

Actions : connecter l’IA aux processus métier

Les topics donnent un cadre. Les actions donnent la capacité d’agir.

Chaque action repose sur une brique Salesforce existante :

• un Flow autolaunched,
• une classe Apex,
• un prompt template,
• une API externe.

C’est ici que l’architecture hybride apparaît. Certaines actions sont déterministes : elles exécutent une logique métier précise via Flow ou Apex. Le résultat est fiable et reproductible.

D’autres sont génératives : elles utilisent un modèle LLM pour résumer, reformuler ou analyser.

Le point clé est simple :

Le modèle ne remplace pas la logique métier. Il l’assiste.

Par exemple :

• Créer une requête → Flow déterministe
• Résumer l’historique d’une requête→ action générative

C’est cette combinaison qui rend l’agent exploitable dans un environnement enterprise. On garde le contrôle sur les opérations critiques, tout en bénéficiant de la flexibilité du LLM.

Data Library : éviter les réponses improvisées

Un agent génératif peut produire des réponses plausibles mais incorrectes s’il n’est pas correctement alimenté.

Pour éviter cela, Agentforce permet de créer une Data Library.

Le principe est simple :

• importer un document (par exemple un PDF),
• générer automatiquement un index,
• permettre à l’agent de s’appuyer sur ce contenu via l’action “Answer Questions with Knowledge”.

Cela implémente une logique de RAG (retrieval-augmented generation).

Mais un point reste fondamental :

La qualité des réponses dépend directement de la qualité du contenu fourni.

Un agent n’est jamais plus fiable que sa base documentaire.

Si les informations sont obsolètes, imprécises ou mal structurées, l’agent le sera aussi.

L’Agent User : sécurité intégrée par conception

Chaque agent dispose de son propre utilisateur Salesforce.

Ce n’est pas un détail.

Cet utilisateur possède :

• un profil spécifique,
• un ensemble de permissions (permission sets),
• un rôle dans la hiérarchie.

L’agent agit donc comme un utilisateur réel.

Il doit respecter :

• les règles de partage,
• les permissions objet,
• les contraintes de sécurité.

Il est recommandé de lui attribuer uniquement les accès strictement nécessaires.

Pourquoi ?

Parce qu’un agent peut lire, créer ou modifier des données. Sans contrôle précis, il pourrait accéder à plus d’informations que prévu.

Cette approche garantit que l’IA reste intégrée à la gouvernance Salesforce existante, et non au-dessus d’elle.

Étape 3 – Tester : valider avant d’exposer

Un agent peut sembler fonctionner en environnement de test. Mais tant qu’il n’a pas été confronté à des scénarios réels, il reste fragile.

Tester un agent ne consiste pas seulement à vérifier qu’il répond.

Il faut vérifier :

• qu’il déclenche les bonnes actions,
• qu’il respecte les permissions,
• qu’il escalade correctement,
• qu’il produit des résultats cohérents.

Concrètement, cela implique plusieurs niveaux de validation.

D’abord, tester les flows et les actions en utilisant l’utilisateur dédié à l’agent. Cela permet de s’assurer qu’il dispose exactement des accès nécessaires, ni plus, ni moins.

Ensuite, contrôler les entrées et sorties : les données sont-elles correctement interprétées ? Les réponses correspondent-elles au contexte métier ?

Les scénarios d’escalade doivent également être simulés : l’agent transfère-t-il au bon moment ? Le résumé transmis à l’humain est-il clair et exploitable ?

Enfin, l’analyse des journaux d’événements permet de comprendre ce que l’agent a réellement fait. C’est indispensable pour détecter des comportements inattendus.

Pourquoi autant de rigueur ?

Parce qu’un agent mal testé peut :

• créer des enregistrements incorrects,
• formuler des réponses imprécises,
• exposer des informations sensibles,
• ou échouer sans que personne ne le remarque immédiatement.

Un agent n’est pas un gadget. Il agit sur vos processus.

Il doit donc être testé comme n’importe quel composant critique du système.

Étape 4 – Déployer : connecter intelligemment aux bons canaux

Une fois validé, l’agent peut être exposé.

Mais le déploiement ne se limite pas à la simple activation.

Il faut définir :

• où il intervient,
• comment il interagit avec les utilisateurs,
• comment il coopère avec les équipes humaines.

Dans un contexte web, cela passe par la configuration d’Enhanced Web Chat. Un formulaire pré-chat peut être ajouté pour collecter des informations essentielles avant même que la conversation commence.

Les URL autorisées doivent être définies avec précision. Les règles d’escalade doivent être configurées.

Et surtout : les équipes doivent être préparées.

Un agent qui transfère une conversation sans résumé clair crée de la frustration. Un transfert mal routé ralentit le traitement.

L’escalade n’est pas un échec de l’IA. C’est une composante normale du système.

Un bon déploiement repose donc sur une question simple :

Quand l’agent doit-il s’arrêter et passer la main ?

Si cette réponse n’est pas claire, l’expérience client se dégrade.

Étape 5 – Monitorer : un agent n’est jamais “terminé”

Le déploiement n’est pas la fin du projet. Un agent IA est un système vivant. Il évolue avec :

• les données,
• les usages,
• les questions des clients,
• les mises à jour des produits.

Il doit donc être suivi.

Cela passe par l’analyse des interactions, des journaux d’audit et des indicateurs de performance.

Parmi les métriques pertinentes :

• le taux de demandes résolues sans intervention humaine,
• le temps moyen de traitement,
• la satisfaction client,
• la qualité du routage vers les équipes.

Sans monitoring, un agent peut se dégrader progressivement :

• réponses moins précises,
• données obsolètes,
• escalades mal configurées,
• évolution des usages non prise en compte.

L’optimisation continue fait partie intégrante du cycle.

Agentforce n’est pas un assistant conversationnel expérimental. C’est une couche IA intégrée à l’architecture Salesforce, pensée pour fonctionner avec vos données, vos processus et votre gouvernance.

Si vous travaillez déjà sur Salesforce et envisagez un projet Agentforce, l’enjeu n’est pas d’aller vite, mais d’aller juste. Nos experts vous accompagnent pour cadrer le périmètre, sécuriser les priorités et structurer une mise en œuvre adaptée à votre contexte.