RAG sur des PDF avec n8n : extraire, découper et interroger vos documents

Des contrats, des rapports, des notices techniques, des factures : la connaissance des entreprises dort massivement dans des PDF. Un assistant RAG capable de répondre « que dit l'article 7 du contrat Dupont ? » en citant le bon passage est l'un des cas d'usage les plus demandés de n8n — et l'un de ceux où les détails d'implémentation font toute la différence. Ce guide couvre le pipeline complet : extraction du texte (y compris pour les PDF scannés), découpage adapté, indexation vectorielle et interrogation, avec les pièges propres au format PDF.

Le pipeline en quatre étapes

Un RAG sur PDF dans n8n s'articule toujours autour du même squelette :

1. Récupérer les fichiers : un trigger Google Drive (nouveau fichier dans un dossier), un node Dropbox, un email entrant avec pièce jointe, ou un simple dossier surveillé en self-hosted.
2. Extraire le texte : le node Extract from File (opération Extract From PDF) restitue le texte de la couche textuelle du PDF.
3. Découper et vectoriser : un text splitter, un modèle d'embeddings, puis l'insertion dans un vector store (Qdrant, Supabase/pgvector, Pinecone…).
4. Interroger : un AI Agent ou une chaîne Question & Answer branchée sur le même vector store, avec un node de chat ou un webhook en entrée.

Les étapes 3 et 4 sont communes à tous les RAG — nos guides sur le chunking des documents et le choix du modèle d'embeddings s'appliquent tels quels. Ce qui change avec les PDF, c'est l'étape 2 : l'extraction, où se joue la qualité de tout le reste. Le principe fondateur du RAG — donner au modèle un accès à une base documentaire externe plutôt que de compter sur sa mémoire — vient des travaux de Lewis et ses co-auteurs publiés en 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks) ; tout ce qui suit en est l'application concrète au format le moins coopératif qui soit.

Extract from File : ce que le node sait faire (et pas)

Pour un PDF natif — produit par un traitement de texte, un export comptable, un générateur de factures — le node Extract from File suffit : il lit la couche texte embarquée et la restitue dans un champ text, avec le nombre de pages et les métadonnées du document. Réglages utiles : l'option Join Pages pour obtenir un seul bloc de texte plutôt qu'un texte par page, et Max Pages pour plafonner le traitement des documents fleuves.

Ce que le node ne sait pas faire :

• Les PDF scannés : un scan est une image, il n'y a pas de couche texte à lire. Le node renvoie une chaîne vide ou quasi vide — c'est d'ailleurs le meilleur test automatique pour router le document vers l'OCR (un node IF sur la longueur du texte extrait).
• La mise en page : colonnes multiples, encadrés, notes de bas de page sortent dans un ordre parfois surprenant.
• Les tableaux : les cellules sont aplaties ligne à ligne, la correspondance avec les en-têtes se perd.

PDF scannés : l'étage OCR

Pour les scans, il faut un étage de reconnaissance optique avant l'indexation. Trois options selon le contexte :

Option	Type	Points forts	À savoir
Mistral OCR / API vision LLM	API cloud	Excellente qualité, restitue le Markdown (titres, tableaux)	Coût par page, données envoyées à un tiers
Google Document AI	API cloud	Très robuste sur les documents administratifs	Configuration GCP plus lourde
Tesseract (self-hosted)	Open source	Gratuit, données sur place	Qualité moindre sur les scans dégradés, pas de structure

La qualité de l'OCR n'est pas un détail cosmétique : les recherches en recherche d'information menées sur des corpus océrisés — notamment les travaux de Taghva, Borsack et Condit publiés en 1996 (Evaluation of model-based retrieval effectiveness with OCR text) — montrent que la recherche résiste étonnamment bien aux erreurs modérées d'OCR, mais se dégrade nettement sur les documents courts ou les scans de mauvaise qualité, exactement le profil des factures et courriers scannés. Un contrôle qualité simple (taux de caractères non alphabétiques, mots hors dictionnaire) en sortie d'OCR évite d'indexer du bruit.

Découper des PDF : respecter la structure

Le découpage par caractères fonctionne, mais les PDF professionnels ont presque toujours une structure exploitable : articles de contrat, sections numérotées, titres. Si votre étage d'extraction restitue du Markdown (cas des OCR modernes), un splitter qui coupe sur les titres produit des chunks qui correspondent à des unités de sens — une clause, une section — et la pertinence de la recherche s'en ressent immédiatement.

Deux réglages complémentaires spécifiques aux PDF :

• Métadonnées de citation : stockez file_name, page et si possible la section dans les métadonnées de chaque chunk. C'est ce qui permet à l'assistant de répondre « contrat Dupont, page 12, article 7 » au lieu d'une affirmation invérifiable — et c'est la base du filtrage par métadonnées.
• Limiter le nombre de chunks remontés : inutile d'envoyer 20 chunks au modèle. Les travaux de Liu et co-auteurs publiés en 2023 (Lost in the Middle: How Language Models Use Long Contexts) montrent que les modèles exploitent mal l'information noyée au milieu d'un long contexte : 4 à 6 chunks bien classés — éventuellement via un reranking — battent 20 chunks bruts.

Le workflow d'ingestion, concrètement

Le squelette d'ingestion à reproduire dans n8n :

1. Google Drive Trigger — On new file in folder, filtré sur application/pdf.
2. Google Drive — Download file (le trigger ne fournit que les métadonnées).
3. Extract from File — Extract From PDF, Join Pages activé.
4. IF — {{ $json.text.length > 100 }} : vrai → suite du pipeline ; faux → branche OCR puis retour au flux principal.
5. Vector Store (Qdrant/Supabase) — Insert documents, avec un Default Data Loader portant les métadonnées (file_id, file_name, page) et un text splitter réglé à 800 tokens / 15 % d'overlap.

Côté interrogation, un AI Agent avec l'outil Vector Store branché sur le même index suffit ; le prompt système doit exiger la citation du fichier et de la page pour chaque affirmation. Pour les corpus mêlant références exactes (numéros d'article, codes) et questions en langage naturel, la recherche hybride BM25 + vecteurs fait la différence, et l'évaluation de la qualité du RAG sur un jeu de questions-réponses de référence vous dira si le pipeline tient ses promesses.

Les pièges spécifiques aux PDF

• Les doublons de versions : sans stratégie de mise à jour par file_id, chaque nouvelle version d'un contrat coexiste avec l'ancienne dans l'index — et l'assistant cite l'obsolète. Voir notre guide sur la mise à jour d'un index RAG.
• Les en-têtes et pieds de page répétés : « Société X — Confidentiel — page N » répété 40 fois pollue les embeddings. Un nettoyage par expression régulière à l'ingestion (lignes identiques présentes sur plus de la moitié des pages) règle le problème.
• Les PDF protégés : un PDF chiffré ou protégé contre la copie fait échouer l'extraction. Prévoir une branche d'erreur qui notifie plutôt qu'un workflow qui s'arrête en silence.
• Extraire ≠ comprendre : pour des documents à structure fixe (factures, bons de commande), l'approche RAG est un détour — une extraction structurée directe par IA vers un JSON validé est plus fiable et moins chère.

Ce qu'il faut retenir

Le RAG sur PDF dans n8n ne demande aucun composant exotique : Extract from File pour les PDF natifs, un étage OCR conditionnel pour les scans, un découpage qui respecte la structure du document, des métadonnées de citation systématiques. La qualité se joue à l'ingestion — c'est là qu'il faut investir, le reste du pipeline étant identique à n'importe quel RAG bien construit.