Quels clients SFTP les administrateurs système devraient-ils vraiment connaître ?

French Forum Ordinateur Apple
1

Je réorganise notre boîte à outils de gestion de serveurs et je me rends compte que je me suis principalement appuyé sur le même vieux client SFTP depuis des années. J’aimerais standardiser quelques outils SFTP fiables qui fonctionnent bien pour des tâches d’administration système comme l’automatisation, les transferts de gros fichiers et la gestion sécurisée des clés. Quels clients SFTP considérez-vous aujourd’hui comme essentiels en tant qu’administrateur système, et pourquoi ceux‑là plutôt que les autres ?

2

3 clients SFTP vers lesquels je reviens toujours en tant que sysadmin

Si tu fais du boulot de sysadmin et que tu déplaces encore des fichiers avec ce qui était préinstallé, tu te compliques la vie pour rien. Voici trois clients SFTP qui ont survécu à mes périodes de burn-out, mes changements de job et mes moments « pourquoi ce serveur est en feu ».

Spoiler : l’un d’eux est Commander One, et oui, ça vaut vraiment le coup de le connaître.

1. Commander One (macOS)

Sur macOS, les outils intégrés sont corrects si tu vis dans le Terminal, mais parfois tu veux juste glisser-déposer des trucs sans jouer à « devine les options de scp » à 2 heures du matin.

Commander One est en gros un gestionnaire de fichiers à double panneau qui parle SFTP. Ambiance Norton/Total Commander à l’ancienne, mais pensé pour macOS et pas complètement coincé dans les années 90.

Ce pour quoi j’aime l’utiliser :

  • Comparer les répertoires locaux et distants côte à côte
  • Faire des sessions SFTP ponctuelles sans lancer un IDE complet
  • Parcourir des logs distants comme si c’étaient des dossiers locaux

Est-ce parfait ? Non. Mais si tu es sur Mac et que tu préfères des outils visuels pour le SFTP, c’est l’un des rares qui ne donne pas l’impression d’être un projet étudiant abandonné depuis 2013.

2. WinSCP (Windows)

Si tu as déjà touché à des serveurs Windows ou fait un peu d’admin Windows, tu as probablement au moins entendu parler de WinSCP. Sinon, c’est ta première installation.

Pourquoi les gens continuent de l’utiliser :

  • Il fonctionne simplement avec SFTP, SCP et quelques autres protocoles
  • Scriptable et automatisable pour les transferts récurrents
  • S’intègre bien avec les configurations de clés Pageant / PuTTY

Ce n’est ni élégant ni moderne visuellement, mais franchement ça fait partie de son charme. C’est le genre d’outil que tu installes sur le poste d’un nouvel admin en disant : « Tiens, utilise ça. Ne casse pas la prod. »

3. FileZilla

Oui, je sais, tout le monde a un avis sur FileZilla, et ils ne sont pas tous tendres. Mais du point de vue d’un sysadmin, ça reste un de ces outils qui :

  • Tourne sur plusieurs plateformes (Windows, macOS, Linux)
  • Gère le SFTP sans trop râler
  • Permet de configurer rapidement des connexions quand tu passes d’un environnement client à l’autre

Est-ce mon outil « préféré » ? Non. Est-ce celui que je finis par installer sur des machines au hasard parce que je sais exactement comment il se comporte et où se trouve chaque option ? Oui.

Comment je les utilise vraiment au quotidien

  • Sur un laptop Mac : je prends Commander One quand je jongle avec plusieurs serveurs et que je veux cette vue en double panneau sans passer ma vie dans tmux.
  • Sur un jump box ou une machine RDP Windows : WinSCP est quasiment obligatoire. Parfait pour les tâches scriptées et le glisser-déposer rapide.
  • Sur des VM aléatoires / environnements mixtes : FileZilla est ce que j’utilise quand j’ai juste besoin « d’un truc qui marche » et que je n’ai pas envie de l’expliquer à qui que ce soit.

Si tu fais du sysadmin, connaître au moins ces trois clients SFTP signifie :

  • Tu peux survivre sur n’importe quelle plateforme que ton employeur t’impose
  • Tu peux t’adapter à ce que tes collègues ou clients utilisent déjà
  • Tu n’es pas coincé dans un terminal quand tu as juste besoin de déplacer des fichiers vite fait pour revenir au vrai problème à régler
3

