Pourquoi les petites polices nuisent
à la précision de l'OCR — 4 causes profondes et leurs solutions

Le problème, c'est la physique, pas l'IA

Quand un moteur d'OCR ou un modèle de vision IA échoue sur du petit texte, le premier réflexe est d'accuser le logiciel. Mais le vrai goulot d'étranglement se situe avant même tout traitement IA — il est déterminé par le nombre de pixels disponibles par caractère.

Voici le calcul. Un « point » en typographie équivaut à 1/72 de pouce. À 150 DPI (points par pouce, la résolution d'un fax typique ou d'un scanner bas de gamme), la hauteur en pixels d'un caractère est :

hauteur en pixels = taille de police (pt) × DPI / 72

Pour un caractère de 6 pt à 150 DPI :

6 × 150 / 72 = 12,5 pixels

Douze pixels, c'est à peu près la hauteur d'une lettre dans la plus petite police que votre système d'exploitation autorise dans une fenêtre de terminal. Maintenant, voyons ce qui se passe à l'intérieur d'un caractère à cette échelle. Les traits distinctifs qui séparent un « 8 » d'un « 6 » — une boucle fermée en haut contre une boucle fermée en bas — ne couvrent que 2 à 3 pixels au maximum. Un seul pixel de bruit du capteur du scanner, un degré fractionnaire d'inclinaison de la page, ou le bloc de compression JPEG d'une photo de téléphone peuvent effacer complètement cette distinction. Le caractère « m » et la paire « rn » occupent la même largeur de colonne de 2 à 3 pixels aux petites tailles — ils deviennent structurellement identiques.

Ce n'est pas un problème que de meilleur entraînement de l'IA ou un post-traitement OCR plus sophistiqué peut résoudre. Le signal d'entrée ne contient pas l'information nécessaire pour que tout système de reconnaissance produise la sortie correcte. Chaque correctif ultérieur dans cet article contourne cette contrainte ou la réduit — mais la contrainte elle-même est inévitable.

De combien de pixels un caractère a-t-il réellement besoin ?

Pour comprendre quand une petite police devient un problème pratique, il faut faire correspondre la taille de la police et la résolution de numérisation à la hauteur en pixels. Le seuil critique pour la reconnaissance des caractères est d'environ 20-25 pixels de hauteur de caractère pour une discrimination fiable entre des glyphes similaires :

✗ = non fiable    ⚠ = limite    ✓ = généralement fiable pour le texte imprimé. Il s'agit d'estimations de la hauteur des caractères — la reconnaissance dépend également de l'épaisseur du trait, du contraste et de la conception de la police.

Le tableau rend le schéma évident : à 300 DPI standard, le texte de 6 pt se situe juste à la limite. À 200 DPI — la résolution de nombreux imprimantes multifonctions de bureau et de la plupart des documents faxés — tout ce qui est inférieur à 10 pt est limite ou non fiable. Lorsque vous descendez à 150 DPI (courant pour les fax et les PDF de mauvaise qualité), seuls les textes de 12 pt et plus sont fiables.

Cause 1 : Résolution de numérisation inférieure à 200 DPI

La cause unique la plus courante d'échec d'extraction des petits caractères est une résolution de numérisation trop faible pour le texte cible. Le problème n'est pas que le matériel du scanner est inadéquat — c'est que le flux de numérisation a été conçu pour du texte lisible (corps de texte d'environ 10-12 pt) et que personne ne l'a ajusté pour les caractères plus petits qui apparaissent dans les notes de bas de page, les cellules de tableau, les mentions légales et les instructions de formulaire.

Pourquoi 200 DPI est le seuil de danger : À 200 DPI, un caractère de 8 pt — la taille typique de nombreuses valeurs de cellules de tableau et d'étiquettes de formulaire — ne produit que 22 pixels de hauteur. Les caractères comme « e » et « c » deviennent presque indistinguables car le compteur ouvert (l'espace intérieur de la lettre) s'effondre à 1 pixel. La boucle d'un « 8 » et le ventre d'un « 6 » occupent le même espace vertical de 2 pixels. C'est pourquoi les factures faxées et les contrats numérisés produisent systématiquement des erreurs d'extraction sur les sections à petits caractères alors que le corps du texte principal semble correct.

