DeepSeek V4.1 Flash + Eleven v3 face à la voix full-duplex : comment comparer les architectures

La vraie décision : choisir une architecture, pas opposer des modèles

Choisir entre une chaîne composée de reconnaissance automatique de la parole (ASR), d’un modèle de texte et de synthèse vocale, et un modèle vocal full-duplex ne revient pas à mettre face à face deux modèles interchangeables. Il s’agit de comparer des systèmes dont les composants, les interfaces et les modes d’interaction diffèrent. La première architecture sépare les tâches ; la seconde peut recevoir et produire de l’audio au sein d’une interaction vocale intégrée. La décision doit s’appuyer sur le comportement de la solution complète au cours d’une conversation représentative.

Une chaîne modulaire peut associer DeepSeek V4.1 Flash comme moteur de réponse, un service d’ASR qui convertit la parole entrante en texte et Eleven v3 qui transforme la réponse textuelle en voix. Elle nécessite également une couche de coordination : gestion des tours de parole, maintien du contexte, choix du moment où envoyer chaque requête et acheminement des appels aux outils. Si l’un de ces éléments ralentit ou échoue, l’expérience est affectée, même si les autres composants fonctionnent correctement.

GPT-Live 1 et Gemini 3.8 Live peuvent servir d’alternatives full-duplex, à condition que l’équipe ait accès aux interfaces pertinentes et fixe les versions évaluées. La documentation d’OpenAI présente GPT-Live 1 comme full-duplex, tandis que Google décrit Gemini 3.8 Live comme un modèle destiné à l’audio en temps réel. Ces descriptions justifient leur inclusion parmi les candidats, mais ne prouvent pas qu’ils soient meilleurs pour un cas d’usage donné.

L’hypothèse à tester n’est pas qu’une architecture l’emporte par définition. Une approche modulaire peut offrir davantage de contrôle sur le choix et le remplacement des composants ; une solution intégrée peut éviter certaines transitions entre services. Le résultat dépend de la tâche, de l’implémentation, du réseau, de la langue, des conditions d’accès et des critères utilisés pour juger une conversation réussie.

Le rôle de chaque composant

Dans la chaîne modulaire, DeepSeek V4.1 Flash sert de moteur de réponse textuelle. La documentation de son API décrit une interface de chat qui prend en charge la diffusion en continu de texte et les appels à des outils. Dans une application, le modèle peut recevoir la transcription, le contexte et les consignes, puis produire une réponse ou une demande structurée destinée à l’exécution d’un outil. L’application doit prendre en charge ce processus : un appel à un outil n’est pas, à lui seul, l’outil exécuté ni une conversation vocale achevée.

Le journal des modifications de DeepSeek a annoncé V4.1 Flash et l’identifiant `deepseek-flash`, et mentionne le routage temporaire de certains anciens alias. Pour qu’un essai soit reproductible, il faut donc consigner l’identifiant envoyé, la date, l’environnement et toute configuration pertinente. Ne déduisez pas qu’un alias désigne toujours le même modèle sans vérifier quel service l’a traité au moment de l’évaluation.

Le fait que la documentation décrive une compréhension visuelle native pour DeepSeek V4.1 Flash ne prouve pas que le modèle accepte ou produit de l’audio conversationnel. Le guide consacré à la vision porte sur la modalité image. Dans l’architecture proposée, l’audio entrant doit passer par un système d’ASR, sauf si une autre voie compatible est documentée et évaluée. Présenter la capacité visuelle comme une preuve de prise en charge de l’audio reviendrait à confondre les modalités.

Eleven v3 joue un autre rôle : c’est un modèle de synthèse vocale à partir de texte. Il reçoit du texte pour produire de la voix ; il ne remplace ni le moteur qui décide de la réponse ni le système qui interprète les propos de l’utilisateur. Le fournisseur précise également que le modèle décrit n’est pas destiné à la conversation en temps réel. Avant de comparer les systèmes, vérifiez donc le produit et l’interface effectivement utilisés. Ne partez pas du principe que leur fonctionnement autorise la même interaction progressive qu’une interface vocale full-duplex.

Une architecture full-duplex ne doit pas non plus être considérée comme une boîte noire magique. L’équipe doit fixer le modèle et l’interface, comprendre la gestion des outils et consigner les conditions du service. GPT-Live 1 est décrit comme full-duplex et peut déléguer à un agent backend et à des outils ; Gemini 3.8 Live est documenté comme une solution audio-à-audio dotée de capacités d’interaction en temps réel. Les fonctions exactes disponibles peuvent dépendre de l’interface et des conditions en vigueur : il faut les vérifier au moment de préparer l’essai.

Les configurations à fixer avant les essais

