Traiter les pièces jointes email avec l’IA dans n8n : extraction, classification et archivage automatique
Publié le 25 août 2026 · 6 min de lecture
Une boîte contact@ ou candidatures@ ne reçoit pas que du texte : elle reçoit des factures fournisseurs, des CV, des scans de pièce d’identité, des devis en PDF, parfois un tableur ou une capture d’écran. Un workflow n8n qui se contente de lire le sujet et le corps de l’email passe à côté de l’essentiel du contenu utile. Traiter correctement une pièce jointe demande une étape de plus que traiter du texte brut : récupérer le binaire, vérifier qu’il est sûr, en extraire le contenu selon son format, puis le classer et le ranger au bon endroit. Ce guide détaille ce pipeline complet, pensé pour s’ajouter à un tri d’emails existant plutôt que le remplacer.
Pourquoi une pièce jointe mérite un traitement à part
Le corps d’un email est du texte immédiatement exploitable par un LLM. Une pièce jointe, elle, arrive sous forme de binaire : n8n doit d’abord savoir qu’elle existe, sous quel nom de propriété binaire elle est rangée, quel est son format, et si elle mérite d’être ouverte du tout. Ignorer cette dernière question n’est pas anodin : une adresse exposée publiquement (candidature, contact, support) reçoit inévitablement, tôt ou tard, une pièce jointe malveillante déguisée en CV ou en facture. Une étude de Muralidharan et Nissim publiée dans Neural Networks (2023) sur la détection de pièces jointes malveillantes par apprentissage profond montre qu’analyser l’en-tête, le corps et la pièce jointe comme trois signaux distincts améliore nettement la détection par rapport à une analyse du seul texte — une confirmation que la pièce jointe n’est pas un détail annexe de l’email, mais une surface à part entière qui mérite son propre filtrage avant traitement.
Récupérer les pièces jointes dans n8n
Le point de départ est un trigger email : Email Trigger (IMAP) pour une boîte générique, ou le trigger Gmail natif si votre messagerie est chez Google. Les deux exposent les pièces jointes comme propriétés binaires sur l’item, mais avec des conventions de nommage différentes :
- Gmail nomme chaque pièce jointe
attachment_0,attachment_1, etc. — il faut itérer sur ces propriétés plutôt que d’en cibler une seule par son nom. - Email Trigger (IMAP) regroupe généralement les pièces jointes sous des noms de propriété liés au fichier lui-même ; vérifiez la sortie du node en mode debug avant de câbler la suite, les conventions varient selon le serveur mail source.
Dans les deux cas, un node Code en début de pipeline qui boucle sur $binary et normalise chaque pièce jointe en un item séparé (avec le nom de fichier, le type MIME et la taille en métadonnée) simplifie tout ce qui suit : le reste du workflow traite alors « un document » sans se soucier de combien il y en avait dans l’email d’origine. Si vos pièces jointes dépassent quelques dizaines de mégaoctets (scans haute résolution, exports volumineux), notre guide sur les fichiers volumineux dans n8n explique les limites réelles de mémoire et les réglages à connaître pour éviter un crash.
Construire le pipeline de traitement
1. Filtrer avant d’ouvrir quoi que ce soit
Avant tout appel à un modèle, un node IF ou Switch simple élimine déjà l’essentiel du bruit et du risque : rejeter les extensions exécutables (.exe, .js, .bat), les archives non attendues (.zip, .rar) sur une adresse qui ne devrait recevoir que des documents, et plafonner la taille acceptée. Sur une boîte exposée publiquement, un appel à un service de scan de fichiers (l’API VirusTotal, par exemple) avant tout traitement ajoute une couche de protection peu coûteuse à mettre en place — un simple node HTTP Request avec le hash ou le fichier en entrée.
2. Extraire le contenu selon le format
Une fois le fichier jugé sûr, l’extraction suit la même logique que pour un document isolé — nous la détaillons en profondeur dans notre guide sur l’extraction de données de factures PDF :
- CSV, XLS/XLSX, HTML, texte, PDF avec texte natif → le node Extract from File suffit, sans coût d’API.
- Image, scan, PDF sans texte sélectionnable → un Chat Model multimodal (GPT-4o, Claude, Gemini) reçoit le binaire encodé en base64 et en extrait directement le contenu, sans étape d’OCR séparée.
3. Classifier automatiquement le document
Le contenu extrait passe ensuite dans une Basic LLM Chain couplée à un Structured Output Parser, avec un schéma qui force une catégorie parmi une liste fermée (facture, contrat, cv, piece_identite, autre) plutôt qu’un texte libre. Classer un document par son contenu visuel et textuel est un problème bien étudié : Harley, Ufkes et Derpanis ont montré dès 2015, dans leur évaluation de réseaux convolutifs pour la classification d’images de documents (ICDAR 2015), que la structure visuelle d’un document (mise en page, densité de texte, présence de tableaux) porte à elle seule un signal de classification fiable — c’est précisément ce qu’un LLM multimodal moderne exploite en un seul appel, là où l’article original nécessitait un modèle entraîné dédié. Notre guide sur le classement automatique de documents entrants détaille ce mécanisme pour un dossier Drive ou Dropbox ; le principe est identique ici, seule la source (email plutôt que dossier surveillé) change.
4. Router et nommer selon la catégorie
Un node Switch branché sur le champ categorie de la sortie structurée dirige chaque document vers le traitement adapté : une facture part vers le pipeline d’extraction de champs comptables, un CV vers une table de suivi de candidatures, une pièce d’identité vers un stockage chiffré à accès restreint. Renommer le fichier selon un gabarit cohérent à cette étape ({date}_{categorie}_{expediteur}.pdf) évite l’accumulation de fichiers nommés scan001.pdf que plus personne ne sait identifier six mois plus tard.
Archiver, journaliser et notifier
Le document classé doit finir quelque part de traçable. Pour un stockage durable hors de la boîte mail, notre guide sur l’archivage de fichiers avec S3 couvre le node S3 (disponible en Community Edition) et son équivalent Google Drive ou Dropbox pour une équipe déjà installée sur ces outils. En parallèle, une ligne dans une table Supabase (nom du fichier, catégorie, expéditeur, date, lien vers l’archive) constitue une piste d’audit exploitable, dans l’esprit du digest quotidien du Pack Inbox IA : plutôt que de notifier pour chaque pièce jointe individuellement, un résumé groupé en fin de journée dans Slack ou Telegram liste les documents reçus et classés, avec une alerte immédiate réservée aux cas où la classification a échoué ou renvoyé une confiance basse. Configurez également un Error Workflow dédié : un fichier corrompu ou un appel API en échec ne doit jamais disparaître silencieusement, il doit atterrir dans une file de reprise manuelle.
Coûts et limites pratiques
Avec un modèle économique (GPT-4o mini ou équivalent), l’extraction et la classification d’un document d’une à deux pages coûtent de l’ordre du centime en tokens d’entrée. Sur une boîte recevant quelques dizaines de pièces jointes par jour, la facture mensuelle reste de l’ordre de quelques euros. Le vrai plafond à surveiller est la mémoire de l’instance n8n plutôt que le coût API : plusieurs pièces jointes volumineuses traitées en parallèle (import massif, rafale de candidatures avec CV en PDF lourd) peuvent saturer la RAM disponible en mode de stockage binaire par défaut — le guide sur les fichiers volumineux détaille les réglages pour l’éviter.
Pour aller plus loin
Ce pipeline — récupération, filtrage sécurité, extraction, classification, routage, archivage — complète naturellement le tri d’emails du Pack Inbox IA (79 €) : là où le pack trie et priorise le message lui-même, ce guide traite ce qui est attaché dessus. Si l’objectif dépasse le simple classement et vise à rendre l’ensemble de vos documents archivés interrogeables en langage naturel, le Pack Assistant RAG (119 €) reprend une architecture d’ingestion très proche pour construire un chatbot documentaire par-dessus. Et si votre secteur impose de prouver qui a traité quel document, quand et avec quel résultat, le Pack Conformité & Audit (149 €) fournit la brique de journalisation Supabase prête à brancher derrière ce type de pipeline.
FAQ
Questions fréquentes
Quelle différence entre traiter le corps de l’email et traiter ses pièces jointes ?
Le corps est du texte directement lisible par un LLM. Une pièce jointe est d’abord un binaire : il faut la récupérer sous forme de fichier, en identifier le format, puis en extraire le contenu (texte natif, OCR ou vision selon le cas) avant de pouvoir la faire lire à un modèle. C’est une étape technique en plus, mais qui suit toujours le même schéma quel que soit le type de document.
Comment savoir si une pièce jointe est dangereuse avant de la traiter ?
Un filtre par extension et taille (rejeter les .exe, .js, .zip non attendus) élimine déjà la majorité des cas grossiers. Pour un premier filtrage plus fin sans construire un antivirus maison, un appel à un service de scan de fichiers (VirusTotal API par exemple) avant tout traitement IA reste la méthode la plus fiable sur une adresse exposée publiquement comme contact@ ou candidatures@.
Peut-on traiter des pièces jointes autres que des PDF (images, tableurs, Word) ?
Oui. Le node Extract from File gère nativement CSV, XLS/XLSX, HTML, texte brut, RTF et PDF texte. Pour les images (photo de document, scan) ou les PDF sans texte sélectionnable, un modèle multimodal (GPT-4o, Claude, Gemini) reçoit directement le fichier encodé en base64 et en extrait le contenu sans étape d’OCR séparée.
Combien coûte le traitement IA d’une pièce jointe par email ?
Avec un modèle économique (GPT-4o mini ou équivalent), classer et extraire le contenu d’un document d’une à deux pages coûte de l’ordre du centime en tokens d’entrée. Sur une boîte qui reçoit quelques dizaines de pièces jointes par jour, la facture mensuelle reste de l’ordre de quelques euros — largement compensée par le temps de tri manuel économisé.
Bundle FlowKit Complet
269 €