Document AI 2026 : les VLM remplacent l'OCR classique

Chaque entreprise connaît ce goulot d'étranglement : des factures fournisseurs qui s'empilent, des contrats à archiver, des formulaires manuscrits à saisir, des PDF scannés impossibles à exploiter. Pendant des années, la promesse de l'OCR (reconnaissance optique de caractères) a été de régler ce problème. Et pendant des années, elle a déçu. Dès qu'un document sortait du gabarit attendu, la chaîne de traitement se brisait et un humain devait reprendre la saisie à la main.

En 2026, la donne a changé. Les modèles vision-langage (VLM) ne se contentent plus de transcrire des caractères : ils comprennent un document comme le ferait une personne. Et surtout, ils livrent ce dont les systèmes modernes ont réellement besoin : des données structurées, prêtes à être consommées par un LLM ou une automatisation.

Pourquoi l'OCR traditionnel a atteint ses limites

L'OCR classique repose sur une logique fragile. Un moteur comme Tesseract extrait des caractères, puis une couche de règles (expressions régulières, gabarits, positions fixes) tente de deviner où se trouve le numéro de facture ou le montant total. Cette approche fonctionne tant que le document ressemble exactement à ce qui était prévu.

Le problème, c'est que les documents réels ne coopèrent jamais. Les chaînes OCR traditionnelles s'effondrent dès qu'elles rencontrent :

• des mises en page multi-colonnes que le moteur lit dans le mauvais ordre ;
• des tableaux à cellules fusionnées qui désalignent toutes les valeurs ;
• de l'écriture manuscrite, que les règles de gabarit ignorent ;
• des documents multilingues mélangeant plusieurs écritures ;
• des formats non standard, propres à chaque fournisseur.

Chaque nouveau format exige un nouveau gabarit, une nouvelle règle, une nouvelle exception. Le coût de maintenance explose, et la précision reste capricieuse. L'OCR voyait des pixels et des lettres, jamais le sens.

Comment les modèles vision-langage ont changé la donne

Un VLM aborde le document autrement. Il combine la disposition visuelle et le contexte sémantique, exactement comme un lecteur humain. Là où l'OCR voit une suite de glyphes, le VLM comprend une structure.

Prenons un exemple concret : un nombre situé en bas à droite d'un tableau. Un VLM sait qu'il s'agit du total, non pas grâce à une règle codée en dur, mais parce qu'il interprète sa position, son formatage (gras, devise) et la proximité du mot « TOTAL ». Cette compréhension conjointe du pixel et du sens est ce qui rend ces modèles robustes face aux mises en page imprévues.

Concrètement, cela signifie qu'un seul modèle gère des factures de dizaines de fournisseurs différents sans gabarit dédié, lit correctement un tableau à cellules fusionnées, et déchiffre une note manuscrite. Le passage de règles rigides à une compréhension contextuelle est la rupture fondamentale de 2026.

Le paysage open-source du Document AI en 2026

L'écosystème open-source est devenu remarquablement mature, et plusieurs modèles spécialisés se distinguent. La qualité se mesure désormais sur olmOCR-bench, le benchmark de référence pour l'OCR et les VLM documentaires.

olmOCR-2-7B-1025 (Allen AI) est un VLM dédié à l'OCR, affiné à partir de Qwen2.5-VL-7B-Instruct sur le jeu de données olmOCR-mix-1025, puis renforcé par apprentissage par renforcement GRPO. Le toolkit olmOCR « linéarise » les PDF en texte brut propre. La version originale d'olmOCR avait été entraînée sur 260 000 pages issues de plus de 100 000 PDF collectés sur le web.

Surya 2 (datalab) est un modèle vision-langage compact d'environ 650M de paramètres, d'architecture inspirée de Qwen3, qui assure à lui seul l'analyse de mise en page, l'OCR (page entière ou par bloc) et la reconnaissance de tableaux dans plus de 90 langues. Il est Pareto-optimal sur le front taille-contre-score d'olmOCR-bench : le meilleur de sa catégorie sous la barre des 3B de paramètres.

