À quelle vitesse votre agent vocal IA doit-il répondre ?

Un agent vocal IA en production doit commencer à parler dans les 800 ms à 1,2 seconde suivant la fin d'une phrase de l'appelant. Au-delà de 2 secondes, les appelants supposent que la ligne est coupée, commencent à se répéter ou raccrochent. Que vous évaluiez des prestataires ou que vous construisiez cette solution en interne, la latence n'est pas une métrique secondaire — c'est la différence entre un agent auquel les gens font confiance et un agent qu'ils contournent.

Pourquoi la latence détermine la confiance des utilisateurs envers l'agent

La conversation humaine a un rythme. Des recherches sur la prise de parole dans différentes langues ont montré que le délai moyen entre la fin d'une phrase et le début de la suivante est d'environ 200 millisecondes, parfois même avant que le premier interlocuteur ait fini (Stivers et al., PNAS). Personne n'attend d'une IA qu'elle atteigne 200 ms aujourd'hui, mais c'est cette référence qu'elle doit rivaliser, pas les 3 à 5 secondes qu'un client pourrait tolérer sur une page web lente.

Du côté des interfaces, les seuils de temps de réponse de Nielsen Norman Group font référence : en dessous de 0,1 s, la réponse semble instantanée ; jusqu'à 1 s, le fil de pensée de l'utilisateur reste intact ; au-delà de 10 s, il a mentalement décroché. La voix comprime cette échelle, car il n'y a ni spinner ni barre de progression — seulement le silence — et un délai de 2 secondes lors d'un appel semble bien plus long que le même délai sur une page web.

C'est particulièrement critique pour tout ce qui est transactionnel : modification de réservation, suivi de commande, tri de demandes de support, vente sortante. Si vous évaluez cela par rapport à un canal texte, la barre de latence pour un agent commercial IA sur WhatsApp est bien plus indulgente — quelques secondes passent pour un temps de frappe normal. La voix ne bénéficie d'aucune telle indulgence.

Où vont réellement les millisecondes

Un pipeline d'agent vocal typique comporte trois étapes, et la plupart des implémentations les exécutent séquentiellement :

1. Speech-to-text (STT) : transcription de l'audio de l'appelant. 150 à 500 ms selon qu'il s'agit de streaming ou de traitement par lot.
2. Génération LLM : décision de ce qu'il faut dire et génération de la réponse complète. 500 ms à 2 s+, selon la taille du modèle, la longueur du prompt et les éventuels appels d'outils (consultation d'une commande, vérification d'un calendrier) avant de pouvoir répondre.
3. Text-to-speech (TTS) : conversion de la réponse textuelle complète en audio. 200 ms à 1 s.

Additionnés séquentiellement, et avant même les allers-retours réseau, on atteint facilement 1,5 à 3,5 secondes avant que l'appelant entende quoi que ce soit. C'est ce délai qui donne l'impression que l'agent est défaillant.

La solution n'est pas un modèle plus rapide, c'est de ne pas attendre la réponse complète avant de commencer à parler. Transmettre en streaming la sortie token par token du LLM vers le TTS, et commencer à parler dès que la première phrase est prête plutôt qu'attendre la réponse entière, permet de réduire concrètement le délai perçu — c'est l'idée que certaines équipes ont formalisée sous l'approche « streaming de phrases, pas d'audio ». Il s'agit d'une décision architecturale, pas d'une mise à niveau de modèle, et c'est généralement le levier le plus efficace disponible.

Les appels d'outils compliquent les choses. Si l'agent doit consulter une base de données avant de répondre (« je vérifie votre commande »), cette requête doit s'exécuter dans la fenêtre de délai et nécessite sa propre stratégie de remplacement — un accusé de réception naturel (« une seconde, je recherche ça ») plutôt qu'un silence mort. C'est l'une des raisons pour lesquelles les systèmes vocaux agentiques nécessitent une orchestration plus soignée qu'un simple remplacement de SVI scripté : l'agent effectue un vrai travail en cours de conversation, il ne se contente pas de réciter un texte.

Comment évaluer un prestataire sur la latence

Ne prenez pas une vidéo de démonstration pour argent comptant. Demandez :

• Un appel en direct, sans script sur votre propre réseau, et non une démonstration pré-enregistrée sur une infrastructure inactive.
• Le time-to-first-audio-byte, mesuré — et non le « temps de réponse », que certains prestataires présentent parfois comme le time-to-first-token du LLM, en ignorant le TTS.
• La latence sous charge simultanée. Un seul appel de test ne vous dit rien sur ce qui se passe à 50 appels simultanés, lorsque les files d'attente GPU et les limites de débit entrent en jeu.
• Ce qui se passe lors des appels d'outils. Demandez-leur de déclencher une vraie requête (CRM, calendrier, système de commandes) en cours d'appel et mesurez le délai.
• Le routage régional. Si vos appelants se trouvent dans le Golfe ou ailleurs hors de la région par défaut du prestataire, renseignez-vous sur l'endroit où l'inférence s'exécute réellement — un modèle hébergé à l'autre bout du monde ajoute un temps d'aller-retour réel, limité par la physique, qu'aucune ingénierie ne peut compenser.

Ce dernier point se cumule si vous gérez également de la parole avec accent ou une langue autre que l'anglais. L'ASR en arabe présente notamment de vrais compromis entre précision et latence, car les modèles haute précision pour les dialectes du Golfe sont souvent plus lents et plus coûteux que les STT génériques en anglais.

Si vous contractualisez l'un de ces éléments, traitez la latence comme vous traiteriez un chiffre de précision — définissez-la, et tenez le prestataire responsable. La même rigueur appliquée aux évaluations dans les contrats prestataires IA s'applique directement ici : sans SLA mesurable, « rapide » signifie ce que le prestataire a jugé bon lors de la démonstration.

Signaux d'alerte

• Le prestataire est incapable de vous citer son time-to-first-audio-byte en p50/p95 spontanément.
• La démo ne fonctionne bien que sur des questions scriptées — posez quelque chose hors script et observez le délai s'allonger.
• « Assez rapide » est la seule réponse que vous obtenez quand vous demandez un chiffre.
• Aucune mention du streaming nulle part dans leur architecture — s'ils attendent une réponse LLM complète avant de lancer le TTS, vous êtes enfermé dans le chemin lent quel que soit le modèle qu'ils substituent.

En résumé

La latence est une décision d'architecture, pas une décision de sélection de modèle. Un pipeline bien conçu sur un modèle intermédiaire battra systématiquement un pipeline mal streamé sur le meilleur modèle disponible. Avant de signer avec un prestataire ou de valider un développement, obtenez un vrai chiffre — pas une impression — et si vous intégrez l'IA dans un produit existant, prévoyez du temps d'ingénierie pour la plomberie du streaming dès le départ, car le retrofitter par la suite est une réécriture, pas un correctif.

Si vous évaluez un agent vocal et souhaitez un avis extérieur sur la solidité des affirmations d'un prestataire en matière de latence, parlons-en.