Agents vocaux : architecture des assistants IA en temps réel

Comment construire un assistant capable de tenir une conversation orale naturelle, de répondre au téléphone ou de piloter des outils à la voix ? Taper du texte dans un chatbot est une chose, parler à une machine en est une autre : le moindre silence de trop, la moindre coupure maladroite et l'illusion s'effondre. C'est tout l'enjeu des agents vocaux.

Standards téléphoniques, prise de rendez-vous, support client de premier niveau, coaching, assistants embarqués : les cas d'usage se multiplient à mesure que les modèles de langue, la reconnaissance et la synthèse vocales progressent. Pour un AI Engineer, le défi n'est plus seulement de produire une bonne réponse, mais de la livrer dans la bonne seconde, avec la bonne intonation, tout en gérant un interlocuteur qui parle, hésite et interrompt.

Dans cet article, nous allons comparer l'architecture en cascade et les modèles speech-to-speech, puis analyser la latence, la gestion du tour de parole et des interruptions, le tool calling vocal, les frameworks open source Pipecat et LiveKit Agents, avant de voir comment évaluer un agent vocal en production.

Deux architectures : cascade et speech-to-speech

Un agent vocal doit transformer un flux audio en entrée en un flux audio en sortie, avec une capacité de raisonnement au milieu. Deux familles d'architectures coexistent.

L'approche en cascade

L'approche historique enchaîne trois briques spécialisées :

• Speech-to-text (STT) : transcrit la voix de l'utilisateur en texte, idéalement en continu (streaming), avec des services comme Deepgram, AssemblyAI ou le modèle open source Whisper
• LLM : analyse la transcription, raisonne, appelle des outils et génère la réponse sous forme de texte
• Text-to-speech (TTS) : convertit la réponse en audio, avec des voix proposées notamment par Cartesia, ElevenLabs ou OpenAI

Micro -> VAD -> STT -> LLM -> TTS -> Haut-parleur
                        |
                     Outils

Cette architecture est la plus répandue en production, car elle est modulaire : on peut changer de fournisseur de transcription sans toucher au modèle, utiliser n'importe quel LLM, ajuster le prompt et brancher des garde-fous sur le texte. Elle offre aussi une excellente observabilité, puisque chaque étape produit une trace lisible. Son principal défaut tient à l'addition des latences de chaque maillon et à la perte d'information paralinguistique : le ton, l'hésitation ou l'émotion disparaissent à la transcription.

Les modèles speech-to-speech

Les modèles speech-to-speech natifs, comme l'API Realtime d'OpenAI ou les modèles Gemini Live, traitent directement l'audio en entrée et produisent de l'audio en sortie, sans passer par une transcription intermédiaire explicite. Le modèle perçoit l'intonation, peut rire, murmurer ou changer de rythme, et la latence est réduite puisqu'un seul appel remplace trois étapes.

Ces modèles ont en contrepartie des limites : le choix de voix et de modèle est restreint, le contrôle fin du comportement est plus difficile, le coût par minute est généralement plus élevé et il est plus compliqué de déboguer une réponse qui n'existe pas sous forme de texte. Le tableau suivant résume les compromis.

En pratique, la cascade reste le choix par défaut pour les assistants d'entreprise qui exigent contrôle, traçabilité et conformité, tandis que le speech-to-speech séduit pour les expériences où le naturel prime. Certains frameworks permettent d'ailleurs de basculer de l'un à l'autre avec la même logique applicative.

Latence : le nerf de la guerre

Dans une conversation humaine, le délai entre la fin d'une phrase et le début de la réponse est de l'ordre de quelques centaines de millisecondes. Au-delà d'environ une seconde, l'échange paraît artificiel. La latence « de bout en bout » d'un agent vocal se mesure donc entre le moment où l'utilisateur cesse de parler et celui où le premier son de la réponse est audible.

Dans une cascade, ce délai se décompose en plusieurs contributions :

• Détection de fin de parole : le temps d'attente pour s'assurer que l'utilisateur a fini sa phrase
• Transcription finale : le STT en streaming limite ce coût, car la plupart des mots sont déjà transcrits
• Time to first token du LLM : souvent la contribution principale, qui dépend du modèle, de la taille du prompt et de la charge
• Time to first byte du TTS : le délai avant la production du premier échantillon audio
• Réseau : le trajet de l'audio entre l'utilisateur, le serveur et les fournisseurs de modèles

