Pourquoi l'IA galère avec les langues peu dotées : regard honnête en 2026

La transcription IA fonctionne presque parfaitement sur un enregistrement en anglais, mais produit quelque chose de quasi illisible sur le même contenu en yoruba. Les deux locuteurs s’expriment aussi clairement l’un que l’autre, le problème ne vient pas de l’audio. Le problème, c’est que le modèle n’a jamais eu assez de données en yoruba pour apprendre.

Cette lacune a un nom : le problème des langues à faibles ressources. Cet article explique pourquoi il existe, quels sont les mécanismes techniques en jeu, et où cet écart se réduit réellement en 2026.

Ce que « faibles ressources » signifie concrètement

Dans la recherche en reconnaissance vocale, une langue à faibles ressources est une langue qui dispose de peu de données d’entraînement étiquetées : de l’audio enregistré associé à des transcriptions précises. Le seuil exact varie selon le contexte de recherche, mais en 2026, les catégories pratiques ressemblent à peu près à ceci :

• Ressources élevées : des centaines de milliers d’heures d’audio étiqueté. Anglais, mandarin, espagnol, français, allemand, portugais, arabe, japonais, coréen. Les modèles entraînés sur ces langues atteignent une précision de niveau production, avec des taux d’erreur de mots (WER) sous les 5 % sur un audio propre.
• Ressources moyennes : des dizaines de milliers d’heures. Italien, néerlandais, vietnamien, thaï, indonésien, polonais, turc, ukrainien. Les modèles de production atteignent un WER entre 8 et 15 %, suffisant pour une transcription fiable en premier jet.
• Faibles ressources : quelques milliers d’heures ou moins. Swahili, haoussa, wolof, bengali, tamoul, ourdou, filipino. Les taux d’erreur sont assez élevés pour qu’une relecture humaine soit nécessaire avant de publier une transcription.
• Très faibles ressources ou non prises en charge : moins de 1 000 heures d’audio transcrit, parfois moins de 100. La plupart des langues africaines, de nombreuses langues autochtones, des centaines de langues régionales plus petites dans le monde. Certaines d’entre elles n’étaient prises en charge par aucun modèle ASR avant fin 2025.

Ces catégories évoluent à chaque sortie majeure de modèle. OpenAI a signalé que 20 des 99 langues prises en charge par Whisper large-v3 ne disposaient d’aucune donnée d’entraînement, ce qui signifie que les prédictions pour ces langues sont essentiellement extrapolées plutôt qu’apprises.

Pourquoi les données d’entraînement sont le vrai goulot d’étranglement

Les modèles de reconnaissance vocale apprennent à partir d'exemples. Avec suffisamment d'enregistrements associés à des transcriptions précises, le modèle apprend quels sons composent chaque mot, comment ces sons varient selon les locuteurs, les âges et les accents, et comment le contexte lève l'ambiguïté entre des mots qui se ressemblent.

L'écart est arithmétique. Les modèles de reconnaissance vocale en anglais ont accès à des ensembles d'entraînement qui se comptent en millions d'heures. Le yoruba dispose peut-être de quelques centaines d'heures d'audio labellisé accessible au public. Un modèle entraîné sur un million d'heures d'une langue et cent heures d'une autre ne produira pas des résultats équivalents, quelle que soit la sophistication de l'architecture.

Ce n'est ni de la malveillance, ni un choix de conception délibéré. Cela reflète simplement où se trouvait l'audio numérique à grande échelle lorsque ces ensembles de données ont été constitués : les infrastructures de diffusion, les plateformes de podcasts, les livres audio et les données d'assistants vocaux penchent fortement vers une poignée de langues dominantes.

Le benchmark FLEURS rend cela concret. FLEURS évalue les modèles de reconnaissance vocale sur 102 langues avec des données parallèles. Whisper large-v3 atteint un WER moyen de 7,4 % sur FLEURS, mais ce chiffre phare masque la variance. Pour le pachto, les évaluations publiées montrent que Whisper large-v3 dépasse 89 % de WER. Pour des langues comme l'amharique et le yoruba, le WER peut dépasser 100 % en raison d'un mode de défaillance spécifique : le modèle génère une sortie qui semble plausible mais structurellement incorrecte, avec le même nombre de tokens de mots, produisant ainsi plus d'erreurs que de mots.

Pour des explications plus approfondies sur les concepts de précision, voir la précision de transcription expliquée.

