Modèles de vision, IA agentique, RAG : l’OCR en plein renouveau

Mistral AI et DataLab mettent l’OCR au service de l’IA agentique  

Le 23 juin 2026, Mistral AI a lancé Mistral OCR 4. Le VLM prend en charge 170 langues différentes ainsi que les formats PDF, DOC, PPT et Open Document. Surtout, OCR 4 ne reconnaît pas seulement les mots, mais également la structure des documents.

« OCR 4 fournit des cadres de sélection, une classification des blocs de texte (titres, tableaux, équations, signatures, etc.) et des scores de confiance intégrés », affirme Mistral AI, dans un billet de blog. « Les cadres de sélection, notre fonctionnalité la plus, permettent de localiser le texte afin de le mettre en évidence dans son contexte et de garantir la fiabilité des flux de données », poursuit la startup. « Parallèlement, les types de blocs et les scores de confiance facilitent la création de citations fondées sur la source, le caviardage et la vérification par un intervenant humain ».

De ce fait, le modèle serait idéal pour l’analyse et l’extraction de documents, l’exécution de pipelines RAG et peut être intégré dans des flux de travail agentique.

Le benchmark interne réalisé par Mistral AI placerait OCR 4 devant Chandra OCR 2 de Datalab, Mineru Pro d’OpenDataLab et PaddleOCRVL de PaddlePaddle toutes langues confondues. OCR 4 dépasserait également ces mêmes adversaires sur le parangonnage OlmOcrBench, consacré à la performance de l’extraction en général. Et Mistral AI d’insister que ces bancs d’essai ne traduisent pas entièrement les performances réelles de son modèle. Ils souffriraient de limitations documentées. De manière générale, les benchmarks sont « directionnels ». « Tous les scores des concurrents reflètent des reproductions internes. Nous recommandons d’évaluer [les VLM OCR] sur vos propres documents ».

OCR 4 reste un modèle propriétaire. Il coûte 4 dollars pour 1000 pages à travers son API, 2 dollars pour des traitements en lot. Mistral AI met également à disposition une interface no-code, nommé DocumentAI. Là, le recours à OCR 4 coûte 5 dollars pour 1000 pages. Le VLM tient sur un seul conteneur et peut être déployé sur site à la demande. Le modèle est disponible sur Microsoft Foundry, Amazon SageMaker et bientôt Snowflake.

Si Mistral AI cherche la frugalité, la plupart des nouveaux acteurs privilégient l’approche open source et veulent rendre possible l’inférence locale.

En plus de Chandra 2.1, un modèle de 4 milliards de paramètres, DataLab a présenté le 27 mai Surya OCR 2, un VLM open weight de 650 millions de paramètres capables de reconnaître 91 langues et de traiter jusqu’à 5 pages par seconde (18 000 pages par heure) sur une seule carte graphique prosumer Nvidia Geforce RTX 5090 (32 Go de VRAM). Les performances approchent celle du modèle de LightOn. Si les poids sont ouverts, DataLab ne dévoile pas ses recettes. Le 18 juin, il a présenté lift, un autre VLM propriétaire (mais sous une licence permissive) de 9 milliards de paramètres capable d’extraire des schémas JSON à partir de PDF ou d’images. De la sorte, les fichiers au format JSON peuvent être stockés dans une base de données relationnelle ou orientée documents.  

 Datalab et Mistral AI entrent clairement en compétition, toutefois les acteurs cités font varier les propositions technologiques.

DeepSeek et Baidu se concentrent sur les documents longs

Une explication s’impose. La plupart des modèles de vision langage couplent un encodeur de type Transformer Vision (VIT) à un LLM, qui joue le rôle de décodeur.

Le rôle de l’encodeur est d’extraire des informations visuelles des images – ici les caractères, les tableaux – en entrée, de les convertir en tokens et de les compresser. Le décodeur génère le résultat, à savoir le texte structuré issu du fichier source.