La comparaison doit commencer par deux configurations documentées, et non par des noms de produits. La première est la chaîne modulaire : capture audio, ASR, gestionnaire des tours de parole, DeepSeek V4.1 Flash, exécution éventuelle d’outils et Eleven v3 pour la réponse parlée. La seconde est une configuration full-duplex choisie parmi les candidats disponibles. Si deux modèles full-duplex sont inclus, chacun constitue une configuration distincte et doit disposer de sa propre fiche.

Consignez les identifiants des modèles, les interfaces, les régions ou conditions d’accès lorsqu’elles sont pertinentes, les paramètres réglables, la date de l’essai et les versions du logiciel client. Pour la chaîne modulaire, notez également le fournisseur et la version de l’ASR, la politique de découpage du texte, les règles d’annulation et le mode de synthèse. Pour le système full-duplex, documentez l’envoi et la réception des données, l’activation des outils et les restrictions applicables. Si un détail n’est confirmé ni par la documentation ni par la configuration observée, indiquez qu’il est inconnu plutôt que de le compléter par une supposition.

Utilisez le même corpus de tâches et les mêmes consignes fonctionnelles. Pour chaque exécution, l’audio d’entrée doit provenir du même fichier ou de la même capture, avec des niveaux et des conditions contrôlés. N’obligez pas un système à produire un format que son interface ne prend pas en charge : décrivez les différences et évaluez le parcours qui serait réellement déployé. Vous éviterez ainsi de transformer l’essai en course artificielle entre des implémentations incompatibles.

Un protocole commun pour les conversations, les interruptions et les outils

Le jeu d’essai doit inclure des tâches courtes et des conversations à plusieurs tours. Combinez des questions dont la réponse est connue, des consignes assorties de contraintes, des demandes nécessitant un outil et des requêtes ambiguës qui devraient déclencher une demande de précision. Ajoutez des noms propres, des quantités, des dates et des chiffres prononcés à voix haute. Ces éléments peuvent révéler des erreurs qu’un essai limité à des réponses fluides ne mettrait pas en évidence.

Prévoyez différentes conditions de parole : plusieurs accents pertinents pour le public visé, des rythmes variés, des pauses, des autocorrections et des niveaux de bruit réalistes. Ne supposez pas qu’une liste d’accents représente tous les locuteurs. Décrivez les participants, la manière dont l’audio a été obtenu et les limites de l’échantillon. Pour évaluer la robustesse, répétez les essais avec le même audio dans des conditions comparables, plutôt qu’avec une phrase différente pour chaque fournisseur.

Testez explicitement les interruptions. Par exemple, demandez une longue réponse puis, pendant sa lecture, interrompez le système par une correction ou une nouvelle question. Notez s’il cesse de parler, le temps que cela prend, s’il conserve la nouvelle consigne et s’il reprend correctement le contexte. Le respect des interruptions ne peut pas être déduit d’une mesure isolée de génération de texte ou de synthèse vocale.

Pour les outils, utilisez une tâche dont le résultat est vérifiable, ainsi qu’un service ou des données dont la version est contrôlée. Mesurez si le modèle détermine correctement qu’un outil est nécessaire, s’il transmet des arguments valides, si le système exécute l’opération prévue et si la réponse finale reflète le résultat. Distinguez les défaillances du modèle des erreurs du backend ; sinon, un incident externe risque d’être attribué à tort à la génération.

Répétez les essais un nombre suffisant de fois pour observer la variabilité. Indiquez la médiane et les percentiles de latence, ainsi que le nombre d’exécutions et les conditions. Ne présentez pas une seule tentative comme un résultat général. Un essai à petite échelle ne garantit pas non plus le comportement sous charge, dans une autre région ou dans une autre langue : les conclusions doivent préciser ces limites.

Mesurer l’expérience de bout en bout

Définissez précisément le délai jusqu’au premier audio audible (TTFA, pour « time to first audio ») : par exemple, le temps écoulé entre la fin de l’intervention de l’utilisateur et le premier fragment de réponse qu’une personne peut entendre. Si l’expérience permet de parler pendant que le système écoute, consignez également le début de la capture et les horodatages liés à l’interruption. Le critère doit être identique et mesurable pour toutes les configurations ; documentez la détection du premier audio et la synchronisation des horloges.

Mesurez aussi le délai jusqu’à la réponse finale et, le cas échéant, la durée des pauses et des chevauchements de tours. La latence d’un modèle n’est pas celle du parcours complet. Dans une chaîne, la reconnaissance, la génération de texte, la coordination et la synthèse peuvent s’additionner ; le réseau, les buffers et l’exécution des outils ont également un effet. La documentation d’ElevenLabs distingue la latence d’inférence du TTFA et explique l’effet cumulatif dans une chaîne ASR–LLM–TTS. Cette distinction justifie de mesurer le système en conditions d’utilisation plutôt que d’extrapoler la durée totale à partir d’un chiffre partiel.

