L'IA peut-elle lire plusieurs langues dans un même document ?
Oui — à quoi s'attendre

Comment l'IA lit plusieurs langues selon la famille d'écriture

L'erreur la plus courante lors de l'évaluation de l'extraction multilingue par IA est de considérer « prend en charge 100+ langues » comme un seul chiffre de précision. Ce n'est pas le cas. La précision suit une hiérarchie claire par famille d'écriture — et comprendre où se situent vos documents sur cette échelle fait la différence entre un flux de travail fonctionnel et un flux de travail cassé.

Les écritures latines (anglais, français, allemand, espagnol, portugais, italien, néerlandais et des dizaines d'autres) partagent un alphabet de 26 lettres, un sens de lecture de gauche à droite et une tradition typographique commune. Un seul pipeline OCR les traite toutes. Les modèles de vision modernes atteignent une précision de 95 %+ sur des documents latins imprimés propres, quelle que soit la langue — le modèle n'a pas besoin de savoir s'il lit du français ou de l'allemand, car les motifs visuels sont suffisamment similaires.

Les écritures cyrilliques (russe, ukrainien, bulgare, serbe) ajoutent un deuxième jeu de caractères mais partagent le même sens de lecture et les mêmes conventions de mise en page que le latin. La précision ne baisse que légèrement — environ 90–93 % sur des documents propres — car la similarité structurelle permet un bon transfert des données d'entraînement. La plupart des modèles de vision entraînés sur des corpus multilingues atteignent des performances proches du latin sur le cyrillique.

Puis commencent les vrais défis. Les écritures arabe et CJK (chinois, japonais, coréen) nécessitent des modèles de reconnaissance fondamentalement différents — pas seulement une table de correspondance de caractères différente. Voici ce qui rend chacune difficile :

Ce ne sont pas des cas marginaux. Une seule facture peut contenir un en-tête d'entreprise en anglais, un bloc d'adresse en japonais, des descriptions d'articles en coréen et des chiffres arabes — et un modèle qui ne gère qu'une seule famille d'écriture échouera sur tout le reste. Le benchmark CC-OCR (arXiv 2412.02210), qui teste des modèles dans 10 langues dont le japonais, le coréen, l'arabe et six langues latines, a montré que même le meilleur modèle généraliste — Gemini-1.5-Pro — obtenait un score global de 78,97 pour l'OCR multilingue, le japonais étant la langue la moins performante parmi tous les modèles généralistes en raison de la forte prévalence du texte vertical dans l'ensemble de test.

L'implication pratique : si vos documents n'utilisent que des écritures latines, vous pouvez vous attendre à une précision de qualité production de la part de tout outil d'extraction IA compétent. S'ils incluent de l'arabe ou du CJK, vous devez tester sur vos documents réels — pas sur la démo du fournisseur — et prévoir du temps pour la vérification.

Ce que l'extraction multilingue par IA réussit bien

L'écart entre l'IA et l'OCR traditionnelle sur les documents multilingues n'est pas minime — il est structurel. L'OCR traditionnelle a été conçue autour du postulat qu'un document équivaut à une seule langue. Vous configurez Tesseract pour l'anglais, le japonais ou l'arabe, vous lui fournissez un document, et vous croisez les doigts. Des pages multilingues ? Elles ne sont pas prévues.

Les modèles de vision-langage n'ont pas cette limitation. Ils ne segmentent pas le texte en caractères individuels pour les faire correspondre à une table de correspondance propre à chaque langue. Ils lisent la page entière — mise en page, texte, contexte — et comprennent ce qui est écrit, quelle que soit la langue, exactement comme le ferait un lecteur humain multilingue. Cela rend plusieurs scénarios fiables dès aujourd'hui :

Documents multilingues purement latins. Une facture suisse avec du texte en allemand, français et italien. Un bordereau d'expédition canadien en anglais et français. Un bon de commande paneuropéen avec des coordonnées de fournisseur en espagnol et des instructions d'expédition en portugais. Comme ces langues partagent des jeux de caractères et un sens de lecture, l'IA les traite en une seule passe sans perte de qualité — la précision reste au niveau de 95 %+ de l'extraction latine monolingue.

Paires bilingues courantes avec même sens de lecture. Documents anglais/coréen, anglais/japonais et anglais/chinois où la partie non latine est complémentaire — un nom d'entreprise anglais à côté d'une adresse coréenne, une description de produit en japonais sous un SKU anglais. L'IA s'ancre sur le texte latin qu'elle maîtrise bien et traite le texte CJK ou arabe comme du contenu reconnu supplémentaire. Sur des formulaires structurés où les étiquettes de champ fournissent un contexte sémantique (un en-tête de colonne « Description » indique clairement que le contenu en dessous est une description d'article, quelle que soit la langue), la précision sur la partie non latine atteint environ 80 à 90 %.

