La bifurcation de l’OCR : deux approches pour lire cent pages d’un coup

Vous êtes ingénieur data dans un cabinet de conseil. Sur votre bureau, un rapport sectoriel scanné de 200 pages — mélange de tableaux, graphiques, mises en page multi-colonnes, et des dizaines de pages d’annotations manuscrites. La mission est claire : transformer ce rapport en données structurées et l’injecter dans le pipeline d’analyse.

Qu’auriez-vous fait il y a quelques années ? Écrire un script, découper le PDF en 200 images, les envoyer une par une au moteur OCR, puis recoller les 200 morceaux de texte — avec de fortes chances de perdre les en-têtes de colonnes des tableaux à cheval sur deux pages, de bouleverser l’ordre de lecture multi-colonnes, et de couper des phrases aux frontières de page.

Le 23 juin 2026, deux posts apparaissent simultanément sur la page d’accueil de Hacker News : Unlimited OCR de Baidu en open source (428 points) et OCR 4 publié par Mistral (420 points). Deux événements le même jour pointent vers un même signal : l’ère de l’OCR pour longs documents est arrivée. Mais comment y parvenir, les deux acteurs donnent des réponses radicalement différentes.

Un vieux problème : pourquoi l’OCR de longs documents est-il si difficile ?

L’OCR en soi n’est pas un problème nouveau. Tesseract existe depuis quarante ans, et les API de reconnaissance documentaire des fournisseurs cloud tournent depuis des années. Mais toutes ces solutions butent sur le même mur face aux longs documents : l’explosion du cache KV.

L’approche qui consiste à utiliser un grand modèle de langue pour l’OCR est en gros la suivante : encoder l’image du document en une séquence de tokens visuels, et laisser le LLM « lire » le texte token par token. À chaque token généré, le modèle doit consulter l’état de tous les tokens précédents — ces états sont stockés dans une structure appelée cache KV. Plus le document est long, plus le contenu généré est long, plus le cache KV croît linéairement en O(N), jusqu’à saturer la mémoire vidéo.

La réponse standard de l’industrie à ce problème est le fameux « découpage-recollement » mentionné plus haut — découper le long document en pages individuelles, les traiter une par une, avec un orchestrateur externe pour gérer le flux. Le commentaire de l’utilisateur HN robotswantdata dans la discussion Unlimited OCR est très juste : « Les développeurs sont forcés d’écrire du code sale qui découpe les PDF en pages individuelles, les traite une à une, et recolle le texte ensuite (janky code that chops PDFs into individual pages, processes them one by one, and glues the text back together). »

Ça fonctionne, mais ce n’est pas de la véritable compréhension de documents longs. Le contexte inter-pages est perdu, les tableaux sont fragmentés, l’ordre de lecture est perturbé — autant de conséquences des « rustines d’ingénierie ».

L’approche Baidu : compresser le cache KV à une constante avec R-SWA

L’innovation centrale d’Unlimited OCR de Baidu s’appelle Reference Sliding Window Attention (R-SWA), un mécanisme d’attention qui compresse le cache KV de O(N) à O(1).

Sans formule, comprenons par l’intuition.

Imaginez que vous recopiez un livre. Vous regardez le texte original (Référence) tout en écrivant (Génération). Vous n’avez pas besoin de relire tout ce que vous avez déjà copié à chaque nouveau mot — vous jetez simplement un coup d’œil de temps en temps aux dernières lignes écrites pour vérifier que vous n’avez pas sauté une ligne. Le texte original reste toujours devant vos yeux, sans se brouiller ni disparaître.

C’est exactement ce que fait R-SWA. Il divise le chemin d’attention en deux voies :

• La voie Référence Globale : chaque token généré prête attention à l’ensemble des tokens visuels (c’est-à-dire l’image du document) et au prompt — le texte original reste toujours net, le contexte inter-pages n’est jamais perdu.
• La voie Génération Locale : chaque token généré ne prête attention qu’aux 128 derniers tokens générés — la mémoire à court terme n’a besoin que d’une fenêtre glissante, les anciens états de tokens peuvent être oubliés sans danger.

Le point clé est que les tokens visuels ne participent pas à la « mise à jour d’état ». Ils sont uniquement lus, jamais modifiés. Cela évite un défaut classique de l’attention par fenêtre glissante : les caractéristiques visuelles qui se « brouillent » progressivement avec la mise à jour des états, entraînant une dégradation de la précision de reconnaissance.

Résultat : le cache KV reste de taille constante tout au long du décodage. Vous jetez un PDF de 40 pages dans le modèle, une seule inférence lit tout — pas besoin de découpage, pas d’orchestrateur externe, pas de « code sale de recollement de pages ».

Sur le plan technique, Unlimited OCR prend DeepSeek OCR comme baseline, conserve son DeepEncoder à taux de compression élevé de 16×, mais remplace toutes les couches d’attention du décodeur LLM par R-SWA. Le modèle fait 3B de paramètres, n’en active que 500M à l’inférence (architecture MoE), obtient un score composite de 93% sur OmniDocBench v1.5, dépassant la baseline DeepSeek OCR de 6 points de pourcentage.

L’article est sur arXiv, le code sur GitHub (licence MIT), les poids du modèle sur HuggingFace et ModelScope. La voie académique classique : publier l’article, ouvrir le code, publier les poids, laisser la communauté étendre.

