Parser les documents : texte, tableaux, OCR

Le router : une décision, un seul endroit

Premier node du pipeline, le router choisit la route d'extraction — et c'est le SEUL endroit du code qui connaisse cette logique :

source visuelle (PDF, image) + clé Mistral configurée  → route VISION (OCR)
PDF sans clé Mistral                                    → route TEXTE (pdfplumber)
image sans clé Mistral                                  → ERREUR (fail loud, pas de page vide)
txt / csv / xlsx / eml / json                           → route TEXTE toujours

Le principe cardinal : deux routes, un contrat. Texte ou vision, la sortie est le même StructuredOrder (le schéma partagé validé Pydantic) — tout l'aval (validator, matchers) ignore la provenance du document.

La route texte : aplatir proprement

• PDF (pdfplumber) : par page, extract_text() + extract_tables() — les tableaux sont rendus en lignes cellule | cellule | cellule injectées dans le texte (le LLM lit très bien ce format) ET conservés en structuré. Le tout en asyncio.to_thread (pdfplumber est sync et CPU-bound — module 1 !). Un PDF scanné ressort vide de pdfplumber : c'est le signal qu'il fallait la route vision ;
• Excel/CSV (pandas) : lecture par feuille, dropna(how="all"), bornée à 1000 lignes ; pour les CSV, une cascade d'essais encodage/séparateur (utf-8 avec ,/;/tab, puis latin-1, puis le sniffing automatique) — les CSV du monde réel sont un zoo, on tente du plus probable au plus permissif.

La route vision : le document natif au modèle

Pour les scans et images, le pipeline n'aplatit rien : le PDF/image part en base64 à mistral-ocr-latest avec le schéma d'annotation dérivé du même StructuredOrder et le même prompt système — document en entrée, JSON structuré en sortie, en un seul appel. Le context_text de l'email accompagne le document ici aussi.

Ce choix (OCR structurant plutôt qu'OCR texte puis LLM) supprime une étape entière de perte : les positions de tableaux, les colonnes alignées visuellement — tout ce que l'aplatissement texte détruit — restent exploitables par le modèle de vision.

Les limites d'entrée : connaître ses plafonds

Tout pipeline d'extraction a des plafonds, et les connaître évite les mystères de prod :

• 1000 lignes lues maximum sur la route texte (la borne pandas) ;
• ~200 lignes structurées en pratique : le budget de sortie LLM (16k tokens) est le vrai plafond — et au-delà, le document est rejeté entièrement (fail loud), pas tronqué en silence : un résultat partiel non signalé serait pire qu'une erreur ;
• la route vision (OCR) va plus loin — encore un argument pour elle sur les gros bons scannés.

La solution structurelle en chantier : le chunking avec contexte — découper les grosses commandes en lots, en ré-envoyant à chaque lot le contexte nécessaire (en-têtes de tableaux, consignes). Et la sagesse d'expérience qui guide son design, héritée d'un produit précédent de l'équipe : la qualité d'extraction se dégrade bien avant la limite technique (~100 lignes, le modèle « s'emmêle ») — les chunks efficaces y étaient de ~40 lignes. Leçon générale : le plafond de qualité d'un LLM arrive avant son plafond de tokens — dimensionne tes lots sur le premier, pas le second.