Que vérifier : Si votre PDF numérisé a été produit par un MFP de bureau (imprimante multifonction) réglé sur son mode « qualité standard » par défaut, il est presque certainement à 200 DPI. Les documents faxés arrivent à 100-200 DPI selon l'équipement de l'expéditeur. Avant de blâmer l'outil d'extraction, vérifiez le DPI effectif de l'image d'entrée : ouvrez les propriétés du fichier dans n'importe quel visualiseur d'images et divisez la largeur en pixels par la largeur physique de la page en pouces. Si le résultat est inférieur à 250 DPI et que votre document contient du texte en dessous de 10 pt, la résolution est probablement la cause racine.

Pour en savoir plus sur la façon dont la qualité d'image interagit avec la précision d'extraction selon les différents types de documents, voir notre guide sur la faible précision OCR des documents numérisés.

Cause 2 : Le choix de la police amplifie le problème de résolution

Tous les caractères de 8 pt ne se valent pas. La conception de la police détermine la part du budget de pixels disponible réellement utilisable pour la reconnaissance :

Sans-serif vs. serif à petites tailles. Une police serif comme Times New Roman ajoute des traits décoratifs (empattements) aux extrémités des hampes de lettres. À 10 pt et plus, ces empattements aident à la lisibilité. À 6-8 pt sur une numérisation à 200 DPI, les empattements fusionnent avec le trait principal, épaississant le caractère de manière imprévisible et rendant plus difficile la séparation des caractères adjacents. Les polices sans-serif (Arial, Helvetica, Calibri) n'ont pas ces traits supplémentaires, ce qui signifie que leurs formes plus simples survivent mieux à une numérisation à basse résolution. La documentation de Tesseract elle-même et plusieurs directives de bibliothèques recommandent spécifiquement les polices sans-serif pour les documents adaptés à l'OCR.

Graisses fines/légères. La graisse « Light » ou « Thin » d'une famille de polices — populaire dans le design de marque moderne, les en-têtes de rapports financiers et les interfaces minimalistes — utilise des traits qui peuvent ne faire que 1 pixel de large aux résolutions de numérisation courantes. Une largeur de trait d'un seul pixel signifie que tout bruit, artefact de compression ou variation du capteur du scanner brisera le trait (rendant le caractère invisible) ou l'épaissira de manière asymétrique (modifiant la forme du caractère). Les graisses grasses et régulières, avec des largeurs de trait de 2-3 pixels à la même résolution, ont une tolérance nettement supérieure à ces artefacts.

Polices avec glyphes ambigus. Certaines conceptions de polices rendent les caractères déjà difficiles pour l'OCR encore plus difficiles. Arial, par exemple, rend le « l » minuscule (L) et le « I » majuscule (i) identiques — le seul signal distinctif est le contexte, ce qui manque à l'OCR traditionnel. À petites tailles, cette ambiguïté s'aggrave car toute différence visuelle restante (une fraction de pixel dans l'empattement ou la hauteur de hampe) disparaît entièrement.

