Précision de la transcription IA : pourquoi les benchmarks des éditeurs mentent, et comment nous testons vraiment les modèles

Si vous cherchez à savoir quel modèle de reconnaissance vocale est le plus précis, le chiffre de benchmark publié est le mauvais endroit où regarder. Le score de précision affiché par un éditeur est un résultat optimisé sur un jeu de données propre, lu à voix haute — il ne vous dit presque rien de la façon dont le modèle se comporte sur l'audio que vous avez réellement : un test produit truffé de noms de marques et de jargon, une réunion où deux personnes se coupent la parole, un accent prononcé, un créateur qui passe sans cesse d'une langue à l'autre.

Je dirige Subanana, un outil de reconnaissance vocale par IA. Nous faisons passer chaque transcription par une chaîne de modèles évalués, et nous réévaluons cette chaîne en permanence. Cet article explique comment nous testons — la méthodologie, les critères et les résultats réels de l'une de nos propres campagnes d'évaluation — et pourquoi nous avons cessé de nous fier aux scores de précision publiés par les éditeurs pour prendre ces décisions.

L'essentiel

• Les benchmarks de précision des éditeurs (un score WER unique, « 98 % de précision ») relèvent surtout de l'optimisation pour le classement (le benchmark-maxing) — ils sont mesurés sur de l'audio propre, scénarisé, à locuteur unique, qui n'a rien à voir avec de vrais enregistrements multilingues, accentués ou à plusieurs voix.
• Nous ne choisissons donc pas les modèles d'après leurs chiffres publiés. Nous les testons sur notre propre audio réel et difficile et nous jugeons le résultat comme le ferait un relecteur humain : a-t-il corrigé les mots mal entendus, se lit-il comme une langue écrite propre, et — surtout — n'a-t-il pas modifié les faits ?
• Lors d'une vraie campagne d'évaluation, un petit modèle rapide a battu notre modèle de production, plus lourd (environ 92 % de préférence du juge, à peu près 13× plus rapide). Plus gros et plus lent ne rimait pas avec plus précis.
• L'échec qui résume tout : un modèle a réécrit en silence le capteur d'appareil photo « LYT-828 » en « LYT-808 » — une phrase impeccable à la lecture, mais factuellement fausse, et invisible pour un score WER.
• Vous évaluez un outil vous-même ? Testez votre pire audio réel — les accents, les chevauchements de voix, le jargon, les changements de langue — observez le calage temporel à l'écran, et traquez la corruption factuelle, pas le chiffre du classement.

Pourquoi les benchmarks de transcription des éditeurs sont-ils trompeurs ?

Un taux d'erreur sur les mots (WER, Word Error Rate) ou un pourcentage de précision publié est un chiffre unique, produit dans des conditions choisies par l'éditeur. Trois choses le rendent quasi inutile pour choisir un modèle de production :

• Le jeu de test est propre. L'audio de benchmark est généralement scénarisé, à locuteur unique, enregistré dans une pièce silencieuse, dans une langue à fortes ressources. Le vrai audio n'est rien de tout cela.
• La métrique est grossière. Le WER compte de la même manière les substitutions, les insertions et les suppressions. Or, se tromper sur un numéro de modèle (un « Vivo X30 » qui devient un « Vivo X90 ») est une erreur catastrophique, tandis qu'une virgule oubliée est sans conséquence. Le WER les note à l'identique.
• C'est le tableau de scores de l'éditeur lui-même. Chaque laboratoire publie la configuration où son modèle paraît le meilleur. Vous lisez le record, pas le résultat attendu.

Rien de tout cela n'est malhonnête à proprement parler. C'est simplement optimiser pour le classement plutôt que pour votre cas d'usage. Aussi, lorsque nous évaluons des modèles, nous ne citons les chiffres publiés de personne. Nous faisons tourner le modèle sur l'audio réel, désordonné et multilingue que nos utilisateurs téléversent vraiment, et nous jugeons le résultat sur ce qui compte pour un sous-titre ou une transcription finie.

