Architecture d'un agent vocal IA : les deux voies

Un agent vocal se construit de deux façons. La première est une chaîne en cascade : la parole est transcrite en texte, un modèle de langage écrit la réponse, puis une synthèse vocale la lit. La seconde est un modèle voix-à-voix, qui reçoit l'audio et renvoie l'audio dans une seule API. La chaîne donne la main sur chaque étape. Le modèle voix-à-voix raccourcit le chemin, mais il laisse moins de prise sur ce qui se passe entre l'entrée et la sortie.

La chaîne en cascade

La documentation de LiveKit Agents décrit un agent comme un pipeline STT-LLM-TTS : reconnaissance vocale (STT), modèle de langage (LLM), puis synthèse vocale (TTS). Le framework gère en plus la détection de fin de tour, les interruptions et l'orchestration du modèle. La page ne détaille pas chaque étape, mais elle montre le principe : chaque brique est un service séparé, que l'on peut changer sans toucher aux autres.

Ce que cela implique :

• Contrôle. Vous choisissez le fournisseur de reconnaissance, celui de synthèse, le modèle de langage. Vous pouvez remplacer l'un d'eux si la qualité baisse sur un accent ou un vocabulaire métier.
• Trace. Le texte intermédiaire existe. On peut le journaliser, le relire et le tester (voir évaluer un agent vocal).
• Coût. Chaque brique se facture à part. Les prix relevés pour la reconnaissance et la synthèse figurent dans le coût par minute.
• Latence. Chaque étape ajoute un délai, sauf si elle démarre avant la fin de la précédente (le streaming). Voir la latence d'un agent vocal.

Le modèle voix-à-voix

Le framework LiveKit Agents mentionne aussi les « realtime APIs » parmi les types de modèles pris en charge, sans les décrire en détail. Le cas de Gemini Live est plus précis : la documentation décrit une connexion WebSocket avec de l'audio PCM en entrée et en sortie, et des transcriptions disponibles pour ce qui est entendu et dit. Voir la fiche Gemini Live.

Avec ce type de modèle, la détection des tours et des interruptions change de place. D'après la documentation LiveKit sur la détection de fin de tour, avec un modèle temps réel dont la détection se fait côté serveur, les réglages d'interruption de l'agent sont en grande partie ignorés, et désactiver les interruptions lève une erreur. Il faut donc vérifier ce point avant de choisir cette voie.

Tableau de choix

Ce qu'il faut décider avant de coder

1. Les langues. Vérifiez, pour chaque brique, que le français figure dans la liste officielle. Une page qui ne le liste pas ne prouve pas qu'il est absent, mais elle ne le garantit pas non plus.
2. Le lieu de traitement des données. Les appels audio passent par ces services. Demandez à chaque fournisseur où les données sont traitées, avec votre délégué à la protection des données.
3. Le cadre open source. Un framework libre ne rend pas les services qu'il appelle gratuits. Les frameworks comparés dans le comparatif open source appellent des API payantes, sauf si vous hébergez vos propres modèles.
4. Le repli. Prévoyez ce que fait l'agent quand un service ne répond pas : message d'attente, transfert vers un humain (voir transférer un appel).

Ce que les documentations ne donnent pas

Aucune des pages lues ne publie de délai de réponse global pour un agent complet. Les chiffres de latence qui circulent dépendent du réseau, de la région, du modèle et de la longueur de la réponse. Pour votre cas, mesurez sur vos propres appels. La méthode est décrite dans la page sur la latence.

Le choix entre les deux voies dépend donc surtout de ce que vous devez contrôler : le texte de chaque réponse, les coûts par brique, ou la rapidité de mise en place. Pour un premier prototype, la chaîne en cascade permet de voir chaque étape ; le modèle voix-à-voix convient quand la conversation reste simple et que la trace texte n'est pas une exigence.