Speech-to-Speech IA : les modèles voix-à-voix vont-ils remplacer le pipeline STT/LLM/TTS dans les agents vocaux ?

Et si votre agent vocal n'avait plus besoin de transcrire ce que dit votre client pour lui répondre ?

Depuis l'émergence des callbots et voicebots, l'architecture dominante repose sur un pipeline en trois étapes : transcription de la voix en texte (STT — Speech-to-Text), raisonnement du modèle de langage (LLM), puis synthèse vocale de la réponse (TTS — Text-to-Speech). Ce pipeline est aujourd'hui mature, maîtrisé, et industrialisé. Mais il accumule une dette que chaque couche alourdit : la latence.

En 2024, OpenAI a lancé l'API Realtime pour GPT-4o, permettant un traitement audio natif en entrée et en sortie. Google a suivi avec Gemini Live. Kyutai a publié Moshi, premier modèle open-source de parole-à-parole. Une nouvelle famille de modèles est née : les modèles Speech-to-Speech (S2S), ou voix-à-voix. Ils traitent l'audio directement, sans passer par le texte.

La promesse : des conversations vocales avec une latence quasi naturelle, une meilleure compréhension des émotions et de la prosodie, et une expérience utilisateur fondamentalement plus fluide. La réalité, en 2026 : c'est plus nuancé. Ce guide compare les deux architectures sur les dimensions qui comptent pour les équipes qui déploient des agents vocaux professionnels : latence, intégration métier, observabilité, coût et conformité.

Le pipeline STT/LLM/TTS : l'architecture de référence

Le pipeline STT/LLM/TTS a permis de déployer des millions d'agents vocaux en production. Sa modularité est sa force — et sa latence cumulée, sa principale contrainte.

Comment fonctionne le pipeline classique

Un agent vocal basé sur un pipeline STT/LLM/TTS fonctionne en trois étapes séquentielles et indépendantes :

1. STT (Speech-to-Text) : le flux audio de l'appelant est transcrit en texte. Solutions courantes : Whisper (OpenAI), Deepgram, AssemblyAI, Google Speech-to-Text, Azure Cognitive Services.
2. LLM (Large Language Model) : le texte transcrit est envoyé au modèle de langage avec un prompt système, un historique de conversation et un contexte métier (RAG, CRM). Le modèle génère une réponse textuelle.
3. TTS (Text-to-Speech) : la réponse textuelle est synthétisée en audio et diffusée à l'appelant. Solutions courantes : ElevenLabs, Azure TTS, Google TTS, Amazon Polly, Cartesia.

Chaque étape est un microservice indépendant. C'est la force du pipeline : chaque composant peut être remplacé, optimisé, monitoré et mis à l'échelle séparément.

Latence cumulée : le principal talon d'Achille

La latence d'un pipeline STT/LLM/TTS est la somme des latences de chaque couche. Voici les ordres de grandeur typiques en production :

Un pipeline optimisé — avec du streaming STT, un LLM rapide et un TTS en streaming — peut descendre sous 500 ms, ce qui reste dans les limites perceptibles par un humain dans une conversation naturelle (seuil psychologique : 300–500 ms).

Les atouts du pipeline classique

Le pipeline STT/LLM/TTS reste dominant pour de bonnes raisons. La modularité permet de choisir le meilleur composant pour chaque étape selon le cas d'usage et la langue. L'observabilité est totale : chaque étape expose des logs structurés, des métriques de latence et des traces — la transcription STT est lisible par un humain, le raisonnement LLM est auditable. L'intégration métier est naturelle : les function calls LLM permettent d'appeler des APIs CRM, des bases de données ou des workflows n8n directement depuis la couche texte. Enfin, la conformité RGPD est maîtrisée : les données textuelles intermédiaires peuvent être pseudonymisées, filtrées ou supprimées selon les exigences légales.

Les modèles Speech-to-Speech : l'architecture de rupture

Un modèle Speech-to-Speech ne "traduit" pas la voix en texte pour y répondre. Il perçoit la voix comme un humain — avec ses intonations, ses silences, ses émotions — et répond directement en voix.

Principe de fonctionnement

Un modèle Speech-to-Speech (S2S) est un modèle multimodal entraîné nativement sur des paires audio-audio. Il reçoit le flux audio de l'appelant en entrée et génère un flux audio de réponse en sortie, sans jamais produire de représentation textuelle intermédiaire dans son inférence principale. Le traitement est continu, en streaming, et peut démarrer la génération de la réponse avant même que l'interlocuteur ait fini de parler.

Les modèles disponibles en 2026

Les avantages distinctifs du S2S

Le principal avantage est la latence structurellement plus faible : en supprimant les allers-retours entre les trois couches, la latence perçue peut descendre à 200–400 ms — dans la zone de conversation naturelle. Deuxième avantage : la préservation des nuances prosodiques. La transcription STT ne retranscrit pas l'hésitation, le ton interrogatif, la frustration ou l'ironie — un modèle S2S les perçoit directement dans le signal audio et peut adapter sa réponse en conséquence. Troisième avantage : la gestion des interruptions et du backchannel. Un modèle S2S peut détecter quand l'interlocuteur commence à parler pendant la réponse et s'arrêter naturellement, comme un humain — ce que les pipelines asynchrones gèrent avec difficulté.

Comparatif STT/LLM/TTS vs Speech-to-Speech : ce qui compte vraiment

Les défis réels des modèles Speech-to-Speech en production

