Apogée Consult
Retour au blog
Jules Ginhac
Jules GinhacCo-Founder & ingénieur IA

Je suis Jules Ginhac, Co-Founder & ingénieur IA chez Apogée Consult à Lyon. Je conçois et déploie des architectures IA génératives (RAG, agents, LLMOps) pour des PME, startups et organisations publiques.

Claude 4.7 vs GPT-5 sur extraction structurée à fort volume : notre bench sur 5000 documents

  • llm-comparison

Nous avons benchmarké Claude 4.7 et GPT-5 sur 5000 documents réels pour de l'extraction JSON. Les résultats contredisent plusieurs idées reçues.

Claude 4.7 vs GPT-5 sur extraction structurée à fort volume : notre bench sur 5000 documents

Choisir un fournisseur LLM pour de l'extraction structurée à volume est une décision qui engage l'infrastructure, les coûts et la qualité des données produites pour des mois. Nous avons fait ce bench sur un cas réel pour ne pas répondre à cette question avec des benchmarks académiques.

Contexte du benchmark

Le corpus : 5 000 documents contractuels en français (baux commerciaux, CGV, contrats de prestation), entre 800 et 12 000 tokens par document. L'objectif : extraire un objet JSON structuré de 18 champs, montants, dates, parties, clauses critiques, durées.

Évaluation : comparaison ligne à ligne sur un ground truth construit manuellement sur 200 documents, extrapolé par règles sur le reste. Le critère principal est l'exact match sur les champs structurés (montants, dates) et une évaluation sémantique binaire sur les champs textuels.

Les deux modèles ont été testés avec leur mode natif de structured output (Anthropic avec tool use + JSON schema enforced, OpenAI avec response_format: json_schema).

Résultats bruts

Sur les 200 documents du ground truth :

CritèreClaude 4.7GPT-5
Exact match champs numériques94.1%91.8%
Exact match champs dates96.3%94.5%
Champs textuels (éval binaire)88.4%89.1%
Format JSON valide (sur 5000)99.97%99.94%
Latence médiane (p50)3.8s4.2s
Latence p959.1s11.6s
Coût pour 5000 docs~$210~$310

Ce que les chiffres cachent

Sur les champs numériques

Claude 4.7 surperforme sur les montants avec formatage ambigu, par exemple "deux mille cinq cents euros HT" dans une phrase, ou des tableaux récapitulatifs avec des totaux partiels. GPT-5 a tendance à retourner la valeur la plus récente mentionnée dans le document, Claude à identifier la valeur contractuellement engageante.

Ce comportement est difficile à mesurer en exact match mais visible en audit manuel.

Sur les champs textuels

L'avantage de GPT-5 sur les champs textuels libres (résumé de clause, description de prestation) tient à des réponses plus longues et plus fluides. Selon l'usage, c'est une qualité ou un défaut, une extraction vers une base de données préfère des valeurs courtes et normalisées.

Sur la stabilité du format

Les deux modèles sont très stables sur le format JSON en mode structured output. L'écart de 0.03 points sur la validité JSON (sur 5000 documents) représente 1 à 2 échecs. Dans les deux cas, le retry sur erreur de format suffit.

Sur la latence

L'écart p95 est significatif : 9.1s vs 11.6s. Sur un pipeline synchrone avec des utilisateurs qui attendent, ça compte. Sur un batch overnight, ça ne change rien.

Ce que nous avons retenu pour notre recommandation

Pour de l'extraction de données contractuelles en français avec des champs structurés forts (montants, dates, identifiants), Claude 4.7 offre une meilleure précision sur les champs critiques et un coût inférieur d'environ 32% à volume équivalent.

GPT-5 garde un avantage sur les champs textuels ouverts et les instructions très complexes avec nombreuses conditions imbriquées, nous l'avons observé sur quelques contrats atypiques à structure narrative.

# Exemple de schéma d'extraction avec tool use Anthropic
tools = [{
    "name": "extract_contract",
    "description": "Extraire les données structurées d'un contrat commercial",
    "input_schema": {
        "type": "object",
        "properties": {
            "montant_ht": {"type": "number", "description": "Montant HT en euros"},
            "date_debut": {"type": "string", "format": "date"},
            "date_fin": {"type": "string", "format": "date"},
            "parties": {
                "type": "array",
                "items": {"type": "string"},
                "maxItems": 4
            },
            # ... 14 autres champs
        },
        "required": ["montant_ht", "date_debut", "parties"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-7",  # ou opus selon budget/précision
    max_tokens=1024,
    tools=tools,
    tool_choice={"type": "auto"},
    messages=[{"role": "user", "content": f"Extraire les données de ce contrat :\n\n{document}"}]
)

Ce que ce bench ne couvre pas

Nous n'avons pas testé le comportement sur les documents multilingues (contrats franco-anglais), les documents avec OCR bruité, ni les cas où le modèle doit inférer un champ absent plutôt que retourner null. Ces trois scenarios peuvent inverser le classement selon le corpus.

La question qui reste ouverte : comment se comporte chaque modèle quand le schema d'extraction évolue en production sans reprocessing des anciens documents ? La gestion des champs optionnels et la tolérance à la dérive de schéma méritent un bench dédié.

Disponible pour de nouveaux projets

Un projet à concrétiser ?
Parlons-en, sans engagement.

Un échange de 30 minutes pour cadrer votre besoin, qualifier la faisabilité et vous proposer une trajectoire claire.

1// kick-off : réponse sous 24h
2const project = await apogee.scope({
3 type: 'web | mobile | IA',
4 timeline: '6 à 16 semaines',
5 approach: 'sur-mesure'
6})
7// → cadrage offert
Claude vs GPT extraction structurée benchmark | Apogée Consult