Agentforce : comment choisir la bonne action pour son agent ?

Créer un agent dans Agentforce ne consiste pas seulement à définir les sujets qu’il peut traiter et à lui donner des instructions.

Très vite, une autre question se pose : que doit-il être capable de faire concrètement lorsqu’il comprend la demande de l’utilisateur ?

Rechercher une information dans Salesforce, créer un enregistrement, modifier une donnée, déclencher un processus, générer un contenu personnalisé, effectuer un calcul ou encore interroger un système externe : selon le besoin, la manière de construire l’action ne sera pas la même.

Et c’est souvent à ce moment que la configuration devient moins évidente.

Salesforce met à disposition des actions standard, mais permet également de créer ses propres actions à partir de Flow, de Prompt Builder ou d’Apex. Ces possibilités donnent beaucoup de souplesse à Agentforce, mais elles obligent aussi à faire des choix d’architecture.

Faut-il utiliser une action déjà disponible ? Construire un Flow ? Créer un Prompt Template ? Passer par Apex ?

Pour répondre à cette question, il faut repartir du besoin que l’agent doit traiter.

Du Topic à l’action : comment Agentforce organise les capacités d’un agent

Avant de comparer les différents types d’actions, il est utile de comprendre leur place dans la construction d’un agent.

Dans les premières versions d’Agentforce Builder, Salesforce utilisait notamment trois notions : Topics, Instructions et Actions.

Depuis avril 2026, les Topics sont appelés Subagents. Salesforce précise qu’il s’agit principalement d'un changement de terminologie : leur fonction reste d’organiser les différents jobs que l’agent est capable de prendre en charge.

On peut donc représenter simplement la logique de construction ainsi :

Subagent → Instructions → Actions

Le Subagent définit un périmètre de travail.

Par exemple :

• gérer une demande concernant une commande ;
• accompagner un commercial sur une opportunité ;
• traiter une demande de support ;
• rechercher des informations sur un compte client.

Les Instructions précisent ensuite la manière dont l’agent doit se comporter dans ce contexte : les règles à respecter, les informations à demander, les situations dans lesquelles une action doit être utilisée ou encore la manière de gérer certaines exceptions.

Enfin, les Actions correspondent aux outils dont dispose l’agent pour accomplir réellement une tâche. Salesforce décrit d’ailleurs les actions comme les outils permettant aux agents d’effectuer leur travail.

Un agent peut donc comprendre qu’un utilisateur souhaite consulter une commande grâce au Subagent concerné et à ses instructions. Mais pour récupérer réellement les informations de cette commande, il doit disposer d’une action capable d’accéder aux données nécessaires.

Cette distinction est importante :

Les instructions orientent le raisonnement et l’utilisation des capacités de l’agent ; les actions lui permettent d’exécuter une tâche.

Pourquoi le choix de l’action Agentforce est important

Pour un même besoin, plusieurs solutions techniques peuvent parfois sembler possibles.

Imaginons qu’un agent doit prendre en charge une demande de remboursement.

On pourrait être tenté de :

• créer une action Apex ;
• construire un Flow ;
• utiliser une action standard existante ;
• ou intégrer une partie du traitement directement dans les instructions de l’agent.

Pourtant, ces solutions ne répondent pas aux mêmes besoins.

Un Flow est particulièrement adapté lorsqu’il existe un processus métier structuré à exécuter.

Apex devient intéressant lorsque la logique nécessite davantage de développement ou des traitements spécifiques.

Un Prompt Template répond plutôt à un besoin de génération, de synthèse ou d’interprétation de contenu.

Et dans certains cas, Salesforce fournit déjà une action qui réalise tout ou une partie du travail demandé.

Le choix ne devrait donc pas commencer par :

« Quelle action Agentforce puis-je créer ? »

Mais plutôt par :

« Que doit réellement accomplir mon agent ? »

Cette différence paraît simple, mais elle évite de transformer progressivement un agent en accumulation d’actions difficiles à comprendre, à tester et à maintenir.

