Koa : comment tester un agent lorsqu'une action devient impossible ?

Un agent peut parfaitement répondre à une question lorsque toutes les informations et tous les outils sont disponibles.

Le vrai test commence lorsqu'il lui manque quelque chose.

Une donnée.
Une autorisation.
Un outil.
Une validation humaine.

Avec Koa, son nouveau modèle de raisonnement dédié aux usages CRM, Salesforce explique avoir intégré précisément ce type de situation dans l'entraînement du modèle.

L'objectif est d'apprendre à l'agent à reconnaître qu'une action sort de son périmètre, puis à adopter le bon comportement.

Une approche intéressante, car la fiabilité d'un agent se mesure autant à sa capacité à agir qu'à sa capacité à savoir quand suspendre une action.

Koa, un modèle entraîné pour les processus d'entreprise

Présenté à Dreamforce 2026, Koa est le premier modèle de raisonnement CRM développé par Salesforce pour Agentforce.

Il repose sur NVIDIA Nemotron 3 Super, puis bénéficie d'un post-entraînement réalisé par Salesforce sur des scénarios représentatifs de processus d'entreprise.

Salesforce indique avoir créé des environnements simulés couvrant plus de 14 secteurs, parmi lesquels l'industrie, les services financiers, la santé ou encore le voyage.

Dans ces environnements, des clients fictifs échangent avec l'agent. Certains sont coopératifs, d'autres frustrés. L'agent doit comprendre la demande, utiliser différents outils et poursuivre le processus jusqu'à sa résolution.

Un système d'évaluation mesure ensuite le résultat obtenu.

Le modèle répète les scénarios afin d'améliorer progressivement sa manière de raisonner et d'utiliser les outils disponibles. Salesforce explique avoir combiné fine-tuning supervisé et apprentissage par renforcement pour ce post-entraînement.

L'approche ressemble finalement à la formation d'un collaborateur.

Connaître une procédure constitue une première étape.
Savoir l'appliquer dans différentes situations constitue la suivante.

Le scénario le plus intéressant : retirer volontairement un outil

Salesforce explique avoir ajouté une difficulté particulière dans certaines simulations.

L'équipe retire volontairement l'outil dont l'agent aurait besoin pour accomplir la demande.

L'agent se retrouve alors face à une situation très courante en entreprise : il comprend l'objectif, mais une condition nécessaire à son exécution manque.

Salesforce cherche ainsi à lui apprendre plusieurs comportements : suspendre l'action, expliquer la situation, demander l'information nécessaire, reprendre le processus lorsque celle-ci devient disponible ou transmettre le dossier à un collaborateur lorsque la situation exige une décision humaine.

C'est un détail important.

Dans un environnement CRM, une réponse plausible apporte peu de valeur si l'action réelle derrière cette réponse reste impossible.

Un agent doit savoir distinguer ce qu'il comprend, ce qu'il peut proposer et ce qu'il est réellement autorisé à exécuter.

Prenons un exemple concret : un agent de service client

Imaginons un agent chargé de traiter les demandes clients dans Salesforce.

Un client lui écrit :

"J'ai été facturé deux fois. Pouvez-vous me rembourser les 450 € aujourd'hui ?"

L'agent accède au compte et retrouve bien les deux transactions.

Il connaît également la politique de remboursement.

Mais son outil lui permet uniquement de traiter automatiquement des remboursements jusqu'à 100 €. Au-delà de ce montant, une validation humaine est obligatoire.

Le raisonnement attendu devient alors relativement simple.

L'agent identifie les transactions concernées. Il vérifie les règles applicables. Il constate que le montant dépasse son niveau d'autorisation. Il prépare les informations nécessaires à la validation et transmet la demande à la personne compétente.

Le client peut recevoir une réponse du type :

"J'ai retrouvé les deux transactions concernées. Votre remboursement de 450 € nécessite une validation supplémentaire. J'ai transmis la demande avec les informations nécessaires à l'équipe en charge du remboursement."

L'agent a donc avancé aussi loin que son périmètre le permet.

Le même principe peut concerner une modification contractuelle, une remise commerciale, une suppression de données, le changement d'une commande ou encore une opération nécessitant une validation financière.

Cet exemple est volontairement générique : il illustre le principe décrit par Salesforce et ne correspond pas à un déploiement client communiqué par l'éditeur.

Tester uniquement le parcours idéal donne une vision incomplète

Lors de la conception d'un agent, les premiers tests suivent souvent le parcours attendu.

Le client formule correctement sa demande.
Les données sont disponibles.
Les outils fonctionnent.
Les autorisations sont suffisantes.

L'agent atteint alors facilement son objectif.

Un agent déployé en production rencontre une réalité beaucoup plus variée.

