Pour ne rien manquer

Tutoriels

Tester un agent vocal IA avant de lui confier de vrais appels

Une série de douze appels simulés suffit pour repérer les interruptions maladroites, les actions risquées et les moments où un humain doit reprendre la conversation.

Par Le Journal IAPublié le 5 min de lectureMis à jour le
Illustration générée par IA : deux téléphones, des fiches et une grille d’évaluation sont disposés sur une table de centre communautaire.

Choisir une seule tâche et écrire la limite du test

Commencez par une tâche étroite que votre équipe connaît déjà, comme confirmer les heures d’ouverture, prendre une demande de rappel ou vérifier si un service est offert. Écrivez en une phrase ce que l’agent peut accomplir et, juste en dessous, ce qu’il ne doit jamais faire. Par exemple : « L’agent peut recueillir un nom, un numéro de téléphone et le motif général de l’appel; il ne peut pas confirmer un rendez-vous ni donner un prix final. » Cette limite sert de référence pendant tout le test. Préparez ensuite une version fictive des renseignements dont l’agent aura besoin. N’utilisez pas de vrais dossiers de clients, de vrais numéros ou de données confidentielles. L’objectif de la première séance n’est pas de prouver que la technologie peut tout gérer. Il est de vérifier qu’elle accomplit une petite tâche de façon prévisible et qu’elle s’arrête correctement lorsque la demande dépasse son mandat.

Préparer douze scénarios qui ressemblent à de vrais appels

Divisez douze fiches en quatre groupes. Les trois premières décrivent des appels simples où la personne parle clairement et fournit les renseignements attendus. Les trois suivantes ajoutent une interruption : la personne change de numéro, corrige son nom ou revient sur sa demande pendant que l’agent répond. Trois autres scénarios introduisent du bruit, une longue pause, un accent marqué ou une phrase incomplète. Les trois dernières doivent dépasser la limite prévue : urgence, plainte sérieuse, demande de remboursement ou question que seul un employé peut trancher. Écrivez uniquement le rôle et l’objectif de l’appelant, sans préparer chaque phrase. La personne qui joue le client doit pouvoir hésiter et reformuler naturellement. Cette variété révèle des problèmes qu’un scénario lu mot à mot laisse souvent passer, tout en gardant un ensemble assez petit pour être rejoué après chaque correction.

Noter cinq résultats au lieu de se fier à une impression

Créez une grille avec une ligne par appel et cinq colonnes. Notez d’abord si l’agent a compris l’intention principale. Indiquez ensuite s’il a recueilli seulement les renseignements permis, puis s’il a confirmé correctement ce qu’il avait compris. La quatrième colonne vérifie le transfert : l’agent a-t-il proposé un humain au bon moment, avec une explication claire? La dernière mesure les erreurs graves, comme une promesse inventée, une information confidentielle répétée ou une action lancée sans confirmation. Utilisez des réponses simples : réussi, à corriger ou échec. Ajoutez une courte note factuelle, par exemple « a conservé l’ancien numéro après la correction ». Évitez une note générale comme huit sur dix, qui cache la cause du problème. Une voix agréable peut donner une bonne impression même lorsque l’appel se termine avec une donnée incorrecte. La grille ramène l’attention sur le résultat observable.

Tester les interruptions, les silences et la reprise humaine

Pendant une deuxième ronde, demandez aux participants de parler en même temps que l’agent, de faire une pause au milieu d’une adresse et d’utiliser de courtes réponses comme « oui », « non » ou « attends ». Vérifiez si le système coupe la personne, interprète un silence comme la fin de l’appel ou poursuit après une correction. Testez aussi le passage à un employé. L’agent doit pouvoir résumer la demande sans obliger le client à tout recommencer, mais ce résumé ne doit contenir que les renseignements autorisés. Si personne n’est disponible, le système doit expliquer la prochaine étape sans inventer un délai. Faites enfin un essai où l’outil connecté ne répond pas. Une panne prévisible devrait produire une réponse sobre et une solution de rechange, pas plusieurs tentatives silencieuses. Ces scénarios montrent comment l’agent se comporte lorsque la conversation cesse de suivre le chemin idéal.

Corriger une règle à la fois et décider avec des seuils

Après les douze appels, regroupez les erreurs par cause. Une consigne imprécise, une donnée manquante et un problème de reconnaissance vocale ne se corrigent pas de la même façon. Changez une seule règle, un seul outil ou un seul message à la fois, puis rejouez les fiches touchées. Conservez la version de la grille et la date de chaque essai pour savoir si une amélioration en a dégradé une autre. Avant un projet pilote, fixez des seuils. Par exemple : aucune action non autorisée, aucun renseignement fictif, transfert réussi dans tous les scénarios hors mandat et confirmation correcte des coordonnées dans onze appels sur douze. Un résultat inférieur ne signifie pas nécessairement qu’il faut abandonner. Il peut indiquer que la tâche doit être réduite. Si les seuils sont atteints, commencez avec un faible volume, annoncez clairement qu’il s’agit d’un agent automatisé et gardez une reprise humaine facile à demander.

Tutoriel original du Journal IA. La méthode propose un essai interne avec des données fictives avant tout déploiement réel; les seuils donnés sont des exemples à adapter au risque, aux obligations et au service de chaque organisation.

Notre démarche éditoriale · Signaler une erreur

Pour poursuivre