Commencer par vérifier les actions standard disponibles dans Agentforce

Avant de créer une nouvelle action, le premier réflexe devrait être de vérifier si la fonctionnalité existe déjà dans la bibliothèque d’actions Agentforce.

Salesforce fournit des actions standard pouvant être utilisées par les agents. Certaines sont disponibles de manière générale, tandis que d’autres sont liées à des produits, des clouds, des licences ou des permissions spécifiques.

Elles peuvent par exemple permettre à un agent de rechercher ou de manipuler certaines informations Salesforce, selon son contexte et les fonctionnalités activées dans l’organisation.

L’intérêt est double.

D’abord, cela évite de recréer une fonctionnalité déjà disponible.

Ensuite, cela permet de rester davantage dans les mécanismes standards de la plateforme, généralement plus faciles à maintenir lors des évolutions de l’organisation Salesforce.

Dans quel cas privilégier une action standard ?

Une action standard doit être regardée en priorité lorsque le besoin correspond à une opération Salesforce relativement classique.

Par exemple :

• retrouver des informations sur un enregistrement ;
• récupérer certaines données Salesforce ;
• effectuer une opération déjà prévue par Agentforce ;
• utiliser une capacité standard liée à Sales Cloud, Service Cloud ou à un autre produit Salesforce.

La question à se poser est donc :

« Agentforce sait-il déjà faire cette opération avant que nous la reconstruisions ? »

Si la réponse est oui, il faut généralement commencer par tester cette possibilité avant de développer une action personnalisée.

Mais les processus propres à chaque entreprise vont rapidement nécessiter des comportements spécifiques. C’est là qu’interviennent les actions personnalisées.

Les actions personnalisées : Flow, Prompt Template ou Apex ?

Salesforce permet d’étendre les capacités d’un agent avec des actions personnalisées reposant notamment sur Flow, Prompt Templates et Apex.

Ces trois mécanismes ne sont pas interchangeables.

Pour choisir entre eux, il faut comprendre le type de travail que l’on souhaite confier à l’agent.

Flow : lorsque l’agent doit exécuter un processus métier

Flow est souvent le premier mécanisme à envisager lorsqu’un agent doit déclencher une automatisation dans Salesforce.

Un Flow permet d’enchaîner des opérations structurées : récupérer des informations, vérifier des conditions, créer ou modifier des enregistrements, déclencher d’autres automatisations ou encore retourner un résultat à l’agent.

Salesforce montre par exemple comment un Flow autolaunched peut être exposé comme action Agentforce afin qu’un agent crée un enregistrement à partir des informations reçues au cours de la conversation.

Exemples de besoins adaptés à Flow

Un agent pourrait utiliser une action basée sur Flow pour :

• créer un Case à partir d’une demande client ;
• mettre à jour le statut d’un Lead ;
• créer une tâche pour un commercial ;
• enregistrer une demande de rappel ;
• vérifier plusieurs conditions avant de modifier un enregistrement ;
• déclencher un processus de validation ou de traitement existant ;
• récupérer des données dans plusieurs objets Salesforce avant de retourner un résultat.

Prenons un exemple simple.

Un utilisateur explique à un agent qu’il souhaite être rappelé par un commercial.

L’agent peut :

1. identifier les informations nécessaires ;
2. demander les données manquantes ;
3. déclencher une action ;
4. transmettre les informations au Flow ;
5. laisser le Flow créer la tâche ou la demande correspondante dans Salesforce.

Ici, le rôle de l’agent est principalement conversationnel : comprendre le besoin et collecter les données.

Le Flow reste responsable du processus métier.

Pourquoi cette séparation est intéressante

Elle permet de ne pas déplacer inutilement toute la logique de l’entreprise dans les instructions de l’agent.

Si une règle existe déjà dans Salesforce, elle peut continuer à vivre dans les automatisations prévues pour cela.

L’agent devient alors un nouveau point d’entrée vers ces processus.

C’est une distinction particulièrement importante lorsque les mêmes automatisations doivent aussi être utilisées par d’autres interfaces, utilisateurs ou processus Salesforce.