Plusieurs leviers permettent de tenir le budget. Le premier est le streaming à chaque étape : le LLM envoie ses tokens dès qu'ils sont générés, le TTS commence à synthétiser dès la première phrase complète, sans attendre la fin de la réponse. Le deuxième consiste à choisir des modèles rapides et compacts pour le dialogue, quitte à réserver un modèle plus puissant aux tâches complexes. Le troisième est de rapprocher géographiquement les composants et de privilégier des transports temps réel, comme WebRTC pour le navigateur ou SIP pour la téléphonie, plutôt que de simples requêtes HTTP. Enfin, la réutilisation de contexte via le caching du prompt système réduit le temps de traitement à chaque tour.

Il faut aussi masquer l'attente quand elle est inévitable. Un agent qui appelle un outil lent peut prononcer une phrase de transition (« Je vérifie cela dans votre dossier ») pour éviter un silence qui laisserait croire à une coupure.

Tour de parole et interruptions

Une conversation orale n'est pas un échange de messages bien délimités. L'utilisateur coupe la parole, marque des pauses, dit « euh », tousse, et le bruit de fond peut être pris pour de la voix. Le cœur de l'expérience tient dans la gestion de ces situations.

Détection d'activité vocale et fin de tour

La détection d'activité vocale (VAD, voice activity detection) est un petit modèle, comme Silero VAD, qui indique à chaque instant si le flux contient de la parole. Elle sert à découper l'audio et à déclencher la transcription. Mais un silence ne signifie pas toujours que l'utilisateur a terminé : une personne qui énumère un numéro de commande marque des pauses au milieu de sa phrase.

C'est pourquoi les frameworks ajoutent des modèles de détection de fin de tour (turn detection), qui analysent le contenu sémantique de ce qui vient d'être dit pour décider si la phrase est complète. Un seuil de silence trop court coupe l'utilisateur, un seuil trop long ralentit chaque réponse. L'enjeu est de trouver le bon compromis, souvent à ajuster selon le cas d'usage.

Gérer les interruptions

Quand l'utilisateur prend la parole alors que l'agent parle (le barge-in), l'agent doit s'arrêter rapidement. Concrètement, il faut :

• Stopper la lecture audio et vider les tampons du TTS déjà synthétisés
• Annuler la génération en cours du LLM et de la synthèse, pour ne pas gaspiller de tokens
• Mettre à jour l'historique avec ce qui a réellement été prononcé, et non avec la réponse complète prévue, afin que le modèle sache où la phrase a été interrompue
• Filtrer les faux positifs comme un « mmh » d'acquiescement ou un bruit ambiant, qui ne doivent pas couper l'agent

L'annulation de la réponse et la mise à jour du contexte sont deux points souvent négligés dans les prototypes. Ils décident pourtant de la cohérence d'une conversation longue. On retrouve ici les problématiques de gestion de l'état des agents, avec la contrainte supplémentaire du temps réel.

Tool calling et agents vocaux

Un agent vocal utile ne se contente pas de discuter : il consulte un agenda, crée un ticket, vérifie une commande ou transfère l'appel. Il s'appuie pour cela sur le tool calling, avec des contraintes propres à l'oral.

D'abord, les outils doivent être rapides ou explicitement masqués par une phrase d'attente, car chaque seconde de silence se remarque. Ensuite, leurs résultats doivent être courts et adaptés à l'oral : lire un tableau de vingt lignes à voix haute n'a aucun sens, il vaut mieux résumer et proposer d'envoyer le détail par SMS ou par e-mail. Enfin, les actions sensibles (annulation, paiement) doivent demander une confirmation orale explicite, comme le recommandent les principes du human-in-the-loop. Les outils peuvent aussi être exposés par un serveur MCP, ce qui permet de réutiliser les mêmes intégrations entre un agent textuel et un agent vocal.

À lire : découvrez notre formation Agentic AI

Frameworks open source : Pipecat et LiveKit Agents

Assembler soi-même le transport temps réel, la VAD, les trois modèles et la gestion des interruptions représente un travail considérable. Deux frameworks open source, écrits en Python, se sont imposés pour le faire.

Pipecat est un framework de pipelines pour agents conversationnels. Il organise le traitement en composants modulaires qui se transmettent des trames (audio, texte, événements) : transport, VAD, STT, LLM, TTS. Il prend en charge de nombreux fournisseurs (Deepgram, AssemblyAI, OpenAI, Anthropic, Cartesia, ElevenLabs...), des modèles speech-to-speech et plusieurs transports comme Daily ou LiveKit. Il se distingue par sa flexibilité : on construit son pipeline brique par brique et on y insère ses propres traitements.

LiveKit Agents s'appuie sur l'infrastructure WebRTC de LiveKit. Un agent rejoint une « room » comme un participant, ce qui facilite la connexion depuis des applications web, mobiles ou depuis le réseau téléphonique grâce à sa pile de téléphonie SIP. Il fournit un modèle de détection de fin de tour intégré et gère nativement les interruptions. L'exemple suivant, inspiré du démarrage officiel, définit un agent avec un outil :

