Node Compression n8n : zipper et dézipper des fichiers dans un workflow

Un workflow n8n qui manipule des fichiers finit toujours par croiser une archive : trois pièces jointes à regrouper avant envoi, un .zip déposé sur un SFTP par un partenaire, un export CSV de 200 Mo à alléger avant l'upload. Le node Compression couvre ces deux besoins symétriques — créer une archive, en extraire le contenu — sans code ni binaire externe. Ce guide détaille ses paramètres réels, les patterns qui marchent, et les trois limites qui font échouer les premiers essais.

Ce que fait le node Compression

C'est un core node, sans credential, avec deux opérations :

• Compress : crée une archive à partir d'une ou plusieurs propriétés binaires de l'item courant.
• Decompress : extrait le contenu d'une archive présente dans une propriété binaire.

Les paramètres de Compress sont peu nombreux et tiennent sur un écran :

• Input Binary Field(s) : le nom de la propriété binaire à compresser, data par défaut. Pour plusieurs fichiers, on liste les noms séparés par des virgules — data,data2,data3.
• Output Format : Zip, Gzip, Tar ou Tar (Gzip).
• File Name : le nom du fichier produit, par exemple documents.zip. Ce champ n'apparaît que pour les formats conteneurs (zip, tar, tar.gz), puisqu'ils regroupent plusieurs entrées sous un nom unique.
• Put Output File in Field : la propriété binaire qui recevra l'archive, data par défaut. Pensez à la renommer (archive par exemple) si l'item transporte déjà un fichier dans data, sinon vous écrasez la source.

En Gzip, la logique change : gzip compresse un flux, pas une arborescence. Chaque propriété binaire listée en entrée est compressée séparément et le node utilise un Output Prefix pour nommer les sorties — gzip sur trois fichiers donne donc trois .gz, pas une archive unique. Si l'objectif est un seul fichier téléchargeable, choisissez Zip ou Tar (Gzip).

Côté Decompress, deux paramètres suffisent :

• Input Binary Field(s) : la propriété contenant l'archive (là encore, plusieurs noms séparés par des virgules).
• Output Prefix : le préfixe des propriétés binaires créées, file_ par défaut, auquel le node ajoute un index incrémental. Une archive de trois fichiers produit donc file_0, file_1, file_2 sur le même item de sortie.

La documentation n8n indique que l'opération reconnaît les extensions .zip, .gz, .gzip, .tar, .tar.gz et .tgz. Un .tar.gz est extrait en une passe : inutile d'enchaîner un Decompress gzip puis un Decompress tar.

Sous le capot, zip et gzip s'appuient tous deux sur DEFLATE, bâti sur l'algorithme publié par Jacob Ziv et Abraham Lempel dans « A Universal Algorithm for Sequential Data Compression » (IEEE Transactions on Information Theory, 1977). D'où l'écart de rendement : un CSV ou un JSON, très redondants, se compriment fortement, alors qu'un PDF ou un JPEG déjà compressé ne gagne quasiment rien.

Regrouper plusieurs pièces jointes en une archive

C'est le cas d'usage le plus demandé, et le plus souvent mal démarré. Le node Compression travaille item par item : trois fichiers répartis sur trois items produisent trois archives d'un fichier chacune. Pour obtenir un seul zip, les trois fichiers doivent être sur le même item, dans des propriétés binaires distinctes. Deux façons de les rassembler :

1. Un node Merge en mode Combine pour agréger des branches parallèles, en veillant à ce que les propriétés binaires ne portent pas le même nom (sinon la dernière écrase les précédentes).
2. Un node Code en mode Run Once for All Items, qui reconstruit un item unique :

const binary = {};
for (const [i, item] of $input.all().entries()) {
  binary[`data${i === 0 ? '' : i + 1}`] = item.binary.data;
}
return [{ json: { count: $input.all().length }, binary }];

Le node Compression qui suit reçoit alors data,data2,data3 en Input Binary Field(s), produit livraison.zip dans la propriété archive, et le node Gmail ou SMTP en aval attache cette seule propriété : une pièce jointe au lieu de dix, et un poids qui repasse souvent sous la limite des serveurs de messagerie. Les noms de fichiers dans l'archive reprennent le fileName des propriétés binaires, pensez donc à les fixer proprement en amont — le pipeline de récupération complet est décrit dans notre guide sur le traitement des pièces jointes email par IA.

Dézipper une archive reçue et traiter chaque fichier

Le chemin inverse est un classique des échanges partenaires : un .zip déposé chaque nuit sur un SFTP, ou reçu en pièce jointe. Le workflow type tient en quatre nodes :

1. Trigger — Schedule + node FTP/SFTP en mode Download, ou Email Trigger (IMAP). Le côté transfert est détaillé dans notre article sur le transfert de fichiers par SFTP avec n8n.
2. Compression, opération Decompress, sur la propriété qui porte l'archive. Sortie : file_0, file_1, file_2… sur un item unique.
3. Code pour éclater ces propriétés en un item par fichier — indispensable, car la plupart des nodes en aval (Extract from File, Google Drive, S3) ne traitent qu'une propriété binaire à la fois.
4. Traitement par fichier : un node Switch sur l'extension, puis Extract from File pour les CSV et XLSX (voir notre guide Excel et CSV dans n8n), un upload vers Google Drive pour les PDF, etc.

L'étape 3 tient en quelques lignes :