Quand Flow devient-il moins adapté ?

Flow n’est pas nécessairement le meilleur choix lorsque le traitement nécessite :

• une logique algorithmique particulièrement complexe ;
• des traitements techniques difficiles à maintenir dans Flow ;
• certaines intégrations spécifiques ;
• ou du code qui existe déjà et qu’il serait inutile de reproduire.

Dans ces situations, Apex peut devenir plus pertinent.

Prompt Template : lorsque l’agent doit générer ou transformer du contenu

Toutes les actions ne consistent pas à créer ou modifier des enregistrements.

Un agent peut également devoir produire un résultat à partir de plusieurs informations.

C’est le rôle que peuvent jouer les Prompt Templates, construits avec Prompt Builder.

Salesforce permet d’exposer un Prompt Template comme action afin qu’il puisse être appelé par un agent.

Cette approche est particulièrement utile lorsque le résultat recherché n’est pas une opération déterministe classique, mais une production reposant sur un modèle de langage.

Exemples de besoins adaptés à un Prompt Template

Un agent pourrait utiliser un Prompt Template pour :

• générer une synthèse d’un compte client ;
• préparer un résumé avant un rendez-vous commercial ;
• rédiger une réponse personnalisée ;
• transformer plusieurs informations Salesforce en texte exploitable ;
• analyser des données textuelles ;
• reformuler une réponse en fonction d’un contexte donné ;
• générer une recommandation à partir de plusieurs éléments.

Imaginons un agent destiné aux équipes commerciales.

Un utilisateur lui demande :

« Peux-tu me préparer un résumé de ce compte avant mon rendez-vous ? »

L’agent peut commencer par récupérer les informations nécessaires : données du compte, opportunités en cours, activités récentes ou autres éléments disponibles.

Un Prompt Template peut ensuite recevoir ces informations et produire une synthèse structurée suivant des instructions définies à l’avance.

Le Prompt Template ne remplace donc pas nécessairement les actions permettant de récupérer les données.

Il peut intervenir après elles, pour transformer les informations récupérées en résultat exploitable.

Flow et Prompt Template peuvent travailler ensemble

Le choix entre Flow et Prompt Template n’est pas toujours exclusif.

Un Flow peut récupérer ou préparer certaines données puis appeler un Prompt Template.

Inversement, un agent peut enchaîner plusieurs actions selon le besoin.

Le point important reste de bien séparer les responsabilités :

• Flow exécute un processus structuré ;
• Prompt Template produit ou transforme du contenu à partir d’instructions et de contexte.

Cette séparation permet généralement de mieux comprendre le fonctionnement de l’agent et de tester chaque composant indépendamment.

Apex : lorsque le besoin nécessite une logique plus spécifique

Apex permet d’aller plus loin lorsqu’une action nécessite du développement.

Salesforce permet d’exposer une méthode Apex invocable afin qu’elle devienne disponible comme action personnalisée dans Agentforce Builder.

Cela ne signifie pas qu’Apex doit devenir le choix par défaut dès qu’une action semble un peu complexe.

Au contraire.

Si le besoin peut être correctement couvert par une action standard ou un Flow simple, ajouter du code peut augmenter inutilement la maintenance.

Apex devient surtout pertinent lorsque le besoin justifie réellement une implémentation spécifique.

Exemples de besoins adaptés à Apex

On peut par exemple envisager Apex pour :

• appliquer une logique métier complexe difficile à exprimer dans Flow ;
• réaliser certains calculs spécifiques ;
• manipuler ou transformer des structures de données particulières ;
• réutiliser une logique Apex déjà existante ;
• gérer une intégration nécessitant un traitement personnalisé ;
• appeler un service tiers dans un scénario qui nécessite une implémentation spécifique.

Dans l’un de ses ateliers Agentforce, Salesforce utilise par exemple une action Apex pour permettre à un agent d’appeler une API externe.

Apex ou Flow ?