Pourquoi les langues tonales aggravent le problème

Le mandarin, le vietnamien, le thaï, le yoruba, l'igbo et d'autres langues tonales ajoutent une couche de difficulté au-delà de la rareté des données. Dans ces langues, la courbe de hauteur sur une syllabe change le sens du mot. La même séquence consonne-voyelle prononcée avec un ton montant signifie quelque chose de différent de la même séquence prononcée avec un ton descendant.

La hauteur tonale est plus difficile à modéliser que les phonèmes, pour plusieurs raisons. Elle varie en continu selon le type de locuteur, l'émotion et l'emphase. Elle est sensible au bruit de fond. Et les données d'entraînement elles-mêmes sont souvent incohérentes : les diacritiques tonaux en yoruba écrit, par exemple, marquent la hauteur dans l'orthographe, mais la qualité des données d'entraînement et les conventions de marquage tonal varient considérablement d'une source à l'autre.

Un article de 2026 présenté à l'atelier LoResLM a évalué Whisper et MMS-1B de Meta sur le yoruba et a constaté que les résultats favorisaient systématiquement les données sans marquage tonal par rapport aux données avec marquage tonal. C'est contre-intuitif, jusqu'à ce qu'on réalise que le modèle a appris à partir de davantage d'exemples sans marquage tonal, donc il performe mieux quand la sortie n'exige pas une génération précise des tons. L'implication est que même lorsque le modèle produit du texte, il supprime ou génère incorrectement les diacritiques qui portent le sens dans la langue.

Pour un examen plus approfondi de ce phénomène dans une langue spécifique, voir Transcription du yoruba : évaluation honnête.

Pourquoi les écritures non latines créent des frictions supplémentaires

La majorité des textes d'entraînement en IA, pas seulement les transcriptions audio mais tout le texte que ces modèles ont jamais vu, penche fortement vers les langues à alphabet latin. Quand un modèle apprend à produire des écritures non latines comme le ge'ez (amharique), l'arabe, le devanagari ou le thaï, il lui faut une capacité d'apprentissage distincte pour les systèmes de caractères, les règles de segmentation des mots et les conventions de génération de texte.

Pour les langues non latines à forte ressource (mandarin, arabe, japonais, russe, coréen), ce n'est pas un problème car les données d'entraînement massives compensent. Pour les langues non latines à faible ressource (amharique, tigrigna, khmer, cinghalais), le défi est aggravé : données audio d'entraînement rares, plus données textuelles rares pour l'écriture.

L'amharique utilise l'écriture guèze, l'un des systèmes d'écriture les plus anciens encore en usage actif, avec 276 caractères distincts. Un modèle qui apprend l'amharique doit assimiler à la fois un système phonologique rare et un inventaire de caractères inhabituel, à partir d'exemples limités. Voir Transcription de l'amharique : statut de l'Éthiopie en 2026 pour un aperçu concret de ce que cela donne en pratique.

Pourquoi l'alternance codique aggrave encore le problème

De nombreuses langues à faibles ressources sont parlées dans des contextes de forte alternance codique : les locuteurs passent de la langue locale à une langue régionale ou coloniale dominante au niveau de la phrase ou du mot. Wolof-français, haoussa-anglais, tagalog-anglais, yoruba-anglais, hindi-anglais.

Les modèles d'IA entraînés sur des données monolingues se comportent ici d'une manière prévisiblement mauvaise. Quand le modèle rencontre un segment ambigu, il se rabat sur la langue à hautes ressources. Une conversation wolof-français peut ressortir presque entièrement en français, avec des phrases wolof transcrites de manière phonétiquement incorrecte ou hallucinées en mots français. Un échange haoussa-anglais peut se réduire à l'anglais.

Les modèles entraînés sur des données avec alternance codique gèrent mieux cela, mais les corpus d'entraînement avec alternance codique restent limités pour la plupart des paires de langues. Le jeu de données NaijaVoices (plus de 1 800 heures, plus de 5 000 locuteurs couvrant le haoussa, l'igbo et le yoruba, publié en 2025) est l'un des efforts récents les plus significatifs pour remédier à cela dans les langues nigérianes. Voir Transcription de l'alternance codique hindi-anglais pour un cas où la situation s'est nettement améliorée.

Où le progrès se produit réellement en 2026

