Guide de migration vers ElevenLabs Scribe v3 Live : prédiction de tour, keyterms et diarisation en direct

Le risque d'une migration vers Scribe v3 Live, c'est justement qu'elle paraît facile. Vous changez un identifiant de modèle, le prix catalogue ne bouge pas, et vos appels en direct passent par un nouveau modèle vocal sans qu'aucune revue de code ne signale quoi que ce soit. Si le nouveau modèle gère moins bien que l'ancien vos accents, vos noms de produits ou les prises de parole, rien ne casse de façon visible. Les transcriptions dérivent simplement, et un agent commence à mal entendre des numéros de compte ou à couper la parole aux appelants. Voici ce qui change, comment se comportent les nouvelles fonctionnalités, et une grille d'évaluation pour décider à partir de vos propres données.

Ce que Scribe v3 et Scribe v3 Live changent pour les utilisateurs de Scribe v2

Sur le benchmark FLEURS couvrant 102 langues, ElevenLabs indique que Scribe v3 fait passer le taux d'erreur de mots (WER) de 16.94% à 12.38%, ce qu'elle présente comme 27% d'erreurs de mots en moins par rapport à Scribe v2. Pour le temps réel, le blog de lancement affirme que, sur 102 langues, Scribe v3 Live réduit le WER sémantique de 43% et le WER standard de 31% par rapport à Scribe v2 Realtime. Avant de comparer le WER sémantique aux chiffres d'autres fournisseurs, nous vous conseillons de vérifier comment chacun définit cette métrique.

La tarification ne change pas. Scribe v3 est affiché à $0.20 par heure d'audio, comme Scribe v2, et Scribe v3 Live à $0.22 par heure, comme Scribe v2 Realtime. Le coût de base ne vous donne aucune raison de migrer, ni aucune raison d'attendre. Les options payantes sont une autre question.

Comment migrer : remplacer l'identifiant du modèle

Un développeur du projet timbal-ai a ouvert une issue GitHub pour adopter les nouveaux modèles. Il a indiqué que les deux modèles étaient déjà disponibles avec sa clé API et fonctionnaient via son adaptateur STT vocal existant, sans aucune modification de code. Il a aussi reconnu franchement la portée limitée de ce constat. Il l'a décrit comme un smoke test sur un seul extrait synthétique propre, avec des mesures de latence incluant le temps de connexion WebSocket, et a précisé clairement qu'il ne s'agissait pas d'un benchmark.

Une intégration propre nécessite donc probablement un changement de configuration, pas une réécriture. Savoir si la précision s'est améliorée est une tout autre question.

Nous vous conseillons de considérer la référence officielle de l'API Realtime comme la source qui fait foi pour transmettre l'identifiant du modèle et les options de session, plutôt que des extraits de code tiers, car les noms de paramètres peuvent changer d'une version à l'autre.

Faire tourner v2 et v3 en parallèle

N'inscrivez pas le nouvel identifiant en dur. Placez le choix du modèle derrière un feature flag ou un paramètre par tenant, afin que certaines sessions utilisent Scribe v3 Live pendant que les autres restent sur Scribe v2 Realtime. Vous obtenez ainsi une comparaison en conditions réelles et un retour arrière qui se compte en secondes. Enregistrez l'identifiant du modèle avec chaque transcription stockée. Si vous tracez déjà les appels de LLM et d'agents, comme dans notre guide de traçage GenAI avec OpenTelemetry, ajoutez l'identifiant du modèle vocal comme attribut, pour qu'une régression renvoie au modèle qui en est à l'origine.

Checklist après le changement

• [ ] Les paramètres de session sont conservés : format audio, fréquence d'échantillonnage, langue et fonctionnalités optionnelles.
• [ ] Vous savez quelle stratégie de commit est active.
• [ ] La logique de l'agent et les enregistrements stockés utilisent le texte validé (committed), pas les transcriptions partielles.
• [ ] La gestion des erreurs couvre les connexions interrompues, les échecs d'authentification et un repli vers v2.
• [ ] Les tableaux de bord séparent la latence et les taux d'erreur par modèle.

