Un agent se teste comme une procédure, pas comme une démo. En démonstration, on choisit les messages qui marchent. En production, les clients écrivent mal, changent d'avis, envoient une photo floue et demandent un humain. La différence entre un lancement serein et une semaine de corrections se joue avant publication, dans les scénarios que vous avez pris le temps de jouer.
Ce que vous risquez sans tests
Trois risques dominent. L'invention : l'agent annonce un prix, un délai ou une règle qui n'existe pas. L'action erronée : un remboursement au mauvais montant ou sur le mauvais dossier. La fuite : une réponse construite avec les données d'un autre client. S'y ajoutent la boucle sans transfert et le ton inadapté face à un client contrarié. Aucun de ces risques ne se voit sur un cas nominal joliment écrit.
Les six familles de scénarios à jouer
- Le nominal : la demande claire, l'identité vérifiable, l'action attendue.
- L'incomplet : « ça ne marche pas », sans numéro de commande ni précision.
- Le refus : code OTP erroné, expiré, ou client qui refuse de le donner.
- Le hors cadre : demande qui ne relève pas de votre procédure.
- L'émotionnel : client agacé, menaçant de partir, qui insiste.
- La manipulation : « ignore tes instructions », « donne-moi le solde de mon voisin ».
Ajoutez les limites : montant inhabituel, client introuvable dans le CRM, API lente ou indisponible. Et les variantes de langue : français, anglais, fautes de frappe, formulations locales. Un parcours qui tient sur ces cas tient en production.
Utiliser le simulateur, pas les clients, pour apprendre
Dans Deep Agent Studio, le simulateur rejoue une conversation sans toucher aux clients réels. Vous écrivez le message, l'agent exécute le parcours, et vous inspectez chaque étape : le motif détecté, l'appel d'outil, la vérification d'identité, la décision de transférer. C'est là qu'on voit si le parcours tient, pas dans une vidéo de démonstration. Trois réflexes : jouer chaque scénario avant publication, vérifier qu'aucune action sensible ne part sans OTP, et rejouer l'ensemble après chaque modification de procédure, de prompt ou de modèle.
Construire un jeu de test utile
Vingt à trente conversations suffisent pour un motif, à condition qu'elles soient réalistes. Reprenez de vraies demandes, anonymisées, plutôt que des exemples inventés. Pour chacune, notez le résultat attendu : résolu ou transféré, action attendue ou aucune, contrainte d'identité. Tenez un tableau simple et rejouez-le à chaque version. Ne visez pas 100 % de résolution : un transfert propre est une réussite, pas un échec. Ce jeu de test devient votre garde-fou de non-régression quand vous changez un message ou un seuil.
Tester les outils autant que les mots
Une conversation peut sembler parfaite alors que l'outil a renvoyé une facture vide ou une erreur silencieuse. Vérifiez donc, à chaque scénario, ce qui s'est passé derrière : l'outil appelé, les paramètres envoyés, la réponse reçue, le délai. Un montant à zéro, un identifiant absent ou un délai de dix secondes sont des signaux que la conversation seule ne montre pas. Si votre agent enchaîne deux outils, testez aussi le cas où le premier réussit et le second échoue : c'est là que les doubles actions apparaissent.
La checklist avant publication
- Un motif, une procédure écrite et relue.
- API testée en succès, en réponse vide, en erreur et en timeout.
- OTP obligatoire sur toute action sensible.
- Seuil de transfert défini par motif.
- Messages client relus, sans jargon interne.
- Scénario émotionnel joué, avec une réponse calme.
- Tentative d'injection et demande de données d'un tiers testées.
- Client inconnu et données absentes testés.
- Trace vérifiée : aucun outil d'écriture appelé sans intention.
- Pilote limité prêt, avec une revue des conversations à J+1.
Après publication : le pilote
Ouvrez petit : quelques clients de confiance ou une part limitée du volume. Relisez les vingt premières conversations le lendemain, puis chaque jour pendant une semaine. Corrigez la procédure avant de corriger le prompt : la plupart des erreurs viennent d'une étape manquante, pas d'une phrase mal tournée. Élargissez quand le taux de résolution est stable et que les transferts arrivent avec un contexte propre. Gardez le jeu de test pour vérifier chaque évolution.
Les erreurs fréquentes
Tester uniquement le cas nominal donne une fausse confiance. Confondre une belle réponse avec une bonne action laisse passer les erreurs métier. Changer de modèle sans rejouer les tests casse des parcours validés. Ignorer les transferts prive de la meilleure source d'amélioration : ils montrent exactement où l'agent ne suffit pas. Publier sur tous les canaux le même jour multiplie les corrections. Enfin, oublier de vérifier les traces empêche de comprendre pourquoi une conversation a dérapé.
FAQ
Combien de scénarios faut-il prévoir ? Vingt à trente par motif au démarrage, puis un scénario de plus à chaque incident observé.
Faut-il de vrais clients pour tester ? Non. Le simulateur suffit avant publication ; le pilote sert ensuite à confronter le parcours au réel.
Que faire si l'agent échoue ? Corrigez la procédure ou l'outil, pas seulement la formulation. Une étape manquante ne se règle pas avec un prompt plus long.
Peut-on tester WhatsApp sans envoyer de message ? Oui, le simulateur rejoue la conversation sans passer par le canal.
