Voice agents : endpointing, barge-in et S2S en prod

Le callbot “wahou” et le callbot “utile”

Le monde de la voix a une malédiction : la démo ment très bien.

Une démo de 3 minutes favorise :

• la plus jolie voix,
• les réponses les plus longues,
• le ton le plus “humain”.

La prod, elle, favorise :

• le temps de résolution (aller au point),
• la capacité à gérer le bruit et l’imprévu,
• la stabilité sur des millions d’appels,
• la conformité (enregistrements, consentement, escalade),
• et la maîtrise des coûts.

Un bon voice agent n’est donc pas “le plus théâtral”. C’est celui qui :

1. comprend vite,
2. répond court,
3. propose une action claire,
4. escalade quand il faut,
5. et laisse une trace.

Le pipeline voix : STT → orchestration → TTS (et l’endroit où tout casse)

Le voice agent, ce n’est pas un modèle. C’est une chaîne.

Le pipeline “classique” (le plus gouvernable)

1. Capture audio (téléphonie, WebRTC, app mobile)
2. STT (speech-to-text)
3. Orchestration (LLM + outils + règles)
4. TTS (text-to-speech)
5. Lecture dans le canal (téléphone, app)

Ce pipeline est “moins magique”, mais très robuste parce que :

• vous avez du texte (audit),
• vous pouvez filtrer/rediger,
• vous pouvez tracer chaque étape,
• vous pouvez rejouer.

Google Cloud documente des appels de Speech-to-Text en streaming pour la reconnaissance temps réel.¹

Et côté open source, Whisper est une référence de STT open source (self-host possible).²

Le pipeline S2S (speech-to-speech) : quand la latence et la fluidité priment

Les API realtime modernes permettent des interactions audio en faible latence, parfois nativement speech-to-speech.

OpenAI documente la Realtime API comme une API bas-latence permettant des interactions speech-to-speech et multimodales (audio/text/image), via WebSocket/WebRTC.³⁴

Et OpenAI documente un guide “Voice agents” qui compare justement deux approches :

• speech-to-speech (natif via Realtime API),
• ou “chained” (audio→texte→audio).⁵

Le S2S peut donner une sensation plus “conversationnelle”… mais il vous impose de prendre au sérieux :

• l’observabilité (qu’est-ce que le modèle a entendu ?),
• la conformité (logs, consentement),
• et la sécurité (actions outillées).

Endpointing : décider quand l’utilisateur a fini de parler (c’est un produit, pas un paramètre)

Dans un chat texte, “fin du tour” est obvious : l’utilisateur appuie sur Entrée.

Au téléphone, l’utilisateur :

• respire,
• hésite,
• se reprend,
• parle avec un collègue en arrière-plan,
• ou lit un numéro à haute voix en chunks.

Endpointing = déterminer le moment où vous considérez que l’énoncé est terminé.

Deepgram documente un événement UtteranceEnd et un paramètre utterance_end_ms, qui correspond à la durée de silence (en millisecondes) entre des mots transcrits avant de déclencher l’événement.⁶

Cette doc montre bien le problème : si vous êtes trop agressif, vous coupez la pensée ; si vous êtes trop conservateur, vous ajoutez de la latence.⁶

Les 3 stratégies d’endpointing (et leurs trade-offs)

1. Silence-based
   On déclenche après X ms de silence. Simple, mais fragile sur le bruit.

2. ASR-driven
   On déclenche quand le moteur STT estime que la phrase est “finale” (speech_final, end-of-utterance).
   Souvent plus robuste, mais dépend de l’ASR.

3. Hybrid
   Silence-based + signaux ASR + règles métier (ex. “si l’utilisateur dicte une date, attendre plus longtemps”).

Le piège classique : optimiser la latence… et perdre la compréhension

Beaucoup d’équipes “optimisent” l’endpointing comme on optimise un benchmark :

• réduire le temps de silence,
• couper plus vite,
• et gagner 300 ms.

Résultat : plus d’interruptions, plus de malentendus, plus de transferts.

La bonne métrique n’est pas “latence minimale”.
C’est “latence minimale à compréhension égale”.

En pratique :

• vous testez sur des appels réels,
• vous segmentez par persona (âgé, bruit, accent),
• et vous gardez un budget d’erreur acceptable.

Barge-in : l’art d’être interrompu (sans perdre l’état)

Barge-in = l’utilisateur coupe l’agent pendant que l’agent parle.

Sur un voice agent “démo”, le barge-in est souvent absent (c’est plus simple).
Sur un voice agent “prod”, le barge-in est obligatoire.

Parce que les humains interrompent. Et au téléphone, ils interrompent beaucoup.

Le barge-in implique :

