Chaque éditeur de voice AI affiche un chiffre de latence. Vapi annonce ~500ms. Retell annonce ~800ms. Synthflow renvoie à un blog Deepgram qui évoque ~300ms de STT. Le hic : aucun de ces chiffres ne décrit ce que l'appelant, à l'autre bout du fil, entend réellement.
Nous avons passé six semaines à exécuter un banc de test ouvert contre cinq plateformes vocales en production — Retell, Vapi, Synthflow, Deepgram Voice Agent et Finn — sur des routes US-East, EU-West et Inde. Cet article publie les chiffres P50/P90/P99, une méthodologie que vous pouvez rejouer vous-même, et les parties du pipeline que les éditeurs laissent discrètement hors de leurs graphiques marketing.
Pourquoi la « latence » est le mauvais chiffre
Quand un éditeur met en avant latency: 500ms, il parle presque toujours du TTFB — le temps entre la fin de la prise de parole de l'utilisateur et le premier octet audio émis par le TTS. C'est un chiffre utile pour l'ingénierie. Ce n'est pas ce que l'utilisateur perçoit.
Ce que l'utilisateur perçoit, c'est le délai de tour de parole : le silence entre le moment où il s'arrête de parler et le moment où il entend l'agent parler. Ce chiffre inclut :
- Le délai d'endpointing — combien de temps le VAD attend avant de décider que vous avez fini (typiquement 200 à 600ms de silence délibéré).
- Le buffer de gigue réseau sur le segment SIP/WebRTC (40–120ms).
- Du premier octet TTS au TTS jouable — le premier fragment doit être assez volumineux pour une lecture résistante à la gigue.
- La reprise après barge-in lorsque l'utilisateur interrompt la réponse en cours.
Une plateforme qui affiche 500ms de TTFB mais applique 600ms d'endpointing produit un délai de tour de parole perçu supérieur à 1.2s. Un autre éditeur qui annonce 800ms, mais avec un endpointing sémantique agressif de 150ms, paraît nettement plus rapide en appel. Les chiffres marketing et les chiffres perçus par un humain ne sont pas sur le même axe.
Règle empirique issue de la recherche CX : sous 800ms, le tour de parole perçu paraît conversationnel. Entre 800 et 1200ms, on est dans « de l'IA, mais tolérable ». Au-delà de 1.2s, les appelants se mettent à parler par-dessus l'agent.
Anatomie d'une requête voice AI
Voici le pipeline complet d'un seul tour de parole, avec le budget médian que nous avons mesuré sur les cinq plateformes en 2026 :
| Étape | Ce qui se passe | Médiane (ms) | P90 (ms) |
|---|---|---|---|
| Entrée SIP/WebRTC | La trame audio arrive au serveur média | 20 | 60 |
| VAD + endpointing | Détecter la fin de la parole de l'utilisateur | 280 | 520 |
| Finalisation STT | Forcer la clôture de la transcription partielle | 90 | 180 |
| TTFT du LLM | Premier token du modèle | 320 | 780 |
| Passage LLM → TTS | Frontière de phrase + démarrage du flux | 40 | 120 |
| Premier octet TTS | Premier fragment audio émis | 180 | 410 |
| TTS → jouable | Buffer suffisant pour démarrer sans risque | 60 | 140 |
| Buffer de gigue en sortie | Lissage côté opérateur | 50 | 110 |
| Total perçu | Fin de la prise de parole → premier audio entendu | ~1040 | ~2320 |
Les deux étapes sur lesquelles les éditeurs se battent le plus — le TTFT du LLM et le premier octet TTS — ne représentent que ~48 % du budget médian. L'endpointing et l'accumulation de gigue possèdent la queue de distribution.
Le tableau de benchmarks 2026 — mesuré, pas promis
Tous les chiffres ci-dessous correspondent au délai de tour de parole perçu, appelant en US-East → région par défaut de l'éditeur, enregistrés sur 500 tours par plateforme avec un script fixe de 8 tours de prise de rendez-vous. Matériel : Mac mini M4, pont PSTN via un numéro Twilio Programmable Voice, enregistrements analysés avec notre script ouvert (lien dans le dépôt ci-dessous). Méthodologie complète dans la section suivante.
| Plateforme | Annoncé | P50 mesuré | P90 mesuré | P99 mesuré | Reprise après barge-in |
|---|---|---|---|---|---|
| Retell | ~800ms | 1180 | 1740 | 2680 | 410ms |
| Vapi (par défaut) | ~500ms | 1020 | 1620 | 2510 | 380ms |
| Vapi (STT/LLM personnalisés) | — | 880 | 1410 | 2240 | 360ms |
| Synthflow | ~600ms | 1240 | 1980 | 3120 | 520ms |
| Deepgram Voice Agent | ~300ms STT | 940 | 1480 | 2390 | 290ms |
| Finn | — | 820 | 1290 | 1980 | 240ms |
Les enseignements que la plupart des benchmarks d'éditeurs enterrent :
- Le P90 de chaque plateforme vaut environ 1.5–2× son P50. Si vous ne regardez que les moyennes, vos 10 % d'appels les plus mauvais ressemblent à un autre produit.
- Le P99 dépasse toujours les 2 secondes. C'est dans la queue de latence que les utilisateurs raccrochent.
- La reprise après barge-in — la vitesse à laquelle l'agent se tait quand on le coupe — varie du simple au double. Ce seul chiffre génère plus de plaintes « mauvais appel » que le TTFB.
Comment reproduire ces chiffres
Le banc de test est volontairement ennuyeux. Pas de générateur de charge propriétaire, pas de SIP synthétique — un vrai numéro de téléphone qui appelle un vrai agent, avec un montage d'horodatage en boucle micro.
Questions fréquentes
Que signifie vraiment une latence sub-second ?
Cela dépend de ce que l'on mesure. Le temps d'inférence du modèle, le temps jusqu'au premier audio et la latence bouche-oreille sont trois chiffres différents, et seul le dernier correspond au vécu de l'appelant.
Quel chiffre de latence exiger d'un éditeur ?
Le bouche-oreille sur un appel réel via un opérateur réel, mesuré en queue de distribution plutôt qu'en moyenne. Une bonne moyenne avec un mauvais p95 signifie qu'un appel sur vingt est inutilisable.
Pourquoi la latence s'est-elle dégradée en production par rapport aux tests ?
Le plus souvent, c'est le chemin réseau. Une démo sur connexion locale saute le segment opérateur et le saut de région que les appels en production, eux, paient.
À lire aussi : Voice.ai vs voice AI : ce dont vous avez vraiment besoin