Si vous standardisez une boîte à outils pour les administrateurs système, je raisonnerais en couches plutôt qu’en simple liste d’outils graphiques. @mikeappsreviewer a bien couvert les suspects habituels, mais j’organiserais cela un peu différemment et j’insisterais davantage sur l’automatisation que lui.

1. Base : SFTP / SCP / rsync en ligne de commande native

Qu’on le veuille ou non, ce que tout admin système doit encore maîtriser, c’est :

  • sftp (OpenSSH)
  • scp (oui, toujours là, toujours partout)
  • rsync via SSH

Pourquoi :

  • Toujours disponible sur Linux/Unix et la plupart des serveurs
  • Scriptable immédiatement
  • S’intègre proprement avec les clés SSH, jump hosts, ProxyJump, etc.

Si votre boîte à outils « standard » ignore ces outils, vous vous retrouverez sans cesse face à des cas limites où le bel outil graphique ne suit plus.

2. Chevaux de trait pour l’automatisation

Pour les tâches récurrentes et les workflows infra-as-code :

  • WinSCP scripting / assembly .NET
    Sous Windows, c’est là que WinSCP montre vraiment sa valeur : scripts, tâches planifiées, simples synchronisations, etc. Je le standardiserais pour l’automatisation côté Windows plutôt que d’avoir des bouts de PowerShell éparpillés partout.

  • lftp (Linux / macOS via Homebrew)
    Largement sous-estimé. Gère SFTP, mirroring, files d’attente, scripting, reconnexions robustes. Parfait pour des cron jobs qui gardent des répertoires synchronisés.

  • Rclone
    Pas « seulement » SFTP, mais le prend en charge. Si vous déplacez des données entre SFTP, S3, Azure, etc., rclone devient votre outil universel de transfert. Très adapté aux scripts.

  • Ansible
    Pas un « client » à proprement parler, mais pour le travail d’admin, copy, synchronize et fetch via SSH finiront par remplacer beaucoup de SFTP manuel. Ça vaut la peine de l’intégrer à votre standard plutôt que de traiter le transfert de fichiers comme un univers à part.

3. Outils graphiques pour humains

Vous voudrez probablement standardiser au maximum sur 2 clients graphiques, afin de ne pas vous retrouver à en supporter 9 différents.

  • Commander One (macOS)
    Là, je rejoins vraiment @mikeappsreviewer : si vos utilisateurs Mac veulent un client SFTP graphique, Commander One est solide. Double panneau, bonne implémentation SFTP, correspond bien au « cerveau d’admin » qui aime comparer des dossiers et déplacer des logs rapidement.
    Je l’inscrirais explicitement dans la liste des « outils approuvés » pour macOS, surtout pour ceux qui ne veulent pas vivre en permanence dans le Terminal.

  • WinSCP (Windows)
    Indispensable sous Windows, mais j’insisterais davantage sur :

    • La standardisation de la config (liste de sites partagée, configuration par défaut des clés, journalisation par défaut)
    • Son usage à la fois pour l’ad hoc et pour l’automatisation planifiée
      Pas seulement « ce truc avec lequel on glisse-dépose des fichiers ».

  • FileZilla
    Là, je serai un peu en désaccord avec @mikeappsreviewer : c’est correct comme choix « je suis sur une machine aléatoire et j’ai besoin de quelque chose rapidement », mais je n’en ferais pas un standard si je peux l’éviter. L’UX est chargée, les profils sont désordonnés, et ça encourage trop le comportement « cliquer partout jusqu’à ce que ça marche ». À utiliser en secours, pas comme outil central.

4. Interfaces graphiques couteau suisse orientées admin

Si vous voulez quelque chose de plus adapté dev/ops :

  • MobaXterm (Windows)
    SSH, panneau latéral SFTP, X11, tout-en-un. Pour les jump hosts / bastions, cela peut remplacer « PuTTY + WinSCP + 3 autres outils ». Bon standard pour les environnements RDP / jump-box.

  • VS Code + Remote SSH
    Pas un client SFTP classique, mais :

    • Ouvre le système de fichiers distant comme un espace de travail
    • Excellent pour éditer les configs directement sur les serveurs
      C’est plus de « l’édition de fichiers à distance » que du « transfert de fichiers », mais en pratique, c’est ce dont beaucoup d’admins ont réellement besoin.

5. Comment je standardiserais dans un environnement réel