• détecter la parole utilisateur pendant la synthèse,
• interrompre la lecture (stop TTS),
• annuler (ou mettre en pause) la génération,
• conserver l’état (ce qu’on a déjà dit, ce qu’on allait faire),
• reprendre proprement.

OpenAI documente la Realtime API comme une API d’événements (session state) où audio et events de contrôle sont ordonnés dans un même canal (WebSocket), ce qui est utile pour raisonner sur l’état d’une conversation temps réel.⁴

Ce détail technique est un détail produit : si vos events ne sont pas cohérents, votre agent devient incohérent.

Téléphonie : Twilio Media Streams, WebSocket, et la réalité d’un appel

Beaucoup d’agents voix naissent en WebRTC (app → micro → agent).

Puis la réalité arrive : le téléphone.

Twilio documente Media Streams comme un mécanisme pour streamer l’audio d’un appel vers votre serveur via WebSockets.⁷

Twilio documente aussi les messages WebSocket envoyés pendant un stream (événements, audio), et indique que vous pouvez envoyer des messages en retour pour contrôler le flow et “pipe audio back” vers l’appel (dans les modes bidirectionnels).⁸⁷

Traduction : la téléphonie vous force à penser “temps réel”, pas “requête HTTP”.

Architecture type (téléphone → agent)

1. Appel entrant (SIP/PSTN)
2. Twilio (ou autre opérateur)
3. Media Streams → WebSocket vers votre infra
4. Pipeline audio (STT ou Realtime S2S)
5. Orchestration (LLM + outils)
6. Audio retour → Twilio → appel

Si vous voulez un voice agent “prod”, vous devez assumer que :

• la connexion tombe,
• le réseau varie,
• des paquets se perdent,
• et l’audio peut arriver en chunks.

Ce n’est pas une exception. C’est le mode normal.

SIP / WebRTC / WebSocket : choisir votre rail

Les API realtime modernes exposent plusieurs rails.

Par exemple, Microsoft Learn documente l’accès à la Realtime API via WebSockets (Azure OpenAI), et mentionne aussi des options via WebRTC ou SIP selon les cas.⁹

Et côté OpenAI, la doc du modèle realtime mentionne une capacité à répondre en temps réel sur des connexions WebRTC, WebSocket ou SIP.¹⁰

Vous n’avez pas besoin d’être un puriste. Vous devez être pragmatique :

• WebRTC : super pour le web/app, plus de contrôle client
• SIP : super pour s’intégrer à la téléphonie
• WebSocket : super pour intégrer avec un serveur audio “central”

S2S vs STT+TTS : les vrais critères de choix

On peut résumer la différence en une phrase :

• STT+TTS = texte au centre
• S2S = audio au centre

Et ce centre change tout.

Auditabilité & conformité

STT+TTS :

• vous logguez texte (avec redaction),
• vous citez ce qui a été dit,
• vous rejouez plus facilement.

S2S :

• vous devez décider quoi logguer (audio brut ? transcript ? embeddings ?),
• et comment l’expliquer (audit).

OpenAI explique justement ces deux approches (speech-to-speech vs chained) dans son guide voice agents.⁵

Latence & “feeling”

S2S est souvent plus fluide si :

• le streaming est bien géré,
• l’endpointing est solide,
• et le barge-in est propre.

Mais la latence totale ne dépend pas que du modèle. Elle dépend de :

• STT,
• endpointing,
• orchestration,
• TTS,
• et de votre téléphonie.

Le modèle n’est qu’un maillon.

Outillage (tools) et actions

Un callbot “répond” et c’est sympa.
Un callbot “agit” et c’est rentable.

Mais agir au téléphone implique des outils :

• consulter un contrat,
• modifier un rendez-vous,
• créer un ticket,
• déclencher un rappel,
• envoyer un SMS.

Donc la vraie question est : comment vous sécurisez le tool calling.

Si votre agent peut faire des actions en temps réel, le design des permissions et des validations devient non négociable (voir /blog/agents-ia/outils/mcp-tools-design-permissions).

Open source vs commercial : composer votre stack sans vous mentir

En 2026, vous avez le choix :

Open source (self-host)

STT :

• Whisper (OpenAI, open source).²
• Vosk API (offline speech recognition).¹¹

TTS :

• Piper (local TTS).¹²
• Coqui TTS (toolkit TTS).¹³

Avantages :

• contrôle (données, déploiement),
• coût marginal plus bas à grande échelle,
• possibilité d’on-prem.

Limites :

• qualité variable selon langues/accents,
• tuning et MLOps,
• latence parfois difficile sans infra audio dédiée.

Commercial (API)

STT :

• Google Cloud STT (streaming).¹
• Deepgram (docs STT/TTS, rate limits).¹⁴

TTS :

