Résumé du webinaire : Donnez une voix humaine à votre chatbot textuel

Les agents conversationnels sont devenus un élément standard des logiciels d’entreprise. La plupart des entreprises en ont un ou en développent un. Reste à savoir quoi faire lorsqu’un utilisateur préfère simplement parler.

La voix transforme l’interaction bien au-delà du simple confort. Les utilisateurs expriment leur frustration, leur urgence et leur confusion par le ton, des nuances que le texte efface entièrement. Un client qui écrit « ma commande n’est pas arrivée » et un autre qui le dit avec une anxiété perceptible n’envoient pas les mêmes signaux. Un agent qui ne lit que la transcription ne dispose que de la moitié des informations.

La question que se posent désormais la plupart des équipes n’est pas de savoir s’il faut ajouter la voix, mais comment le faire sans reconstruire tout ce qui fonctionne déjà.

Lors de l’atelier en direct : donnez à votre chatbot textuel une voix humaine, Paul Asjes (Developer Experience), Bhargavi Bhatt (Customer Experience) et Fergal Burnett (Product Marketing, ElevenAPI) ont présenté les réalités techniques de l’ajout de la voix à un agent existant et les caractéristiques concrètes d’une intégration fonctionnelle.

Pourquoi développer avec la voix est plus difficile qu’il n’y paraît

L’un des principaux défis est la gestion des tours de parole. Les humains savent qu’une personne a fini de parler grâce à l’intonation, au rythme et au contexte. La détection d’activité vocale, l’approche standard, ne détecte toutefois que le silence.

On obtient souvent un système qui interprète chaque pause comme une invitation à parler : il interrompt, coupe la parole en plein milieu d’une idée et traite les hésitations naturelles comme des phrases terminées.

Il fonctionne techniquement, mais échoue dans la conversation.

Le contexte est l’autre moitié du problème. Transmettre l’historique de la conversation à un LLM à chaque tour est nécessaire, mais insuffisant. Les mêmes mots prennent un sens différent selon la façon dont ils sont prononcés : « je vais bien » avec soulagement et « je vais bien » avec frustration produisent la même transcription, mais une interaction différente. Un système vocal qui ignore cette dimension sonnera toujours légèrement faux, quelle que soit la qualité des modèles qui le composent.

Il faut aussi tenir compte de la charge d’ingénierie. Les équipes qui gèrent leur propre orchestration vocale doivent maintenir en continu la logique des tours de parole, la gestion des interruptions et le profilage de la latence. Ce n’est pas un développement ponctuel.

Comment ajouter la voix à un agent existant

L’approche la plus simple repose sur une architecture à deux WebSocket. 

1. Une connexion relie le client à l’API ElevenLabs et une autre relie votre serveur à l’API ElevenLabs
2. L’utilisateur parle dans son microphone, l’audio est envoyé à l’API ElevenLabs, où il est transcrit puis transmis à votre serveur
3. Votre serveur transmet au LLM l’intégralité de l’historique de conversation reçu de l’API ElevenLabs, puis la réponse diffusée en continu est renvoyée pour synthèse audio
4. Cela peut commencer avant que le LLM ait fini de générer, afin de réduire la latence jusqu’au premier octet 

Le point d’intégration clé est la méthode onTranscript , déclenchée à la fin de chaque tour et qui transmet l’historique complet de la conversation au LLM. 

Une contextualUpdate au début de la session reprend ce qui s’est passé dans la partie textuelle de la conversation avant que l’utilisateur passe à la voix. C’est ce qui permet à un même agent de fonctionner dans les deux modalités sans perdre le contexte.

Quelques points à garder à l’esprit lors du développement :

1. Le choix du LLM compte davantage pour la voix que pour le chat. Les modèles de raisonnement approfondi introduisent des pauses qui paraissent artificielles à l’audio, même si la qualité des réponses est supérieure. Pour la voix en temps réel, les modèles plus rapides offrent presque toujours une meilleure qualité perçue.
2. Préférez WebRTC aux WebSocket pour l’audio. WebRTC intègre l’annulation de l’écho et la réduction du bruit, essentielles sur mobile ou dans les environnements bruyants. Utiliser des WebSocket pour transporter l’audio signifie que vous devez vous en charger vous-même.
3. Ne demandez pas aux utilisateurs de choisir une langue. Cela rompt le flux de la conversation. Détecter la langue dès les premières secondes de parole et la verrouiller est une meilleure approche, qui permet aussi de changer de langue naturellement sans demander quoi que ce soit à l’utilisateur.
4. Dissociez votre modèle de gestion des tours de parole de votre LLM. Utiliser le LLM pour déterminer quand un utilisateur a fini de parler ajoute de la latence et des coûts à chaque tour. Un modèle dédié à la gestion des tours de parole le fait plus rapidement et avec davantage de précision. Il mérite d’être traité comme un composant distinct de l’architecture.

Quelle part de l’infrastructure gérer

La bonne réponse dépend de ce qui existe déjà. Si vous disposez d’un agent conversationnel fonctionnel, lui ajouter une couche vocale tout en conservant votre LLM, votre orchestration et votre logique métier est généralement la voie la plus rapide et la moins risquée. 

Vous ne reconstruisez rien. Vous ajoutez une interface audio à un système qui fonctionne déjà.

Si vos besoins couvrent aussi la téléphonie, la gestion des canaux de déploiement, les tests intégrés et l’analytique, il peut être judicieux de confier une plus grande partie de la pile à une plateforme d’agents vocaux. Les deux approches ne s’excluent pas : les équipes peuvent commencer par une couche vocale légère, puis ajouter des capacités de plateforme à mesure que le cas d’usage évolue.

Démo : ajouter la voix à un chatbot existant

Cette démonstration suit un utilisateur en pleine conversation avec un chatbot textuel de planification de voyage, auquel il demande des recommandations de quartiers et de restaurants pour un séjour au Japon.

Ce que nous avons présenté :

• Le chatbot a été enrichi d’une couche vocale, sans aucune modification de l’agent sous-jacent.
• L’utilisateur est passé de la saisie au mode vocal au milieu de la conversation, et l’agent a conservé tout le contexte dans les deux modalités.
• L’utilisateur a parlé néerlandais ; l’agent a détecté automatiquement le changement de langue
• Lorsque l’agent a été interrompu et qu’on lui a demandé de repasser à l’anglais au milieu d’une phrase, il l’a fait, puis a terminé sa réponse avec un léger accent néerlandais, sans y être invité.
• Tout au long de la conversation, la détection des interruptions a permis à l’utilisateur de parler naturellement par-dessus l’agent, sans que celui-ci termine son tour de parole.

Pourquoi c’est important : 

La démonstration ne présentait pas un agent vocal conçu à cette fin. Elle montrait un agent textuel déjà fonctionnel, auquel une couche vocale avait été ajoutée. La gestion du contexte, la détection de la langue et le comportement face aux interruptions provenaient tous de cette couche vocale. L’agent textuel sous-jacent, lui, n’avait pas changé. 

Regarder la session complète

Regardez le webinaire complet ici.