Résumer des documents longs avec l'IA dans n8n : la méthode qui tient la longueur

Un rapport annuel de 80 pages, un appel d'offres, un thread d'emails de six mois, la transcription d'une réunion de deux heures : les documents dont on a le plus besoin d'un résumé sont précisément ceux qui ne tiennent pas confortablement dans un appel LLM. La tentation du « je colle tout dans le prompt » se heurte à une limite bien documentée : une étude de Liu et al. publiée en 2024 dans Transactions of the Association for Computational Linguistics (« Lost in the Middle: How Language Models Use Long Contexts », voir sur Google Scholar) montre que les modèles exploitent nettement mieux les informations situées au début et à la fin de leur contexte que celles du milieu — exactement là où se trouve le cœur d'un long rapport. La bonne nouvelle : un pipeline n8n de type map-reduce contourne le problème proprement.

La stratégie map-reduce en trois étages

1. Découper le document en blocs cohérents (par chapitre, section ou groupe de pages).
2. Résumer chaque bloc indépendamment (map) : chaque appel LLM travaille sur un contexte court, où rien n'est « au milieu ».
3. Synthétiser les résumés partiels en un résumé final (reduce), éventuellement en plusieurs passes si le document est très long.

Ce découpage a un second avantage, moins évident : chaque résumé partiel est traçable. Quand le résumé final affirme quelque chose, vous pouvez remonter au bloc source — impossible avec un appel unique sur 80 pages.

Étape 1 : extraire et découper le texte

L'extraction dépend du format : le node Extract From File récupère le texte des PDF natifs, DOCX et TXT — les mêmes mécanismes que dans notre guide sur l'extraction de fichiers Excel et CSV. Pour le découpage, un node Code suffit : coupez sur les frontières naturelles (titres, doubles sauts de ligne) autour de 2 000 à 4 000 tokens par bloc, avec un léger chevauchement. Les principes détaillés dans notre guide du chunking de documents pour le RAG s'appliquent, avec une différence : pour du résumé, on préfère des blocs plus gros et sémantiquement complets plutôt que des petits chunks optimisés pour la recherche.

// Découpage par sections avec regroupement ~3000 tokens (≈ 12000 caractères)
const sections = $json.texte.split(/\n(?=#{1,3} |\d+\. )/);
const blocs = [];
let courant = "";
for (const s of sections) {
  if ((courant + s).length > 12000) { blocs.push(courant); courant = s; }
  else courant += "\n" + s;
}
if (courant.trim()) blocs.push(courant);
return blocs.map((texte, i) => ({ json: { bloc: i + 1, texte } }));

Étape 2 : résumer chaque bloc (map)

Chaque bloc part dans un appel LLM — via le node Summarization Chain de n8n, qui implémente nativement les stratégies map-reduce et refine, ou via une boucle Loop Over Items sur une Basic LLM Chain si vous voulez contrôler finement le prompt. Le prompt des résumés partiels doit imposer trois choses : conserver chiffres, dates, montants et noms propres tels quels ; indiquer la section source ; signaler explicitement si le bloc ne contient aucune information substantielle plutôt que de broder. Sur le choix du modèle, le résultat compte plus que la puissance brute : une étude de Zhang et al. publiée en 2024 dans TACL (« Benchmarking Large Language Models for News Summarization », voir sur Google Scholar) montre que c'est l'instruction tuning, bien plus que la taille du modèle, qui fait la qualité d'un résumé — un modèle économique et récent résume mieux qu'un gros modèle mal instruit, et divise vos coûts par dix sur les étapes map.

Étape 3 : la synthèse finale (reduce)

Un node Aggregate (voir notre guide Split Out et Aggregate) rassemble les résumés partiels, puis un dernier appel LLM produit la synthèse. C'est ici qu'un modèle plus capable se justifie : hiérarchiser, détecter les contradictions entre sections, produire une structure exploitable. Verrouillez la sortie avec un Structured Output Parser — résumé exécutif, points clés, chiffres, risques, actions — plutôt qu'un texte libre : c'est ce qui rend le résumé exploitable par la suite du workflow (envoi Slack, fiche Notion, rapport PDF).

Si les résumés partiels dépassent eux-mêmes le contexte confortable du modèle de synthèse, ajoutez un étage intermédiaire : résumez les résumés par groupes de dix, puis synthétisez les méta-résumés. Deux étages suffisent pour des documents de plusieurs centaines de pages.

Fiabilité : les trois contrôles qui comptent

• Contrôle de couverture : vérifiez par code que chaque bloc a bien produit un résumé (un appel échoué en silence = une section entière absente de la synthèse). Un Error Workflow et des retries sur les nodes LLM couvrent les pannes ponctuelles.
• Contrôle des chiffres : un node Code vérifie que les montants et dates critiques du document source apparaissent dans le résumé final ; sinon, l'item part en revue humaine.
• Contrôle du coût : sur de gros volumes, les étapes map dominent la facture. Suivez la dépense par exécution avec notre méthode de suivi du coût des appels IA, et pensez au cache sémantique si les mêmes documents reviennent.

Résumer ou interroger ? Les deux.

Le résumé donne la vue d'ensemble ; il ne remplace pas la possibilité de poser des questions précises sur le document. Les deux pipelines partagent leurs premières étapes (extraction, découpage) : prolongez le vôtre en indexant les chunks dans une base vectorielle pour obtenir un RAG complet avec Supabase. C'est exactement l'architecture du Pack Assistant RAG (119 €) : ingestion de PDF, chatbot avec citations et API question-réponse, auxquels un étage de résumé map-reduce s'ajoute naturellement.

Un pipeline de résumé bien construit transforme la pile de documents que personne ne lit en synthèses de dix lignes que tout le monde lit — avec les chiffres exacts, et la possibilité de remonter à la source de chaque affirmation.