n8n : extraire les données de factures PDF avec l'IA (guide complet)

Une PME qui reçoit trente factures fournisseurs par semaine perd facilement deux à trois heures à les ressaisir dans son outil de compta : numéro, date, montant HT, TVA, référence fournisseur. Le travail est répétitif, sujet aux erreurs de frappe, et n'apporte aucune valeur. C'est exactement le type de tâche que n8n peut automatiser de bout en bout : réception de la facture, lecture du contenu, extraction des champs utiles dans un format fiable, puis stockage ou export vers votre outil de gestion. Ce guide détaille les deux architectures possibles et le pipeline concret à construire.

Deux approches pour lire une facture PDF

Toutes les factures PDF ne se ressemblent pas côté machine. Une facture générée par un logiciel (Stripe, une compta en ligne, un ERP) contient un texte réellement sélectionnable. Une facture scannée ou photographiée n'est qu'une image : il n'y a aucun texte à extraire tant qu'on n'a pas fait de reconnaissance optique de caractères.

Pour un PDF texte natif, le node Extract from File (n8n-nodes-base.extractFromFile) suffit : il récupère le contenu textuel brut du document, sans dépendance externe ni coût d'API. C'est l'option la plus rapide et la moins chère quand vos fournisseurs envoient des PDF propres.

Pour un PDF scanné ou une photo, deux options existent :

OCR classique puis LLM : un service dédié (Google Cloud Vision, Mistral OCR, Nanonets) transforme d'abord l'image en texte, que l'on passe ensuite à un modèle de langage pour l'extraction structurée. C'est l'approche la plus robuste sur de gros volumes ou des tableaux complexes (lignes d'articles multiples), car ces outils sont spécialisés dans la reconnaissance de mise en page.
LLM multimodal direct : les modèles récents (GPT-4o, Claude, Gemini) lisent directement une image ou un PDF sans étape d'OCR séparée — on leur envoie le fichier encodé en base64 et ils en extraient le texte et la structure en une seule passe. Plus simple à mettre en place pour un volume modéré, avec une seule clé API à gérer plutôt que deux services distincts.

En pratique, commencez par le LLM multimodal direct : il couvre la majorité des cas avec un seul node et un seul credential. Ne basculez vers un OCR dédié que si vous traitez des centaines de documents par jour (coût unitaire plus faible) ou des tableaux de lignes très denses où un OCR spécialisé se montre plus fiable qu'un modèle généraliste.

Construire le pipeline dans n8n

1. Déclenchement

Trois sources courantes selon votre organisation :

Pièce jointe email (IMAP ou Gmail Trigger) : la facture arrive directement dans une boîte dédiée (factures@ par exemple).
Dossier surveillé (Google Drive Trigger ou Dropbox) : vos fournisseurs ou votre équipe y déposent les PDF.
Webhook : un formulaire d'upload ou un autre outil pousse le fichier via POST.

Dans les trois cas, le node de déclenchement doit produire un binaire (le fichier PDF) exploitable par les nodes suivants — vérifiez le champ binaire (data par défaut) dans les propriétés du node.

2. Extraction du texte

PDF texte natif → Extract from File, mode PDF, sortie en texte brut.
PDF scanné → conversion du binaire en base64 (souvent automatique selon le node modèle) puis appel à un Chat Model capable de vision (OpenAI GPT-4o, Anthropic Claude, Google Gemini) avec le fichier en pièce jointe du message.

3. Extraction structurée avec une chaîne LLM

Que le texte vienne d'Extract from File ou d'un LLM vision, l'étape suivante est identique : une Basic LLM Chain (chainLlm) associée à un Structured Output Parser qui impose un schéma JSON précis. C'est le même mécanisme que nous détaillons dans notre guide pour débuter avec les nodes IA de n8n — ici appliqué à un cas concret. Un schéma typique pour une facture :

{
  "numero_facture": "string",
  "date_facture": "string (format AAAA-MM-JJ)",
  "fournisseur": "string",
  "montant_ht": "number",
  "montant_tva": "number",
  "montant_ttc": "number",
  "devise": "string",
  "lignes": [
    { "description": "string", "quantite": "number", "prix_unitaire": "number" }
  ]
}

Le prompt de la chaîne doit être explicite sur les cas ambigus : que faire si un champ est absent (renvoyer null, jamais inventer une valeur), comment normaliser les dates, et sur quelle devise se baser si plusieurs montants apparaissent (acompte, solde). Cette rigueur de prompt fait toute la différence entre une extraction exploitable et un JSON à moitié halluciné.

Valider et stocker les données

Avant tout stockage, ajoutez une étape de validation logique dans un node IF ou Code : le montant HT plus la TVA doit correspondre au montant TTC à un centime près, la date doit être dans une plage plausible, le numéro de facture ne doit pas être vide. Ces vérifications simples détectent la majorité des extractions défaillantes sans appel supplémentaire au modèle.

Pour le stockage, une table Supabase (factures_extraites) est la solution la plus flexible : elle permet ensuite des requêtes, des tableaux de bord ou une synchronisation vers votre outil de compta. Notre guide de connexion n8n à Supabase couvre la mise en place des credentials et des requêtes d'insertion. Pour une équipe plus habituée aux tableurs, un export direct vers Google Sheets fonctionne tout aussi bien pour démarrer.

Gérer les cas difficiles

Aucun pipeline d'extraction n'atteint 100 % de fiabilité automatique, et ce n'est pas l'objectif : l'objectif est de ne faire relire à un humain que les cas réellement ambigus.

Facture manuscrite ou scan de mauvaise qualité : si le modèle renvoie un score de confiance bas ou des champs null sur des informations critiques (montant, fournisseur), routez la facture vers une relecture manuelle plutôt que de l'insérer telle quelle. Le pattern d'approbation humaine avec le node Wait et des boutons Slack, décrit dans notre article dédié, s'applique parfaitement ici : un message Slack affiche les champs extraits, un clic valide ou corrige avant l'insertion finale.
Échec d'appel API (timeout, erreur du modèle) : configurez un Error Workflow dédié pour capturer ces échecs et notifier plutôt que de perdre silencieusement la facture — voir notre guide sur la gestion des erreurs dans n8n.
Doublon : avant insertion, vérifiez par une requête Supabase si un numéro de facture identique pour le même fournisseur existe déjà, pour éviter les doubles saisies en cas de renvoi accidentel du même email.

Coûts et volumétrie

Pour un LLM multimodal économique (type GPT-4o mini ou équivalent), une facture d'une à deux pages coûte de l'ordre de quelques centimes en tokens d'entrée (l'image pèse davantage que du texte pur, mais reste marginal face au temps humain économisé). Au-delà de quelques dizaines de documents traités en rafale (import d'un mois d'archives, par exemple), pensez à cadencer les appels pour éviter les erreurs 429 — notre article sur les rate limits des API OpenAI et Anthropic dans n8n détaille le réglage de Loop Over Items et du node Wait pour ce cas précis.

Pour aller plus loin

Ce pipeline — déclenchement, extraction, sortie structurée, validation, stockage — reprend l'architecture exacte du workflow d'ingestion documentaire du Pack Assistant RAG (119 €), à la différence que l'objectif ici est l'extraction de champs précis plutôt que la recherche sémantique. Si votre besoin dépasse la simple extraction et inclut une piste d'audit complète (qui a traité quelle facture, quand, avec quel résultat), le Pack Conformité & Audit (149 €) fournit la brique de journalisation Supabase prête à brancher derrière ce type de pipeline.