Stack callbot 2026 : LLM, STT, TTS, Speech-to-Speech

Le callbot est un système (et le modèle n’est qu’une pièce)

Le fantasme classique : “on choisit le modèle, et le callbot est fait”.

La réalité : un callbot est une chaîne de service, avec des bouts qui cassent, des bouts qui ralentissent, et des bouts qui ont besoin d’être surveillés.

Vous pouvez avoir la meilleure voix du monde — si votre callbot ne sait pas :

• transférer proprement,
• gérer le barge-in,
• confirmer une information sensible,
• et survivre à un timeout API,

…il ne “marche” pas. Il fait une performance.

Si vous voulez cadrer la partie production (KPI, exploitation, “POC vs scale”), commencez par : Callbot en production. Pour la partie temps réel (latence, endpointing), lisez : Latence, barge-in, VAD. Et si la téléphonie vous fait encore lever un sourcil, vous avez : SIP/RTP/WebRTC.

Maintenant, parlons modèles.

LLM 2026 : choisir pour l’action (et pour l’ops), pas pour la poésie

Un callbot n’est pas un roman.

Un callbot est un outil qui doit :

• comprendre une demande,
• poser 1–3 questions utiles,
• déclencher une action,
• conclure,
• et, quand c’est nécessaire, passer la main.

Ce qui compte vraiment côté LLM :

• latence (et régularité),
• tool calling fiable (si vous appelez des APIs),
• robustesse sur votre langue (et vos accents écrits),
• garde-fous et contrôlabilité,
• coût à grande échelle,
• gouvernance (versions, logs, conformité).

OpenAI (GPT-5.2, Realtime, Transcribe, TTS…)

La documentation OpenAI liste explicitement des familles de modèles, dont des variantes récentes comme GPT-5.2 (texte) et des familles Realtime, Audio, Transcribe, TTS.¹

En callbot, ça vous donne deux chemins :

1. pipeline STT→LLM→TTS (familles Transcribe + GPT + TTS),
2. S2S via Realtime (famille Realtime).²

Anthropic (Claude Opus/Sonnet 4.x)

Anthropic publie une liste de modèles avec identifiants versionnés et datés, typiquement pour des variantes “Opus/Sonnet”.³

Pour un callbot, l’intérêt d’Anthropic est souvent dans :

• la qualité rédactionnelle (utile pour des confirmations claires, un ton stable),
• une bonne discipline “système” (prompts + policies),
• et, selon votre use case, une intégration tool use solide.

Google (Gemini 2.5 et la famille Gemini)

Google documente les modèles Gemini disponibles via son API.⁴

L’intérêt côté callbot : un écosystème large (GCP), et des options orientées latence selon les modèles.

Open-weight / open source : Llama 4, Mistral…

Pour les organisations qui veulent plus de contrôle (déploiement, coûts, souveraineté, isolation), les modèles open-weight sont un pilier.

Meta publie une model card pour Llama 4 avec des informations techniques (dont contexte, usages, etc.).⁵

Mistral publie aussi une liste officielle de modèles et une vue d’ensemble de ses offres.⁶

STT 2026 : streaming, précision, et surtout “fin de tour”

Le STT (speech-to-text) est le capteur principal de votre callbot.

Quand il se trompe, l’IA “raisonne” sur une entrée fausse. Et un raisonnement parfait sur une entrée fausse, c’est juste une erreur très confiante.

OpenAI Transcribe

OpenAI liste des modèles de transcription (famille Transcribe) comme gpt-4o-transcribe et gpt-4o-mini-transcribe.¹

Deepgram Nova-3

Deepgram documente Nova-3 et des capacités pertinentes pour le temps réel, dont des réglages d’endpointing / end-of-turn.⁷

ElevenLabs (Scribe)

ElevenLabs documente des modèles de speech recognition (famille “Scribe”, dont Scribe v2 et variantes realtime), avec des fonctionnalités comme diarization et timestamps, et des indications de latence pour les variantes realtime.⁸

Mistral (Voxtral Mini Transcribe / Voxtral Realtime)