from livekit.agents import (
    Agent,
    AgentServer,
    AgentSession,
    JobContext,
    RunContext,
    cli,
    function_tool,
    inference,
)


@function_tool
async def statut_commande(context: RunContext, numero: str):
    """Renvoie le statut d'une commande à partir de son numéro."""
    # Appel fictif : à remplacer par une requête vers votre système
    return {"numero": numero, "statut": "expédiée"}


server = AgentServer()


@server.rtc_session()
async def entrypoint(ctx: JobContext):
    session = AgentSession(
        vad=inference.VAD(),
        stt=inference.STT("deepgram/nova-3", language="multi"),
        llm=inference.LLM("openai/gpt-4.1-mini"),
        tts=inference.TTS("cartesia/sonic-3", voice="<identifiant-de-voix>"),
    )
    agent = Agent(
        instructions="Tu es un assistant téléphonique concis. Réponds en une ou deux phrases.",
        tools=[statut_commande],
    )
    await session.start(agent=agent, room=ctx.room)
    await session.generate_reply(instructions="Salue l'utilisateur et propose ton aide")


if __name__ == "__main__":
    cli.run_app(server)

Le code déclare une session qui assemble la VAD, le STT, le LLM et le TTS, puis un agent qui reçoit ses instructions et ses outils. L'agent rejoint la room, salue l'utilisateur et le framework se charge du streaming, du tour de parole et des interruptions. Les identifiants de modèles dépendent de votre fournisseur et de la version du SDK : il faut consulter la documentation pour les valeurs en vigueur.

Le choix entre les deux dépend du contexte. Pipecat convient bien aux pipelines très personnalisés et aux équipes qui veulent maîtriser chaque composant, LiveKit Agents aux projets où l'infrastructure temps réel et la téléphonie sont centrales. Dans les deux cas, le choix du transport pèse sur la latence, comme le montre la comparaison des protocoles de communication dans notre article gRPC vs REST.

Évaluer et surveiller un agent vocal en production

Un agent vocal qui fonctionne en démonstration peut décevoir dès les premiers appels réels : accents, bruit, interlocuteurs pressés, numéros dictés chiffre par chiffre. L'évaluation d'un agent doit donc couvrir à la fois la qualité de la conversation et les performances techniques.

Les indicateurs à suivre se répartissent en deux familles :

• Indicateurs techniques : latence de bout en bout (en suivant les percentiles p50 et p95 plutôt que la moyenne), taux d'interruption mal gérée, taux d'erreur de transcription (WER), disponibilité des fournisseurs
• Indicateurs métier : taux de résolution sans transfert humain, taux de réussite des tâches, durée moyenne des appels, satisfaction des utilisateurs

Pour la qualité des réponses, on peut combiner des scénarios de test simulés (un second agent joue le client, avec différents profils et niveaux de bruit) et un jugement automatique par LLM-as-a-Judge appliqué aux transcriptions. Les traces de chaque tour (audio, transcription, appels d'outils, durées) doivent être conservées, avec l'accord de l'utilisateur et dans le respect du RGPD, grâce à un outil d'observabilité comme Langfuse. Sans elles, impossible de comprendre pourquoi un appel a mal tourné.

Enfin, la mise en production demande les mêmes précautions que pour tout agent IA en production : des guardrails pour empêcher les dérives et l'usurpation de consignes par la voix, une maîtrise des coûts à la minute, et un transfert vers un humain chaque fois que l'agent atteint ses limites. Sur ce dernier point, l'optimisation du budget est d'autant plus importante que la facturation d'un agent vocal cumule transcription, tokens et synthèse.

À découvrir : notre formation Agentic AI

Conclusion

Concevoir un agent vocal consiste à orchestrer un flux temps réel autour d'un modèle de langue. L'architecture en cascade offre modularité, contrôle et observabilité, tandis que les modèles speech-to-speech apportent naturel et faible latence au prix d'une moindre maîtrise. Le choix dépend des exigences du produit plutôt que d'une supériorité absolue de l'une des approches.

La qualité perçue se joue sur la latence et sur la gestion du tour de parole : streaming à chaque étape, détection de fin de tour, annulation propre des réponses interrompues et phrases d'attente pendant les appels d'outils. Pipecat et LiveKit Agents fournissent ces mécanismes prêts à l'emploi, ce qui permet de se concentrer sur la logique métier, les outils et les garde-fous.

Enfin, un agent vocal ne se juge pas sur une démonstration mais sur des appels réels, mesurés, tracés et évalués en continu. Savoir concevoir, déployer et améliorer ces assistants en temps réel est une compétence différenciante pour les AI Engineers, à mesure que la voix redevient une interface de premier plan.