Chandra 2 (datalab) est un modèle de 4B de paramètres qui atteint 85,9 % sur olmOCR-bench. Il prend en charge plus de 90 langues, produit du Markdown, du HTML ou du JSON structuré, et gère sans broncher les tableaux à cellules fusionnées, l'écriture manuscrite et les équations LaTeX.

Pour les besoins de compréhension documentaire les plus exigeants, on s'appuie aussi sur de grands VLM généralistes comme Qwen2.5-VL-72B-Instruct, DeepSeek-VL2 ou GLM-4.5V. Ces modèles offrent un raisonnement plus profond au prix d'une infrastructure plus lourde.

Du texte aux données structurées

Le véritable changement de 2026 n'est pas la précision de l'OCR : c'est la nature du livrable. Hier, on extrayait du texte. Aujourd'hui, on extrait des données prêtes pour l'IA — du JSON structuré, du Markdown propre, des insights sémantiques que l'on peut directement injecter dans un LLM ou un workflow d'automatisation.

Au lieu de demander « transcris cette page », on demande au modèle de remplir un schéma. Le VLM lit l'image de la facture et renvoie un objet conforme à la structure attendue :

import json
from transformers import AutoModelForImageTextToText, AutoProcessor
from PIL import Image
 
model_id = "datalab-to/chandra-2"
processor = AutoProcessor.from_pretrained(model_id)
model = AutoModelForImageTextToText.from_pretrained(
    model_id, device_map="auto", torch_dtype="auto"
)
 
invoice = Image.open("facture_fournisseur.png")
 
prompt = """Tu es un extracteur de factures. Lis l'image et renvoie UNIQUEMENT
un objet JSON valide avec ce schéma exact (aucun texte autour) :
{
  "invoice_number": string,
  "date": "YYYY-MM-DD",
  "vendor": string,
  "currency": string,
  "total": number,
  "line_items": [
    { "description": string, "quantity": number, "unit_price": number, "amount": number }
  ]
}"""
 
messages = [{
    "role": "user",
    "content": [
        {"type": "image", "image": invoice},
        {"type": "text", "text": prompt},
    ],
}]
 
inputs = processor.apply_chat_template(
    messages, add_generation_prompt=True,
    tokenize=True, return_dict=True, return_tensors="pt",
).to(model.device)
 
output_ids = model.generate(**inputs, max_new_tokens=1024)
raw = processor.batch_decode(output_ids, skip_special_tokens=True)[0]
 
data = json.loads(raw[raw.find("{"): raw.rfind("}") + 1])
print(data["invoice_number"], data["total"], data["currency"])

La sortie n'est plus un mur de texte à reparser, mais un objet directement exploitable par le reste du système.

Construire un pipeline de Document AI

Un pipeline robuste en production ne se résume pas à un appel de modèle. Voici les étapes pratiques :

1. Ingestion et normalisation. Convertir chaque document (PDF, scan, photo) en images de page propres, redressées et à résolution suffisante.
2. Analyse de mise en page. Détecter blocs de texte, tableaux, figures et ordre de lecture. C'est ici que Docling, associé à Surya, excelle : il reconstruit les tableaux imbriqués, les en-têtes hiérarchiques, les formules mathématiques et rétablit l'ordre de lecture correct.
3. Extraction structurée. Appeler le VLM avec un schéma cible et valider la sortie.
4. Validation et garde-fous. Vérifier les types, recalculer les totaux, signaler les champs à faible confiance pour relecture humaine.

L'étape de validation est essentielle : un schéma typé transforme une sortie probabiliste en donnée fiable.

from pydantic import BaseModel, field_validator
from typing import List
 
class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    amount: float
 
class Invoice(BaseModel):
    invoice_number: str
    date: str
    vendor: str
    currency: str
    total: float
    line_items: List[LineItem]
 
    @field_validator("total")
    @classmethod
    def total_matches_lines(cls, value, info):
        items = info.data.get("line_items", [])
        computed = round(sum(i.amount for i in items), 2)
        if items and abs(computed - value) > 0.01:
            raise ValueError(
                f"Total {value} incoherent avec la somme des lignes {computed}"
            )
        return value
 
