Latence, barge-in, VAD : la réalité d’un callbot temps réel

Pourquoi 700 ms, c’est déjà long au téléphone

Le cerveau humain a un talent étrange : il accepte que votre colis arrive “entre 8h et 18h”… mais il ne supporte pas un silence de 1,5 seconde dans une conversation.

Les standards télécom le disent sans poésie : au-delà de certains seuils, la “dynamique conversationnelle” se dégrade. ETSI, en s’appuyant sur l’ITU-T, rappelle des plages de temps de transmission à sens unique (one-way) : 0–150 ms (préféré), 150–400 ms (acceptable avec dégradation), > 400 ms (non acceptable) pour la voix conversationnelle.¹

Et là, on ne parle que du transport audio. Un callbot, lui, empile :

• capture + buffer,
• envoi,
• STT,
• décision (LLM / règles),
• TTS,
• lecture + jitter buffer,
• et parfois un transfert.

La leçon : si vous ne raisonnez pas en latence bout en bout, vous risquez de gagner 40 ms sur le STT et d’en perdre 400 sur une mauvaise gestion des tours de parole.

Barge-in : quand l’utilisateur coupe la parole (et c’est normal)

Le “barge-in” est un terme élégant pour une chose très humaine : interrompre.

Sur un callbot, le barge-in n’est pas un bug. C’est un signal de santé.

Quand votre callbot dit :

“Très bien, je vais vous demander votre numéro de…”

Et que l’utilisateur répond :

“C’est 7823…”

…il est en train d’essayer de vous aider. S’il ne peut pas, il va :

1. répéter plus fort,
2. s’énerver,
3. raccrocher,
4. rappeler (bonjour FCR).

Comment gérer le barge-in sans transformer l’audio en soupe

Un barge-in propre, c’est une chorégraphie :

• vous jouez du TTS (vous parlez),
• mais vous écoutez quand même,
• vous détectez la parole entrante,
• vous interrompez le TTS immédiatement,
• vous donnez la priorité à l’utilisateur,
• puis vous reprenez au bon endroit (avec état conversationnel).

Ce qui rend le problème délicat, ce n’est pas la théorie. C’est la pratique :

• l’audio n’est pas parfait,
• il y a des échos,
• la VAD n’est pas infaillible,
• certains TTS sont plus faciles à interrompre que d’autres,
• et la téléphonie peut ajouter du jitter.

Sur la partie transport (voix), Twilio rappelle que la latence dépend notamment du réseau, des buffers et de la chaîne média, et propose des recommandations pour limiter l’impact sur l’expérience.²

VAD, endpointing et “end-of-turn” : arrêter d’attendre le silence parfait

Une conversation naturelle n’est pas une succession de phrases terminées par un point.

C’est une succession de micro-silences :

• un souffle,
• une hésitation,
• un “euh”,
• un changement d’idée,
• une question qui commence et se re-formule.

Si votre callbot attend 800 ms de silence pour “être sûr”, il sera lent.

Si votre callbot coupe au bout de 200 ms, il sera impoli.

Bienvenue dans l’art de l’endpointing.

VAD : la détection de voix comme capteur de “tour de parole”

La VAD (Voice Activity Detection) sert à détecter si l’audio contient de la parole.

Dans une stack open source, on voit souvent passer des implémentations comme WebRTC VAD (librairies dérivées du projet WebRTC).³

La VAD seule ne suffit pas (elle dit “parole / pas parole”), mais elle est une brique solide :

• pour déclencher un barge-in,
• pour éviter d’envoyer du silence au STT,
• pour gérer les timeouts (“êtes-vous toujours là ?”).

Endpointing : décider quand l’utilisateur a fini (ou presque)

Les moteurs STT modernes ont compris le problème : la question n’est pas “qu’a-t-il dit ?”, c’est “a-t-il fini ?”.

Par exemple, Deepgram documente des options de détection de fin de tour (end-of-turn / endpointing) et des réglages associés sur ses modèles (ex. Nova) afin d’optimiser l’interactivité.⁴

En pratique, votre endpointing est un compromis explicite entre :

• vitesse (répondre tôt),
• exactitude (laisser finir),
• politesse (ne pas couper),
• coût (moins de secondes = moins de traitement).

Streaming STT → LLM → TTS : le seul moyen de gagner vraiment

Le streaming n’est pas une optimisation. C’est une philosophie.

Vous voulez éviter : “j’attends que tout soit transcrit, puis je réfléchis, puis je parle”.

Vous voulez plutôt : “je transcris au fil de l’eau, je prépare une réponse au fil de l’eau, je parle au fil de l’eau”.

Pipeline (STT→LLM→TTS) : modulaire et auditable

Le pipeline, c’est la chaîne classique :

