Scribe v2 dans les benchmarks vocaux : ce que comparent les scores et ce qui manque pour les reproduire

Une revendication de leadership doit s’appuyer sur un protocole

ElevenLabs a présenté Scribe v2 en affirmant qu’il obtenait le WER le plus bas dans les benchmarks du secteur. Il s’agit d’une déclaration du fournisseur, et non d’une conclusion indépendante que l’on peut accepter sans connaître les tests comparés, les versions utilisées et les règles appliquées. La page de lancement permet d’attribuer correctement cette affirmation, mais elle ne nomme pas les benchmarks précis qui l’étayent et ne fournit pas de protocole suffisant pour refaire le calcul.

Cela ne prouve pas que l’affirmation est fausse. Cela signifie qu’avec les informations documentées sur cette page, un lecteur externe ne peut pas reconstituer les audios utilisés, la taille de l’échantillon, la préparation des transcriptions de référence ni les autres systèmes inclus. En l’absence de ces précisions, « le WER le plus bas » doit être compris comme une déclaration dont la portée n’est pas établie publiquement dans cette source, et non comme la preuve d’une supériorité universelle.

Il faut également distinguer cette déclaration de lancement d’une évaluation indépendante : Artificial Analysis publie AA-WER v2.0, un benchmark qui fournit des résultats pour Scribe v2. Cette évaluation constitue un point de référence concret à examiner, mais son existence ne vérifie pas automatiquement les benchmarks auxquels ElevenLabs fait allusion. Chaque résultat dépend de son propre jeu de données, de son protocole et de sa date d’exécution.

Ce que mesure le WER — et ce qu’il ne mesure pas

Le WER, ou taux d’erreur sur les mots, compare une transcription automatique à une transcription de référence. Il compte les substitutions, les suppressions et les insertions par rapport au texte de référence, puis exprime leur total comme une proportion des mots de ce texte. C’est un indicateur utile pour résumer des divergences, mais il ne mesure pas à lui seul l’utilité d’une transcription ni la gravité pratique de chaque erreur.

Deux systèmes peuvent obtenir le même score tout en commettant des erreurs différentes. Confondre un nom propre peut coûter plus cher dans une réunion que supprimer une hésitation ; pourtant, une métrique agrégée ne pondère pas les erreurs en fonction du contexte. Le WER ne renseigne pas non plus directement sur la latence, la stabilité des résultats en direct, la diarisation, la lisibilité ou le coût. Ces dimensions nécessitent des mesures et des évaluations supplémentaires.

Le résultat dépend aussi de ce qui est considéré comme un mot et de la normalisation appliquée à la référence et à la sortie du système avant comparaison. Les différences de casse, de ponctuation, d’écriture des nombres, de contractions ou de mots d’hésitation peuvent modifier le décompte si les règles ne sont pas communes. Le plan d’évaluation OpenASR de NIST documente la normalisation des références ; publier la règle appliquée fait donc partie du protocole et ne relève pas d’un simple choix éditorial.

L’unité de comparaison compte également. Une référence peut découper la parole différemment de la transcription du modèle. Si le système traite des segments, si ceux-ci sont concaténés ou si certaines portions de l’audio sont exclues, la procédure peut modifier les erreurs prises en compte. Sans définition du corpus, de la référence, de la normalisation et de la segmentation, un chiffre ne permet donc pas de savoir précisément ce qui a été mesuré.

Le corpus définit la portée de la conclusion

Un score résume le comportement d’un système sur un jeu de données donné, et non sur tous les audios qu’une organisation pourrait traiter. Le choix des enregistrements, leur durée, leur langue, leurs accents, les conditions acoustiques et les types de parole délimitent la population d’exemples représentée. Une moyenne peut masquer des écarts entre langues ou conditions si les résultats détaillés et le nombre d’exemples de chaque groupe ne sont pas publiés.

FLEURS fournit un exemple de contexte d’évaluation multilingue : l’article original décrit un jeu de données couvrant 102 langues et présente son objectif pour l’évaluation de représentations vocales. Le fait qu’un benchmark comporte plusieurs langues ne signifie pas qu’il couvre de manière exhaustive tous les usages réels, ni qu’une moyenne entre langues représente les besoins de chaque équipe. Pour interpréter un résultat, il faut savoir quelles langues ont été évaluées, comment elles ont été pondérées et combien d’exemples ont contribué à chaque score.

