Pourquoi votre OCR produit-il
du texte illisible ? 3 causes racines et solutions

Si vous voyez un texte illisible, vous n'êtes pas seul. Une communauté Reddit existe uniquement pour aider à identifier la langue que votre mojibake « pourrait être ». Le forum de la communauté Adobe Acrobat compte des dizaines de fils non résolus d'utilisateurs dont l'OCR japonais a produit des chaînes comme 蟷ｴ莉｣繧｢繧ｸ繧｢縺ｫ縺翫¢繧九げ繝ｭ繝ｼ繝舌Ν蛹悶� au lieu d'un texte lisible. La bibliothèque Python ftfy — un outil dédié à la correction du mojibake — a été téléchargée des millions de fois, car il s'agit d'un problème récurrent dans tout le secteur.

Bonne nouvelle : un texte OCR illisible n'est pas un dommage aléatoire. Il suit des schémas prévisibles causés par l'un des trois mécanismes racines. Une fois le schéma identifié, la correction est reproductible.

Cause 1 — Décalage d'encodage : le coupable le plus fréquent

Le symptôme : Les caractères accentués, les symboles monétaires et les guillemets intelligents se transforment en charabia multi-caractères. L'espagnol corazón devient corazón. Le symbole euro € apparaît comme €. Les guillemets courbes “ressemblent à ça”. Le document est globalement lisible, mais chaque caractère non ASCII est erroné.

Pourquoi cela arrive : L'encodage des caractères est l'accord entre un fichier et un lecteur sur la façon de mapper les octets en lettres. Lorsque le moteur d'OCR lit le fichier avec un encodage (disons UTF-8) mais que le fichier a été créé avec un autre (disons Windows-1252), les mêmes octets correspondent à des caractères complètement différents. Le résultat est une corruption systématique — comme lire une carte dessinée en pouces comme si c'était des centimètres. Chaque mesure est décalée du même facteur, et le schéma d'erreur vous indique exactement quelle conversion a été appliquée.

Comment identifier le problème d'encodage

Certains motifs de mojibake sont si caractéristiques qu'on peut diagnostiquer l'erreur d'encodage rien qu'en regardant le résultat :

Comment corriger les erreurs d'encodage

Option 1 : Réenregistrer avec le bon encodage. Ouvrez le document source (ou le résultat OCR) dans un éditeur de texte comme VS Code ou Notepad++ qui permet de changer explicitement l'encodage. Utilisez Enregistrer sous → UTF-8. Si le fichier était en Windows-1252, le réenregistrer en UTF-8 avec une détection correcte des caractères résout souvent le problème.

Option 2 : Utiliser des outils de réparation mojibake. Pour des corrections en masse ou automatisées, la bibliothèque Python ftfy (pip install ftfy) détecte et inverse automatiquement les erreurs d'encodage courantes — y compris les corruptions multicouches où le texte a été décodé avec le mauvais encodage, puis réencodé, puis redécodé de travers. Un simple appel à ftfy.fix_text() résout la grande majorité des erreurs d'encodage simple ou double.

Option 3 : Forcer le moteur OCR à relire la couche image au lieu de la couche texte. De nombreux problèmes de texte illisible dans les PDF viennent du fait que le PDF sous-jacent a une couche texte corrompue ou encodée de façon personnalisée, alors que la couche image visuelle est parfaitement correcte. Si vous configurez votre outil OCR pour traiter la page comme une image (plutôt que d'extraire la couche texte existante), il reconnaîtra tous les caractères à partir des glyphes rendus — contournant ainsi les dommages d'encodage. Dans Adobe Acrobat, cela signifie choisir « ClearScan » ou « Image consultable (exact) » au lieu de « Image consultable (compressé) » dans les paramètres OCR.

Cause 2 — Encodage des polices : quand le glyphe est correct mais le code caractère est erroné

Le symptôme : Le PDF s'affiche parfaitement à l'écran — chaque caractère semble correct — mais copier le texte ou exécuter une OCR produit du charabia : GLYPH<38>, 9%)A:\2A, ou des séquences de caractères répétées sans signification. La page visuelle est nette ; la couche texte est un désastre.

Pourquoi cela arrive : Un fichier PDF possède deux couches de « texte » : les glyphes visuels (ce que vous voyez à l'écran) et le mappage caractère-à-glyphe (ce que lit un extracteur de texte ou un moteur d'OCR). Normalement, ces deux couches concordent. Mais dans les PDF mal générés, le fichier de police peut contenir un encodage de glyphes personnalisé — les formes des glyphes sont correctes (donc la page semble bonne), mais les codes caractères auxquels elles correspondent sont non standard ou totalement dépourvus de correspondances Unicode.