Cette question revient régulièrement dans les projets Salesforce, même en dehors d’Agentforce.

Le raisonnement reste assez proche.

Si le processus est clair, déclaratif et peut être correctement maintenu avec Flow, il n’est pas nécessaire de développer du code simplement parce que l’action sera utilisée par un agent.

En revanche, si Flow oblige à construire une automatisation extrêmement complexe pour contourner ses limites, Apex peut offrir une architecture plus lisible.

Le bon choix dépend donc aussi de l’existant Salesforce.

Une organisation disposant déjà d’une logique métier Apex éprouvée n’a pas forcément intérêt à la reconstruire dans Flow uniquement pour Agentforce.

En résumé : quelle action Agentforce choisir ?

Voici une première grille de lecture.

Besoin de l’agent	Solution à regarder en priorité
Réaliser une opération déjà couverte par Agentforce	Action standard
Rechercher ou manipuler des données avec une capacité déjà disponible	Action standard
Déclencher un processus métier Salesforce	Flow
Créer ou mettre à jour des enregistrements avec plusieurs règles	Flow
Orchestrer plusieurs étapes déterministes	Flow
Générer un texte à partir de données et d’instructions	Prompt Template
Résumer ou reformuler des informations	Prompt Template
Produire une réponse personnalisée reposant sur un modèle de langage	Prompt Template
Exécuter une logique métier complexe	Apex
Réutiliser une logique technique existante	Apex
Réaliser une intégration nécessitant du développement spécifique	Apex

Cette grille n’est pas une règle absolue.

Un même cas d’usage peut utiliser plusieurs mécanismes.

Un agent peut par exemple :

rechercher une information → déclencher un Flow → appeler un Prompt Template → retourner le résultat à l’utilisateur.

L’objectif n’est donc pas de chercher une technologie unique pour tout le Subagent.

Il faut déterminer quelle responsabilité appartient à chaque action.

Une méthode simple pour choisir la bonne action

Plutôt que de commencer directement dans Agentforce Builder, on peut utiliser quelques questions pour cadrer le besoin.

1. Que doit produire l’action ?

La première question concerne le résultat attendu.

L’action doit-elle :

• récupérer une information ?
• créer quelque chose ?
• mettre à jour une donnée ?
• exécuter un processus ?
• générer un contenu ?
• effectuer un calcul ?
• appeler un autre système ?

Cette première étape permet déjà d’écarter plusieurs options.

Si l’objectif consiste simplement à produire un résumé personnalisé, construire un Flow complexe n’est probablement pas le meilleur point de départ.

À l’inverse, si l’action doit créer plusieurs enregistrements en respectant des règles précises, un simple Prompt Template ne peut pas porter cette responsabilité.

2. Une action standard existe-t-elle déjà ?

Avant tout développement, il faut vérifier les capacités disponibles dans l’Asset Library.

C’est particulièrement important dans un environnement comme Agentforce, qui évolue rapidement et dont la bibliothèque d’actions continue de s’enrichir.

Créer une action personnalisée pour reproduire une capacité standard ajoute de la complexité sans nécessairement apporter de valeur.

3. Le résultat doit-il être déterministe ?

C’est probablement l’un des critères les plus importants.

Certaines opérations doivent toujours produire un résultat prévisible.

Par exemple :

si toutes les conditions sont réunies, créer une demande avec les champs A, B et C puis mettre son statut à “Nouveau”.

Ce type de logique doit idéalement être porté par des mécanismes déterministes comme Flow ou Apex.

À l’inverse :

« Produire une synthèse claire de l’historique du client en cinq lignes »

nécessite une capacité de génération.

Le Prompt Template devient alors beaucoup plus naturel.

Cette distinction permet également de déterminer ce qui peut être laissé au raisonnement de l’agent et ce qui doit être contrôlé par la plateforme.

4. Cette logique existe-t-elle déjà dans Salesforce ?

Agentforce ne doit pas automatiquement conduire à reconstruire l’existant.

