Latence d'un callbot : le critère qui décide de tout

Un callbot peut avoir la voix la plus naturelle du marché et un moteur de langage capable de comprendre n'importe quelle reformulation : si sa réponse met plus d'une seconde à arriver, rien de tout cela ne se perçoit. La latence est le seul critère qu'un appelant juge avant même d'avoir écouté le contenu de la réponse — et c'est celui sur lequel les éditeurs communiquent le moins précisément, un chiffre de fiche produit décrivant presque toujours un seul maillon de la chaîne, mesuré hors ligne téléphonique. Ce guide fixe les repères que l'oreille humaine tolère, détaille où les millisecondes s'accumulent dans le pipeline vocal, et propose une méthode pour mesurer cette latence sur vos propres appels plutôt que sur une fiche technique.

Ce que l'oreille humaine tolère

En conversation humaine, le délai moyen entre la fin d'une phrase et le début d'une réponse se situe autour de 200 millisecondes, selon l'étude de référence sur le sujet — Stivers et al., 2009, menée sur dix langues. Ce n'est pas une cible technique atteignable — aucune plateforme vocale n'égale la vitesse d'un cerveau humain qui anticipe la fin d'une phrase avant qu'elle ne soit terminée — mais un point de repère, qui explique pourquoi tout délai supplémentaire se remarque, même chez un appelant incapable de le chiffrer.

Au-delà de 700 à 800 millisecondes environ, l'appelant perçoit un décalage. Ce repère n'est pas propre à l'intelligence artificielle : bien avant les callbots, la norme ITU-T G.114 fixait déjà à 150 millisecondes le délai de transmission à sens unique en dessous duquel un appel reste transparent, et à 400 millisecondes la limite jugée inacceptable — un callbot ajoute son propre traitement par-dessus ce budget réseau déjà loin d'être nul.

Passé environ une seconde, voire une seconde et demie selon l'enjeu de l'appel, l'illusion de naturel se casse franchement : l'appelant reprend la parole en pensant que le bot n'a pas compris, répète sa demande, ou raccroche — un gradient, pas un couperet unique, où chaque tranche de délai supplémentaire dégrade un peu plus la perception.

Où naît la latence dans le pipeline

« La latence d'un callbot » n'est jamais un seul chiffre : c'est la somme de plusieurs maillons qui s'enchaînent — ou se chevauchent, sur les architectures récentes — entre le silence de l'appelant et le premier son audible de la réponse. Twilio publie sa propre grille de référence (novembre 2025), étage par étage plutôt qu'en total agrégé :

Étage	Cible visée	Limite haute
Réseau : trajet aller-retour complet	~230 ms	~300 ms
Reconnaissance vocale (STT)	350 ms	500 ms
Modèle de langage, premier jeton	375 ms	750 ms
Synthèse vocale, premier octet audio	100 ms	250 ms
Total bouche-à-oreille	≈ 1 115 ms	≈ 1 400 ms

Le total n'est pas une simple addition des 4 lignes : Twilio ajoute aussi un surcoût d'orchestration interne entre étages, non attribuable à un seul maillon — mise en mémoire tampon, transcodage de codec entre les briques — d'environ 60 ms sur la cible ; et la limite haute qu'elle publie est un agrégat mesuré, pas la somme des pires cas de chaque étage, ces pires cas ne se produisant pas tous simultanément sur un même appel.

Deux maillons concentrent l'essentiel de la variance d'un appel à l'autre. Le premier est invisible dans ce tableau : à l'intérieur de la reconnaissance vocale se cache la détection de fin de tour (endpointing), la décision que l'appelant a fini de parler. Un minuteur trop court coupe la parole à qui hésite ; trop long, il ajoute des centaines de millisecondes inutiles — Cekura résume le dilemme : une pause de 400 millisecondes paraît déjà poussive au téléphone, une seconde complète paraît franchement cassée. Deepgram propose une détection anticipée, qui laisse le modèle réfléchir avant la fin officielle du tour : un gain de 100 à 200 millisecondes, payé par 50 à 70 % d'appels supplémentaires au modèle — dont une partie sera jetée si l'appelant n'avait pas terminé.

Le second maillon caché est celui que les fiches produit omettent le plus souvent : le trajet téléphonique lui-même. Un test indépendant mené par TECHSY en juin 2026, relayé par Telnyx, mesure sur le seul saut opérateur pur — le trajet réseau brut, avant tout traitement — des latences de 70 à 95 millisecondes en médiane, jusqu'à 161 millisecondes sur les appels les plus lents ; la ligne « Réseau » du tableau ci-dessus est plus large, puisqu'elle inclut en plus la mise en mémoire tampon et le décodage internes à la plateforme, ce qui explique l'écart entre les deux chiffres. Un modèle de synthèse vocale annoncé à 75 millisecondes mesure ainsi, selon ElevenLabs, le seul calcul du modèle, avant d'y ajouter le réseau (20 à 200 ms) et la mise en mémoire tampon du lecteur audio (500 ms est courant). Un chiffre qui ne précise ni le périmètre mesuré ni la présence d'une vraie ligne téléphonique ne se compare à rien — le même problème de méthode que nous détaillons pour les taux de résolution dans comment choisir un callbot.

