Corriger les erreurs de code-switching dans la transcription

Pourquoi l'audio en langues mixtes pose problème

La solution à la plupart des échecs de code-switching consiste à choisir un moteur doté d'un modèle multilingue natif et à lui indiquer de ne pas s'ancrer sur une seule langue. Si vous utilisez AssemblyAI, passez speech_model: "universal" et définissez vos deux codes de langue. Si vous utilisez Deepgram, définissez language=multi avec Nova-3 ou Flux. Si vous utilisez Whisper, définissez language=None pour autoriser la détection par segment. Le reste de cet article explique pourquoi ces choix comptent et quoi faire lorsqu'ils échouent quand même.

La plupart des moteurs de transcription sont conçus autour d'une hypothèse mono-langue. Ils reçoivent l'audio, choisissent une langue principale et confrontent chaque phonème au vocabulaire de cette langue. Lorsqu'un locuteur change de langue en pleine phrase, le modèle est confronté à trois mauvaises options : restituer la langue secondaire sous forme d'approximations phonétiques de la langue principale (« para crear » devient « para crayer »), se verrouiller sur la nouvelle langue et y rester même après que le locuteur est revenu à la première, ou supprimer purement et simplement les segments incompatibles. Chacune produit une transcription cassée.

Le problème le plus profond se situe précisément aux frontières entre les langues. Les recherches sur les modèles de parole multilingues montrent que le WER aux points de bascule (le taux d'erreur mesuré dans la fenêtre de 2 à 3 mots autour de chaque transition linguistique) peut être 30 à 50 points plus élevé que le WER global agrégé. Un modèle affichant 10 % de WER global peut néanmoins massacrer chaque code-switch. Les chiffres de précision agrégés masquent ce phénomène.

Les trois modes de défaillance, nommés

Comprendre quel mode de défaillance vous rencontrez vous indique quelle correction appliquer.

Substitution phonétique : le moteur reste dans la langue principale et restitue les mots de la langue secondaire sous forme de quasi-homophones. C'est la défaillance la plus courante et la plus facile à repérer. « Finalizando » devient « finally sando ». Correction : passer à un moteur multilingue.

Verrouillage de langue : le moteur détecte la bascule et s'engage dans la nouvelle langue, puis ne parvient pas à revenir en arrière. Le reste de la transcription est dans la mauvaise langue. Correction : utiliser une détection par segment plutôt que par tâche.

Hallucination aux frontières : le modèle perd le contexte à un point de transition et génère du texte plausible qui n'a jamais été prononcé. C'est la défaillance la plus difficile à détecter car la sortie semble propre mais est erronée. Elle est particulièrement fréquente avec Whisper sur de courts segments audio où le silence ou le bruit tombe à une frontière linguistique. Correction : utiliser un prétraitement VAD (détection d'activité vocale) pour supprimer les segments silencieux avant qu'ils n'atteignent le modèle, et privilégier les moteurs de code-switching dédiés aux modèles multilingues généralistes pour les contenus riches en bascules.

Correction 1 : utiliser un moteur de code-switching dédié

L'avancée la plus nette dans ce domaine depuis 2024 est que plusieurs grandes API proposent désormais des modes de code-switching dédiés, et pas seulement une « prise en charge multilingue ».

Deepgram Nova-3 avec language=multi prend en charge le code-switching dans 10 langues : anglais, espagnol, français, allemand, hindi, russe, portugais, japonais, italien et néerlandais. Définissez language=multi dans la chaîne de requête lors de l'appel à /listen. Pour le streaming, Deepgram recommande endpointing=100 (détection de fin de segment à 100 ms) spécifiquement pour l'audio en code-switching. Nova-3 Multilingual a apporté une réduction relative d'environ 34 % du WER en mode batch lors de sa mise à jour de mars 2026, avec les gains les plus importants aux frontières de code-switching.

Deepgram Flux Multilingual (flux-general-multi), disponible en disponibilité générale depuis avril 2026, prend en charge les mêmes 10 langues avec un code-switching natif intégré à l'architecture du modèle plutôt qu'en tant que couche de détection superposée à un modèle monolingue. Vous pouvez passer des paramètres optionnels language_hint pour orienter la détection lorsque vous savez quelles langues sont présentes.

AssemblyAI Universal-3 Pro gère le code-switching pour l'audio pré-enregistré en anglais, espagnol, portugais, français, allemand et italien. La contrainte à connaître : vous pouvez spécifier au maximum deux codes de langue par requête de transcription, et l'un d'eux doit être l'anglais. La langue autre que l'anglais doit être dominante dans l'audio pour obtenir les meilleurs résultats.

Pour le streaming en temps réel spécifiquement, le modèle Universal-Streaming d'AssemblyAI traite six langues en une seule passe (anglais, espagnol, français, allemand, italien, portugais) sans nécessiter de spécification manuelle de la langue.

Pour les paires de langues hors de ces ensembles, les outils basés sur Whisper restent la solution de repli la plus large. Voir la correction 2.

Voir aussi : Deepgram Nova-3 expliqué pour un examen approfondi de l'architecture du modèle multilingue.

Correction 2 : utiliser Whisper avec auto-détection pour les paires non prises en charge

Pour les paires de langues non couvertes par les moteurs dédiés ci-dessus (wolof + français, cantonais + anglais, taglish, singlish, portunhol et autres), Whisper Large-v3 est l'option la plus pratique car ses données d'entraînement couvraient un éventail plus large de combinaisons de langues.

Le réglage crucial : définissez language=None pour autoriser la détection par segment plutôt que d'imposer un seul code de langue.

result = model.transcribe(
    audio_file,
    language=None,  # auto-detect per segment
    task="transcribe"
)

Définir un code de langue spécifique force le modèle à interpréter tout l'audio comme étant dans cette langue. Le laisser à None permet à Whisper d'estimer la langue par fenêtre de 30 secondes.

L'avertissement honnête : la précision du code-switching de Whisper se dégrade aux frontières linguistiques, et il est plus sujet à l'hallucination à ces endroits que les moteurs dédiés. Pour le hinglish spécifiquement, aucun outil de transcription commercial ne le gère de manière fiable en 2026. Whisper est la meilleure option disponible pour le code-switching hindi-anglais, mais attendez-vous à effectuer davantage de corrections manuelles que pour le spanglish ou le contenu franco-anglais, où les données d'entraînement sont plus abondantes.

Correction 3 : spécifier explicitement les langues lorsque c'est pris en charge

Pour les moteurs qui acceptent une liste de langues plutôt qu'un seul code, nommer explicitement les langues présentes dans l'audio aide le modèle à concentrer sa détection.

# Google Cloud Speech-to-Text (Chirp 3, V2 API)
config = {
    "model": "chirp_3",
    "language_codes": ["es-US", "en-US"]  # up to 3 languages; fewer = more accurate
}

La documentation de Google note que spécifier moins de langues augmente la précision de la détection. L'API V2 prend également en charge language_codes: ["auto"] sur Chirp 3 pour une détection entièrement automatique, bien que les codes explicites surpassent l'auto-détection lorsque vous connaissez la paire de langues.

Pour Google Cloud STT, la fonctionnalité est disponible uniquement dans la région global et les multi-régions us et eu.

Schémas de code-switching et choix du moteur

Le bon moteur dépend des langues concernées par la bascule. Voici une analyse pratique par paire courante.

Pour les enregistrements de réunions multilingues où vous avez besoin de la séparation des locuteurs en plus de la détection de langue, voir la diarisation des locuteurs expliquée et la transcription de réunions multilingues.

AWS Transcribe : identification multi-langues vs code-switching

AWS Transcribe a ajouté l'identification multi-langues pour les tâches batch et streaming. La fonctionnalité détecte les langues dominantes par segment et les étiquette dans la sortie de transcription. Elle peut identifier les « locuteurs bilingues qui alternent entre les langues, telles que l'anglais américain et le hindi-IN, en identifiant et en transcrivant chaque langue séparément ».

La distinction importante : il s'agit d'identification de langue et de transcription par segment, pas de code-switching en pleine phrase. Pour l'alternance structurée (le locuteur A répond en anglais, le locuteur B répond en espagnol), cela fonctionne bien. Pour le mélange intra-phrastique (« I was finalizando the deal »), c'est moins fiable car la bascule se produit dans une seule fenêtre de détection.

La rédaction (redaction) et les modèles de langue personnalisés ne sont actuellement pas pris en charge conjointement avec l'identification multi-langues.

Correction 4 : découper l'audio pour les bascules prévisibles

Pour les enregistrements présentant une alternance structurée des langues plutôt qu'un mélange au niveau de la phrase, découper par segment de langue et transcrire chaque partie séparément produit la sortie la plus propre.

Cela vaut les étapes supplémentaires lorsque : le contenu présente des frontières linguistiques prévisibles (une interview où les questions sont en anglais et les réponses en mandarin), les enjeux sont suffisamment élevés pour justifier le travail supplémentaire, ou la paire de langues n'est pas prise en charge par un moteur dédié.

Le flux de travail : identifier les frontières linguistiques (manuellement ou avec un outil de détection de langue), découper en segments, transcrire chaque segment avec le réglage de langue correspondant, fusionner dans l'ordre. Pour les contenus réguliers à structure prévisible, ce processus peut être scripté.

Nettoyage manuel des transcriptions en code-switching

Même avec les meilleurs choix de moteur, les transcriptions en code-switching bénéficient d'une passe de relecture ciblée.

Vérifiez d'abord les mots aux points de bascule. Les mots situés immédiatement avant et après chaque frontière linguistique concentrent la plupart des erreurs. Parcourez ces positions avant de lire la transcription complète.

Corrigez les substitutions phonétiques. Lorsque le modèle a restitué une langue sous forme d'équivalent phonétique approximatif dans l'autre langue, l'erreur est généralement reconnaissable si vous connaissez les deux langues. « Para crayer » pour « para crear », « I told my mom acha » pour « I told my mom accha ».

Vérifiez les noms propres. Les noms de personnes, de lieux et de marques qui franchissent des frontières linguistiques sont souvent restitués de manière incohérente ou phonétique. Une relecture par un locuteur natif bilingue est le contrôle le plus efficace pour les contenus à enjeux élevés.

N'éditez pas au profit de la fluidité de lecture au détriment de l'exactitude. Un discours en code-switching peut sembler maladroit sous forme de transcription, mais le rôle de la transcription est de capturer ce qui a été dit, pas de se lire aisément. Signalez les passages maladroits pour une relecture humaine plutôt que de les lisser silencieusement.

Pour les benchmarks de précision entre moteurs, voir la précision de transcription expliquée.

Quand le problème n'est pas le code-switching

Certains fichiers audio sont diagnostiqués à tort comme des problèmes de code-switching alors qu'il s'agit en réalité d'autre chose.

Parole accentuée dans une seule langue : un locuteur avec un fort accent régional peut déclencher la détection de langue du modèle. Ce n'est pas du code-switching et la correction est différente : utilisez un modèle robuste face aux accents plutôt qu'un mode de code-switching multilingue.

Emprunts et mots importés : un locuteur qui dit « I ordered sushi at the izakaya » n'a pas fait de code-switching. Les emprunts isolés insérés dans des phrases par ailleurs monolingues sont bien gérés par n'importe quel moteur moderne. Cela ne devient un problème de transcription que lorsque les emprunts sont rares et que le modèle les restitue phonétiquement.

Contenu bilingue structuré : si chaque énoncé est clairement dans une seule langue (locuteur A en anglais, locuteur B en français), vous avez un contenu bilingue plutôt que du code-switching. Utilisez l'identification multi-langues (AWS Transcribe, Google Cloud STT) ou l'attribution d'une langue par locuteur plutôt qu'un modèle de code-switching.

La règle générale : si la bascule se produit en pleine phrase (structure grammaticale mixte au sein d'un même énoncé), c'est du code-switching. Si elle se produit aux frontières des énoncés, c'est du contenu bilingue. La correction diffère.

Pour les réunions multilingues enregistrées, créer des comptes rendus de réunion à partir d'un audio couvre le flux de travail complet, y compris la gestion des langues.

Mon avis : en 2025, le conseil pratique était « utilisez Whisper et acceptez ses limites ». À mi-2026, le tableau est plus différencié. Pour les 10 langues couvertes par le language=multi de Deepgram et les 6 langues du mode code-switching de l'U3-Pro d'AssemblyAI, les moteurs dédiés sont désormais mesurablement meilleurs que Whisper aux points de bascule. Whisper reste le bon choix pour les paires de langues que ces moteurs ne couvrent pas, mais il n'est plus la recommandation par défaut pour tout. Adaptez le moteur à la paire de langues, pas au flux de travail.

Si vous avez besoin d'une transcription rapide d'un audio multilingue sans configurer d'API, ConvertAudioToText gère la détection automatique de la langue, sans compte requis pour la première utilisation.

FAQ

Quel est le meilleur moteur de transcription pour le hinglish en 2026 ?

Deepgram Nova-3 avec language=multi est l'option la plus solide, car le hindi fait partie de son ensemble de 10 langues pour le code-switching. Whisper Large-v3 avec language=None constitue une solution de repli raisonnable. Aucun moteur actuel ne gère le hinglish avec une grande précision sur tous les accents régionaux ; attendez-vous à plus de corrections manuelles pour le hinglish que pour le spanglish ou le contenu franco-anglais. Les affirmations de 80 à 90 % de précision pour le hinglish ne sont pas vérifiables auprès de benchmarks indépendants.

En quoi le code-switching d'AssemblyAI diffère-t-il de celui de Deepgram ?

Pour l'audio pré-enregistré, AssemblyAI Universal-3 Pro prend en charge deux codes de langue par requête, dont l'un doit être l'anglais, avec de meilleurs résultats lorsque la langue autre que l'anglais est dominante. Deepgram Nova-3 avec language=multi couvre 10 langues sans exiger que l'anglais en fasse partie, et n'impose pas de limite de deux langues. Pour le streaming en temps réel, les deux proposent des modèles de streaming multilingues dédiés (AssemblyAI Universal-Streaming pour 6 langues, Deepgram Flux pour 10 langues), et l'écart se resserre. Choisissez selon les paires de langues dont vous avez besoin.

AWS Transcribe prend-il en charge le code-switching en pleine phrase ?

L'identification multi-langues d'AWS Transcribe fonctionne bien pour le contenu bilingue structuré où chaque énoncé est dans une seule langue, mais elle est moins fiable pour le code-switching intra-phrastique (mélange au sein d'une même phrase). La fonctionnalité détecte la langue dominante par segment audio et transcrit chaque segment séparément. Pour les bascules en pleine phrase, Deepgram Nova-3 ou AssemblyAI Universal-3 Pro sont de meilleurs choix si vos paires de langues se recoupent.

Pourquoi Whisper hallucine-t-il aux frontières linguistiques ?

Le décodeur de Whisper génère du texte à partir de motifs appris sur l'audio d'entraînement. Lorsque le contenu audio est ambigu à un point de bascule linguistique (notamment près d'un silence ou d'un bruit de fond), le modèle revient à des suites statistiquement probables plutôt qu'à la parole réelle, produisant du texte fabriqué mais plausible. Un prétraitement par détection d'activité vocale (VAD) supprime les segments de silence les plus susceptibles de déclencher ce phénomène. Pour les contenus riches en bascules, les modèles de code-switching dédiés sont moins sujets à l'hallucination aux frontières car leur architecture traite explicitement le signal de bascule plutôt que via la continuation de motifs.

Sources

• Documentation du code-switching d'AssemblyAI : https://www.assemblyai.com/docs/pre-recorded-audio/code-switching
• Article de blog multilingue d'AssemblyAI Universal-Streaming : https://www.assemblyai.com/blog/real-time-transcription-code-switches-multilingual-speakers
• Documentation du code-switching multilingue de Deepgram : https://developers.deepgram.com/docs/multilingual-code-switching
• Lancement de Deepgram Flux Multilingual (avril 2026) : https://deepgram.com/learn/deepgram-launches-flux-multilingual-press-release
• Mise à jour WER de Deepgram Nova-3 Multilingual (mars 2026) : https://deepgram.com/learn/nova-3-multilingual-major-wer-improvements-across-languages
• Documentation multi-langues de Google Cloud Speech-to-Text : https://docs.cloud.google.com/speech-to-text/docs/multiple-languages
• Documentation d'identification de langue d'AWS Transcribe : https://docs.aws.amazon.com/transcribe/latest/dg/lang-id.html