La voix en temps réel offre une façon fondamentalement différente d’interagir avec les applications propulsées par l’IA. Au lieu de taper du texte ou de parcourir des menus, les utilisateurs parlent naturellement et reçoivent des réponses au rythme naturel, qui tiennent compte du contexte émotionnel.
Créer une excellente expérience vocale en temps réel consiste à coordonner une interaction en direct. C’est ici 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 distinct.
Le modèle n’est qu’une partie du système. Les applications en production exigent une infrastructure conçue pour la voix, une séparation claire 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 les qualités conversationnelles éphémères 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 façon : la parole entre, du texte en sort, un modèle réfléchit et une voix synthétique lit la réponse. Cela fonctionne. Mais l’interaction donne l’impression de ce qu’elle est : une chaîne de traitement, et non une conversation.
La voix en temps réel change la donne. Les utilisateurs parlent naturellement et reçoivent des réponses qui transmettent un rythme, un ton et un contexte émotionnel. L’expérience est plus rapide et fluide que les chaînes de conversion parole-texte. Elle ressemble davantage à une conversation avec une personne qu’à l’utilisation d’un système.
Nous avons constaté que cela ouvre des possibilités de produits auxquelles les architectures en chaîne se prêtent mal. Les agents vocaux en temps réel peuvent gérer des interactions de service à la clientèle qui exigeraient autrement de longs menus RVI contraignants et des transferts entre services. Ils peuvent offrir de l’accompagnement, faciliter l’intégration, favoriser l’accessibilité sur différents supports et bien plus encore. Partout où la conversation orale présente un avantage sur les interfaces textuelles, il vaut la peine de développer la voix en temps réel.
La plupart des applications vocales utilisent ce qu’on appelle « l’approche en chaîne » : une suite 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 ne se trouve qu’aux extrémités. Les étapes distinctes imposent une structure et ajoutent de la latence, ce qui rend l’interaction moins naturelle qu’une véritable conversation.
La voix en temps réel adopte une approche différente. Plutôt que de s’appuyer sur des modèles distincts pour écouter, réfléchir et parler, un seul modèle gère nativement les trois fonctions, en comprenant et en générant simultanément l’audio et les transcriptions. Les entrées et les sorties sont continues. Le système peut ainsi répondre avec un rythme naturel et une expressivité émotionnelle qui préservent la cadence réaliste d’une conversation en direct. Le rythme, le ton et la gestion des interruptions deviennent donc des éléments centraux du produit.
L’expérience en temps réel est attrayante parce qu’elle semble immédiate; elle est difficile à réaliser parce 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 dans une session en direct; tout ce qui l’entoure — état, sécurité, orchestration et contrôle — doit fonctionner en parallèle avec la conversation, au même rythme.
Dans une application vocale en chaîne, les conversations au tour par tour offrent une structure d’échange claire. 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, aucune ne parle et le silence s’installe. 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 fondamentalement un problème de coordination et que 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 adaptée aux interactions en direct. Elle repose sur 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, la prise en charge de la téléphonie peut aussi être nécessaire. Ce sont des éléments fondamentaux de l’expérience et essentiels au déploiement à grande échelle de l’application.
Une couche de session conçue pour la voix constitue la première exigence. Les cadres 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 en fournissant une pile WebRTC à faible latence, dotée d’une réduction de bruit de haute qualité et d’une atténuation de la gigue prêtes à l’emploi. La complexité supplémentaire liée à la mise en œuvre interne de cette couche en vaut rarement la peine.
Une architecture multiagent pour la voix en temps réel repose fondamentalement sur la séparation des responsabilités.
Les modèles vocaux en temps réel sont très efficaces pour la diffusion audio conversationnelle, mais ils ne sont pas optimisés pour le raisonnement approfondi. Les tâches comme l’appel d’outils, la recherche d’information ou la prise de décisions structurée gagnent à être exécutées par un autre modèle.
L’architecture répondant-penseur constitue un modèle utile.
Le répondant 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 gère des tâches comme l’utilisation d’outils, la recherche d’information et la planification. Le répondant peut faire appel à lui au besoin et réintégrer les résultats dans la conversation.
Dans certains cas, le penseur peut effectuer lui-même le raisonnement. Dans d’autres, il peut orchestrer un ensemble d’agents spécialisés. L’idée principale est de confier ce travail à un modèle mieux adapté aux tâches de raisonnement.
L’avantage est simple : le répondant reste rapide, naturel et concentré, tandis que le penseur gère le travail qui exige plus 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, font une pause et interrompent. Les transcriptions sont mises à jour progressivement. Les réponses sont générées et diffusées en continu. Des résultats externes arrivent. Les conditions évoluent au cours de la session. Tous ces éléments peuvent être saisis, diffusés et stockés comme des évènements clés ayant créé l’état actuel précis de la conversation. Sans eux, nous perdons la capacité d’effectuer des interventions précises et ciblées.
Une approche évènementielle offre une façon claire de gérer cette situation. Le système saisit les évènements à mesure qu’ils surviennent, met à jour 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 mesures, suppression des renseignements sensibles, mise à jour des bases de données et fermeture d’une session — sont déclenchées de façon asynchrone en arrière-plan.
À mesure que des fonctionnalités sont ajoutées, le nombre de tâches en arrière-plan peut augmenter rapidement. Même de petits changements au produit peuvent introduire 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 demeure compréhensible et fiable à mesure qu’il évolue.
Cette approche évènementielle répond aussi à un enjeu essentiel du produit : façonner la conversation elle-même. Un système audio en temps réel ne se limite pas à générer des réponses; il gère le rythme, les silences et les interruptions, puis décide comment et quand mettre fin à une session. Ces comportements font partie de l’expérience du 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 directives ciblées au répondant. Il peut inviter l’agent à aider l’utilisateur à conclure à l’approche de la limite de la session ou à fournir 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 vue claire de l’état de la session : qui parle, comment la conversation progresse et quelles conditions ont été remplies. Cet état, continuellement actualisé par le flux d’évènements, permet de fournir les bonnes directives au bon moment.
Les garde-fous ne sont pas facultatifs dans une IA destinée aux utilisateurs. Ils gèrent la sécurité, la conformité, les utilisations abusives et la fiabilité. Dans un système au tour par tour, il existe des moments évidents pour les exécuter : après que l’utilisateur a parlé ou avant de livrer une réponse.
La voix en temps réel élimine la plupart de ces points de contrôle pratiques. Les entrées de l’utilisateur arrivent en continu. La sortie audio peut déjà être diffusée en continu. Les transcriptions finales sont souvent en retard sur le son. Si le système attend les messages complets avant de les vérifier, la conversation cesse de sembler se dérouler en temps réel.
Les garde-fous doivent plutôt fonctionner en parallèle avec la conversation pour préserver le naturel de l’interaction. Une approche consiste à placer l’audio dans une mémoire tampon tout en évaluant de façon 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, au besoin, en mettant fin à la session. Les garde-fous fonctionnent ainsi en temps réel sans nuire à l’expérience utilisateur.
Le plus difficile dans l’évaluation d’un système conversationnel en temps réel est que certaines des qualités les plus importantes — rythme, interruptions, fluidité et ton — ne peuvent pas être mesurées par des tests fondés uniquement sur les transcriptions.
Les processus d’évaluation standards soumettent des scénarios réalistes au système, observent les sorties et les notent. Pour les systèmes textuels ou les chaînes 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 s’inscrivent dans le temps : la façon dont l’agent gère les paroles simultanées, sa vitesse 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 peuvent pas être déployés à grande échelle. L’automatisation fondée sur les transcriptions passe à l’échelle, mais élimine 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 méthodes :
Évaluations d’agent à agent : un deuxième agent en temps réel, chargé d’incarner un profil utilisateur précis, converse avec le système testé. Un troisième LLM agissant comme juge note l’interaction. Cette méthode teste à grande échelle l’ensemble du parcours audio, notamment le rythme et la gestion des interruptions.
Mesures non fonctionnelles : le délai avant le premier son et l’analyse des sentiments dans les transcriptions fournissent des indicateurs quantitatifs de la qualité conversationnelle.
Examen qualitatif manuel : toujours essentiel pour repérer les problèmes que les mesures automatisées omettent, particulièrement en matière de ton et de naturel.
Aucune méthode ne couvre tout à elle seule. Le déploiement d’agents en temps réel en production exige de combiner les trois méthodes. Même ainsi, les outils d’évaluation audio en temps réel restent peu évolués comparativement à 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 exige une couche de session conçue pour la voix, une séparation claire entre la parole et le raisonnement ainsi qu’un contrôle évènementiel de la session en direct. Les garde-fous demeurent le principal goulot d’étranglement lié à la latence, mais des approches créatives peuvent préserver une grande part de l’expérience en temps réel.
L’évaluation demeure le maillon le plus faible de l’ensemble. Il n’existe pas encore de méthode établie pour tester les qualités d’une bonne expérience vocale en temps réel : le rythme, le ton, la gestion des interruptions et la fluidité de la conversation. D’ici là, les équipes qui développent cette technologie devront combiner des tests automatisés, des exécutions d’agent à agent et des examens manuels.