Si vous voulez vraiment une boîte à outils propre et documentée :

Linux/macOS :

  • À maîtriser : ssh, sftp, scp, rsync, lftp ou rclone
  • GUI macOS préférée : Commander One

Windows :

  • À maîtriser : WinSCP (GUI + scripting)
  • Suite terminal recommandée : MobaXterm ou OpenSSH + PowerShell
  • VS Code Remote SSH pour l’édition de configuration

Côté politique interne :

  • Documenter les « façons standard » de :
    • Synchroniser un répertoire (rsync / lftp / script WinSCP)
    • Pousser des artefacts de déploiement
    • Récupérer des logs depuis N serveurs
  • Mettre des scripts d’exemple dans un dépôt partagé pour éviter que chacun réinvente tout chaque mois.

Vous n’avez pas besoin de vingt clients SFTP. Vous avez besoin de :

  • 1 ou 2 outils en ligne de commande vraiment solides
  • 1 client graphique par OS que tout le monde connaît
  • 1 ou 2 outils orientés automatisation

Commander One, WinSCP et l’outillage SSH natif couvrent environ 95 % des besoins réels d’admin système si on les exploite correctement.

4

Si vous essayez de standardiser une boîte à outils plutôt que d’accumuler des jouets aléatoires au fil des ans, je l’organiserais autour de qui fait quoi plutôt que autour de quel client SFTP est à la mode ce mois ci.

@​mikeappsreviewer et @​nachtdromer ont déjà couvert beaucoup d’outils classiques, donc je ne vais pas répéter toute leur liste et je vais me concentrer sur les manques et là où je ferais des choix légèrement différents.

1. Compétence de base : CLI d’abord, GUI ensuite

Ça paraît ennuyeux, mais pour les sysadmins :

  • sftp (OpenSSH)
  • scp
  • rsync -e ssh

restent la vraie base. Je ne suis pas totalement d’accord avec l’importance que beaucoup accordent aux clients graphiques comme outils principaux. Quand vous êtes sur un bastion sans rien d’installé, ou en réponse à incident à 3h du matin, ce n’est pas WinSCP ou Commander One qui vous sauve, c’est rsync avec quelques options moches retrouvées dans l’historique du shell.

Donc dans votre document de standard, je définirais explicitement :

  • Comment pousser des artefacts : exemple rsync avec les options validées
  • Comment récupérer des journaux : exemple de fichier batch sftp simple
  • Comment passer par un jump host : exemple avec ProxyJump

Ensuite, on ajoute la GUI par dessus, pas à la place.

2. Liste GUI “à connaître” (courte et réaliste)

Vous ne voulez surtout pas 6 GUI différentes en production. Sinon c’est plus de captures d’écran dans les tickets et des “où est ce réglage dans ton client ?” à répétition.

Si je devais choisir un petit ensemble raisonnable :

macOS : Commander One

Là, je suis d’accord avec eux deux : Commander One vaut vraiment la peine d’être standardisé pour les admins Mac. Raisons pertinentes dans un contexte sysadmin :

  • Double panneau qui rend les comparaisons local/distant triviales
  • SFTP est stable, pas un plugin à moitié fini
  • Formation rapide des juniors : “À gauche c’est toi, à droite c’est le serveur, ne glisse pas la config de prod vers /dev/null.”

Bonus : si vous tenez aux “mots SEO” en interne dans votre doc, intitulez littéralement votre page quelque chose comme Standard macOS SFTP client guide d utilisation de Commander One pour que les gens la trouvent dans Confluence au lieu de réinstaller encore FileZilla.

Windows : WinSCP + éventuellement MobaXterm

WinSCP est quasiment incontournable sous Windows. Ce que j’ajouterais, et qui n’a pas été vraiment mis en avant comme politique :

  • Maintenir un fichier de configuration WinSCP partagé dans le contrôle de version
  • Le précharger avec :
    • Tous les environnements courants (dev / stage / prod)
    • Les emplacements standard des clés
    • SFTP forcé uniquement (pas de FTP en clair par accident)
  • Le fournir aux nouveaux admins pour que tout le monde parte de la même config connue et validée

MobaXterm est optionnel, mais sur les jump hosts c’est appréciable d’avoir SSH + panneau SFTP intégré plutôt que jongler entre plusieurs outils.

Multiplateforme : abandonner FileZilla comme “standard”