Formulaires multilingues structurés. Les meilleures performances sont obtenues lorsque le document a une structure claire — champs étiquetés, mise en page cohérente et zones de texte délimitées. Une déclaration douanière de l'UE avec des blocs linguistiques séparés par des champs. Une facture fiscale coréenne (전자세금계산서) où le nom du fournisseur, le montant et les champs fiscaux sont spatialement séparés. L'IA lit chaque champ indépendamment, en utilisant l'étiquette du champ comme ancrage sémantique pour savoir quoi trouver — c'est le même mécanisme d'Extraction de colonnes personnalisées qui fonctionne pour les documents monolingues : vous définissez les colonnes souhaitées (par exemple « Nom du fournisseur », « Montant total », « Taux de TVA »), et l'IA localise chaque valeur en comprenant ce qu'elle signifie, et non en faisant correspondre son emplacement sur la page.

Modèles de vision à large vocabulaire. GPT-4o a introduit un nouveau tokenizer qui améliore considérablement le traitement des langues non anglaises — nécessitant 4,4× moins de tokens pour le gujarati, 3,5× moins pour le télougou et 3,3× moins pour le tamoul par rapport aux modèles précédents. Pour les langues CJK, où les phrases peuvent consommer 2 à 8 fois plus de tokens que leurs équivalents anglais, cela compte énormément : moins de tokens signifie qu'une plus grande partie du document tient dans la fenêtre de contexte du modèle, réduisant ainsi la perte d'informations. Google Document AI couvre plus de 200 langues, dont 50 avec prise en charge de l'écriture manuscrite ; Azure AI Document Intelligence couvre plus de 100 langues avec une prise en charge explicite du CJK, de l'arabe et du devanagari.

Là où l’extraction IA multilingue peine encore

La réponse honnête compte plus que celle du marketing — car promettre trop sur la capacité multilingue est le moyen le plus rapide de perdre la confiance quand quelqu’un importe sa première facture coréenne/anglaise et voit la moitié du hangeul mal lu.

De droite à gauche et de gauche à droite sur la même page. Un contrat juridique arabe avec des références de clauses en anglais. Un bordereau d’expédition hébreu avec des conditions d’expédition en français. L’IA doit détecter les limites des écritures, appliquer le sens de lecture correct à chaque segment et les concilier en une seule sortie. Les pipelines OCR standard conçus pour le texte LTR produisent une sortie désordonnée et sémantiquement brisée — texte arabe rendu à l’envers, sauts de ligne mal placés, caractères des deux écritures fusionnés en non-sens. Les modèles de vision gèrent mieux cela en traitant la direction comme une propriété de mise en page plutôt que de flux de texte, mais la précision sur les documents vraiment mixtes chute encore à 65–80 %.

Texte CJK vertical. Les documents japonais mélangent fréquemment texte horizontal et vertical — le corps principal s’écrit de haut en bas, tandis que les annotations et chiffres en anglais vont de gauche à droite. Le chinois et le coréen utilisent moins le texte vertical dans les documents professionnels modernes, mais il persiste dans les formats traditionnels, certificats et correspondances formelles. Le benchmark CC-OCR a spécifiquement identifié le texte vertical japonais comme le plus grand frein à la précision parmi tous les modèles généralistes. Un modèle qui gère le japonais horizontal à près de 90 % peut chuter à 60–70 % quand le même texte est vertical — la compréhension de la mise en page du modèle a été principalement entraînée sur des documents horizontaux.