L'observabilité : le problème de la boîte noire audio

Dans un pipeline STT/LLM/TTS, chaque interaction produit une trace textuelle exploitable : la transcription de ce qu'a dit le client, le raisonnement du LLM, la réponse générée. On peut relire, auditer, évaluer et détecter les hallucinations. Dans un modèle S2S pur, il n'y a pas de texte intermédiaire — seulement un flux audio entrant et un flux audio sortant. Pour détecter qu'un agent S2S a inventé une information incorrecte, il faut soit réécouter l'appel, soit faire tourner un modèle STT en parallèle pour reconstituer la transcription a posteriori — ce qui annule une partie du gain de latence et complexifie l'architecture.

L'intégration CRM : la nécessité d'hybridation

Un agent vocal professionnel a besoin d'accéder à des données CRM, de mettre à jour un dossier client, de vérifier une commande ou de déclencher un workflow métier. Dans le pipeline classique, ce mécanisme repose sur les function calls du LLM, qui expose une sortie JSON structurée que l'infrastructure intercepte pour appeler les APIs. Dans un modèle S2S natif, la logique d'action est embarquée dans le modèle — l'infrastructure ne peut pas "voir" le texte pour détecter quand appeler une API. La solution actuelle (OpenAI GPT-4o Realtime l'implémente) : des function calls audio, où le modèle signale explicitement dans son flux de sortie qu'il attend le résultat d'un outil. Cela fonctionne, mais est plus fragile et moins portable qu'un pipeline texte standard.

Le coût : la facture de la multimodalité

Les modèles multimodaux audio sont significativement plus coûteux à l'inférence que leurs équivalents textuels. L'API Realtime de GPT-4o facture l'audio en tokens audio (100 tokens audio = environ 1 seconde de parole), à un tarif 6 à 10 fois supérieur aux tokens texte équivalents. Pour un déploiement à grande échelle — un centre de contact traitant 10 000 appels de 3 minutes par jour — le coût d'inférence d'un modèle S2S cloud peut représenter 3 à 5 fois le coût d'un pipeline STT/LLM/TTS optimisé. L'équation économique reste un frein majeur à l'adoption à grande échelle en 2026.

La conformité RGPD et la biométrie vocale

Les données audio vocales sont des données biométriques au sens du RGPD (article 9) lorsqu'elles permettent l'identification d'une personne physique. Leur traitement via une API S2S cloud implique un transfert de données biométriques hors UE si le prestataire est américain — ce qui exige des Clauses Contractuelles Types (CCT) et une Analyse d'Impact relative à la Protection des Données (AIPD) spécifique. Le pipeline STT/LLM/TTS, en pseudonymisant les données au niveau de la transcription texte avant de les envoyer au LLM, permet une architecture plus facilement conforme.

L'architecture hybride : la trajectoire la plus probable

La vraie question n'est pas "S2S ou pipeline ?" mais "quelle couche de mon agent doit être S2S ?"

En 2026, la trajectoire la plus pragmatique est l'architecture hybride : exploiter les capacités S2S pour les dimensions où elles apportent une valeur ajoutée mesurable, en conservant le pipeline texte pour les fonctions critiques.

Cas d'usage favorables au S2S natif

Certains cas d'usage bénéficient directement des capacités S2S : la détection d'émotions en temps réel (frustration, urgence, détresse) pour prioriser l'escalade vers un agent humain ; la prosodie adaptative pour des expériences de marque premium où le ton de la réponse doit refléter celui de l'interlocuteur ; les conversations ultra-courtes à faible besoin d'intégration métier (confirmation d'horaire, rappel d'information simple) ; et les interactions bilingues où la langue alterne dans un même tour de parole, ce que le pipeline STT gère mal.

Architecture recommandée : S2S pour la perception, pipeline pour l'action

L'approche recommandée pour les agents vocaux professionnels en 2026 est la suivante. Un modèle S2S léger est utilisé en première couche pour analyser le signal audio : détecter les émotions, la prosodie, les interruptions, et produire une transcription enrichie avec des métadonnées prosodiques. Cette transcription enrichie est transmise à un LLM texte classique (Sonnet, GPT-4o, Llama) qui raisonne, appelle les APIs métier et produit une réponse textuelle. Un TTS haute qualité avec clonage vocal génère la réponse audio finale. Ce modèle hybride conserve toute l'observabilité et l'intégrabilité du pipeline texte tout en gagnant les nuances du traitement audio natif en entrée.

Perspectives 2027 : vers la convergence ?

Plusieurs signaux indiquent que la frontière entre pipeline et S2S va s'estomper. Premièrement, les grands labs (OpenAI, Google, Meta) investissent massivement dans les architectures multimodales audio-texte natives — les prochaines versions de leurs modèles devraient améliorer significativement la gestion des function calls audio et réduire les coûts. Deuxièmement, des frameworks d'orchestration comme LiveKit Agents, Pipecat et Vapi ont commencé à standardiser des patterns hybrides qui exposent une interface unifiée quelle que soit l'architecture sous-jacente. Troisièmement, la démocratisation des modèles S2S open-source (suite à Moshi) permettra leur déploiement on-premise, résolvant en partie les contraintes RGPD.

La convergence la plus probable à horizon 2027 : des modèles multimodaux capables de traiter l'audio nativement tout en exposant une couche texte structurée pour l'intégration métier et l'observabilité — le meilleur des deux architectures dans un seul modèle.