Voilà toute la philosophie : la précision n'est pas un nombre qu'un éditeur vous tend. C'est quelque chose que vous mesurez sur votre propre cas d'usage — sans quoi vous ne la connaissez pas vraiment.

Ce que « précision » veut vraiment dire pour un sous-titre

Quand la plupart des gens parlent de « précision de transcription », ils confondent deux tâches totalement différentes :

1. La reconnaissance vocale (STT / ASR) — transformer l'audio en texte brut horodaté. C'est là que vit le WER.
2. La mise au propre du texte — transformer ce texte ASR brut et désordonné en un sous-titre publiable : corriger les mots mal entendus, convertir le phrasé oral en une forme écrite propre, restaurer l'espacement et la ponctuation, supprimer les hésitations, et surtout ne pas modifier les faits.

Les deux étapes peuvent échouer, et elles échouent différemment. Un modèle peut produire un excellent texte brut et tout de même livrer des sous-titres inutilisables parce que le calage temporel dérive. Un autre peut avoir un horodatage parfaitement aligné et néanmoins massacrer un nom de marque. Un pourcentage de précision unique ne peut capturer rien de tout cela — c'est précisément pourquoi nous testons chaque étape séparément et qualitativement.

La suite de cet article parcourt les deux : d'abord l'étape de mise au propre du texte, pour laquelle nous disposons d'une évaluation structurée avec de vrais chiffres que nous pouvons partager, puis l'étape de STT brute, où nos constats sont délibérément qualitatifs.

Comment nous testons l'étape de mise au propre : un modèle juge sur de l'audio réel

Voici la méthodologie d'une vraie campagne d'évaluation menée en avril 2026. La cible était le modèle qui assure la passe de mise au propre par-dessus la sortie ASR brute — l'étape qui transforme une transcription machine grossière en un sous-titre publiable. Cette passe accomplit deux tâches distinctes, et nous testons chacune séparément :

• Corriger les erreurs — rectifier les mots et les nombres que la reconnaissance vocale a mal restitués : un nom de marque mal entendu, un numéro de modèle erroné, une négation oubliée.
• Mettre au propre la formulation — transformer un phrasé oral et familier en une langue écrite propre, restaurer la ponctuation et l'espacement, et élaguer les mots de remplissage — sans changer le sens. (Dans certaines langues, l'écart entre l'oral et l'écrit est considérable et demande une véritable conversion.)

(Périmètre, dit clairement : cette campagne évalue cette passe de mise au propre du texte, et non la reconnaissance vocale brute. Les deux sont testées différemment.)

• Le jeu de données était un petit ensemble d'échantillons réels, composé à dessein. Dans notre cas, il s'agissait de parole mêlant deux langues au sein d'un même passage, choisie non pour sa taille mais pour les cas qui mettent les modèles en échec : script mixte, termes techniques et numéros de modèle, passages très ponctués, fragments courts et fragiles, longues séquences. La langue précise importe moins que le principe : une poignée d'échantillons vraiment retors, issus de votre propre cas d'usage, fait remonter plus d'échecs réels qu'un millier d'échantillons propres.
• La comparaison était par paires. Pour chaque échantillon, la sortie de chaque modèle candidat a été confrontée à notre référence de production actuelle, et un modèle distinct, servant de juge, a désigné la meilleure des deux — ou prononcé l'égalité.
• Les critères étaient six éléments qui définissent réellement un bon sous-titre, notés indépendamment pour chaque échantillon :
  • Correction des mots mal entendus — a-t-il corrigé ce que la reconnaissance vocale avait mal restitué ?
  • Mise au propre de l'oral vers l'écrit — a-t-il transformé la parole familière en une langue écrite propre ? (Chaque langue a sa propre façon de transformer la parole en prose.)
  • Suppression des mots de remplissage — a-t-il éliminé les « euh » et les faux départs ?
  • Préservation des faits — a-t-il laissé intacts les noms, les nombres et les faits ?
  • Interdiction des annotations — a-t-il évité d'inventer des notes entre crochets que le locuteur n'a jamais prononcées ?
  • Exhaustivité — a-t-il vraiment nettoyé le texte, ou laissé des erreurs évidentes ?