AA-WER v2.0 identifie plusieurs jeux de données dans son évaluation et distingue AA-AgentTalk, qui est propriétaire, de VoxPopuli et Earnings22. Cette distinction est importante : un benchmark peut réunir des corpus dont les conditions et la disponibilité diffèrent. La présence de données à accès limité réduit la possibilité, pour des tiers, de reproduire l’intégralité de l’évaluation à l’identique, même s’ils peuvent étudier le protocole publié ou refaire certaines parties à partir de données accessibles.

La licence des enregistrements influe également sur la reproductibilité. Un jeu de données peut être connu et décrit sans pour autant pouvoir être redistribué ou utilisé librement pour répéter un test. Si les fichiers ne peuvent pas être partagés, la documentation devrait préciser comment l’accès a été obtenu, quel sous-ensemble a été utilisé et quels artefacts alternatifs sont disponibles pour permettre l’audit de la comparaison.

Configuration, prompting et variantes du produit

Le nom d’un modèle ne suffit pas à identifier une exécution reproductible. Pour comparer un score, il faut au minimum disposer de l’identifiant exact du modèle et de la date d’accès ou d’exécution, ainsi que des paramètres pertinents. Les services peuvent être mis à jour ; une évaluation effectuée à une date donnée ne décrit donc pas nécessairement le comportement d’une version ultérieure. La documentation sur les capacités permet de distinguer les produits, mais ne révèle pas à elle seule la configuration historique d’un test de lancement.

Il faut aussi préciser si le keyterm prompting a été utilisé. La documentation d’ElevenLabs décrit le paramètre keyterms pour l’API batch. Fournir des termes connus peut orienter la reconnaissance d’un vocabulaire spécifique ; une évaluation menée avec ces informations n’est donc pas directement équivalente à une évaluation sans elles. Pour interpréter le résultat, il faut publier les termes fournis, les critères de sélection et indiquer si un avantage contextuel comparable a été accordé à tous les systèmes évalués.

Scribe v2 et Scribe v2 Realtime ne devraient pas être traités comme une seule entrée de benchmark sans préciser quel produit a été évalué. La documentation d’ElevenLabs les distingue dans son offre de transcription. Un test portant sur de l’audio enregistré traité en mode batch et un test de transcription en direct correspondent à des conditions différentes : dans ce dernier cas, l’arrivée progressive de l’audio et la latence peuvent compter en plus de la précision finale. Mélanger les résultats des deux modes rend une classification unique difficile à interpréter.

La méthodologie d’Artificial Analysis distingue elle aussi les évaluations batch et streaming. Cette séparation justifie concrètement que chaque score indique le mode utilisé. Elle ne permet pas, à elle seule, de déduire quel mode correspond à chacune des affirmations de la page de lancement d’ElevenLabs ; cette information devrait accompagner le score concerné.

Quand deux scores sont-ils comparables ?

La comparaison la plus solide utilise les mêmes fichiers audio, les mêmes références et les mêmes règles de notation. Elle maintient également des conditions équivalentes en matière de langue, de segmentation et d’accès au contexte. Si les fournisseurs reçoivent des consignes ou des vocabulaires différents, ou si un système traite des segments alors qu’un autre reçoit des enregistrements complets, le résultat peut refléter ces différences autant que les capacités de reconnaissance.

En pratique, il n’est pas toujours possible de tester tous les services dans des conditions parfaitement identiques. Dans ce cas, la bonne approche consiste à documenter les écarts et à limiter la portée de la conclusion. Un benchmark peut orienter une évaluation sans permettre une comparaison causale stricte entre modèles. Le problème apparaît lorsqu’un chiffre est présenté sans les conditions nécessaires pour distinguer les performances du système de l’effet du protocole.

Artificial Analysis publie une méthodologie pour son benchmark de conversion de la parole en texte ainsi qu’un tableau comparatif non streaming. Ces sources permettent de situer le score de Scribe v2 dans le cadre d’une évaluation précise. Elles ne transforment pas automatiquement la position obtenue dans ce cadre en affirmation valable pour tous les benchmarks, toutes les langues, tous les genres audio ou toutes les variantes en temps réel. Une position dans un tableau répond aux règles et aux participants de ce tableau.