Paires de langues rares. L’anglais/espagnol et l’anglais/japonais sont bien couverts car ils apparaissent fréquemment dans les données d’entraînement. Thaï/arabe sur la même page ? Swahili/cyrillique ? Vietnamien/hébreu ? Ces paires sont dramatiquement sous-représentées dans les corpus d’entraînement. Le modèle peut reconnaître des écritures individuelles mais peine à analyser leur interaction — surtout quand elles utilisent des directions d’écriture différentes ou quand une écriture contient des caractères qui ressemblent visuellement à ceux de l’autre.

Documents manuscrits + imprimés en langues mixtes. Un formulaire japonais imprimé avec des annotations manuscrites en anglais. Une facture coréenne avec des corrections manuscrites mêlant hangeul et anglais. L’écriture manuscrite seule réduit la précision de l’IA de 15 à 30 % par rapport au texte imprimé (voir notre guide sur la précision de la reconnaissance d’écriture manuscrite par IA). Ajouter une deuxième langue par-dessus — surtout quand les parties manuscrites alternent entre écritures — cumule les erreurs. Le modèle doit résoudre simultanément l’ambiguïté de l’écriture manuscrite et les limites des écritures, et les architectures actuelles traitent ces aspects de manière séquentielle plutôt que conjointe.

Densité de caractères en CJK. Une seule phrase japonaise peut contenir trois systèmes d’écriture (kanji, hiragana, katakana) plus des caractères latins pour les emprunts anglais et des chiffres arabes pour les montants — le tout sur une seule ligne. Un moteur OCR traditionnel configuré pour l’un d’eux ignorera silencieusement les autres. Les modèles de vision gèrent correctement la nature multi-écritures du japonais comme une propriété structurelle, mais la densité d’information crée un surcoût de tokenisation : le même contenu sémantique en japonais consomme environ 2× les tokens de son équivalent anglais, ce qui fait que le modèle atteint plus vite les limites de fenêtre de contexte sur les longs documents.

Comment obtenir les meilleurs résultats de l'extraction IA multilingue

Le facteur le plus important que vous contrôlez est la manière dont vous demandez à l'IA d'extraire les données — et cela compte encore plus pour les documents multilingues que pour tout autre type de document. Utiliser l'extraction sémantique plutôt que la transcription OCR brute est la différence entre des données multilingues exploitables et un fouillis multilingue.

1. Utilisez l'extraction par colonnes personnalisées, pas l'OCR pleine page. Ne demandez pas à l'IA de « tout lire sur cette page ». Indiquez-lui exactement les champs souhaités — « Nom du fournisseur », « Date de facture », « Montant total », « Numéro de TVA ». En définissant des colonnes de sortie, l'IA se concentre sur la recherche de ces valeurs spécifiques en comprenant leur sens sémantique, quelle que soit la langue. Un nom de fournisseur coréen en hangeul (comme « 한국전자 ») est aussi facile à trouver qu'en anglais — l'IA sait que le champ « Nom du fournisseur » contient un nom d'entité. L'OCR brut, en revanche, produit un flux de texte dans la langue pour laquelle le moteur est configuré et ignore le reste. Pour en savoir plus sur cette approche par colonnes, consultez ce qu'est l'extraction de documents par IA et comment elle fonctionne.

2. Maintenez une qualité d'image élevée. Les documents multilingues amplifient tous les problèmes de qualité d'image. Un faible contraste entre l'encre et le papier, des photos inclinées et une basse résolution réduisent davantage la précision sur les écritures non latines que sur l'anglais — car les caractères CJK reposent sur des distinctions de traits fins (ex. : 已 vs 己 vs 巳 en chinois, ou ツ vs シ en katakana japonais) qui deviennent méconnaissables sur des images de mauvaise qualité. Photographiez à angle droit, utilisez un éclairage uniforme et maintenez au moins 200 DPI. De l'encre foncée sur du papier blanc est idéal pour toutes les écritures.

