Pipeline ou speech-to-speech : deux façons de faire parler une IA au téléphone

Deux façons de faire parler une machine

Pour tenir une conversation, un agent vocal doit comprendre ce qu'on lui dit, décider quoi répondre, et le dire. Il y a deux façons de l'organiser. La première enchaîne trois modèles : une reconnaissance vocale qui transforme la voix en texte, un modèle de langue qui rédige une réponse, une synthèse vocale qui la prononce. On l'appelle pipeline, ou chaîne. La seconde confie tout à un seul modèle qui reçoit du son et produit du son, sans passer par l'écrit : c'est le speech-to-speech. Certains écoutent et parlent en même temps, comme on le fait au téléphone : on les dit full-duplex. Ce choix décide de la vitesse de réponse, de ce qui se passe quand on coupe la parole à l'agent, de ce qu'on peut vérifier, et des langues qu'il parle.

La chaîne : entendre, écrire, réfléchir, parler

Dans une chaîne, chaque étape a son modèle, et l'on peut changer l'un sans toucher aux autres. Selon la documentation d'OpenAI, la chaîne sert quand on veut « inspecter ou transformer le texte intermédiaire et remplacer chaque composant indépendamment ». Kyutai, laboratoire français, a fait le même choix pour Unmute : sa reconnaissance vocale (stt-1b-en_fr, qui comprend l'anglais et le français) et sa voix se branchent sur n'importe quel modèle de langue, et le laboratoire écrit que « la force principale d'Unmute est sa modularité ».

Le prix à payer, c'est le temps, et ce qui se perd en route. Chaque étape attend la précédente : Kyutai explique qu'une fois la fin de parole détectée, son système doit encore attendre 500 millisecondes, le délai de sa reconnaissance vocale, avant d'avoir tout le texte. Et le texte ne garde pas le ton, l'hésitation, le « oui » qui veut dire « non ». Au téléphone, où la reconnaissance vocale se trompe beaucoup plus qu'en studio, une erreur d'écriture devient une erreur de compréhension.

Le modèle unique : de la parole à la parole

Un modèle speech-to-speech reçoit le son et répond en son, sans étape écrite. Moshi, publié par Kyutai en 2024 avec des poids ouverts, est présenté par ses auteurs comme le premier grand modèle de langue parlé full-duplex en temps réel : il suit sa propre parole et celle de son interlocuteur dans deux flux parallèles, avec une latence théorique de 160 millisecondes, 200 en pratique sur une carte graphique L4. OpenAI propose une API « Realtime » qui utilise « un seul modèle pour interpréter l'audio, décider quoi faire et répondre en parole », et décrit aussi une troisième voie : un modèle qui écoute et parle en même temps, et confie le raisonnement et les outils à un système séparé.

Le prix à payer est l'inverse. Kyutai, qui a construit les deux, l'écrit : Moshi « n'égale pas encore » les modèles de texte pour l'appel d'outils, le raisonnement et l'apprentissage à partir d'exemples. Et un modèle unique ne parle que les langues qu'il a apprises, quand une chaîne peut changer de reconnaissance vocale pour chaque langue.

Ce que chacun gagne et perd

Ce que mesurent les bancs d'essai, et ce qu'ils ne mesurent pas

Artificial Analysis classe les modèles speech-to-speech, et des chaînes « par défaut » de plusieurs fournisseurs, sur le raisonnement (Big Bench Audio : 1 000 questions en anglais, lues par des voix de synthèse), sur les pauses, les tours de parole et les interruptions (Full Duplex Bench), et sur des tâches de service client (τ-Voice). Full-Duplex-Bench, publié en mars 2025, propose une façon de mesurer ces comportements ; Luqia en a construit en 2026 des versions françaises, canadienne et européenne, et note qu'optimiser les chiffres d'un banc peut nuire au naturel de la conversation (voir les corpus en français).

Aucune de ces mesures ne sort d'une ligne téléphonique. Les 200 millisecondes de Moshi sont mesurées sur une carte graphique, pas au bout d'un appel, et son codec audio, Mimi, traite du son échantillonné à 24 kHz, trois fois plus que les 8 kHz d'une ligne. Sur de vrais appels, OpenBenchmarks relève, pour cinq plateformes du marché, un délai avant le premier son de 1,3 à 1,7 seconde en médiane. Ces chiffres ne mesurent pas la même chose et ne se comparent pas ; ils rappellent qu'une latence de laboratoire n'est pas une latence d'appel (voir les cinq chiffres qui comptent).

