Pourquoi votre OCR omet-il les points décimaux
et les symboles monétaires ?

Le coût dépasse un simple chiffre erroné à l'écran. Selon les exigences de conformité SOX, les sociétés cotées en bourse doivent tenir des registres financiers complets et exacts — une erreur de point décimal dans un pipeline automatisé constitue une exposition à la conformité. Pour toute entreprise, un paiement de 15 499,00 $ sur une facture de 154,99 $ signifie un trop-payé de 15 344,01 $ jusqu'à ce que la clôture de fin de mois le détecte. La plupart des moteurs OCR annoncent une précision de 99 % au niveau des caractères, mais ce chiffre est trompeur lorsqu'une seule erreur de caractère dans un champ numérique peut casser une ligne entière de données. Voici ce qui cause ces erreurs au niveau des pixels — et comment les éviter.

Cause 1 : La compression basse résolution efface les petits points

Un point décimal dans une police de 10 pt ne fait que 3 à 5 pixels de large à 100 DPI. À 72 DPI — la résolution de la plupart des captures d'écran — il se réduit à environ 2 pixels. La compression JPEG traite les images par blocs de 8×8 pixels, et un point de 2 pixels dans un bloc majoritairement blanc est traité comme du bruit et supprimé.

C'est ainsi que 154,99 $ devient 15499 $ — le point décimal entre 4 et 9 disparaît simplement, et les valeurs auparavant distinctes 154 et 99 fusionnent en un seul nombre 100 fois plus grand que l'original. Le même mécanisme affecte les montants de lignes, les prix unitaires, les totaux de taxes et tout autre champ dépendant d'une composante fractionnaire à deux chiffres.

L'effet s'aggrave avec un mauvais éclairage — les ombres ou les reflets autour d'un point décimal rendent encore plus difficile pour le filtre de binarisation (conversion de la couleur en pixels noir et blanc) de distinguer le point de son arrière-plan. Une fois le point disparu dans l'image binarisée, aucun modèle de langage ne peut le récupérer — car le moteur ne l'a jamais vu.

Cause 2 : Confusion due à la proximité du symbole monétaire

Les symboles monétaires se trouvent dans un angle mort pour la plupart des moteurs d'OCR. Le signe dollar ($), le symbole euro (€), le signe livre (£) et le signe yen (¥) sont des caractères décoratifs qui apparaissent immédiatement avant ou après une valeur numérique. L'OCR traditionnel les traite comme des glyphes isolés à identifier, et il se trompe fréquemment.

Trois modes de défaillance distincts affectent les symboles monétaires en pratique :

• Le symbole est entièrement supprimé — le moteur d'OCR décide que 1 234,56 $ devrait simplement être 1 234,56, supprimant silencieusement l'indicateur de devise. Cela crée une sortie ambiguë : 1 234,56 est-il en USD, en EUR ou dans une autre unité ? Lorsque des données provenant de plusieurs fournisseurs ou devises sont fusionnées dans une seule feuille de calcul, la perte du marqueur de devise rend impossible de déterminer quelles valeurs sont comparables.
• Le symbole est mal lu comme une lettre ou un chiffre — $ est fréquemment lu comme S ou 5. £ peut être lu comme un L majuscule ou un E stylisé. Ces substitutions produisent une sortie comme S1 234,56, que les systèmes en aval peuvent interpréter comme une chaîne plutôt que comme une valeur numérique, provoquant des erreurs de conversion de type lors des importations de bases de données ou des formules Excel.
• Le symbole fusionne avec un chiffre adjacent — lorsqu'un signe $ est imprimé dans une police grasse ou serif et se trouve près du premier chiffre, l'OCR peut lire la région combinée comme un seul caractère. 5 $ devient 55 ou 95 selon les détails de la police.

La confusion des symboles monétaires est frustrante car la sortie passe un examen visuel rapide — les chiffres semblent corrects — mais l'information sur quelle devise ces chiffres représentent a été perdue. C'est pourquoi la précision au niveau du champ importe plus que la précision au niveau du caractère dans le traitement de documents financiers.

Cause 3 : Flou d'anticrénelage sur les petits caractères

L'anticrénelage (lissage des polices) rend les contours des caractères sous forme de dégradés de pixels partiellement remplis pour créer l'illusion de courbes lisses. Pour les grands corps de texte, cela améliore la lisibilité, mais pour les petits caractères comme les points décimaux et les symboles monétaires, c'est l'inverse.

