Agents documents : OCR, parsing, tables et citations

Le document est le boss final du B2B

Quand on vend des agents en entreprise, on finit toujours par tomber sur un PDF.

Même quand on n’a rien demandé.

Le document est partout :

• contrats,
• avenants,
• factures,
• relevés,
• formulaires,
• scans moches,
• tableaux en diagonale (pourquoi ?),
• et “petites notes” qui contiennent l’information critique.

Donc les agents “documents” sont un cas d’usage central, mais aussi une zone de danger :

• hallucinations (“il a inventé une clause”),
• erreurs de lecture (OCR bancal),
• perte de structure (tableaux devenus soupe de texte),
• et surtout : absence de preuve.

En entreprise, la question n’est pas “est-ce que l’agent est intelligent ?”. La question est :

“Peux-tu me montrer d’où tu sors ça ?”

Si vous ne pouvez pas répondre, vous n’avez pas un agent. Vous avez une opinion bien formulée.

Le pipeline qui tient : ingestion → OCR/parsing → structuration → décision → citations

Il y a mille variantes, mais les briques sont toujours les mêmes.

1) Ingestion (et normalisation)

Objectif : transformer “un PDF envoyé par mail” en objet gouvernable :

• identifiant,
• hash (déduplication),
• métadonnées (client, dossier, date),
• stockage brut sécurisé,
• et trace (qui l’a envoyé, quand).

Rien n’est sexy ici. Tout est rentable.

2) OCR / parsing : extraire le contenu et la structure

Selon vos documents, vous utilisez :

• OCR (si scan/photographié),
• parsing (si PDF texte, Word, HTML),
• ou hybride.

Unstructured se décrit comme une solution open source d’ETL pour transformer des documents en formats structurés “ready for LLMs”.¹²

Et sa doc insiste sur la partition (partitioning) : extraire un document en “éléments” structurés (titres, paragraphes, tables, etc.).²

3) Structuration : champs, tables, sections, pages

Ici, votre objectif n’est pas “du texte”. Votre objectif est une représentation exploitable :

• champs extraits,
• tables alignées,
• sections détectées,
• pages + positions,
• et liens vers la source brute.

Exemple : Textract documente comment extraire des tables et des cellules (headers, merged cells, etc.).³

Et si vous avez besoin de “preuves” (bounding boxes), des formats comme hOCR existent ; Tesseract explique qu’il peut produire un output XHTML conforme à la spec hOCR via une config dédiée.⁴

4) Décision : LLM + règles (pas LLM à la place des règles)

Une fois la structure extraite :

• le LLM interprète (classer, résumer, décider, rédiger),
• et vos règles vérifient (plafonds, cohérence, conformité).

Le LLM est excellent pour :

• comprendre une clause,
• reformuler proprement,
• repérer une anomalie (“ce champ est incohérent”).

Il est mauvais pour :

• garantir une règle business,
• appliquer des seuils sans erreur,
• être idempotent sur une action.

5) Citations : pointer et prouver (sinon vous ne déployez pas)

L’agent doit rendre :

• la réponse,
• plus les citations (source, page, extrait),
• plus un “explain plan” (ce qu’il a fait),
• plus des traces (tool calls, erreurs, retries).

Sans citations, vous avez un agent “marketing”. Avec citations, vous avez un agent “production”.

OCR vs VLM vs hybride : le cas du PDF de 120 pages

On me demande souvent :

“Pourquoi pas un VLM direct ?”

Parce que la prod aime les choses vérifiables.

Option A — VLM direct

Avantages :

• simplicité conceptuelle,
• compréhension visuelle de la mise en page,
• parfois très bon sur des documents courts.

Limites typiques :

• coûts/latence sur des gros documents,
• difficulté à citer précisément,
• et gestion multi-pages qui peut devenir un sport.

Option B — OCR dédié + LLM (le pattern le plus robuste)

Avantages :

• texte indexable (RAG),
• citations page/section,
• versioning,
• retries plus propres.

Exemples OCR cloud :

• Google Document AI propose un “Enterprise Document OCR”.⁵
• Amazon Textract extrait texte + tables (et plus).³

Exemples OCR “LLM-ish” :

• Mistral documente OCR 3 comme un modèle OCR (ex. mistral-ocr-2512) intégré à son stack Document AI.⁶⁷

Exemples open source :

• Tesseract (Apache 2.0) est un moteur OCR open source.⁸

Option C — Hybride (souvent le meilleur compromis)

Pattern recommandé :

