Modèles en cascade vs fusionnés : comparaison des architectures derrière les agents conversationnels

ElevenAgents sont propulsés par un moteur d’orchestration à faible latence, conçu spécialement pour les conversations en temps réel, ajoutant moins de 100 ms de latence. Cette architecture combine le meilleur de la recherche ElevenLabs avec des LLM de pointe de fournisseurs comme OpenAI, Google et Anthropic, ainsi que des modèles open source sélectionnés et hébergés par ElevenLabs. En utilisant plusieurs modèles à différentes étapes de la chaîne de réponse, l’agent garantit des conversations à la fois très réactives et pertinentes. En exploitant dynamiquement les points forts de chaque modèle, nous assurons des performances fiables et évolutives sur une large gamme de tâches et de scénarios conversationnels en entreprise, tout en optimisant l’équilibre entre intelligence, rapidité et coût.

L’architecture de l’agent influence le naturel, l’intelligence et la cohérence de ses réponses, ainsi que sa capacité à rester prévisible dans le temps. Par exemple, un agent basé sur une architecture fusionnée peut sembler très réaliste lors d’échanges courts, mais avoir du mal à raisonner ou à rester cohérent lors de conversations plus longues.

Chez ElevenLabs, nous utilisons une architecture en cascade qui enchaîne des modules spécialisés pour la reconnaissance vocale, le raisonnement et la génération vocale. À l’inverse, le modèle Realtime d’OpenAI adopte une approche fusionnée qui regroupe ces étapes dans un seul réseau.

Dans cet article, nous présentons les cinq principales architectures d’agents conversationnels actuelles, en expliquant leurs principes, leurs avantages et inconvénients, et comment les équipes choisissent selon leurs objectifs.outils et d’une base de connaissances. Il est préférable de choisir des agents indépendants plutôt que des workflows lorsque le cas d’usage nécessite peu de vérifications d’une séquence stricte d’étapes ou lorsqu’il est important d’éviter les silos de connaissances entre agents. Les silos apparaissent lorsque certains outils, documents ou contextes historiques sont accessibles à certains sous-agents mais pas à d’autres. C’est inhérent aux workflows multi-agents et cela crée un compromis entre flexibilité et déterminisme.

Ce que les équipes cherchent à optimiser lors de la création d’agents

• Formulent des requêtes de génération efficaces
• Récupèrent et intègrent les documents pertinents
• Génèrent et exécutent des appels d’outils pour enrichir les réponses
• Produisent des résultats pour l’évaluation et la collecte de données

Construction du contexte de conversation 

Même si d’autres facteurs comme la gestion de la simultanéité, les intégrations ou la qualité vocale comptent aussi, les axes ci-dessus dépendent directement de l’architecture de l’agent. Les équipes les plus performantes adaptent leur architecture pour optimiser ces aspects selon leur cas d’usage.

Les architectures en cascade sont construites en enchaînant des composants spécialisés : , un Large Language Model, et Text to Speech. Chaque étape peut être optimisée, testée et améliorée indépendamment.article précédent. Cela permet de retrouver efficacement des documents même si la dernière intervention de l’utilisateur est un suivi, une confirmation ou ne contient pas de question explicite.

La récupération n’est cependant qu’une des façons dont les agents interagissent avec des systèmes externes.

Cette modularité permet aux équipes d’intégrer les derniers LLM pour un meilleur raisonnement, d’appliquer des garde-fous explicites au niveau du texte, et de contrôler précisément la façon dont l’agent parle grâce à un TTS contextuel. Le principal compromis est que les architectures en cascade perdent souvent plus de signaux prosodiques – comme l’intonation, le rythme et l’émotion – car la parole est convertie en texte avant d’être régénérée. Ces indices peuvent être partiellement récupérés par une modélisation explicite, mais ils ne sont pas capturés aussi naturellement que dans les approches fusionnées. D’autres aspects, comme la latence et la gestion des tours de parole, peuvent généralement être optimisés pour atteindre des performances comparables dans les deux approches.

De leur côté, les approches fusionnées regroupent ces étapes dans un seul modèle multimodal. L’audio entre et ressort, avec reconnaissance, raisonnement et génération réalisés dans le même réseau. Plus on ajoute d’outils, plus le modèle doit raisonner pour choisir la bonne séquence d’outils. Dans l’Agent Builder, la description de l’outil précise ce qu’il fait et les champs qu’il retourne. C’est cette information que le modèle de langage utilise pour comprendre le contexte d’utilisation. Une fois défini, les conditions spécifiques d’utilisation de l’outil doivent figurer dans le prompt système de l’agent. Par exemple :