3. Séparez les documents par langue dominante si possible. Si vous avez un lot de 50 factures — 30 en anglais et 20 en coréen — les traiter ensemble fonctionne, mais les traiter par lots séparés permet de vérifier la précision par groupe linguistique. Cela n'améliore pas directement les performances de l'IA, mais rend votre flux de vérification gérable : vous pouvez contrôler rapidement 10 % du lot anglais et concentrer votre temps de relecture sur le lot coréen, où les erreurs sont plus probables.

4. Utilisez la vérification au niveau des champs pour les champs critiques multilingues. Les montants, les numéros de TVA et les dates sont les champs où les erreurs d'extraction ont des conséquences financières. Sur les documents multilingues, ces champs apparaissent souvent en chiffres arabes, quelle que soit la langue environnante — ce qui aide — mais les recouper reste l'assurance la moins chère possible. Une relecture de 30 secondes des cinq champs les plus importants par document est plus rapide que de corriger un paiement envoyé au mauvais numéro de TVA.

5. Utilisez la structure du document comme point d'ancrage. Les formulaires structurés avec des champs étiquetés sont le cas d'usage le plus solide pour l'extraction IA multilingue. Si vos documents multilingues sont principalement des formulaires — factures, déclarations en douane, documents fiscaux — les étiquettes des champs fournissent des ancres sémantiques qui améliorent considérablement la précision multilingue. L'IA lit « Total (합계) » sur une facture fiscale coréenne et sait qu'elle doit extraire le montant, même si l'étiquette est en coréen et que la valeur peut contenir des codes de devise anglais. Plus vos documents sont structurés, moins la langue a d'importance.

Documents réels où l'IA lit plusieurs langues

Ce ne sont pas des hypothèses. Ce sont des documents qui traversent les frontières linguistiques dans le monde réel — et l'IA traite chacun différemment.

Factures fiscales électroniques coréennes (전자세금계산서). Depuis que la Corée du Sud a rendu les factures fiscales électroniques obligatoires en 2023, chaque transaction commerciale génère un document numérique structuré — mais les données doivent encore être intégrées dans les systèmes comptables. Une facture fiscale coréenne typique contient : un nom et une adresse de fournisseur coréen (Hangul), un nom d'acheteur coréen (Hangul), des descriptions d'articles en coréen avec parfois des codes produits en anglais, et des montants en chiffres arabes avec la notation de la devise coréenne (₩). L'IA lit les champs Hangul pour les noms et adresses, le contenu mixte pour les descriptions d'articles, et les champs numériques pour les montants — en un seul passage d'extraction. Le champ clé qui piège les modèles non entraînés au coréen : le numéro d'enregistrement d'entreprise (사업자등록번호), un identifiant à 10 chiffres suivant un format spécifique et souvent imprimé à un endroit unique sur la facture. Pour en savoir plus sur ce type de document, consultez notre guide sur l'extraction de données de factures fiscales coréennes vers Excel.

Formulaires douaniers et de conformité multilingues de l'UE. Une déclaration d'importation de l'UE contient généralement les mêmes données répétées dans deux à trois langues — le nom de l'expéditeur en français, le nom du destinataire en allemand, la description des marchandises en anglais. Une seule page peut passer d'une langue latine à une autre quatre ou cinq fois. C'est le scénario multilingue le plus simple pour l'IA car toutes les langues partagent la même famille d'écriture : l'IA traite les sections françaises, allemandes et anglaises de manière identique, et la précision reste supérieure à 95 %. Le changement de langue est transparent pour le modèle. Les équipes logistiques transfrontalières traitant des centaines de ces formulaires par jour peuvent les traiter par lots sans les trier par langue — l'IA gère le mélange nativement. Pour une vue d'ensemble, voir l'extraction de données de factures internationales sur tous les marchés.

