Chaque article de blog d'un fournisseur sur la « voice AI à faible latence » ne parle en réalité que d'un seul maillon du pipeline. Un nouveau modèle vocal qui a réduit la synthèse de 80 ms. Un ajustement de l'endpointing. Une astuce de mise en cache. Chacun est réel — et chacun est inutile si les cinq autres étapes de votre chaîne d'appel consomment 1 200 ms pendant que vous célébrez les 80.
La latence est un budget, pas une fonctionnalité. L'appelant n'entend qu'un seul chiffre : le silence entre le moment où il cesse de parler et celui où votre agent commence. Ce chiffre est la somme de chaque étape, du microphone au haut-parleur, plus le réseau que vous ne contrôlez pas. Voici le modèle de bout en bout — ce que coûte chaque étape, où se cachent réellement les millisecondes, et où le streaming, l'endpointing et la mise en cache vous font véritablement gagner du temps par rapport aux cas où ils ne font que déplacer le problème.
Pourquoi la latence est la frontière entre « de l'AI » et une vraie conversation
Les tours de parole humains ont un rythme. Dans une conversation naturelle, l'intervalle entre les locuteurs est en moyenne d'environ 200 ms, et les gens commencent à préparer leur réponse avant que l'autre personne ait fini. Quand un agent téléphonique laisse 1,5 seconde de silence après chaque phrase, l'appelant ne se dit pas « quelle AI impressionnante ». Il pense que la ligne a coupé, il parle en même temps que l'agent, ou il raccroche.
Les seuils pratiques sur lesquels nous concevons :
- Moins de ~500 ms de temps de réponse : cela donne l'impression d'une conversation. L'appelant remarque à peine l'intervalle.
- 500 à 800 ms est acceptable, mais on entend le côté « assistant ». Cela convient à de nombreux cas d'usage.
- Plus de ~1 000 ms casse le rythme. Les appelants interrompent, se répètent, et la confiance s'érode.
Cet objectif sous la seconde, c'est tout l'enjeu. Et ce n'est pas l'affaire d'un seul composant — c'est le budget que vous répartissez sur l'ensemble de la stack.
Le budget de latence : chaque étape, du micro au haut-parleur
Voici l'aller-retour pour un seul tour de conversation. Fourchettes approximatives en production pour un agent bien conçu lors d'un appel téléphonique :
| Étape | Ce qui se passe | Budget typique |
|---|---|---|
| Entrée audio / réseau entrant | L'audio de l'appelant atteint votre STT (PSTN → SIP → votre edge) | 50–150ms |
| STT (en streaming) | Parole → transcription partielle + finale | 100–300ms |
| Endpointing | Déterminer que l'appelant s'est effectivement arrêté | 200–800ms |
| TTFT du LLM | Prompt → premier token de sortie (time to first token) | 200–600ms |
| Premier octet du TTS | Premier segment de texte → premier audio en sortie | 80–300ms |
| Sortie audio / réseau sortant | Audio synthétisé renvoyé à l'appelant | 50–150ms |
Additionnez tout cela et vous obtenez environ 700 ms à 2,4 s. L'écart est énorme — et remarquez ce qui le domine : l'endpointing et le TTFT du LLM, pas les modèles STT ou TTS que tout le monde évalue.
Deux règles découlent immédiatement de ce tableau :
- Optimisez d'abord le poste le plus important. Remplacer un TTS à 120 ms par un TTS à 90 ms ne change rien si votre détecteur de fin de tour attend 700 ms. Mesurez avant d'optimiser.
- Les étapes se chevauchent quand vous diffusez en streaming. Le budget ci-dessus correspond au pire cas en série. Le streaming permet au STT, au LLM et au TTS de s'exécuter simultanément plutôt que bout à bout — c'est de là que viennent la plupart de vos gains réels (voir ci-dessous).
Détection de fin de tour et de silence : les 500 ms les plus sous-estimées
La détection de fin de tour tranche la question suivante : l'appelant a-t-il terminé son tour de parole, ou a-t-il seulement marqué une pause pour reprendre son souffle ? C'est le plus gros bloc de latence sur lequel vous pouvez agir, et le compromis le plus difficile de toute la pile.
Approche naïve : attendre N millisecondes de silence, puis déclencher. Si N est trop faible (disons 200 ms), vous coupez la parole aux gens en pleine phrase — brutal quand quelqu'un lit un numéro de carte à 16 chiffres ou dit « mon adresse est… 42 Oak Street ». Si N est trop élevé (900 ms), chaque tour de parole paraît poussif.
Ce qui fonctionne vraiment en production, c'est une détection de fin de tour adaptative et sémantique plutôt qu'un minuteur de silence fixe :
- La VAD (détection d'activité vocale) vous donne le signal brut « y a-t-il de l'énergie audio » — rapide, mais aveugle à l'intention.
- La détection de fin de tour sémantique s'appuie sur la transcription partielle pour juger si l'énoncé est complet. « Mon numéro de compte est » est manifestement inachevé ; « Je veux résilier mon compte » est une pensée complète. Un modèle qui lit le texte partiel peut déclencher plus tôt sur les énoncés complets et attendre plus longtemps au milieu d'un numéro.
- Des délais d'attente sensibles au contexte. Quand vous venez de demander un numéro de téléphone, élargissez la fenêtre de silence et ne traitez pas les pauses entre les chiffres comme une fin de tour. Liez le seuil de détection de fin de tour au champ que vous êtes en train de collecter.
Réussissez ce point et vous récupérez 300 à 500 ms sur la plupart des tours de parole sans jamais couper la parole à un appelant. Ratez-le et aucun changement de modèle ne vous sauvera.
Tout diffuser en streaming : la latence gratuite que vous laissez de côté
Le plus gros mensonge du tableau de budget en série, c'est que les étapes se succéderaient l'une après l'autre. Ce ne devrait pas être le cas. Diffusez en streaming à chaque frontière et le pipeline se comprime :
- Transcriptions partielles. N'attendez pas le résultat STT final. Alimentez votre détecteur de fin de tour avec les partiels et préchauffez même le contexte du LLM pour ne pas démarrer à froid quand l'appelant s'arrête.
- Streaming de tokens depuis le LLM. Ce qui compte, c'est le délai jusqu'au premier token, pas le délai jusqu'à la réponse complète. Dès que la première proposition est diffusée, transmettez-la au TTS. Vous n'avez pas besoin de la réponse entière pour commencer à parler.
- Découpage du TTS. Synthétisez et commencez à jouer la première phrase pendant que le LLM en est encore à générer la troisième. C'est le premier octet audio qui compte, pas le clip audio complet.
Bien fait, l'appelant entend les premiers mots de la réponse pendant que le LLM est encore en train d'écrire la suite. C'est ainsi qu'une pile dont le budget en série totalise 1,8 s délivre une réponse perçue en 600 ms. Le streaming n'est pas une optimisation que l'on ajoute après coup — c'est l'architecture dont on part.
Une réserve : diffuser le TTS en cours de génération signifie que vous vous engagez sur des mots avant que la réponse complète n'existe. Si votre LLM est susceptible de se corriger lui-même (« en fait, laissez-moi vérifier — non, vous avez raison »), vous aurez déjà prononcé la mauvaise moitié. Contraignez le modèle à produire des réponses en une seule passe, ou mettez la première proposition en tampon jusqu'à ce que la structure de la phrase soit stable.
Mise en cache audio et préchauffage : de vrais gains, de vrais pièges
La mise en cache, c'est le terrain des articles Vapi du type « nous avons accéléré les choses », et elle est réellement utile — avec des angles vifs.
Ce que l'on peut mettre en cache ou préchauffer sans risque :
- Les invites figées et les formules toutes faites. Messages d'accueil, messages d'attente, mentions légales, « veuillez patienter pendant que je vérifie ». Pré-synthétisez-les une bonne fois. Zéro latence TTS à l'exécution.
- Le préchauffage des connexions. Gardez les sockets STT/LLM/TTS ouverts et les modèles chauds pour que le premier tour d'un appel ne paie pas la taxe du démarrage à froid. Rien que cela peut économiser des centaines de millisecondes sur le premier tour.
- Les phrases de remplissage prévisibles. Un bref et naturel « je vérifie cela pour vous », joué pendant qu'un appel d'outil lent s'exécute, masque une latence backend que l'appelant percevrait autrement comme un blanc.
Ce qui casse si vous le mettez en cache :
- Tout ce qui contient des données dynamiques. Mettez « Votre solde est de [X] » en cache comme modèle et vous finirez par annoncer le mauvais solde au mauvais appelant. Mettez en cache la phrase porteuse, synthétisez le champ variable en direct.
- L'audio personnalisé ou sensible du point de vue de la conformité. Noms, détails de compte, prix annoncés — synthétisez à neuf, à chaque fois.
- Les versions de voix/modèle périmées. Un extrait mis en cache issu d'une ancienne voix TTS, juxtaposé à une voix en direct, s'entend de façon criante en pleine phrase. Versionnez vos clés de cache en fonction du modèle de voix.
La mise en cache vous rapporte le plus sur les parties prévisibles d'un appel. Elle n'apporte rien au tour de raisonnement dynamique — et c'est précisément pourquoi elle ne peut pas constituer toute votre stratégie de latence.
Réalité de la téléphonie et du réseau : le dernier kilomètre qui ne vous appartient pas
Vous pouvez régler chaque modèle à la perfection et livrer malgré tout un agent poussif, car un appel téléphonique circule sur une infrastructure que vous ne contrôlez pas.
- Le RTC et le SIP ajoutent du temps réel. Le réseau téléphonique commuté public et le SIP trunking introduisent un délai de transport avant même que votre STT ne reçoive l'audio. Le transcodage de codec (par exemple, vers/depuis G.711) en ajoute encore un peu.
- Gigue et perte de paquets. Les appelants sans fil, un mauvais Wi-Fi et les opérateurs congestionnés livrent l'audio de façon irrégulière. Votre tampon de gigue lisse la lecture mais ajoute de la latence pour y parvenir — encore un compromis à ajuster, pas à éliminer.
- Géographie. Si votre inférence tourne dans us-east et que votre appelant et votre fournisseur de téléphonie sont en Europe, vous avez ajouté un aller-retour transatlantique à chaque tour de parole. Colocalisez votre chemin média avec vos appelants et vos points de terminaison de modèle.
- Le chemin média compte autant que le modèle. Le pontage WebRTC-vers-SIP, le routage SBC et l'emplacement de votre serveur média peuvent coûter ou faire économiser plus qu'un changement de modèle. C'est de l'ingénierie d'infrastructure, pas du prompt engineering.
À retenir : prévoyez 100–300 ms pour le réseau et la téléphonie que vous ne pouvez pas optimiser, et assurez-vous que les millisecondes que vous pouvez contrôler ne sont pas gaspillées sur un chemin média qui fait des allers-retours entre trois régions.
Mesurer la latence de tour de parole en production (le chiffre qui compte)
Vous ne pouvez pas optimiser ce que vous ne mesurez pas, et la métrique qui compte n'est le benchmark d'aucun composant isolé. C'est la fin de la parole de l'utilisateur jusqu'au début de l'audio de l'agent — mesurée en production, sur de vrais appels, au percentile qui fait mal.
- Instrumentez l'aller-retour complet. Horodatez : dernière trame audio de l'appelant → détection de fin de parole déclenchée → premier token du LLM → premier octet du TTS → première trame audio sortante. Enregistrez chaque étape à chaque tour de parole pour voir quelle boîte a fait exploser le budget quand un appel a semblé lent.
- Surveillez le p95, pas la moyenne. Votre latence moyenne peut être d'un joli 550 ms alors que le p95 est à 1,8 s — et ce sont les tours à p95 qui font raccrocher les appelants. Les moyennes cachent les appels que vous perdez.
- Suivez le taux de barge-in / d'interruption. Si les appelants parlent souvent par-dessus votre agent, votre détecteur de fin de parole se déclenche trop tard ou votre réponse démarre trop lentement. C'est un symptôme de latence déguisé en métrique UX.
Déployez l'instrumentation avant d'optimiser. Toute affirmation du type « nous avons réduit la latence » qui n'est pas étayée par une mesure du p95 en production est une supposition.
Liens internes
- Comment nous avons construit le pipeline Voice AI — choix de STT : Whisper vs Deepgram
- Corriger la latence SIP dans les solutions de centre d'appels AI
- Faire le pont entre WebRTC et SIP : transferts d'agents vocaux AI à faible latence
- Agents vocaux AI pour l'entreprise : architecture et ROI
- Comment gérer des volumes d'appels élevés sans recruter plus d'agents (2026)
FAQ
Qu'est-ce qu'une bonne cible de latence pour un agent vocal AI en production ? Visez moins de 800 ms de bout en bout (de la fin de la parole de l'appelant au début de l'audio de l'agent), et considérez le sous-500 ms comme l'objectif pour un ressenti vraiment conversationnel. Mesurez au p95, pas en moyenne — c'est la queue lente qui provoque les raccrochages.
Quelle partie du pipeline de voice AI cause le plus de latence ? Généralement la détection de fin de parole et le délai avant le premier token du LLM, pas les modèles STT ou TTS sur lesquels se concentrent la plupart des benchmarks. La détection de fin de parole peut à elle seule ajouter 200–800 ms, c'est donc le premier endroit où regarder avant de changer le moindre modèle.
La mise en cache audio réduit-elle la latence de la voice AI ? Oui, pour le contenu fixe — les messages d'accueil, les mentions légales, les messages d'attente et les phrases de remplissage peuvent être pré-synthétisés pour une latence d'exécution quasi nulle. Cela ne change rien pour les tours de raisonnement dynamique, et mettre en cache quoi que ce soit contenant des données personnalisées ou variables risque de communiquer la mauvaise information à un appelant.
Pourquoi mon agent vocal semble-t-il lent même avec un modèle rapide ? Parce que la latence est la somme de tout le pipeline plus la téléphonie que vous ne contrôlez pas. Un TTS rapide n'aidera pas si votre détecteur de fin de parole attend 700 ms, si votre LLM diffuse lentement ou si votre chemin média fait des allers-retours entre les régions. Instrumentez chaque étape et corrigez la plus grosse boîte en premier.
Finn est conçu latence-first — STT en streaming, détection sémantique de fin de parole et passage du token au TTS ajustés pour atteindre des tours de parole en moins d'une seconde sur de vrais appels téléphoniques, pas sur des extraits de benchmark. Découvrez comment les agents vocaux de Finn gèrent le volume d'appels en production sans les blancs.
