Outils de transfert de fichiers Linux : options CLI et web

Sur Linux, le meilleur outil de transfert dépend de la situation : déplacer des fichiers entre vos propres machines (rsync, scp, sftp) ou envoyer à quelqu'un hors de votre contrôle (services web comme HexaTransfer). Pour les copies en masse serveur-à-serveur, rsync -avP --partial est l'outil de référence. Pour une livraison ponctuelle à un destinataire non technique, une URL issue d'un service web vaut mieux que lui demander d'installer un client SSH. Les environnements de bureau Linux (GNOME, KDE) gèrent aussi nativement SMB, WebDAV et SFTP via le gestionnaire de fichiers.

Les classiques en ligne de commande

scp — copie sécurisée via SSH. Simple et direct :

scp bigfile.tar.gz user@server:/home/user/
scp -r folder/ user@server:/path/

Pas de reprise en cas d'échec. Fiable sur des réseaux stables, pénible sur des connexions instables. OpenSSH 9.0 (2022) a basculé le protocole par défaut de SCP-sur-SSH vers SFTP — le comportement est similaire mais les cas limites diffèrent.

rsync — synchronisation incrémentale avec reprise :

rsync -avP --partial source/ user@server:/dest/

Flags : -a mode archive (préserve permissions, dates, liens symboliques), -v verbeux, -P progression + --partial (conserve le fichier partiel en cas d'échec). --bwlimit=50000 plafonne la bande passante à 50 Mo/s sur une liaison partagée.

Pour des racines source et destination identiques, rsync ne transfère que les octets modifiés lors des exécutions suivantes — un gain de temps considérable sur les transferts répétés.

sftp — transfert de fichiers interactif en SSH. S'utilise comme un client FTP classique :

sftp user@server
> put bigfile.tar.gz
> get somefile.txt

rclone — comme rsync mais pour les fournisseurs cloud. Compatible S3, Google Drive, Dropbox, OneDrive, Backblaze B2 et des dizaines d'autres. Idéal pour les uploads scriptés vers du stockage objet :

rclone copy local/folder remote:bucket/path -P

Options web pour les destinataires non techniques

Tous les destinataires n'ont pas de clés SSH. Pour envoyer à des journalistes, clients ou proches, une URL de service de transfert est ce qui fonctionne :

| Service | Max gratuit | Chiffrement | Compatible Linux | |---|---|---|---| | HexaTransfer | 10 Go | Bout en bout AES-256-GCM | Oui (tout navigateur) | | WeTransfer | 2 Go | TLS | Oui | | SwissTransfer | 50 Go | TLS | Oui | | Proton Drive Share | 1 Go | Bout en bout | Oui | | Tresorit Send | 5 Go | Bout en bout | Oui |

Firefox et Chromium sur Linux gèrent tous les deux les gros uploads sans difficulté. Les performances dépendent généralement du matériel et du débit montant, pas du navigateur.

Outils réseau local depuis le bureau

GNOME Fichiers (Nautilus) : Se connecter au serveur > smb://, sftp://, ftp://, dav://. Monte le volume distant comme s'il était local. Pratique pour une navigation occasionnelle.

KDE Dolphin : même fonctionnalité, interface légèrement différente. Prend en charge les mêmes protocoles.

smbclient — SMB en ligne de commande pour les scripts :

smbclient //server/share -U user

sshfs — montez un système de fichiers distant via SSH :

sshfs user@server:/remote/path ~/mnt/remote

Utile quand une application attend un chemin local.

Optimisation des vitesses de transfert sur Linux

Le scaling de fenêtre TCP par défaut de Linux gère bien les transferts haut débit, mais certaines distributions embarquent des réglages conservateurs. Pour des transferts sur liaisons longue distance (latence élevée, débit élevé) :

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

Activez le contrôle de congestion BBR pour un meilleur débit sur les liaisons avec perte :

sysctl -w net.ipv4.tcp_congestion_control=bbr

Ces réglages sont inutiles sur un réseau domestique ordinaire — mais si vous déplacez des données entre datacenters ou entre continents, la différence entre CUBIC par défaut et BBR peut atteindre un facteur 2 à 3.

Archivage : variantes de tar

tar -czf archive.tar.gz folder/          # gzip, rapide, compression modérée
tar -cjf archive.tar.bz2 folder/         # bzip2, plus lent, meilleure compression
tar -cJf archive.tar.xz folder/          # xz, le plus lent, meilleure compression
tar --use-compress-program=zstd -cf archive.tar.zst folder/   # zstd, rapide et bon ratio

Pour un système Linux moderne, zstd surpasse gzip en vitesse comme en ratio de compression. Pour distribuer à des destinataires non-Linux, restez sur .zip — utilisez zip -r archive.zip folder/.

Pour fractionner une archive volumineuse en morceaux :

tar -czf - folder/ | split -b 2G - archive.tar.gz.part_

Réassemblez avec cat archive.tar.gz.part_* | tar -xzf -.

Le stockage objet comme couche de transfert

Pour les charges qui génèrent de nombreux fichiers ou des fichiers très volumineux, utiliser un bucket cloud comme couche de transfert est plus propre qu'un service ponctuel :

AWS S3 : aws s3 cp fichier s3://bucket/chemin puis générez une URL pré-signée avec aws s3 presign s3://bucket/chemin --expires-in 3600. Le destinataire obtient un téléchargement direct limité dans le temps.

Cloudflare R2 : API compatible S3, sans frais d'egress. Utilisez la même CLI aws avec un endpoint personnalisé.

Backblaze B2 : b2 upload-file bucket fichier cle puis b2 get-download-url-with-auth bucket cle 3600.

MinIO : auto-hébergez un serveur compatible S3, émettez des URL pré-signées depuis votre propre domaine.

Pour les développeurs qui envoient des artefacts de build, des logs ou des dumps, ces solutions surpassent un service de transfert généraliste.

Serveurs HTTP ad-hoc

Pour les transferts rapides sur le même réseau local :

python3 -m http.server 8000

Sert le répertoire courant sur http://votre-ip:8000/. Le destinataire ouvre l'URL et télécharge. Utile entre votre ordinateur portable et une VM ou un téléphone sur le même Wi-Fi. Non chiffré — acceptable en interne, déconseillé en externe.

Pour du HTTPS avec un certificat auto-signé :

python3 -c "import http.server, ssl; httpd = http.server.HTTPServer(('0.0.0.0', 8443), http.server.SimpleHTTPRequestHandler); httpd.socket = ssl.wrap_socket(httpd.socket, certfile='cert.pem', server_side=True); httpd.serve_forever()"

caddy file-server le fait proprement avec HTTPS automatique si vous disposez d'un vrai domaine.

Outils pair-à-pair

Magic Wormhole (wormhole) :

wormhole send bigfile.tar.gz
# affiche un code du type 7-crossover-clockwork
# le destinataire lance : wormhole receive 7-crossover-clockwork

Chiffré de bout en bout, traverse les NAT via un serveur de rendez-vous. Parfait pour des transferts directs ponctuels.

croc (de schollz) : similaire à wormhole, binaire unique, multiplateforme. Populaire dans la communauté homelab.

Ces outils sont pair-à-pair mais transitent tout de même par des serveurs de rendez-vous pour la traversée NAT — le chiffrement est de bout en bout, mais le chemin n'est pas direct.

Chiffrement au repos avant l'upload

Pour les workflows qui exigent le maximum de précaution, chiffrez l'archive avant de la passer par n'importe quel service :

gpg --symmetric --cipher-algo AES256 bigfile.tar.gz

Produit bigfile.tar.gz.gpg. Le destinataire déchiffre avec gpg --decrypt. Partagez la passphrase via un canal séparé.

Ou utilisez age, une alternative moderne :

age -p -o encrypted.age plaintext.tar.gz

Avec des services de transfert chiffrés de bout en bout comme HexaTransfer, ce double emballage est généralement superflu — mais pour des modèles de menace au niveau étatique, la redondance de sécurité reste pertinente.

Essayez sur hexatransfer.com — fonctionne depuis n'importe quel navigateur Linux. Gratuit, sans compte, jusqu'à 10 Go.