Pourquoi votre OCR omet les points décimaux
& symboles monétaires ?

Le coût ne se limite pas à un mauvais numéro sur un é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 décimale dans un pipeline automatisé constitue un risque de non-conformité. Pour toute entreprise, un paiement de 15 499,00 $ sur une facture de 154,99 $ signifie un trop-perçu de 15 344,01 $ jusqu'à ce que la clôture mensuelle 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 briser une ligne entière de données. Voici ce qui cause ces erreurs au niveau du pixel — 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 presque blanc est considéré 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 des 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 l'éblouissement autour d'un point décimal rendent encore plus difficile pour le filtre de binarisation (conversion des pixels couleur en 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 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 complètement supprimé — le moteur OCR décide que 1 234,56 $ doit simplement être 1 234,56, supprimant silencieusement l'indicateur monétaire. Cela crée une sortie ambiguë : 1 234,56 est-il en USD, EUR ou une autre unité ? Lorsque des données de plusieurs fournisseurs ou devises sont fusionnées dans un seul tableur, la perte du marqueur monétaire rend impossible de déterminer quelles valeurs sont comparables.
• Le symbole est mal interprété comme une lettre ou un chiffre — $ est souvent 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 qu'une valeur numérique, provoquant des erreurs de conversion de type dans les importations de bases de données ou les formules Excel.
• Le symbole fusionne avec un chiffre adjacent — lorsqu'un signe $ est imprimé dans une police grasse ou avec empattement 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 le résultat passe un rapide examen visuel — 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 est plus importante que la précision au niveau du caractère dans le traitement des documents financiers.

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

L'anticrénelage (lissage de police) 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 8pt ou 9pt — courant dans les tableaux de lignes de factures ou les petits caractères sur les reçus — a si peu de pixels que tout lissage le brouille 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 souvent rendus en très petite taille dans les cellules denses des tableaux où l'anticrénelage est le plus destructeur.

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

Un seul caractère — le point ou la virgule — a des significations opposées selon l'origine du document. Aux États-Unis, 1 234,56 utilise la virgule comme séparateur de milliers et le point comme séparateur 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 séparateur 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 (123456), multipliant la valeur par 100. Dans les deux cas, des données corrompues entrent silencieusement dans le système comptable.

Le problème se cumule avec les documents multirégionaux — un fournisseur français utilisant la virgule comme séparateur décimal mais des libellés de champs en anglais perturbe les outils OCR basés sur la locale qui s'attendent à une seule convention régionale.

Comment corriger : un cadre diagnostique basé sur les symptômes

Toutes les erreurs de décimales et de devises n'ont pas la même cause racine. Utiliser la mauvaise correction fait perdre du temps et ne résout pas le vrai problème. Le tableau ci-dessous fait correspondre le symptôme observé dans votre résultat extrait à la cause la plus probable et à la correction correspondante.

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

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

• Numérisez à 300 DPI minimum — 200 DPI est le seuil bas ; 300 DPI est la norme fiable pour les documents financiers. Utilisez un scanner à plat plutôt qu'un appareil photo de téléphone dans la mesure du possible.
• Enregistrez au format TIFF ou PNG, pas JPEG — La compression avec perte du JPEG est la cause principale de la disparition des points décimaux. Le TIFF et le PNG préservent les points de 2 à 3 pixels que le JPEG supprime.
• Pour les photos de téléphone — prenez la photo à la verticale, sur une surface bien éclairée, et exportez à la résolution maximale de l'appareil. Recadrez au plus près de la zone du document pour maximiser la densité de pixels sur la zone de texte.

Correction 2 : Utiliser les indices de type de champ

C'est la correction que la plupart des outils d'OCR généralistes ne peuvent pas offrir — et la 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 indices sémantiques sur la valeur, et non comme des caractères ordinaires.

Dans ImageToTable.ai, cela fonctionne via l'Extraction de colonnes personnalisées : vous définissez des colonnes comme « Total facture » et l'IA comprend le type de champ. Lorsqu'elle rencontre une valeur dans un champ de devise connu, elle cherche 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 indices de type de champ transforment une disparition de point décimal d'une corruption silencieuse des données en une ambiguïté corrigeable. Cette 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 expressions régulières 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 rattraper la majorité des erreurs de décimales et de devises après extraction. Pour un aperçu plus large des stratégies de prétraitement, d'optimisation du moteur et de validation au niveau des champs, lisez notre guide complet sur comment améliorer la précision de l'OCR sur les documents financiers.

Validation par motifs. La plupart des montants en devises suivent des motifs prévisibles. Une expression régulière 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 des séparateurs incohérents est signalée pour révision.

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 la somme des lignes est de 1 249,85 $ mais que le total extrait est de 124 985,00 $, la virgule 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 racine.

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 rattraper les erreurs qui ont échappé aux autres contrôles.

Quand escalader : 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é d'entrée 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 multi-sources à volume élevé. Si votre flux de travail traite des factures de centaines de fournisseurs utilisant différents formats et conventions régionales, l'optimisation 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 avec un téléphone introduisent des distorsions 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, mais 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 multi-lignes concentrent les nombres dans de petites cellules de tableau où les points décimaux sont rendus en 6pt à 8pt. À cette taille, le flou d'anticrénelage est presque inévitable, quelle que soit la résolution de numérisation — l'OCR basée sur les pixels atteint un plafond de précision fondamental.

Dans ces scénarios, même un prétraitement parfait ne peut pas combler le fossé — la solution est une approche basée sur la vision qui comprend la structure du document et la sémantique des champs, et non seulement les valeurs des pixels. Pour des conseils connexes, voir comment les cellules fusionnées brisent 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équentes

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 oublié peut surpayer un fournisseur de 15 000 $ ou faire passer une infraction de conformité inaperçue lors des contrôles de fin de mois. Les erreurs ne sont pas aléatoires : chacune a une cause traçable, ancrée dans la façon dont les moteurs d'OCR traitent les images au niveau du pixel. Savoir quelle cause a frappé votre document fait la différence entre modifier les réglages à l'aveugle et résoudre 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éparateur régionales sans configuration manuelle. C'est ce que permet l'extraction sémantique. Importez une facture avec laquelle votre outil actuel a du mal et comparez la précision côte à côte.