J’ai testé la transcription d’un entretien en anglais avec l’IA — Résultats du 26 février 2026 (Whisper BASE, ~11 minutes d’audio)

2026-02-26Test

Eric King

Author

1. Pourquoi ce benchmark d’entretien est important

Pour les entretiens réels, la précision de la transcription n’est pas un « bonus », c’est une condition de base. Elle détermine si vous pouvez citer vos invités en toute confiance, rechercher les thèmes clés et construire des analyses en aval sans déformer ce qui a été réellement dit. Un adjectif oublié, un nombre mal entendu ou un nom propre déformé peuvent changer le sens d’une réponse.

Dans ce benchmark, j’ai fait passer un extrait d’entretien en anglais avec « Bill » dans une chaîne de transcription basée sur Whisper, puis je l’ai évalué avec des métriques ASR standard. L’objectif n’est pas de faire du marketing, mais de fournir un instantané concret et reproductible des performances du système sur un entretien réel de longueur modérée.

L’entretien original provient d’une vidéo YouTube, que vous pouvez consulter pour le contexte :
Vidéo source de l’entretien sur YouTube.

Source Materials

Toutes les entrées utilisées pour ce benchmark se trouvent dans le dépôt ou dans des ressources statiques, et peuvent être inspectées directement :

Audio original : Audio source
Transcription de référence (VTT) : Base text
Transcription du modèle (VTT) : Result text

Ces fichiers sont les seules sources utilisées pour dériver les chiffres et les conclusions de cet article.

Screenshots from this run

Tableau de bord SayToWords — vue d’ensemble des métriques

Tableau de bord SayToWords — vue de la transcription

2. Configuration du test (Testing Setup)

Pour ce run, j’ai utilisé la configuration suivante (toutes les valeurs proviennent des métadonnées pré‑calculées et de result.json) :

Date du run : 2026‑02‑26 (dérivée des horodatages de traitement)
Scénario : entretien en anglais (test-transcripts/bill-interview)
Langue : anglais
Durée audio :
- audioDurationSeconds = 653.2934375
- ≈ 10,89 minutes de contenu
Temps de traitement :
- sttProcessingTimeSeconds = 85.476
- ≈ 1,42 minute de décodage de bout en bout
Modèle / mode :
- whisper-model : BASE
- saytowords-mode : base

Les conditions d’enregistrement, le type de micro et la densité de parole ne sont pas documentés dans les métadonnées, donc je préfère ne pas les inventer ni les commenter. Tous les alignements et le scoring ont été réalisés avant la rédaction de ce rapport ; les chiffres ci‑dessous sont lus directement dans test-transcripts/bill-interview/result.json.

3. Méthodologie d’évaluation (Evaluation Methodology)

La transcription humaine de référence (ref.vtt) et la sortie du modèle (model.vtt) sont stockées au format WebVTT. Le pipeline d’évaluation extrait d’abord le texte brut, aligne la référence et l’hypothèse, puis calcule différentes métriques d’erreur.

Word Error Rate (WER)

Après tokenisation en séquences de mots, on compte :

(S) : substitutions
(D) : suppressions (deletions)
(I) : insertions
(N) : nombre total de mots de référence

La WER est définie par :

[ \text{WER} = \frac{S + D + I}{N} ]

La précision au niveau mot (Accuracy) est alors :

[ \text{Accuracy} = 1 - \text{WER} ]

Character Error Rate (CER)

Au niveau caractère, on supprime les espaces puis on calcule une distance d’édition de type Levenshtein :

Distance d’édition en caractères : total des insertions, suppressions et substitutions
Total de caractères : nombre de caractères de la référence (sans espaces)

[ \text{CER} = \frac{\text{Character edit distance}}{\text{Total characters}} ]

Real‑Time Factor (RTF)

Le débit est mesuré via le Real‑Time Factor :

[ \text{RTF} = \frac{\text{Processing Time}}{\text{Audio Duration}} ]

Ici, le temps de traitement vient de la différence entre processtime-at et completed-at dans other.yaml, et la durée audio provient de audio-duration dans le même fichier.

Notes d’implémentation

Toutes les métriques sont calculées à partir d’un alignement entre la référence et l’hypothèse.
Les distances d’édition (mots et caractères) utilisent une implémentation Levenshtein optimisée.
Le moteur d’alignement tourne sur un backend C++ optimisé.
La complexité temporelle est de l’ordre de O(nm) pour des séquences de longueur (n) et (m).
Toutes les valeurs de result.json sont déterministes et reproductibles : mêmes entrées ⇒ mêmes résultats.

4. Vue d’ensemble du modèle (Model Overview)

Un seul paramétrage de modèle a été évalué dans ce benchmark :

Whisper BASE (saytowords-mode: base)
Un modèle de reconnaissance vocale généraliste, de capacité moyenne, conçu pour l’anglais multi‑accent et l’audio longue durée. Dans ce benchmark, il est utilisé tel quel (sans fine‑tuning ni correction manuelle) pour observer son comportement brut sur un entretien réel.

Des comparaisons futures pourraient intégrer des variantes Whisper plus petites ou plus grandes, ainsi que d’autres familles de modèles, mais ce billet se concentre volontairement sur cette unique baseline.

5. Résultats (d’après result.json)

Les valeurs suivantes sont prises telles quelles dans test-transcripts/bill-interview/result.json :

Durée audio (s) : 653.2934375
Temps de traitement (s) : 85.476
Mots de référence (N) : 1846
Substitutions (S) : 67
Suppressions (D) : 178
Insertions (I) : 23
WER : 0.14517876489707476
Accuracy : 0.8548212351029252
Caractères de référence : 7335
Distance d’édition en caractères : 825
CER : 0.11247443762781185
RTF : 0.13083860191079907

