Copie SSH - scp, rsync, sftp : Lequel choisir et pourquoi ?

Dans un contexte DevOps, la copie de fichiers via SSH sert surtout à déployer vite, synchroniser un serveur de préproduction ou rapatrier une sauvegarde sans exposer les données en clair. Ce que beaucoup résument un peu vite par ssh copy recouvre en réalité plusieurs approches, du simple scp à rsync, en passant par sftp ou un flux tar encapsulé dans ssh. L’enjeu n’est pas seulement de faire passer un fichier : il faut aussi choisir l’outil qui évite les surprises sur les permissions, les dossiers volumineux et les mises à jour incrémentales.

Ce que recouvre vraiment la copie via SSH

Je commence toujours par une clarification simple : SSH n’est pas, à lui seul, un outil de copie. C’est le canal sécurisé sur lequel viennent s’appuyer des outils comme scp, sftp ou rsync lorsqu’il passe par un shell distant. Dans les faits, SSH chiffre la connexion, authentifie les machines et protège les échanges contre l’interception sur le réseau.

Cette distinction compte, parce qu’elle évite un contresens fréquent. Si l’objectif est de transférer un fichier isolé, la solution la plus courte n’est pas forcément la meilleure pour un déploiement. Si l’objectif est de synchroniser un répertoire de build, la copie brute peut devenir inutilement coûteuse. Et si l’objectif est de restaurer une arborescence avec des permissions cohérentes, le bon choix change encore. En pratique, je pense en termes de fichier, dossier, synchronisation ou restauration, pas seulement en termes de “copie”.

Un autre point utile : la famille OpenSSH fournit les outils qu’on utilise le plus souvent pour ces opérations, notamment ssh, scp et sftp. À partir de là, tout devient une question d’usage concret. Une fois ce cadre posé, le plus simple est de partir du cas le plus courant : un fichier isolé à envoyer ou à récupérer.

Copier un fichier avec scp sans se tromper

Pour un envoi ponctuel, scp reste la voie la plus rapide à lire et à mémoriser. Le principe est simple : tu indiques une source locale et une destination distante, ou l’inverse. Pour un fichier unique, c’est souvent le meilleur compromis entre clarté et efficacité.

scp ./config.json deploy@serveur:/srv/app/config.json
scp deploy@serveur:/var/log/app.log ./
scp -P 2222 ./build.zip deploy@serveur:/srv/releases/

Le premier réflexe que je garde en tête, c’est le port : 22 est la valeur par défaut, mais beaucoup d’équipes changent ce port pour des raisons d’organisation ou de politique de sécurité. Dans ce cas, -P sert à préciser le port du serveur distant. L’authentification par clé SSH fonctionne naturellement dans ce scénario et évite de taper un mot de passe à chaque opération.

Depuis les versions récentes d’OpenSSH, scp s’appuie sur SFTP pour le transfert des données tout en conservant le contexte de connexion SSH. C’est une bonne nouvelle dans la majorité des cas, car le comportement des chemins et des caractères spéciaux est plus prévisible qu’avec l’ancien protocole SCP “pur”. En revanche, pour des synchronisations répétées ou des arborescences volumineuses, je ne m’arrête jamais à scp trop longtemps. C’est là que la logique de dossier entre en jeu.

Copier un dossier entier proprement

Quand on passe d’un fichier à un répertoire complet, il faut regarder au-delà du simple réflexe de copie. scp -r peut suffire pour un petit arbre, mais je le réserve plutôt aux cas simples. Dès qu’il y a des centaines de fichiers, des builds fréquents ou un besoin de reprise régulière, rsync est plus rationnel.

scp -r ./assets deploy@serveur:/var/www/app/
rsync -avz --progress ./dist/ deploy@serveur:/var/www/app/
rsync -avz --delete ./dist/ deploy@serveur:/var/www/app/

Le détail qui change tout avec rsync, c’est le slash final sur la source. ./dist/ et ./dist ne racontent pas exactement la même chose : dans le premier cas, on copie le contenu du dossier, dans le second on peut se retrouver avec le dossier lui-même selon la destination visée. C’est un petit piège, mais c’est précisément le genre de détail qui fait perdre du temps en déploiement.

J’utilise aussi souvent --dry-run avant un sync potentiellement destructif, surtout quand --delete entre en jeu. Cette option ne modifie rien et montre ce qui serait transféré ou supprimé. En pratique, c’est une assurance bon marché contre une erreur de chemin ou une variable d’environnement mal réglée. Pour les très gros volumes, rsync garde un avantage net grâce à son approche incrémentale : il ne renvoie que ce qui a changé, au lieu de retransmettre tout le dossier à chaque fois.

