L'OCR en profondeur : Comment les ordinateurs apprennent à lire du texte à partir d'images

Ouvrez n'importe quelle image dans un éditeur hexadécimal. La photo d'un panneau de signalisation, un ticket de caisse, une capture d'écran de PDF. Au décalage zéro, vous obtenez l'en-tête de format. Quelques kilo-octets plus loin, vous atteignez les données de pixels : trois octets par pixel en RVB, une grille de nombres où (128, 52, 19) pourrait être un mur de briques et (240, 238, 220) du papier. Quelque part dans cette grille se trouve un panneau stop avec le mot "STOP" en blanc sur rouge en police Highway Gothic. Un humain voit quatre lettres. L'ordinateur voit une zone de 47 × 19 de valeurs de pixels proches du rouge où le canal R avoisine 200 et les canaux G et B tombent sous 40. Faire correspondre cette zone à la chaîne "STOP" est la reconnaissance optique de caractères (Optical Character Recognition), et c'est un problème de recherche ouvert depuis que Gustav Tauschek a breveté la première machine à lire en 1929.

L'OCR est trompeusement difficile parce que la lecture est trompeusement facile. Un enfant de six ans peut reconnaître la lettre A dans une douzaine de polices, à plusieurs tailles, sous un éclairage irrégulier, légèrement tournée, partiellement occultée et écrite au crayon. Un ordinateur a besoin d'un pipeline : nettoyer l'image, trouver les régions de texte, segmenter les caractères ou séquences de glyphes et classifier chacun. Chacune de ces étapes a un mode d'échec, et les échecs se cumulent.

Ce qui rend l'OCR difficile

Le problème central n'est pas la classification. Classer une image de caractère de 28 × 28 pré-segmentée dans l'une des 62 classes (A–Z, a–z, 0–9) est une tâche qu'un LeNet des années 1990 peut résoudre à 99 % de précision. La partie difficile est tout ce qui précède le classificateur.

Variation des polices. La lettre "g" a au moins quatre variantes structurelles courantes : à une boucle (manuscrite), à deux boucles (la plupart des polices à empattement), la queue en boucle de l'Helvetica et la queue ouverte du Futura. Un modèle entraîné sur Tahoma lira mal Univers à un taux mesurable. L'OCR en conditions réelles couvre des centaines de polices ainsi que l'écriture manuscrite, qui n'a aucune topologie de trait cohérente.

Distorsion géométrique. Les photos de documents sont rarement des numérisations à plat. Une photo de ticket de caisse au téléphone introduit une inclinaison de perspective, une courbure et une échelle non uniforme. Le texte près de la reliure d'un livre se courbe. Les photos de tableau blanc capturent l'ombre du photographe. Une inclinaison de 10 degrés réduit la précision de Tesseract d'environ 97 % à moins de 85 % sur les benchmarks standard. Les algorithmes de redressement (détection de lignes de Hough, transformée de Radon, analyse de profil de projection) récupèrent une partie de cette perte, mais aucun ne la récupère entièrement.

Éclairage et bruit. Un éclairage irrégulier transforme un fond uniforme en gradient, brisant le seuillage global. Les artefacts de compression JPEG créent un effet de ringing autour des arêtes vives. En termes d'OCR, cela signifie du ringing autour des traits de lettres. Le bruit poivre-et-sel des capteurs en faible luminosité remplit l'espace blanc de pixels sombres qui ressemblent à de la ponctuation. Une photocopie d'une photocopie fusionne les traits fins, transformant "rn" en "m" et "cl" en "d".

Complexité de la mise en page. Les documents ont des colonnes, des légendes, des tableaux, des en-têtes, des notes de bas de page et des encadrés. Le texte contourne les images. Certaines langues s'écrivent de droite à gauche. D'autres mélangent les directions dans le même paragraphe. Identifier l'ordre de lecture (quel bloc de texte vient après quel autre) est un problème d'analyse de mise en page distinct de la reconnaissance, et se tromper mélange la sortie même lorsque chaque caractère est correctement classifié.

Ambiguïté contextuelle. Avec seulement le motif de pixels, "0" (zéro), "O" (lettre O majuscule) et "o" (lettre o minuscule) sont identiques dans de nombreuses polices sans empattement. "1", "l", "I" et "|" partagent un trait vertical. La résolution ajoute une autre dimension : à 12 pixels de haut, "e" et "c" ne diffèrent que par un seul trait horizontal de trois pixels de large. Les lecteurs humains résolvent cela par le contexte. Les machines ont besoin de modèles de langage, statistiques ou appris, pour prendre la même décision.