Mistral documente ses capacités “Audio & Transcription”, avec deux modèles principaux :

• Voxtral Mini Transcribe (batch, long audio, diarization, timestamps, context biasing),
• Voxtral Realtime (streaming, latence configurable, orienté voice agents).

La documentation mentionne aussi des open weights disponibles sous licence Apache 2.0 (via Hugging Face) pour le déploiement self-hosted/edge, ce qui en fait une option intéressante côté STT open-weight en 2026.¹⁹

AWS Transcribe / Azure Speech / Google STT (cloud)

AWS documente la transcription streaming en temps réel pour Amazon Transcribe (utile pour des callbots à gros volumes).⁹

Microsoft documente des fonctionnalités comme Custom Speech (personnalisation du speech-to-text) selon vos besoins de vocabulaire et de domaine.¹⁰

Google documente aussi des options de modèles speech-to-text (dont des modèles spécifiques par usage) dans ses guides (selon votre stack GCP).¹¹

Open source : Whisper, Vosk (et le “self-hosted” assumé)

OpenAI a publié Whisper en open source (repository officiel).¹²

Vosk (open source) est aussi utilisé pour des scénarios STT offline/on-prem (repo officiel).¹³

Le trade-off est clair :

• • contrôle (données, infra, coûts),
• • intégration fine,
• • complexité d’exploitation (GPU, scaling, mises à jour),
• • parfois des performances variables selon langues/bruit.

TTS 2026 : la voix n’est pas le but, mais c’est l’interface

La TTS (text-to-speech) est la surface visible.

Et c’est là que les équipes se font piéger : elles passent 4 semaines à choisir “la plus belle voix”… puis découvrent que :

• elle ne s’interrompt pas bien (barge-in),
• elle “lit” les chiffres comme un robot,
• elle allonge les phrases,
• elle ajoute de la latence.

OpenAI TTS (familles gpt-4o-mini-tts, tts-1, etc.)

OpenAI liste des modèles TTS (dont gpt-4o-mini-tts, tts-1, tts-1-hd).¹

ElevenLabs (Eleven v3, Flash/Turbo v2.5, Multilingual v2…)

ElevenLabs publie une page “Models” décrivant des modèles TTS comme Eleven v3 et des variantes orientées latence (Flash/Turbo v2.5), ainsi que des modèles STT (“Scribe”).⁸

Google Gemini TTS

Google Cloud documente “Gemini-TTS” et l’utilisation de modèles de synthèse de la famille Gemini (ex. Gemini 2.5 Pro TTS).¹⁴

Google publie aussi des mises à jour sur Gemini 2.5 TTS (Flash/Pro TTS preview), ce qui est utile pour suivre l’évolution des capacités et limites.¹⁵

AWS Polly / Azure Neural TTS

AWS documente Amazon Polly et ses usages (TTS cloud).¹⁶

Open source : Piper, Coqui TTS

Piper (repo officiel) est une option open source populaire pour faire de la TTS localement (souvent pour des contraintes d’embarqué / edge / on-prem).¹⁷

Coqui TTS (repo officiel) est une boîte à outils open source pour la synthèse vocale et des modèles associés.¹⁸

Speech-to-Speech (S2S) : la promesse, la réalité, les garde-fous

Le S2S est séduisant : audio in → audio out, avec un modèle “temps réel” qui gère la boucle.

Ce que ça apporte souvent :

• une latence perçue plus faible,
• des tours de parole plus naturels,
• une intégration plus directe côté “voice agent”.

Ce que ça peut coûter :

• moins de contrôle sur un texte intermédiaire (audit),
• des garde-fous plus délicats,
• une dépendance plus forte à la qualité du modèle temps réel.

OpenAI décrit sa Realtime API (WebRTC/WebSocket, et des connecteurs SIP dans certains contextes) comme une manière de gérer des échanges “low-latency” audio en streaming.²

Open source vs commercial : comment décider sans religion

Voici une grille simple (et étonnamment efficace) pour éviter les débats d’ego.

