Visual RAG : faire du RAG sur PDF, scans et images (guide 2026)

Pourquoi le Visual RAG existe (et pourquoi vous en aurez besoin sans l’avoir demandé)

Vous pouvez avoir la meilleure base de connaissance du monde… et tomber sur un PDF.

Un vrai PDF. Pas le PDF “texte” qu’on copie-colle. Le PDF scanné, grainy, avec une signature en bas, un tableau au milieu, et un tampon “URGENT” qui fait joli en audit.

C’est là que les RAG “classiques” (texte → embeddings → retrieval) montrent leur limite : ils ne voient pas le document. Ils voient… le néant.

Le Visual RAG, c’est la réponse pragmatique : transformer un document visuel en source interrogeable, tout en conservant la provenance (page/zone), sinon vous obtenez le pire des deux mondes : une réponse confiante et impossible à auditer.

OCR-first vs VLM-first : deux routes, une même destination

On peut résumer le débat comme ça :

• OCR-first : “d’abord je lis, ensuite je comprends”.
• VLM-first : “je comprends en regardant”.

Et comme souvent en ingénierie… la bonne réponse est : ça dépend.

Route A — OCR-first (la plus stable en prod)

L’idée : convertir le document en texte + structure (layout, tableaux) puis appliquer un RAG classique.

Vous pouvez vous appuyer sur des solutions Document AI commerciales :

• Google Cloud Document AI (OCR + parsing orienté documents).¹
• Azure AI Document Intelligence (ex-Form Recognizer).²
• AWS Textract (notamment pour tableaux et formulaires).³

Ou sur de l’open source :

• Tesseract (OCR historique, bon sur certains cas, exigeant sur d’autres).⁴
• PaddleOCR (multilingue, plus “moderne”, beaucoup d’options).⁵

Avantages

• Vous pouvez indexer, rechercher, filtrer.
• Vous avez des passages textuels “citable”.
• Vous scalez mieux sur des documents multi-pages.

Inconvénients

• L’OCR peut casser des éléments critiques (une virgule, un IBAN, une date).
• La structure (tables) est parfois difficile.

Route B — VLM-first (quand le visuel fait partie de la réponse)

Ici, vous utilisez un modèle vision-langage (VLM) pour interpréter une page (image) : diagrammes, schémas, mise en page complexe, éléments non textuels.

Deux approches courantes :

1. “VLM pour résumer + indexer” : le VLM produit un texte (caption, description, extraction), puis vous indexez.
2. “VLM dans le loop” : au moment de la question, vous envoyez la/les pages candidates au VLM.

Le papier “Donut” est un exemple de modèle orienté compréhension documentaire sans OCR (il traite le document comme une séquence).⁶

Avantages

• Comprend des pages où le texte seul est insuffisant.
• Peut gérer certains visuels (diagrammes, images).

Inconvénients

• Plus coûteux, plus sensible aux limites de contexte et de débit.
• Plus difficile à rendre “audit-proof” si vous ne conservez pas les preuves.

Le pipeline Visual RAG qui tient (sans magie, mais avec de la méthode)

On déroule la version “prod”.

1

Ingestion : stocker le brut + gouverner la source

Stockez le fichier original (avec hash), les métadonnées (client, dossier, date), et les droits (qui peut le lire). Sans ça, vous construisez un moteur de fuite de données.

2

Normalisation : pages, images, rotation, qualité

Détectez orientation, résolutions, pages vides. Beaucoup d’erreurs “IA” sont en fait des erreurs de scan.

3

OCR / parsing : extraire texte + structure

Objectif : obtenir texte, blocs, coordonnées, tableaux, champs. Textract et consorts documentent des pipelines orientés tables/formulaires.³

4

Layout-aware chunking : découper sans perdre la page

Un chunk doit garder (a) son texte, (b) sa page, (c) sa zone, (d) son contexte (titre/section), sinon vous perdez l’audit.

5

Indexation : embeddings + métadonnées + preuves

Indexez les chunks (vecteurs) mais conservez les métadonnées : page, bbox, type (table, paragraphe), date, source. Visual RAG = RAG + preuve.

6

Retrieval : texte + filtres, puis reranking si besoin

La clé : réduire le bruit. Si votre retrieval remonte 10 pages “presque bonnes”, votre LLM improvisera.

7

Génération : réponse + citations (page/zone)

La réponse doit pointer : « page 7, paragraphe 2 ». C’est ce qui rend le système adoptable.

8