1. OCR/parsing pour extraire et indexer (RAG, citations),
2. VLM (ou modèle multimodal) uniquement quand la mise en page porte le sens (tableaux tordus, scans),
3. LLM pour interpréter et écrire la décision.

Parsing & structure : Unstructured (et pourquoi “juste du texte” ne suffit pas)

Le problème des documents, ce n’est pas l’absence de texte. C’est la structure.

Unstructured présente des capacités de partitioning pour transformer des fichiers “complexes” en éléments structurés.²

Ce que vous gagnez :

• séparer titres vs paragraphes vs listes,
• isoler tableaux,
• détecter sections,
• et produire un JSON exploitable.

Pourquoi c’est clé ?

Parce qu’un agent qui doit répondre à :

“Quel est le plafond d’indemnisation et où est-il mentionné ?”

… doit retrouver la bonne section, pas juste “une phrase au hasard”.

Tables : l’endroit où les agents perdent leur dignité

Les tableaux sont le cimetière des pipelines “vite faits”.

Textract documente explicitement l’extraction de tables et de cellules, avec des attributs comme headers, merged cells, etc.³

Et côté Mistral, le changelog mentionne des options de formatage de tables dans l’OCR API (choisir markdown ou HTML via un paramètre).⁹

Traduction : la table est un objet. Traitez-la comme un objet.

Sinon, vous aurez :

• des colonnes qui glissent,
• des montants associés aux mauvaises lignes,
• et des décisions absurdes… parfaitement cohérentes avec une mauvaise extraction.

Extraction structurée : JSON schema, validations, et “ne pas inventer”

Une règle d’or :

Un agent documents doit sortir du structuré avant de sortir du texte.

Sinon, vous ne savez pas ce qu’il “a compris”.

Pattern robuste :

1. extraction champs → JSON (avec schema strict),
2. validation (types, champs obligatoires),
3. puis rédaction (texte, mail, rapport) à partir du JSON validé.

Ça réduit :

• les hallucinations,
• les champs “oubliés”,
• et les surprises en prod.

Citations & audit : comment rendre un agent acceptable pour un assureur

Dans l’assurance, le document n’est pas juste un input. C’est une pièce de conformité.

Donc votre agent doit pouvoir :

• citer la page,
• citer l’extrait,
• et expliquer la règle appliquée.

On peut implémenter ça simplement :

• chaque chunk porte : doc_id, page, section, bbox (si dispo),
• chaque extraction garde un lien : field -> chunk_id,
• chaque décision garde : decision -> fields -> chunks.

Résultat : quand on vous demande “pourquoi ce montant ?”, vous pointez.

Sans ça, vous ne déploierez pas au-delà du POC.

Open source vs cloud : une stratégie “mix” est souvent la meilleure

Open source

• Unstructured (open source) pour transformer documents en éléments structurés.¹²
• Tesseract pour OCR (self-host).⁸

Avantages : contrôle, on-prem, coût marginal.

Limites : qualité OCR variable, tuning, maintenance.

Cloud / commercial

• Google Document AI (Enterprise Document OCR).⁵
• AWS Textract (tables/forms).³
• Mistral OCR 3 + Document AI stack (modèle mistral-ocr-2512).⁶⁷

Avantages : time-to-market, qualité, features (tables, pipelines).

Limites : gouvernance fournisseur, coûts, dépendance.

Chunking & retrieval : “RAG” pour documents, mais version adulte

Beaucoup d’équipes font du RAG “classique” sur des documents :

• OCR → gros texte,
• chunking arbitraire (500 tokens),
• embeddings,
• retrieval,
• réponse.

Ça marche… jusqu’au moment où :

• vous devez citer une page,
• vous devez retrouver une clause exacte,
• ou vous devez extraire une valeur d’un tableau.

Dans un agent documents, le chunking n’est pas une optimisation. C’est une partie du contrat.

Chunking par structure (pas par tokens)

La doc Unstructured insiste sur le partitioning en éléments (titres, paragraphes, tables).²

L’idée “prod” :

• un chunk = un élément logique,
• chaque chunk porte la provenance (doc_id, page, section),
• et on garde le lien vers le brut.

Vous obtenez :

• retrieval plus propre (moins de bruit),
• citations “naturelles” (page/section),
• et moins de réponses “à côté”.

Hybrid search : quand les nombres et les codes comptent

Les documents métiers contiennent :

• des codes (références, numéros de contrat),
• des montants,
• des dates,
• des sigles.

