Un agent vocal IA mentait aux clients et confondait les appelants : le développeur a trouvé la cause ailleurs que dans le prompt

Le développeur d'un agent vocal IA pour les entreprises a passé trois mois en conditions réelles et a documenté tous les écueils : l'agent mentait, confondait les clients et falsifiait la voix d'une manière très éloignée de ce qui était prévu.

Les trois grands échecs de l'agent

Durant ses premiers mois en production, l'agent vocal s'est illustré à plusieurs reprises.

Premier incident : l'agent a annoncé à un client que « l'administrateur Alexeï » le rappellerait dans une heure. Aucun Alexeï n'existait. L'agent avait généré ce nom à partir du contexte d'appels précédents, en mélangeant des bribes de dialogues. Le client a attendu, puis déposé une réclamation.

Le deuxième bug était plus grave : l'agent a commencé à prendre tous les appelants pour la même personne. La session n'était pas réinitialisée entre les appels, et la mémoire du client précédent fuyait dans la conversation suivante. Techniquement, c'est le problème classique du contexte partagé sans isolation explicite.

• L'agent appelait le nouveau client par le nom de l'appelant précédent
• Il se souvenait des détails de la commande d'un autre et proposait de « poursuivre l'enregistrement »
• Il confirmait des accords inexistants issus de sessions passées
• Il s'excusait d'un « retard » qui n'avait pas eu lieu, en confondant l'appel en cours avec le précédent

Le troisième cas a été le plus long à détecter. Pendant un mois entier, l'agent a utilisé une synthèse TTS ordinaire tout en se présentant aux clients comme une « voix clonée ». Le clonage ne s'est pas connecté à cause d'une erreur de configuration, mais aucune exception n'a été levée : le système a simplement basculé en silence vers la synthèse standard.

Pourquoi le prompt ne guérit rien

La première réaction intuitive consiste à ajouter au prompt des consignes : « n'invente pas de noms », « ne te souviens pas des appelants précédents », « vérifie toujours qu'un profil vocal existe ». L'auteur a essayé et explique pourquoi cela ne fonctionne pas de façon systématique.

Un modèle de langage ne fait pas la différence entre une interdiction écrite dans le prompt et les données du contexte de session. Si l'historique d'un appel précédent se retrouve physiquement dans la fenêtre de contexte, le modèle s'en sert. Une instruction ne peut pas interdire ce qui se trouve déjà en mémoire.

« Le prompt est une recommandation, pas une barrière architecturale.

La barrière doit être dans le code. »

La solution consiste à isoler l'état au niveau de l'infrastructure : réinitialisation stricte du contexte entre les appels, vérification de la présence du profil vocal avant le début de l'appel (et non pendant), et validation explicite de chaque fait avant de le prononcer.

La pile russe et ses particularités

L'auteur travaille entièrement avec des outils nationaux : un LLM russe, un fournisseur de TTS russe et la téléphonie via un opérateur local. Cela impose des contraintes spécifiques.

La documentation de plusieurs de ces outils est incomplète ou en retard sur l'API. C'est pourquoi l'erreur de clonage vocal est restée invisible : en l'absence de profil vocal, le fournisseur ne renvoyait aucune erreur. Il livrait discrètement la synthèse standard avec un code 200. La substitution ne pouvait se détecter qu'en analysant l'audio de sortie ou en vérifiant explicitement les métadonnées de la réponse.

Leçons pratiques de trois mois d'expérience :

• Vérifiez la présence de toutes les ressources (voix, profil, session) avant de lancer l'opération, pas pendant
• Journalisez non seulement les erreurs, mais aussi les réponses « réussies » : une dégradation silencieuse est plus dangereuse qu'un plantage franc
• Isolez l'état de l'agent entre les sessions dans le code, pas dans le prompt
• Testez la sortie audio, pas seulement le journal textuel : une synthèse et un clone ne sonnent pas pareil

Ce que cela signifie

En production, les agents vocaux IA tombent en panne autrement que les chatbots : les erreurs sont dites à voix haute, le client les entend en temps réel et ne peut ni les relire ni les ignorer. La rigueur architecturale devient donc critique.

La plupart des « comportements étranges » d'un agent vocal ne sont pas des hallucinations du modèle, mais des failles d'architecture dans le code qui l'entoure. Cela se corrige. Mais pas avec un prompt.