L'écart est réel. Il se réduit aussi, en partie grâce à de meilleures architectures de modèles, et en partie grâce à un travail sérieux de collecte de données.

Meta Omnilingual ASR (novembre 2025)

Meta a publié Omnilingual ASR le 10 novembre 2025, couvrant plus de 1 600 langues, dont environ 500 qui n'avaient jamais été prises en charge par un système de reconnaissance vocale auparavant. Le plus grand modèle (7 milliards de paramètres) atteint un taux d'erreur sur les caractères inférieur à 10 pour 78 % de ces langues. Le système est open source et peut être étendu à d'autres langues grâce à l'apprentissage contextuel avec très peu d'exemples appariés. Le corpus d'entraînement comprend l'Omnilingual ASR Corpus, construit avec African Next Voices, la Fondation Mozilla et des partenaires académiques, avec des enregistrements de locuteurs natifs pour 350 langues sous-représentées.

C'est l'expansion la plus significative jamais publiée en matière de couverture linguistique pour la reconnaissance vocale. La réserve, c'est qu'un taux d'erreur inférieur à 10 pour 78 % des 1 600 langues laisse encore 22 % des langues avec des taux d'erreur plus élevés, et la précision en production pour les langues les plus pauvres en ressources reste très loin de ce que vivent les utilisateurs anglophones.

Google Chirp 3 (2025) et l'initiative des 1 000 langues

Le modèle vocal universel de Google (USM) sous-tend la famille d'API vocales Chirp. Chirp 3, sorti en 2025, s'entraîne sur 12 millions d'heures d'audio dans plus de 300 langues et ajoute le support du streaming ainsi qu'une meilleure précision multilingue. L'objectif de recherche à long terme de Google est un système couvrant 1 000 langues ; USM a été présenté comme la première étape vers cet objectif.

Jeux de données communautaires : Common Voice et Lacuna Fund

Mozilla Common Voice v26.0, publié en juin 2026, couvre 294 langues avec 21 594 heures validées dans 131 langues. Chaque heure de nouvel audio validé en haoussa, en kinyarwanda ou en luganda est un carburant pour les futures versions de modèles. Lacuna Fund a soutenu la création de jeux de données pour plus de 29 langues africaines à travers plusieurs cohortes de financement ; le jeu de données NaijaVoices (haoussa, igbo, yoruba) en est un exemple.

Ces jeux de données comptent parce que les modèles ne valent que ce que valent les données sur lesquelles ils s'entraînent. Chaque enregistrement qu'un locuteur natif apporte à Common Voice est directement utilisable comme donnée d'entraînement.

Pré-entraînement auto-supervisé

Le changement architectural le plus important pour les langues peu dotées est l'apprentissage auto-supervisé : les modèles se pré-entraînent sur de grandes quantités d'audio brut et non étiqueté dans une langue cible, apprenant la structure phonologique générale avant un affinage sur les données étiquetées limitées disponibles. wav2vec 2.0 et HuBERT ont établi cette approche. AfriHuBERT (présenté à Interspeech 2025) l'applique spécifiquement aux langues africaines, atteignant un WER inférieur à 60 % sur l'afrikaans, le haoussa et le swahili, sans les exigences de données étiquetées des systèmes antérieurs.

Le pré-entraînement auto-supervisé réduit efficacement la quantité de données étiquetées nécessaire pour atteindre un niveau de précision donné. Cela ne résout pas le problème des données d'entraînement, mais diminue la quantité de données étiquetées requise pour démarrer.

Modèles affinés par langue

Les modèles plus petits, affinés sur une seule langue, surpassent souvent les modèles multilingues génériques pour cette langue cible. Des chercheurs ont affiné Whisper spécifiquement pour l'amharique, le pachto, le gallois et d'autres langues peu dotées, avec des gains de précision significatifs par rapport au modèle multilingue de base. Ces modèles sont disponibles sur Hugging Face et d'autres référentiels, bien que le déploiement en production exige toujours une évaluation par rapport à votre domaine de contenu spécifique.

L'état honnête pour les utilisateurs en 2026

Si vous travaillez dans une langue bien dotée (anglais, espagnol, français, portugais, allemand, arabe, mandarin, japonais, coréen, hindi, vietnamien, indonésien, russe, italien, néerlandais, polonais, turc), la transcription par IA fonctionne à un niveau de production pour la plupart des cas d'usage.

