À la fin d’un PoC Agentforce, le sponsor doit tenir un dossier de décision : de quoi choisir entre poursuivre, corriger et retester, ou arrêter. Obtenir une réponse naturelle en démo est facile. La preuve de ce qu’on peut confier à l’agent sur des demandes réelles se construit délibérément. La mise en production suit la même logique. Un agent ne répond qu’avec les données qu’il atteint et les droits qu’on lui accorde : quand un pilote bloque au seuil de la production, cherchez d’abord sous le prompt.
Quatre questions auxquelles le dossier répond
Un PoC qui se conclut par « le potentiel est confirmé » transforme la réunion suivante en opinion contre opinion. L’équipe plateforme dit avoir vu la fonctionnalité, la sécurité demande le chemin des données, l’exploitation demande qui traite un échec. Le dossier de décision répond à ces questions dans le PoC :
- Quelles demandes l’agent peut-il traiter ?
- Quelles demandes doivent aller à une personne ?
- Quelles limites d’accès s’appliquent aux données que l’agent lit et aux actions qu’il appelle ?
- Face à une erreur ou une demande imprévue, qui valide quel changement ?
Dans le vocabulaire Salesforce, les subagents découpent le périmètre, les actions relient le travail que l’agent exécute, les instructions fixent son comportement dans cette limite. La documentation de test Agentforce DX décrit un test d’agent comme l’envoi d’un énoncé suivi de la vérification que le comportement de la réponse correspond à l’attendu. La mesure porte donc sur l’aiguillage, le choix d’action, le transfert et le refus, plus que sur le ton de la réponse.
Le responsable de l’exploitation valide ces critères avant le démarrage. Des critères ajustés après les résultats laissent un dossier où la conception a été calée sur le résultat. Chez Disneyland Paris en 2022, j’ai audité les processus B2B et fixé une cible Salesforce avant le choix de l’intégrateur. Le même ordre vaut pour un PoC : le client écrit les critères de décision avant qu’un partenaire construise la démo.
Un seul parcours, et le chemin du refus d’abord
Mettez service client, support commercial et recherche documentaire dans un seul agent : un bon résultat ne dira pas ce qui a marché, un mauvais ne dira pas quoi corriger. Chaque parcours a ses données, ses accès, ses exceptions et son responsable. Un parcours suffit. Par exemple, un salarié cherche une politique interne dans des articles de connaissance auxquels il a déjà accès, l’agent cite l’article source et transfère à l’équipe responsable quand il n’est pas sûr. C’est facile à défaire, et cela teste d’un coup la qualité de recherche, les accès, le transfert et la traçabilité.
Écrivez ensuite le chemin du refus avant le chemin du succès, dans un seul document :
- demandes autorisées : types de demandes traitées et informations requises ;
- demandes interdites : ce que l’agent ne répond pas ou n’exécute pas ;
- conditions de transfert : qui reçoit la demande quand l’information manque, que la formulation est ambiguë ou qu’un droit doit être vérifié ;
- limite des actions : lecture, suggestion, enregistrement ou modification externe, et lesquels sont permis ;
- reprise : qui valide l’arrêt, la correction et le nouveau test après une mauvaise réponse ou un mauvais appel.
Afficher le résultat d’une requête et modifier l’état d’un système externe ne portent pas le même risque. Gardez les actions qui modifient un état hors du premier PoC ; si l’une est indispensable, limitez sa cible et concevez à l’avance l’approbation humaine et le retour arrière. « Ce n’est que l’environnement de test » ne remplace pas une conception des accès, et de vraies données personnelles n’entrent pas dans un PoC par commodité.
Le tableau de tests porte deux verdicts
Les cas de test couvrent demandes normales, informations manquantes, formulations ambiguës, demandes interdites, demandes hors droits et échecs d’action. Pour chaque cas, notez l’énoncé, le subagent attendu, les actions autorisées ou interdites, les éléments obligatoires de la réponse et si un transfert est attendu. Écrivez les résultats attendus comme des conditions vérifiables, par exemple « répondre uniquement à partir de l’article X et transférer à l’équipe responsable s’il ne contient pas la réponse », plutôt que « une bonne réponse » que chaque évaluateur lit à sa façon.
Le premier verdict porte sur le comportement de l’agent : bon subagent, outils autorisés, transfert ou refus. L’équipe plateforme peut le mener. Le second porte sur l’adéquation opérationnelle : ce comportement respecte-t-il la politique du service, le partage des responsabilités et les principes d’accès aux données ? Le responsable métier et le responsable sécurité ou le DPO le rendent.
Un cas en échec désigne une couche. Si l’agent a montré une donnée que l’utilisateur ne doit pas voir, vérifiez l’accès aux données, les droits de l’utilisateur, les entrées et sorties des actions avant d’allonger les instructions. S’il transfère sans cesse, vérifiez si la source de connaissance, la classification ou la condition de transfert est trop étroite.
La décision de sortie et les conditions de production
La réunion de sortie se termine par poursuivre, corriger et retester, ou arrêter. Un candidat à la poursuite a séparé demandes autorisées et interdites, tenu la limite des actions en test, montré un transfert qui fonctionne et noté une cause et un responsable pour chaque cas en échec. Les signaux d’attente vont dans le même document : des actions imprévues appelées pour une raison différente à chaque test, pas de propriétaire des données ni de responsable métier nommé, un succès qui dépendait de droits d’exception ou de données de test irréalistes, aucun moyen de vérifier que les tests précédents passent encore après une correction.
Poursuivre n’ouvre pas la production à lui seul. Cinq conditions le font.
| Condition | Ce que vérifie le sponsor |
|---|---|
| Données | La liste des questions auxquelles l’agent doit répondre, avec l’emplacement des données de chaque réponse et la capacité de l’agent à les atteindre. |
| Accès | Le contexte utilisateur dans lequel l’agent s’exécute, et ce que ce contexte autorise. |
| Responsable d’arrêt | La personne qui coupe l’agent quand la qualité baisse, et son critère, nommés avant l’ouverture. |
| Jeu de tests | Le jeu du PoC est devenu un jeu de non-régression, rejoué à chaque changement. |
| Circuit de support | L’équipe qui reçoit les transferts existe, et ses effectifs et horaires correspondent aux conditions de transfert. |
Ne pas atteindre les données nécessaires et atteindre des données interdites appellent deux corrections différentes. Le premier cas relève du mapping des droits : une connexion sans ce mapping laisse l’agent aveugle. Le second relève du modèle de sécurité : un modèle de droits pensé pour des personnes n’a pas prévu l’agent comme nouvel acteur. Ni l’un ni l’autre ne se règle en retouchant le prompt ou en changeant de modèle.
Accordez-vous avec l’équipe sécurité sur le chemin des données personnelles dès la conception du pilote ; une revue lancée juste avant l’ouverture peut exiger un nouveau consentement ou un nouveau contrat de sous-traitance, ce qui ne tient pas dans un sprint. Si un intégrateur a construit le pilote, datez au même moment la reprise des droits d’exploitation par l’équipe interne. Le partage des droits de changement après l’ouverture est traité dans Modèle opérationnel Agentforce.
À vérifier
- Le responsable de l’exploitation a-t-il validé des critères de réussite écrits avant le démarrage du PoC ?
- Le document de sortie permet-il de choisir entre poursuivre, corriger et retester, ou arrêter ?
- Chaque cas de test nomme-t-il le subagent attendu, les actions autorisées et le transfert attendu ?
- Pouvez-vous dire en une phrase dans quel contexte utilisateur l’agent s’exécute ?
- La personne qui peut couper l’agent est-elle nommée avant l’ouverture ?