ABBYY Hot Folder reconnaît les tickets de caisse en local et n'occupe que 25 Mo de mémoire

La lecture des tickets de caisse semble être la tâche idéale pour un agent IA : il reçoit une photo, reconnaît les lignes, identifie le magasin, la date, les articles et le total, et le tour est joué. En pratique, entre la photo et des dépenses structurées surgit un petit zoo de déformations, de feuilles froissées, de polices étranges, de langues variées et de formats de caisse. L'auteur de l'article a testé ce parcours sur mille cinq cents tickets et en a tiré une conclusion désagréablement utile : un nouveau modèle ne signifie pas encore un produit prêt à l'emploi.

Le contraste le plus frappant oppose la chaîne artisanale à ABBYY Hot Folder, un composant de FineReader que l'auteur connaît depuis 2008. Alors que les outils modernes obligent à relier plusieurs modèles et bibliothèques, Hot Folder se contente de surveiller un dossier, de préparer les images, de lancer l'OCR et d'enregistrer le résultat. En veille, selon les observations de l'auteur, le programme occupe environ 25 Mo de mémoire.

Pourquoi reconnaître le texte ne suffit pas

La première version de la compétence de l'agent utilisait docTR. Deux modèles y travaillent : l'un repère les zones de texte, l'autre reconnaît les caractères. Mais il faut encore transformer le résultat en lignes et les ordonner correctement. Pour cela, l'auteur a ajouté bbox-align, et docuwarp pour redresser les documents déformés.

Une frontière d'ingénierie importante est alors apparue. L'OCR peut lire correctement des mots isolés tout en se trompant sur la structure du document. Les coordonnées des rectangles arrivent parfois dans un ordre inattendu, les lignes sont mal assemblées, et certains mots apparaissent en miroir ou à l'envers. Pour l'hébreu, la tâche est plus ardue : le texte principal se lit de droite à gauche, tandis que les nombres qu'il contient se lisent de gauche à droite. Il faut donc, après la reconnaissance, une couche de normalisation distincte qui comprenne le sens d'écriture et la géométrie du document.

Et ce n'est que la moitié du travail. Les tickets d'une même enseigne peuvent différer par l'emplacement de la date, du numéro de succursale, des remises et des taxes. Le nom du magasin est parfois une image, un article une ligne anonyme, et une même référence peut correspondre à plusieurs lignes. Un formulaire universel se brise donc vite. Un LLM facilite l'extraction des champs à partir d'un texte hétérogène, mais ne dispense pas de vérifier les montants, les dates et les lignes d'articles.

Ce qu'a montré Xiaomi-OCR

La tentative suivante a été Xiaomi-OCR-0, exécuté en local via llama.cpp sur un ordinateur portable doté de 24 Go de mémoire vive et d'environ 0,5 Go de mémoire vidéo. Le modèle était chargé à la demande et déchargé après traitement, afin de ne pas occuper la mémoire en permanence. Un ticket de test de dix articles était reconnu en 30 secondes environ.

Sur des images nettes et droites, le résultat était bon. Sur des tickets flous, le modèle perdait des fragments, basculait parfois vers des idéogrammes et gérait mal la police Sütterlin. Le texte russe fonctionnait lui aussi de façon instable dans la configuration de l'auteur. Cela ne rend pas le modèle inutile, mais révèle le prix de la localité : il faut un jeu de test, une version reproductible du modèle et un scénario d'échec explicite.

Que retenir pour un système de production

Pour une machine Windows où une licence payante est acceptable, Hot Folder reste une excellente base de référence. Il exécute rapidement la préparation des images et l'OCR, et l'on peut laisser à l'agent l'analyse des champs, la catégorisation des dépenses et la validation. Si le code ouvert, la portabilité et le contrôle total des données comptent, l'association de docTR ou de Xiaomi-OCR avec un post-traitement maison offre plus de liberté, mais demandera nettement plus de travail d'ingénierie.

La conclusion pratique est simple : ne commencez pas par choisir un modèle à la mode, mais par constituer un jeu de tickets réels et des métriques. Mesurez l'exhaustivité des lignes, la précision des montants, le temps de traitement et la part des documents envoyés en vérification manuelle. Et gardez impérativement un outil simple et tout prêt comme point de contrôle. Parfois, le meilleur agent est celui qui surveille un dossier en silence depuis quinze ans et accomplit une seule tâche sans surprise.