Pendant qu'ils réfléchissent, c'est presque comme s'ils étaient sourds et aveugles. Ils ne perçoivent plus rien de ce qui se passe autour d'eux. -
Je trouve hallucinant que la plupart des agents vocaux prennent encore leurs décisions à partir d'une transcription.
Chaque appel est converti de l'audio vers le texte avant même que la « couche de réflexion » de l'agent ne le voie. Cette conversion entraîne des pertes. Seuls les mots survivent. L'hésitation, le « euh », l'intonation qui descend en fin de phrase, le bruit de fond, la demi-tête tournée pour parler à quelqu'un d'autre : tout cela disparaît.
L'agent doit donc deviner. Il coupe la parole en plein milieu d'une idée, attend trop longtemps une fois que la personne a fini de parler, et passe à côté de la colère dissimulée derrière une phrase polie.
C'est selon moi la plus grande lacune de l'IA vocale aujourd'hui.
Cet article présente ma vision du statu quo et explore les questions suivantes :
- Un agent peut-il bien décider s'il n'entend jamais l'appel ?
- Pourquoi un réseau de LLM n'a-t-il pas comblé ce fossé ?
- Pourquoi ne pas utiliser des modèles speech-to-speech ?
- À quoi ressemblerait une « couche de réflexion » qui écoute vraiment ?
Où en est le marché aujourd'hui ?
https://x.com/jordan_dearsley/status/2085602471918064064
Pendant des années, on a prédit que la voix deviendrait le moyen universel d'interagir avec les logiciels. En 2026, cette prédiction commence à se concrétiser. L'IA gère des milliards d'appels professionnels chaque année, grâce à des entreprises comme @ElevenLabs et @DeepgramAI, ainsi qu'à plus de 800 produits d'IA vocale.
Mais comme lors de la phase initiale de toute vague technologique, l'adoption a devancé la qualité. Seulement une entreprise sur cinq environ se dit très satisfaite de ses agents en production. La plupart des agents s'en tiennent donc à ce qui est abordable et fiable : les appels sortants qui suivent un script, ou les requêtes entrantes suffisamment simples pour être prévisibles.
Presque tous les agents vocaux fonctionnent en cascade : reconnaissance vocale (STT), puis un LLM, puis synthèse vocale (TTS). Les ingénieurs adorent cette architecture car elle permet de choisir le meilleur modèle pour chaque tâche, de lire chaque étape intermédiaire et de garder un contrôle strict sur ce que l'agent dit et fait.
Même si le STT et le TTS ont énormément progressé en matière de latence et de coût, le point faible reste la couche de réflexion.
Ce qu'une transcription laisse de côté
Le rôle de la couche de réflexion est simple. Savoir dans quel état se trouve la conversation, et choisir l'action qui la fera passer au bon état suivant : parler, agir, transférer ou continuer à écouter.
Votre code sait toujours à quelle étape du workflow se trouve un appel. Ce qu'il ignore, c'est ce qui se passe du côté de la personne au bout du fil. C'est précisément ce que la couche de réflexion doit décrypter à chaque tour de parole :
- L'utilisateur a-t-il terminé, ou fait-il juste une pause ?
- Quelle langue parle-t-il ?
- Est-il curieux, ou furieux à cause d'un mauvais service ?
- Est-ce une télévision en arrière-plan, ou des enfants qui jouent ?
- Me parle-t-il à moi, ou à son partenaire ?
- Que veut-il : un remboursement, un nouveau compte, un suivi de statut ?

Deux extraits audio avec la même transcription : « Oui, allez-y. » L'un est adressé à l'agent, l'autre à quelqu'un d'autre dans la pièce. Seul l'audio permet de les distinguer.
Les éléments en gras ci-dessus nous indiquent comment quelque chose a été dit, et pas seulement ce qui a été dit. Une transcription conserve les mots mais élimine l'intonation, le rythme, les silences et l'environnement sonore.
Prenons la première question. Nous savons tous qu'une personne s'apprête à finir sa phrase avant même que le silence ne s'installe : la hauteur de la voix baisse, le débit ralentit, la voix s'éteint peu à peu. Les modèles qui entendent l'audio apprennent à exploiter exactement ces indices (Ekstedt & Skantze, 2022). Mais ceux qui ne lisent que des transcriptions ne le peuvent pas, car la prosodie n'a jamais été retranscrite (Rajaa, 2026).
Idem pour la cinquième question. Lorsqu'Apple a testé si une prise de parole était destinée à son assistant, l'ajout de l'audio à la transcription a réduit les erreurs jusqu'à 39 % par rapport à la transcription seule.
Les meilleures décisions combinent l'audio et le texte. Malheureusement, les agents actuels ne reçoivent que le texte.