Situation testée	Exemple	Comportement attendu
Parcours complet	Toutes les données et tous les outils sont disponibles	Exécuter correctement l'action
Information manquante	Une référence client manque	Identifier l'information nécessaire et la demander
Outil indisponible	L'action requise reste inaccessible	Suspendre l'exécution et proposer la prochaine étape
Autorisation insuffisante	Une validation humaine est requise	Préparer le dossier et effectuer l'escalade
Situation ambiguë	Plusieurs actions pourraient répondre à la demande	Clarifier l'intention avant d'agir
Échec d'une action	Un appel à un outil échoue	Identifier l'échec et adapter la suite du processus

Ces scénarios permettent de mesurer quelque chose de plus important que la simple qualité conversationnelle : la capacité de l'agent à rester fiable lorsque le processus sort du cas idéal.

Un agent fiable doit connaître trois frontières

Pour tester concrètement un agent, trois frontières méritent une attention particulière.

La première concerne l'information.

L'agent dispose-t-il réellement des données nécessaires pour prendre sa décision ? Par exemple, il peut connaître la politique commerciale tout en ignorant le statut du contrat concerné.

La deuxième concerne les outils.

Comprendre l'action à effectuer et pouvoir l'exécuter sont deux choses différentes. Un agent peut parfaitement déterminer qu'un remboursement est justifié tout en ayant besoin d'un outil spécifique pour déclencher la transaction.

La troisième concerne les droits.

Un outil accessible peut également comporter des limites. Une action peut être autorisée jusqu'à un certain montant, pour certains profils ou après une validation particulière.

Tester ces trois frontières permet de construire des agents capables de gérer davantage de situations réelles.

Le sujet dépasse largement le choix du modèle

Koa apporte ici un angle intéressant sur l'entraînement des modèles de raisonnement.

Mais la fiabilité d'un agent repose sur un ensemble plus large.

Le modèle doit raisonner correctement.

Les données doivent fournir le contexte utile.

Les outils doivent exposer précisément les actions disponibles.

Les droits doivent déterminer ce que l'agent peut exécuter.

Les règles d'escalade doivent indiquer quand et comment transmettre une situation à un humain.

Salesforce présente d'ailleurs Koa comme une composante d'un ensemble de modèles spécialisés. Certaines tâches comme la classification d'intention, l'évaluation de texte ou le reranking peuvent être confiées à d'autres modèles, tandis que Koa prend en charge le raisonnement sur des processus en plusieurs étapes.

L'enjeu devient donc autant un sujet d'architecture que de modèle.

Comment transformer ce principe en protocole de test ?

Une entreprise qui déploie un agent peut reprendre cette logique sans entraîner son propre modèle.

Pour chaque action importante, il suffit de créer plusieurs variantes du scénario : conditions réunies, information manquante, autorisation insuffisante, outil inaccessible, résultat inattendu ou demande ambiguë.

Prenons un agent commercial chargé de modifier une opportunité.

Le test classique consiste à lui demander de modifier correctement la date de closing.

Un test plus intéressant consiste à retirer l'identifiant de l'opportunité.

Puis à lui retirer le droit de modification.

Puis à lui donner deux opportunités susceptibles de correspondre à la demande.

Puis à simuler une erreur lors de l'écriture dans Salesforce.

Chaque scénario permet d'observer la réaction de l'agent.

Cherche-t-il à clarifier la situation ?
Utilise-t-il le bon outil ?
Respecte-t-il ses autorisations ?
Explique-t-il correctement la prochaine étape ?
Transmet-il le contexte utile lorsqu'une intervention humaine devient nécessaire ?

Ce type de test rapproche beaucoup plus l'évaluation des conditions réelles d'utilisation.

Avec les agents, savoir s'arrêter devient une compétence

L'intérêt de l'approche présentée avec Koa dépasse finalement le modèle lui-même.

Plus les agents obtiennent la capacité d'agir dans les systèmes d'entreprise, plus leur évaluation doit porter sur leurs décisions.

Répondre correctement constitue une partie du problème.

Choisir le bon outil, vérifier les conditions d'exécution, respecter les autorisations et savoir transmettre une situation au bon moment deviennent tout aussi importants.

Salesforce affirme que Koa obtient de meilleurs résultats que plusieurs modèles généralistes sur ses benchmarks CRM et indique notamment moins d'erreurs sur des tâches comme la mise à jour d'une opportunité, le routage d'un dossier ou la planification d'un suivi. Ces résultats proviennent des propres évaluations de Salesforce et doivent donc être considérés comme tels à ce stade.

Au 25 septembre 2026, Koa fonctionne déjà sur certains usages internes chez Salesforce et fait l'objet de pilotes auprès d'un nombre limité de clients. Salesforce prévoit une disponibilité générale durant l'hiver 2026 dans les régions américaines.

Pour les entreprises qui travaillent déjà sur leurs propres agents, le principal enseignement peut toutefois être appliqué dès aujourd'hui :

un bon scénario de test vérifie ce que fait l'agent lorsque tout fonctionne. Un excellent scénario vérifie aussi ce qu'il fait lorsque quelque chose manque.