Test agent vocal IA : clients virtuels et LLM-as-a-judge

David Guede, Partner Data / IA et Expert Agentique chez Converteo, est spécialisé dans le déploiement d’architectures d’IA en production. Il accompagne les entreprises dans l’industrialisation d’agents intelligents, transformant des processus métiers complexes en véritables leviers de performance et d’avantage concurrentiel.

À retenir

• Un agent vocal peut répondre parfaitement à 99 conversations et complètement dérailler à la centième. La vraie question des tests n’est pas « est-ce que ça marche » mais « est-ce que ça marche dans 100 % des cas ».
• Trois outils, complémentaires et non substituables, structurent l’évaluation à l’échelle : les clients virtuels pour simuler des conversations, le LLM-as-a-judge pour évaluer la qualité des réponses, et le bug bounty pour traquer les failles de sécurité.
• Cette infrastructure de test n’est pas un confort technique. C’est ce qui rend possible un véritable cycle d’itération en production, sans régression silencieuse.

Un agent vocal, c’est un système probabiliste. Cela change tout. Dans un système déterministe classique, si un test passe une fois, on peut raisonnablement supposer qu’il passera la fois suivante. Dans un système probabiliste, une même question posée deux fois peut produire deux réponses différentes, et c’est la millième qui sera catastrophique.

Cette réalité impose de repenser entièrement la manière dont on teste. Tester à la main, en rejouant quelques scénarios devant un café, ne suffit absolument pas. Il faut industrialiser l’évaluation, et le faire avec trois outils principaux : les clients virtuels, le LLM-as-a-judge, et le bug bounty. Aucun de ces outils n’est nouveau pris isolément. Ce qui change, c’est la nécessité de les combiner systématiquement pour tout projet d’agent vocal sérieux.

Les clients virtuels : simuler la diversité du monde réel

L’idée est simple. Plutôt que de demander à des humains de tester l’agent en se faisant passer pour des clients (ce que l’on fait évidemment au démarrage), on automatise cette simulation. Un modèle joue le rôle du client, avec ses propres profils, ses propres tournures, son propre niveau de patience. L’agent ne sait pas qu’il s’adresse à une IA. Il répond comme il le ferait avec une personne réelle.

L’intérêt est triple.

• D’abord, on couvre une diversité de cas qu’aucune équipe de test humaine ne pourrait reproduire à coût raisonnable. Différents profils de clients, différentes manières de formuler une même demande, différents niveaux d’agacement, différentes interruptions.
• Ensuite, on détecte les régressions entre deux versions de l’agent. C’est essentiel. Quand on modifie un prompt, un agent, ou la base de connaissance, on veut savoir si on a cassé quelque chose. Sans clients virtuels, on s’en aperçoit en production, c’est-à-dire trop tard.
• Enfin, on libère du temps humain pour les sujets qui en demandent vraiment : la définition des scénarios complexes, la validation des cas limites, l’analyse des dérives. C’est typiquement le couple humain + machine bien organisé : la machine joue 1000 conversations, l’humain analyse les 10 qui ont posé problème.

LLM-as-a-judge : évaluer la qualité, pas seulement la réussite

Simuler des conversations ne suffit pas. Il faut ensuite les évaluer. Et c’est là qu’intervient ce qu’on appelle le « LLM-as-a-judge » : un modèle de langage à qui l’on confie la mission d’évaluer la qualité d’une conversation.

Concrètement, on lui donne la transcription d’un échange, et on lui demande de répondre à des questions précises. L’agent a-t-il bien tutoyé ou vouvoyé le client selon la règle ? A-t-il bien répondu à la question posée ? S’est-il trompé sur un prix, sur une caractéristique produit, sur une condition contractuelle ? A-t-il respecté la posture de la marque ?

Sur un sujet d’opérateur télécom, par exemple, on ne peut pas se permettre que l’agent dise « cet iPhone est à 1 € » alors qu’il est à 1 200 euros. Sur une option de forfait, on ne peut pas se permettre qu’il promette des appels illimités dans un pays qui n’est pas couvert. Le LLM-as-a-judge va scanner systématiquement ces critères, sur des milliers d’interactions, et lever des alertes là où c’est nécessaire.

C’est cette brique qui rend l’évaluation véritablement industrielle. Sans elle, on est condamné soit à inspecter les conversations à la main (impossible à l’échelle), soit à s’en remettre à des indicateurs trop grossiers (taux de transfert vers un humain, durée moyenne d’appel) qui ne disent pas grand-chose de la qualité réelle.

Bug bounty : traquer les failles avant les autres

Les clients virtuels et le LLM-as-a-judge testent ce que fait l’agent dans des conditions normales. Le bug bounty, lui, teste ce qu’il fait quand quelqu’un essaie volontairement de le faire dérailler.

C’est une pratique bien établie dans le monde de la cybersécurité classique : on ouvre, contre rémunération, l’accès à un système à une communauté de white hackers, qui essaient de trouver des failles. Quand ils en trouvent une, ils sont récompensés, et la faille est corrigée avant qu’un acteur malveillant ne l’exploite.

Pour les agents vocaux et conversationnels, ce sujet est particulièrement neuf. Les modes d’attaque ne sont pas les mêmes que sur une application web. On parle ici d’injections de prompt, de tentatives de faire dire à l’agent quelque chose de contraire à la marque, de manipulations sociales pour lui faire divulguer une information confidentielle, ou de faire valider une transaction qu’il n’aurait pas dû valider. Ces failles ne se détectent pas avec les outils traditionnels de sécurité applicative.

Mettre en place un bug bounty spécifique IA implique plusieurs choses : choisir un partenaire spécialisé, définir une grille de criticité (un agent qui se trompe de prénom n’est pas équivalent à un agent qui promet 100 euros au mauvais client), structurer un programme de rétribution, et organiser le cycle de correction. C’est un investissement, mais il est devenu indispensable pour tout agent qui parle directement à des clients finaux.

Combiner les trois : la condition pour itérer en production

Pris isolément, chacun de ces outils est utile. Pris ensemble, ils permettent quelque chose de plus précieux : itérer en production sans peur.

C’est ce que l’expérience montre. Une fois qu’on a une batterie de clients virtuels qui rejouent quotidiennement un panel large de conversations, un LLM-as-a-judge qui évalue automatiquement la qualité des réponses, et un bug bounty qui traque les failles en continu, on peut se permettre de modifier l’agent fréquemment. On voit immédiatement, dès la nuit suivant un déploiement, si une régression est apparue. On peut rouler en arrière si nécessaire.

À l’inverse, sans cette infrastructure, chaque modification devient un acte de foi. On hésite à toucher au système qui marche. L’agent se fige, et ses limites deviennent permanentes.

Tester un agent vocal à l’échelle, c’est la condition même de son industrialisation. Les trois leviers (clients virtuels, LLM-as-a-judge, bug bounty) ne se remplacent pas l’un l’autre. Ils couvrent trois questions différentes : est-ce que ça marche sur la diversité du monde réel ? Est-ce que la qualité est au rendez-vous ? Est-ce que c’est résistant aux attaques ?

Les organisations qui investissent tôt dans cette infrastructure de test prennent une avance qu’il sera difficile de rattraper. Elles itèrent vite, déploient sereinement, et accumulent les apprentissages. Les autres restent prisonnières de leur première version.