Supposons qu’un Flow permette déjà à un conseiller de créer une demande de remboursement en vérifiant plusieurs critères.

Si l’agent doit désormais permettre à un utilisateur d’effectuer la même demande, il peut être préférable de réfléchir à la réutilisation de ce processus plutôt que de construire une deuxième logique uniquement pour Agentforce.

Le même raisonnement vaut pour Apex.

Les agents doivent autant que possible s’intégrer à l’architecture Salesforce existante plutôt que créer une couche parallèle difficile à maintenir.

5. L’action sera-t-elle réutilisée ailleurs ?

Une autre question concerne le périmètre de réutilisation.

Une logique peut être utile :

• à plusieurs Subagents ;
• à plusieurs agents ;
• dans Salesforce en dehors d’Agentforce ;
• dans un Flow ;
• depuis une autre application.

Salesforce permet d’ailleurs de créer des actions dans l’Asset Library afin de les rendre disponibles plus largement, tandis qu’une action créée directement depuis un agent peut être limitée à cet agent et à sa version.

Penser à la réutilisation dès la conception évite de multiplier les actions presque identiques.

Les instructions d’action sont aussi importantes que l’action elle-même

Créer le bon Flow ou le bon code Apex ne suffit pas.

L’agent doit également comprendre quand utiliser l’action, quelles informations lui fournir et comment interpréter son résultat.

Une action Agentforce possède notamment un nom et des instructions en langage naturel qui aident l’agent à déterminer comment et quand l’utiliser.

Cette couche est essentielle.

Prenons deux actions :

• Create Support Case
• Create Commercial Request

Techniquement, elles peuvent être parfaitement construites.

Mais si leurs descriptions restent vagues, l’agent peut avoir des difficultés à déterminer laquelle utiliser lorsqu’un utilisateur demande :

« J’ai un problème avec mon contrat et j’aimerais être rappelé. »

Les instructions doivent permettre de comprendre la différence entre les deux actions.

Une bonne instruction d’action doit répondre à plusieurs questions

À quoi sert cette action ?

Son objectif doit être identifiable rapidement.

Quand doit-elle être utilisée ?

Il faut préciser le contexte attendu.

Quand ne doit-elle pas être utilisée ?

Ce point peut être particulièrement utile lorsque plusieurs actions sont proches.

Quelles données sont nécessaires ?

L’agent doit savoir quels inputs récupérer avant de lancer l’action.

Que représente le résultat ?

Les outputs doivent eux aussi être suffisamment compréhensibles.

Salesforce souligne notamment l’importance de descriptions claires pour permettre au moteur de sélectionner correctement une action, de renseigner ses entrées et d’interpréter ses sorties.

Une grande partie de la qualité d’un agent se joue donc dans la manière dont ses outils lui sont présentés.

Faut-il mettre la règle dans les instructions ou dans l’action ?

C’est une autre question importante lorsque l’on commence à concevoir des agents.

Prenons une règle métier :

les remboursements supérieurs à un certain montant doivent être validés par un responsable.

On pourrait écrire cette règle uniquement dans les instructions du Subagent.

Mais si cette condition est critique pour le processus métier, il peut être plus robuste de l’appliquer également dans la logique exécutée par Flow ou Apex.

Les instructions servent à guider le raisonnement.

Elles ne doivent pas nécessairement devenir l’unique endroit où vivent toutes les règles importantes de l’entreprise.

Une bonne approche consiste donc à distinguer :

les règles conversationnelles, qui peuvent guider le comportement de l’agent ;

et

les règles d’exécution, qui doivent être garanties par les processus et contrôles du système.

Cette distinction devient encore plus importante lorsque l’action modifie des données, déclenche une opération sensible ou interagit avec un système externe.

Et Agent Script dans tout ça ?

La nouvelle version d’Agentforce Builder ajoute une autre notion qu’il est utile de distinguer des actions : Agent Script.

Agent Script permet de combiner des instructions en langage naturel avec des expressions plus programmatiques afin de gérer des conditions, des transitions, des variables ou encore des séquences d’actions.

