Automatiser les transferts SFTP et FTP avec n8n : fini les dépôts de fichiers à la main

On annonce sa mort depuis vingt ans, et pourtant : le fichier déposé sur un serveur SFTP reste le lingua franca des échanges B2B — catalogues fournisseurs, exports comptables, flux bancaires, interfaces avec des logiciels métier qui n'auront jamais d'API. Tant que ces transferts se font à la main (« tous les lundis, Karine récupère le fichier et l'importe »), ils concentrent un risque bien documenté : une étude de Liginlal, Sim et Khansa publiée en 2009 dans Computers & Security (« How significant is human error as a cause of privacy breaches? », voir sur Google Scholar) montre que l'erreur humaine est la cause principale des incidents de fuite de données analysés — fichier envoyé au mauvais destinataire, mauvaise version importée, oubli pur et simple. Automatiser ces flux avec n8n élimine précisément cette classe d'erreurs. Voici comment le faire proprement.

Le node FTP de n8n : un node, deux protocoles

Le node FTP de n8n parle FTP et SFTP — le choix se fait dans le crédentiel. En pratique, exigez le SFTP dès que possible (chiffrement de bout en bout), et privilégiez l'authentification par clé SSH : le crédentiel SFTP de n8n accepte une clé privée avec passphrase, plus sûre et plus révocable qu'un mot de passe. Comme tout secret, la clé vit exclusivement dans le gestionnaire de crédentiels — les réflexes de notre guide sur la sécurisation des crédentiels s'appliquent intégralement.

Cinq opérations couvrent tous les cas : List (lister un dossier distant), Download (récupérer en binaire), Upload (déposer), Rename (renommer ou déplacer) et Delete. Les fichiers transitent en données binaires entre nodes — pour les gros volumes, notre guide du binary data et des fichiers volumineux explique comment ne pas saturer la mémoire.

Pattern 1 : récupérer les dépôts d'un partenaire

Le SFTP ne notifie pas : on sonde. Le workflow type :

1. Schedule Trigger à l'intervalle adapté au flux (5 minutes pour des commandes, la nuit pour du comptable).
2. FTP – List sur le dossier de dépôt convenu.
3. Filtrage des nouveautés : comparaison avec la liste des fichiers déjà traités, tenue dans une Data Table (nom + taille + date). C'est l'équivalent fichier de l'idempotence des webhooks : sans ce garde-fou, un fichier retraité deux fois double les écritures en aval.
4. FTP – Download puis traitement : extraction du CSV ou de l'Excel, validation des colonnes attendues, injection en base ou dans l'application cible.
5. Archivage : Rename vers archive/AAAA-MM/, ou vers erreurs/ si le traitement a échoué.

Le piège spécifique au sondage : attraper un fichier en cours d'upload. Convenez avec l'émetteur d'un renommage final (dépôt en .tmp, renommage en .csv une fois complet) ou vérifiez la stabilité de la taille entre deux listages avant de télécharger.

Pattern 2 : déposer vos exports chez un partenaire

Dans l'autre sens — envoyer un état comptable à l'expert-comptable, un catalogue à une marketplace, un fichier de virements à la banque — le workflow s'inverse : génération du fichier (un export Excel ou CSV, un PDF de facturation), puis FTP – Upload vers le dossier convenu, sous nom temporaire renommé à la fin si le partenaire sonde de son côté.

Ajoutez systématiquement une preuve de dépôt : après l'upload, un List de contrôle vérifie la présence et la taille du fichier, et le résultat est journalisé (Data Table, ou message dans un canal Slack d'exploitation). Le jour où le partenaire affirme n'avoir rien reçu, cette trace vaut de l'or.

Le cas concret : le fichier de stock fournisseur

L'exemple canonique combine les deux patterns : chaque nuit, le fournisseur dépose son fichier de stock ; n8n le récupère, valide son format, met à jour les niveaux — le flux détaillé dans notre guide de la synchronisation des stocks Shopify — puis archive le fichier et journalise le résultat. Vingt minutes de clics hebdomadaires deviennent un workflow qui tourne à 3 h du matin et alerte quand quelque chose cloche.

Fiabilité : ce qui distingue la production du bricolage

• Retries et timeouts : les serveurs SFTP de partenaires tombent, redémarrent, saturent. Activez les retries du node avec un délai entre tentatives, comme pour n'importe quelle requête HTTP fragile.
• Error Workflow : un transfert qui échoue à 3 h du matin doit produire une alerte à 3 h 01, pas une découverte à 9 h 30.
• Validation avant intégration : un fichier présent n'est pas un fichier correct. Vérifiez colonnes, encodage et volumétrie plausible avant d'écrire quoi que ce soit ; en cas de doute, dossier d'erreur et alerte.
• Environnements : hôtes, chemins et noms de dossiers appartiennent aux variables d'environnement, pas au workflow — indispensable pour la séparation dev/prod.

Un flux SFTP automatisé avec ces garde-fous est ennuyeux au sens noble : il tourne des mois sans qu'on y pense, et c'est très exactement ce qu'on demande à un échange de fichiers.