• ElevenLabs (API streaming).¹⁵
• Deepgram TTS.¹⁴

S2S :

• OpenAI Realtime API (speech-to-speech).³⁵

Avantages :

• time-to-market,
• qualité souvent très solide,
• features realtime prêtes.

Limites :

• dépendance fournisseur,
• gouvernance (logs, rétention),
• coûts à grande échelle.

Observabilité voix : métriques qui comptent (pas celles qui font joli)

En voix, les métriques “sexy” trompent.

Vous voulez des métriques de résolution :

• taux de résolution sans transfert (containment),
• durée moyenne d’appel,
• temps avant première réponse utile,
• taux d’interruptions (barge-in) “mal gérées”,
• taux d’escalade (et qualité de l’escalade),
• erreurs STT (mots clés ratés : noms, numéros, dates),
• erreurs outils (timeouts, 429, etc.).

Et évidemment :

• latence P95/P99,
• coût par appel résolu.

Le tout doit être corrélé à des traces (sinon c’est du “dashboard décoratif”).

Checklist “prod” : ce que vous devez verrouiller avant de scaler

1

Définissez un budget de latence par tour

Exemple : STT + endpointing + orchestration + TTS = budget. Si vous ne le découpez pas, vous optimisez au hasard.

2

Testez endpointing + barge-in sur du bruit réel

Les environnements calmes mentent. Testez open space, voiture, accent, appels “cassés”. Ajustez utterance_end_ms et votre stratégie d’interruption.⁶

3

Rendez les actions idempotentes

Un agent qui retry doit pouvoir retry sans duplicats. Sinon, vous créez deux tickets, deux SMS, deux remboursements.

4

Instrumentez la téléphonie comme un service distribué

Media Streams, WebSockets, sessions realtime : tracez IDs, erreurs, déconnexions, et corrélez avec vos outils.⁷⁸

5

Assumez l’escalade humaine

Un voice agent adulte sait dire “je transfère” proprement, avec un résumé et des champs extraits. L’objectif n’est pas zéro transfert : c’est le bon transfert.

FAQ

Questions frequentes

S2S ou STT+TTS : quel choix par défaut ?+

Si vous avez des exigences fortes d’audit et de conformité, STT+TTS est souvent le choix par défaut. Si votre priorité est la fluidité (et que vous savez gouverner logs/permissions), le S2S via une API realtime peut donner une expérience plus naturelle.⁵

Endpointing : je mets la valeur la plus basse possible ?+

Non. Trop agressif, vous coupez l’utilisateur. Trop conservateur, vous ajoutez de la latence. La doc Deepgram montre bien ce trade-off et l’intérêt de calibrer sur des cas réels.⁶

La plus belle voix = le meilleur callbot ?+

Non. La prod récompense la résolution, la stabilité, et l’escalade propre. La “voix wow” ne compense pas un mauvais tour de parole.

Je peux faire un callbot sans téléphonie dédiée ?+

Pour une app web/mobile, oui (WebRTC). Pour le téléphone (PSTN), vous aurez besoin d’un opérateur (Twilio ou équivalent) et d’un rail temps réel (Media Streams/WebSocket).⁷

Open source pour la voix : c’est viable ?+

Oui, surtout si vous acceptez du tuning et des compromis. Whisper et Vosk sont des options STT open source, Piper/Coqui côté TTS.^2111213

Sources et references

1. [1]Google Cloud, “Speech-to-Text requests” (streaming recognition concept).
2. [2]GitHub, OpenAI, “Whisper” (open source speech recognition).
3. [3]OpenAI API docs, “Realtime API” (low-latency speech-to-speech, WebSocket/WebRTC).
4. [4]OpenAI API docs, “Realtime model capabilities” (event flow, session state, WebRTC/WebSocket channels).
5. [5]OpenAI API docs, “Voice agents” (S2S vs chained STT/LLM/TTS).
6. [6]Deepgram docs, “Utterance End” ( utterance_end_ms , endpointing).
7. [7]Twilio docs, “Media Streams Overview” (stream call audio via WebSockets).
8. [8]Twilio docs, “Media Streams - WebSocket messages” (bi-directional control/audio).
9. [9]Microsoft Learn, “Use the GPT Realtime API via WebSockets” (Azure OpenAI realtime).
10. [10]OpenAI developers, “gpt-realtime model” (WebRTC/WebSocket/SIP).
11. [11]GitHub, Alpha Cephei, “Vosk API” (offline speech recognition).
12. [12]GitHub, rhasspy/piper (Piper TTS).
13. [13]GitHub, coqui-ai/TTS (TTS toolkit).
14. [14]Deepgram docs, “Text-to-Speech” (API docs + rate limits reference).
15. [15]ElevenLabs docs, “Streaming” (TTS streaming API).