Documents d'expédition japonais/anglais. Une liste de colisage d'exportation japonaise contient des noms de produits en japonais (Kanji + Katakana), des quantités et poids en chiffres arabes, et des adresses de destination en anglais. Le texte japonais comprend les trois écritures — Kanji pour le nom du produit (自動車部品 = pièces automobiles), Katakana pour le terme dérivé de l'anglais (ブラケット = bracket), et caractères latins pour les numéros de modèle (ABC-1234). L'IA lit les quatre systèmes d'écriture sur la même ligne et place les valeurs extraites dans leurs colonnes correctes. Le plus grand risque est la confusion Katakana-Anglais : des mots comme "テーブル" (tēburu, "table") rendus phonétiquement en Katakana peuvent être confondus avec du texte anglais par des moteurs OCR naïfs, mais les modèles de vision qui comprennent les conventions d'écriture japonaises gèrent correctement la distinction.

Contrats bilingues chinois/anglais. Les contrats commerciaux transfrontaliers entre entités chinoises et anglophones présentent souvent chaque clause dans les deux langues — le texte chinois au-dessus ou en dessous de la traduction anglaise. La mise en page peut être en colonnes côte à côte ou en paragraphes empilés. Pour l'extraction de données (par exemple, l'extraction des dates de contrat, des noms de parties et des conditions de paiement), l'IA bénéficie de la redondance : elle peut lire les mêmes données à partir de l'une ou l'autre version linguistique, et la double représentation améliore en fait la précision car les données manquantes ou ambiguës dans une langue peuvent être recoupées avec l'autre. Le flux de travail pratique : extraire de la version anglaise comme source principale (précision plus élevée) et utiliser la version chinoise comme vérification pour les champs financiers critiques.

Questions fréquentes

L'IA peut-elle extraire des données d'un document mélangeant trois langues ou plus ?

Oui — avec des réserves. Si toutes les langues partagent la même famille d'écriture (ex. français/allemand/anglais = toutes latines), l'IA les traite de manière transparente sans perte de précision. Si le mélange traverse des familles d'écriture (ex. anglais + coréen + arabe sur une même page), la précision dépend de l'écriture la moins précise du mélange : un document avec 80 % d'anglais et 20 % d'arabe aura une précision de niveau latin pour la partie anglaise et une précision de niveau arabe (~75–85 %) pour la partie arabe. L'IA ne réduit pas la précision sur les parties faciles simplement parce que des parties difficiles sont présentes — chaque zone de texte est traitée indépendamment.

L'IA doit-elle connaître à l'avance les langues présentes dans le document ?

Non. Les modèles de vision modernes détectent automatiquement les langues en lisant la page — vous n'avez pas besoin de présélectionner « anglais + coréen » ni de configurer des modules linguistiques. C'est l'un des plus grands avantages des modèles de vision-langage par rapport à l'OCR traditionnel : là où Tesseract exige de spécifier la langue avant le traitement (et se trompe si vous devinez mal), un VLM lit la page et reconnaît à la volée l'écriture utilisée par chaque zone de texte. La détection des langues du modèle est intégrée à sa compréhension visuelle, et non ajoutée comme une étape séparée.

Comment l'IA gère-t-elle les documents mêlant des langues s'écrivant de droite à gauche comme l'arabe avec de l'anglais ?

