Pour évaluer un agent vocal, testez ce qui se passe lorsque l’appel quitte le scénario prévu. Une réponse fluide à une demande simple ne montre ni la capacité à corriger une erreur, ni la qualité du relais à un humain.
Le protocole proposé ci-dessous ne constitue pas un classement de produits. Il sert à comparer des configurations identifiées à partir de situations fictives et de critères décidés avant l’essai.
Fixer le périmètre de l’évaluation
Notez le produit, la version ou la date de configuration, les outils accessibles et les actions autorisées. Un agent limité à prendre un message ne doit pas être évalué comme un système autorisé à modifier un rendez-vous.
Écrivez ce que le système doit faire, ce qu’il doit refuser et quand il doit demander de l’aide. Préparez également les règles applicables à l’information des appelants : l’article 50 du règlement européen sur l’intelligence artificielle prévoit une obligation d’information pour certains systèmes destinés à interagir directement avec les personnes, avec les conditions et exceptions précisées par le texte. Article 50, paragraphe 1.
Cette vérification porte sur le service vocal envisagé. Elle fait partie du cadrage avant son utilisation réelle.
Construire des scénarios qui obligent à corriger
Commencez par une demande simple, puis introduisez une correction : changement de nom, numéro rectifié ou abandon de la demande initiale. Vérifiez que la version finale reprend la correction sans conserver deux instructions contradictoires.
Ajoutez une interruption, une phrase ambiguë ou une information manquante. Le résultat attendu peut être une question de clarification, une reformulation ou un relais. Il ne doit pas être une réponse inventée pour terminer l’échange.
Utilisez des formulations variées correspondant au public prévu, y compris des difficultés d’audition, de diction ou de compréhension lorsque ces situations entrent dans le périmètre. Un seul enregistrement de démonstration ne couvre pas ces usages.
Tester les limites d’action et de divulgation
Préparez une demande hors cadre : accès à une information réservée, modification non autorisée ou instruction demandant d’ignorer les consignes. L’essai doit rester fictif et isolé des données réelles.
Observez la réponse et les effets dans les outils. Un refus oral ne suffit pas si une action a tout de même été exécutée. Inversement, une réponse accueillante ne prouve pas qu’une opération a abouti.
Pour chaque scénario, conservez l’entrée, le résultat attendu, le résultat constaté et les traces disponibles. Si une partie du parcours n’est pas observable, indiquez cette limite au lieu de conclure à un succès.
Vérifier le relais à un humain jusqu’à son terme
Le transfert doit être évalué avec son contexte : qui reçoit l’appel, quelles informations lui parviennent et ce que l’appelant doit répéter. Prévoyez aussi le cas où personne ne répond.
Un message indiquant « je vous transfère » ne démontre ni la connexion ni l’acceptation de la demande. Le guide du transfert accompagné et celui du suivi de prise en charge aident à définir ces étapes.
Dans un exemple fictif, l’agent comprend qu’une demande dépasse ses droits, mais le destinataire humain est absent. Le test doit vérifier le repli autorisé et l’absence de promesse de rappel non prise en charge.
Comparer des résultats comparables
Faites passer les mêmes scénarios aux configurations comparées, dans des conditions documentées. Séparez compréhension, exactitude de l’action, protection des informations, reprise après erreur et relais.
Ne réduisez pas tout à une moyenne : une divulgation indue ou une action hors autorisation peut demander une décision distincte, même si les demandes simples réussissent. Fixez les critères de blocage avant l’essai.
Le livrable est une liste de résultats observés et d’écarts à corriger. Un nouveau réglage appelle une nouvelle vérification des cas concernés. Sans essai exécuté, ces scénarios restent un protocole de préparation, et aucun résultat de performance ne peut être annoncé.