Cette situation est étonnamment courante. Les polices subset — où seuls les caractères exacts utilisés dans le document sont inclus — utilisent souvent des identifiants de caractères (CID) non standard pour le mappage interne. Lorsqu'un extracteur de texte tente d'interpréter ces CID à l'aide d'une table d'encodage standard, il obtient du charabia. Un problème signalé sur le projet Docling montrait exactement cela : un PDF s'affichait correctement, l'OCR était réglée sur do_ocr=True, et le résultat était '() +,- .+.. /01 02034567638469:; 4<8:=> — car l'encodage interne de la police ne correspondait pas à l'Unicode standard.

Scénarios où le charabia d'encodage de police est le plus probable :

• PDF générés par des logiciels spécialisés : Les outils de CAO (AutoCAD, Archicad), les générateurs de rapports ERP, ou les pilotes d'impression vers PDF hérités intègrent souvent des polices avec des tables d'encodage personnalisées. Une discussion communautaire sur les forums Adobe décrit un utilisateur d'Archicad dont les PDF contenaient Segoe UI intégrée — et produisaient toujours du texte brouillé, car l'intégration seule ne garantit pas un mappage de caractères standard.
• Documents PDF/A ou signés numériquement : Les formats de documents axés sur la conformité suppriment ou modifient parfois les informations de mappage de caractères lors du processus de conversion.
• Documents scannés avec une couche de texte cachée ajoutée par un précédent passage OCR : Si l'OCR antérieure a produit des caractères incorrects et que le PDF a été enregistré avec cette couche de texte intégrée, l'extraction ultérieure lit le mauvais texte mis en cache au lieu d'exécuter une nouvelle reconnaissance.
• Documents avec des écritures non latines : Les polices japonaises Shift-JIS, coréennes EUC-KR et chinoises GB-encodées sont des sources fréquentes de décalage d'encodage lorsque le visualiseur PDF ou le moteur d'OCR utilise par défaut une page de codes différente.

Comment corriger les caractères illisibles dus au codage de police

Option 1 : Forcer une nouvelle OCR sur le calque image. C'est la solution la plus fiable. Dites à votre outil d'OCR d'ignorer le calque de texte existant et de lire directement les images de page rendues. Dans Acrobat Pro, allez dans Outils → Analyse et OCR → Reconnaître le texte → Dans ce fichier et assurez-vous que le moteur d'OCR traite le document comme une image numérisée. Avec ocrmypdf, utilisez l'option --force-ocr pour écraser entièrement le calque de texte existant.

Option 2 : Convertir en format d'image sans perte et relancer l'OCR. Exportez les pages PDF en fichiers TIFF ou PNG haute résolution (au moins 300 DPI), puis exécutez l'OCR sur ces images. Cela supprime toutes les métadonnées de codage de police défectueuses et fournit au moteur d'OCR une source visuelle propre. Le fil de discussion de la communauté Adobe Acrobat sur le mojibake japonais a montré que l'exportation en TIFF et la ré-OCR résolvaient le problème là où l'OCR directe du PDF avait échoué.

Option 3 : Vérifier l'incorporation des polices avec Preflight. Dans Adobe Acrobat Pro, utilisez Outils → Production d'impression → Preflight et exécutez un profil d'analyse des polices. Cela vous indique si les polices sont entièrement incorporées, incorporées en sous-ensemble, ou manquantes, et si elles incluent des tables de caractères Unicode. Si une police est incorporée en sous-ensemble sans tables /ToUnicode appropriées, c'est la preuve irréfutable.

Cause 3 — Résolution et confusion des caractères : quand la qualité d'image laisse l'OCR tomber

Le symptôme : Des caractères individuels sont erronés de manière à ressembler à des substituts raisonnables : 5 devient S, 0 devient O, 1 devient l (L minuscule), rn devient m. La ponctuation disparaît. Les traits fins dans des caractères comme e ou a sont manquants, donnant aux mots un aspect abrégé. Le résultat n'est pas totalement inutilisable — il est subtilement, frustrant, erroné.

Pourquoi cela se produit : Les moteurs d'OCR fonctionnent en faisant correspondre les formes des caractères à des modèles de glyphes connus. Lorsque l'image d'entrée a une résolution insuffisante, les pixels disponibles ne suffisent pas à distinguer des caractères visuellement similaires. Une lettre S à 72 DPI occupe environ 10 à 12 pixels verticalement — à cette résolution, l'empattement d'un 5 et la courbe d'un S peuvent sembler identiques. Ce n'est pas un problème de codage ; c'est une contrainte fondamentale de la théorie de l'information. Si l'image ne contient pas assez de pixels pour représenter les caractéristiques distinctives de chaque caractère, aucun moteur d'OCR, aussi avancé soit-il, ne peut faire une supposition parfaite à chaque fois.

