La voix en temps réel offre une manière fondamentalement différente d’interagir avec les applications fondées sur l’IA. Au lieu de saisir du texte ou de parcourir des menus, les utilisateurs parlent naturellement et reçoivent des réponses au rythme du temps réel, avec un contexte émotionnel.
Créer une excellente expérience vocale en temps réel consiste à coordonner une interaction en direct. C’est là que commence le véritable travail sur le produit. L’expérience en temps réel est immédiate et naturelle ; créer une application qui la maintient constitue un défi d’ingénierie à part entière.
Le modèle n’est qu’une partie du système. Les applications en production nécessitent une infrastructure conçue pour la voix, une séparation nette entre le flux conversationnel et le raisonnement approfondi, ainsi qu’un contrôle événementiel pour gérer la session à mesure qu’elle se déroule.
Les garde-fous et l’évaluation concentrent une grande partie des difficultés restantes. Les contrôles de sécurité doivent suivre le rythme de l’audio en direct, tandis que des qualités conversationnelles fugaces comme le rythme, le ton et la fluidité sont difficiles à évaluer avec les stratégies traditionnelles.
Aujourd’hui, la plupart des applications d’IA à commande vocale fonctionnent encore de la même manière : la parole entre, du texte en sort, un modèle réfléchit, puis une voix de synthèse lit la réponse. Cela fonctionne. Mais l’interaction reflète sa véritable nature : une chaîne de traitement, pas une conversation.
La voix en temps réel change la donne. Les utilisateurs parlent naturellement et reçoivent des réponses qui transmettent rythme, ton et contexte émotionnel. L’expérience est plus rapide et fluide qu’avec les chaînes de conversion parole-texte ; elle ressemble davantage à un échange avec une personne qu’à l’utilisation d’un système.
Nous avons constaté que cela ouvre des possibilités de produit difficiles à exploiter avec les architectures en pipeline. Les agents vocaux en temps réel peuvent gérer des interactions de service client qui nécessiteraient autrement de longs menus SVI contraignants et des transferts entre services. Ils peuvent former, accompagner la prise en main, améliorer l’accessibilité sur différents supports, et bien plus encore. Partout où la conversation orale présente un avantage sur les interfaces textuelles, il est pertinent de développer la voix en temps réel.
La plupart des applications vocales utilisent l’« approche en chaîne » : un pipeline de modèles distincts pour la conversion parole-texte, le traitement du langage et la conversion texte-parole. Ces systèmes fonctionnent bien et ouvrent de nombreuses possibilités, mais l’audio n’intervient qu’aux extrémités. Les étapes distinctes imposent une structure et une latence, ce qui rend l’interaction moins naturelle qu’une vraie conversation.
La voix en temps réel adopte une approche différente. Au lieu de s’appuyer sur des modèles distincts pour écouter, réfléchir et parler, un seul modèle gère nativement ces trois fonctions en comprenant et en générant simultanément l’audio et les transcriptions. Les entrées et sorties sont continues, ce qui permet au système de répondre avec un rythme naturel et de l’émotion, tout en préservant la cadence réaliste d’une conversation en direct. Le rythme, le ton et la gestion des interruptions deviennent ainsi des éléments centraux du produit.
L’expérience en temps réel séduit par son immédiateté ; sa difficulté vient du fait que rien n’attend son tour. Sa prise en charge exige plus qu’une génération audio rapide et précise. Tout le reste constitue la partie difficile. Le modèle fonctionne au sein d’une session en direct ; tout ce qui l’entoure — état, sécurité, orchestration et contrôle — doit suivre la conversation au même rythme.
Dans une application vocale en chaîne, les conversations au tour par tour offrent une structure claire d’échanges successifs. L’utilisateur parle, le système répond, puis l’étape suivante commence. La voix en temps réel n’offre pas cette structure. Les deux parties peuvent parler simultanément ou, au contraire, garder toutes deux le silence. Un utilisateur peut interrompre une réponse en cours ou poser une question complémentaire avant que le système ait fini de parler. Les interruptions cessent d’être des cas limites et deviennent un mode d’interaction central.
C’est pourquoi les applications en temps réel posent avant tout un problème de coordination, et pourquoi le système entourant le modèle compte autant que le modèle lui-même.
La prise en charge de ce type de système à grande échelle exige une conception spécialement adaptée aux interactions en direct, articulée autour de trois éléments récurrents dans les systèmes mis en production.
Les sessions vocales en temps réel doivent gérer la diffusion audio, les tours de parole, les interruptions, le cycle de vie de la connexion et l’exécution des agents. Selon l’environnement de déploiement de l’application, une prise en charge de la téléphonie peut aussi être nécessaire. Ces éléments constituent le socle de l’expérience et sont essentiels au passage à l’échelle de l’application.
Une couche de session conçue pour la voix est la première exigence. Les frameworks de communication en temps réel (RTC) permettent à l’application de gérer les participants, de diffuser l’audio et d’exécuter des agents dans un environnement téléphonique. D’après notre expérience, Livekit s’est révélé particulièrement utile grâce à une pile WebRTC à faible latence, avec réduction de bruit de haute qualité et atténuation de la gigue intégrées. Il est rarement utile d’implémenter soi-même cette couche au prix d’une complexité accrue.
Une architecture multi-agents pour la voix en temps réel repose fondamentalement sur la séparation des responsabilités.
Les modèles vocaux en temps réel excellent dans la diffusion d’audio conversationnel, mais ne sont pas optimisés pour un raisonnement approfondi. Les tâches comme l’appel d’outils, la recherche d’informations ou la prise de décision structurée gagnent à être exécutées par un autre modèle.
Un modèle d’architecture utile est l’architecture répondeur-penseur.
Le répondeur est l’agent vocal en temps réel. Il est chargé de maintenir l’interaction en direct : écouter, parler, gérer les interruptions et préserver la fluidité de la conversation. Sa conception privilégie la réactivité, la clarté et la continuité émotionnelle.
Le penseur est un agent distinct, propulsé par un modèle capable de raisonnement. Il fonctionne hors bande et prend en charge des tâches comme l’utilisation d’outils, la recherche d’informations et la planification. Le répondeur peut le solliciter si nécessaire, puis réintégrer les résultats dans la conversation.
Dans certains cas, le penseur peut assurer directement le raisonnement. Dans d’autres, il peut orchestrer un ensemble d’agents spécialisés. L’idée essentielle est de confier ce travail à un modèle mieux adapté aux tâches de raisonnement.
L’avantage est simple : le répondeur reste rapide, naturel et concentré, tandis que le penseur gère les tâches nécessitant davantage de temps, de contexte ou de structure.
Les futurs progrès des modèles de pointe pourraient rendre cette approche inutile, mais nous constatons pour l’instant qu’elle surpasse systématiquement les approches à agent unique.
Les systèmes vocaux en temps réel produisent naturellement un flux continu d’événements.
Les utilisateurs commencent à parler, marquent une pause et interrompent. Les transcriptions sont mises à jour progressivement. Les réponses sont générées et diffusées en continu. Les résultats externes arrivent. Les conditions de la session évoluent. Tous ces éléments peuvent être capturés, diffusés et stockés comme des événements clés ayant produit l’état actuel de la conversation. Sans eux, nous perdons la capacité d’effectuer des interventions précises et ciblées.
Une approche événementielle offre un moyen clair de gérer cela. Le système capture les événements à mesure qu’ils surviennent, actualise l’état de la session et déclenche les actions de suivi appropriées.
Des gestionnaires légers préservent la réactivité du parcours en temps réel, tandis que les tâches plus complexes — mise à jour des machines à états, journalisation des métriques, suppression des informations sensibles, mise à jour des bases de données et fermeture d’une session — sont déclenchées de manière asynchrone en arrière-plan.
À mesure que des fonctionnalités sont ajoutées, le nombre de ces tâches d’arrière-plan peut augmenter rapidement. Même de petites modifications du produit peuvent créer de nouveaux flux d’événements et de nouvelles dépendances. Une architecture bien structurée pour gérer cette concurrence est essentielle afin que le système reste compréhensible et fiable au fil de son évolution.
Cette approche événementielle répond aussi à un enjeu produit essentiel : façonner la conversation elle-même. Un système audio en temps réel ne se contente pas de générer des réponses : il gère le rythme, les silences et les interruptions, et décide comment et quand terminer une session. Ces comportements font partie de l’expérience produit et gagnent à être conçus explicitement.
À mesure que l’état de la session évolue selon le nombre de tours, le temps écoulé ou le comportement de l’utilisateur, le système peut transmettre des consignes ciblées au répondeur. Il peut inciter l’agent à aider l’utilisateur à conclure à l’approche de la limite de session, ou apporter des précisions si l’interaction s’enlise. Ces interventions sont légères, mais rendent l’expérience intentionnelle et cohérente.
Un système bien conçu conserve une vision claire de l’état de la session : qui parle, comment la conversation progresse et quelles conditions sont remplies. Cet état, continuellement actualisé par le flux d’événements, permet de fournir les bonnes consignes au bon moment.
Les garde-fous ne sont pas facultatifs dans une IA destinée aux utilisateurs. Ils assurent la sécurité, la conformité, la prévention des abus et la fiabilité. Dans un système au tour par tour, les moments où les appliquer sont évidents : après que l’utilisateur a parlé ou avant de transmettre une réponse.
La voix en temps réel supprime la plupart de ces points de contrôle commodes. Les entrées de l’utilisateur arrivent en continu. La sortie audio peut déjà être diffusée en continu. Les transcriptions terminées sont souvent en retard sur le son. Si le système attend des messages complets avant de les vérifier, la conversation ne semble plus se dérouler en temps réel.
Les garde-fous doivent plutôt fonctionner en parallèle de la conversation pour préserver une interaction naturelle. Une approche consiste à diffuser l’audio dans une mémoire tampon tout en évaluant de manière asynchrone les fragments de transcription dès qu’ils sont disponibles. Les contrôles de sécurité peuvent ainsi s’exécuter presque en temps réel sans bloquer l’interaction.
Lorsqu’un garde-fou se déclenche, le système peut réagir selon le contexte en réorientant la conversation, en adaptant son comportement ou, si nécessaire, en mettant fin à la session. Ainsi, les garde-fous fonctionnent en temps réel sans dégrader l’expérience utilisateur.
Le plus difficile dans l’évaluation d’un système conversationnel en temps réel est que certaines qualités essentielles — rythme, interruptions, fluidité et ton — ne peuvent pas être mesurées uniquement à partir des transcriptions.
Les pipelines d’évaluation standard soumettent des scénarios réalistes au système, observent ses sorties et leur attribuent une note. Pour les systèmes textuels ou les chaînes de traitement audio, c’est simple : envoyer du texte et vérifier le texte produit. En temps réel, l’entrée est un flux audio en direct et les dynamiques conversationnelles les plus importantes relèvent du temps : la manière dont l’agent gère les prises de parole simultanées, sa rapidité de réponse et sa reprise après une interruption.
Les tests manuels, qui consistent à parler directement à l’agent, saisissent ces qualités, mais ne sont pas adaptables à grande échelle. L’automatisation fondée sur les transcriptions passe à l’échelle, mais supprime le signal qui distingue une bonne expérience en temps réel d’une mauvaise.
Aucune méthode ne suffit à elle seule. La solution pratique consiste à combiner plusieurs couches :
Évaluations d’agent à agent : un deuxième agent en temps réel, chargé d’incarner un profil utilisateur précis, dialogue avec le système testé. Un troisième LLM faisant office de juge note l’interaction. Cela permet de tester à grande échelle l’ensemble du parcours audio, y compris le rythme et la gestion des interruptions.
Indicateurs non fonctionnels : le délai avant le premier son et l’analyse des sentiments dans les transcriptions fournissent des indicateurs quantitatifs indirects de la qualité conversationnelle.
Examen qualitatif manuel : toujours essentiel pour détecter les problèmes ignorés par les indicateurs automatisés, notamment ceux liés au ton et au naturel.
Aucune méthode ne couvre tout à elle seule. Le déploiement en production d’agents en temps réel exige de combiner ces trois méthodes. Même ainsi, les outils d’évaluation audio en temps réel restent peu matures par rapport à ceux de l’IA textuelle.
La voix en temps réel transforme la nature du produit. Le rythme, les interruptions, les silences et la reprise comptent autant pour les utilisateurs que les mots.
Le modèle n’est donc qu’une partie du système. En production, la voix en temps réel nécessite une couche de session conçue pour la voix, une séparation nette entre parole et raisonnement, ainsi qu’un contrôle événementiel de la session en direct. Les garde-fous restent le principal goulot d’étranglement en matière de latence, mais des approches créatives permettent de préserver une grande partie de l’expérience en temps réel.
L’évaluation reste la partie la plus faible de la pile. Il n’existe pas encore de méthode établie pour tester les qualités d’une bonne expérience vocale en temps réel : rythme, ton, gestion des interruptions et fluidité de la conversation. D’ici là, les équipes qui utilisent cette technologie devront associer tests automatisés, exécutions d’agent à agent et examens manuels.