Consignez le moment où commence un appel à un outil, celui où il se termine et le temps nécessaire pour recevoir une réponse audible intégrant son résultat. Notez séparément les erreurs de connexion, les limites de service, les nouvelles tentatives, les réponses vides et les annulations. Pour mesurer le taux d’interruptions respectées, définissez à l’avance les critères de réussite : arrêter l’audio, reconnaître le nouveau tour et répondre à la consigne corrigée peuvent constituer des critères différents.

L’évaluation des résultats doit disposer d’une grille distincte des mesures de temps. Vérifiez l’exactitude factuelle, le respect des consignes, l’intelligibilité et la prononciation des noms et des chiffres. Dans la mesure du possible, évaluez la naturalité de la voix à l’aveugle : les personnes qui notent la voix ne devraient pas savoir quelle configuration l’a produite. Ne confondez pas naturalité et exactitude : une voix convaincante peut prononcer clairement une réponse erronée.

Coûts, complexité et points de défaillance

Le coût pertinent n’est pas le prix d’une seule API, mais celui d’une conversation réussie. Pour la chaîne modulaire, comptabilisez l’ASR, la génération de réponse, la synthèse vocale, les outils, l’infrastructure attribuable et les nouvelles tentatives. Ajoutez les exécutions échouées et les tâches qui n’ont pas abouti ; les omettre ferait paraître le coût par réussite plus bas. Pour chaque offre, vérifiez le tarif applicable, les unités facturées, les conditions d’accès et la date. Sans ces informations, il est impossible d’en déduire un coût comparable.

La modularité multiplie les frontières entre composants qu’il faut instrumenter. Une transcription incorrecte peut entraîner une mauvaise réponse ; une réponse correcte peut être mal prononcée ; une interruption peut parvenir trop tard au synthétiseur ; un outil peut terminer son travail après l’annulation du tour par le client. Ce sont des modes de défaillance à éprouver, pas des résultats qu’il faudrait automatiquement imputer à un fournisseur.

Une option full-duplex demande elle aussi du travail d’intégration et d’exploitation. L’équipe doit vérifier l’accès, les quotas, les régions, les interfaces, les outils, l’observabilité et le traitement des erreurs. Une description de produit ne suffit pas à déterminer le coût réel ni la capacité disponible pour un lancement. Il faut confirmer la disponibilité pour le public cible à la date de publication et consigner les limites rencontrées.

Le coût d’exploitation comprend également le temps nécessaire au diagnostic des défaillances, à la mise à jour des composants et à la maintenance des mesures. En principe, une chaîne facilite le remplacement d’un élément sans en changer tous les autres, mais elle impose de gérer les compatibilités et les états entre composants. Une configuration intégrée peut réduire certains points de coordination, mais elle ne dispense ni des essais, ni des journaux, ni des contrôles qualité. Il s’agit de considérations de conception à valider dans l’environnement réel.

Interpréter les résultats sans proclamer de gagnant à l’avance

Si la chaîne modulaire obtient une voix préférée lors d’une évaluation à l’aveugle, mais répond plus lentement et respecte moins bien les interruptions, la décision dépendra du poids accordé à ces facteurs dans le produit. Si elle résout mieux les tâches nécessitant des outils, vérifiez si cet avantage persiste une fois prises en compte la latence et les erreurs du backend. Si un modèle full-duplex est plus rapide lors de l’essai, ce résultat ne s’étend pas automatiquement à un autre réseau, une autre langue, une autre région ou une autre charge.

La modularité peut être envisagée lorsque l’équipe a besoin de contrôler le modèle qui répond, la voix qui synthétise et l’exécution des outils, et qu’elle est prête à instrumenter et à maintenir la coordination. Une solution full-duplex peut être envisagée lorsque l’interaction vocale intégrée est prioritaire et que la configuration disponible répond aux exigences d’accès, de qualité et d’exploitation. Il s’agit d’hypothèses destinées à guider la décision, et non de garanties de supériorité d’une architecture.

Publiez les configurations exactes, le scénario d’évaluation, les définitions des mesures, les données de coût et les exclusions. Faites état de la variabilité et des résultats négatifs. Une comparaison utile permet de reproduire l’essai et de comprendre quel composant explique une différence ; un score global sans ventilation ne révèle pas si le problème vient de la transcription, de la réponse, de la voix, de la gestion des tours, des outils ou du réseau.

La documentation disponible permet de définir le rôle de chaque service et de concevoir une évaluation équitable. Elle ne suffit toutefois pas à déterminer à l’avance quelle configuration offrira la latence totale la plus faible, la meilleure qualité ou le coût le plus bas dans une implémentation donnée. Ces conclusions exigent des mesures effectuées avec des versions identifiées, des tarifs vérifiés et des tâches représentatives de l’usage prévu.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.