La reconnaissance optique de caractères peut s'exécuter entièrement dans un onglet de navigateur. Sur ce site, Image en texte charge le moteur de reconnaissance Tesseract.js en WebAssembly, lit l'image depuis la mémoire locale et renvoie du texte modifiable, donc l'image n'est jamais transmise. PDF en texte va plus loin et évite généralement entièrement le moteur de reconnaissance.
Le chemin PDF est la conception la plus intéressante. L'outil parcourt le document page par page et lit d'abord toute couche de texte existante. Un PDF numérique, exporté depuis un traitement de texte ou un outil de design, produit un texte exact en environ une seconde et ne télécharge jamais le moteur de reconnaissance. Seules les pages pratiquement sans texte, donc les scans et les photographies, sont rendues en double taille et transmises à l'OCR. Cette approche en deux étapes signifie que le gros téléchargement n'est payé que lorsqu'il est réellement nécessaire, et les pages numérisées sont traitées une à une à quelques secondes chacune.
La raison pour laquelle cela compte n'est pas abstraite. Les documents numérisés sont la catégorie que les gens sont le moins à l'aise de confier : formulaires signés, lettres médicales, factures, papiers d'identité, tout ce qui est photographié sur un bureau. Un moteur de reconnaissance qui s'exécute localement supprime entièrement la décision, car il n'y a aucune copie à évaluer.
Image en texte
Lisez le texte d'une photo, d'une capture d'écran ou d'un scan. Plusieurs images sont traitées dans l'ordre, et le résultat apparaît dans une zone modifiable que vous pouvez copier ou télécharger.
Ce qui change quand la reconnaissance s'exécute dans le navigateur
Un service OCR basé sur un serveur reçoit votre fichier, exécute la reconnaissance sur son propre matériel et renvoie le texte. Un outil dans le navigateur télécharge le moteur plutôt que le document, et le trafic circule en sens inverse.
| Reconnaissance dans l'onglet | Reconnaissance sur un serveur | |
|---|---|---|
| Ce qui traverse le réseau | Fichiers du moteur et de langue, en | Votre document, dehors |
| Des copies sur le disque de quelqu'un d'autre | Aucun | Au moins le téléversement, souvent aussi un fichier de résultat |
| Compte | Non nécessaire | Souvent nécessaire pour les lots ou les fichiers plus volumineux |
| Fonctionne hors ligne après le premier chargement | Oui | Non |
| Vitesse | Quelques secondes par page numérisée | Plus rapide sur les gros lots |
| Vérifiable par vous | Oui, dans le panneau réseau | Non |
Un détail technique vaut la peine d'être connu car il explique pourquoi cela est possible sans configuration serveur spéciale. Le moteur est mono-thread et n'utilise pas SharedArrayBuffer, donc la page n'a pas besoin des en-têtes d'isolation cross-origin que le WebAssembly multithread exige normalement. C'est pourquoi un simple hébergeur statique peut le servir.
La conception en deux étapes de PDF en texte
La plupart des PDF que les gens appellent des scans n'en sont pas du tout. Un document exporté depuis un traitement de texte, un tableur ou un générateur de rapports contient de vrais caractères, positionnés sur la page mais stockés sous forme de texte. Reconnaître ces caractères avec l'OCR serait une chose étrange à faire, car cela introduirait des erreurs dans des données déjà exactes.
Étape un : lire la couche de texte
L'outil ouvre le PDF avec PDF.js et demande à chaque page son contenu textuel, puis reconstruit l'ordre de lecture à partir des données de position afin que les lignes et les paragraphes ressortent dans un ordre cohérent. Cette étape est rapide et sans perte : les caractères sont ceux que le fichier contient déjà, il n'y a donc rien à rater. Une page est considérée comme ayant une couche de texte lorsqu'elle contient au moins 20 caractères hors espaces, ce qui est un seuil délibérément bas pour qu'une page avec une légende vraiment courte soit tout de même lue directement.
Étape deux : ne reconnaître que les pages qui en ont besoin
Les pages qui échouent à ce test sont celles qui sont réellement des images, et elles passent par une autre voie. Chacune est rendue sur un canvas au double de la taille normale, convertie en PNG et transmise au moteur de reconnaissance. Doubler l'échelle de rendu compte plus qu'il n'y paraît, car les modèles OCR travaillent sur les traits et les contours, et une page rastérisée à la résolution d'écran perd les fins détails des petits caractères.
| Document | Ce que fait l'outil | Téléchargement du moteur |
|---|---|---|
| PDF numérique, toutes les pages contiennent du texte | Lit la couche de texte sur chaque page | Aucun |
| PDF numérisé, sans couche de texte | Rend chaque page en 2x et la reconnaît | Un téléchargement, puis mis en cache |
| Document mixte, annexe numérisée | Lit directement les pages de texte, reconnaît le reste | Un téléchargement, utilisé pour une partie du fichier |
Le résultat vous indique quel chemin chaque page a suivi. Le résumé rapporte le nombre de pages, combien proviennent de la couche de texte et combien ont été reconnues, et le corps est divisé en blocs de page. Cette distinction est utile en pratique : si un document que vous pensiez numérique rapporte une pile de pages reconnues, il a probablement été imprimé en image quelque part en chemin.
PDF en texte
Les pages numériques sont lues depuis la couche de texte en environ une seconde. Le moteur de reconnaissance n'est chargé que pour les pages qui sont réellement des images.
Ce que le moteur télécharge réellement
Rien n'est récupéré au chargement de la page. Le moteur arrive à la demande, la première fois que vous appuyez sur le bouton, et les chiffres valent la peine d'être énoncés car ils expliquent à la fois le délai et le comportement hors ligne par la suite.
- Le noyau fait environ 3,7 MB. C'est la version WebAssembly du modèle de reconnaissance, et il s'agit d'un seul fichier auto-hébergé plutôt que de plusieurs variantes.
- Les données de langue anglaise font environ 2,8 MB et est servi depuis ce site, donc le cas courant ne nécessite aucun tiers du tout. Ensemble, la première exécution en anglais tire environ 6,5 MB, et le navigateur la met en cache.
- Les autres langues proviennent d'un CDN public de données Tesseract. Le sélecteur liste douze langues au total ; l'anglais est local, et les onze autres, du chinois et du japonais au russe et à l'arabe, sont téléchargées à la première utilisation et mises en cache par le moteur dans IndexedDB.
- Un seul worker est conservé à la fois. Un worker conserve le noyau et les données de langue en mémoire, donc changer de langue termine le précédent au lieu de les empiler.
- La prise en charge de SIMD est vérifiée avant tout chargement. Le chargeur valide d'abord un petit échantillon WebAssembly, car la version du moteur nécessite des instructions vectorielles. Sans cette vérification, un navigateur plus ancien échouerait avec une erreur de compilation de bas niveau au lieu d'un message lisible.
Comment obtenir un résultat propre
- Choisissez la langue avant de commencer. C'est le seul réglage qui décide de la précision, et il ne s'applique qu'aux pages qui passent par la reconnaissance. Un PDF numérique l'ignore entièrement.
- Envoyez la source la plus nette dont vous disposez. La photo d'origine bat une capture d'écran d'un aperçu, et un scan à plat bat une photo prise de biais au téléphone. Si vous n'avez qu'une photo, un léger recadrage sur le bloc de texte aide plus que n'importe quel réglage.
- Redressez-la et éclairez-la. Une page inclinée de quelques degrés, ou éclairée d'un seul côté avec une ombre au milieu, coûte plus en précision qu'une résolution plus faible.
- Lancez-le et lisez la sortie. La zone de résultat est modifiable, donc corrigez-y les noms et les nombres plutôt que d'exporter puis de corriger après coup.
- Vérifiez le taux de confiance. Il est rapporté comme une moyenne sur l'ensemble du fichier. Un chiffre faible est un signal pour réexaminer la source, pas un verdict sur le texte.
Si une photo doit être nettoyée avant la reconnaissance, Recadreur d'image et Compresseur d'image les deux s'exécutent localement, donc toute la chaîne, de la photo brute au texte, peut rester sur l'appareil.
Où l'OCR échoue encore
Être clair à ce sujet est plus utile qu'une affirmation de confiance, car les modes d'échec sont prévisibles et se regroupent autour de la façon dont la source a été produite plutôt qu'autour du moteur.
- Graphismes de design et fonds colorés. Le modèle de reconnaissance a été entraîné sur des documents, pas sur des affiches. Testé contre le graphique de couverture bleu foncé de ce site, qui comporte de grandes lettres stylisées, le moteur n'a renvoyé qu'un seul trait d'union. Toute image où le texte est décoratif plutôt que composé est un mauvais candidat.
- L'écriture manuscrite. Le texte imprimé est la cible. Les notes manuscrites, les signatures et les champs de formulaire produisent une sortie peu fiable, et aucune résolution ne corrige cela.
- Numérisations médiocres. Reçus thermiques pâles, fax, photocopies de photocopies, pages de travers dans le scanner. La précision chute pour chacun de ces cas, et l'outil n'a aucun moyen de vous signaler quels mots sont douteux.
- Vitesse sur les pages numérisées. La reconnaissance prend quelques secondes par page, et le travail se fait sur votre propre CPU, donc l'onglet est occupé pendant l'exécution. Un long document numérisé est une tâche lente plutôt qu'instantanée.
- Couverture linguistique. Uniquement les douze langues du sélecteur. Toute autre langue n'est pas prise en charge, et une page mélangeant deux écritures est lue avec le seul modèle que vous avez choisi, ce qui coûte en précision sur la seconde.
- La mise en page n'est pas conservée. La sortie est du texte brut avec des marqueurs de page. Les colonnes, les tableaux et les encadrés ressortent comme un flux linéaire, donc une mise en page complexe doit être reformatée ensuite.
- Les PDF protégés par mot de passe doivent d'abord être déverrouillés. Le lecteur ne peut pas ouvrir un fichier chiffré, et l'outil le dit plutôt que d'échouer en silence.
Quand un service basé sur un serveur est la meilleure réponse
La reconnaissance locale est le bon choix par défaut pour une poignée de documents, et c'est le mauvais outil pour quelques tâches précises. Trois cents factures numérisées, une archive très manuscrite, une écriture hors de la liste prise en charge, ou une exigence de sortie structurée préservant la géométrie des tableaux pointent toutes dans la même direction, car celles-ci nécessitent un débit ou des modèles qu'une version dans le navigateur ne transporte pas.
L'habitude utile est de séparer les deux cas avant de commencer. Si le document est sensible et le volume faible, la voie du navigateur le couvre et le fichier ne bouge jamais. Si le volume est important, la bonne démarche est un service approuvé plutôt que cent exécutions manuelles, et le choix du service est une décision organisationnelle plutôt que technique. Cette séparation, et la façon dont elle s'applique aux équipes traitant des dossiers de personnel, juridiques ou cliniques, fait l'objet de documents sensibles et le cloud.