Il ne remplace donc pas Flow, Apex ou Prompt Builder.

Il intervient à un autre niveau.

On peut le voir comme un moyen d’améliorer l’orchestration du comportement de l’agent.

Par exemple, Agent Script peut aider à définir :

• dans quelle situation passer vers un autre Subagent ;
• si une condition doit être vérifiée avant de poursuivre ;
• dans quel ordre certaines actions doivent être exécutées ;
• comment gérer certaines variables au cours du parcours.

L’action, elle, reste l’outil qui réalise la tâche.

Cette distinction aide à ne pas mélanger trois niveaux différents :

Le Subagent définit le périmètre.

Les instructions et la logique de raisonnement organisent le comportement.

Les actions exécutent les capacités métier.

Un agent n’a pas forcément intérêt à avoir beaucoup d’actions

Puisque de nombreuses possibilités sont disponibles, on pourrait être tenté de donner à un agent un grand nombre d’actions afin qu’il puisse répondre au maximum de situations.

Ce n’est pas nécessairement la meilleure stratégie.

Plusieurs actions très proches peuvent rendre le choix plus difficile.

De même, un Subagent contenant de nombreuses branches conditionnelles et plusieurs actions exécutées successivement peut devenir plus difficile à comprendre et à tester.

Salesforce documente notamment des situations où des instructions comportant de nombreuses conditions, plusieurs prérequis et de longues séquences d’actions peuvent entraîner des comportements moins fiables.

Cela conduit à une règle de conception assez simple :

chaque action doit avoir une responsabilité identifiable.

Si deux actions semblent faire presque la même chose, il faut se demander si la différence est réellement nécessaire.

Si une action réalise dix opérations très différentes, il faut vérifier si elle ne devrait pas être découpée.

Et si un seul Subagent tente de traiter un nombre très important de parcours sans relation claire entre eux, le problème se situe peut-être plus haut dans l’architecture de l’agent.

Quelques erreurs fréquentes lors de la conception des actions Agentforce

Créer une action personnalisée avant de regarder l’existant

Le réflexe de développement peut conduire à créer immédiatement un Flow ou une classe Apex.

Pourtant, une capacité standard peut déjà répondre au besoin.

La vérification de l’Asset Library devrait donc faire partie des premières étapes de conception.

Utiliser Apex pour tous les cas complexes

Apex offre une grande liberté, mais cette liberté a un coût en développement, tests et maintenance.

Une logique qui peut être clairement exprimée et maintenue avec Flow n’a pas forcément besoin de code.

Utiliser Flow pour de la génération de contenu

Un Flow est très adapté à l’orchestration d’un processus.

En revanche, lorsqu’un résultat repose essentiellement sur de la génération, de la synthèse ou de l’interprétation de texte, Prompt Builder doit entrer dans la réflexion.

Confondre instructions et logique métier

Une phrase inscrite dans les instructions n’est pas toujours le meilleur endroit pour garantir une règle critique.

Les contraintes qui doivent impérativement être respectées doivent aussi être pensées dans l’architecture du processus, les permissions et les composants exécutés.

Donner des descriptions trop vagues aux actions

Une action appelée « Get Information » ou « Process Request » donne peu d’indications à l’agent.

Les noms, descriptions, inputs et outputs doivent permettre de comprendre précisément la responsabilité de chaque outil.

Multiplier les actions similaires

Créer Create Lead, Create New Lead, Generate Lead et Register Prospect dans un même contexte risque davantage de créer de l’ambiguïté que de rendre l’agent plus performant.

Il faut chercher à rendre les capacités clairement différenciables.

Concevoir l’action sans penser au parcours complet

Une action ne fonctionne jamais totalement seule.

Il faut aussi prévoir :

• les données dont elle a besoin ;
• la manière dont l’agent les obtient ;
• les permissions nécessaires ;
• les erreurs possibles ;
• les informations retournées ;
• ce que doit faire l’agent après l’exécution.

C’est le parcours complet qui doit être testé.