Avec Unlimited OCR, Baidu entend numériser et analyser de longs documents. Pour ce faire, le fournisseur chinois Baidu s’appuie sur l’architecture de DeepSeek OCR, un VLM « sMoE » doté de 3 milliards de paramètres, dont 500 millions sont actifs.

Les chercheurs de Baidu ont choisi cette base pour son efficacité. DeepEncoder, l’encodeur de DeepSeek OCR, combine lui-même deux encodeurs VIT.

Il dispose ainsi d’une couche d’attention locale pour convertir et traiter les tokens en entrée, assuré par une variante du projet SAM (Segment Anything Model) de Meta. Un « pont » entre les deux modèles sert à compresser les tokens, puis la couche d’attention globale de l’encodeur CLIP d’OpenAI est utilisée pour les interpréter. De la sorte, l’encodeur tient sur 380 millions de paramètres et peut compresser une image PDF de 1024 par 1024 pixels en seulement 256 tokens.

Or, au moment de traiter de longs documents, c’est le décodeur qui pose un problème. Les LLM ont tendance à occuper plus de mémoire vive quand un grand nombre de pages s’accumule. Cette mémoire abrite le KV Cache. Ce cache contient les paires de clés-valeurs qui désignent les tokens textuels et visuels des documents (de manière plus générique, les images), les tokens du prompt en entrée et leur position.

DeepSeek 3B dispose d’une fenêtre de contexte de 128 000 tokens. Malgré le taux de compression de DeepEncoder, un document de 20 à 30 pages peut occuper jusqu’à 100 000 tokens, estime Baidu. Le « crash » n’est pas loin.

En conséquence, Baidu remplace la couche d’attention multitête du décodeur pour s’en affranchir. Le mécanisme en question est nommé Reference Sliding Window Attention (R-SWA). Celui-ci permet de disposer d’un KV Cache d’une taille « constante ». En clair, les tokens du document en entrée sont conservées en mémoire, mais la fenêtre d’attention glissante ne se concentre que sur une part fixe des derniers tokens. Comme un humain, le modèle oublie le texte qu’il a déjà transcrit, illustre Baidu. Unlimited OCR ne dispose que d’une fenêtre de contexte de 32 000 tokens, mais il peut traiter environ 40 pages en étant 35 % plus rapide que DeepSeek OCR avec des résultats supérieurs.

Au-delà des 40 pages, les erreurs s’accumulent à cause de la résolution insuffisante de DeepEncoder, dixit Baidu. Ici, le terme « infini » est abusif : Unlimited OCR ne peut pas emmagasiner des documents de plusieurs milliers de pages. Il faudra allonger la fenêtre de contexte pour ce faire. C’est prévu. Et cette même fenêtre d’attention pourrait servir dans d’autres cas d’usage, anticipe l’entreprise chinoise.

PaddlePaddle et son « système OCR léger »

PaddlePaddle va plus loin en matière de frugalité, mais se rapproche davantage des acteurs traditionnels. PP-OCRv6 est une collection de trois modèles dédiés à l’OCR. Leur taille respective ? 1,5 million, 7,7 millions et 34,5 millions de paramètres. Ils prennent en charge 48 langues et sont compatibles avec le kit logiciel OpenVino. Ils peuvent être exécuté sur un CPU.

PP-OCRv6 ne serait pas un VLM, ni un LLM multimodal, mais un « système OCR léger ». Il combine un réseau de neurones convolutif dédié à la détection de texte et un encodeur de reconnaissances de texte – doté d’un mécanisme d’attention global – unifiées sur un même « backbone ».  

Avec son précédent modèle, le fournisseur chinois s’appuyait sur deux socles architecturaux. Il s’en est débarrassé en raison « de la complexité d’entraînement, de déploiement et de maintenance ».

Le backbone encode l’image en entrée dans une carte de caractéristiques – c’est-à-dire des abstractions de concepts appris par le modèle. Avec les modèles petit et moyen, cette carte est interprétée par l’encodeur. Elle est seulement redimensionnée avec le plus petit modèle. Puis elle est décodée par une architecture multitête pour générer le résultat. Celle-ci est divisée en deux branches : l’une pour l’entraînement, l’autre pour l’inférence rapide.