Mesurer la latence réelle d'un appel

Un chiffre obtenu en démonstration commerciale ne dit presque rien : la démonstration tourne sur un réseau propre, sans concurrence d'autres appels, avec un scénario déjà rodé. Seule une mesure sur de vrais appels, dans vos conditions, compte. Voici une méthode reproductible, sans outillage spécialisé.

1. Enregistrer des appels réels, pas une démonstration. Demandez l'export de l'enregistrement audio complet (.wav ou .mp3) d'une série d'appels réellement passés par des appelants — la plupart des plateformes et opérateurs le permettent sur demande.

2. Chronométrer précisément, sur chaque tour de parole. Ouvrez l'enregistrement dans un éditeur audio gratuit affichant la forme d'onde, et repérez, pour chaque tour de l'appel (pas seulement le premier, parfois artificiellement plus rapide ou plus lent), l'instant où la voix de l'appelant s'arrête et celui où le premier son du callbot commence : cet écart est la latence bouche-à-oreille, la seule qui compte pour l'appelant.

3. Répéter sur un échantillon d'appels, pas un seul. Une vingtaine d'appels distincts, à des heures différentes, suffit généralement à distinguer un outil régulier d'un outil qui a de bons et de mauvais jours.

4. Retenir une médiane et une valeur haute, pas une moyenne isolée. Classez les mesures et relevez la médiane ainsi qu'une valeur haute (la plus lente sur dix, une approximation du 90ᵉ centile) — le principe déjà détaillé dans notre grille de critères de choix d'un callbot : un outil à 400 ms en moyenne mais avec des pics à deux secondes paraît moins fluide qu'un outil régulier à 500 ms.

5. Tester en conditions dégradées. Reprenez une partie de l'échantillon depuis un mobile en zone de couverture moyenne, avec du bruit de fond réel, et si possible pendant un pic de simultanéité d'appels : un outil mesuré à 500 ms en test isolé peut dériver nettement dès que plusieurs appels se chevauchent sur la même ligne.

6. Recommencer périodiquement. Un changement de modèle, une bascule d'infrastructure ou une mise à jour de consignes côté éditeur peuvent faire dériver la latence sans alerte visible. Une mesure faite une seule fois avant signature ne garantit rien douze mois plus tard.

Avec accès aux journaux techniques d'un intégrateur, la même mesure se fait par points d'ancrage plutôt qu'à l'oreille — méthode détaillée par AssemblyAI : horodatage de fin de tour, du premier jeton du modèle, du premier octet audio en sortie. Ces écarts mis bout à bout donnent la même latence totale qu'au chronomètre, en indiquant en plus à quel étage elle se construit.

Leviers de réduction

Une fois la latence mesurée et le maillon fautif identifié, plusieurs leviers existent — aucun n'est gratuit : chacun se paie en coût de calcul, en risque d'erreur, ou en qualité perçue ailleurs.

Levier	Gain typique documenté	Contrepartie
Détection de fin de tour anticipée (eager end-of-turn)	100 à 200 ms	50 à 70 % d'appels supplémentaires au modèle de langage
Diffusion des jetons du modèle en flux, sans attendre la réponse complète	100 à 300 ms	orchestration technique plus complexe
Codec téléphonique unique de bout en bout	100 à 300 ms	suppose une infrastructure télécom modernisée
Hébergement rapproché et réutilisation de connexion	40 à 100 ms	disponibilité régionale du fournisseur
Voix pré-chargée, phrases fréquentes en cache	100 à 200 ms	ne fonctionne que sur des réponses répétitives
Appels annexes (CRM, agenda) rendus asynchrones	50 à 200 ms	complexité de développement supplémentaire

Sources : Vapi, Deepgram.

Le choix et l'hébergement du modèle de langage pèsent au moins autant que ces réglages : le temps avant le premier jeton varie de plusieurs centaines de millisecondes d'un modèle à l'autre, et le classement Artificial Analysis relayé par MarkTechPost fin août 2026 montre qu'un même modèle répond plus vite ou plus lentement selon l'hébergeur choisi, indépendamment de ses paramètres — un sujet suivi dans notre pilier IA & modèles.