Si vous travaillez dans une langue peu dotée mais en amélioration (swahili, haoussa, yoruba, wolof, bengali, tamoul, ourdou, filipino), la transcription IA actuelle produit un premier jet utilisable, mais prévoyez une passe de relecture. La précision dépend fortement de la clarté du locuteur, des conditions audio et du domaine. Testez sur un échantillon représentatif avant de construire un flux de production autour d'un outil. Pour du contexte sur ce groupe de langues, les outils de transcription pour les langues africaines couvre ce qui est disponible actuellement.

Si vous travaillez dans une langue très peu dotée (la plupart des langues africaines restantes, de nombreuses langues autochtones des Amériques et du Pacifique, des langues régionales plus petites à travers le monde), la réponse honnête à la mi-2026 est la suivante : la transcription IA vous donne au mieux un point de départ approximatif. Prévoyez la transcription manuelle comme cœur de votre flux de travail, avec l'IA comme étape de prétraitement pour réduire le problème de la page blanche.

Si vous voulez tester la transcription IA sur votre audio sans vous engager dans un plan payant, ConvertAudioToText offre un accès gratuit pour tester votre contenu spécifique avant de décider si la précision répond à vos besoins.

Ce que les utilisateurs peuvent faire aujourd'hui

Contribuer à des ensembles de données vocales ouvertes. Mozilla Common Voice accepte des enregistrements de locuteurs natifs dans toute langue prise en charge. Chaque enregistrement alimente directement l'entraînement des futurs modèles.

Exiger de la transparence de la part des fournisseurs d'IA. Quand un outil de transcription prétend prendre en charge votre langue, demandez des données de précision sur un contenu représentatif. Certains outils listent des langues qu'ils supportent à peine. Le taux d'erreur varie énormément selon le domaine, le locuteur et l'accent au sein d'une même langue.

Construisez votre flux de travail autour de la précision que vous obtenez réellement. Pour les langues peu dotées, prévoyez du temps de révision. Utilisez la sortie IA comme un premier jet, pas comme une transcription finale. Recoupez les citations importantes avec l'audio source.

Suivez les versions des modèles. Le rythme d’amélioration des langues à faibles ressources s’est accéléré au second semestre 2025 (Omnilingual ASR, Chirp 3, NaijaVoices). Des langues sans aucun support en 2024 pourraient bénéficier d’un support expérimental en 2026.

Testez les alternatives affinées. Pour certaines langues à faibles ressources, les modèles affinés par la communauté sur Hugging Face surpassent le modèle multilingue Whisper de base. Cherchez votre langue avant de vous rabattre sur les options prêtes à l’emploi.

Où cela nous mène

Le problème structurel, à savoir une qualité et une quantité de données d’entraînement radicalement inégales selon les langues en 2026, ne disparaîtra pas l’année prochaine. Mais le rythme de changement est plus rapide que jamais. Le seul Omnilingual ASR de Meta a ajouté le support ASR pour 500 langues auparavant non prises en charge en une seule publication.

Mon avis : une transcription de qualité production pour le niveau actuel de faibles ressources (swahili, haoussa, wolof) est réalisable d’ici deux ans, à mesure que les modèles entraînés sur NaijaVoices et les systèmes multilingues affinés arrivent à maturité. Pour les écarts les plus profonds, une première ébauche de qualité pour la plupart des grandes langues non desservies est probable d’ici trois à cinq ans, à condition que le travail communautaire sur les jeux de données se poursuive.

L’écart n’est pas permanent. Mais il est réel, et prétendre le contraire ne rend pas service aux locuteurs qui ont le plus besoin de ces outils.

FAQ

Qu’est-ce qu’une langue à faibles ressources dans le contexte de l’IA ?

Une langue à faibles ressources est une langue pour laquelle les modèles d’IA disposent de peu de données d’entraînement étiquetées. En reconnaissance vocale, cela signifie généralement moins de quelques milliers d’heures d’audio transcrit. Le seuil n’est pas fixe et évolue à mesure que les efforts de collecte de jeux de données progressent, mais la définition de travail est la suivante : pas assez de données pour entraîner un modèle à une précision de production sans techniques spéciales comme le pré-entraînement auto-supervisé ou l’affinage à partir d’un modèle multilingue de base.

Pourquoi Whisper fonctionne-t-il si mal sur le yoruba et d’autres langues tonales africaines similaires ?