Quand le commercial/cloud est souvent un bon choix

• Vous devez livrer vite.
• Vous avez besoin de SLA fournisseur.
• Vous voulez tester plusieurs modèles rapidement.
• Vous n’avez pas une équipe infra GPU / MLOps.

Quand le self-host/open source/open-weight devient intéressant

• Vous avez des contraintes de données (on-prem, isolation).
• Vos volumes rendent les coûts cloud sensibles.
• Vous voulez un contrôle fin sur la latence et l’optimisation.
• Vous avez une équipe capable d’exploiter (GPU, scaling, monitoring).

Comment choisir sans se faire piéger : shortlist, benchmark, puis architecture

Si vous voulez un callbot qui tient, je vous propose une méthode très simple (donc très contre-intuitive) :

1. vous ne choisissez pas “un modèle”,
2. vous choisissez un protocole de décision.

Parce que le marché change. Les noms changent. Les versions changent. Et votre callbot, lui, doit rester stable.

Étape 1 : écrivez vos contraintes comme des budgets

Un callbot se pilote avec 3 budgets :

• budget latence : combien de temps l’utilisateur accepte-t-il entre sa fin de phrase et votre réponse ?
• budget coût : combien vous coûte une minute d’appel (télécom + STT + LLM + TTS) à votre volume ?
• budget conformité : quelles données peuvent sortir, combien de temps, sous quelles conditions ?

Ces budgets ne sont pas des opinions. Ce sont des garde-fous.

Ils vous évitent de “gagner” une voix plus naturelle… en perdant votre SLA.

Étape 2 : construisez un banc d’essai audio (pas un benchmark texte)

Le piège classique, c’est de comparer des LLM sur des prompts.

Pour un callbot, le vrai terrain est l’audio :

• 8 kHz téléphonie,
• bruits,
• chevauchement,
• diction imparfaite,
• et surtout “fin de tour” ambiguë.

Votre banc d’essai minimal :

• 30–50 appels (anonymisés),
• 6 intentions majeures (les plus fréquentes),
• 10 cas “bizarres” (accents, noms propres, appels interrompus),
• 5 scénarios de transfert,
• et 5 scénarios d’échec (API down, client non trouvé, authentification impossible).

Oui, c’est du travail. Mais c’est le travail qui évite les surprises en prod.

Étape 3 : scorecard (KPI > vibes)

Ne notez pas “ça sonne bien”.

Notez :

• taux de résolution (FCR / résolution sans rappel),
• durée moyenne (AHT),
• taux d’escalade (et qualité de l’escalade),
• latence p95 tour complet,
• taux de répétition (“allo ?”, “je répète ?”),
• erreurs STT critiques (numéros, dates, montants),
• erreurs d’action (mauvais ticket, mauvais créneau).

Vous pouvez même faire une formule (exemple volontairement simplifié) :

score = 0.4 * resolution + 0.2 * (1 - escalation) + 0.2 * (1 - latency_p95) + 0.2 * (1 - cost)

Le but n’est pas d’avoir “la bonne formule”. Le but est d’avoir une manière de trancher.

Étape 4 : architecture qui permet de changer (sinon vous êtes mariés)

Le callbot devient dangereux quand vous ne pouvez plus changer de brique.

La règle d’or :

• découplez STT, orchestration, LLM, TTS,
• loggez des événements,
• et gardez un format d’échange stable.

Ça vous permettra :

• de changer de STT sans toucher au dialogue,
• d’ajouter une couche de règles sans réécrire,
• et de migrer vers du S2S sur certains flux sans tout casser.

Étape 5 : plan B (parce qu’il y a toujours un plan B)

À l’échelle, une panne arrive. La question est : comment vous tombez.

Préparez :

• un fallback de modèle (même famille ou autre fournisseur),
• un fallback de canal (SMS de confirmation, rappel),
• un transfert automatique en cas de doute,
• et un mode “dégradé” (collecte + ticket) quand la résolution est indisponible.

Et surtout : testez ces modes. Les plans B non testés sont des plans imaginaires.

FAQ