Transférer des fichiers, c’est banal. Jusqu’au jour où ça ne l’est plus.
Un backup qui n’arrive pas au bon endroit. Un site en prod où tu uploades un fichier au mauvais moment. Un serveur distant sur un Wi-Fi douteux. Ou pire, une archive client qui traîne en clair.
Du coup, très vite, la question arrive : tu choisis SFTP ou rsync pour faire ça proprement, sans te tirer une balle dans le pied.
Les deux sont excellents. Mais pas pour les mêmes raisons, pas pour les mêmes usages, et pas avec le même niveau de confort au quotidien.
Dans cet article, je vais te donner une comparaison honnête, très terrain, avec des exemples de commandes, des pièges, et quelques choix simples. Et si tu aimes ce genre de contenu SysAdmin ou Linux, je te recommande de jeter un œil à ce blog, qui regorge de ressources utiles sur ces sujets.
Image : schéma rapide des deux approches
Image indicative autour de SSH, parce que SFTP et rsync en remote passent très souvent par SSH.
SFTP et rsync : de quoi parle-t-on vraiment
SFTP : un transfert « fichier par fichier » via SSH
SFTP veut dire SSH File Transfer Protocol. En clair : c’est un protocole de transfert de fichiers qui passe dans un tunnel SSH. Donc chiffré, authentifié, assez standard.
Tu l’utilises :
- en ligne de commande avec
sftp - via un client graphique (FileZilla, WinSCP, Cyberduck)
- via des libs dans plein de langages
L’idée est simple : tu push ou pull des fichiers, comme tu le ferais en FTP, mais sans le côté « années 90 ».
Pour optimiser l'utilisation de ces outils dans un environnement Linux, il peut être intéressant d'explorer les différentes distributions Linux disponibles ou encore les certifications Linux qui peuvent renforcer tes compétences dans ce domaine.
rsync : une synchro intelligente (delta), souvent via SSH
rsync, lui, n’est pas un protocole à la base. C’est un outil de synchronisation. Son super pouvoir : il ne renvoie pas tout à chaque fois.
Il compare, calcule des différences (delta), et ne transfère que ce qui change. Et ça, quand tu gères des gros dossiers, des sites web, des backups incrémentaux, ça devient vite indispensable.
Rsync peut passer :
- en local
- via SSH (le plus courant)
- via le daemon rsync (possible, mais moins « safe by default » si mal configuré)
Le point sécurité : les deux peuvent être « sûrs », mais pas pareil
SFTP : sécurité simple, surface d’attaque réduite
SFTP repose sur SSH. Donc tu profites :
- du chiffrement en transit
- de l’authentification par clé
- de la possibilité de restreindre des comptes (chroot, restrictions, etc.)
C’est généralement « propre » et facile à expliquer à un client ou une équipe : « on transfère en SFTP, c’est dans SSH ».
rsync : dépend surtout de la manière dont tu le fais
Rsync via SSH est très sûr aussi. En pratique :
rsync -e sshoursync(qui utilise SSH par défaut dans beaucoup de cas)- mêmes avantages : chiffrement, clés, bastion, etc.
Là où ça se complique un peu :
- si tu actives un daemon rsync ouvert sur le réseau, il faut bien gérer auth, ACL, firewall, logs
- certaines options rsync sont puissantes, donc dangereuses si tu les lances sans comprendre
Donc oui, rsync peut être aussi sûr que SFTP. Mais tu peux plus facilement te faire mal si tu copies colles une commande trouvée vite fait.
Cas d’usage : quand SFTP est le meilleur choix
1) Tu veux un outil universel, y compris pour des non techniques
Si tu dois donner un accès à quelqu’un qui veut juste déposer ou récupérer un fichier, SFTP est parfait.
- WinSCP côté Windows
- Cyberduck côté macOS
- FileZilla partout
Et tu peux créer un utilisateur SSH limité au SFTP.
2) Tu fais des transferts ponctuels
Un export, une archive, un fichier de config. Pas une synchro régulière de 60 Go.
SFTP est très bien pour ça. Simple.
3) Tu veux naviguer, lister, renommer à distance
SFTP te donne des commandes interactives :
ls,cd,put,get,mkdir, etc.
Ça ressemble à un mini shell dédié aux fichiers. Pratique.
Cas d’usage : quand rsync est le meilleur choix
1) Tu fais des backups réguliers, incrémentaux, et tu veux gagner du temps
Rsync est littéralement fait pour ça.
Tu sync un dossier de site web tous les soirs, par exemple. Le premier run copie tout, puis ensuite ça transfère juste les fichiers modifiés.
2) Tu as beaucoup de fichiers, et la latence te tue
Sur des dizaines de milliers de petits fichiers, SFTP peut être lent. Rsync est souvent plus efficace, surtout bien paramétré.
3) Tu veux garder les permissions, dates, liens, owners
Rsync est très fort pour conserver la structure et les métadonnées.
Exemples concrets : commandes SFTP propres
Connexion avec une clé
bash sftp -i ~/.ssh/id_ed25519 user@serveur.example.com
Une fois dedans :
text sftp> ls sftp> cd /var/www sftp> put fichier.zip sftp> get backup.tar.gz
Transfert direct sans shell interactif
bash sftp user@serveur.example.com:/var/www << 'EOF' put index.html put -r assets EOF
Ce n’est pas toujours le plus ergonomique, mais c’est scriptable.
Exemples concrets : commandes rsync utiles (et pas trop risquées)
Sync local vers serveur (cas classique déploiement)
bash rsync -avz ./site/ user@serveur.example.com:/var/www/site/
-a: archive (permissions, dates, etc.)-v: verbeux-z: compression (utile sur réseau lent)
Important : le slash change tout
Ces deux commandes ne font pas exactement la même chose :
bash rsync -av ./site user@serveur:/var/www/
vs
bash rsync -av ./site/ user@serveur:/var/www/site/
Le premier copie le dossier site dans /var/www/. Le second copie le contenu de site/ dans la cible.
C’est un détail, mais c’est un détail qui casse des nuits.
Faire un miroir propre (suppression côté destination)
bash rsync -av --delete ./site/ user@serveur:/var/www/site/
--delete supprime sur la destination ce qui n’existe plus en source. C’est utile pour un vrai miroir, mais c’est aussi l’option qui fait peur. Teste d’abord avec --dry-run.
Mode simulation pour éviter les catastrophes
bash rsync -av --delete --dry-run ./site/ user@serveur:/var/www/site/
Tu regardes la sortie. Tu respires. Puis tu enlèves --dry-run.
Image : rsync en pratique
Ok ce n’est pas une capture rsync, mais l’idée est là : rsync se vit souvent au terminal, en script, en cron.
Performances : rsync gagne souvent, mais pas toujours
rsync est imbattable si…
- tu synchronises souvent les mêmes dossiers
- tu as des dossiers énormes avec peu de changements
- tu veux éviter de re-uploader des fichiers identiques
SFTP peut être suffisant, voire plus simple si…
- tu transfères un fichier unique de temps en temps
- la différence « delta » ne t’apporte rien
- tu as besoin d’un outil graphique et d’une approche plus « humaine »
Le vrai sujet : la gestion des accès et des erreurs humaines
Techniquement, SFTP et rsync via SSH sont tous les deux chiffrés. Donc la sécurité, c’est aussi :
- qui a accès à quoi
- comment tu gères les clés
- comment tu limites les dégâts si une clé fuite
- comment tu logs
Bonnes pratiques rapides (valables pour les deux)
- désactiver l’auth par mot de passe sur SSH si possible
- utiliser des clés
ed25519 - mettre un
AllowUsersouAllowGroupsdédié - limiter avec
Match Userdanssshd_config - firewall : n’ouvre pas SSH au monde si tu peux éviter, passe par un VPN ou un bastion
- activer des logs et les regarder, parfois
SFTP : tips de durcissement côté serveur
Forcer un utilisateur en SFTP uniquement
Dans /etc/ssh/sshd_config :
text Match User sftpuser ForceCommand internal-sftp PasswordAuthentication no ChrootDirectory /sftp/%u AllowTcpForwarding no X11Forwarding no
Tu redémarres SSH :
bash sudo systemctl restart ssh
Et tu as un compte qui ne peut pas ouvrir un shell, juste faire du transfert.
C’est très apprécié en contexte client, agence, freelance. Tu donnes un accès fichier sans donner un accès serveur.
rsync : tips de durcissement et d’ergonomie
Utiliser une clé SSH dédiée à rsync
Tu peux créer une clé juste pour ça :
bash ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_rsync
Et l’utiliser :
bash rsync -av -e "ssh -i ~/.ssh/id_ed25519_rsync" ./data/ user@serveur:/backup/data/
Restreindre la clé côté serveur (authorized_keys)
Sur le serveur, dans ~user/.ssh/authorized_keys, tu peux préfixer la clé avec des restrictions.
Exemple simple :
text from="1.2.3.4",no-agent-forwarding,no-port-forwarding,no-pty ssh-ed25519 AAAA...
Tu limites l’usage à une IP, et tu coupes des options.
Image : checklist sécurité SSH
Tableau comparatif rapide : SFTP vs rsync
| Critère | SFTP | rsync |
| Chiffrement | oui (SSH) | oui si via SSH |
| Facile pour débutant | oui | moyen |
| Client graphique | oui | pas vraiment (il existe des wrappers, mais bon) |
| Synchro incrémentale | non | oui |
| Miroir avec suppression | manuel | natif (--delete) |
| Préservation des métadonnées | basique | excellente (-a) |
| Risque d’erreur destructrice | faible | moyen à élevé (si --delete mal utilisé) |
| Idéal pour | échanges ponctuels, accès client | backups, déploiements, gros volumes |
Quel choix je recommande, en vrai
Si tu hésites et que tu veux une règle simple :
- SFTP si tu veux un transfert sûr, simple, compatible, et que tu fais ça ponctuellement ou avec des non techniques.
- rsync via SSH si tu fais des transferts répétés, des backups, des déploiements, ou si la performance compte.
Et oui, beaucoup de gens finissent par utiliser les deux.
SFTP pour « envoyer un fichier à quelqu’un ». Rsync pour « maintenir deux dossiers synchronisés sans y passer la vie ».
Mini scénarios concrets (pour trancher vite)
Scénario A : tu es freelance et tu dois récupérer des exports clients
Choix : SFTP
Tu donnes un accès SFTP chrooté, le client dépose le fichier, fin de l’histoire. Tu limites le risque.
Scénario B : tu déploies un site WordPress ou un front statique souvent
Choix : rsync
Parce que tu vas relancer 50 fois la commande, et tu ne veux pas re-transférer 200 Mo à chaque push.
Scénario C : tu fais des backups journaliers vers un serveur distant
Choix : rsync (ou rsnapshot, restic, borg… mais ça, c’est un autre article)
Rsync est une brique simple, fiable, scriptable. Et combiné à SSH, c’est solide.
Une dernière chose : ce qui compte, c’est ton process
Le meilleur outil, c’est celui que tu peux exécuter à 2 h du matin sans te tromper.
Donc :
- écris tes commandes dans un script
- utilise
--dry-run - logge les sorties
- documente deux ou trois commandes propres dans ton wiki perso
C’est exactement le genre de routines que j’essaie de pousser aussi sur Le Blog Tech Pro de Samyn-Antoy ABASSE, où je partage des articles sur Linux et productivité. Ça se lit vite, et ça peut éviter des erreurs très bêtes. Par ailleurs, si jamais tu te demandes quel système d'exploitation choisir entre Linux et Windows pour tes besoins en informatique, je te recommande vivement de lire cet article sur Linux vs Windows: quel OS choisir pour tes projets?.
Conclusion : SFTP ou rsync, lequel est « le plus sûr » ?
Les deux peuvent être sûrs.
- SFTP est souvent le choix « safe par défaut », facile à déléguer, et très bien pour des transferts ponctuels.
- rsync est le choix « pro » quand tu veux de la synchro, de la vitesse, et de la répétabilité, à condition de le manier avec un peu de discipline.
Si tu veux, dis moi ton cas précis (taille des fichiers, fréquence, qui transfère, quel OS, contrainte de compliance ou non) et je te propose une config type, avec les commandes exactes, et une checklist de sécurité adaptée.
Questions fréquemment posées
Qu'est-ce que SFTP et comment fonctionne-t-il ?
SFTP signifie SSH File Transfer Protocol. C'est un protocole de transfert de fichiers sécurisé qui utilise un tunnel SSH pour chiffrer et authentifier les échanges. Il permet de transférer des fichiers fichier par fichier, via la ligne de commande avec l'outil 'sftp', des clients graphiques comme FileZilla, WinSCP ou Cyberduck, ou encore via des bibliothèques dans plusieurs langages.
Quelles sont les principales différences entre SFTP et rsync ?
SFTP est un protocole de transfert fichier par fichier sécurisé via SSH, idéal pour des transferts ponctuels ou pour des utilisateurs non techniques. Rsync est un outil de synchronisation intelligent qui compare les fichiers source et destination pour ne transférer que les différences (delta), ce qui est très efficace pour gérer de gros dossiers ou des backups incrémentaux. Rsync peut fonctionner localement, via SSH ou via un daemon rsync.
Quels sont les avantages en termes de sécurité de SFTP ?
SFTP bénéficie directement de la sécurité du protocole SSH : chiffrement en transit, authentification par clé, et possibilité d'appliquer des restrictions d'accès (comme chroot). Cela réduit la surface d'attaque et facilite la gestion sécurisée des transferts, ce qui est clair à expliquer aux équipes ou clients.
Comment assurer la sécurité lors de l'utilisation de rsync ?
Rsync est très sûr lorsqu'il est utilisé via SSH (par exemple avec 'rsync -e ssh'). Il profite alors du chiffrement et de l'authentification sécurisée. Toutefois, utiliser le daemon rsync ouvert sur le réseau nécessite une configuration rigoureuse des autorisations, du firewall et des logs. De plus, certaines options rsync peuvent être dangereuses si mal utilisées, il faut donc bien comprendre les commandes.
Dans quels cas privilégier l'utilisation de SFTP plutôt que rsync ?
SFTP est idéal si vous souhaitez un outil universel accessible même aux non-techniciens (avec clients graphiques), pour des transferts ponctuels comme exporter une archive ou configurer un fichier unique, ou encore lorsque vous avez besoin de naviguer, lister ou renommer des fichiers à distance grâce à son interface interactive.
Pourquoi utiliser rsync pour synchroniser des données volumineuses ?
Rsync excelle dans la synchronisation intelligente grâce à son mécanisme delta : il ne transfère que les parties modifiées d'un fichier ou dossier. Cela rend les transferts plus rapides et économes en bande passante, parfait pour gérer régulièrement de gros volumes comme des sites web complets ou des sauvegardes incrémentales.
0 Commentaires