L’approche Mistral : définir l’intelligence documentaire par une solution produit

Le même jour, Mistral a publié OCR 4, un an après sa dernière mise à jour de la gamme OCR.

L’argument de vente d’OCR 4 est la complétude de la livraison d’ingénierie. Il fait passer l’OCR de « l’extraction de texte » à « la compréhension de la structure du document » : la sortie n’est pas seulement du texte, elle inclut des bounding boxes (localisation de chaque bloc de texte dans la page), la classification des blocs (titres, tableaux, formules, zones de signature) et un score de confiance inline (niveau de confiance par caractère ou par mot).

Support de 170 langues, 10 familles linguistiques. Un seul conteneur suffit pour un déploiement auto-hébergé. Score de 85,20 sur OlmOCRBench, taux de victoire moyen de 72% dans les tests de préférence humaine.

Du point de vue du positionnement de Mistral, OCR 4 est un « composant d’ingestion » de son pipeline d’intelligence documentaire — en complément du Search Toolkit pour la recherche d’entreprise, le RAG et la recherche de domaine. Les bounding boxes permettent de surligner les résultats de recherche dans le document original ; les scores de confiance pilotent les flux de vérification humaine ; la sortie structurée en blocs rend les pipelines de données en aval plus fiables.

Code fermé, API commerciale, facturation au volume — la voie classique d’une entreprise produit.

La dérive des commentaires HN : l’adresse manuscrite, le vrai miracle de l’OCR ?

La section commentaires de Mistral OCR 4 sur HN a pris une tournure intéressante. Le commentaire le plus upvoté vient d’ericyd :

« J’ai toujours pensé que le service postal américain était un miracle technique. Ils arrivent à reconnaître et router des milliards de courriers, avec des adresses écrites de façon extrêmement non standardisées — la même adresse peut s’écrire de plusieurs manières… »

Puis idoubtit a enchaîné avec une histoire encore plus extrême : son père a reçu dans les années 70 une lettre envoyée d’Algérie, avec seulement trois mots sur l’enveloppe — son nom, le nom de la ville « Créteil », et « France ». Sans Internet, sans base de données centrale, le système postal a réussi à acheminer la lettre.

À mes yeux, il y a une tension subtile entre ces histoires et la sortie de Mistral OCR 4. Elles rappellent aux praticiens que l’objectif ultime de l’OCR est la reconnaissance dans le monde réel, extrêmement non standardisée, extrêmement dépendante du contexte. Le routage des adresses manuscrites est peut-être le premier « OCR de longs documents » du domaine — sauf que son « document » était l’enveloppe, et son « modèle » la mémoire qu’avait le facteur de son quartier.

La bifurcation : les dimensions du choix

À mes yeux, Unlimited OCR de Baidu et OCR 4 de Mistral représentent deux philosophies de livraison différentes sur la même piste.

Choisir la voie Baidu, vous obtenez : un article que vous pouvez lire, une base de code que vous pouvez modifier, un mécanisme d’attention générique transférable à d’autres tâches (l’article mentionne l’ASR, la traduction). Le prix à payer est de devoir déployer vous-même, régler les paramètres vous-même, gérer les problèmes d’ingénierie vous-même. Cela convient aux équipes avec des capacités d’ingénierie, à la recherche académique, ou aux scénarios nécessitant du finetuning personnalisé.

Choisir la voie Mistral, vous obtenez : un endpoint API, une sortie JSON structurée, un pipeline d’intelligence documentaire prêt à l’emploi. Le prix à payer est de ne pas voir les poids du modèle, de ne pas pouvoir modifier la logique interne, de payer au token. Cela convient aux déploiements entreprise, à l’intégration rapide, aux scénarios de production nécessitant des bounding boxes et des scores de confiance.

Les deux ne sont pas mutuellement exclusifs. Le pipeline documentaire d’une même entreprise peut utiliser les deux solutions : optimiser l’efficacité du traitement des longs documents avec l’approche Unlimited OCR, puis utiliser la sortie structurée d’OCR 4 pour la localisation et la recherche en aval.

Le véritable point d’inflexion : de « pouvoir lire » à « pouvoir tout lire d’un coup »

Quelle que soit la voie choisie, le 23 juin 2026 mérite d’être retenu. Pas parce que deux produits sont apparus simultanément sur la page d’accueil de HN — ce n’est que la surface. Mais parce que le domaine de l’OCR a officiellement franchi une ligne : de « à peu près utilisable » à « l’analyse de longs documents en zero-shot ».

Il y a un an, faire lire 40 pages de document scanné d’un seul coup à un modèle relevait encore du fantasme. Aujourd’hui, c’est le point de départ commun de deux voies techniques différentes. R-SWA a prouvé que l’innovation mathématique sur les mécanismes d’attention peut ouvrir de nouveaux espaces de possibilités ; OCR 4 a prouvé que le polissage d’ingénierie de la sortie structurée peut intégrer l’OCR dans de véritables pipelines de production.

Pour l’ingénieur face à son rapport de 200 pages, la réponse n’est plus « écris une boucle for pour découper et recoller ». Quant à savoir s’il faut utiliser la solution open source R-SWA ou appeler l’API Mistral, c’est une autre histoire.