Comparatif
LLM ou modèle spécialisé pour extraire des documents
Modèle prédéfini (Azure, Google) ou grand modèle de langage avec schéma imposé : forces, limites, coûts à calculer et règle de choix pour vos documents.
Mis à jour le
Un modèle spécialisé (par exemple le modèle facture d'Azure Document Intelligence) convient quand votre type de document est couvert et que vous voulez des champs prêts à l'emploi avec un score de confiance. Un grand modèle de langage (LLM) auquel on impose un schéma JSON convient quand les documents sont variés, rares ou en langue ou format non couverts. Le bon choix se tranche sur un échantillon de vos documents, pas sur des brochures. Mise à jour le 15/11/2026.
Ce que fait chaque famille
Modèle spécialisé. Il est entraîné pour un type de document et renvoie des champs nommés. Le modèle prebuilt-invoice d'Azure analyse factures, factures de services, bons de commande et commandes clients, dans 27 langues d'après Microsoft. Google propose un Invoice Parser en disponibilité générale (12 langues dont le français) et un Custom Extractor pour les autres documents.
LLM avec schéma imposé. Vous envoyez le document et un schéma ; le modèle répond en JSON. Chez Anthropic, les sorties structurées s'appuient sur un décodage contraint : le JSON est toujours valide, les types et les champs obligatoires sont garantis, sans nouvel essai en cas de violation du schéma. Claude lit un PDF page par page (texte et image) : 1 500 à 3 000 jetons de texte par page selon la densité, sans supplément propre au PDF, d'après la documentation.
Tableau de décision
| Critère | Modèle spécialisé | LLM avec schéma |
|---|---|---|
| Document standard (facture, pièce d'identité) | Très adapté | Possible |
| Document rare ou sur mesure (courrier, rapport) | Il faut entraîner un modèle personnalisé | Un nouveau schéma suffit |
| Langue | Dépend du modèle : le modèle contrat d'Azure ne gère que l'anglais | Large, à tester en français |
| Score de confiance par champ | Fourni par Azure (champs, mots) | Pas fourni par les sorties structurées : à construire |
| Forme du résultat | Fixée par l'éditeur | Fixée par votre schéma |
| Coût | À la page, grille de l'éditeur | À la quantité de jetons |
| Mise en route | Rapide si le type est couvert | Rapide, mais l'évaluation reste à faire |
Les trois limites à connaître
- Les sorties structurées garantissent la forme, pas le fond. Un montant peut être bien typé et faux. Ajoutez des contrôles de cohérence, décrits dans schéma JSON d'extraction.
- Les langues. Azure indique que son modèle de contrat supporte les documents en anglais. Google précise que son mode génératif du Custom Extractor ne prend officiellement en charge que l'anglais. Pour des contrats français, un LLM est donc l'option documentée ; voir extraire les clauses d'un contrat.
- Les limites de volume. Claude accepte jusqu'à 600 pages par requête (100 si la fenêtre de contexte est inférieure à 1 million de jetons) et 128 Mo par requête. Azure traite jusqu'à 2 000 pages par PDF et 500 Mo en offre payante.
Comparer les coûts sans se tromper
Le prix à la page d'un service spécialisé se compare à un coût en jetons. Calcul de borne basse, avec les prix relevés le 15/11/2026 : en traitement par lots, Claude Sonnet 5.5 est affiché à 1 $ par million de jetons en entrée. Mille pages à 3 000 jetons de texte chacune font 3 millions de jetons, soit environ 3 $ de texte en entrée. C'est une borne basse : le PDF est aussi lu comme une image, la sortie est facturée à part (5 $ par million de jetons en lot), et rien ne dit que le résultat sera assez juste. À titre de repère, Mistral OCR 4.1 affiche 5 $ les 1 000 pages annotées.
Le coût réel comprend ensuite le temps humain passé à relire les champs douteux. Un service un peu plus cher mais plus juste coûte souvent moins cher au total : c'est ce que la mesure de précision permet de chiffrer.
Règle de choix
- Votre document est un type courant, dans une langue couverte, et vous voulez un score par champ : commencez par le modèle spécialisé. Comparatif de prix pour les factures : API d'extraction de factures.
- Vos documents sont variés, ou le modèle spécialisé ne couvre pas votre langue : commencez par un LLM et un schéma strict.
- Dans les deux cas, prenez 50 à 100 documents réels, saisissez la bonne réponse à la main et comparez. Incluez les pires : scans de travers, documents de plusieurs pages.
- Vous pouvez aussi combiner : un modèle spécialisé pour le gros du flux, un LLM pour les documents qui n'ont pas passé les contrôles.
Pour choisir la taille du modèle, voir petit ou grand modèle. Pour la sortie JSON côté API, voir sortie JSON structurée.
Questions fréquentes
Un LLM peut-il remplacer un modèle d'extraction spécialisé ?
Souvent pour des documents variés ou rares, à condition de lui imposer un schéma et de mesurer le résultat. Un modèle spécialisé reste plus simple quand le type de document est couvert (facture, pièce d'identité) et que vous voulez un score de confiance par champ.
Les sorties structurées garantissent-elles que les valeurs sont justes ?
Non. Elles garantissent que le JSON est valide et conforme au schéma (types, champs obligatoires), pas que le montant lu soit le bon.
Sources
Pages consultées pour écrire cet article :
- https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice?view=doc-intel-4.0.0
- https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/contract?view=doc-intel-4.0.0
- https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/concept/accuracy-confidence?view=doc-intel-4.0.0
- https://docs.cloud.google.com/document-ai/docs/processors-list
- https://platform.claude.com/docs/en/build-with-claude/pdf-support
- https://platform.claude.com/docs/en/build-with-claude/structured-outputs
- https://platform.claude.com/docs/en/build-with-claude/batch-processing
- https://docs.mistral.ai/models/ocr-4-1