Utiliser commit_strategy=turn_prediction dans les agents vocaux

Dans une session en temps réel, le serveur diffuse des transcriptions partielles qui évoluent à mesure que l'audio arrive. Un commit finalise le segment en cours. Si votre agent attend le texte validé avant de répondre, le moment du commit façonne le ressenti de toute la conversation. Des commits tardifs donnent l'impression d'un agent lent. Des commits trop précoces le font parler par-dessus des personnes qui n'ont pas terminé.

Scribe v3 Live prend en charge commit_strategy=turn_prediction. Selon le guide des stratégies de commit, avec cette stratégie, le serveur valide le segment en cours dès qu'une transcription partielle atteint une turn_probability de 0.9 ou plus. Autrement dit, le serveur prédit si la personne a fini de parler et valide lorsqu'il en est suffisamment sûr.

Nous vous conseillons de comparer la prédiction de tour à l'approche de commit que vous utilisez aujourd'hui, sur les mêmes enregistrements, plutôt que de supposer qu'elle conviendra mieux à vos appelants.

Pendant les tests, enregistrez chaque valeur de turn_probability et chaque événement de commit avec leur horodatage, à côté de ce que la personne a réellement dit. Repérez les commits déclenchés en pleine réflexion et ceux qui arrivent longtemps après la fin de la prise de parole. Commencez par les personnes qui hésitent et celles qui dictent de longs numéros, car ce sont elles qui révèlent le plus vite les problèmes. Pour une méthode structurée de notation, consultez notre carte à horloge commune pour l'évaluation des prises de parole.

Le guide décrit le seuil comme un comportement côté serveur ; nous vous conseillons donc de ne pas compter sur son réglage. Concentrez plutôt vos efforts sur la façon dont votre agent se rattrape lorsqu'un utilisateur continue de parler après un commit.

Keyterms et bibliothèques de keyterms pour le vocabulaire métier

Les modèles vocaux génériques ont tendance à rater les mots qui comptent le plus pour une entreprise : noms de produits, noms de rue, codes postaux, numéros de contrat, noms de médicaments et jargon interne. C'est souvent là que les fonctionnalités de vocabulaire métier montrent leur utilité, à condition de les tester sur vos propres erreurs.

ElevenLabs a publié un exemple tiré de son client Eneco. Selon ElevenLabs, lors de véritables appels clients, l'agent a reconnu correctement les codes postaux néerlandais du premier coup 40% plus souvent, et les numéros de maison 15% plus souvent. Considérez cela comme une illustration du fournisseur, pas comme une prévision pour votre propre vocabulaire.

Pour les vocabulaires plus étendus, il existe keyterm_library. Data Studios relève que la documentation indique qu'une bibliothèque peut contenir jusqu'à 10,000 termes, alors qu'une autre ligne de la même page mentionne 100,000. Si votre conception repose sur une très grande bibliothèque, confirmez d'abord la limite réelle auprès d'ElevenLabs.

Le keyterm prompting est une option payante, affichée à $0.05 par heure sur la page de tarification de l'API ; mieux vaut donc sélectionner soigneusement les termes de la bibliothèque plutôt que d'y ajouter tout ce que vous avez. Une boucle simple fonctionne bien :

1. Récupérez de vraies transcriptions d'appels et repérez les termes que le modèle a mal transcrits.
2. Regroupez les erreurs par type, par exemple noms, codes alphanumériques, adresses et termes produits.
3. Ajoutez les termes qui échouent souvent et qui ont un impact sur le résultat métier.
4. Relancez le même audio avec et sans la bibliothèque.
5. Révisez la bibliothèque à intervalles réguliers et supprimez les termes qui n'apportent plus rien.

Si vos appelants changent de langue en cours de conversation, nous vous conseillons de tester sur des enregistrements qui contiennent réellement de l'alternance de langues, et de vérifier dans la documentation des modèles et la référence de l'API comment les éventuelles options multilingues traitent vos paires de langues, plutôt que de faire des suppositions.