• Description de l’outil pour lookup_order : « Récupère les détails d’une commande client via son ID. Retourne le statut de la commande, les articles achetés, l’adresse de livraison et le numéro de suivi. »
• Instruction dans le prompt système : « Après avoir vérifié l’identité du client, appelez l’outil lookup_order pour récupérer les détails de sa commande. »

Ce design permet aux architectures fusionnées de mieux préserver et restituer la prosodie, car le modèle traite directement la prononciation et l’intonation. Cependant, les modèles fusionnés sont plus difficiles à tester et à contrôler, car les sorties intermédiaires ne sont pas accessibles. Ils reposent aussi souvent sur des LLM plus légers, ce qui limite le raisonnement et l’utilisation d’outils par rapport aux approches en cascade qui peuvent utiliser les modèles les plus puissants disponibles.Guide du Prompt. Dans ce cadre, plusieurs types d’outils peuvent être définis, principalement :

• Outils webhook qui appellent des API externes.
• Outils client qui envoient des requêtes d’outils comme événements via le websocket de conversation.
• Outils système pour des actions intégrées comme les transferts d’appel.
• Outils MCP qui se connectent à des serveurs Model Context Protocol.

Les cinq architectures possiblesvariable dynamique. Ces informations sont stockées sous forme de paires clé-valeur simples, extraites de la réponse de l’outil via des mappings prédéfinis. Une fois définies, ces variables peuvent être réutilisées dans le prompt système, les paramètres d’outils futurs ou les conditions de workflow. Cette boucle de rétroaction donne à l’agent une mémoire de travail qui évolue au fil des interactions.

1. Cascade basique

Une fois l’exécution et l’orchestration en place, il faut savoir comment mesurer la performance.

Dans une architecture en cascade basique, l’audio est transcrit, le LLM génère une réponse textuelle, puis le TTS lit exactement ce texte. Comme chaque étape fonctionne sur du texte brut, les équipes ont une visibilité et un contrôle complets. Les garde-fous peuvent être appliqués au niveau du texte, les appels d’outils et intégrations API sont gérés directement par le LLM, et des logiques déterministes peuvent orienter la conversation et appliquer des règles métier de façon prévisible.

Cependant, l’agent ne reconnaît pas les nuances de la parole comme le ton, le rythme ou l’émotion, ce qui peut limiter le naturel de la conversation.collecte de données et les critères d’évaluation entrent en jeu. La collecte de données permet d’extraire des informations structurées à partir de la transcription pour analyse ou agrégation. Les clients exportent souvent ces données vers leur data lakehouse pour le reporting ou l’enrichissement. Par exemple, un Agent commercial peut extraire automatiquement les informations d’un prospect pour créer ou mettre à jour une fiche dans le CRM. Les critères d’évaluation, eux, déterminent si un appel est considéré comme réussi. Si tous les critères sont remplis, l’appel est marqué comme réussi ; sinon, il est signalé comme échec. Cela garantit que les conversations respectent toujours les standards de qualité et d’intégrité, tout en fournissant un retour rapide. Une fois l’appel terminé et le webhook post-appel déclenché, l’agent traite la transcription finale, y compris les exécutions d’outils et les métadonnées, via un LLM avec tous les points de collecte et critères d’évaluation configurés. Le modèle utilise ce prompt combiné pour déterminer si chaque critère est rempli et pour extraire les données demandées pour analyse. Comme le LLM interprète ces configurations directement dans son prompt, il est important de les formuler clairement et de façon cohérente pour qu’il les comprenne et les applique correctement. Nous recommandons donc les bonnes pratiques suivantes pour rédiger les critères d’évaluation et les descriptions de collecte de données.

Exemples d’usages :