Le schéma pratique : si le petit texte de votre document utilise une police sans-serif légère et moderne (courante dans les relevés bancaires européens, les factures SaaS et les rapports d'investissement), vous constaterez des erreurs d'extraction à des tailles où une police plus grasse ou plus chargée en serif produirait encore un résultat lisible. Le choix de la police n'est pas la cause du problème — mais il détermine à quelle hauteur de pixel le problème devient visible.

Cause 3 : Tout extraire au lieu de prioriser

C'est moins un problème technique qu'un problème de conception de flux de travail — mais c'est l'une des sources de frustration les plus courantes avec l'extraction de petites polices.

De nombreux utilisateurs abordent l'extraction avec l'état d'esprit que tout ce qui se trouve sur la page doit être restitué : chaque ligne, chaque avertissement, chaque note de bas de page, chaque annotation marginale. Lorsqu'un avertissement légal en 6 pt en bas d'un relevé bancaire produit un résultat illisible, on a l'impression que toute l'extraction a échoué. En pratique, le corps du texte et les chiffres financiers clés ont peut-être été extraits parfaitement — l'échec était isolé à une section de texte dont aucun flux de travail pratique n'a réellement besoin.

La stratégie de priorisation des champs : Avant d'extraire, séparez le contenu du document en trois catégories :

• Champs critiques (10 pt et plus) — numéros de facture, totaux, dates, noms de fournisseurs, numéros de compte, numéros de police. Ceux-ci sont presque toujours définis dans une taille de police lisible et portent le poids financier ou opérationnel. Extrayez-les avec une grande confiance.
• Champs complémentaires (8-10 pt) — codes de référence, noms de départements, ventilations fiscales, champs de quantité. Généralement extractibles à 300 DPI, éventuellement marginaux à des résolutions inférieures. Signalez-les pour une vérification ponctuelle.
• Texte accessoire (moins de 8 pt) — avertissements légaux, mentions de droits d'auteur, conditions générales, pieds de page, instructions en petits caractères. Ceux-ci sont rarement nécessaires dans un flux de travail de données structurées. Envisagez de les omettre entièrement de l'extraction plutôt que de laisser des erreurs dans ces champs éroder la confiance dans le résultat global.

Lorsque vous utilisez un outil d'extraction IA avec Extraction de colonnes personnalisées (où vous saisissez les noms de colonnes dont vous avez besoin et l'IA localise les valeurs sémantiquement), cette priorisation est intégrée au flux de travail par conception : vous ne définissez que les colonnes pour les données dont vous avez réellement besoin. L'IA ne gaspille pas de capacité de traitement sur les sections du document que vous n'avez jamais demandées. Si une colonne contient une valeur provenant d'une région à petite police, son score de confiance vous donne un indicateur naturel pour une vérification manuelle.

Le même principe s'applique au traitement par lots : si vous extrayez 50 devis de fournisseurs et que les conditions en petits caractères arrivent dans chaque ligne avec une précision variable, demandez-vous si vous avez réellement besoin de ces conditions dans le tableur. Souvent, la réponse est non — et les supprimer améliore à la fois la vitesse d'extraction et la qualité perçue du résultat.

Cause 4 : Artefacts de rendu sous-pixel sur les captures d'écran

Cette cause est presque invisible (littéralement) à l'œil humain, mais elle produit certaines des erreurs d'extraction les plus déroutantes. Elle n'affecte que les captures d'écran — mais comme une part croissante du traitement de documents commence par des captures d'écran (exports de tableaux de bord, factures de portails web, captures d'écran d'applications mobiles), elle concerne plus de flux de travail que la plupart des gens ne le pensent.

Les systèmes d'exploitation modernes utilisent le rendu sous-pixel (ClearType sur Windows, Core Text sur macOS) pour améliorer la netteté du texte sur les écrans LCD. Cette technique fonctionne en adressant les sous-pixels rouge, vert et bleu individuels au sein de chaque pixel d'écran, triplant ainsi la résolution horizontale pour le rendu du texte. Pour votre œil, cela rend le petit texte à l'écran net et bien défini. Pour un moteur OCR qui traite la capture d'écran comme une image plate, le même texte arrive avec des franges colorées — des bords rouges et bleus sur les contours des caractères — qui perturbent la détection des contours, la binarisation et la segmentation des caractères.