const bin = $input.first().binary;
return Object.keys(bin).map((key) => ({
  json: { fileName: bin[key].fileName },
  binary: { data: bin[key] },
}));

Une précaution utile : calculer un hash SHA256 de chaque fichier extrait avec le node Crypto permet de sauter les fichiers déjà traités lors d'une relivraison — les partenaires redéposent souvent la même archive deux fois.

Compresser un export avant archivage ou upload

Troisième usage : alléger un fichier avant de l'envoyer ailleurs. Export CSV, dump de logs, extraction de base — tout ce qui est texte se compresse fortement, et compresser avant un Put S3 réduit la facture de stockage comme le temps de transfert (pattern complet dans notre article sur l'archivage de fichiers vers S3 avec n8n). Même logique pour des workflows exportés en JSON avant push, sujet traité dans notre guide sur la sauvegarde et le versionnement des workflows n8n avec Git.

Le réflexe « compresser, c'est toujours gagnant » mérite une nuance. Kenneth C. Barr et Krste Asanović, dans « Energy-Aware Lossless Data Compression » (ACM Transactions on Computer Systems, 2006), ont mesuré l'énergie consommée par plusieurs compresseurs sans perte avant transmission sans fil et constaté qu'avec plusieurs outils courants le bilan est négatif : le coût CPU de la compression dépasse l'économie réalisée sur l'émission. Transposé à n8n, le principe tient : sur un fichier déjà compressé (PDF, JPEG, MP4) ou sur un petit fichier envoyé en réseau local, l'étape coûte de la RAM et du temps pour un gain nul. Réservez-la aux gros volumes de texte.

Le piège mémoire

Le node Compression charge tout en mémoire : pendant l'opération, le process n8n détient à la fois les fichiers sources et l'archive produite. Compresser un CSV de 500 Mo demande donc bien plus de 500 Mo de RAM disponible, et l'échec prend la forme du familier JavaScript heap out of memory, dont les causes sont détaillées dans notre article dédié à l'erreur heap out of memory dans n8n.

Trois mesures concrètes :

• Passer le stockage binaire en mode fichier (N8N_DEFAULT_BINARY_DATA_MODE=filesystem) pour que les données binaires ne transitent pas systématiquement dans la base d'exécutions — mécanique détaillée dans notre guide sur la gestion des fichiers volumineux et des données binaires n8n. Cela ne dispense pas de la mémoire nécessaire pendant la compression elle-même.
• Traiter les fichiers par petits lots avec un node Loop Over Items plutôt que d'agréger vingt pièces jointes sur un item avant de zipper.
• Relever NODE_OPTIONS=--max-old-space-size si les volumes sont structurellement gros, en gardant une marge par rapport à la RAM du conteneur.

Au-delà de quelques centaines de mégaoctets, un node Execute Command appelant zip, tar ou gzip reste plus sobre : le binaire système écrit sur disque au fil de l'eau au lieu de tout tenir en RAM. Cette option suppose un accès shell sur l'instance, donc pas de n8n Cloud.

Sécurité : une archive reçue n'est pas un fichier de confiance

Deux angles morts à traiter explicitement. Pas de mot de passe d'abord : le node n'expose aucun paramètre de chiffrement : il ne crée pas d'archive protégée et ne sait pas ouvrir celles qui le sont — un .zip chiffré fait simplement échouer l'opération Decompress. Pour transmettre des documents sensibles, chiffrez au niveau du transport (SFTP, lien signé à durée limitée) plutôt que de compter sur un mot de passe d'archive.

Un zip entrant est une entrée non fiable. Décompresser automatiquement une archive reçue par email revient à ouvrir du contenu tiers dans votre infrastructure. Le risque n'est pas théorique : David Fifield a montré dans « A Better Zip Bomb » (13e USENIX Workshop on Offensive Technologies, WOOT 2019) qu'une archive de 10 Mo, non récursive et parfaitement conforme au format, peut se déployer en 281 To après une seule décompression — de quoi saturer un worker n8n avec un fichier qui paraît anodin. Trois garde-fous :

• Un node IF sur fileSize avant le Decompress, et un plafond sur le nombre de propriétés produites après.
• Une allowlist d'expéditeurs ou d'extensions : le .zip reste un vecteur privilégié pour faire passer un exécutable à travers un filtre antivirus. Notre article sur la détection de phishing et de spam par IA dans n8n couvre le tri en amont.
• Un timeout d'exécution sur le workflow, pour qu'une décompression pathologique s'arrête d'elle-même.

En résumé

Le node Compression tient en deux opérations et cinq paramètres : Compress (Input Binary Field(s), Output Format, File Name, Put Output File in Field) et Decompress (Input Binary Field(s), Output Prefix). L'essentiel du travail se joue autour : rassembler plusieurs fichiers sur un même item avec des propriétés binaires distinctes avant de zipper, puis les ré-éclater en items après avoir dézippé. Restent trois limites — tout passe en mémoire, aucune gestion de mot de passe, et une archive venue de l'extérieur mérite une validation de taille et d'origine avant d'être ouverte.

Pour aller plus loin

Le Pack Inbox IA (79 €) enchaîne réception, tri et traitement des pièces jointes email, archives comprises. Pour les workflows où les fichiers extraits doivent être tracés et conservés dans les règles, le Pack Conformité & Audit (149 €) fournit la piste d'audit associée.