Deux problèmes se cumulent. D'abord, le yoruba dispose de très peu de données d'entraînement comparé à l'anglais ou au français. Ensuite, c'est une langue tonale où la courbe de hauteur modifie le sens des mots, et les marques tonales à l'écrit sont indispensables pour lever l'ambiguïté. Whisper a été entraîné sur des données où l'orthographe tonale est incohérente, ce qui produit des transcriptions trop segmentées avec des taux d'erreur sur les mots dépassant 100% dans les benchmarks publiés. Ce n'est pas un échec de la conception du modèle, c'est un échec de la quantité et de la qualité des données d'entraînement.

Le modèle Omnilingual ASR de Meta est-il utilisable aujourd'hui pour les langues peu dotées ?

Meta a publié Omnilingual ASR en novembre 2025 en open source. Il couvre plus de 1 600 langues, dont environ 500 qui n'avaient jamais été prises en charge par aucun système de reconnaissance vocale. Le modèle de 7 milliards de paramètres atteint des taux d'erreur sur les caractères inférieurs à 10 pour 78% de ces langues. Il peut aussi s'étendre à d'autres langues grâce à l'apprentissage en contexte avec très peu d'exemples. Cependant, pour les langues les plus pauvres en ressources, les taux d'erreur restent élevés par rapport au niveau de l'anglais, et un déploiement en production exige une évaluation sur votre domaine précis et vos conditions audio.

Qu'est-ce que le benchmark FLEURS et pourquoi est-il important pour évaluer les langues peu dotées ?

FLEURS (Few-shot Learning Evaluation of Universal Representations of Speech) est un benchmark vocal multilingue qui couvre 102 langues avec environ 12 heures de données parallèles par langue. Il sert couramment à comparer les modèles de reconnaissance vocale à travers la diversité linguistique. Whisper large-v3 atteint un taux d'erreur moyen de 7,4% sur FLEURS, mais cette moyenne masque des écarts énormes : certaines langues peu dotées dépassent 50% voire 90% de taux d'erreur sur les mots, ce qui rend la ventilation par langue bien plus instructive que le chiffre global.

Que puis-je faire dès aujourd'hui si j'ai besoin de transcrire une langue peu dotée ?

Premièrement, testez avant de vous engager sur un outil : téléversez un échantillon représentatif et vérifiez la précision sur votre contenu, votre locuteur et vos conditions acoustiques. Deuxièmement, prévoyez une passe de correction manuelle dans votre flux de travail pour tout ce qui est en dessous de 85 % de précision. Troisièmement, envisagez de contribuer des enregistrements à Mozilla Common Voice, ce qui alimente directement les données d'entraînement des futurs modèles. Quatrièmement, pour les contenus en langues africaines, vérifiez si un modèle affiné spécifique à la langue existe (les modèles entraînés sur NaijaVoices pour le haoussa, l'igbo et le yoruba, par exemple). Cinquièmement, suivez les sorties de modèles : Omnilingual ASR et Chirp 3 ont chacun ajouté une couverture significative en 2025, et le rythme d'amélioration s'accélère.

Sources

• Article OpenAI Whisper et WER FLEURS par langue : openai.com/research/whisper
• Annonce Meta Omnilingual ASR (novembre 2025) : ai.meta.com/blog/omnilingual-asr-advancing-automatic-speech-recognition
• Blog de recherche Google USM et Chirp : research.google/blog/universal-speech-model-usm-state-of-the-art-speech-ai-for-100-languages
• Mozilla Common Voice v26.0 (juin 2026) : community.mozilladatacollective.com/common-voice-23-0-live-on-mozilla-data-collective
• Article sur le jeu de données NaijaVoices (Interspeech 2025) : arxiv.org/abs/2505.20564
• Le ton en yoruba pour la reconnaissance vocale (LoResLM 2026) : aclanthology.org/2026.loreslm-1.14
• Modèle auto-supervisé AfriHuBERT (Interspeech 2025) : isca-archive.org/interspeech_2025/alabi25_interspeech.pdf
• Jeux de données NLP africains de Lacuna Fund : lacunafund.org/datasets/language
• Description du benchmark FLEURS et évaluation de Whisper : vexascribe.com/how-accurate-is-whisper
• Benchmark WER FLEURS de Whisper en pashto : aclanthology.org/2025.chipsal-1.20