Pour plus de lisibilité :

WER ≈ 14,52 %
Accuracy ≈ 85,48 %
CER ≈ 11,25 %
RTF ≈ 0,13, soit environ 7,6× plus rapide que le temps réel.

6. Analyse du profil d’erreurs (Error Pattern Analysis)

Aucun marquage détaillé par segment ou visualisation interactive n’est fourni ; l’analyse repose donc uniquement sur les comptes agrégés.

Type d’erreur dominant : suppressions (deletions)
- Suppressions : D = 178
- Substitutions : S = 67
- Insertions : I = 23
  Les suppressions constituent la majorité des erreurs au niveau mot. Cela indique que le modèle omet plus souvent des mots qu’il n’en invente. Dans un entretien, cela se traduit souvent par des mots outils manquants, des fins de phrases tronquées dans la parole rapide, ou des morceaux de parole qui disparaissent lorsque plusieurs personnes parlent en même temps.
Les substitutions sont présentes, mais secondaires
Avec S = 67, les substitutions représentent environ un quart des erreurs. Il s’agit typiquement de confusions lexicales : mots à prononciation proche, noms propres mal reconnus, ou termes de domaine peu fréquents pour le modèle.
Les insertions sont relativement rares
On ne voit que I = 23 insertions. Cela correspond à un modèle plutôt conservateur vis‑à‑vis des hallucinations de contenu : il se trompe plus souvent par omission que par ajout.

Au niveau caractère :

Distance d’édition en caractères = 825 pour 7335 caractères, soit CER ≈ 11,25 %.
Comparée à une WER d’environ 14,5 %, cette CER plus faible suggère que de nombreux mots erronés restent proches de la référence au niveau des caractères — par exemple des variations de flexion, de petites erreurs d’orthographe ou des mots composés découpés/joints différemment.

Sans marquage d’erreur à l’échelle de l’horodatage, il est difficile de pointer « le moment exact où le modèle se trompe ». Mais la décomposition S/D/I donne déjà un profil utile : ce système a tendance à sous‑transcrire (under‑transcribe) plutôt qu’à inventer des phrases qui n’existent pas.

7. Enseignements clés (Key Insights)

En se basant uniquement sur les chiffres, on peut dégager plusieurs enseignements :

Compromis vitesse/précision raisonnable pour les entretiens
Avec RTF ≈ 0,13, le système traite ~10,9 minutes d’audio en ~1,4 minute, tout en conservant WER ≈ 14,5 % et CER ≈ 11,3 %. Pour de la transcription en masse d’entretiens, ce point de fonctionnement est pratique.
Profil d’erreur clairement dominé par les suppressions
Les suppressions (178) dominent les substitutions (67) et les insertions (23). En pratique, vous risquez donc davantage de perdre de petits morceaux de contenu que de voir le modèle fabriquer des passages entiers.
Stabilité meilleure au niveau caractère qu’au niveau mot
Le fait que la CER soit inférieure à la WER indique que beaucoup de mots erronés restent proches de la référence au niveau des caractères. C’est plutôt positif pour des tâches comme la recherche plein texte ou le clustering thématique, qui tolèrent de légères variations lexicales.
Un volume de parole non trivial
Avec 1846 mots de référence et 7335 caractères, on est bien plus proche d’un entretien réel que d’un exemple jouet. Les métriques reflètent un comportement soutenu sur plusieurs minutes de parole spontanée.

8. Meilleur modèle pour ce scénario (Best Model for This Scenario)

Dans ce benchmark, un seul modèle a été testé : Whisper BASE (mode base). Il est donc à la fois :

le meilleur modèle du « tableau », et
le seul point de comparaison.

Dans ce cadre, il offre :

WER ≈ 14,5 %, Accuracy ≈ 85,5 % sur ~11 minutes d’entretien.
RTF ≈ 0,13, soit 7–8× plus rapide que le temps réel.

Pour les usages où l’on a besoin de transcriptions d’entretien rapides et raisonnablement fiables — pour la navigation, la recherche ou des citations approximatives — cette configuration est numériquement suffisante. Pour les cas où chaque mot compte, les métriques montrent clairement qu’une relecture humaine ou un modèle plus puissant restent nécessaires.

9. Verdict final neutre (Neutral Final Verdict)

Sur cet entretien en anglais du 26 février 2026, Whisper BASE en mode « base » présente :

un profil d’erreur dominé par les suppressions, avec peu d’insertions,
une WER dans les bas‑milieux de 10 % et une CER dans les bas‑milieux de 10 %, soutenues par une transcription de référence non triviale,
un Real‑Time Factor autour de 0,13, adapté au traitement par lots à grande échelle.

Le comportement est numériquement cohérent, reproductible et suffisamment rapide pour des benchmarks quotidiens. Pour un évaluateur indépendant, le message est simple : cette configuration constitue une baseline viable pour la transcription d’entretiens, mais ne remplace pas encore la relecture humaine dans les domaines très sensibles.

Artefacts de référence (Reference Artifacts)

Ci‑dessous, des blocs repliables sont prévus pour la transcription de référence et la sortie du modèle ; vous pouvez y intégrer le contenu VTT complet si nécessaire.

ref.vtt (transcription de référence)

<!-- Collez ici le contenu complet de test-transcripts/bill-interview/ref.vtt -->

model.vtt (transcription du modèle)

<!-- Collez ici le contenu complet de test-transcripts/bill-interview/model.vtt -->