L'application d'archivage OCR

Le besoin

Le client reçoit chaque semaine des factures, des devis, des bons de livraison, souvent scannés, parfois photographiés au téléphone. Elle voulait trois choses : les archiver sans les ressaisir, les retrouver par leur contenu, et à terme pouvoir leur poser des questions — combien a-t-on dépensé chez tel fournisseur depuis juin, quels devis n'ont pas eu de suite.

Le projet est porté par l'entreprise pour ce client. Quand je l'ai récupéré, le dépôt ne contenait qu'un fichier de présentation. Tout ce qui est décrit ici, je l'ai cadré, choisi et construit.

Cadrer avant d'écrire une ligne

Le besoin était arrivé à l'oral, avec deux formulations qui ne disaient pas la même chose : le client voulait « communiquer avec » ses documents. J'ai commencé par une note de cadrage : le besoin tel que je le comprenais, les questions à trancher avant de coder, trois scénarios d'architecture chiffrés, et un comparatif des moteurs de lecture — services payants des grands hébergeurs, modèles récents spécialisés, moteurs libres.

Un critère a pris le dessus sur tous les autres : la langue. Les documents peuvent mêler le français et l'arabe, et tous les moteurs ne lisent pas l'arabe. Aucun document arabe n'étant librement disponible pour tester, j'ai fabriqué une facture bilingue fictive, pour vérifier au moins l'arabe imprimé.

Sont venues ensuite une maquette interactive de chaque écran et une liste de questions d'arbitrage pour le tuteur. Le code n'a commencé qu'une fois les réponses revenues.

Mesurer les moteurs au lieu de les croire

Avant de choisir un moteur, j'ai construit un banc de test : quatorze factures et tickets d'exemple, passés dans chaque moteur, avec un rapport qui donne le temps, la confiance annoncée et la part des mots attendus réellement retrouvés. Quand les premiers scans du client sont arrivés, le banc a appris à les lire aussi — sans que ces documents ni leur texte n'entrent jamais dans le dépôt de code.

• Les vrais scans ont leurs pièges. Une page blanche à la fin de chaque PDF (scanner recto verso), un trait laissé par la vitre, une page posée de travers. Le banc écarte les pages vides par un seuil de pixels sombres — 0,04 % contre au moins 1,8 % pour une vraie page — et redresse les pages tournées.
• Une photo trop fine se lit moins bien. Les photos de téléphone en très haute définition faisaient baisser la qualité de lecture. Plafonner la largeur à 2 000 pixels, après mesure, a amélioré tous les documents.
• Deux moteurs, deux compromis. Sur les scans du client, le moteur libre le plus courant retrouve 50 mots attendus sur 53 en 2 à 5 secondes par page. Un second moteur en retrouve 52, mais met plus d'une minute par page sur la machine de développement.

L'erreur qui ne prévient pas

Le vrai danger n'était pas le mot illisible. C'était un montant de 10 000,00 lu 40 000,00, avec 88 % de confiance. Aucun signal d'erreur : le moteur était sûr de lui. Dans une application comptable, c'est le pire défaut possible.

La réponse tient en trois mécanismes. Chaque montant est relu seul, agrandi, par un second passage limité aux chiffres ; si les deux lectures ne sont pas d'accord, la relecture l'emporte et la ligne passe « à vérifier » avec les deux valeurs. Chaque nombre garde ses lectures de secours, et l'application choisit celle qui vérifie quantité × prix = montant ou HT + TVA = TTC. Enfin, une valeur incertaine n'est jamais devinée : elle sort « à vérifier », et c'est un humain qui tranche.

Une valeur incertaine sort « à vérifier ». La machine propose, la personne qui connaît le document valide.

Ce que fait l'application

Un assistant qui ne peut pas mentir sur les chiffres

L'assistant ne lit pas les tables : il lit des vues préparées pour lui, qui ne contiennent que les documents validés et aucune donnée de compte. Même si le modèle écrivait une mauvaise requête, il ne pourrait structurellement pas compter un document non vérifié. Et il se connecte avec un rôle de base de données qui ne peut qu'interroger.

Pour choisir le modèle, j'ai comparé quatre modèles ouverts sur sept questions dont je connaissais la réponse : des comptages, des classements, une période sans aucun document, une soustraction. Le modèle retenu a donné 7 bonnes réponses sur 7 en 3,6 secondes, contre 5 sur 7 pour le modèle de départ. Il est plus cher, mais le coût reste négligeable à l'échelle d'une question — et c'est la justesse qui compte ici.

La comparaison a aussi révélé un piège : un modèle annonçait 900 000 unités au lieu de 900, parce que la base rendait « 900.000 » en texte. Les nombres sont désormais convertis avant d'être montrés au modèle. Et le correcteur automatique avait compté cette réponse juste — j'ai relu toutes les réponses à la main avant de conclure.

Une dépense qu'on ne fait pas seul

L'hébergeur européen du modèle impose un crédit prépayé, non remboursable, à la création du projet. Je n'ai pas engagé cette dépense sans l'accord de l'entreprise : j'ai réorienté le travail sur la lecture des documents en attendant la décision. Une fois le crédit validé, j'ai ajouté un relevé de consommation à chaque question — jetons envoyés, jetons reçus, coût estimé — pour que la facture ne soit jamais une surprise.

La mise en ligne

• Un même contrat, deux stockages. Les documents sont rangés sur le disque en développement et dans la base en ligne, derrière une seule couche d'accès choisie par configuration.
• La lecture continue après la requête. Le traitement se termine alors que l'utilisateur a déjà eu sa réponse, donc sans sa session. L'écriture passe par le serveur, et le rôle de l'utilisateur est vérifié avant chaque appel. Les champs sont écrits d'abord, le statut « validé » en dernier.
• Une adresse de retour qui pointait vers l'intérieur. En vérifiant l'application en ligne, le lien de connexion par e-mail renvoyait vers l'adresse interne du conteneur. L'adresse publique est maintenant reconstruite à partir des en-têtes du proxy.
• Une lecture à la fois. Sur un processeur partagé, deux lectures en parallèle ne vont pas plus vite. Une file d'attente les enchaîne ; le pic de mémoire a été mesuré à 450 Mo avant d'être écrit dans la documentation.

Un test automatisé de l'historique rejoue onze vérifications — création, reprise, rechargement, suppression, affichage sur téléphone — et un guide de mise en ligne explique où trouver chaque clé et dans quel ordre la poser.

Le film

La page de connexion montre un film de présentation. J'ai préparé le dossier de tournage — trente-cinq captures du parcours prises automatiquement en mode démonstration, et un découpage scène par scène — puis réalisé le film en code, en recopiant chaque écran depuis l'application. Le curseur clique au bon endroit parce qu'un script mesure la position réelle de chaque bouton avant le rendu.

Où ça en est

L'application est en ligne, testée de bout en bout sur la vraie base avec les premiers documents du client. La suite : plus de documents réels et de photos de téléphone pour éprouver la lecture, et un journal des actions sur chaque document.