Nous avons soumis 31 configurations de modèles à cette campagne. Seules 17 étaient même exécutables — les autres ont calé dès le contrôle préalable, à cause d'identifiants de modèle invalides, de délais d'attente dépassés ou de réglages non pris en charge, ce qui est en soi un résultat utile : un modèle que l'on ne peut pas appeler de façon fiable n'est pas un candidat, quel que soit son score de benchmark.

C'est une méthodologie de qualité documentaire, pas une impression au doigt mouillé. Chaque chiffre ci-dessous provient de la sortie même de cette campagne, et nous le partageons parce qu'il est à nous — pas parce qu'un éditeur nous a affirmé que son modèle était bon.

Ce que nous avons trouvé : les chiffres de notre propre campagne

Quelques résultats se sont démarqués. Tous les chiffres proviennent de notre propre évaluation ; ce sont des taux de préférence du juge et des vitesses sur la tâche de mise au propre des sous-titres — pas un pourcentage de précision STT de qui que ce soit.

Trois enseignements tirés de nos données :

• La meilleure préférence moyenne du juge sur l'ensemble de la campagne était d'environ 92 % — une configuration légère de Gemini 3.1 Flash Lite que le juge a préférée à notre référence de production sur la grande majorité des échantillons. Un petit modèle rapide a battu le modèle par défaut, plus lourd.
• La configuration exécutable la plus dépouillée était environ 13× plus rapide que la référence — à peu près 19 secondes contre environ 4 minutes — pour une fraction du coût, et elle l'a tout de même emporté nettement sur la correction des erreurs. Plus gros et plus lent n'était pas meilleur.
• Plafonner le budget de « réflexion » du modèle a été le plus grand gain d'efficacité à lui seul. La référence consacrait l'écrasante majorité de son budget à des jetons de raisonnement dont elle n'avait, pour l'essentiel, pas besoin. Désactiver ce budget de raisonnement sur la même famille de modèles a produit une sortie que le juge a jugée aussi bonne ou meilleure, environ un ordre de grandeur plus vite et de façon bien plus économe. Pour une tâche contrainte et bien spécifiée comme la mise au propre de sous-titres, le raisonnement étendu était surtout de l'effort gaspillé.

Vous remarquerez qu'aucun de ces chiffres n'est un « pourcentage de précision ». Ce sont des scores de préférence relatifs émis par un modèle juge, sur notre audio, face à notre propre référence. C'est une affirmation délibérément plus modeste que « 98 % de précision », et bien plus utile pour choisir réellement un modèle.

L'échec qui prouve pourquoi un test jugé par l'humain, ancré dans le cas d'usage, est indispensable