1. Support client une phrase ou une puce courte vaut mieux que plusieurs objectifs dans un même critère.
2. Assistants commerciaux formulez l’objectif pour que le succès ou l’échec soit déterminé à partir de la transcription (ce qui a été dit, ce que l’agent a fait, ce que l’utilisateur a demandé). Évitez les objectifs nécessitant un contexte externe que le LLM n’a pas.
3. Réceptionnistes IA le LLM sait déjà que pour marquer comme réussi l’objectif doit être atteint, comme échec il ne doit pas l’être, et comme inconnu il ne doit pas pouvoir le déterminer à partir de la transcription. L’objectif doit donc être rédigé pour que « atteint » ou « non atteint » soit bien défini ; si c’est ambigu, le modèle risque de pencher vers inconnu ou une mauvaise classification.
4. PNJ pour jeux vidéo et divertissement parfois, de nombreux critères d’évaluation sont envoyés ensemble. Des critères trop longs ajoutent du bruit et peuvent provoquer des hallucinations.
5. Remplacement d’IVR toute explication fournie par le LLM sur la réussite ou non d’un critère sera dans la même langue que la description du critère, il faut donc en tenir compte.

2. Cascade avancée

1. Décrivez précisément ce qu’il faut extraire : la description est le principal signal pour le LLM. Indiquez ce que signifie le champ, dans quelle situation il doit être renseigné, et quoi faire si ce n’est pas clair (ex : « Laissez vide si le client n’a jamais indiqué de date préférée »).
2. Respectez le type attendu : la valeur fournie par le LLM correspondra toujours au type de donnée assigné au point de collecte (ex : booléen, chaîne, entier, etc.). La description doit donc être alignée. Par exemple : « Extraire le nombre d’articles demandés » pour un entier, et « Oui/non si le client a accepté l’offre » pour un booléen.
3. Utilisez des enums si possible : pour les chaînes, si la liste de valeurs est fixe, utilisez enum dans le schéma ; cela contraint le modèle et réduit les sorties invalides.
4. Un objectif d’extraction par item : Ne regroupez pas plusieurs faits non liés dans la même description ; séparez-les pour que chaque item ait une cible d’extraction claire.
5. Gardez les descriptions courtes : Quelques phrases suffisent ; pas besoin de longs paragraphes. La transcription est déjà dans le message utilisateur, donc le schéma + une courte description suffisent.

Les architectures en cascade avancée introduisent un TTS contextuel, où le LLM décide non seulement quoi dire mais aussi comment le dire, en transmettant des instructions comme « dites-le de façon rassurante » ou « répondez avec insistance » au modèle TTS. L’agent parle avec un ton et un style plus réalistes, tout en gardant les mêmes garde-fous, logiques déterministes, utilisation d’outils et auditabilité qu’une cascade basique.

C’est l’approche utilisée dans

Exemples d’usages plus expressifs :

Support client offrent une interface visuelle pour concevoir des parcours conversationnels complexes. Cela produit au final l’objet logique utilisé par l’orchestrateur pour gérer plusieurs sous-agents, outils et transferts sous un identifiant d’agent indépendant. Les Workflows ajoutent des éléments à prendre en compte en plus de ceux des agents indépendants, notamment comment :

• Les prompts système et les objectifs conversationnels des sous-agents interagissent.
• Le passage entre les différents points de transition du graphe est déterminé.

Objectifs de conversation spécialisés

Certaines architectures en cascade transmettent des caractéristiques acoustiques (ex. : prononciation, émotion, ton) de la voix d’entrée directement au LLM sous forme d’embeddings. Cette architecture préserve davantage l’intention originale de l’utilisateur tout en gardant le TTS modulaire. L’utilisation d’outils et les garde-fous restent possibles, mais le bloc ASR+LLM fusionné est plus difficile à auditer qu’un passage de texte classique, et le LLM ne peut plus être remplacé aussi facilement que dans un modèle en cascade.

Sur cette base commune, les Workflows introduisent des sous-agents spécialisés opérant dans un graphe orienté. Chaque sous-agent reçoit un objectif précis et enrichit la configuration de base avec des instructions de prompt, des outils et des sources de connaissances spécifiques à son rôle. Plutôt que de redéfinir tout le contexte, les sous-agents ajoutent leur intention via la composition de prompts et l’extension sélective du contexte. L’historique de conversation est conservé lors des transitions pour maintenir la continuité, mais chaque sous-agent fonctionne avec une vue volontairement limitée du système. Les bases de connaissances et outils sont exposés de façon sélective, créant des silos clairs qui évitent les fuites entre responsabilités. Pour renforcer cette isolation, l’objet orchestrateur est reconstruit à chaque transition comme s’il s’agissait d’un agent indépendant. Cela garantit que l’état du prompt, la configuration et les capacités du sous-agent actif restent entièrement déterministes. Ce design permet aux Workflows de maintenir une cohérence globale tout en favorisant la spécialisation locale, pour un comportement prévisible, une séparation claire des responsabilités et un contrôle précis sur le contexte, la connaissance et les actions à chaque étape de l’interaction.