1. STT streaming (transcription),
2. LLM (décision + génération),
3. TTS streaming (synthèse).

Avantages :

• on peut logger la transcription (utile pour audit),
• on peut changer un composant sans tout casser,
• on peut appliquer des règles métier au texte.

Inconvénient : la latence cumulée peut être pénible si chaque brique attend “la fin”.

Speech-to-Speech : promesse de fluidité, compromis d’auditabilité

Les offres “temps réel” modernes proposent des API “realtime” capables de gérer l’audio en entrée et en sortie avec une boucle conversationnelle en streaming.

OpenAI, par exemple, décrit une Realtime API permettant de se connecter via WebRTC ou WebSocket (et même SIP dans certains cas d’intégration) pour des échanges audio “low-latency”.⁵

La promesse est simple : réduire la friction, et donc la latence perçue.

Le compromis est aussi simple : selon la stack, l’auditabilité peut être plus complexe (moins de texte intermédiaire exploitable).

Jitter, paquets perdus, échos : la téléphonie n’est pas un studio

Même quand votre IA est brillante, le réseau peut être… créatif.

Le RTP (Real-time Transport Protocol) est le protocole historique pour transporter l’audio/vidéo en temps réel et décrit des concepts essentiels comme le timestamping, la séquence, et la gestion de la variation de délai (jitter).⁶

Et dans le monde WebRTC, les exigences de sécurité et de transport (DTLS-SRTP, etc.) sont standardisées et documentées, ce qui influence la manière dont vous intégrez un callbot à des clients web ou des passerelles WebRTC.⁷

Ce que ça veut dire concrètement :

• vous devez accepter qu’il y ait des trous (packet loss),
• vous devez gérer des variations de délai,
• vous devez limiter l’écho (sinon la VAD devient parano),
• et vous devez faire des choix de codecs (avec des compromis qualité/bitrate/latence).

Si cette partie est floue, lisez d’abord : SIP/RTP/WebRTC pour callbots.

Le “kit de survie” pour une latence stable

Voici une checklist qui marche bien (et qui évite les optimisations de coin de table).

1) Mesurez la latence “tour complet”

Mesurez :

• fin de parole utilisateur → début de parole callbot (p50/p95),
• durée moyenne du tour,
• taux d’interruption (barge-in),
• taux de répétition (“pardon ?”, “allo ?”).

2) Décomposez en segments (mais n’optimisez pas à l’aveugle)

Segments typiques :

• réseau entrant,
• STT,
• LLM,
• TTS,
• réseau sortant,
• lecture.

Le piège : optimiser STT alors que votre TTS ne stream pas.

3) Rendez le système interruptible

Sans interruption, un callbot n’est pas conversationnel. Il est “diffuseur”.

4) Faites des fallback UX, pas des fallback techniques

Quand ça rame, l’utilisateur n’a pas besoin d’un “retry”. Il a besoin d’une phrase utile :

“Je prends votre demande et je vous rappelle dans 2 minutes.”

Ou d’un transfert.

5) Évitez la “latence cachée” des scripts

Certaines latences viennent de choses bêtes :

• validation côté CRM,
• chargement de contexte,
• retrieval trop lent,
• ou un prompt qui fait écrire une dissertation.

En callbot, on préfère souvent : réponse courte + question de clarification plutôt que “la réponse parfaite en 4 secondes”.

Mesurer et améliorer : instrumenter la latence comme un produit

Le problème avec la latence, c’est qu’elle se cache très bien.

Vous pouvez passer une semaine à optimiser un composant… et découvrir que votre pire lenteur vient d’un “petit” appel CRM.

La méthode la plus fiable est la plus ennuyeuse : tracer.

Tracez un “tour” comme une transaction

Définissez un “tour de parole” comme une transaction :

• user_speech_end (fin de parole détectée),
• stt_final (texte final),
• decision_start / decision_end (LLM + règles + outils),
• tts_first_byte (premier chunk audio),
• bot_audio_start (début de lecture),
• barge_in (si interruption),
• handoff (si transfert).

Une fois que vous avez ça, vous pouvez calculer :

• latence p50/p95 “tour complet”,
• latence par composant,
• et surtout la variance (le vrai poison : l’irrégularité).

Faites des “tests de torture” (parce que vos utilisateurs le feront)

Ne testez pas uniquement en conditions “studio”.

Testez :

• téléphonie 8 kHz (qualité standard),
• bruit de fond (rue, voiture, open space),
• chevauchement de parole (l’utilisateur parle pendant le bot),
• débit rapide + phrases cassées,
• et réseau dégradé (jitter, pertes de paquets).

Le but n’est pas de “passer un test”. Le but est de comprendre comment votre système se comporte quand il ne contrôle plus l’environnement.