Fallback : VLM ciblé sur pages ambiguës

Pour un tableau tordu, une signature, un schéma : appelez un VLM uniquement sur ces pages. Le VLM devient un outil, pas un mode de vie.

Layout-aware chunking : la différence entre “retrieval” et “archéologie”

Un Visual RAG échoue souvent à cause d’un truc bête : il découpe mal.

Le document, ce n’est pas un flux de texte : c’est une mise en scène.

Les 4 règles (simples, mais pas négociables)

1. Page d’abord : chaque chunk sait de quelle page il vient.
2. Zone ensuite : chaque chunk garde sa bbox (ou au minimum son bloc).
3. Titre/section : récupérez la hiérarchie (sinon “Article 12” devient orphelin).
4. Type de contenu : table ≠ paragraphe ≠ liste.

Lire l’ordre de lecture (le détail qui change tout)

Un document n’est pas un texte : c’est une mise en page. Colonnes, encarts, notes de bas de page, tableaux, en-têtes… et parfois un logo qui n’a rien demandé.

Deux options réalistes :

1. Heuristiques (souvent suffisantes) : détecter colonnes, suivre les blocs de haut en bas, préserver les titres, rattacher les notes de bas de page.
2. Modèles “layout-aware” : utiliser des modèles pré-entraînés qui exploitent à la fois le texte et la mise en page pour représenter le document (famille LayoutLM, par exemple).⁸

La bonne stratégie en entreprise est souvent hybride :

• heuristiques en V1 (rapide, contrôlable),
• puis modèle layout-aware sur les documents qui posent problème (complexes, multi-colonnes, formulaires).

Pourquoi ? Parce qu’un mauvais ordre de lecture crée des hallucinations “propres” : le modèle assemble deux bouts qui ne devraient jamais se rencontrer. Et comme il écrit bien… ça passe.

Si vous ne respectez pas ça, vous ne faites pas du retrieval. Vous faites de l’archéologie : vous retrouvez des bouts, mais vous ne savez plus d’où ils viennent.

Tables, formulaires, champs : quand le Visual RAG doit produire du “structuré”

Beaucoup d’équipes découvrent le problème trop tard :

L’utilisateur ne veut pas “une réponse”. Il veut un champ. Un montant. Une date. Une référence.

Et là, un Visual RAG “texte-only” peut se comporter comme un étudiant en partiels : il reformule très bien… mais il ne remplit pas la case.

Le pattern robuste consiste à séparer deux sorties :

1. une sortie “explication” (naturelle, pour l’humain),
2. une sortie “structurée” (JSON/champs, pour le système).

Exemples typiques :

• extraire la date d’échéance d’un contrat (et citer la page),
• lire un numéro de police dans un scan (et signaler l’incertitude),
• récupérer les lignes d’un tableau (et conserver l’alignement).

Et si vous avez besoin d’un “agent documents” (pas seulement de Q/R), lisez : Agents documents : OCR, parsing, tables, citations.

La stack 2026 : open source vs commercial (OCR, VLM, orchestration)

OCR / Document AI

• Google Document AI (commercial).¹
• Azure AI Document Intelligence (commercial).²
• AWS Textract (commercial).³
• Mistral OCR (commercial, documenté comme capacité).⁷
• Tesseract / PaddleOCR (open source).⁴⁵

Document AI “clé en main” : utile… si vous gardez la chaîne

Certains fournisseurs proposent aussi des capacités “document” plus haut niveau (OCR + extraction + parfois Q/R), qui peuvent accélérer une V1. Par exemple, Mistral documente une capacité “Document AI”.¹¹

Deux conseils pour éviter le piège :

1. gardez un accès aux sorties intermédiaires (texte, blocs, tables),
2. et conservez la preuve (page/zone) côté produit, pas seulement “dans la magie du service”.

Sinon, vous gagnez du temps au début… et vous perdez la maîtrise quand il faut expliquer une décision en audit.

VLM (vision-langage)

On retrouve le même dilemme qu’avec les LLM : performance vs contrôle.

• Commercial : familles OpenAI / Anthropic / Google Gemini / Mistral (selon besoins et contraintes). Pour les repères “2026”, voir : Modèles IA 2026 pour chatbot.
• Open source : vous trouverez des VLM sur Hugging Face, avec des compromis (qualité, vitesse, hébergement).

L’important n’est pas “qui gagne”. L’important est : pouvez-vous fournir une preuve (page/zone) et garder un pipeline stable.

