La Réponse Courte
Les actions sont le point où un agent cesse de parler pour passer à l'acte, concentrant ainsi la majeure partie du risque et du coût de maintenance. Il y a quatre méthodes de mise en œuvre : les actions standard, Flow, Apex et les services externes via une API. Le choix entre ces méthodes ne dépend pas de leur capacité — presque toutes les actions sont possibles avec chacune d'elles — mais plutôt de qui en assurera la maintenance, de la rapidité avec laquelle elles peuvent être modifiées et de la manière dont elles sont testées.
L'ordre de préférence recommandé est de commencer par le haut : privilégier une action standard, passer à Flow lorsque la logique métier le requiert, à Apex lorsque la complexité est réelle, et aux services externes lorsque la source de vérité se trouve hors de Salesforce. Chaque descente dans cette hiérarchie ajoute des coûts de maintenance et doit donc être justifiée.
Tableau de Décision
| Implémentation | Quand est-ce approprié ? | Qui maintient ? | Coût de l'option |
|---|---|---|---|
| Action Standard | Récupération, mise à jour de champ, ouverture de Case, résumé d'enregistrement | Administrateur de la plateforme | Flexibilité limitée pour les règles métier |
| Flow | Règles métier changeantes, processus en plusieurs étapes, validation | Admin ou propriétaire du processus | Exécution à haut volume, gestion limitée des erreurs |
| Apex | Logique complexe, traitement intensif, gestion des erreurs | Développeur uniquement | Chaque modification nécessite un cycle de déploiement et de test |
| Services Externes / API | La source de vérité est en dehors de Salesforce | Équipe d'intégration | Dépendance à la disponibilité, la latence et la gestion des versions du tiers |
La Première Règle : Décrire avant d'Implémenter
Avant de choisir une technologie, il est essentiel de rédiger une description de l'action. Cela peut sembler procédural, mais c'est le facteur clé qui déterminera si l'agent déclenchera la bonne action. L'agent ne lit pas le code ; il lit la description et prend sa décision en conséquence.
Une bonne description comprend trois parties : ce que fait l'action, dans quelles situations elle doit être utilisée, et explicitement dans quelles situations elle ne doit pas l'être. La troisième ligne est souvent oubliée, mais c'est elle qui empêche l'agent d'activer une action de remboursement lorsque le client ne fait que s'informer sur la politique de remboursement.
Les paramètres doivent être minimaux et de types bien définis. Un paramètre de texte libre où l'agent est censé saisir une valeur d'une liste fermée est une invitation à l'erreur ; une liste de valeurs prédéfinies y remédie sans logique supplémentaire.
Quand Utiliser Flow et Quand Apex
Flow est la solution par défaut pour les règles métier, car il est visuellement intuitif et permet au propriétaire du processus de comprendre ce qui se passe. Pour les agents, un avantage supplémentaire est la rapidité de correction : si l'action ne vérifie pas une condition d'éligibilité, la correction peut être apportée le jour même.
Apex se justifie dans quatre situations : logique avec de nombreuses ramifications qui rendrait un Flow illisible, traitement de gros volumes en une seule opération, besoin d'un contrôle précis sur la gestion des erreurs et des transactions, et intégration nécessitant un traitement de réponse complexe. En dehors de ces situations, Apex tend principalement à augmenter le coût de la prochaine modification.
Le choix est également lié à la dette technique existante. Une organisation qui gère déjà des milliers de lignes de code Apex sans tests devrait y réfléchir à deux fois avant d'ajouter une nouvelle couche – les considérations complètes sont détaillées dans Flow vs Apex.
Actions avec des Systèmes Externes
C'est le domaine où les défaillances atteignent l'utilisateur final. Trois décisions doivent être prises avant le développement : quel est le temps d'attente maximum, que dit l'agent en cas d'échec de l'appel, et s'il est permis de réessayer.
L'idempotence est le concept crucial. Une action de lecture peut être relancée en toute sécurité. Une action qui crée un enregistrement, envoie un message ou débite une carte – une nouvelle tentative risquerait de créer des doublons. La solution est une clé unique pour chaque requête que le système récepteur identifie, ou l'abandon conscient de la tentative de répétition.
La latence est une considération d'expérience utilisateur et pas seulement technique. Un appel prenant quelques secondes est acceptable dans un canal de chat si l'agent indique qu'il est en train de vérifier ; un appel plus long nécessite un chemin asynchrone – l'agent confirme la réception et met à jour lorsque la réponse arrive.
Les stratégies pour gérer les échecs d'intégration sont détaillées dans Traitement des erreurs d'intégration dans Salesforce.
Chaque action doit être limitée par une autorisation distincte. L'erreur courante est d'accorder à l'agent un profil large qui couvre toutes les actions, ce qui ne permet pas d'ouvrir une action spécifique à un groupe sans ouvrir toutes les autres.
Le principe de travail : autorisation minimale pour chaque action, validation au sein de l'action et pas seulement dans les instructions pour l'agent, et vérification que l'action respecte le contexte de l'utilisateur. Il ne faut pas se fier au fait que les instructions empêcheront l'activation – les instructions sont une orientation, pas un contrôle.
Quand Diviser une Action
Une action qui accomplit trois choses est difficile à tester et à approuver. Les signes à considérer pour une division : quand une partie de l'action nécessite une approbation humaine et l'autre non, quand différentes parties requièrent des autorisations différentes, ou quand un échec au milieu laisse le processus dans un état incohérent.
La division augmente légèrement le coût d'orchestration mais s'avère rentable : chaque partie est testée séparément, l'agent peut faire une pause entre les parties, et les autorisations sont précises. La règle pratique : une action, une décision.
La planification des points d'arrêt entre les parties est détaillée dans Human-in-the-Loop dans Agentforce.
Cas d'Étude : Une Organisation Passant d'Apex à Flow
Une entreprise de services a construit six actions en Apex lors d'un projet pilote, partant du principe que cela lui donnerait un contrôle total. En deux mois, il est apparu que quatre d'entre elles avaient vu leur logique modifiée trois fois chacune – non pas en raison de bugs, mais parce que les règles métier étaient encore en phase de maturation. Chaque modification exigeait un développeur, des tests et un cycle de déploiement de plusieurs jours.
Lors de la deuxième phase, les deux actions restantes en Apex étaient celles impliquant de multiples appels à un système externe et un traitement de réponse complexe. Les quatre autres ont été migrées vers Flow, et l'administrateur de la plateforme en est devenu responsable. Le temps moyen de correction est passé de jours à des heures.
La leçon n'était pas qu'Apex était mauvais, mais qu'à un stade où les règles sont encore en cours de formation, le coût de la modification est plus important que le coût initial de développement.
Risques et Actions Préventives
| Risque | Comment il se manifeste | Action Préventive |
|---|---|---|
| Description d'action ambiguë | L'agent active la mauvaise action | Description avec "quand oui" et "quand non" et paramètres définis |
| Réessai aveugle | Enregistrements ou débits en double | Clé unique par requête ou abandon de l'option de réessai |
| Autorisation large pour l'agent | Action sensible accessible à tout utilisateur | Autorisation distincte pour chaque action et validation au sein de l'action |
| Toute la logique en Apex | Chaque changement métier devient un projet de développement | Flow pour les règles évolutives, Apex pour une vraie complexité |
| Action réalisant trois choses | Échec au milieu laissant un état incohérent | Division selon le jugement et les autorisations |
Mesures pour les Actions
| Mesure | Ce qu'elle révèle | Fréquence |
|---|---|---|
| Taux de succès des actions | Pourcentage d'activations réussies | Hebdomadaire |
| Taux d'action incorrecte | Pourcentage de cas où une action incorrecte a été choisie | À chaque version |
| Latence médiane par action | L'expérience reste-t-elle raisonnable ? | Hebdomadaire |
| Taux d'échecs d'intégration | Stabilité des systèmes cibles | Hebdomadaire |
| Temps moyen de correction | L'implémentation choisie permet-elle un changement rapide ? | Mensuel |
Lorsque vous avez besoin d'un accompagnement pour la planification de la couche d'actions et son adaptation à l'architecture existante, le service Agentforce et IA est la voie pratique à suivre.
Liste de Contrôle pour Chaque Action
- ☐ Description rédigée avec "quoi", "quand oui" et "quand non"
- ☐ Paramètres minimaux et de types définis
- ☐ Implémentation choisie au niveau le plus élevé suffisant pour le besoin
- ☐ Autorisation distincte définie pour l'action
- ☐ Validation effectuée au sein de l'action et non seulement dans les instructions
- ☐ Détermination de l'idempotence de l'action et de la politique de réessai
- ☐ Temps d'attente maximum et message d'échec définis pour l'utilisateur
- ☐ Actions à multiples prises de décision divisées
- ☐ Scénario de test existant pour l'échec et pas seulement le succès