Les moteurs OCR traditionnels qui s'appuient sur le seuillage (conversion de l'image en noir et blanc avant la reconnaissance) sont particulièrement sensibles à cet artefact. Lorsque l'étape de binarisation rencontre un bord de caractère avec une frange sous-pixel rouge, elle peut interpréter la frange comme faisant partie du caractère ou comme un objet séparé — dans les deux cas, le contour du caractère se déplace de manière imprévisible. Aux tailles de document normales (10-12 pt), l'artefact est petit par rapport au caractère et le moteur OCR peut encore deviner correctement. À 6-8 pt, la frange sous-pixel peut être aussi large que le trait du caractère lui-même, produisant une sortie qui semble « lire » du bruit coloré au lieu du texte.

Comment tester cela : Si vous obtenez de mauvais résultats à partir d'une capture d'écran mais que le même document scanné à 300 DPI fonctionne bien — et que le texte est suffisamment petit pour que l'œil humain ait du mal à le lire à l'écran — le rendu sous-pixel est un contributeur probable. Essayez de zoomer le navigateur ou l'application à 150 % avant de prendre la capture d'écran, ce qui augmente le budget de pixels par caractère et rend la frange sous-pixel proportionnellement plus petite.

Pour un aperçu plus détaillé des défis d'extraction spécifiques aux captures d'écran, y compris les problèmes de couleur, de contraste et de mise à l'échelle, voir pourquoi l'extraction OCR échoue sur les fonds colorés et les filigranes — bon nombre des mêmes principes de qualité d'image s'appliquent aux captures d'écran avec du petit texte.

Ce qui fonctionne vraiment : une hiérarchie pratique des correctifs

Les correctifs ci-dessous sont classés du plus fort impact / moindre effort au plus faible impact / plus grand effort. Commencez par le haut et arrêtez-vous lorsque la précision est acceptable pour votre flux de travail.

Correctif 1 : Visez 300+ DPI pour les documents avec petits caractères

Si vous contrôlez l'étape de numérisation, c'est l'action la plus efficace. Pour les documents contenant du texte en dessous de 10 pt, numérisez à 400-600 DPI plutôt qu'à 300 DPI standard. Le guide des bonnes pratiques OCR de l'Université de Pittsburgh confirme que 400-600 DPI est recommandé spécifiquement pour les documents à petits caractères. L'inconvénient est une taille de fichier plus grande et un traitement plus lent, mais pour les pages où la précision des petits caractères compte, l'amélioration en vaut la peine. Pour les documents faxés ou envoyés par email dont vous ne contrôlez pas la source, notez la limite de résolution comme une contrainte connue dans votre flux de travail — tous les documents ne peuvent pas être extraits avec une précision égale, et c'est acceptable tant que les attentes sont définies en conséquence.

Correctif 2 : Appliquez une priorisation des champs dans votre conception d'extraction

Révisez vos définitions de colonnes et supprimez tout champ ciblant du texte accessoire en petits caractères. Si la ligne de pied de page en 6 pt contient un numéro d'enregistrement fournisseur que vous n'avez jamais utilisé dans un rapprochement, supprimez la colonne. Chaque colonne supprimée est une source de résultats de faible confiance qui n'a plus besoin de vérification. Lorsque vous utilisez l'extraction de colonnes personnalisées, explorez les signaux de confiance de l'outil — si un champ renvoie systématiquement des valeurs de faible confiance, vérifiez si le texte source est suffisamment petit pour que l'IA devine réellement. Si c'est le cas, décidez si le champ mérite d'être conservé avec une vérification manuelle ou si vous pouvez l'obtenir différemment.

Correctif 3 : Super-résolution (agrandissement) — à utiliser avec prudence