Un point décimal rendu en 8 pt ou 9 pt — courant dans les tableaux de lignes de factures ou les mentions en petits caractères sur les reçus — a si peu de pixels que tout lissage le fond dans l'arrière-plan. Lorsque le moteur OCR applique la binarisation (conversion de l'image en noir et blanc), le point devient une tache grise qui tombe sous le seuil de confiance, et le moteur ne produit rien pour cette position.

Il en va de même pour les signes moins des montants négatifs, les parenthèses utilisées pour les crédits, et les traits fins des symboles monétaires comme ¥ ou € — tous fréquemment rendus en très petite taille dans des cellules de tableau denses où l'anticrénelage est le plus destructeur.

Cause 4 : Ambiguïté des conventions de virgule et de point décimal

Un seul caractère — le point ou la virgule — porte des significations opposées selon l'origine du document. Aux États-Unis, 1,234.56 utilise une virgule comme séparateur de milliers et un point comme point décimal. Dans la majeure partie de l'Europe continentale, la même valeur écrite apparaît comme 1.234,56 — le point comme séparateur de milliers, la virgule comme point décimal. Un moteur OCR sans contexte régional n'a aucun moyen fiable de les distinguer.

Un système OCR conçu pour les factures américaines rencontrant un 1.234,56 allemand peut le diviser en deux nombres (1 et 234,56) ou supprimer les deux séparateurs entièrement (123456), gonflant la valeur par 100×. Dans les deux cas, des données corrompues entrent silencieusement dans le système comptable.

Le problème s'aggrave avec les documents de régions mixtes — un fournisseur français utilisant des virgules décimales mais des étiquettes de champs en anglais perturbe les outils OCR basés sur la locale qui s'attendent à une seule convention régionale.

Comment résoudre le problème : un cadre de diagnostic basé sur les symptômes

Toutes les erreurs de décimale et de devise n'ont pas la même cause racine. Utiliser le mauvais correctif fait perdre du temps et ne résout pas le vrai problème. Le tableau ci-dessous associe le symptôme observé dans votre sortie extraite à la cause la plus probable et au correctif correspondant.

Correctif 1 : Améliorer la qualité de l'image source

Le correctif le plus efficace est aussi le plus simple : donner plus de pixels au moteur OCR. Un point décimal à 300 DPI occupe environ 9 pixels — assez pour que la compression JPEG ne puisse pas l'éliminer comme bruit. À 600 DPI, ce même point s'étend sur 18 pixels et survit aux réglages de compression agressifs.

• Numériser à 300 DPI minimum — 200 DPI est le minimum absolu ; 300 DPI est la norme fiable pour les documents financiers. Utilisez un scanner à plat plutôt qu'un appareil photo de téléphone lorsque c'est possible.
• Enregistrer en TIFF ou PNG, pas en JPEG — la compression avec perte du JPEG est la cause principale de la perte des points décimaux. Le TIFF et le PNG préservent les points de 2 à 3 pixels que le JPEG élimine.
• Pour les photos de téléphone — photographiez directement au-dessus, sur une surface bien éclairée, et exportez à la résolution maximale de l'appareil. Recadrez précisément sur la zone du document pour maximiser la densité de pixels sur la zone de texte.

Correctif 2 : Utiliser les indications de type de champ

C'est le correctif que la plupart des outils OCR généralistes ne peuvent pas offrir — et le plus efficace pour les données financières. Lorsque vous indiquez au système qu'un champ est un montant en devise, il traite le point décimal et le symbole monétaire comme des signaux sémantiques sur la valeur, et non comme des caractères ordinaires.

Dans ImageToTable.ai, cela fonctionne grâce à l'Extraction de colonnes personnalisées : vous définissez des colonnes comme « Total de la facture » et l'IA comprend le type de champ. Lorsqu'elle rencontre une valeur dans un champ de devise connu, elle recherche activement le séparateur décimal et utilise la structure attendue à deux décimales pour valider les chiffres. Si le résultat brut produit « 15499 » pour un champ « Total (USD) », l'IA signale la décimale manquante et applique une correction probabiliste.

C'est la différence fondamentale entre l'extraction basée sur la position (où l'outil lit chaque caractère dans une zone et affiche ce qu'il voit) et l'extraction basée sur la sémantique (où l'outil comprend ce qu'il cherche et utilise ce contexte pour résoudre les ambiguïtés). Les indications de type de champ transforment une perte de point décimal d'une corruption silencieuse des données en une ambiguïté corrigeable. La même approche vous permet de traiter des lots de factures fournisseurs directement dans des feuilles Excel structurées sans configuration de modèle par fournisseur — l'IA gère les variations de format en comprenant ce que chaque champ signifie, et non où il se trouve sur la page.