Transcription seule : 74,8 % des tours de parole sont interrompus trop tôt. Avec l'audio : 7,8 %. Uniphore, arXiv 2609.11066.
Pourquoi le réseau de LLM atteint ses limites
Pour construire la « couche de réflexion », les ingénieurs ont opté pour la solution de facilité. Ils ont emprunté le chemin le plus rapide offrant le meilleur retour immédiat : recruter le meilleur LLM frontier du moment et lui confier un manuel géant lui expliquant quoi faire. C'était toute l'histoire de 2023-2024.
Sauf que cette approche pose plusieurs problèmes.
- Premièrement, les équipes ont réalisé que les LLM sont imprévisibles, lents, et qu'ils perdent les instructions noyées dans des prompts longs et denses.
- Deuxièmement, un seul appel à un LLM ne suffit pas pour comprendre une prise de parole.
L'étape logique suivante fut donc un réseau de LLM plus rapides et moins chers : chacun dédié à une tâche différente, avec un orchestrateur au-dessus. Les démos étaient fantastiques. Les acheteurs étaient impressionnés et les revenus ont commencé à affluer.
Voilà la stack frontier d'aujourd'hui.
Mais en production, cette architecture a révélé deux failles :
- Chaque composant lit toujours la même transcription. Ajouter plus de LLM ne ramènera pas la pause ou le ton que la transcription a déjà supprimés.
- Les composants s'attendent les uns les autres. Chaque appel ajoute du délai. Reconnaître le tour de parole, décider quoi faire et exécuter les tâches consomment jusqu'à 80 % du temps de réponse.

Un agent vocal en cascade : l'audio de l'appelant passe par la reconnaissance vocale, puis par plusieurs appels à des LLM, puis par la synthèse vocale. L'intonation, les pauses, le ton, l'arrière-plan et le destinataire sont perdus dès l'étape de reconnaissance vocale.
L'industrie a découpé la couche de réflexion par tâches. Elle aurait dû la découper par type d'entrée : les décisions nécessitant des signaux audio devraient revenir à un modèle natif audio, tandis que le LLM ne devrait traiter que du texte.
Pourquoi ne pas supprimer complètement la transcription ?
Les modèles speech-to-speech (STS) ont commencé à montrer de vrais signes de vie cette année. L'attrait est évident : une latence réduite, une meilleure compréhension de la conversation et moins d'ingénierie, en compressant le STT, le LLM et le TTS dans un seul modèle.
Le principal inconvénient est le manque de contrôle et de données vérifiables. Impossible de prévoir exactement ce qu'un modèle STS va dire, et les appels d'outils ou l'exécution de code ne viennent pas naturellement à un modèle qui pense en audio.
Je pense que le STS est encore loin d'être une réalité à court terme. Même s'il s'accélère, il conviendra d'abord à des cas d'usage plus simples comme la réponse aux FAQ. Les développeurs resteront sur l'architecture en cascade, en partie par inertie, mais surtout parce qu'ils ont besoin de son contrôle et de sa flexibilité.
C'est pourquoi je construis des modèles qui rendent la stack en cascade plus facile à contrôler, et viable à déployer tant en termes de coût que de latence.
La couche qui écoute
Je suis convaincu qu'il existe un moyen de contrôler les agents et d'éliminer le superflu : les modèles de décision.
Regardez de près GPT-Live et vous y trouverez un moteur de décision en son cœur. Plusieurs fois par seconde, il décide s'il doit parler, continuer à écouter, faire une pause, interrompre ou appeler un outil. La cascade a besoin du même moteur, sous forme de composant visible et contrôlable.
Un modèle de décision prend l'état actuel et un ensemble limité d'options (parler ou attendre, escalader ou continuer, quelle intention) et renvoie un choix assorti d'une probabilité, plus rapidement et à un coût bien moindre qu'un LLM. @typesafeai a surpris beaucoup de monde par l'efficacité de cette approche sur du texte.
Voici ce que je propose :
- Le modèle de décision écoute l'appel et prend les décisions bornées.
- Votre logiciel conserve l'état du workflow, les permissions et les outils.
- Le LLM fait ce qu'il fait de mieux : rédiger la réponse, une fois que la décision sur l'action à mener a été prise.