Du cas d’usage à l’action : quelques exemples

Pour rendre cette logique plus concrète, voici plusieurs besoins typiques.

« Je veux que mon agent crée une demande dans Salesforce »

Commencer par : Flow.

Le Flow peut récupérer les informations transmises par l’agent, appliquer les règles métier puis créer l’enregistrement correspondant.

Apex peut être envisagé si la logique dépasse ce qui est raisonnablement maintenable avec Flow.

« Je veux que l’agent me résume un compte avant un rendez-vous »

Plusieurs actions peuvent être nécessaires.

Une première capacité récupère les données pertinentes.

Puis un Prompt Template transforme ces informations en résumé structuré.

« Je veux que mon agent mette à jour une opportunité »

Il faut d’abord vérifier les actions standard disponibles.

Si le processus nécessite des contrôles ou plusieurs opérations spécifiques, Flow est généralement un bon candidat.

« Je veux que mon agent effectue un calcul métier complexe »

Si le calcul est simple et peut être géré dans l’automatisation existante, Flow peut suffire.

Pour une logique algorithmique ou technique plus importante, Apex peut être préférable.

« Je veux que mon agent rédige une réponse personnalisée »

Le besoin relève principalement de la génération de contenu.

Un Prompt Template permet de cadrer cette génération et de lui fournir le contexte nécessaire.

« Je veux que mon agent interroge un système externe »

Il faut d’abord regarder comment ce système est déjà intégré à l’écosystème Salesforce.

Une capacité ou intégration existante peut éventuellement être réutilisée.

Si une logique personnalisée est nécessaire, Apex peut exposer une action capable d’interagir avec le service concerné. D’autres briques de l’écosystème Salesforce, notamment les mécanismes d’intégration, peuvent également entrer dans l’architecture selon le projet.

Le meilleur choix dépend aussi de l’architecture Salesforce existante

Agentforce ne doit pas être conçu comme une application indépendante ajoutée au-dessus de Salesforce.

Sa valeur vient justement de sa capacité à s’appuyer sur les données, automatisations, règles, permissions et intégrations déjà présentes dans l’écosystème.

Le choix d’une action doit donc prendre en compte deux dimensions :

ce que l’agent doit faire ;

mais aussi :

comment l’entreprise sait déjà faire cette opération dans Salesforce.

Si un processus fiable existe déjà, l’objectif est souvent de permettre à l’agent de l’utiliser.

Si aucune automatisation n’existe, le projet Agentforce peut au contraire révéler qu’il faut d’abord structurer ce processus.

C’est aussi pourquoi la conception d’un agent ne commence pas réellement dans Agentforce Builder.

Elle commence par la compréhension des parcours, des données et des processus métier que l’on souhaite rendre accessibles à l’agent.

Action standard, Flow, Prompt Template ou Apex : le bon réflexe

Lorsqu’un nouveau besoin apparaît, on peut finalement suivre cette logique :

1. Définir précisément ce que l’agent doit accomplir.

2. Vérifier si une action standard répond déjà au besoin.

3. Si l’agent doit exécuter un processus métier structuré, regarder Flow.

4. Si le résultat nécessite de générer, synthétiser ou transformer du contenu, regarder Prompt Builder.

5. Si une logique technique ou métier spécifique nécessite du développement, envisager Apex.

6. Vérifier si plusieurs mécanismes doivent être combinés plutôt que de forcer toute la logique dans une seule action.

7. Décrire précisément l’action, ses inputs, ses outputs et les situations dans lesquelles l’agent doit l’utiliser.

8. Tester le parcours complet, et pas seulement le bon fonctionnement technique de l’action.

Cette approche permet de revenir à l’essentiel : une action Agentforce n’est pas simplement une fonctionnalité ajoutée à un agent.

C’est un point de connexion entre son raisonnement et les processus réels de l’entreprise.

Plus ce rôle est clair, plus il devient simple de choisir entre les différentes possibilités proposées par Salesforce et de construire des agents dont le comportement reste compréhensible, testable et maintenable.