Voici l'exemple qui résume tout l'argument. Un modèle candidat, en mettant au propre un test de téléphone (l'un de nos extraits mêlant deux langues), a fait ceci :

Source :    T-828 的 sensor 啦。那這顆 LYT-828 呢，我們，我們又來……
Référence : ……呢粒 LYT-828 呢……
Candidat :  ……嗰呢粒 LYT-808 呢……

Le modèle a réécrit en silence le capteur d'appareil photo « LYT-828 » en « LYT-808 ». Nous avons observé la même classe d'erreur ailleurs dans la campagne, où un autre candidat transformait un « Vivo X30 Pro » en « Vivo X90 Pro ».

Le texte se lit parfaitement. La grammaire est propre, la ponctuation est restaurée, le phrasé oral est rangé en une forme écrite correcte. Un score WER enregistrerait à peine le changement — un chiffre sur un long passage. Pourtant, c'est une corruption factuelle : un autre produit, un autre capteur. Pour un testeur de matériel, c'est le genre d'erreur qui vaut une demande de correction dans les commentaires.

La leçon ne porte sur aucune langue en particulier. Elle est que les erreurs de transcription les plus dangereuses sont les fluides — une phrase impeccable à la lecture où un terme technique, un numéro de modèle ou un nom propre a été silencieusement remplacé. Elles se cachent exactement dans l'audio dense en jargon et à script mixte que les vrais utilisateurs enregistrent, quelle que soit la langue. Aucun benchmark de précision publié n'aurait détecté cela ; ce n'est apparu que parce que nous avons jugé la sortie comme l'aurait fait un relecteur humain — face à la question précise « le modèle a-t-il changé un fait ? » — sur le type d'audio où cet échec se produit réellement. C'est toute la différence entre courir après le classement et tester sur son cas d'usage réel.

Cela montre aussi pourquoi la « préservation des faits » est l'un de nos six critères, et pourquoi nous la lisons comme un signal comparatif plutôt que comme un décompte littéral d'erreurs. Au cours de la même campagne, un modèle a rendu « quatre-vingt-dix pour cent » de deux façons également correctes — sémantiquement identiques, sans la moindre erreur. Une métrique naïve aurait signalé la reformulation et manqué l'inversion du capteur. Le jugement, sur le bon matériau, met cet ordre de gravité au bon endroit.

Et l'étape de reconnaissance vocale brute ?

Pour l'étape de STT elle-même — audio en entrée, texte horodaté en sortie — nos constats sont volontairement qualitatifs. Nous ne publions aucune table WER, ni la nôtre ni celle de quiconque, parce que les échecs qui comptent ici sont mal capturés par un taux d'erreur unique. Ce qui casse un modèle STT en production, c'est généralement l'un de ces problèmes : du contenu halluciné que le locuteur n'a jamais dit, de la parole valide manquée, des performances instables sur des langues à faibles ressources ou multilingues, ou un calage temporel qui dérive par rapport à l'audio.

Quelques enseignements tirés de nos tests sur notre propre audio, plutôt que de la lecture des fiches techniques :

• Un bon texte ne signifie pas un bon calage temporel. Nous avons évalué un modèle multimodal de pointe comme moteur de transcription : la qualité de son texte brut était réellement bonne, mais l'horodatage de ses repères dérivait — acceptable pour une transcription de lecture, inutilisable pour des sous-titres qui doivent tomber sur la bonne image.
• Certains modèles produisent un calage temporel d'emblée inutilisable. Un autre modèle testé pour le même usage avait, selon nos notes, un « horodatage catastrophique » — solide sur le papier, rédhibitoire pour des sous-titres alignés dans le temps.
• Les langues à faibles ressources et multilingues sont là où les modèles généralistes vacillent. Les langues propres, à fortes ressources sur lesquelles s'appuie un benchmark sont le cas facile ; les défaillances se révèlent sur les accents, les dialectes et l'audio qui change de langue au sein d'un même enregistrement. Subanana a débuté avec un unique modèle STT bien connu, et nous avons été contraints d'abandonner l'approche mono-fournisseur précisément par le genre d'échec que les benchmarks masquent : des hallucinations et de la parole manquée en conditions réelles, les langues les plus difficiles étant les moins stables. C'est pourquoi nous répartissons désormais le trafic sur plusieurs moteurs évalués et basculons automatiquement lorsque l'un produit un mauvais segment.
• Le vrai travail d'ingénierie vit dans les interstices. Quand nous avons intégré un nouveau fournisseur de STT, le travail n'était pas « le WER est-il plus bas ». C'était : une plage de musique de fond dont le calage se retrouvait attribué au mauvais sous-titre, des balises parasites de type [musique entraînante] à supprimer, des segments collés les uns aux autres sans espace. Rien de cela n'apparaît dans un score de précision ; tout cela apparaît pour l'utilisateur.

Le résumé honnête est que nous choisissons le modèle STT le plus performant par langue source et par cas d'usage, et que nous le revérifions sans cesse — parce qu'un modèle qui obtient de bons scores de benchmark peut malgré tout dériver sur l'horodatage ou halluciner sur les langues les plus difficiles, et le seul moyen de le savoir est de le faire tourner sur du vrai. Vous pouvez en lire davantage sur le fonctionnement de cette répartition et de cette chaîne qualité sur nos pages outil de sous-titrage IA et transcription de réunions par IA.

Comment évaluer vous-même la précision d'une transcription ?

Vous n'avez pas besoin d'un dispositif d'évaluation élaboré pour éviter le piège des benchmarks. Le principe est simple : testez sur votre propre audio, jugez sur ce qui compte pour vous.

• Utilisez votre pire audio réel, pas un extrait propre. Choisissez le fichier avec les accents, les chevauchements de voix, le jargon, les changements de langue. C'est là que les modèles se distinguent.
• Vérifiez le calage temporel, pas seulement les mots. Lisez la vidéo avec les sous-titres affichés. Des repères qui dérivent sont invisibles dans une comparaison de texte et évidents à l'écran.
• Traquez spécifiquement la corruption factuelle. Passez en revue les noms, les nombres et les termes de produits ou de marques. Un sous-titre impeccable à la lecture avec un mauvais chiffre est pire qu'un sous-titre manifestement brut.
• Jugez le résultat fini, pas la transcription brute. Ce que vous livrez, c'est le sous-titre corrigé et mis en forme — alors évaluez-le, y compris la quantité de mise au propre manuelle qu'il réclame encore.
• Réévaluez dans le temps. Les modèles évoluent. Le meilleur pour votre langue ce trimestre ne le sera peut-être pas le suivant. Nous relançons notre évaluation précisément parce que la réponse ne cesse de bouger.

Si vous préférez ne pas vous infliger ce parcours, c'est le travail que nous faisons en continu : évaluer les modèles, router vers le plus performant par langue et par cas d'usage, et superposer la détection d'hallucinations et la relecture pour que la sortie que vous examinez soit déjà la plus solide que le système puisse produire. Vous pouvez l'essayer sur votre audio le plus difficile — commencez avec un fichier gratuit et vérifiez les points ci-dessus.

FAQ

Un pourcentage de précision publié plus élevé est-il un moyen fiable de choisir un outil de transcription ?

Non. Les chiffres publiés sont des résultats optimisés sur de l'audio propre, souvent à locuteur unique, dans une langue à fortes ressources. Ils prédisent rarement les performances sur du vrai audio avec accents, chevauchements de voix, termes techniques ou changements de langue. Testez plutôt sur vos propres fichiers.

Quelle est la différence entre la précision de transcription et la qualité des sous-titres ?

La précision de transcription désigne généralement la reconnaissance vocale brute — les mots et le calage temporel. La qualité des sous-titres, c'est le résultat fini après mise au propre : mots mal entendus corrigés, phrasé oral transformé en forme écrite propre, ponctuation et espacement restaurés, hésitations supprimées, faits laissés intacts. Un outil peut bien réussir l'un et mal réussir l'autre.

Pourquoi évaluez-vous les modèles avec un autre modèle comme juge ?

Pour l'étape de mise au propre du texte, un modèle servant de juge nous permet de comparer deux sorties par paires selon des critères constants, bien plus vite qu'une relecture manuelle, et de relancer l'opération à moindre coût chaque fois qu'un nouveau modèle paraît. Nous traitons ses verdicts comme un signal de préférence relatif face à notre propre référence — non comme un score de précision absolu — sur un échantillon délibérément difficile et composé à la main, et nous gardons des humains dans la boucle sur les échecs qui comptent, comme la corruption factuelle.

Un modèle au bon texte de transcription produit-il toujours de bons sous-titres ?

Non, et c'est un piège fréquent. Nous avons vu des modèles au texte brut réellement bon produire un calage temporel dérivant ou inutilisable. Pour des sous-titres, qui doivent s'aligner sur l'image, la fiabilité du calage compte autant que la précision des mots — et les deux ne sont pas corrélées.

Pourquoi Subanana utilise-t-il plusieurs modèles de reconnaissance vocale plutôt qu'un seul ?

Parce qu'aucun modèle unique n'est le meilleur pour toutes les langues et tous les cas d'usage, et que n'importe quel modèle peut halluciner ou manquer de la parole sur du vrai audio. Subanana a débuté avec un seul fournisseur et est passé à une approche multi-modèles après que les données de production ont montré les limites d'un moteur unique — en particulier sur les langues à faibles ressources et multilingues. Nous routons vers le modèle le mieux évalué par langue source et basculons automatiquement quand la qualité de sortie chute.