def parse_invoice(raw_json: str) -> Invoice:
    # raw_json provient de la sortie du VLM (voir bloc precedent)
    invoice = Invoice.model_validate_json(raw_json)
    return invoice

Avec Pydantic, un document mal extrait échoue bruyamment au lieu de polluer silencieusement la base de données.

Le tournant agentique : raisonnement multi-documents

En 2026, selon le cadrage de Forrester et des analystes du secteur, la différenciation s'est déplacée « vers le haut de la pile ». Extraire les champs d'une facture est devenu une commodité. La valeur réside désormais dans l'orchestration agentique, le raisonnement multi-documents et l'automatisation de bout en bout.

Concrètement, un agent ne se contente pas de lire une facture : il la rapproche du bon de commande et du bon de livraison correspondants, détecte les écarts de prix, signale les anomalies et déclenche une action (validation, relance fournisseur, paiement). Les plateformes IDP d'entreprise comme Hyperscience ou UiPath traitent ainsi des documents structurés, semi-structurés et non structurés via une architecture composable et une gouvernance ModelOps. Le VLM n'est qu'un composant ; l'intelligence vit dans le workflow qui l'entoure.

Ce que cela change pour les entreprises de la région MENA

L'OCR arabe a longtemps été un cas particulièrement difficile : écriture de droite à gauche, ligatures cursives, diacritiques qui modifient le sens. Les moteurs traditionnels y échouaient régulièrement. Les VLM multilingues modernes, entraînés sur plus de 90 langues, gèrent enfin l'arabe avec une qualité exploitable en production.

Cette avancée tombe à point nommé, car la région impose désormais des données de facturation structurées. En Tunisie, le dispositif TTN El Fatoora encadre la facture électronique ; en Arabie Saoudite, le mandat ZATCA Fatoorah exige des factures conformes à un format structuré. Or de nombreux fournisseurs envoient encore des PDF ou des scans hétérogènes, souvent bilingues arabe-français ou arabe-anglais.

Un pipeline VLM transforme ces documents bruts en champs structurés exactement comme l'exigent ces réglementations : numéro de facture, date, identifiant fiscal, montants HT et TTC, TVA, devise, lignes de détail. Ce qui demandait une saisie manuelle fastidieuse devient une étape automatisée, conforme et auditable.

Construire ou acheter

Faut-il assembler son propre pipeline open-source ou adopter une plateforme IDP commerciale ? La réponse dépend du volume, de la sensibilité des données et des compétences internes.

Construire avec Surya 2, Chandra 2 ou olmOCR-2 et Docling offre un contrôle total, des coûts d'inférence maîtrisés et la souveraineté des données — un argument décisif lorsque les documents sont confidentiels ou doivent rester sur site. C'est la voie idéale pour des volumes prévisibles et une équipe technique solide.

Acheter une plateforme comme Hyperscience ou UiPath fait sens lorsqu'il faut une gouvernance ModelOps prête à l'emploi, une supervision humaine intégrée et un support contractuel, au prix d'un coût récurrent et d'une dépendance fournisseur. Beaucoup d'organisations adoptent une voie hybride : un socle open-source pour l'extraction, enrichi d'une orchestration sur mesure.

Conclusion

L'OCR traditionnel transcrivait des caractères ; les modèles vision-langage comprennent des documents et livrent des données prêtes pour l'IA. En 2026, cette transition n'est plus expérimentale : des modèles open-source compacts gèrent plus de 90 langues, l'arabe inclus, et s'intègrent directement aux workflows agentiques et aux mandats d'e-facturation TTN et ZATCA.

Si vous souhaitez concevoir un pipeline de Document AI adapté à vos factures, contrats et formulaires — qu'il soit open-source, souverain ou hybride — l'équipe de noqta.tn peut vous accompagner de la preuve de concept à la production.