Par ailleurs, PaddlePaddle a revu ses pipelines de curation de données au regard de trois dimensions : la difficulté, la précision et la diversité. L’éditeur a surtout intégré de nouveaux cas d’usage : la reconnaissance de schémas de PCB, de dessins CAO, ou encore de matrices de texte. Résultat, il dit faire mieux que Qwen3-VL-235B, Gemini 3.1 Pro, GPT-5.5, Kimi K2.6 et Minimax-M3.

DocLang, une norme pour faciliter l’interprétation des documents par les agents IA

Malgré cette avalanche de revendications, ABBYY n’a pas dit son dernier mot. Outre le fait qu’il combine machine learning et OCR traditionnelle à travers sa solution FineReader Engine, l’éditeur est l’un des premiers soutiens du projet DocLang.

Cette spécification portée par la Linux Foundation, IBM, Red Hat, HumanSignal, Nvidia et Forgis vise à structurer les documents pour les LLM, les agents IA et les pipelines RAG. DocLang fournit une syntaxe et des éléments sémantiques pour le langage markup (XML) du projet. Le langage s’accompagne de règles pour encoder la structure des documents, leur contenu et les métadonnées, des éléments de représentation de la pagination, du formatage du texte, du code, des diagrammes, des tables, etc. Il s’agit non seulement de rendre les documents plus aisément interprétables par les tokenisers des LLM, mais également de réduire le volume de tokens en entrée.

Reste à voir désormais si le marché adoptera cette norme. ABBYY l’intègre déjà dans la version 12.8.0 de son FineReader Engine. Et l’éditeur d’assurer que son moteur peut traiter jusqu’à 2,16 millions de pages par heure. Dans un test, il dit avoir traité 23 000 pages en 130 secondes en répartissant la charge de travail sur 60 conteneurs propulsés par des CPU.

Son modèle commercial est plus complexe : ABBY différencie des licences développeurs et pour la production. FineReader Engine peut être installé sur un ordinateur ou sur des serveurs. Le prix dépend d’un nombre de pages ou de caractères traités par mois.

De l’importance du pipeline OCR

Justement. Le réseau canadien de documentation pour la recherche, issue d’un partenariat incluant 88 établissements, dont des bibliothèques universitaires, a réalisé en mai 2026 un comparatif entre ABBYY FineReader Server 14 et les modèles de précédentes générations de Datalab, DeepSeek et PaddlePaddle. Le réseau a l’expérience nécessaire : les établissements ont numérisé plus de 64 millions de pages.

Les tests portent plus particulièrement sur des documents « difficiles », dont des pages de journaux. ABBYY FineReader Server demeure plus efficace que les solutions des nouveaux venus, mais les outils de PaddlePaddle s’en rapprochent suffisamment pour en justifier l’usage.

Plutôt que d’établir un vainqueur, Brittny Lapierre, responsable du développement des infrastructures numériques du réseau, l’autrice du rapport, voit là deux philosophies s’affronter. « ABBYY se distingue souvent en associant la reconnaissance à la structure, aux contraintes et au contrôle qualité au niveau du flux de travail », constate-t-elle.

Avec ses modèles et ses outils, PaddlePaddle pousse une approche similaire, mais « offre davantage d’ouverture, de flexibilité et de contrôle sur la pile OCR ». Quant à Datalab, avec Chandra, il se concentre sur « des résultats structurés de haute-fidélité ». DeepSeek OCR – et donc Unlimited OCR – est plus adapté pour les documents longs et la production de fichiers Markdown.

De manière générale, Brittny Lapierre souligne l’importance du pipeline OCR. « La qualité du résultat peut dépendre de bien plus que de la simple reconnaissance de caractères », nuance-t-elle. L’amélioration de l’image, la détection de la mise en page, la restauration de l’ordre de lecture (un phénomène qui affecte les fichiers PowerPoint), l’extraction des champs, les règles de validation, les processus de révision humaine et la normalisation à l’exportation sont autant d’éléments à étudier.