Ce qui peut être reproduit et ce qui reste incertain

Les sources publiques identifiées permettent de décrire la déclaration de lancement comme une affirmation d’ElevenLabs et de vérifier l’existence d’une évaluation AA-WER v2.0 qui inclut un résultat pour Scribe v2. Il est également possible de consulter la présentation de FLEURS, la normalisation prévue par NIST, la méthodologie d’Artificial Analysis et la documentation d’ElevenLabs sur les keyterms et les modèles de transcription. Ces éléments sont utiles, mais ils ne constituent pas un protocole unique qui permettrait de reproduire toutes les affirmations de performance.

La principale incertitude concerne les benchmarks précis auxquels faisait référence la page de lancement lorsqu’elle attribuait à Scribe v2 le WER le plus bas. La source fournie ne les identifie pas et ne présente pas le protocole correspondant. Elle ne permet pas non plus d’établir la version exacte du modèle exécutée, l’éventuel recours au prompting, la normalisation appliquée ou le traitement des segments. Il serait imprudent de combler ces lacunes en supposant que la configuration était identique à celle d’une évaluation ultérieure.

L’existence d’un tableau comparatif indépendant ne résout pas toutes ces questions. Pour reproduire intégralement un benchmark, il faut disposer des artefacts et des conditions du test ; l’accès limité à certains jeux de données propriétaires peut empêcher des tiers de répéter l’évaluation. Si le responsable ne publie que des résultats agrégés, il convient de vérifier qu’il fournit aussi des résultats par corpus ou par condition et explique la pondération appliquée : une moyenne ne remplace pas ces informations.

Liste minimale pour publier un benchmark de reconnaissance vocale

Un benchmark utile à des tiers doit permettre de comprendre le chiffre autant que la démarche qui y a conduit. Publier un classement final ne suffit pas : les lecteurs doivent pouvoir déterminer si le corpus correspond à leur cas d’usage, si les règles sont cohérentes et si une répétition est envisageable. La liste ci-dessous ne garantit pas que deux services fonctionnent dans des conditions identiques, mais elle rend visibles les différences qui limitent la comparaison.

L’incertitude doit elle aussi être communiquée. Les résultats dépendent de l’échantillon et peuvent varier d’un sous-ensemble à l’autre. Publier le nombre d’exemples et les résultats détaillés permet d’évaluer ces variations ; si une marge ou un intervalle est fourni, la méthode de calcul doit être expliquée. Sans ces informations, un faible écart entre deux scores ne devrait pas être automatiquement transformé en conclusion ferme sur le meilleur système.

Conclusion : considérer le score comme un indicateur, pas comme une garantie

Les scores publiés peuvent aider à choisir des candidats pour un test interne, mais ils ne garantissent pas les performances dans une organisation donnée ni sur un type d’audio particulier. L’affirmation d’ElevenLabs concernant le WER le plus bas doit rester attribuée à l’entreprise ; il ne faut pas en élargir la portée sans identifier les benchmarks et protocoles concernés. AA-WER v2.0 fournit une évaluation identifiable de Scribe v2, mais ses conclusions se limitent à ce benchmark et à ses conditions.

Pour décider d’une migration, une équipe devrait tester des échantillons représentatifs de ses langues, de ses enregistrements, de ses noms propres et de ses conditions acoustiques, appliquer des règles de référence cohérentes et évaluer séparément les fonctions importantes pour son flux de travail. Si la transcription en direct est nécessaire, elle doit évaluer la variante et les métriques correspondant à ce mode, plutôt que d’extrapoler à partir d’un test batch.

La conclusion prudente n’est ni que Scribe v2 est le grand gagnant, ni que les chiffres sont dépourvus de valeur. Un WER n’est informatif avec rigueur que s’il est accompagné du corpus, de la version, de la configuration et des règles de calcul. Lorsque ces données manquent, le score peut servir d’indice, mais pas de comparaison reproductible ni de garantie des résultats futurs.

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.