Le pipeline OCR traditionnel

Avant le Deep Learning, l'OCR était une séquence d'étapes conçues manuellement. Chaque étape était développée indépendamment, souvent par différents groupes de recherche, et ajustée pour une dégradation spécifique. Le pipeline ressemblait à ceci :

Image brute → Prétraitement → Binarisation → Redressement → Analyse de mise en page
  → Segmentation des caractères → Extraction de caractéristiques → Classification
  → Post-traitement (modèle de langage) → Sortie texte

Prétraitement et binarisation

Les images couleur sont converties en niveaux de gris. La réduction de bruit lisse le signal avant le seuillage. Le filtrage médian traite le bruit poivre-et-sel. Le flou gaussien traite le bruit de capteur. Le filtrage bilatéral est utilisé lorsque la préservation des contours est importante.

La binarisation transforme l'image en niveaux de gris en texte noir sur fond blanc. L'algorithme standard est la méthode d'Otsu (1979) : il recherche exhaustivement le seuil qui minimise la variance intra-classe entre les distributions de pixels de premier plan et d'arrière-plan. Otsu suppose un histogramme bimodal (les pixels de texte se regroupent à une intensité, les pixels d'arrière-plan à une autre), ce qui fonctionne pour les numérisations à plat sous éclairage contrôlé et échoue pour les photos au téléphone avec des ombres. Les méthodes adaptatives locales (Sauvola, Niblack) calculent un seuil différent par pixel basé sur les statistiques de voisinage, traitant l'éclairage irrégulier au prix d'artefacts près des contours.

Redressement et analyse de mise en page

L'inclinaison du document est détectée en trouvant des lignes : soit par transformée de Hough sur les pixels de contour, soit par analyse de profil de projection où le document est tourné dans une plage d'angles et l'angle avec les pics de projection horizontale les plus nets est choisi. Une fois l'angle d'inclinaison connu, une transformation affine remet l'image droite.

L'analyse de mise en page segmente la page en blocs de texte. L'approche classique exécute une analyse en composantes connexes (Connected-Component Analysis, CCA) pour trouver des amas de pixels de premier plan, les regroupe en mots par proximité, puis regroupe les mots en lignes et les lignes en blocs. L'algorithme XY-cut divise récursivement la page en trouvant des espaces blancs le long des projections horizontales et verticales, construisant un arbre de régions. Les implémentations modernes utilisent un hybride : CCA pour les amas initiaux, puis un modèle appris pour classifier chaque amas comme texte, image, tableau ou séparateur.

Segmentation des caractères

Pour le texte imprimé, la segmentation consiste à découper les images de mots en caractères individuels. Le profil de projection verticale (un histogramme du nombre de pixels de premier plan par colonne) produit des pics aux centres des caractères et des creux aux frontières des caractères. Cela fonctionne jusqu'à ce que deux caractères se touchent, ou qu'un caractère contienne des parties déconnectées ("i", "j", ":", "%"). La sur-segmentation (découper trop agressivement) suivie d'une fusion basée sur la confiance du classificateur est une solution. Une autre consiste à sauter entièrement la segmentation et à reconnaître des mots entiers — c'est ce que font les méthodes modernes basées sur les séquences.

Extraction de caractéristiques et classification

Une fois que vous avez une image de caractère, vous devez la décrire numériquement pour un classificateur. Les caractéristiques pré-Deep Learning incluaient :

• Valeurs de pixels brutes comme vecteur aplati (simple, fragile face à la translation et à l'échelle)
• Zoning : diviser la boîte englobante du caractère en une grille N × N, compter les pixels de premier plan par cellule, utiliser les comptages comme caractéristiques
• Caractéristiques basées sur les gradients (HOG) : l'Histogramme des Gradients Orientés capture les directions des contours, robuste aux petites translations
• Transformée de caractéristiques invariante à l'échelle (SIFT) : détecte et décrit des points clés invariants à l'échelle, à la rotation et à l'éclairage

Le classificateur était typiquement une Machine à Vecteurs de Support (SVM) avec noyau RBF, entraînée sur des dizaines de milliers d'images de caractères étiquetées par police. Un pipeline SVM + HOG bien réglé pouvait atteindre ~98 % de précision par caractère sur du texte imprimé propre. Passez une entrée bruitée, inclinée ou manuscrite dans le même pipeline, et la précision tombait à 70–80 %.

Tesseract : des HP Labs au LSTM

Tesseract est le moteur OCR open source de référence. Il a commencé comme projet de thèse aux HP Labs Bristol dans les années 1980, a été publié en open source en 2005 et est maintenu par Google depuis 2006. Son architecture se divise nettement en deux époques.

Version 3 : le pipeline classique

Tesseract 3 implémentait le pipeline traditionnel avec quelques innovations. Son analyse de mise en page utilisait un algorithme de détection de taquets de tabulation qui trouvait les limites de colonnes en alignant les boîtes englobantes des mots — une heuristique pragmatique ajustée pour le type de documents que HP numérisait dans les années 1990. La segmentation des caractères utilisait une logique hacheur/associateur : le hacheur sur-segmentait l'image du mot en coupes candidates, et l'associateur utilisait la confiance du classificateur et un dictionnaire pour décider quelles coupes fusionner.

Le classificateur était un système à deux passes. La première passe (classificateur statique) faisait correspondre les amas segmentés à des prototypes (échantillons d'entraînement clusterisés) en utilisant une recherche par plus proche voisin. La deuxième passe (classificateur adaptatif) s'ajustait finement sur le document lui-même, apprenant la police spécifique utilisée dans cette image. Le classificateur adaptatif avait besoin d'environ une page de texte pour devenir efficace, c'est pourquoi Tesseract 3 performait mal sur les images de mots isolés comme les panneaux de signalisation et les légendes.

Tesseract 3 distribuait des fichiers .traineddata : des archives contenant les clusters prototypes, les définitions de jeu de caractères, un dictionnaire de fréquence des mots et une table d'ambiguïté unichar mappant les paires de caractères confusables. Entraîner une nouvelle langue nécessitait de fournir à Tesseract des images de texte associées à des transcriptions de vérité terrain, d'encadrer chaque caractère et d'exécuter les outils d'entraînement. Un processus de plusieurs heures par langue.

Version 4/5 : le LSTM remplace le pipeline

Tesseract 4 (2018) a remplacé tout le chemin de reconnaissance par un seul réseau neuronal LSTM. Le LSTM opère sur une séquence de tranches verticales de l'image de ligne de texte, chaque tranche faisant un pixel de large et la hauteur totale de la ligne de texte. Chaque tranche est introduite dans un empilement de couches LSTM bidirectionnelles. La sortie est une séquence de probabilités de caractères avec une perte CTC (Connectionist Temporal Classification) qui aligne la séquence de sortie de longueur variable sur le texte de vérité terrain sans nécessiter de positions de caractères pré-segmentées.

Le modèle LSTM gère les caractères de largeur variable, les caractères qui se touchent et la variation des polices sans la machinerie hacheur/associateur. Il s'appuie toujours sur l'analyse de mise en page héritée de Tesseract pour trouver les lignes de texte, mais la reconnaissance de ligne est neuronale de bout en bout. Sur le benchmark ICDAR 2017, Tesseract 4 a atteint un taux d'erreur caractère (CER) de 4,4 % sur l'anglais imprimé, contre 7,2 % pour Tesseract 3. Le processus d'entraînement est passé de l'ancien outil d'encadrement à la combinaison de lignes de texte avec des transcriptions. Toujours supervisé, mais avec une étiquette par ligne au lieu d'une par caractère.

Le format .traineddata a été étendu pour contenir les poids du modèle LSTM (plusieurs mégaoctets) aux côtés des données héritées (dictionnaire, tables unichar) dans un seul fichier. L'entraînement d'un modèle LSTM rapide à partir de zéro prend environ 24 heures sur un GPU moderne pour une langue à écriture latine avec ~100 classes de caractères ; les langues CJK prennent plus de temps en raison de jeux de caractères plus grands.

Caractéristiques de précision

Tesseract 5 a amélioré la version 4 avec un corpus d'entraînement plus grand et de meilleurs paramètres par défaut, mais l'architecture est inchangée. La précision dépend fortement de l'entrée :

Le modèle LSTM élimine la plupart des problèmes de sensibilité aux polices de la version 3, mais le moteur se dégrade toujours sur les basses résolutions (sous 200 DPI, l'entrée en tranches de pixels du LSTM perd les détails des traits), le texte manuscrit (le modèle a été entraîné sur des polices imprimées ; l'écriture manuscrite a des statistiques de traits fondamentalement différentes) et les mises en page complexes (l'analyse de mise en page reste le chemin de code hérité, pas le neuronal).

Approches modernes de Deep Learning

Sur le plan académique, l'OCR a dépassé le paradigme CTC + LSTM autour de 2019. Trois architectures dominent désormais la littérature.

CRNN + CTC

Le Réseau Neuronal Convolutif Récurrent (CRNN), publié par Shi et al. en 2015, associe un extracteur de caractéristiques CNN à un modèle de séquence RNN et un décodage CTC. Le CNN extrait des caractéristiques spatiales de l'image, apprenant essentiellement ce que le LSTM de Tesseract recevait manuellement (représentations en tranches verticales). Le RNN modélise les dépendances séquentielles à travers les caractéristiques extraites. Le CTC gère l'alignement. CRNN-CTC est devenu la référence standard : entraînable de bout en bout, bonne généralisation, inférence rapide (~20 ms par ligne sur GPU).

Encodeur-décodeur basé sur l'attention

Les modèles basés sur l'attention ont adapté le paradigme seq2seq de la traduction automatique. Un encodeur CNN ou de vision produit une carte de caractéristiques de l'image. Un décodeur RNN génère le texte de sortie un caractère à la fois, en portant attention aux régions spatiales pertinentes de la carte de caractéristiques à chaque étape. Le mécanisme d'attention supprime la contrainte de monotonie du CTC : le décodeur peut revenir à des parties antérieures de l'image lorsque le modèle de langage attend un motif répété, bien que cette flexibilité introduise également un risque d'hallucination pour les entrées illisibles. Les décodeurs basés sur l'attention atteignent ~1,5–3 % de CER sur l'anglais imprimé propre, surpassant les modèles exclusivement CTC sur les longues séquences et les mises en page irrégulières.

Vision Transformers (TrOCR, Donut)

TrOCR (Microsoft, 2021) a appliqué l'architecture Transformer à l'OCR. L'image est divisée en patchs, encodée par un encodeur ViT (Vision Transformer), et le texte est décodé de manière autorégressive par un décodeur de texte Transformer. C'est l'architecture d'un modèle multimodal standard, entraîné spécifiquement pour l'OCR. TrOCR obtient des résultats à l'état de l'art sur le texte imprimé (moins de 1 % de CER sur les numérisations propres) sans aucun prétraitement CNN, modèle de langage explicite ou segmentation au niveau des caractères.

Donut (NAVER, 2022) a étendu l'approche à la compréhension de documents : l'entrée est une image de document complète, et la sortie est un JSON structuré extrait directement des caractéristiques visuelles, contournant entièrement le pipeline OCR → NLP. Cela brouille la frontière entre l'OCR et l'analyse de documents d'une manière qui compte pour les applications réelles : extraire un total de facture, un numéro de passeport ou un tableau d'un article de recherche devient un seul appel de modèle au lieu d'OCR + regex + heuristiques.

Comparaison de performances (anglais imprimé, 300 DPI propre)

L'écart entre Tesseract et les meilleurs modèles Transformer est réel sur les benchmarks. En pratique, l'écart se réduit parce que la plupart des systèmes déployés fournissent à Tesseract une entrée propre, bien éclairée, à 300 DPI, et sur cette entrée, 1,8 % de CER signifie un caractère erroné tous les 55. Acceptable pour l'indexation de recherche, moins pour une transcription de document juridique.

L'OCR non-anglais : pourquoi c'est plus difficile

L'OCR anglais est un problème résolu. Un jeu de caractères de 26 majuscules, 26 minuscules, 10 chiffres et une poignée de signes de ponctuation donne environ 70 classes. Un problème de classification multi-classes confortablement dans la capacité d'un LeNet des années 1990. Les autres systèmes d'écriture du monde sont moins indulgents.

CJK : explosion du jeu de caractères

Le chinois, le japonais et le coréen (CJK) représentent le défi OCR le plus difficile rien que par la taille du jeu de caractères. Le chinois simplifié utilise environ 3 500 caractères courants et plus de 6 000 dans le texte général. Le chinois traditionnel ajoute un millier de formes variantes supplémentaires. Le japonais mélange deux syllabaires (hiragana, katakana : 46 caractères chacun) avec environ 2 000 kanji courants plus des caractères alphanumériques latins dans la même phrase. Le hangul coréen est phonétiquement régulier (24 lettres de base se combinant en blocs syllabiques), mais visuellement dense : un seul bloc peut contenir jusqu'à six composants jamo individuels entassés dans un espace d'environ la taille de deux caractères latins côte à côte.

Un système OCR CJK ne peut pas traiter la reconnaissance comme une classification à 70 voies. C'est une classification à 4 000 voies pour le japonais, 6 000 pour le chinois simplifié et plus de 10 000 pour le chinois traditionnel, au minimum. La couche de sortie softmax à elle seule a plus de paramètres qu'un modèle OCR complet pour écriture latine. Les besoins en données d'entraînement évoluent avec le jeu de caractères : ~100 échantillons étiquetés par classe pour une précision acceptable, donc les ensembles d'entraînement chinois commencent à 600 000 images de lignes de texte.

Tesseract fournit des fichiers traineddata CJK (chi_sim, chi_tra, jpn, kor), mais ils sont nettement plus volumineux que les modèles latins. chi_sim.traineddata fait ~50 Mo contre ~15 Mo pour eng.traineddata, et la reconnaissance est plus lente car l'espace de sortie est plus grand. La précision sur le texte CJK imprimé propre est de 2–5 % de CER pour Tesseract 5, soit environ 2 à 3 fois le taux d'erreur de l'anglais dans des conditions équivalentes.

L'arabe et les écritures de droite à gauche

L'arabe ajoute deux problèmes au-delà du jeu de caractères (28 lettres avec des formes contextuelles qui changent selon la position dans le mot). Premièrement, il s'écrit de droite à gauche, donc le moteur OCR doit détecter la direction du texte et inverser l'ordre de sortie. Deuxièmement, l'arabe est cursif. Les lettres d'un mot se connectent par un trait de ligne de base, rendant la segmentation intrinsèquement plus difficile qu'avec les formes de lettres majoritairement déconnectées des écritures latines et cyrilliques. Une image de mot arabe est un amas continu ; la segmentation basée sur les caractères est effectivement impossible, c'est pourquoi l'approche LSTM/CTC (qui opère sur des images de mots sans segmentation de caractères) a été une percée plus grande pour l'OCR arabe que pour l'OCR anglais.

L'hébreu, l'ourdou, le farsi et le pachto partagent une combinaison de ces défis. Tesseract fournit un traineddata arabe, mais la précision est d'environ 5–8 % de CER sur le texte imprimé propre, environ 4 fois moins bonne que l'anglais dans les mêmes conditions.

Les écritures indiennes : le problème des conjonctifs

Le devanagari (hindi, marathi, népalais) et les autres écritures brahmiques représentent un défi distinct : l'unité d'écriture n'est pas le caractère mais le conjonctif, un groupe visuellement fusionné d'une consonne, d'un modificateur de voyelle et parfois d'une consonne supplémentaire. Le bloc Unicode devanagari compte 128 points de code, mais le nombre de conjonctifs possibles dépasse 1 000. La "shirorekha" (la ligne de tête horizontale reliant les caractères dans un mot) rend la segmentation plus difficile car la ligne de tête fusionne les caractères adjacents en une seule unité visuelle.

Le traineddata hindi de Tesseract (hin) couvre les conjonctifs courants mais la précision est 3 à 4 fois inférieure à l'anglais sur le texte imprimé. Le tamoul, le télougou, le bengali et d'autres écritures indiennes sont moins bien prises en charge, certaines sans aucun fichier traineddata officiel. La cause racine est le volume de données d'entraînement : des images de lignes de texte annotées de haute qualité pour l'hindi existent par millions, tandis que pour le kannada, les ensembles de données disponibles se comptent en dizaines de milliers.

Texte vertical et mises en page à directions mixtes

Le japonais et le chinois traditionnel sont parfois composés verticalement, avec des lignes allant de haut en bas et des colonnes de droite à gauche. L'analyse de mise en page de Tesseract suppose un texte horizontal ; le texte vertical nécessite une pré-rotation ou un moteur séparé. Le texte horizontal et vertical mélangé sur la même page, courant dans les journaux japonais et les mangas, brise complètement l'hypothèse de direction unique et nécessite une détection de direction par région avant la reconnaissance.

Petites langues et données d'entraînement

Pour les langues de moins de 10 millions de locuteurs, des données d'entraînement OCR de haute qualité existent rarement. Le consortium Unicode a encodé plus de 150 écritures, mais Tesseract fournit des traineddata pour environ 120 langues, dont beaucoup sont générées à partir de texte synthétique rendu avec des polices standard sur des fonds propres. Les données synthétiques fonctionnent pour le texte imprimé dans des polices courantes et échouent pour les polices, papiers et qualités d'impression trouvés dans les documents réels de ces langues. Un modèle entraîné sur de l'Arial synthétique à 300 DPI ne lira pas un document amharique dactylographié des années 1970.

OCR côté navigateur avec Tesseract.js

Exécuter l'OCR dans le navigateur était impraticable avant l'arrivée de WebAssembly. Tesseract.js compile Tesseract 5 (LSTM) en WebAssembly via Emscripten, enveloppant le moteur C++ dans une API JavaScript qui exécute un Web Worker par tâche de reconnaissance. Le moteur, les données linguistiques et le worker sont chargés depuis des actifs statiques. Aucun aller-retour serveur pour les données d'image.

La surface de l'API est simple : créer un worker avec un ou plusieurs codes de langue, lui fournir une image, récupérer le texte reconnu avec des scores de confiance par caractère. Plusieurs workers peuvent s'exécuter en parallèle, limités par les cœurs CPU disponibles. Typiquement quatre tâches de reconnaissance parallèles sur un ordinateur portable grand public, six à huit sur les téléphones récents.

Les performances sont limitées par trois facteurs. Premièrement, WebAssembly s'exécute à environ 50–70 % de la vitesse native ; une ligne de texte qui prend 100 ms en Tesseract natif prend environ 160 ms dans le navigateur. Deuxièmement, les fichiers traineddata sont chargés via le réseau. eng.traineddata fait environ 15 Mo, chi_sim.traineddata environ 50 Mo, et les deux doivent être entièrement téléchargés avant que la reconnaissance ne commence. Troisièmement, le décodage d'image (JPEG/PNG/WebP/HEIC vers données de pixels brutes) utilise les décodeurs intégrés du navigateur, qui sont rapides mais varient selon le format et l'appareil.

L'avantage en matière de confidentialité est structurel. L'OCR côté client signifie que l'image ne quitte jamais l'appareil. Une photo de passeport, un relevé bancaire, un dossier médical. Les pixels sont décodés dans le navigateur, l'équivalent de Textract s'exécute dans un Web Worker, et le résultat est une chaîne de texte que l'utilisateur peut copier ou enregistrer. Aucun centre de données ne traite l'image. Ce n'est pas une fonctionnalité ; c'est l'absence de serveur, ce qui est catégoriquement différent d'une politique de confidentialité promettant de ne pas regarder.

Notre outil Image vers Texte utilise exactement cette pile : Tesseract.js avec reconnaissance LSTM, Web Workers pour le traitement parallèle, et traineddata pour 12 langues (anglais, espagnol, français, allemand, portugais, italien, chinois simplifié et traditionnel, japonais, coréen, hindi et russe). Déposez une photo, sélectionnez les langues, obtenez le texte. L'outil lit les entrées JPEG, PNG, WebP, BMP et GIF, applique une pré-mise à l'échelle tenant compte de la résolution (les images de plus de 3 000 pixels sur le côté le plus long sont réduites pour maintenir une latence de reconnaissance raisonnable) et produit du texte brut par image avec la confiance par caractère disponible.

Le choix du format d'image affecte la qualité de l'OCR en pratique. Les photos HEIC des iPhones, converties en JPEG avant l'OCR, acquièrent des artefacts de compression autour des bords du texte qui réduisent la précision de reconnaissance. Convertir d'abord le HEIC en PNG (sans perte, sans artefacts de quantification) préserve les contours nets dont le LSTM dépend. Nos convertisseurs HEIC vers JPG et HEIC vers PNG gèrent cette étape de prétraitement directement dans le navigateur. De même, les photos prises en faible luminosité bénéficient d'une conversion vers un format qui préserve toute la plage tonale avant le seuillage : JPG vers PNG évite les artefacts JPEG de deuxième génération qui s'accumulent lorsqu'une source JPEG est ré-encodée.

La pile OCR navigateur n'est pas compétitive avec les modèles côté serveur accélérés par GPU en termes de débit. Un serveur exécutant Tesseract sur 32 cœurs CPU en C++ natif surpassera toujours un onglet de navigateur. Elle l'emporte sur la confidentialité, zéro infrastructure et zéro coût par requête. Pour numériser quelques pages, un ticket de caisse ou une poignée de panneaux, la différence de latence entre 200 ms et 50 ms est imperceptible.

Vers où va l'OCR

L'OCR a cessé d'être un domaine de recherche autonome vers 2022 et a fusionné dans l'espace plus large de l'IA documentaire et des modèles multimodaux. Trois changements sont en cours.

LLMs multimodaux comme OCR zero-shot. GPT-4V, Claude et Gemini peuvent lire du texte à partir d'images sans entraînement OCR explicite. Fournissez la photo d'un document et demandez le texte, et le modèle le retourne. Non pas parce qu'il a une tête OCR dédiée, mais parce que la reconnaissance de texte émerge de l'entraînement sur des milliards de paires image-texte. La qualité est inégale. Sur l'anglais imprimé propre, GPT-4V atteint ~1 % de CER, comparable à un TrOCR affiné. Sur des photos de tickets de caisse chinois en basse résolution, il peut surpasser Tesseract parce que le modèle exploite le contexte (il sait à quoi ressemble un ticket de caisse et quels nombres attendre) plutôt que de se fier uniquement aux preuves au niveau des pixels. Sur l'écriture manuscrite, il est moins bon qu'un reconnaisseur affiné parce que la distribution d'entraînement n'incluait pas assez d'images manuscrites.

Le compromis est le coût et la latence. Un appel API à GPT-4V pour l'OCR coûte 1 à 3 centimes par page selon le nombre de tokens et prend 1 à 3 secondes. Tesseract s'exécute localement en 100–500 ms et ne coûte rien par page. Pour numériser un document de 200 pages, la différence est de 2–6 $ et plusieurs minutes de temps réel contre zéro et moins d'une minute. Pour un usage ponctuel (un seul ticket de caisse, une photo de tableau blanc), le modèle multimodal est plus simple et souvent plus précis.

Inférence sur l'appareil. Les modèles derrière l'OCR serveur rétrécissent. ONNX Runtime Web exécute des modèles CRNN quantifiés et de petits modèles ViT dans le navigateur à 50–100 ms par ligne de texte sur WebGPU. Le framework Vision d'Apple fournit un modèle OCR compact sur l'appareil pour iOS et macOS, accessible via VNRecognizeTextRequest sans appel réseau. L'écart entre "modèle GPU serveur" et "modèle navigateur" se réduit parce que les deux convergent vers le même point d'équilibre architectural : un petit encodeur ViT (~20–50M de paramètres) avec un décodeur léger, quantifié en INT8 ou FP16.

Compréhension de documents, pas seulement transcription. La sortie de l'OCR est une chaîne. La plupart des tâches réelles impliquent l'extraction d'informations structurées de cette chaîne : numéros de facture, dates, totaux, noms, adresses. L'approche traditionnelle enchaîne l'OCR avec des regex, la reconnaissance d'entités nommées et le mapping de schéma. Chaque étape est un modèle séparé avec ses propres modes d'échec. Les modèles de compréhension de documents de bout en bout (Donut, LayoutLMv3, Pix2Struct) sautent l'OCR et mappent directement les images de documents à des sorties structurées. Un modèle Donut affiné sur des tickets de caisse ne produit pas une transcription texte puis ne l'analyse pas. Il produit {"total": "42.50", "date": "2026-07-27", "vendor": "..."} directement à partir de l'entrée pixel. L'étape OCR, la partie dont traite cet article, devient un détail d'implémentation invisible.

Cela ne rend pas l'OCR obsolète. Cela en fait une brique de construction. Le pipeline doit encore gérer les cas limites : le ticket de caisse photographié en biais dans un restaurant sombre, le document dactylographié de 50 ans sur du papier jauni, le panneau dans une langue pour laquelle aucun grand modèle multimodal n'a été entraîné. Les moteurs OCR spécialisés entraînés sur ces distributions spécifiques surpasseront un modèle généraliste pendant des années, parce qu'un modèle généraliste entraîné sur l'intégralité d'Internet alloue une fraction infime de sa capacité à lire la sortie d'une machine à écrire amharique des années 1970.

L'OCR n'est pas un problème résolu pour la plupart des langues du monde et la plupart des conditions réelles de prise de vue. C'est un problème résolu pour le texte propre, 300 DPI, anglais, une colonne, imprimé mécaniquement — la tranche la plus étroite et la mieux financée de l'espace du problème. Le reste est encore ouvert.