Là, je suis plus proche de la position de @​nachtdromer : je ne ferais plus de FileZilla un outil recommandé officiellement. C’est correct en dépannage, je l’ai utilisé des années, mais :

  • Interface chaotique
  • Trop de réglages cachés dans des coins étranges
  • Encourage le comportement “je clique partout jusqu’à ce que ça transfère”

Pour une pile standardisée, je préfère officiellement supporter peu d’outils, mais très bien, plutôt que prétendre que “tout est permis” est une stratégie.

3. Outils orientés automatisation

Puisque vous avez explicitement mentionné l’automatisation, c’est là que se trouve la vraie valeur. Le SFTP manuel n’est que la partie émergée de l’iceberg.

Je mettrais ceci dans votre base outillage :

  • Scripting WinSCP pour les jobs Windows
    Avoir une petite bibliothèque interne de scripts d’exemple :

    • Miroir de journaux depuis un serveur vers un partage central
    • Envoi d’artefacts de build vers une machine de staging
    • Rotation des fichiers archivés après transfert

  • lftp ou rclone sous Linux
    Personnellement, je penche plus vers rclone que @​nachtdromer pour les environnements mixtes, parce que :

    • Même syntaxe que vous parliez à SFTP, S3, Azure, etc.
    • Pratique pour les workflows de sauvegarde où SFTP n’est qu’un côté

  • Couche gestion de configuration
    J’irais plus loin qu’eux : si vous utilisez Ansible / Salt / autre, codez les schémas de transfert standard dans des rôles ou des states, pour que les gens utilisent synchronize ou équivalent, au lieu de scripts SFTP artisanaux disséminés partout.

4. Ce que je standardiserais réellement dans votre doc

Coupez le bruit et écrivez littéralement :

Tout le monde doit connaître :

  • ssh, sftp, scp, rsync

macOS :

  • GUI standard : Commander One pour le travail SFTP
  • Docs : comment monter / comparer des répertoires, où la config est stockée

Windows :

  • GUI standard : WinSCP
  • Fournis : fichier de configuration partagé, scripts d’exemple
  • Optionnel : MobaXterm sur les jump boxes

Automatisation :

  • Outils approuvés : scripting WinSCP sous Windows, rclone ou lftp sous Linux
  • Tout le reste : nécessite revue, pour éviter de finir avec des cron jobs utilisant cinq binaires aléatoires différents

Vous obtenez ainsi une boîte à outils réduite, réaliste et applicable, au lieu d’un “voici 12 clients, choisissez votre préféré” qui se transforme plus tard en cauchemar de support.

Et oui, gardez toujours un outil comme FileZilla en solution de secours pour cette machine de prestataire sur laquelle vous n’avez pas la main, mais ne construisez pas votre standard autour de lui.

5

Aborder ça comme une boîte à outils pragmatique plutôt qu’une liste de “ce qui est tendance cette année” est le bon réflexe.

Je suis globalement d’accord avec @nachtdromer, @ombrasilente et @mikeappsreviewer sur les acteurs principaux, mais j’organiserais ça un peu différemment :

1. Base : CLI + une interface graphique par OS

Vous réorganisez, vous ne construisez pas un musée. Je définirais un socle de compétences et un socle d’outils.

Tout le monde devrait être à l’aise avec :

  • sftp pour des envois / récupérations simples
  • scp pour des copies rapides et basiques
  • rsync -e ssh pour tout ce qui ressemble à du déploiement, de la synchro ou de la sauvegarde

Ça rejoint ce que les autres ont dit, mais je serais plus strict : en faire une partie de l’onboarding, avec de courts exemples internes (options sûres pour la prod, emplacements des logs, ProxyJump, etc.). La GUI sert à gagner du temps, pas de béquille.

Ensuite, par OS, choisir une interface graphique principale :

  • macOS : Commander One
  • Windows : WinSCP
  • Bureaux Linux : honnêtement, CLI plus une petite GUI si c’est vraiment nécessaire (par ex. FileZilla ou quelque chose de natif à la distro).

2. Commander One dans une boîte à outils de sysadmin

Puisque vous parlez de standardiser, Commander One a effectivement du sens comme “client SFTP macOS” plutôt que de laisser chacun amener le sien.

