Latence d'un agent vocal : où se perd le temps

La latence d'un agent vocal, c'est le temps entre la fin de la phrase de l'appelant et le début de la réponse entendue. Dans une conversation téléphonique, un silence trop long fait croire que la ligne est coupée. Il n'existe pas de seuil officiel, et aucune page lue ici n'en publie un. Pour le trouver, il faut mesurer sur ses propres appels.

Où le temps se perd

Un tour de parole traverse quatre endroits :

1. Le réseau. L'audio va du téléphone ou du navigateur jusqu'au serveur, puis revient. Le chemin dépend de la région où tourne l'agent.
2. La reconnaissance. Le texte n'est disponible qu'après le traitement de l'audio. Un résultat partiel arrive plus tôt, mais il peut changer.
3. Le modèle. Le temps avant le premier mot de la réponse dépend du modèle, de la taille du contexte et de la charge du fournisseur.
4. La synthèse. Le premier morceau d'audio doit exister avant d'être envoyé. Une synthèse qui attend la fin du texte ajoute tout le temps de génération.

À cela s'ajoute le temps de détection de fin de parole. C'est souvent le plus gros poste, parce que l'agent attend un silence avant de répondre. Un délai court répond plus vite, mais coupe l'appelant qui marque une pause. La page sur la détection de fin de parole détaille ces réglages.

Les leviers décrits par les documentations

Le streaming. Deepgram présente son modèle Flux STT comme « ultra-low latency optimized for voice agent pipelines », avec une détection de fin de tour intégrée. AssemblyAI envoie des messages Turn pendant la parole, avant la fin du tour. Le streaming évite d'attendre la fin de l'audio.

La synthèse en flux. ElevenLabs propose un point d'accès en flux (/v1/text-to-speech/{voice_id}/stream) et un réglage de latence allant de 0 à 4. Au niveau 4, la normalisation du texte est désactivée, ce qui réduit encore le délai mais peut mal prononcer des nombres et des dates. La page indique que le gain du niveau 1 représente « about 50% of possible latency improvement of option 3 », et le niveau 2 « about 75% ». Ce sont des proportions relatives, pas des millisecondes. La même page précise que le paramètre de réglage est déprécié et que « the best possible final latency varies by model ».

Les réglages qui ajoutent du délai. Toujours chez ElevenLabs, l'option de renforcement de voix use_speaker_boost demande « a slightly higher computational load », et la normalisation de langue peut « heavily increase the latency of the request ».

Le choix de région. Telnyx décrit un « Anchorsite », c'est-à-dire la sélection du point de présence régional pour optimiser les médias. C'est un levier réseau concret, à vérifier chez votre opérateur.

Les réglages de tour. La documentation LiveKit donne des valeurs d'exemple pour la téléphonie temps réel : silence_duration_ms=400, prefix_padding_ms=300, threshold=0.7. Ce sont des réglages, pas des mesures. Ils illustrent le compromis : raccourcir le silence accélère la réponse, mais augmente le risque de couper l'appelant.

Ce que les documentations disent mesurer

Les pages lues ne publient pas de chiffre de latence de bout en bout pour un agent complet. La page de métriques de LiveKit Agents indique que l'onglet « Agent insights » affiche des métriques, et que les « Data hooks » permettent d'en collecter dans le SDK. Elle renvoie vers ces pages sans en reprendre les noms ni les définitions dans la page lue. La détection d'activité vocale Silero, elle, annonce un traitement de « one audio chunk (30+ ms) » en « less than 1ms » sur un seul thread CPU : c'est un chiffre pour une seule brique, sur le matériel de l'éditeur.

Le constat est simple : les éditeurs publient des chiffres partiels, pour une brique ou un mode, rarement pour le tour complet.

Méthode de mesure

1. Définir le tour. Le point de départ est la fin de la phrase de l'appelant, détectée par votre enregistrement ou par l'horodatage du serveur. Le point d'arrivée est le premier son de la réponse.
2. Mesurer par appel, pas en moyenne seule. Gardez les valeurs de chaque tour. La moyenne cache les pics, et les pics sont ce que l'appelant remarque.
3. Découper. Mesurez séparément la détection de fin de parole, la reconnaissance, le modèle et la synthèse. Un tour lent n'a pas toujours la même cause.
4. Tester les réglages un par un. Changez un seul paramètre entre deux séries d'appels de test.
5. Garder la date et la région de chaque mesure. Une mesure faite en janvier depuis Paris ne dit rien d'une mesure faite en novembre depuis une autre région.

À retenir

La latence se joue dans plusieurs endroits à la fois, et le plus lent n'est pas toujours celui que l'on pense. Commencez par découper le tour, puis optimisez la brique la plus lente. Pour l'architecture qui conditionne ces choix, lisez l'architecture d'un agent vocal.