Ces tokens sont parfois mieux servis par du keyword search que par des embeddings.

Donc, en pratique, vous combinez :

• vector search (sémantique),
• • keyword/BM25 (exact).

Et vous “rerank” ensuite pour choisir les meilleurs extraits.

Le but n’est pas d’être élégant. Le but est d’être juste.

Citations : la règle “pas de chunk, pas de claim”

La règle que j’aime bien imposer :

• si l’agent affirme un chiffre, il doit pointer un chunk,
• si l’agent applique une clause, il doit pointer un chunk,
• si l’agent n’a pas de chunk… il demande.

Ça réduit drastiquement les hallucinations, parce que vous transformez l’agent en système “citation-first”.

Erreurs fréquentes (et comment les diagnostiquer sans pleurer)

Un agent documents échoue souvent de façon très terre-à-terre :

1. OCR “0/O” ou “1/I”
   Ça paraît bête, mais un identifiant mal lu peut casser une intégration entière.

2. Séparateurs décimaux
   1,234 vs 1.234 : si votre pipeline ne normalise pas, vous fabriquez des anomalies.

3. Tables qui glissent
   Un montant associé à la mauvaise ligne. Textract documente des structures de tables ; utilisez-les, et testez sur vos tables réelles.³

4. Pages scannées “invisibles”
   Un PDF mixte (texte + scan) : certaines pages nécessitent OCR, d’autres non.

5. Documents non fiables (prompt injection)
   Un PDF peut contenir des instructions malveillantes (“ignore les règles”). La mitigation est la même que pour le RAG : isoler les données non fiables, filtrer, et garder les instructions système immuables.

Le point commun : sans traçabilité (quel OCR ? quel chunk ? quelle page ?), vous ne débuggez pas. Vous devinez.

Checklist “prod” : de 0 à agent documents en 10 jours

1

Collectez 100 documents réels (et moches)

Mélangez scans, photos, PDFs, tableaux. Si vous ne testez que du “propre”, vous testez un mensonge.

2

Choisissez une stratégie OCR (A/B/C)

VLM direct, OCR+LLM, ou hybride. Calibrez sur coût/latence/audit, pas sur “la meilleure réponse”.

3

Structurez avant de rédiger

Champs + tables + sections en JSON, validés. Le texte vient après.

4

Ajoutez citations et traçabilité

field -> chunk_id -> page. Sans ça, pas de confiance métier.

5

Mesurez et rejouez

Tracez, rejouez, comparez à l’humain. Sans replay, vous ne saurez pas pourquoi “ça rate une fois sur dix”.

FAQ

Questions frequentes

VLM direct : jamais ?+

Pas “jamais”. Sur des documents courts, très visuels (captures, formulaires), ça peut être excellent. Mais sur des documents longs et paginés, OCR+LLM est souvent plus gouvernable (citations, chunking, audit).

Unstructured suffit pour tout ?+

Non. Unstructured aide à structurer, mais la qualité dépend du type de documents, des tables, et de votre stratégie OCR. En prod, vous combinez souvent plusieurs briques.

Pourquoi les tables sont si difficiles ?+

Parce qu’une table est un objet spatial (lignes/colonnes), pas une suite de mots. Utilisez des outils qui extraient explicitement la structure (ex. Textract tables) et testez sur vos documents.³

Comment éviter que l’agent invente ?+

Extraction structurée (JSON strict) + validations + citations obligatoires sur les champs critiques. Et gardez la règle métier hors du LLM.

Quelle brique OCR en 2026 ?+

Ça dépend de vos contraintes. Google Document AI, AWS Textract, Mistral OCR 3 (mistral-ocr-2512) et Tesseract sont des options documentées. Choisissez sur vos documents, pas sur un benchmark générique.⁵³⁶⁸

Sources et references

1. [1]GitHub, Unstructured-IO/unstructured (open source ETL for documents).
2. [2]Unstructured docs, “Partitioning” (structured elements extraction).
3. [3]AWS Textract docs, “Tables” (cells/headers/merged cells).
4. [4]Tesseract Wiki FAQ, “hOCR output” (XHTML/hOCR).
5. [5]Google Cloud Document AI, “Enterprise Document OCR”.
6. [6]Mistral Docs, “OCR 3” (mistral-ocr-2512).
7. [7]Mistral AI, “Introducing Mistral OCR 3”.
8. [8]GitHub, tesseract-ocr/tesseract (open source OCR engine).
9. [9]Mistral Docs, changelog (table formatting option in OCR API).