← Retour au blog

28 avril 2026 · Équipe betool

Voix temps réel ou batch — un agent IA téléphonique n'est pas un chatbot

Pourquoi un assistant vocal exige une architecture radicalement différente d'un chatbot écrit, et ce que ça implique pour la latence, le barge-in et le choix de modèle.

voixarchitecturelatence

Voix temps réel ou batch — un agent IA téléphonique n'est pas un chatbot

Quand un éditeur propose un « agent IA téléphonique », posez-lui une question : « Quelle est votre latence end-to-end entre la fin de la parole utilisateur et le début de la réponse ? »

Si la réponse dépasse 1,5 seconde, ce n'est pas un agent téléphonique. C'est un chatbot avec un module ASR / TTS collé devant.

La règle des 800 ms

Un humain au téléphone tolère un silence après sa question. Mais ce silence a un seuil : au-delà de 800 ms, l'autre côté semble « figé ». À 1 500 ms, l'interlocuteur dit « allô ? ». À 3 000 ms, il raccroche en pensant à un problème de ligne.

L'objectif d'un agent vocal sérieux est donc : moins de 800 ms entre la fin de la parole et le début audible de la réponse.

Décomposons.

Le budget temps en détail

[parole user]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
       ~150ms          ~80ms       ~?      ~250ms             ~50ms

Sur les ~800 ms disponibles, environ 270 ms partent dans ASR + TTS + transport. Reste 530 ms pour le LLM — incluant son temps de prefill, de réflexion, et la génération du premier token.

Conséquences :

  • GPT-4 Turbo en non-streaming : ~2 000 ms pour générer une réponse de 200 tokens. Hors-jeu.
  • GPT-4o streaming : ~400 ms au premier token sur les bons jours, ~800 ms sur les mauvais. Acceptable mais tendu.
  • Claude Haiku streaming : ~250 ms au premier token. Confortable.
  • Llama 3 8B servi par vLLM : ~150 ms au premier token. Excellent (et privé).

Une architecture voix sérieuse impose donc :

  1. Tout est en streaming — ASR, LLM, TTS. Pas un seul maillon en batch.
  2. Le modèle LLM est choisi pour le TTFT (time to first token), pas pour le score MMLU.
  3. Le TTS commence à parler dès le premier token reçu, pas à la fin de la réponse complète.

Le barge-in

Sur un canal écrit, l'utilisateur attend que le bot ait fini. Au téléphone, il coupe. Trois fois sur cinq, dans les conversations naturelles.

Un agent vocal qui ne sait pas se faire couper paraît « autiste » — il continue à dérouler sa phrase pendant que l'utilisateur essaie de l'interrompre. C'est insupportable et signe immédiatement qu'on parle à un robot mal foutu.

Le barge-in technique demande :

  • Le TTS s'arrête immédiatement quand l'ASR détecte du signal vocal sortant utilisateur.
  • Le LLM jette la complétion en cours (sans rancune).
  • Le buffer audio sortant est purgé instantanément (sinon on entend une demi-syllabe résiduelle).
  • L'historique de conversation note que la réponse n'a pas été entendue en totalité — pour ne pas la répéter par erreur.

C'est un détail technique qui change tout dans le ressenti.

La gestion d'incertitude

Au téléphone, l'ASR se trompe régulièrement. Là où un chatbot écrit dispose toujours du texte exact tapé par l'utilisateur, l'agent vocal reçoit une transcription souvent imparfaite.

Stratégies qui marchent :

  • Demander confirmation sur les éléments à forte conséquence (numéro de dossier, montant, nom de famille rare). Pas systématiquement — sinon insupportable.
  • Ne pas faire confiance aveugle au LLM quand l'ASR est ambigu. Si la phrase reçue est « je veux annuler mon contrat » avec un score de confiance bas, mieux vaut demander « vous voulez bien dire annuler votre contrat ? » que de lancer la procédure d'annulation.
  • Couper court aux dérapages — un agent qui s'éloigne du script doit être ramené par un nœud condition / opérateur, pas par un prompt qui « devrait suffire ».

Le téléphone, c'est aussi une stack

Au-delà de l'IA, un agent téléphonique exige :

  • Un trunk SIP auprès d'un opérateur (Twilio, Voxbone, OVH, Sewan…).
  • Une gateway média (LiveKit-SIP, FreeSWITCH, Asterisk) qui parle SIP côté opérateur et WebRTC côté plateforme.
  • Un transcripteur robuste au bruit, aux accents, aux superpositions de voix.
  • Un synthétiseur qui prononce correctement les noms propres, les nombres, les dates.

Aucun de ces éléments n'est trivial. Tous interagissent.

Ce que betool prend en charge

L'architecture voix de betool — LiveKit + LiveKit-SIP + worker dédié + cascaded LLM streaming — couvre les besoins ci-dessus en standard. Vous restez maître :

  • Du trunk SIP (votre opérateur, vos numéros).
  • Des modèles (BYOK ou modèles privés).
  • Des paramètres (latence cible, agressivité du barge-in, fall-back voix humaine).

Vous ne configurez pas la plomberie temps-réel — c'est le travail de la plateforme. Vous concevez la conversation, qui est le vrai sujet métier.