L'architecture compte enfin davantage que chaque réglage isolé : Retell documente l'écart entre un pipeline séquentiel, qui attend la fin complète de chaque étage, et un pipeline en flux, où transcription, génération et synthèse démarrent dès que les premiers éléments sont prêts — l'écart se compte en secondes, pas en dixièmes de seconde.

Arbitrages qualité/latence/coût

Aucun de ces leviers n'est un gain pur : chacun déplace le curseur ailleurs, et le bon réglage dépend du cas d'usage.

Une détection de fin de tour trop agressive gagne des millisecondes mais coupe la parole aux appelants qui marquent une pause pour réfléchir ou épeler un nom. Un modèle plus rapide est souvent plus petit, donc moins capable sur une reformulation complexe : le gain de vitesse peut se traduire par davantage de transferts vers un humain, annulant une partie du bénéfice perçu. Une infrastructure optimisée pour la vitesse — codec unique, hébergement dédié — coûte presque toujours plus cher à intégrer qu'une configuration générique, détaillé dans les coûts cachés d'un projet callbot.

Le sens de l'appel déplace aussi le curseur. Un callbot entrant répond à un appelant dont le budget de patience est très court, puisqu'il a déjà pris l'initiative d'appeler : la latence y pèse au maximum. Un callbot sortant, qui compose lui-même le numéro, dispose d'une marge un peu plus large — une demi-seconde de battement en tout début d'échange se remarque moins qu'en plein milieu d'un dialogue déjà engagé.

Un service client à fort volume, sur des demandes simples, peut raisonnablement privilégier la vitesse brute, quitte à perdre quelques points de précision sur les cas rares. Un scénario réglementé ou à fort enjeu — santé, finance, réclamation sensible — peut au contraire accepter 200 à 300 millisecondes supplémentaires en échange d'un modèle plus capable et d'une détection de fin de tour plus prudente.

Questions fréquentes

Quelle latence faut-il viser pour qu'un callbot paraisse naturel ?

Viser un délai sous 700 à 800 millisecondes environ entre la fin de la phrase de l'appelant et le début de la réponse : le seuil au-delà duquel le décalage devient perceptible. Au-delà d'une seconde à une seconde et demie, l'illusion de naturel se casse franchement et l'appelant reprend la parole, répète sa demande ou raccroche. La moyenne seule ne suffit pas : un outil à 400 ms en moyenne mais avec des pics à deux secondes paraîtra moins fluide qu'un outil régulier à 500 ms, nettement sous le seuil de perception.

Pourquoi la latence annoncée par un éditeur ne correspond-elle jamais à ce que j'entends en appel réel ?

Parce que le chiffre publié décrit le plus souvent un seul maillon — un modèle de synthèse vocale seul, par exemple — mesuré hors ligne téléphonique, sans réseau opérateur ni détection de fin de tour. Chaque maillon supplémentaire ajoute des dizaines à des centaines de millisecondes que la fiche produit ne montre pas, et un chiffre sans périmètre ni conditions de test précisés n'est comparable à rien.

Combien d'appels faut-il mesurer pour obtenir un chiffre fiable ?

Une vingtaine d'appels distincts, répartis sur plusieurs créneaux horaires, suffit généralement à distinguer un outil régulier d'un outil qui affiche une bonne moyenne mais des pics fréquents. Mesurez chaque tour de parole de chaque appel, pas seulement le premier échange, et retenez la valeur haute plutôt que la seule moyenne.

Une latence plus faible signifie-t-elle toujours une meilleure expérience ?

Non. Une détection de fin de tour trop agressive gagne des millisecondes mais coupe la parole aux appelants qui hésitent ; un modèle plus rapide est parfois moins capable sur les demandes complexes, ce qui peut augmenter les transferts vers un humain et annuler une partie du gain perçu. La latence reste un critère décisif, mais elle se pondère avec la précision des réponses et le coût de l'infrastructure qui la permet.

En résumé

La latence d'un callbot se juge sur trois repères : environ 200 millisecondes pour la référence conversationnelle humaine, 700 à 800 millisecondes pour le seuil de perception de gêne, environ une seconde à une seconde et demie pour la rupture franche de l'illusion de naturel. Elle se construit sur plusieurs maillons — réseau, détection de fin de tour, reconnaissance vocale, modèle de langage, synthèse vocale, transport téléphonique — que les chiffres publiés par les éditeurs décrivent rarement dans leur ensemble. La seule façon de savoir ce que vos appelants vivront réellement est de la mesurer vous-même, sur des appels réels, en échantillon suffisant et en conditions dégradées, puis de répéter la mesure dans le temps plutôt qu'une seule fois avant signature. Si vous voulez appliquer cette méthode à votre projet, parlons-en.