Dans certains cas, je ne copie même pas dossier par dossier. Je compacte d’abord l’arborescence, puis je la fais passer dans SSH en un seul flux. C’est particulièrement utile quand il y a beaucoup de petits fichiers ou quand je veux limiter les allers-retours réseau.

tar czf - ./mon-dossier | ssh user@serveur 'tar xzf - -C /srv/app'

Cette méthode est moins “interactive” qu’un scp classique, mais elle devient très propre pour des restaurations ou des déploiements temporaires. Le choix entre ces variantes dépend surtout de la fréquence des transferts et de la taille réelle des données. Pour clarifier ce choix, un comparatif vaut mieux qu’une règle unique.

Choisir entre scp, rsync, sftp et un flux tar

Si je devais résumer ma logique en une table simple, je dirais que chaque outil a sa zone de confort. Le bon réflexe n’est pas de chercher un vainqueur absolu, mais de relier l’outil au besoin réel : transfert ponctuel, synchronisation, navigation manuelle ou restauration structurée.

Je remarque aussi qu’on confond souvent copie et exploration. Quand l’objectif est juste d’inspecter quelques fichiers distants ou de déposer un document ponctuellement via une interface, sftp est très confortable. Quand l’objectif est d’aligner un serveur de staging avec un dossier local, rsync est presque toujours plus cohérent. Et quand il faut restaurer une arborescence telle quelle, le flux tar garde une vraie utilité.

Le bon outil dépend donc surtout de la fréquence, du volume et de la sensibilité des données. Une fois ce tri fait, il reste le point que beaucoup négligent trop vite : la sécurité et l’automatisation.

Sécuriser et automatiser les transferts dans un flux DevOps

Dans un pipeline DevOps, je cherche moins à “faire marcher” la copie qu’à la rendre fiable dans la durée. La première règle est simple : utiliser des clés SSH plutôt qu’un mot de passe dès que l’opération sort du cadre ponctuel. Cela réduit les frictions, facilite l’automatisation et évite de stocker des secrets fragiles dans des scripts ou des logs.

• Je crée un compte distant dédié au déploiement plutôt que d’utiliser un compte personnel.
• Je vérifie la clé d’hôte au premier contact et je garde un fichier known_hosts propre.
• Je teste toute synchronisation risquée avec --dry-run avant d’ajouter --delete.
• Je quote systématiquement les chemins et les variables dès qu’ils passent dans un script CI.
• Je n’essaie pas de tout faire en root si les permissions classiques suffisent.

Dans les équipes qui déploient sur plusieurs environnements, j’ajoute souvent une étape de validation avant la copie réelle. Un simple prévisualisateur de diff, ou même une sortie --itemize-changes côté rsync, fait déjà gagner du temps quand un chemin n’est pas celui qu’on croyait. Si un bastion est présent entre la machine de build et le serveur cible, le transfert reste possible, mais il faut alors penser à la chaîne de connexion dans sa globalité plutôt qu’au seul serveur final.

Le point le plus sous-estimé, à mon avis, reste la gestion des permissions. Copier un fichier correctement ne garantit pas qu’il sera exécutable, lisible par le bon service ou compatible avec le mécanisme de rotation des secrets. En production, une copie réussie mais inutilisable est encore un échec. C’est exactement pour cela que je préfère des scripts courts, lisibles et testés plutôt que des enchaînements trop “malins”. Une bonne automatisation n’est pas spectaculaire ; elle est stable.

Ce que je garde pour les déploiements et sauvegardes

En pratique, je retiens une règle simple : un fichier isolé passe bien avec scp, un dossier vivant mérite souvent rsync, une manipulation manuelle se fait mieux avec sftp, et une arborescence complète avec beaucoup de petits fichiers peut gagner à transiter dans un flux tar | ssh. Ce tri évite de surdimensionner l’outil par réflexe, et il rend les transferts plus lisibles dans les scripts d’exploitation.

Si je ne devais garder qu’une habitude, ce serait celle-ci : ne copie pas par habitude, copie selon le rythme du changement. C’est ce qui fait la différence entre un transfert SSH simplement “fonctionnel” et un transfert vraiment exploitable en production, en préproduction et dans les sauvegardes régulières.