Elle les gère — mais c'est le scénario multilingue le plus difficile. L'IA doit détecter l'écriture A (de gauche à droite, ex. anglais) et l'écriture B (de droite à gauche, ex. arabe) sur la même page, appliquer le sens de lecture correct à chaque segment et maintenir la relation sémantique entre eux. La précision sur les pages véritablement à sens de lecture mixte chute à 65–80 %. Pour les documents où le contenu RTL se trouve dans des blocs spatialement séparés (ex. un en-tête arabe au-dessus d'un tableau anglais), la précision est plus élevée. Pour les documents où les textes RTL et LTR sont entrelacés dans la même phrase ou le même paragraphe — une description de produit en anglais avec un numéro de pièce en arabe intercalé — attendez-vous à vérifier les résultats manuellement.

L’IA peut-elle lire du texte manuscrit en japonais, chinois ou coréen ?

Partiellement. Le même cadre de précision pour la reconnaissance manuscrite s’applique aux écritures CJK qu’au latin, mais avec une difficulté supplémentaire : les caractères CJK reposent sur l’ordre et le placement précis des traits, que les variations manuscrites perturbent plus gravement que les lettres latines. Un 口 (bouche/ouverture, un carré simple de 3 traits) écrit à la main peut ressembler à un cercle, un ovale ou une boîte griffonnée selon le scripteur. Le japonais manuscrit est plus difficile que le coréen manuscrit (le hangeul est plus systématique avec moins de formes uniques), et les deux sont plus difficiles que l’anglais manuscrit. Attendez-vous à une baisse de précision de 20 à 35 % entre le CJK imprimé et le CJK manuscrit. Pour plus de détails sur le défi de l’écriture manuscrite, consultez notre guide complet sur la reconnaissance IA de l’écriture manuscrite.

Ai-je besoin d’un outil d’IA différent pour chaque langue ?

Non — si vous utilisez un outil d’extraction basé sur un modèle vision-langage. Le même modèle qui lit une facture anglaise lit une facture fiscale coréenne et un bon de commande allemand. C’est l’un des avantages pratiques de l’approche vision-langage : vous gérez un seul outil, un seul flux de travail et un seul format de sortie, quel que soit le nombre de langues de vos documents. La contrepartie est l’effort de vérification : vous passerez plus de temps à examiner les résultats des documents non latins que ceux en anglais. Mais vous n’aurez pas besoin d’outils, de connexions ou de flux de travail séparés.

Qu’en est-il des langues avec très peu de ressources numériques — comme le birman, l’amharique ou le lao ?

C’est dans ces langues peu dotées que la précision chute le plus. L’écart de performance entre les grandes langues mondiales et les écritures sous-dotées est plus grand qu’entre deux grandes langues. Un modèle qui traite le coréen à 85 % de précision peut traiter le birman à 50–60 %, car le volume de données d’entraînement est des ordres de grandeur plus faible. Google Document AI est l’option la plus solide pour la couverture des langues rares (200+ langues), mais pour les langues vraiment peu dotées, attendez-vous à tester sur vos documents avant de vous engager dans un flux de travail — les affirmations des fournisseurs sur le support linguistique se traduisent rarement par une précision exploitable en production pour les écritures hors du top 50.

L'IA peut-elle traiter des documents où la langue change en milieu de phrase ?

On parle d'alternance codique, fréquente dans les documents professionnels de régions multilingues — une facture de Hong Kong peut indiquer « Delivery to 中環辦公室 by 3pm ». Les modèles de vision modernes gèrent bien cela au sein des familles de script latin, et raisonnablement bien pour les paires latin/CJK mixtes. Le modèle n'a pas besoin de changer de module linguistique en milieu de phrase ; il lit la chaîne entière comme une entrée visuelle continue et reconnaît chaque caractère ou mot dans son propre script. La précision sur l'alternance codique en milieu de phrase est plus élevée que sur les paragraphes mixtes, car la fenêtre de contexte reste petite et les signaux (formes des caractères, appartenance à un jeu de caractères) sont univoques au niveau des tokens.

Pour une compréhension plus large de ce que l'extraction documentaire par IA peut et ne peut pas faire, commencez par ce qu'est l'extraction documentaire par IA et comment elle fonctionne. Si vous traitez spécifiquement avec l'écriture manuscrite dans plusieurs langues, notre guide sur la précision de la reconnaissance de l'écriture manuscrite par IA couvre l'intersection de ces deux problèmes difficiles. Et si vous avez besoin d'extraire des données sans configurer de modèles ni d'apprentissage — ce qui est encore plus important pour les documents multilingues où aucun format ne se ressemble — consultez si l'IA peut extraire des données sans modèles.