Diarisation en direct : ce qu'elle permet et jusqu'où lui faire confiance

L'étiquetage des locuteurs en direct permet de produire des notes de réunion au fil de l'eau avec les noms associés, des outils d'assistance aux agents qui ne réagissent qu'au client, et un contrôle qualité des appels qui distingue l'agent du client pendant que l'appel est encore en cours.

ElevenLabs indique que, sur la partie anglaise de son jeu de données réelles en 16 langues, Scribe v3 Live affiche un taux d'erreur de diarisation de 3.1%, contre 5.9% à 7.3% pour les autres modèles temps réel testés. En traitement par lots, l'entreprise affirme que Scribe v3 commet 17% d'erreurs de diarisation en moins que Scribe v2 sur les enregistrements comportant trois locuteurs ou plus, une difficulté fréquente en diarisation.

Prenez ces chiffres avec du recul. AlphaSignal note que les résultats de diarisation proviennent d'un jeu de données interne distinct couvrant des réunions, des appels d'agents et des messages vocaux dans 16 langues, et que ces résultats internes n'ont pas été vérifiés de manière indépendante. ElevenLabs dit prévoir de publier ce jeu de données en open source.

Testez les cas difficiles : paroles qui se chevauchent, voix qui se ressemblent, personnes qui rejoignent l'appel en retard et longs passages où une seule personne domine. Nos vérifications du passage entre locuteurs et transcription en cas de chevauchement de parole s'appliquent ici aussi.

Tarification de Scribe v3 Live, options et factures prévisibles

*Remarque sur le tableau : les tarifs des options sont les tarifs API affichés. Confirmez les tarifs des options temps réel applicables à votre forfait.*

C'est avec les options que la facture grimpe. Data Studios estime que les options peuvent augmenter la facture par lots de 60% et la facture en direct d'environ 91%, et conseille de ne les activer que là où le vocabulaire personnalisé ou la mise en forme automatique suppriment du travail manuel.

Deux habitudes aident. D'abord, activez les options par flux de travail, et non sur l'ensemble du compte. Une ligne de gestion des sinistres qui entend des numéros de contrat toute la journée peut justifier les keyterms, alors qu'un simple enregistreur de réunions générales n'en a peut-être pas besoin. Ensuite, suivez le coût par heure utile : l'audio qui a produit une transcription exploitable sans correction manuelle. Une heure moins chère qui demande encore un nettoyage humain n'est pas vraiment moins chère.

Conformité et options de conservation des données

Pour les clients Enterprise, ElevenLabs propose un Zero Retention Mode. La documentation précise que, dans ce mode, la plupart des données des requêtes et des réponses sont supprimées immédiatement une fois la requête terminée.

Notez les mots « la plupart ». Lisez la page pour savoir ce qui est exclu et consignez-le dans votre analyse d'impact relative à la protection des données. Si vous traitez des données de santé, demandez directement à ElevenLabs si un Business Associate Agreement HIPAA est disponible avec votre forfait et s'il couvre les fonctionnalités temps réel que vous prévoyez d'utiliser.

Vérifiez aussi vos propres systèmes. La suppression côté fournisseur ne sert pas à grand-chose si votre application, vos journaux ou votre entrepôt analytique conservent indéfiniment l'audio brut et les transcriptions, y compris les journaux de débogage que votre évaluation va générer.

Avant de tester : pourquoi les chiffres du fournisseur ne suffisent pas

Tous les chiffres de précision des supports de lancement sont communiqués par le fournisseur, et les propres pages d'ElevenLabs ne concordent pas entièrement. Le blog cite une réduction de 43% du WER sémantique sur 102 langues, tandis que la documentation des modèles indique que, sur FLEURS et 73 langues, Scribe v3 Live présente un WER sémantique inférieur de 44% à celui de Scribe v2 Realtime. Citez une seule source avec précision au lieu de les mélanger. Les scores ne sont comparables que si l'on connaît le protocole qui les sous-tend, comme nous l'expliquons dans pourquoi les scores de benchmark ont besoin de protocoles.