Où se place ASDIC

ASDIC n'est ni une chaîne ni un modèle speech-to-speech : c'est un modèle de compréhension. Il ne rédige pas de réponse et ne parle pas. Il doit écouter l'appel et prendre les décisions qui font tenir une conversation : humain ou répondeur, la personne a-t-elle fini sa phrase, que veut-elle, faut-il passer la main à un conseiller. Ces questions se posent quelle que soit l'architecture qui parle : dans une chaîne, un tel modèle peut décider sur le son sans attendre le texte ; à côté d'un modèle unique, il apporte des décisions séparées, que l'on peut mesurer.

C'est un choix de méthode, pas un résultat. Les agents de Nodical fonctionnent aujourd'hui en chaîne, avec une reconnaissance vocale et une voix fournies par un prestataire américain, et Nodical n'a, à ce jour, aucun modèle de compréhension qui lui soit propre. Sur les appels de septembre 2026, l'agent répond en 0,14 seconde en médiane une fois qu'il a décidé que la personne avait fini, et en 1,32 seconde pour 9 réponses sur 10 ; ce délai exclut la détection de fin de parole, qui est justement ce qu'ASDIC doit apprendre. Notre objectif est écrit comme un objectif : répondre en moins de 0,5 seconde, en coupant la parole moins de 5 % du temps. Il n'est pas atteint ; il sera publié avec la mesure, dans le carnet.

Ce que ça change pendant l'appel

Pour une entreprise, l'architecture compte moins que ce qu'elle permet de faire pendant l'appel : poser un rendez-vous, mettre à jour une fiche, prévenir un commercial. Ces gestes passent par du texte et des logiciels, là où, de l'aveu même de Kyutai, le modèle unique est encore en retrait. Le site de Nodical détaille les enchaînements que Nodical déclenche pendant l'appel.

Et concrètement ? les enchaînements que Nodical déclenche pendant l'appel

Sources

consultées le 1er octobre 2026.

1. Kyutai, « Unmute » (reconnaissance vocale et voix branchées sur n'importe quel modèle de langue ; comparaison avec Moshi) — https://kyutai.org/unmute
2. Kyutai, « Kyutai STT » (délai de 500 ms de stt-1b-en_fr, VAD sémantique, « flush trick » d'Unmute) — https://kyutai.org/stt/
3. Hugging Face, kyutai/stt-1b-en_fr (anglais et français, délai de 0,5 s) — https://huggingface.co/kyutai/stt-1b-en_fr
4. arXiv 2410.00037, Kyutai, « Moshi: a speech-text foundation model for real-time dialogue » (2024) — https://arxiv.org/abs/2410.00037
5. Kyutai, dépôt Moshi (latence de 160 ms théorique, 200 ms sur carte L4 ; codec Mimi à 24 kHz) — https://github.com/kyutai-labs/moshi
6. OpenAI, « Voice agents » (documentation : GPT-Live, Realtime API, chaîne) — https://developers.openai.com/api/docs/guides/voice-agents
7. OpenAI, « Realtime API » (documentation) — https://developers.openai.com/api/docs/guides/realtime
8. Artificial Analysis, classement speech-to-speech (Big Bench Audio, Full Duplex Bench, τ-Voice, « Default Cascaded System ») — https://artificialanalysis.ai/speech-to-speech
9. Artificial Analysis, jeu de données Big Bench Audio (1 000 questions, anglais, voix de synthèse) — https://huggingface.co/datasets/ArtificialAnalysis/big_bench_audio
10. arXiv 2503.04721, « Full-Duplex-Bench: a benchmark to evaluate full-duplex spoken dialogue models on turn-taking capabilities » (mars 2025) — https://arxiv.org/abs/2503.04721
11. arXiv 2609.10765, Luqia, « French Full-Duplex Benchmark » (EMNLP 2026 Industry) — https://arxiv.org/abs/2609.10765
12. OpenBenchmarks, « Voice agent latency benchmark (2026), TTFAB from real phone calls » (dernier appel : 1er août 2026) — https://openbenchmarks.com/voice-agent-latency
13. ASDIC, carnet n° 1 : « Septembre 2026 : première mesure » — https://asdic.ai/carnet/2026-09-premiere-mesure

Corrections

Aucune correction à ce jour.