Calibrez un “budget” barge-in

Un barge-in efficace ne veut pas dire “couper dès que ça bouge”.

Ça veut dire :

• ne pas interrompre pour un bruit non vocal,
• interrompre vite quand l’utilisateur répond,
• et reprendre sans se perdre.

Une heuristique utile :

• bruit court : ignorer,
• parole confirmée : interrompre immédiatement,
• ambigu : ralentir la sortie (chunk plus courts) pour être plus interruptible.

Optimisez la forme des réponses, pas seulement la stack

Un callbot est un système temps réel. Mais une partie de votre latence est… rhétorique.

Deux réponses, même sens :

• “Je vais maintenant procéder à la vérification de votre identité afin de pouvoir accéder à votre dossier, pouvez-vous s’il vous plaît me communiquer votre numéro de…”
• “Pour ouvrir votre dossier : votre numéro client ?”

La deuxième est meilleure pour :

• l’AHT (moins de mots),
• le barge-in (moins de monologue),
• la compréhension (moins de complexité),
• et même la précision STT (moins de bruit sémantique).

Si vous voulez “gagner” en latence perçue, écrivez des phrases plus courtes. C’est l’optimisation la moins chère du monde. Et, miracle, elle marche aussi en cas de panne.

Un mot sur les silences (et les “accusés de réception”)

Les humains font naturellement des “backchannels” :

• “ok”,
• “d’accord”,
• “je vois”,
• “mmh”.

Dans un callbot, c’est tentant d’en rajouter pour paraître vivant. Mais en production, ces micro-phrases ont un coût :

• elles consomment du temps d’appel,
• elles peuvent gêner le barge-in (on parle au mauvais moment),
• et elles ajoutent du bruit audio au STT (surtout si vous réécoutez votre propre voix).

La règle simple : utilisez les backchannels comme outil, pas comme décoration.

Exemples efficaces :

• “Très bien.” (après une confirmation critique),
• “Parfait.” (quand vous avez assez d’éléments pour agir),
• “Je vérifie.” (quand vous allez introduire un silence perceptible).

Et évitez les phrases longues pour “meubler”. Si vous devez meubler, donnez une information utile : “Je consulte votre dossier, ça prend quelques secondes.”

Petit test simple : réécoutez vos appels. Si vous entendez des silences où l’utilisateur dit “allo ?” ou répète, ce n’est pas “un détail UX” : c’est un signal de latence perçue, donc un signal de risque (AHT, abandon, escalade). Dans un callbot, un silence de trop est souvent plus coûteux qu’une phrase de moins.

FAQ

Questions frequentes

Quelle latence est 'acceptable' pour un callbot ?+

Il n’y a pas un chiffre magique unique, mais les standards télécom indiquent que les délais de transmission importants dégradent fortement la conversation. ETSI (en référence à ITU-T G.114) mentionne des plages de 0–150 ms (préféré), 150–400 ms (acceptable avec dégradation), au-delà de 400 ms (non acceptable) pour la voix conversationnelle. L’enjeu callbot est de limiter la latence bout en bout, pas seulement réseau.¹

Barge-in : indispensable ou gadget ?+

Indispensable. Sans barge-in, vous forcez l’utilisateur à attendre la fin des phrases du callbot, ce qui augmente la durée d’appel (AHT) et la frustration. C’est exactement l’inverse du but.

Pipeline ou Speech-to-Speech pour la latence ?+

Le Speech-to-Speech peut être très performant en latence perçue, mais le pipeline reste souvent plus simple à auditer et à contrôler. La bonne réponse est souvent hybride : S2S pour certains flux, pipeline pour les cas réglementés ou très intégrés.

Pourquoi mon callbot coupe la parole alors que j’ai une VAD ?+

Parce que la VAD détecte la parole, pas l’intention. Un micro-silence n’est pas forcément une fin de tour. Il faut un endpointing calibré (souvent appuyé par le STT) et une logique conversationnelle (états, confirmations) plutôt qu’un seuil fixe universel.

Sources et references

1. [1]ETSI TS 122 105 V16.0.0 (2020-08), section delay “Conversational voice” (référence à ITU-T G.114).
2. [2]Twilio, “Voice latency”.
3. [3]WebRTC VAD (implémentations open source dérivées).
4. [4]Deepgram, “Nova-3” (docs, dont paramètres d’endpointing / end-of-turn).
5. [5]OpenAI, “Realtime API” (WebRTC/WebSocket/SIP connectors).
6. [6]RFC Editor, “RTP: A Transport Protocol for Real-Time Applications” (RFC 3550).
7. [7]RFC Editor, “WebRTC Security Architecture” (RFC 8827).