# Synchroniser les médias entre environnements avec rclone > Copier sélectivement des fichiers entre stockages distants sans faire dépendre le développement local d'une connexion permanente. - Auteur : Clément Hadrot - Publié le : 2024-12-06 - Mis à jour le : 2024-12-06 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/synchroniser-medias-environnements-rclone/ ## L’essentiel - rclone copie sans dupliquer ce qui existe déjà localement - Un filtre par date évite de retélécharger tout l'historique - La commande fonctionne aussi bien en local qu'en CI 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` : > L'essentiel à retenir : rclone copie sans dupliquer ce qui existe déjà localement ; Un filtre par date évite de retélécharger tout l'historique ; La commande fonctionne aussi bien en local qu'en CI ``` [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.