Cette classe d'erreurs est particulièrement fréquente dans :

• Les photos de documents prises avec un téléphone en faible luminosité ou en angle
• Les pages faxées ou photocopiées à plusieurs reprises où chaque génération perd des détails
• Les anciens scans de microfilms de documents historiques
• Les documents avec des petites tailles de police (8 points ou moins) numérisés à 200 DPI ou moins

Comment corriger le texte illisible lié à la résolution

Option 1 : Augmenter la résolution d’entrée. La norme industrielle pour l’OCR est de 300 DPI minimum, avec 400–600 DPI recommandés pour les textes petits ou denses. Si vous travaillez à partir d’une photo de téléphone, les étapes de prétraitement d’image comme la mise à l’échelle, le renforcement de la netteté et le redressement peuvent aider avant d’envoyer l’image au moteur OCR.

Option 2 : Utiliser un outil d’extraction basé sur la vision plutôt que l’OCR traditionnel. C’est la solution structurelle. Les moteurs OCR traditionnels (Tesseract, ABBYY, Adobe OCR) reposent sur une reconnaissance caractère par caractère — c’est pourquoi un pixel manquant peut transformer un 5 en S. L’extraction par modèle de langage visuel (VLM) (l’approche utilisée par ImageToTable.ai et des outils similaires) lit des mots et phrases entiers comme des objets visuels, en utilisant le contexte sémantique pour lever les ambiguïtés. Quand le moteur voit "Commander S unités" et que le contexte est une facture, il comprend que S est probablement 5 — non pas parce qu’il reconnaît mieux la forme du caractère, mais parce que « Commander 5 unités » a du sens alors que « Commander S unités » n’en a pas. Pour une explication de la différence avec l’OCR traditionnel, lisez ce qu’est l’OCR et d’où viennent ses limites.

Option 3 : Appliquer un prétraitement d’image avant l’OCR. Même un prétraitement simple peut réduire considérablement les confusions de caractères. Convertir en niveaux de gris, appliquer un seuillage adaptatif pour binariser le texte, et supprimer le bruit (taches, motifs de fond) donne au moteur OCR un signal plus propre. Consultez notre guide pour améliorer la précision de l’OCR pour des workflows de prétraitement éprouvés.

Quand passer à autre chose : que faire si aucune solution ne fonctionne

Si vous avez vérifié l’encodage, contrôlé les polices et prétraité l’image — et que le résultat est toujours illisible — l’outil lui-même n’est peut-être pas adapté au type de document. Les documents avec des écritures mixtes, des polices décoratives, des notations mathématiques ou de lourds tampons dépassent les limites de conception de l’OCR traditionnel.

Dans ces cas, la solution pratique est de passer à un outil d’extraction par IA visuelle sans modèle qui lit les documents de manière holistique. Des outils comme ImageToTable.ai contournent complètement les problèmes d’encodage et de police car ils extraient le sens du rendu visuel de la page, et non d’une couche de texte préexistante. Vous téléchargez le document, nommez les colonnes souhaitées, et l’IA extrait les données en comprenant la structure visuelle et sémantique du document — sans couche de texte dépendante des polices, ni tables d’encodage à gérer.

FAQ

Texte OCR illisible : ce n’est pas du hasard — voici la marche à suivre

Quand un texte OCR ressemble à un alphabet mélangé, on a tendance à accuser le logiciel et à passer à autre chose. Pourtant, les trois causes présentées ici — erreurs d’encodage, problèmes de police et confusions liées à la résolution — ont chacune une signature spécifique et une solution adaptée. Apprendre à les distinguer transforme un mystère frustrant en un diagnostic reproductible.

Commencez par le symptôme : caractères parasites autour des accents (comme é) → erreur d’encodage, corrigez par un ré-encodage ou ftfy. Affichage parfait à l’écran mais glyphes sans rapport en sortie OCR → problème de police, corrigez en forçant l’OCR sur l’image. Caractères individuels remplacés par des similaires (5→S) → problème de résolution, corrigez par prétraitement ou un outil contextuel.

La dernière option — passer de l’OCR par caractères à l’extraction visuelle — contourne les causes profondes en lisant le document comme le ferait un humain : comprendre le sens plutôt qu’apparier des motifs de pixels ou parcourir des tables d’encodage.

Testez sur vos propres documents illisibles. Voyez si le problème disparaît quand le moteur ne dépend plus d’une couche texte.