Un développeur qui travaille sur un site avec plusieurs dizaines de milliers de médias accumulés depuis des années se retrouve vite face à un choix : soit il télécharge l’intégralité du dossier wp-content/uploads en local, au prix d’un temps de synchronisation et d’un espace disque considérables, soit il travaille avec des images cassées, en `alt` sans source, ce qui rend toute revue visuelle impossible.
L’agence utilise rclone, un outil en ligne de commande pensé pour la synchronisation entre stockages distants variés (S3, SFTP, WebDAV, Google Drive et bien d’autres), pour copier sélectivement les médias nécessaires sans dépendre d’un accès permanent au serveur de production, contrairement à une solution de proxy d’uploads en temps réel déjà couverte par ailleurs.
Pourquoi rsync ne suffisait plus
Avant d’adopter rclone, la synchronisation des médias reposait sur un simple rsync par SSH vers le serveur de production. Cette approche fonctionnait tant que le volume de médias restait modeste, mais elle s’est mise à échouer régulièrement sur un projet avec plus de 80 000 fichiers dans uploads : la phase de calcul du delta, où rsync compare l’arborescence distante et locale fichier par fichier, prenait plusieurs minutes avant même de commencer à transférer quoi que ce soit, et la connexion SSH expirait parfois avant la fin.
rclone résout ce problème différemment : il maintient une représentation plus efficace de l’état distant, en s’appuyant sur les métadonnées natives du stockage cible (taille, date de modification, empreinte) plutôt que sur un calcul de delta complet à chaque exécution.
Configurer un accès au stockage de production
La configuration se fait une fois, via rclone config, ou directement dans le fichier ~/.config/rclone/rclone.conf :
[production-boutique]
type = sftp
host = boutique.example.com
user = deploiement
key_file = ~/.ssh/deploiement_agence
shell_type = unix
[production-boutique-s3]
type = s3
provider = AWS
access_key_id = AKIA...
secret_access_key = ...
region = eu-west-3
Deux remotes coexistent volontairement ici : certains sites de l’agence stockent encore leurs médias sur le serveur lui-même via SFTP, d’autres ont déjà migré vers un stockage S3 avec une extension d’offload. rclone traite les deux cas avec la même syntaxe de commande, ce qui simplifie la vie de l’équipe qui n’a pas à retenir deux outils différents.
Copier sélectivement plutôt que tout dupliquer
La commande de base copie le contenu distant vers un dossier local, sans supprimer ce qui existe déjà localement mais n’existe plus côté distant, contrairement à sync qui, lui, aligne strictement les deux côtés :
rclone copy production-boutique:/var/www/boutique/wp-content/uploads \
./wp-content/uploads \
--progress
Filtrer par date pour ne pas tout retélécharger
Pour un développement quotidien, retélécharger l’intégralité de l’historique des médias à chaque synchronisation n’a aucun sens : seuls les fichiers récents, liés au travail en cours, ont vraiment besoin d’être à jour localement. Le filtre --max-age limite la copie aux fichiers modifiés récemment côté distant :
rclone copy production-boutique:/var/www/boutique/wp-content/uploads \
./wp-content/uploads \
--max-age 90d \
--progress
Pour les médias plus anciens, une alternative consiste à ne synchroniser que les vignettes légères plutôt que les fichiers sources en pleine résolution, via un filtre sur le motif de nom de fichier généré par WordPress :
rclone copy production-boutique:/var/www/boutique/wp-content/uploads \
./wp-content/uploads \
--include "*-{150x150,300x200,768x*}.{jpg,png,webp}" \
--progress
Intégrer la synchronisation dans un script de mise à jour d’environnement
Sur les projets de l’agence, cette commande fait partie d’un script plus large, appelé après une synchronisation de base de données, qui prépare un environnement local à jour :
#!/usr/bin/env bash
set -euo pipefail
echo "Synchronisation de la base de données..."
wp db import "$(wp @production db export - --allow-root)" --allow-root
echo "Synchronisation des médias récents (90 derniers jours)..."
rclone copy production-boutique:/var/www/boutique/wp-content/uploads \
./wp-content/uploads --max-age 90d --progress
echo "Recherche et remplacement des URL..."
wp search-replace 'https://boutique.example.com' 'https://boutique.local' --allow-root
echo "Environnement local à jour."
Utiliser rclone aussi en intégration continue
La même commande fonctionne sans modification dans un job GitHub Actions, par exemple pour préparer un environnement de test avec un sous-ensemble représentatif de médias avant de lancer une suite de tests visuels :
- name: Installer rclone
run: curl https://rclone.org/install.sh | sudo bash
- name: Récupérer un échantillon de médias
run: |
mkdir -p ~/.config/rclone
echo "${{ secrets.RCLONE_CONF }}" > ~/.config/rclone/rclone.conf
rclone copy production-boutique:/var/www/boutique/wp-content/uploads \
./wp-content/uploads --max-age 30d
Synchroniser tous les médias d’un site par principe, sans réfléchir à ce qui sert réellement au travail en cours, revient à remplir un disque dur pour le plaisir de dire que l’environnement local est complet.
En résumé
Sur le projet qui a motivé l’adoption de rclone, une synchronisation qui échouait régulièrement avec rsync s’est stabilisée à environ six minutes pour 40 Go de médias filtrés sur les trois derniers mois, un temps largement compatible avec une routine de démarrage de journée. L’outil se prête aussi bien à un usage manuel ponctuel qu’à une intégration dans un pipeline CI, sans changer de syntaxe entre les deux contextes.
