Vision LLMs sur factures et bons de commande : notre bench interne sur 200 documents

L'OCR traditionnel est mort, dit-on. La réalité est plus nuancée : les LLMs vision sont très bons sur certains formats, médiocres sur d'autres, et leur coût reste un ordre de grandeur au-dessus d'un OCR classique. Avant de migrer un pipeline RPA vers du LLM vision, nous avons voulu mesurer ce que ça donne vraiment.

Le corpus de test

200 documents réels fournis par un client du secteur distribution. Anonymisés, répartis comme suit :

• 110 factures fournisseurs (formats variés : A4 portrait standard, factures scannées avec inclinaison, factures multi-pages avec récapitulatif)
• 90 bons de commande (formats internes structurés et formats PDF exportés depuis 3 ERP différents)

Chaque document a été annoté manuellement avec les champs cibles : numéro de document, date, fournisseur/émetteur, montant HT, TVA, montant TTC, lignes de détail (désignation, quantité, prix unitaire, total ligne).

Les documents scannés représentent 34 % du corpus. Le reste est natif PDF.

Protocole

Tous les documents PDF ont été convertis en image PNG 150 DPI avant envoi au modèle. Nous avons testé une résolution plus haute (300 DPI) et les résultats ne progressent pas de façon mesurable sur nos documents, pour un coût image multiplié par deux à quatre.

Prompt identique pour tous les modèles :

Extrais les champs suivants de ce document en JSON strict.
Si un champ est absent, utilise null.
Ne génère aucun texte en dehors du JSON.

{
  "numero_document": string | null,
  "date_document": string | null,  // format YYYY-MM-DD
  "emetteur": string | null,
  "montant_ht": number | null,
  "tva": number | null,
  "montant_ttc": number | null,
  "lignes": [
    {
      "designation": string,
      "quantite": number | null,
      "prix_unitaire": number | null,
      "total_ligne": number | null
    }
  ]
}

Métrique principale : exactitude par champ (valeur extraite = valeur annotée, avec tolérance de 0,01 € sur les montants numériques).

Résultats globaux

"Documents parfaits" signifie que tous les champs annotés correspondent exactement, y compris toutes les lignes de détail.

Claude 3.5 Sonnet prend la tête sur ce corpus, avec un avantage particulier sur les lignes de détail des documents scannés. L'écart avec GPT-4o reste serré sur les champs scalaires.

Où chaque modèle décroche

GPT-4o

L'erreur la plus fréquente : hallucination de lignes de détail quand un tableau est coupé entre deux pages. GPT-4o invente des lignes pour "compléter" le tableau visible sur la première page au lieu d'aller chercher la suite. Sur nos documents multi-pages, le taux d'erreur sur les lignes grimpe à 22 %.

Claude 3.5 Sonnet

Problème récurrent sur les montants avec espace insécable comme séparateur de milliers (format français 1 234,56 €). Claude retourne parfois 1234.56 et parfois 1.23456, selon la mise en forme du document. La normalisation doit être faite côté application.

Gemini 1.5 Pro

Gemini est le plus instable sur les documents avec inclinaison supérieure à 5°. Son taux de champ null sur les documents scannés de mauvaise qualité est deux fois plus élevé que GPT-4o et Claude. Pour un corpus de factures scannées mal cadrées, le classement s'inverserait probablement.

Les erreurs qui coûtent cher

Toutes les erreurs ne se valent pas. Un numéro de document mal extrait est corrigeable manuellement. Une ligne de détail inventée qui passe en comptabilité, c'est un autre problème.

Nous avons classé les erreurs en deux catégories :

Erreurs de précision : mauvaise valeur extraite pour un champ présent dans le document. Ces erreurs représentent 60 % des cas.

Erreurs d'hallucination : valeur retournée pour un champ absent, ou ligne de détail inventée. Ces erreurs représentent 40 % des cas et sont systématiquement plus dangereuses.

Sur les erreurs d'hallucination, Claude 3.5 Sonnet a le taux le plus bas : 4,1 % de champs hallucinés contre 6,8 % pour GPT-4o et 9,2 % pour Gemini.

Ce qu'on a retenu et pourquoi

Nous avons déployé Claude 3.5 Sonnet avec un post-traitement systématique :

1. Validation JSON schema avant toute écriture en base.
2. Vérification de cohérence arithmétique : somme des total_ligne doit correspondre au montant_ht à 0,02 € près. Si la vérification échoue, le document est mis en file de revue humaine.
3. Normalisation des montants français (suppression des espaces, remplacement de la virgule décimale).

import re
from decimal import Decimal, InvalidOperation

def normalize_french_amount(value: str) -> float | None:
    if not value:
        return None
    # Supprime les espaces insécables et normaux utilisés comme séparateurs de milliers
    cleaned = re.sub(r'[\s ]', '', str(value))
    # Remplace la virgule décimale par un point
    cleaned = cleaned.replace(',', '.').replace('€', '').strip()
    try:
        return float(Decimal(cleaned))
    except InvalidOperation:
        return None

Avec ce pipeline, le taux de documents passant en revue humaine est de 11 %. C'était 28 % avec l'OCR traditionnel sur le même corpus.

Coût réel vs OCR

Un OCR Tesseract avec post-traitement maison coûte environ 0,002 € par document (compute inclus). Claude 3.5 Sonnet coûte 0,024 € par document sur ce corpus. Soit un rapport de 12.

La justification économique repose sur deux éléments : la réduction du volume de revue humaine (de 28 % à 11 %) et l'élimination de la maintenance d'un moteur d'extraction par type de formulaire. Un OCR sur factures libres nécessite des règles ou un modèle fine-tuné par layout. Le LLM vision s'adapte sans intervention.

Le calcul devient favorable au LLM vision dès que le coût de la revue humaine ou de la maintenance des règles d'extraction dépasse la différence de coût de compute.

Ce que ce bench ne couvre pas

Notre corpus est majoritairement en français, sur des formats A4 standards. Nous n'avons pas testé :

• Les factures manuscrites ou partiellement manuscrites.
• Les formats exotiques (tickets de caisse, relevés bancaires).
• Les documents en deux colonnes ou avec filigranes denses.
• Les performances à très grande échelle (effets de rate limit, latence p99).

Sur les formats hors standard, l'avantage du LLM vision se réduit probablement, et les taux d'hallucination augmentent. La prochaine étape pour nous est de tester avec des documents enrichis de métadonnées de confiance, un score de qualité du scan passé en contexte au modèle.