Extraire les données d'une facture PDF avec un modèle de langage, ça prend une après-midi à faire fonctionner sur vos dix premières factures — et pas mal plus longtemps à rendre fiable sur les mille suivantes. Voici ce qui compte réellement dans ce trajet-là.

La réponse courte

Pour la majorité des cas, l'approche qui marche aujourd'hui tient en trois étapes :

Envoyez le PDF à un modèle multimodal (qui lit l'image de la page, pas seulement le texte). Oubliez les gabarits par fournisseur.
Forcez une sortie structurée avec un schéma JSON explicite. Ne demandez jamais « réponds en JSON » en espérant pour le mieux.
Validez la sortie avec du code déterministe. C'est l'étape que tout le monde saute, et c'est celle qui sépare une démo d'un système utilisable.

Le reste de cet article détaille chacune d'elles, avec les pièges rencontrés en production.

Pourquoi c'est plus dur qu'il n'y paraît

Une facture, c'est un document semi-structuré : tout le monde met les mêmes informations, personne ne les met au même endroit. Le total est en bas à droite, sauf chez ce fournisseur-là où il est en haut. La date est en format AAAA-MM-JJ, sauf sur les factures américaines. Le numéro de TPS est parfois collé au numéro de TVQ dans la même ligne de pied de page.

C'est exactement le genre de variabilité qui tue les approches classiques :

Les gabarits par fournisseur fonctionnent parfaitement — jusqu'à ce que le fournisseur refasse son en-tête. Vous vous retrouvez à maintenir un gabarit par émetteur, pour l'éternité.
Les expressions régulières attrapent bien un numéro de taxe, mal un sous-total, et jamais une structure.
L'OCR classique (Tesseract et compagnie) vous rend du texte brut avec des coordonnées. Il voit les caractères, il ne comprend pas que ce nombre-là est un total et celui-ci une quantité.

Un modèle de langage multimodal change la donne parce qu'il fait les deux d'un coup : il lit la page et il interprète ce qu'il lit. Vous lui demandez « c'est quoi le sous-total » plutôt que de lui décrire où chercher.

Choisir son modèle

Le paysage bouge vite, alors plutôt qu'un palmarès qui sera périmé dans six mois, voici les axes sur lesquels comparer — et ce qu'ils veulent dire concrètement.

Le modèle voit-il la page, ou seulement son texte ? C'est la question la plus importante. Un PDF scanné n'a pas de couche texte : un modèle purement textuel n'y verra rien du tout. Les familles multimodales courantes (Claude, GPT, Gemini, Mistral) gèrent l'image ; assurez-vous d'utiliser la variante qui accepte des documents ou des images, pas seulement du texte.

Y a-t-il un mode « document » dédié ? Certains fournisseurs proposent une API spécialisée en OCR de documents, distincte de leur modèle de conversation. Quand elle existe, elle est généralement nettement moins chère à la page et mieux calibrée sur la mise en page. Ça vaut la peine de la tester avant de sortir l'artillerie lourde.

Le modèle garantit-il une sortie structurée ? Voir la section suivante — c'est un critère éliminatoire, pas un bonus.

Où sont traitées les données ? Au Québec, si vous traitez des documents contenant des renseignements personnels, la Loi 25 vous oblige à évaluer les transferts hors province. Ce n'est pas un détail juridique abstrait : ça peut éliminer un fournisseur de votre liste avant même le premier test de qualité.

Le bon réflexe : montez un jeu de 20 factures réelles et représentatives — pas des exemples propres — et faites tourner deux ou trois candidats dessus. Vous apprendrez plus en une après-midi qu'en une semaine de lecture de bancs d'essai.

Obtenir du JSON fiable, pas du JSON approximatif

Demander à un modèle de « répondre en JSON » produit du JSON valide la plupart du temps. « La plupart du temps » n'est pas une base sur laquelle bâtir. Un bloc de texte d'explication avant l'accolade ouvrante, et votre parseur plante.

Tous les grands fournisseurs offrent aujourd'hui un mécanisme de sortie structurée : vous fournissez un schéma JSON, et l'API garantit que la réponse s'y conforme. Utilisez-le systématiquement.

L'astuce qui fait gagner du temps : définissez le schéma une seule fois, dans votre langage, et dérivez-en le reste. Ça évite la dérive entre deux fournisseurs et vous donne la validation de type gratuitement.

Pour les développeurs

En TypeScript avec Zod, un même schéma sert de source de vérité, de validateur à l'exécution, et de schéma JSON pour l'API :

import { z } from "zod";

export const FactureSchema = z.object({
  date: z.string().nullable(),          // ISO AAAA-MM-JJ
  fournisseur: z.string().nullable(),
  numero_facture: z.string().nullable(),
  no_tps: z.string().nullable(),
  no_tvq: z.string().nullable(),
  sous_total: z.number().nullable(),
  tps: z.number().nullable(),
  tvq: z.number().nullable(),
  total: z.number().nullable(),
  devise: z.string().nullable(),
});

export type Facture = z.infer<typeof FactureSchema>;

// Le même schéma, converti pour une API qui attend du JSON Schema :
const jsonSchema = z.toJSONSchema(FactureSchema);

Deux choix qui comptent plus qu'ils n'en ont l'air :

Tout est nullable. Un champ absent doit pouvoir revenir à null. Si votre schéma exige une valeur, le modèle en inventera une — c'est la source d'hallucination numéro un sur ce genre de tâche.
Les montants sont des nombres, pas des chaînes. Vous éviterez de reparser 1 234,56 $ plus tard, avec ses espaces insécables et sa virgule décimale.

La règle d'or : le modèle extrait, le code valide

C'est le cœur du sujet, et la partie que les démos escamotent.

Un modèle de langage n'a aucune notion de cohérence arithmétique. Il peut vous rendre un sous-total de 100 $, une TPS de 5 $, une TVQ de 9,98 $ et un total de 118 $ sans sourciller — chaque champ isolément plausible, l'ensemble faux. Il peut aussi lire 1 234,56 comme 123456 si le séparateur de milliers est un espace fin.

La parade n'est pas un meilleur prompt. C'est du code ordinaire, exécuté après coup :

Pour les développeurs

const TAUX_TPS = 0.05;
const TAUX_TVQ = 0.09975;
const TOLERANCE = 0.02; // en dollars, pour absorber les arrondis

function valider(f: Facture): string[] {
  const avis: string[] = [];

  // 1. La somme balance-t-elle ?
  if (f.sous_total != null && f.total != null) {
    const somme = f.sous_total + (f.tps ?? 0) + (f.tvq ?? 0);
    if (Math.abs(somme - f.total) > TOLERANCE) {
      avis.push(`Le total ne balance pas (calculé ${somme.toFixed(2)}).`);
    }
  }

  // 2. Les taux sont-ils plausibles ?
  if (f.sous_total && f.tps != null) {
    const taux = f.tps / f.sous_total;
    if (Math.abs(taux - TAUX_TPS) > 0.002) {
      avis.push(`Taux de TPS inhabituel : ${(taux * 100).toFixed(2)} %.`);
    }
  }

  // 3. Les numéros de taxe ont-ils la bonne forme ?
  if (f.no_tps && !/^\d{9}\s?RT\s?\d{4}$/i.test(f.no_tps)) {
    avis.push("Numéro de TPS mal formé.");
  }

  return avis;
}

Trois vérifications, quelques dizaines de lignes, et vous attrapez la grande majorité des extractions douteuses.

Le point important, c'est ce que vous faites de ces avis. Ne corrigez pas silencieusement. Si le total ne balance pas, ne recalculez pas le total à la place de l'utilisateur : signalez-le. Une valeur corrigée en douce est pire qu'une valeur manifestement fausse, parce que personne ne la vérifiera jamais. Une colonne « avertissements » à côté des données extraites transforme un système opaque en système auditable.

Ce que ça coûte

Impossible de donner un chiffre qui tienne plus qu'un trimestre — les prix des API bougent, souvent à la baisse. Ce qui ne bouge pas, c'est la manière de calculer :

Les jetons d'entrée dominent. Une page de facture envoyée en image consomme typiquement beaucoup plus de jetons que la réponse JSON qu'elle produit. Optimisez la résolution de l'image avant d'optimiser le prompt.
La sortie est minuscule. Une dizaine de champs, c'est négligeable.
Le mode « document » dédié, quand il existe, coûte souvent un ordre de grandeur de moins qu'un modèle de conversation généraliste pour la même page. Vérifiez-le sur votre propre volume.

Le calcul à faire : prenez le prix par million de jetons d'entrée, estimez les jetons d'une page chez votre fournisseur, multipliez par votre volume mensuel. Puis comparez au temps humain que ça remplace — c'est là que le ratio devient évident.

Les pièges qui coûtent cher

Les crédits et les notes de crédit. Un montant négatif change tout le sens du document. Si votre schéma ne prévoit pas le cas, vous allez additionner des remboursements comme des dépenses.

Les devises multiples. Une facture en dollars américains avec des taxes canadiennes, ça existe. Extrayez la devise explicitement, ne la déduisez jamais du symbole $.

Les factures multipages. Le total est sur la dernière page, les lignes sur les précédentes. Un traitement page par page sans agrégation vous rendra des résultats incohérents.

Les documents qui ne sont pas des factures. Tôt ou tard, quelqu'un déposera un relevé bancaire ou un bon de commande. Le modèle fera de son mieux et vous rendra des données plausibles et inutiles. Prévoyez un champ de confiance et un seuil de rejet.

Les taux de taxe hors Québec. La TVH des provinces maritimes n'est pas une TPS plus une TVQ. Si vos règles de validation sont écrites en dur pour le Québec, elles crieront au loup sur chaque facture de Halifax.

Faut-il le bâtir soi-même ?

Honnêtement : ça dépend du volume et de ce que vous faites du résultat.

Si vous traitez quelques dizaines de factures par mois pour votre propre comptabilité, le temps de développement ne se rentabilisera jamais — un outil existant coûtera moins cher que votre après-midi. C'est d'ailleurs pour ça que FactureCSV existe : déposer des PDF, récupérer un CSV, sans écrire une ligne de code.

Si vous traitez des milliers de documents, ou si l'extraction doit s'intégrer dans un flux existant — un ERP, un système de comptes payables, une base de données maison — alors bâtir a du sens. Le travail réel n'est pas l'appel à l'API : c'est la validation, la gestion des cas limites, la reprise sur erreur et le suivi de qualité dans le temps.

C'est aussi là que la plupart des projets calent. Pas sur la démo, qui marche en une après-midi, mais sur les 20 % de documents qui ne rentrent pas dans le moule.