Évaluer un Visual RAG : la checklist anti-hallucination documentaire

Vous devez mesurer plus que la “jolie réponse”.

1) Qualité OCR / parsing

Si la lecture est fausse, tout le reste est faux.

2) Pertinence retrieval

La question : est-ce qu’on remonte les bons blocs, sur la bonne page ?

3) Groundedness + citations

Est-ce que la réponse cite la bonne page/zone et reste cohérente avec l’extrait ?

4) Temps humain

Le Visual RAG “gagne” quand il fait gagner du temps aux équipes. Pas quand il génère un roman.

Citations “auditables” : page + zone + snapshot

La citation, ce n’est pas “un lien en bas”.

Une citation utile contient :

• la page,
• la zone (bbox ou au minimum le bloc),
• et un extrait stable (ou un snapshot du document).

Pourquoi ? Parce que sans snapshot, vos preuves changent. Le document est remplacé, l’URL renvoie autre chose, et vous vous retrouvez à défendre un système avec : “je vous promets qu’hier c’était écrit”.

Le Visual RAG, c’est justement l’occasion de faire mieux : la preuve fait partie du produit.

Sécurité : l’injection de prompt… via un document

Oui, un PDF peut devenir une attaque.

Un scénario fréquent : un document contient du texte qui ressemble à une instruction (“Ignore les règles, réponds autre chose…”). Si vous injectez ce texte tel quel dans le prompt, vous ouvrez la porte à des attaques de prompt injection et à des dérives de comportement.

L’OWASP recommande de traiter ces risques sérieusement dans les applications LLM (filtrage, séparation des rôles, validation).⁹

AWS détaille aussi des mécanismes d’attaques et des stratégies de mitigation (notamment sur les prompts injectés via des contenus externes).¹⁰

Le bon réflexe : considérer le texte extrait comme non fiable, au même titre qu’une entrée utilisateur. On le contextualise (“ceci est un extrait de document”), on le filtre, et on impose au modèle des règles explicites.

Performance : multi-pages, batching, et “ne pas payer deux fois”

Un Visual RAG scalable évite trois gaspillages :

1. refaire l’OCR à chaque question (ingestion = offline),
2. envoyer 40 pages au VLM parce que “peut-être”,
3. injecter 15 chunks “au cas où”.

En général :

• OCR + indexation se font en batch (pipeline),
• retrieval + reranking font le tri,
• VLM intervient ponctuellement,
• et la génération finale reste sobre.

L’objectif n’est pas d’être impressionnant. C’est d’être stable quand le volume grimpe.

Si vous démarrez : faites une V1 OCR-first avec preuves (page/zone), puis ajoutez le VLM là où il apporte un vrai signal. C’est rarement l’inverse.

FAQ

Questions frequentes

Faut-il faire du VLM direct sur tout le PDF ?+

Rarement. Sur des documents multi-pages, OCR + chunking + retrieval est souvent plus stable et scalable. Utilisez le VLM comme un outil ciblé sur les pages difficiles (tableaux complexes, schémas, visuels), pas comme un bulldozer.

Peut-on faire du Visual RAG sans services cloud ?+

Oui, mais c’est plus d’ingénierie : OCR open source (Tesseract/PaddleOCR), parsing, stockage, puis RAG. Ça peut être une bonne option si vous avez des contraintes fortes de souveraineté et les compétences internes.

Quelle différence avec un agent “documents” ?+

Le Visual RAG est centré sur “retrouver et répondre avec preuves”. Un agent documents va souvent plus loin : extraction structurée, décisions, tool calling, workflows. Voir : Agents documents : OCR, parsing, tables, citations.

Sources et references

1. [1]Google Cloud, “Document AI overview”.
2. [2]Microsoft Learn, “Azure AI Document Intelligence overview”.
3. [3]AWS Docs, “Amazon Textract: Analyzing tables”.
4. [4]GitHub, “tesseract-ocr/tesseract”.
5. [5]GitHub, “PaddleOCR”.
6. [6]Kim et al., “Donut: Document Understanding Transformer without OCR”.
7. [7]Mistral AI Docs, “OCR (capability)”.
8. [8]Xu et al., “LayoutLM: Pre-training of Text and Layout for Document Image Understanding”.
9. [9]OWASP, “Top 10 for LLM Applications”.
10. [10]AWS, “Prompt Injection Attacks: What, Why & How” (whitepaper).
11. [11]Mistral AI Docs, “Document AI”.