4. Fusion séquentielle

Piloter les transitions de workflow avec des conditions LLM

Dans les architectures fusionnées séquentielles, un seul modèle multimodal gère la reconnaissance, le raisonnement et la génération vocale. Fonctionnant tour par tour, le modèle écoute jusqu’à la fin de l’intervention de l’utilisateur, puis produit directement l’audio. En traitant l’audio de bout en bout, ces architectures captent naturellement des indices comme la prononciation, le rythme ou l’intonation, ce qui donne souvent une parole plus fluide et expressive.

Le compromis, c’est que les garde-fous sont plus difficiles à appliquer sans couche texte, l’utilisation d’outils est limitée par des cœurs de raisonnement plus légers, et la visibilité est réduite sans sorties intermédiaires claires.

Quand une conversation passe à une nouvelle étape, le système active une version de l’agent adaptée à cette étape. Chaque étape fonctionne avec ses propres instructions ciblées et n’a accès qu’aux connaissances et outils pertinents pour sa mission. Par exemple, une étape de gestion de remboursement peut accéder aux politiques de remboursement sans hériter du contexte d’onboarding ou de triage. Le passage d’une étape à l’autre est régi par des conditions de transition explicites. Ces conditions déterminent quand transférer la responsabilité et permettent un routage naturel au fil de la conversation. Pour maintenir la continuité, l’expérience utilisateur reste fluide lors des transitions, chaque étape héritant du contexte pertinent sans exposer la mécanique du passage. Des garde-fous surveillent aussi les transitions pour éviter les boucles improductives, assurant la stabilité et l’orientation du workflow.

Sécurité et protection

5. Fusion duplex

Garde-fous

Dans les architectures fusionnées duplex, le modèle traite l’entrée et la sortie simultanément. Cela permet d’obtenir un échange très naturel, avec des chevauchements de parole plus authentiques lors de conversations courtes, mais cela ajoute aussi beaucoup de complexité. Les garde-fous sont plus difficiles à appliquer, les interruptions et chevauchements peuvent causer des erreurs, et la visibilité est minimale par rapport aux architectures en cascade.

Gestion des données conforme

Il arrive que des intervenants partagent avec un agent des informations sensibles soumises à des exigences strictes de stockage et de traitement, par exemple des données médicales nécessitant une gestion conforme HIPAA. Pour ces cas, nous proposons le mode Zero Retention (ZRM) au niveau de l’Agent ou de l’Espace de travail. Lorsqu’il est activé, toutes les données d’appel sont traitées uniquement en mémoire et jamais stockées de façon persistante. Une fois l’appel et le traitement terminés, aucune information n’est conservée par ElevenLabs. Les transcriptions, enregistrements audio et analyses ne sont donc pas disponibles dans le tableau de bord Agents, et cette politique s’applique aussi bien aux systèmes clients qu’aux logs internes. Même si les données ne sont pas conservées, elles sont traitées pendant l’appel, et tout webhook post-appel configuré recevra les résultats, permettant aux clients de stocker les transcriptions ou analyses dans leurs propres systèmes si besoin.

Choisir la bonne architecture selon votre usage

Il n’existe pas d’architecture universelle pour les agents conversationnels. Chaque variante a ses forces et ses compromis, de la prévisibilité et du contrôle des modèles en cascade à la prosodie naturelle des modèles fusionnés.

Dans cet article, nous avons vu comment les Agents ElevenLabs gèrent le contexte conversationnel, les outils, l’évaluation et les workflows structurés pour offrir des expériences fiables et en temps réel à grande échelle. À mesure que les clients déploient des agents dans des environnements de plus en plus complexes, nous continuons d’élargir la flexibilité de notre moteur d’orchestration, avec des modèles d’évaluation configurables, des contrôles de transition enrichis et une meilleure visibilité sur la composition des prompts et l’utilisation des tokens à chaque étape.

Notre équipe Forward Deployed Engineering travaille en étroite collaboration avec les clients pour faire évoluer ces capacités au rythme des déploiements réels. La prochaine génération d’Agents offrira encore plus de transparence, de déterminisme et d’adaptabilité, sans compromis sur la faible latence qui rend la conversation en temps réel possible.