Extraction de données par IA — sorties structurées à partir de PDF, factures et textes non structurés

Le cas d’usage peu glamour mais précieux

Pendant deux décennies, extraire des données structurées de documents non structurés était un projet d’un trimestre : pipeline OCR, règles regex, gestion des cas limites et modèles de mise en page propres à chaque fournisseur. Avec un LLM contraint par un schéma JSON, cela tient en 30 lignes de code, est précis dès le premier passage et peut être mis en production en une journée. Les exemples ci-dessous s’exécutent sur Kunavo, une passerelle indépendante compatible avec OpenAI ; le principe appartient aux modèles et fonctionne de la même façon avec chacun d’eux.

Vous extrayez spécifiquement des factures ? Cette page offre une vue d’ensemble interdocuments. Le guide dédié à l’extraction des données de factures approfondit ce type de document : comparaison des anciennes approches fondées sur des modèles et des templates avec un appel à un LLM de vision, tutoriel Python complet avec contrainte de schéma, garde-fou arithmétique, routage à deux niveaux et coût par facture.

Catégories pour lesquelles cette approche fonctionne particulièrement bien :

• Factures, reçus, bons de commande
• Contrats, accords juridiques (extraire les parties, les dates et les obligations)
• CV / curriculum vitæ (conversion en structure compatible ATS)
• Enrichissement de prospects à partir de signatures d’e-mails ou de pages web
• Dossiers médicaux, comptes rendus de laboratoire (avec traitement des données personnelles)
• Annonces immobilières, catalogues de produits
• Tri d’e-mails et ingestion structurée

Le principe central en 30 lignes

import json
from openai import OpenAI
client = OpenAI(api_key="sk-kn-...", base_url="https://api.kunavo.com/v1")

# The schema is the output contract. Claude enforces a json_schema
# response_format (json_object it does not), so the reply has this shape
# unless max_tokens cuts it off (finish_reason == "length").
STR = {"type": ["string", "null"]}
NUM = {"type": ["number", "null"]}
INVOICE = {
    "type": "object",
    "properties": {
        "vendor": {"type": "string"},
        "invoice_number": STR, "date_iso": STR, "due_date_iso": STR,
        "currency": STR, "subtotal": NUM, "tax": NUM, "total": NUM,
        "line_items": {"type": "array", "items": {
            "type": "object",
            "properties": {"description": {"type": "string"},
                           "qty": NUM, "unit_price": NUM, "amount": NUM},
            "required": ["description", "qty", "unit_price", "amount"],
            "additionalProperties": False,
        }},
    },
    "required": ["vendor", "invoice_number", "date_iso", "due_date_iso",
                 "currency", "subtotal", "tax", "total", "line_items"],
    "additionalProperties": False,
}
RESPONSE_FORMAT = {"type": "json_schema",
                   "json_schema": {"name": "invoice", "schema": INVOICE}}
RULES = "Extract the invoice. Use null for missing fields. Dates in ISO 8601."

# Extract structured fields from an invoice PDF (after OCR)
def extract_invoice(ocr_text: str) -> dict:
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",
        messages=[
            {"role": "system", "content": RULES},
            {"role": "user", "content": ocr_text},
        ],
        response_format=RESPONSE_FORMAT,
        max_tokens=1200,
    )
    return json.loads(resp.choices[0].message.content)

# Extract from an image directly (no OCR step needed)
def extract_invoice_from_image(image_url: str) -> dict:
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",   # vision + an enforced schema
        messages=[
            {"role": "system", "content": RULES},
            {"role": "user", "content": [
                {"type": "text", "text": "Extract this invoice:"},
                {"type": "image_url", "image_url": {"url": image_url}},
            ]},
        ],
        response_format=RESPONSE_FORMAT,
        max_tokens=1200,
    )
    return json.loads(resp.choices[0].message.content)

Deux flux : texte uniquement (après une étape OCR séparée) et vision directe (un modèle de vision lit l’image et produit du JSON en un seul appel). Le flux vision est plus rapide à développer, mais légèrement plus coûteux par appel ; le flux OCR puis LLM est moins cher à grande échelle, car l’OCR est un coût unique par page.

Benchmarks de précision

Sur un jeu de données public de factures (1 000 factures provenant de 50 fournisseurs), avec le mode JSON et un prompt système de 200 mots :

• Claude Haiku 4.5 : précision de 96 % au niveau des champs
• Claude Sonnet 4.6 : précision de 98 % au niveau des champs
• Templates traditionnels : 80 à 90 % pour les fournisseurs connus, 0 % pour les nouveaux

Le LLM gère sans exemple préalable les nouvelles mises en page de fournisseurs. Ajoutez 2 ou 3 paires d’exemples dans le prompt système (few-shot) et Haiku s’approche de la précision de Sonnet pour une fraction du coût.

Coût par document

• Facture (environ 2 000 tokens d’entrée, environ 500 en sortie) : Haiku environ 0,003 $, Sonnet environ 0,02 $
• Contrat d’une page (environ 5 000 tokens d’entrée) : Haiku environ 0,005 $, Sonnet environ 0,04 $
• Contrat de 10 pages (environ 50 000 tokens d’entrée, résumé structuré en sortie) : Sonnet environ 0,30 $
• CV (environ 3 000 tokens d’entrée) : Haiku environ 0,003 $
• Image de reçu avec vision : Haiku, environ le coût d’une facture — l’image compte pour environ 1 500 tokens d’entrée

Traitement de 10 000 factures par mois : environ 30 $ avec Haiku. L’alternative commerciale la plus proche (Rossum, AWS Textract + post-traitement) coûte environ 2 000 à 5 000 $ par mois pour le même volume.

Les 5 principes qui maintiennent une grande précision

• Gestion explicite des valeurs nulles : demandez au modèle d’utiliser null pour les champs manquants, et non « N/A » ou des chaînes vides. Le code en aval peut distinguer « absent » de « volontairement vide ».
• Dates ISO 8601 : indiquez-le explicitement. Sinon, le modèle choisit des formats régionaux et l’analyse en aval échoue.
• Devise sous forme de code ISO : « USD », pas « $ » ; « EUR », pas « € ». Évitez l’ambiguïté (« $ » peut désigner USD, CAD ou AUD).
• Validez le JSON : utilisez Pydantic / Zod pour imposer votre schéma. S’il est invalide, renvoyez un prompt avec l’erreur.
• Vérifiez manuellement 1 % pendant une semaine, puis 0,1 % en continu. Suivez la précision au niveau des champs, pas seulement au niveau des enregistrements.

Quel modèle utiliser dans quel cas

Considérations de conformité

Pour les documents contenant des données personnelles (les factures contiennent des noms et des adresses ; les dossiers médicaux contiennent de tout), pseudonymisez les données avant l’extraction ou utilisez la conservation zéro des données en amont. Consultez le guide de conformité pour les pratiques propres à chaque région et l’analyse approfondie du RGPD pour le guide allemand.

Commencez ici : /app/signup — un paiement à l’usage à partir d’un rechargement de 10 $ couvre environ 3 000 extractions de factures, et votre solde n’expire jamais. Consultez la documentation de chat à /docs/chat pour savoir ce que response_format impose à chaque famille de modèles et découvrir les pratiques d’utilisation des outils.

FAQ