Voice AI sub-800 ms : ce qu'on a appris à monter un assistant vocal qui répond comme un humain
Un humain attend, en moyenne, 300 à 500 millisecondes entre la fin de votre phrase et le début de sa réponse. Au-delà d'une seconde, c'est inconfortable. Au-delà de trois, la conversation est cassée — la personne raccroche, ou pire, vous parle dessus et tout part en cacahuète.
La plupart des assistants vocaux IA en production en 2026 tournent entre 1,5 et 2,5 secondes (Twilio Engineering, 2026). C'est l'état de l'art "qui marche sans optimiser". On l'a constaté de visu sur trois assistants tiers qu'on a benchmarkés en début d'année. Les utilisateurs raccrochent. Les SLA explosent. C'est triste.
On a réussi à descendre à 620 ms en médiane sur un pilote client il y a deux mois. Pas parce qu'on a trouvé le composant magique — il n'y en a pas. Mais parce qu'on a refusé de mettre les choses en série quand on pouvait les streamer en parallèle.
Voilà ce qu'on a appris, avec les chiffres réels et les pièges.
Le problème, ce n'est pas un composant lent
Avant de parler architecture, posons les chiffres absolus, parce que c'est important de réaliser que les composants individuels sont très rapides en 2026.
Le STT meilleur de sa catégorie aujourd'hui, c'est AssemblyAI Universal-Streaming à 90 ms pour le premier mot, ou Deepgram Nova-3 Flux autour de 150 ms (Future AGI benchmark 2026). Le TTS, c'est ElevenLabs Flash à 75 ms pour le premier byte audio, ou Deepgram Aura-2 à 100 ms. Un LLM rapide comme Claude Haiku 4.5 ou GPT-4o mini sort son premier token autour de 400-500 ms.
Si vous additionnez tout ça naïvement — j'attends que le STT finisse, puis j'attends que le LLM finisse, puis j'attends que le TTS finisse — vous arrivez mécaniquement à 1,2 seconde minimum. Et c'est sans compter la détection de fin de tour, qui est typiquement le long pole de la latence (200 à 500 ms).
C'est exactement pour ça que tout le monde galère à descendre sous une seconde sans repenser le flow.
L'architecture stream-everything
Voilà l'architecture qu'on déploie. Elle a un nom interne ("stream-everything") et un principe : personne n'attend personne.
PSTN/SIP Orchestrator Output
────── ───────────── ──────
Caller ──audio chunks──► ┌──────────────────┐ ──partial txt──► ┌─────┐
│ Twilio Media │ │ STT │
│ Streams (WS) │ ◄──audio── │ │
└──────────────────┘ └─────┘
│ │
│ audio chunks 20ms │ partial transcript stream
│ │
▼ ▼
┌──────────────────┐ ──streamed tokens─► ┌─────┐
│ Agent Loop │ │ LLM │
│ (state machine) │ ◄──tool calls── │ │
└──────────────────┘ └─────┘
│ │
│ token-by-token │ streaming response
▼ │
┌──────────────────┐ ──audio chunks─────────┘
│ TTS Streaming │ (ElevenLabs / Aura)
│ + jitter buffer │
└──────────────────┘
│
▼
Caller
Quatre principes derrière ça.
Premier principe : le STT ne s'arrête jamais
L'agent ne doit jamais attendre la fin de la transcription. Les bons providers — Deepgram, AssemblyAI — exposent un flag is_final qui marque les segments stables. Dès qu'un segment est stable, vous l'envoyez à votre agent loop. Quand speech_final arrive (fin de tour détectée), vous committez le turn et vous déclenchez le LLM.
const dg = deepgram.listen.live({
model: "nova-3-flux",
endpointing: 300,
interim_results: true,
});
dg.on("Results", (data) => {
const transcript = data.channel.alternatives[0];
if (transcript.is_final) {
agentLoop.appendStableInput(transcript.transcript);
if (data.speech_final) {
agentLoop.commitTurn();
}
}
});
C'est trois lignes de logique mais ça change tout. On voit régulièrement des équipes attendre la "transcription finale" complète avant de commencer le LLM, et perdre 500 ms inutilement à chaque tour.
Deuxième principe : le TTS commence au premier token
Quand votre LLM produit son premier token, vous l'envoyez direct au TTS. ElevenLabs streaming et Deepgram Aura supportent l'audio chunks au token-level. La personne au téléphone entend la première syllabe de la réponse alors que le LLM est encore en train de générer la fin de la phrase. C'est un peu magique la première fois qu'on le voit fonctionner.
Troisième principe : la détection de fin de tour, calibrée au métier
Le long pole, presque toujours, c'est le délai avant que votre système décide que la personne a fini de parler. Les défauts sont tunés très conservateurs — 700 à 900 ms de silence — pour éviter les faux positifs. Trop conservateurs pour une vraie conversation.
En cadrant l'usage métier, on peut descendre à 250-400 ms sans dégrader l'expérience. Si vous montez un standard de qualification de leads, les utilisateurs répondent par phrases courtes — 300 ms suffisent. Pour un assistant de prise de RDV où la personne réfléchit entre les créneaux, 400 ms. Pour un support tier-2 technique où l'utilisateur structure une question complexe, 600 ms.
Le secret, c'est de ne pas prendre la valeur par défaut et de la tuner par cas d'usage.
Quatrième principe : la colocation, ça compte vraiment
Chaque hop réseau de 50 ms compte triple, parce qu'il s'applique sur le chemin audio caller → orchestrator → LLM → TTS → audio caller. Si vous mettez votre orchestrator en Europe et votre TTS aux US, vous payez deux fois la latence transatlantique.
Le fix : déployer le TTS dans la même région cloud que votre orchestrator, et utiliser les edge locations Twilio pour minimiser la distance PSTN ↔ orchestrator. Sur nos déploiements Europe, c'est 150 à 300 ms gagnés rien que sur la topologie. C'est gratuit, mais il faut y penser.
Ce qu'on a mesuré en pilote
Sur un assistant vocal de qualification entrante qu'on a déployé en mars pour un client, voilà ce qu'on a obtenu après deux semaines de tuning :
La latence end-to-end médiane est passée de 1 920 ms à 620 ms. La p95 — celle qui fait raccrocher les gens — est descendue de 2 850 ms à 890 ms. Le taux de chevauchement (caller qui parle sur l'agent) a chuté de 18 % à 4 %. Le taux d'abandon dans les 30 premières secondes est passé de 23 % à 9 %. Le CSAT post-appel est monté de 6,2 à 8,4 sur 10.
L'amélioration vient à 80 % du streaming et à 20 % de la colocation. Le tuning du turn-detection a fait le reste.
La stack qu'on recommande, mi-2026
Pour le media gateway, Twilio Media Streams reste le standard. Vonage et Plivo sont des alternatives, mais Twilio a l'écosystème le plus mature. La nouveauté de l'année, c'est ConversationRelay : ça simplifie énormément le flow et la latence média native est sous 500 ms.
Pour le STT, Deepgram Nova-3 Flux par défaut. AssemblyAI Universal-Streaming si vous cherchez la latence de premier mot absolue (90 ms). Whisper-large-v3 self-hosted si vous avez des contraintes RGPD strictes — vous perdez en latence (~200 ms de plus), vous gagnez en souveraineté.
Pour le LLM, on est sur Claude Haiku 4.5 ou GPT-4o mini. Le compromis latence/qualité/steerability est optimal. On garde du Llama 3.3-70B self-hosted dans la boîte à outils pour les cas où le client veut tout sur ses serveurs.
Pour le TTS, ElevenLabs Flash v2.5 par défaut. Sub-100 ms first-byte, voix multilingues qui passent crème en français et arabe. Deepgram Aura-2 si vous voulez tout chez le même provider que le STT. Mimic 3 self-hosted si RGPD strict (mais préparez-vous à un upgrade qualité moyen).
Pour l'orchestrator, Node.js + WebSocket fait largement le job. L'écosystème Twilio est le plus mature en Node. Python + FastAPI marche aussi, Go + gRPC si vous voulez de la perf brute.
Combien ça coûte
C'est la question qu'on nous pose toujours. Pour donner un ordre de grandeur, sur une minute de conversation (50 % parole utilisateur, 50 % agent) :
Une stack premium type Deepgram + ElevenLabs + Claude Haiku, vous êtes autour de 5,5 cents par minute. Une stack standard avec Whisper + OpenAI TTS + GPT-4o mini, vous tombez à environ 3 cents. Une stack souveraine UE full self-hosted, vous descendez à moins d'un cent par minute hors amortissement du VPS.
Les chiffres sont des ordres de grandeur (Softcery a un calculateur sympa), mais l'écart d'un facteur 5 entre les stacks est réel.
Quatre erreurs qu'on a vues en production
Je termine avec quelques pièges qui nous ont coûté du temps, pour que vous les évitiez.
Activer la "barge-in" sans VAD adaptée. La barge-in permet au caller d'interrompre l'agent en parlant. Cool sur le papier, catastrophique en pratique si votre détection de voix est sensible au bruit de fond. L'agent s'arrête à chaque toux, à chaque bruit de clavier, et la conversation devient erratique. Désactivez la barge-in par défaut, activez-la uniquement après avoir validé votre VAD sur du vrai signal sale.
Cacher les tools/list côté LLM sans cache-busting quand votre stack métier évolue. L'agent appelle des outils qui n'existent plus → fallback verbal très embarrassant ("euh, attendez, je vais essayer une autre approche…"). Ajoutez un ETag, c'est gratuit.
Choisir une voix TTS trop premium pour des cas d'usage transactionnels rapides. Personne ne veut entendre une voix d'audiobook quand il appelle pour confirmer un RDV de dentiste. Adaptez la voix à la situation. Pour le transactionnel court, une voix neutre et rapide. Pour l'émotionnel ou la conciergerie, là vous pouvez monter en gamme.
Oublier les patterns "ack vocal" ("d'accord, je note", "un instant…") quand le LLM met plus de 800 ms à répondre — typiquement sur les tours qui déclenchent un tool call. Sans ack, l'utilisateur croit la ligne morte. C'est trois lignes de code, ça change tout.
Pour aller plus loin
- Twilio — Core Latency in AI Voice Agents
- Deepgram — Best Voice AI Agents 2026 Buyer's Guide
- Future AGI — Best STT APIs in 2026
- Softcery — AI Voice Agent Cost Calculator 2026
On déploie des assistants vocaux en production pour des services clients et des standards de qualification, avec des SLA de latence sub-1 seconde. Si vous évaluez la voice AI pour votre équipe, discutons du cadrage technique — premier échange offert.