L'agrandissement par IA (super-résolution, ou SR) peut agrandir un scan à 150 DPI en un apparent 300 DPI en interpolant de nouveaux pixels entre les pixels existants. Les résultats sur les textes en petite police sont mitigés : un agrandissement simple par plus proche voisin ou bilinéaire n'ajoute pas de nouvelles informations — il étale simplement les mêmes 12 pixels sur un espace plus grand. Les modèles de super-résolution par IA (SRGAN, ESRGAN, Real-ESRGAN) entraînés sur des images de documents peuvent récupérer une partie des détails des traits sur des textes modérément dégradés, en particulier sur des caractères imprimés à fort contraste. Pour les textes en petite police qui manquent déjà de caractéristiques de pixels distinctives, la SR ne peut pas inventer des caractéristiques qui n'ont jamais été capturées — elle peut produire une sortie visuellement plus lisse sans réellement améliorer la précision au niveau des caractères. Le cas d'utilisation le plus fiable de la SR est l'agrandissement de textes provenant d'un scan déjà à résolution marginale (par exemple, de 200 DPI à 400 DPI) avant de le transmettre à un outil d'extraction — n'attendez pas de la SR qu'elle sauve un texte capturé à une résolution de niveau fax.

Pour les techniques de prétraitement qui fonctionnent avant l'extraction, notamment l'agrandissement, la binarisation et la redressement, consultez notre guide de prétraitement d'images OCR.

Correctif 4 : Demander de meilleurs documents sources lorsque c'est possible

Dans de nombreux flux de travail professionnels — en particulier la comptabilité fournisseurs, la gestion des contrats et le traitement des documents fiscaux — vous avez la possibilité de demander une meilleure source. Si un fournisseur envoie une facture par fax à 150 DPI et que les descriptions des lignes d'article à 7 pt sont systématiquement illisibles, demandez au fournisseur d'envoyer un PDF numérique à la place. Si un sous-traitant soumet une photocopie d'une photocopie d'un formulaire signé, demandez l'original ou une photo propre. Ce correctif n'est pas toujours disponible (certains fournisseurs hérités n'utilisent que le fax, certains formulaires gouvernementaux n'existent que dans un format imprimé fixe), mais il est plus souvent disponible que ce que les équipes supposent. Le coût d'une demande par e-mail est inférieur au coût de la correction manuelle de 50 erreurs d'extraction sur un lot.

La limite honnête : sous 7 pt, l'extraction est peu fiable pour tout système

Aucune amélioration de précision, aucun ajustement de flux de travail ni mise à niveau d'outil ne rendra le texte en 6 pt fiablement extractible à partir d'un scan à 200 DPI. Le budget de pixels n'y est tout simplement pas. La précision de reconnaissance sur du texte imprimé sous 7 pt plafonne à environ 60-80 % au niveau des caractères — soit 20-40 % de caractères mal lus — quel que soit le moteur, qu'il s'agisse d'OCR traditionnel ou d'un modèle vision-langage moderne. La marge sur ce numéro en 6 pt sur votre facture ne sera pas extractible avec une précision de 99 % au niveau du champ, et la réponse responsable consiste à prévoir une vérification manuelle ou une omission plutôt que de passer du temps à optimiser un flux de travail autour d'une entrée que la physique de la numérisation ne peut pas prendre en charge.

Cette limite s'applique à tous les systèmes actuellement en production. Pas seulement Tesseract, pas seulement l'OCR hérité — elle s'applique également à Google Cloud Vision, Amazon Textract et aux outils basés sur des modèles vision-langage. La différence entre ces outils sur du texte en petite police se mesure en points de pourcentage, pas en ordres de grandeur. Les modèles d'IA vision ont un avantage sur le texte sous 7 pt car ils utilisent le contexte environnant pour deviner un caractère manquant — si l'IA voit « Inv_ice N_mber » parmi des en-têtes de factures familiers, elle peut en déduire les valeurs correctes — mais cette supposition contextuelle a une limite. Lorsque des caractères sous un certain seuil de pixels sont véritablement ambigus, l'inférence n'est au mieux qu'une supposition éclairée.

Pour une vue plus large des attentes en matière de précision selon les types de documents et les conditions, consultez notre guide pratique pour améliorer la précision de l'OCR.

Questions fréquemment posées