scp : copier des fichiers sans se raconter d'histoires

Rien de plus. Pas de synchronisation, pas de reprise après coupure, pas de gestion de versions. C'est le marteau de la boîte à outils : tu l'attrapes pour un clou, tu le reposes, tu ne réfléchis pas.

La question n'est donc pas « comment on s'en sert ». La question est de savoir quand `scp` suffit et quand tu es en train de te compliquer la vie pour rien.

Ce que tu obtiens sans rien installer

Sur toute distribution Linux ou Unix correctement configurée, `scp` est déjà là. Il fait partie de la suite OpenSSH, comme `ssh` et `sftp`. Si tu peux te connecter en SSH à une machine, tu peux copier des fichiers vers elle.

C'est l'argument principal. Pas de démon à installer côté serveur, pas de port supplémentaire à ouvrir, pas de fichier de configuration à maintenir. Le service SSH qui tourne déjà fait tout le travail.

Cette simplicité a un prix, et il faut le nommer : `scp` ne sait rien faire d'autre que copier. Il ne compare pas les fichiers, il ne reprend pas une transfert interrompu, il ne compresse pas intelligemment. Tu lui donnes une source et une destination, il exécute, il rend un code de sortie.

La syntaxe tient en deux lignes

Pour envoyer un fichier vers une machine distante :

```bash scp ./config.yml user@serveur.example.com:/etc/app/config.yml ```

Pour le récupérer dans l'autre sens :

```bash scp user@serveur.example.com:/var/log/app/error.log ./error.log ```

Le `host` s'écrit `user@serveur`, et le chemin suit les deux-points. Si tu omets le chemin après les deux-points, le fichier atterrit dans le répertoire personnel de l'utilisateur distant. Si tu omets l'utilisateur, `scp` prend ton nom de login local, ce qui marche rarement sur un serveur de production.

L'authentification suit exactement les règles de `ssh`. Clé privée, agent, mot de passe, tout ce que ton `~/.ssh/config` contient s'applique. Tu ne configures rien de neuf.

Le `-r` et le reste

Pour un dossier entier, il faut `-r`, sans exception :

```bash scp -r ./projet user@serveur.example.com:/var/www/projet ```

Sans `-r`, `scp` refuse les répertoires. C'est une protection, pas un oubli. Copier une arborescence sans le dire explicitement est le genre d'erreur qu'on ne veut pas découvrir après coup.

Quelques options valent la peine d'être connues. `-P` (majuscule) change le port SSH, à ne pas confondre avec `-p` minuscule qui préserve les horodatages. `-C` active la compression, utile sur une liaison lente, inutile sur un réseau local. `-i` pointe vers une clé privée précise quand ton agent ne fait pas le travail.

Et puis il y a `-3`, qui force le transfert à passer par la machine locale quand tu copies entre deux serveurs distants. Sans cette option, `scp` tente une connexion directe entre les deux, ce qui échoue souvent derrière un pare-feu. Avec `-3`, tout transite par ta machine, ce qui fonctionne toujours mais coûte de la bande passante locale.

Là où ça devient intéressant

`scp` utilise SFTP comme couche de transport depuis OpenSSH 9.0, sorti en avril 2022. Avant cette version, il utilisait le protocole `scp` historique, plus ancien et plus limité. La différence est invisible pour l'utilisateur, sauf sur les très vieux serveurs où le sous-système SFTP est désactivé. Dans ce cas, `scp -O` force l'ancien protocole.

Ce détail compte pour une raison : le protocole `scp` d'origine ne sait pas gérer les noms de fichiers contenant certains caractères, et il a connu des failles de sécurité liées à l'expansion des caractères génériques côté serveur. SFTP règle ces problèmes. Si tu administres des machines récentes, tu bénéficies de ces corrections sans rien faire.

Le code de sortie reste ton meilleur ami dans un script. `scp` retourne `0` en cas de succès, une valeur non nulle sinon. Un script de sauvegarde qui vérifie ce code sait immédiatement si la copie a abouti, sans parser de logs.

Ce que `scp` ne fera jamais

Il ne reprend pas un transfert interrompu. Si tu copies un fichier de 4 Go et que la connexion tombe à 90 %, tu recommences à zéro. `rsync` fait mieux, et c'est son métier.

Il ne synchronise pas de répertoires. Il copie, il écrase, il ne compare pas. `rsync -a` sur une arborescence existante ne transfère que les différences ; `scp -r` renvoie tout.

Il n'offre pas d'interface interactive pour naviguer dans le système de fichiers distant. `sftp` le fait, avec les mêmes fondations SSH, et reste une meilleure option quand tu ne sais pas exactement où se trouve ce que tu cherches.

Ces limites ne sont pas des défauts. Ce sont les conséquences directes de sa simplicité. Un outil qui ferait tout ça serait plus complexe, aurait plus d'options, et tomberait en panne de façons plus variées.

Le choix dépend de trois questions

Combien de fois vas-tu faire cette copie ? Si c'est une fois, `scp` gagne, sans discussion. Si c'est récurrent et que seuls quelques fichiers changent, `rsync` te fera gagner du temps et de la bande passante.

La connexion est-elle stable ? Sur une liaison fiable, `scp` suffit. Sur un lien instable ou une connexion mobile, l'absence de reprise devient vite pénible.

As-tu besoin de voir ce que tu fais ? Si tu préfères naviguer, lister, choisir, `sftp` ou un client graphique sera plus confortable. Si tu connais le chemin exact, `scp` va droit au but.

Il n'y a pas de mauvaise réponse ici. Il y a des habitudes, et il y a ce que ta situation impose. `scp` reste dans la boîte parce qu'il ne demande rien, ne casse rien, et fait exactement ce qu'on lui dit. C'est rare, et c'est suffisant pour beaucoup de gens.

Le reste du temps, tu sauras pourquoi tu ouvres autre chose.