Le benchmark a lui aussi ses limites. Comme le souligne AlphaSignal, FLEURS contenant de la parole lue et propre, ses résultats de WER ne prouvent rien sur les performances lors d'appels bruyants ou de conversations où les voix se chevauchent beaucoup.

Les moyennes masquent aussi de fortes variations d'une langue à l'autre. ElevenLabs annonce pour Live des gains de 77% pour le grec, 54% pour le danois, 45% pour le croate et 36% pour l'hindi. En traitement par lots, elle annonce 42% pour l'allemand, 35% pour l'espagnol et 23% pour l'anglais. Si votre trafic est majoritairement en anglais, votre gain pourrait être nettement inférieur à la moyenne multilingue.

Des signaux indépendants existent, mais ce sont des instantanés. DEV Community a rapporté que, sur le classement Artificial Analysis pour l'audio enregistré, consulté le 12 novembre, Scribe v3 se classait deuxième sur 64 modèles avec 1.9% d'erreurs de mots, derrière Alibaba Cloud Fun-Realtime-ASR-preview à 1.7%. Un classement sur audio enregistré ne dit rien de direct sur le comportement en temps réel avec votre trafic. C'est pourquoi le test ci-dessous s'effectue sur votre propre audio.

La grille Swap-Safe : tester Scribe v3 Live sur votre propre audio

La grille Swap-Safe (Swap-Safe Scorecard) est un plan en sept étapes qui aboutit à un seul tableau : le même audio, les deux modèles, six lignes. Remplissez les deux colonnes de résultats, et convenez de la règle de décision avec les parties prenantes avant que quiconque ne voie les résultats.

Règle de décision : v3 Live ne l'emporte que s'il améliore les lignes liées à votre résultat métier sans dégrader les interruptions ni le coût par heure utile.

Étape 1 : constituer un jeu d'évaluation représentatif. Échantillonnez du trafic réel, y compris des appels bruyants, des accents variés, des paroles croisées, des termes métier et toutes les langues que vous servez. Obtenez le consentement nécessaire et appliquez vos règles de conservation au jeu de données lui-même.

Étape 2 : rédiger les références et figer les lignes. Créez des transcriptions et des étiquettes de locuteurs de référence pour un sous-ensemble, et fixez les métriques avant le début des tests.

Étape 3 : faire tourner les deux modèles en parallèle. Envoyez le même audio aux deux modèles avec des paramètres identiques. Recommencez ensuite avec les keyterms activés, afin de distinguer le gain du modèle de celui de l'option.

Étape 4 : traduire le WER en impact métier. ElevenLabs propose un repère utile : une réunion d'une heure à 150 mots par minute représente environ 9,000 mots, donc l'écart entre un WER de 4% et de 2% correspond à 180 mots erronés, soit trois pour chaque minute de parole. Faites le même calcul pour la durée de vos propres appels, et pondérez les erreurs sur les entités qui déterminent les résultats.

Étape 5 : mesurer le comportement de l'agent de bout en bout. Avec la prédiction de tour activée, suivez les interruptions, le délai de réponse et la capacité à se rattraper lorsque les utilisateurs continuent de parler. Une transcription plus propre qui dégrade le ressenti de la conversation n'est pas une victoire.

Étape 6 : utiliser les benchmarks publics comme simple contrôle de cohérence. ElevenLabs indique que Scribe v3 abaisse le WER sur Earnings-22, un corpus d'appels financiers en anglais avec accents, de 5.99% à 3.91%, et sur VoxPopuli, un corpus de discours du Parlement européen, de 2.13% à 1.71%. Vérifiez dans le blog de lancement si ces chiffres concernent le modèle par lots ou le modèle Live avant de les utiliser comme référence temps réel.

Étape 7 : déployer progressivement. Basculez le trafic par tenant ou par pourcentage, surveillez les lignes de la grille sur des tableaux de bord en direct, et conservez un retour arrière vers v2 en un seul interrupteur jusqu'à ce que le nouveau modèle ait tenu sur un cycle d'activité complet.