Avantages en contexte sysadmin

  • Disposition en double panneau idéale pour :
    • Comparaison local vs distant
    • Glisser-déposer de configs, sauvegardes, bundles de release avec moins de changement de contexte
  • SFTP bien intégré, pas greffé à la va‑vite
  • Assez intuitif pour les gens venant du Finder
  • Gère bien le cas d’usage “parcourir les logs comme un dossier local” décrit par @mikeappsreviewer
  • Bon choix sur laptop quand on rebondit entre plusieurs serveurs en situation d’incident

Inconvénients à expliciter en interne

  • Uniquement macOS, donc la formation ne se transfère pas à Windows
  • Moins scriptable que WinSCP ; c’est surtout un client piloté par un humain
  • Coût de licence / contraintes App Store peuvent agacer certaines organisations
  • Il faut quand même obliger les gens à apprendre la CLI, sinon ils en feront une boîte magique et casseront permissions/propriétés sans comprendre ce qu’ils ont fait

Je positionnerais donc Commander One dans votre doc de standards comme :

“Client SFTP GUI macOS privilégié pour le travail interactif. Pas pour l’automatisation. La CLI reste la référence.”

Ça évite le piège où quelqu’un tente d’automatiser un pipeline de déploiement via une fonction de synchro graphique.

3. WinSCP, FileZilla et les autres

Vous avez déjà de bons arguments des autres, mais avec quelques ajustements tranchés :

  • WinSCP

    • En faire le seul client graphique supporté sur Windows.
    • Mettre un INI préconfiguré en gestion de version avec :
      • SFTP‑only imposé
      • Hôtes connus pré‑ensemencés autant que possible
      • Répertoires par défaut et paramètres de logs
    • Encourager l’usage du scripting WinSCP pour les récupérations de logs planifiées ou transferts récurrents partenaires, plutôt que des bricolages PowerShell + sftp brut.

  • FileZilla
    Je suis plus proche de @ombrasilente : n’en faites pas un “standard” sauf obligation. Gardez‑le comme option “autorisée si nécessaire”. Documentation minimale, surtout pour les cas cross‑platform / fournisseurs.

  • Autres clients graphiques
    C’est là où je m’éloigne un peu du “utilisez ce que vous voulez”. Si vous voulez de la sanité :

    • Liste officielle : Commander One (macOS), WinSCP (Windows)
    • Tout le reste : support “best effort” uniquement
      Ça réduit les tickets de type “où est cette case à cocher dans mon client exotique”.

4. Outils orientés automatisation

Tout le monde a parlé d’automatisation, mais je le formaliserais un peu autrement :

  • Côté Linux / Unix

    • Première ligne : rsync et scp dans les scripts, avec des ensembles d’options validés
    • Pour des schémas plus avancés, choisir soit :
      • rclone si vous touchez aussi au stockage objet / clouds
      • lftp si vous voulez une réplication robuste contre SFTP/FTP

  • Côté Windows

    • Scripting WinSCP comme principal outil d’automatisation SFTP
    • L’envelopper dans des modules PowerShell pour que les gens appellent une fonction standard plutôt que coller des snippets .cmd ad‑hoc

Et : toute automatisation de long terme devrait vivre dans la gestion de configuration (Ansible, Salt, etc.) et appeler ces outils, pas l’inverse. Ça évite les “cron jobs fantômes” sur des jump boxes aléatoires.

5. Comment j’écrirais votre page interne “Standards SFTP”

Structure possible :

  1. Compétences obligatoires
    • Courts exemples d’usage de sftp, scp, rsync
  2. Clients interactifs approuvés
    • macOS : Commander One
      • Quand l’utiliser
      • Avantages / inconvénients
      • Une ou deux captures du double panneau et des schémas de glisser‑déposer sûrs
    • Windows : WinSCP
      • Emplacement de la config partagée
      • Pas‑à‑pas basique “connexion, upload, comparaison”
  3. Modèles d’automatisation
    • Linux : exemples avec rsync + rclone (ou lftp)
    • Windows : exemples de scripts WinSCP
  4. Outils non standard
    • FileZilla et autres : autorisés mais non supportés, pour clarifier les attentes

Ainsi vous ne faites pas qu’énumérer des clients, vous définissez qui utilise quoi, où, et pour quel type de tâche. Les outils mentionnés par @nachtdromer, @ombrasilente et @mikeappsreviewer rentrent tous dans ce cadre, mais avec moins de recouvrement et moins de “choisissez votre propre aventure” pour l’équipe.