Pourquoi les petites polices cassent
la précision OCR — 4 causes racines et 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 :

✗ = peu fiable    ⚠ = limite    ✓ = généralement fiable pour du texte imprimé. Ce sont des estimations de hauteur de caractères — la reconnaissance dépend aussi de l'épaisseur du trait, du contraste et de la police.

Le tableau montre clairement la tendance : à 300 DPI standard, le texte en 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 en dessous de 10 pt est limite ou peu fiable. En descendant à 150 DPI (courant pour les fax et les PDF de faible qualité), seuls le 12 pt et au-dessus sont fiables.

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

La cause la plus fréquente d'échec d'extraction des petites polices est une résolution de numérisation trop faible pour le texte cible. Le problème n'est pas que le scanner lui-même soit inadéquat, mais que le processus de numérisation a été conçu pour du texte lisible (corps de texte ~10-12 pt) et que personne ne l'a adapté aux caractères plus petits présents 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 critique : À 200 DPI, un caractère de 8 pt — 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 indiscernables car le contrepoinçon ouvert (l'espace intérieur de la lettre) se réduit à 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 régulièrement des erreurs d'extraction sur les sections en petites polices 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 d'incriminer 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 l'interaction entre la qualité d'image et la précision d'extraction selon les types de documents, consultez notre guide sur la faible précision OCR des documents numérisés.

Cause 2 : Le choix de 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 réellement utilisable pour la reconnaissance :

Sans-serif vs. serif en petites tailles. Une police serif comme Times New Roman ajoute des empattements décoratifs aux extrémités des jambages. À 10 pt et plus, ces empattements aident la lisibilité. À 6-8 pt sur un scan à 200 DPI, les empattements fusionnent avec le jambage 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 permet à leurs formes plus simples de mieux survivre à une numérisation basse résolution. La documentation de Tesseract elle-même et plusieurs recommandations de bibliothèques préconisent spécifiquement les polices sans-serif pour les documents adaptés à l'OCR.

Graisses fines/légères. Les variantes "Light" ou "Thin" d'une famille de polices — populaires dans le design de marque moderne, les en-têtes de rapports financiers et les interfaces minimalistes — utilisent des traits qui peuvent n'avoir qu'1 pixel de large aux résolutions de numérisation courantes. Une épaisseur 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 Bold et Regular, avec des épaisseurs de trait de 2 à 3 pixels à la même résolution, ont une tolérance significativement plus grande pour ces artefacts.

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

Le constat pratique : si le texte de petite taille sur votre document utilise une police sans-serif moderne et légère (courante dans les relevés bancaires européens, les factures SaaS et les rapports d'investissement), des erreurs d'extraction apparaîtront à des tailles où une police plus grasse ou plus chargée 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 : Vouloir 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 les plus fréquentes de frustration avec l'extraction de petites polices.

De nombreux utilisateurs abordent l'extraction avec l'idée que tout ce qui se trouve sur la page doit être récupéré : chaque ligne, chaque avertissement, chaque note de bas de page, chaque annotation marginale. Lorsqu'un avertissement juridique en 6pt 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é parfaitement extraits — l'échec était limité à une section de texte dont aucun flux de travail réel n'a besoin.

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

• Champs critiques (10pt+) — numéros de facture, totaux, dates, noms de fournisseurs, numéros de compte, numéros de police. Ceux-ci sont presque toujours dans une taille de police lisible et portent le poids financier ou opérationnel. Extrayez-les avec une grande confiance.
• Champs complémentaires (8-10pt) — codes de référence, noms de service, ventilations fiscales, champs de quantité. Généralement extractibles à 300 DPI, peut-être marginaux à des résolutions inférieures. Signalez-les pour une vérification ponctuelle.
• Texte accessoire (moins de 8pt) — mentions légales, avis 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 complètement 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 par 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 sa capacité de traitement sur des sections de document que vous n'avez jamais demandées. Si une colonne contient une valeur provenant d'une zone de 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 vraiment 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 produit certaines des défaillances d'extraction les plus déroutantes. Elle n'affecte que les captures d'écran — mais comme une fraction croissante du traitement de documents commence par des captures (exportations 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 clarté du texte sur les écrans LCD. La technique fonctionne en adressant individuellement les sous-pixels rouges, verts et bleus 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 traitant 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 limites des caractères — qui perturbent la détection des contours, la binarisation et la segmentation des caractères.

Les moteurs OCR traditionnels qui reposent 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 de 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, la limite du caractère se déplace de manière imprévisible. Aux tailles de document normales (10-12pt), l'artefact est petit par rapport au caractère et le moteur OCR peut encore deviner correctement. À 6-8pt, 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 : Suréchantillonnage par super-résolution — À utiliser avec prudence

Le suréchantillonnage par IA (super-résolution, ou SR) peut agrandir un scan à 150 DPI pour atteindre un 300 DPI apparent en interpolant de nouveaux pixels entre les existants. Les résultats sur les textes en petits caractères sont mitigés : un simple suréchantillonnage par plus proche voisin ou bilinéaire n'ajoute pas d'information — 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 certains détails de tracé sur des textes modérément dégradés, en particulier sur des caractères imprimés à fort contraste. Pour les textes en petits caractères qui manquent déjà de caractéristiques distinctives au niveau des pixels, la SR ne peut pas inventer des détails qui n'ont jamais été capturés — elle peut produire un résultat visuellement plus lisse sans réellement améliorer la précision au niveau des caractères. Le cas d'usage le plus fiable pour la SR est l'agrandissement de textes provenant d'un scan déjà en 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 télécopie.

Pour les techniques de prétraitement qui fonctionnent avant l'extraction, y compris le suréchantillonnage, la binarisation et le 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 télécopie à 150 DPI et que les descriptions des lignes en corps 7 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 nette. Ce correctif n'est pas toujours disponible (certains fournisseurs hérités n'utilisent que la télécopie, certains formulaires gouvernementaux n'existent qu'en format imprimé fixe), mais il est plus souvent disponible que ce que les équipes supposent. Le coût d'une demande par courriel est inférieur au coût de la correction manuelle de 50 erreurs d'extraction sur un lot.

La limite honnête : en dessous de 7 pt, aucun système n'est fiable

Aucune amélioration de précision, ajustement de flux de travail ou mise à niveau d'outil ne permettra d'extraire de manière fiable un texte en 6 pt à partir d'un scan à 200 DPI. Le budget pixel est tout simplement insuffisant. La précision de reconnaissance des textes imprimés en dessous de 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 de langage visuel moderne. La marge sur ce nombre en 6 pt sur votre facture ne pourra pas être extraite avec une précision de 99 % au niveau du champ, et la réponse responsable est de prévoir une vérification manuelle ou une omission plutôt que de passer du temps à optimiser un flux autour d'une entrée que la physique de la numérisation ne peut pas supporter.

Cette limite s'applique à tous les systèmes actuellement en production. Pas seulement Tesseract, pas seulement l'OCR hérité — elle s'applique à Google Cloud Vision, Amazon Textract et aux outils basés sur des modèles de langage visuel. La différence entre ces outils sur les textes en petits caractères se mesure en points de pourcentage, pas en ordres de grandeur. Les modèles d'IA visuelle ont un avantage sur les textes en dessous de 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 facture familiers, elle peut en déduire les valeurs correctes — mais cette supposition contextuelle a une limite. Lorsque les caractères en dessous d'un certain seuil de pixels sont véritablement ambigus, l'inférence n'est qu'une supposition éclairée.

Pour une vue d'ensemble 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équentes