La latence est l'ennemi numéro un de l'expérience voicebot. Anatomie des sources de délai dans un pipeline STT–LLM–TTS, et leviers concrets pour descendre sous la seconde.
Publié le 28 avril 2026 | Voicebots & Agents Vocaux IA
La latence est l'ennemi numéro un de l'expérience voicebot. Un délai de réponse supérieur à une seconde suffit à briser l'illusion de la conversation naturelle — l'interlocuteur décroche, hésite, ou perd confiance. Pourtant, la latence est mal comprise : elle a plusieurs visages, plusieurs sources, et plusieurs leviers. Voici comment la décomposer et l'attaquer méthodiquement.
La règle d'or : 1 seconde
Pour qu'une conversation vocale semble naturelle, le voicebot doit commencer à répondre dans la seconde qui suit la fin de l'énoncé de l'utilisateur. Au-delà, l'échange devient artificiel. En dessous de 500 ms, l'agent semble vif et réactif.
Mais attention à ne pas confondre latence mesurée et latence perçue. Un agent qui répond en 900 ms mais permet à l'utilisateur de l'interrompre naturellement sera souvent perçu comme plus fluide qu'un agent qui répond en 600 ms mais coupe la parole ou ne laisse pas l'utilisateur finir ses phrases.
Anatomie de la chaîne : où le temps passe
Tout voicebot pipeline (STT → LLM → TTS) accumule de la latence à chaque étape. Voici les ordres de grandeur cibles pour un pipeline streaming bien optimisé :
| Étape | Latence cible | Ce qui la détermine |
|---|---|---|
| Transport audio (WebRTC) | < 50 ms | Topologie réseau, proximité serveur |
| STT — premier token partiel | 100–200 ms | Streaming vs. batch, fournisseur |
| LLM — time-to-first-token | 200–400 ms | Taille du modèle, infrastructure |
| TTS — premier audio | 100–300 ms | Synthèse en streaming |
| Total cible | < 1 s | Pipeline streaming bout en bout |
Un pipeline séquentiel — où chaque étape attend que la précédente soit terminée — produit typiquement 2 à 4 secondes de délai. Inutilisable en production. Le pipeline streaming, qui chevauche les étapes (le STT transmet des transcriptions partielles au LLM pendant que l'utilisateur parle encore, le LLM envoie ses premiers tokens au TTS dès qu'ils sont disponibles), rend la conversation naturelle possible.
L'architecture est le premier levier
Pipeline STT–LLM–TTS
C'est le standard industriel actuel. Trois modèles spécialisés en séquence : 1. STT (Speech-to-Text) : transcrit l'audio en texte 2. LLM : raisonne et génère une réponse textuelle 3. TTS (Text-to-Speech) : synthétise la réponse en audio
Avantages : modulaire, débogable, contrôlable à chaque étape. La latence est compressible avec un bon streaming. Inconvénient : la conversion audio→texte→audio fait disparaître les informations prosodiques (ton, hésitation, émotion).
Realtime speech-to-speech
Certains modèles multimodaux (comme Gemini Native Audio ou GPT-4o Realtime) reçoivent de l'audio brut et restituent de l'audio brut, sans passer par un texte intermédiaire. Avantage structurel sur la latence : moins de sauts, moins de conversions. Ils captent aussi le ton et l'émotion de l'utilisateur.
Inconvénient : moins de contrôle sur chaque composant, coût plus difficile à optimiser, debugging moins transparent.
Half-cascade
Un compromis intéressant : utiliser un modèle realtime pour l'entrée (comprendre l'audio avec ses nuances prosodiques) mais router la sortie vers un TTS dédié pour garder le contrôle de la voix. Utile quand l'identité vocale de la marque est importante.
Turn detection : le détonateur ignoré
La turn detection — la décision de savoir quand l'utilisateur a fini de parler — est le maillon le plus sous-estimé de la latence. C'est lui qui déclenche toute la chaîne de réponse.
Un timeout de silence réglé à 800 ms ajoute 800 ms à chaque réponse, avant même que le STT, le LLM ou le TTS n'aient démarré. Sur une conversation de 10 minutes, c'est des dizaines de secondes de délai cumulé.
Trois approches principales :
VAD-only (Voice Activity Detection) : détecte le silence audio. Simple, mais ajoute une latence proportionnelle au seuil configuré. Sensible au bruit de fond.
STT endpointing : le fournisseur STT émet un signal de fin d'énoncé basé sur son propre modèle. Plus rapide que d'attendre le silence, plus informé que le VAD seul.
Détection sémantique par modèle : un modèle de classification lit la transcription partielle en temps réel et prédit si l'utilisateur a terminé son idée — indépendamment du silence. Peut déclencher la réponse avant la fin du silence. C'est l'approche la plus précise pour les cas complexes ("Je voudrais prendre rendez-vous pour... euh... jeudi prochain").
Interruptions et latence perçue
La gestion des interruptions est le levier le plus impactant sur la latence perçue — sans toucher à la latence mesurée.
Si un utilisateur peut interrompre naturellement l'agent (barge-in), il reprend le contrôle immédiatement, ce qui rend l'échange plus fluide même si la latence absolue reste identique.
Le problème : la détection naïve des barge-ins repose sur le VAD, qui se déclenche aussi sur des backchannels ("mm-hmm", "oui"), des soupirs, des bruits de fond. Si chaque bruit interrompt l'agent, la conversation devient saccadée.
Les approches modernes utilisent un modèle audio dédié qui analyse les caractéristiques acoustiques (forme de l'onde, onset, prosodie) pour distinguer une vraie interruption d'un son incidentel — avec une inférence en moins de 30 ms.
Leviers pratiques : par où commencer
1. Monitorer avant d'optimiser
Sans mesure, toute optimisation est aveugle. Les métriques clés :
- `e2e_latency` : latence totale bout en bout par tour de conversation
- LLM time-to-first-token (TTFT) : temps avant le premier token de réponse
- TTS time-to-first-byte (TTFB) : temps avant le premier audio synthétisé
Identifiez le maillon dominant avant de chercher à optimiser.
2. Co-localiser agent et modèles
C'est le levier à l'impact le plus élevé. Un agent hébergé en Europe qui appelle des modèles aux États-Unis peut facilement ajouter 200 à 400 ms de latence réseau superflue à chaque étape.
3. Choisir des modèles plus rapides sur l'étape dominante
Tester un modèle plus léger ou plus récent sur le maillon lent (souvent le LLM) offre généralement le meilleur ratio effort/impact.
4. Soigner le tool-calling
Si l'agent appelle des outils externes (APIs métier, base de données), ces appels bloquent la génération et ajoutent une latence importante et variable. Bonnes pratiques :
- Limiter le nombre d'exécutions d'outils par tour
- Jouer un son de réflexion pendant l'exécution
- Prévenir l'utilisateur verbalement ("Je vérifie ça pour vous...")
5. Contrôler la taille du contexte
Un prompt système long ou un historique non élagué augmente le nombre de tokens d'entrée traités par le LLM. L'impact est faible, mais c'est un levier gratuit : prompt concis, historique résumé.
6. Précharger le VAD (prewarming)
En production, précharger le modèle VAD avant l'arrivée des sessions évite un délai de démarrage de plusieurs secondes. Incontournable pour tout déploiement sérieux.
En résumé
La latence d'un voicebot n'est pas un paramètre unique — c'est la somme de plusieurs délais accumulés à travers une chaîne complexe. La bonne démarche :
1. Mesurer : identifier le maillon dominant avec des métriques par étape 2. Co-localiser : mettre agent et modèles dans la même région 3. Streamer : s'assurer que chaque étape stream ses sorties partielles 4. Affiner le turn detection : ne pas laisser un timeout arbitraire pénaliser chaque réponse 5. Soigner les interruptions : la latence perçue compte autant que la latence mesurée
Il n'y a pas de silver bullet. Mais en attaquant méthodiquement le maillon dominant, il est tout à fait possible d'atteindre une latence bout en bout inférieure à 1 seconde — et de construire un voicebot qui sonne vrai.