Un modèle de décision prend l'audio, la conversation jusqu'ici et un ensemble d'options, puis renvoie une probabilité pour chaque option : refund_status 0.91, cancel_order 0.06, escalate 0.03 (exemple).
Le score de confiance est ce qui rend tout cela possible. Demandez à un LLM à quel point il est sûr de lui, et il répondra généralement « très », même quand il a tort (Xiong et al., 2024). Les scores d'un classifieur, eux, peuvent être calibrés jusqu'à refléter fidèlement la réalité : quand un classifieur affirme être sûr de lui, il l'est généralement (Guo et al., 2017).
Nos premières expériences avec nos partenaires de conception montrent que 30 à 40 % de ce que fait un LLM au sein d'un agent relève exactement de ce type de travail : routage, tri, choix entre des options limitées.
Mais les modèles de décision actuels travaillent sur du texte ou des images. TypeSafe AI rapporte que chaque modèle, y compris Jev, prend de moins bonnes décisions lorsqu'on ajoute une autre modalité au texte, et Jev ne dispose d'aucun support audio documenté.
On ne peut pas simplement greffer de l'audio sur un modèle de décision textuel. Construire un modèle qui écoute exige trois choses :
- De véritables audios conversationnels annotés avec la bonne décision à chaque instant
- Un modèle qui décide en utilisant l'audio et le texte conjointement
- Des scores de confiance qui restent fiables malgré les accents, le bruit et les mauvaises lignes téléphoniques.
Le bon modèle de décision pour la voix est celui qui écoute : une couche de décision native audio.
Ce qui change quand la couche de décision peut entendre
Un modèle de décision natif audio débloque les cas d'usage suivants :
- Des agents que l'on peut déboguer. De nombreuses équipes conçoivent aujourd'hui un agent sous forme de graphe d'états : saluer, vérifier l'identité, gérer le remboursement, escalader. Chaque tour de parole se résume à deux décisions : dans quel état se trouve réellement la conversation, et vers quel état doit-elle passer ensuite ? Faussez l'une ou l'autre, et tout l'appel déraille.
Avec un modèle de décision à chaque étape, chaque transition devient une petite unité explicable : ce qui a été entendu, quelles options existaient, ce qui a été choisi, et avec quel niveau de confiance. Quand un appel tourne mal, vous ne déboguez pas un prompt géant. Vous trouvez le rouage qui a glissé et vous corrigez cette pièce précise.
- Des réponses prêtes avant même que l'appelant ait fini. Les gens révèlent ce qu'ils veulent avant d'avoir terminé leur phrase. « Je vous appelle au sujet de la commande que j'ai passée la semaine dernière... » est déjà une recherche de commande. Un agent axé sur le texte attend que l'utilisateur s'arrête, attend la transcription finale, décide quel outil appeler, et seulement alors l'appelle. Chaque étape allonge le silence.

Chronologie d'un appelant disant « Je vous appelle au sujet de ma commande de la semaine dernière ». Un agent axé sur le texte attend la fin, puis transcrit, décide et appelle get_order. Un routeur qui écoute déclenche get_order en pleine phrase et répond dès que l'appelant s'arrête, ce qui fait gagner du temps.
Un modèle de décision qui écoute agit comme un routeur qui anticipe l'appel. Il reconnaît l'intention en pleine phrase et déclenche la recherche pendant que l'utilisateur parle encore, de sorte que les détails de la commande sont prêts à l'instant où il s'arrête.
Des chercheurs de Meta et de la CMU ont démontré le bénéfice : prédire les requêtes d'outils en parallèle de la parole de l'utilisateur a réduit la latence des outils de 20 % et rendu les réponses plus précises.
- Des agents personnels qui semblent instantanés. Les agents personnels entendent des commandes via des notes vocales toute la journée, dans les cuisines, les voitures et les rues animées. La plupart de ce qu'ils entendent ne nécessite qu'une vérification rapide : s'agit-il d'une tâche, d'un rappel, d'une pensée passagère, ou cela ne m'est-il pas du tout destiné ?
Envoyer chaque prise de parole à un LLM frontier est lent et coûteux. Un petit modèle qui écoute prend cette décision en une fraction du temps, et ne réveille le LLM que lorsqu'il y a un vrai travail à accomplir. L'agent semble instantané, car la première décision n'attend jamais le gros modèle.
https://x.com/signulll/status/2077444321243013306
L'avenir de l'IA vocale
La voix était censée devenir l'interface universelle. Aujourd'hui, elle ne fonctionne que lorsque la conversation est prévisible.
Mais une conversation non scénarisée n'est pas infinie. À chaque tour de parole, les actions sensées sont peu nombreuses : parler, attendre, demander, agir, transférer. Ce que personne ne peut scénariser, c'est l'ordre dans lequel elles surviennent. Pas besoin de scénariser une conversation pour la contrôler. Il faut prendre chaque décision correctement, à partir de ce qui a réellement été entendu.
C'est sur ce changement que je mise : décider, puis prompter. Un modèle qui écoute prend les décisions, votre logiciel maintient l'état, et le LLM rédige les mots. Chaque décision est visible, rapide et mesurable. Quand cela fonctionnera, la voix cessera d'être un simple canal pour les appels basiques et deviendra la façon dont les gens parlent aux logiciels.
Je construis cette couche de décision chez @tazolabs, et je partagerai davantage de détails sur nos modèles dans les prochains jours.
Si vous développez des agents vocaux, j'adorerais savoir quelles décisions posent problème à votre agent aujourd'hui. Et si cette vision vous parle, venez construire avec nous chez Tazo Labs.
Quelle est la décision que votre agent vocal rate le plus souvent ?