Correctif 3 : Post-traitement par regex et recoupement

Lorsque vous ne pouvez pas contrôler la qualité de la source ou l'outil d'extraction, le post-traitement est le filet de sécurité. Deux techniques permettent de détecter la majorité des erreurs de décimales et de devises après l'extraction. Pour une vue d'ensemble plus large des stratégies de prétraitement, de réglage du moteur et de validation au niveau des champs, consultez notre guide complet sur comment améliorer la précision de l'OCR sur les documents financiers.

Validation basée sur des motifs. La plupart des montants en devises suivent des motifs prévisibles. Une regex comme ^\d{1,3}(?:,\d{3})*\.\d{2}$ valide les montants au format américain. Toute valeur sans point décimal, avec quatre décimales ou avec des séparateurs incohérents est signalée pour examen.

Recoupement (validation mathématique). Sur tout document comportant des lignes d'articles, la somme des montants des lignes doit être égale au total. Un écart signale une erreur de lecture du point décimal. Si les montants des lignes totalisent 1 249,85 $ mais que le total extrait est de 124 985,00 $, la décimale a migré de trois positions — presque certainement une erreur de perte de point. Le recoupement détecte cela instantanément, quelle qu'en soit la cause.

Le post-traitement ne remplace pas une bonne qualité de source ou une extraction sémantique — c'est une couche de détection conçue pour attraper les erreurs qui ont échappé aux étapes précédentes.

Quand passer à l'étape supérieure : reconnaître les limites des correctifs

Toutes les erreurs de point décimal et de symbole monétaire ne peuvent pas être corrigées en améliorant la qualité des entrées ou en ajoutant des règles de post-traitement. Trois scénarios indiquent que l'approche d'extraction elle-même doit changer :

Scénario 1 : Traitement à volume élevé de sources mixtes. Si votre flux de travail traite des factures provenant de centaines de fournisseurs utilisant des formats et des conventions régionales différents, le réglage du prétraitement par fournisseur ne passe pas à l'échelle — la surcharge annule les gains d'efficacité de l'automatisation.

Scénario 2 : Documents principalement capturés sur mobile. Les photos prises au téléphone introduisent une distorsion de perspective, des reflets et un éclairage variable qui dégradent systématiquement la reconnaissance des petits caractères. La solution n'est pas un meilleur prétraitement ; c'est un système qui utilise le contexte sémantique pour interpréter les valeurs lorsque la reconnaissance au niveau des caractères est incertaine.

Scénario 3 : Documents avec des tableaux extrêmement denses. Les relevés bancaires, les rapports de courtage et les factures multilignes concentrent les nombres dans de petites cellules de tableau où les points décimaux sont rendus en 6 pt à 8 pt. À cette taille, le flou d'anticrénelage est presque inévitable, quelle que soit la résolution de numérisation — l'OCR basé sur les pixels atteint un plafond de précision fondamental.

Dans ces scénarios, même un prétraitement parfait ne peut pas combler l'écart — la solution est une approche basée sur la vision qui comprend la structure du document et la sémantique des champs, et pas seulement les valeurs des pixels. Pour des conseils connexes, voir comment les cellules fusionnées cassent l'extraction de tableaux et pourquoi l'OCR échoue à reconnaître les tableaux — des scénarios courants où les erreurs de décimales proviennent de lectures structurelles erronées plutôt que de problèmes au niveau des pixels.

Questions fréquemment posées

Ne laissez pas un point manquant vous coûter des milliers

Les points décimaux et les symboles monétaires sont de petits caractères aux conséquences énormes — un seul point manqué peut vous faire surpayer un fournisseur de 15 000 $ ou laisser passer une violation de conformité lors des contrôles de fin de mois. Ces erreurs ne sont pas aléatoires : chacune a une cause traçable, ancrée dans la façon dont les moteurs OCR traitent les images au niveau du pixel. Savoir quelle cause a touché votre document fait la différence entre ajuster les paramètres à l'aveugle et corriger le problème définitivement.

La solution la plus fiable est un système d'extraction qui comprend ce qu'il lit — reconstruisant les points décimaux manquants, validant les valeurs par rapport aux formats attendus et gérant les conventions de séparateurs régionaux sans configuration manuelle. C'est ce que rend possible l'extraction sémantique. Téléversez une facture avec laquelle votre outil actuel a du mal et comparez la précision côte à côte.