Qu'est-ce que l'OCR dans le navigateur ?

L'OCR dans le navigateur est une reconnaissance optique de caractères effectuée par du code exécuté dans votre navigateur, et non par un service tournant sur la machine d'un tiers. Le moteur est compilé en WebAssembly et téléchargé comme n'importe quelle ressource de page ; le document est lu depuis la mémoire locale ; le texte extrait est produit dans l'onglet et n'a jamais à en sortir.

L'OCR classique fonctionne à l'inverse : vous envoyez le fichier, un serveur le reconnaît, du JSON revient. C'est plus simple à construire et généralement plus précis, et cela signifie qu'une copie de votre document existe sur une infrastructure que vous ne contrôlez pas.

Comment cela fonctionne

Un pipeline d'OCR navigateur comporte quatre étapes, et seule la troisième est la reconnaissance proprement dite.

• Lire — le fichier est chargé en mémoire depuis le champ de fichier. Aucune requête réseau ne le transporte.
• Décider — si le PDF contient déjà une couche de texte, ce texte est lu directement et l'OCR est ignoré.
• Reconnaître — les pages sans texte exploitable sont rasterisées et confiées à un moteur WebAssembly dans un worker, pour que l'interface reste réactive.
• Assembler — les mots reconnus portent des positions, qui servent à reconstruire lignes, paragraphes, tableaux et ordre de lecture.

La couche de texte du PDF passe en premier

C'est l'étape que la plupart des descriptions de l'OCR passent sous silence, et elle compte davantage que le moteur. Un PDF exporté depuis un logiciel comptable contient déjà les caractères, avec leurs coordonnées exactes. Lui appliquer l'OCR serait plus lent et moins précis que lire ce qui est déjà là : vous convertiriez du texte parfait en pixels pour ensuite deviner ces pixels.

Un pipeline bien construit inspecte donc chaque page et choisit une route page par page, si bien qu'un contrat imprimé avec une page de signature scannée est traité correctement.

Navigateur ou cloud

Aucun des deux n'est universellement meilleur. Ils échouent à des endroits différents, et la vraie question est de savoir quelle défaillance vous pouvez tolérer.

• Précision sur les entrées difficiles — avantage cloud. Les modèles côté serveur sont plus gros que tout ce qu'on peut raisonnablement livrer à un navigateur.
• Confidentialité du document — avantage navigateur, nettement. Le fichier ne quitte pas l'appareil : il n'existe aucune copie à sécuriser ni à compromettre.
• Vitesse sur une page isolée — souvent le cloud, matériel dédié et modèle déjà chargé.
• Vitesse sans bande passante montante — le navigateur, puisqu'il n'y a rien à envoyer.
• Coût au volume — le navigateur, la reconnaissance tournant sur du matériel que vous ne payez pas.
• Prévisibilité — le cloud, car vous maîtrisez la machine ; dans le navigateur, tout dépend de l'appareil du visiteur.
• Fonctionnement hors ligne — le navigateur, une fois les ressources mises en cache.

Quand le cloud est préférable

Pour des dizaines de milliers de documents par nuit, pour la meilleure précision possible sur des photos froissées, ou pour la reconnaissance d'écriture manuscrite, un service côté serveur est le bon outil. L'OCR navigateur n'est pas un remplacement universel, et prétendre le contraire serait malhonnête.

Quand le navigateur est préférable

Il convient aux documents que l'on hésite à envoyer : factures avec coordonnées bancaires, reçus liés à une carte personnelle, contrats, pièces d'identité, courriers médicaux. Il convient aussi à qui préfère ne pas assumer les obligations liées à la détention des documents d'autrui — car le moyen le plus simple de protéger un fichier est de ne jamais le recevoir.

Ce que cela ne signifie pas

Cela ne signifie pas que la page n'effectue aucune requête réseau. Le moteur et ses modèles de langue sont téléchargés, et une application peut malgré tout enregistrer qu'une conversion a eu lieu. Chez nous, le serveur reçoit un bref enregistrement — nom du fichier, type, taille, nombre de pages et une clé identifiant la tentative — car un quota ne peut pas être appliqué en demandant au navigateur de compter honnêtement.

La formulation juste est étroite et vérifiable : les octets du document sont traités localement dans le navigateur et ne sont jamais envoyés, tandis que des métadonnées limitées sont transmises à des fins de quota et de traçabilité. Tout ce qui va au-delà relève du marketing.

Ce qu'il faut attendre de la précision

La qualité dépend bien davantage de l'image que du moteur. Un scan net, à plat et bien éclairé d'un texte imprimé se lit bien avec n'importe quel OCR moderne. Un reçu froissé photographié de biais dans une lumière faible, non — dans le navigateur comme sur un serveur. L'écriture manuscrite est un problème distinct que l'OCR généraliste ne résout pas de façon fiable.

La vraie protection n'est pas une promesse de précision plus élevée, mais un score de confiance attaché à chaque champ extrait, pour signaler les valeurs incertaines au lieu de les inscrire silencieusement dans un tableur.

Comment EasyInvoiceOCR le met en œuvre

La reconnaissance s'exécute côté client avec Tesseract.js compilé en WebAssembly. Les PDF dotés d'une couche de texte sont lus directement via PDF.js et l'OCR est ignoré. Cinq modèles de langue sont disponibles — anglais, français, arabe, allemand et espagnol — plus deux modes combinés, anglais + arabe et anglais + français, pour les documents bilingues. Le moteur et les modèles sont servis depuis notre propre domaine plutôt que par un CDN tiers.

Chaque champ extrait porte un score de confiance et un indicateur de relecture, tous deux inscrits dans le tableur exporté plutôt qu'affichés une fois puis oubliés.