Optimisation du téléchargement groupé : transférer plus vite

La stratégie d'envoi groupé la plus rapide : regroupez le dossier dans un seul .zip (mode stockage, sans compression) et envoyez un gros objet au lieu de milliers de petits. Un dossier de 5 000 fichiers .jpg à 500 Ko chacun totalise 2,5 Go mais prend 10 à 20 fois plus longtemps à envoyer individuellement qu'en tant qu'archive unique de 2,5 Go, car chaque petit fichier paie la pleine surcharge TLS et HTTP. Les services avec prise en charge des envois parallèles (HexaTransfer, Dropbox, rclone) aident quand de nombreux blocs sont volumineux. Les services sans parallélisme gagnent quand même en débit une fois que vous combinez les petits fichiers en une seule archive. Ajoutez la déduplication des fichiers accidentellement dupliqués, excluez les fichiers parasites .DS_Store et Thumbs.db, et vous terminerez en une fraction du temps naïf.

Pourquoi des milliers de petits fichiers sont lents

Chaque envoi de fichier via HTTPS porte une surcharge fixe : poignée de main TLS (réutilisable avec keep-alive de connexion), en-têtes HTTP (≈500 octets), acquittement du serveur et flush disque côté serveur. Pour un fichier de 50 Ko, cette surcharge peut dépasser la taille du fichier lui-même. Pour un fichier de 500 Ko, la surcharge représente 10 à 20 % des octets total envoyés sur le réseau.

Multipliez par 5 000 fichiers et vous avez brûlé la moitié du temps sur des métadonnées plutôt que sur la charge utile. C'est pourquoi copier un grand dossier contenant de nombreux petits fichiers vers un stockage externe est toujours plus lent que copier une archive de taille équivalente.

Archiver d'abord, envoyer ensuite

Le gain le plus important pour les envois de dossiers : compressez en un seul fichier .zip, .7z ou .tar d'abord. Pour les contenus déjà compressés (photos, vidéos, documents bureautiques), utilisez le mode stockage (sans compression) — vous obtenez le bénéfice du regroupement sans le coût CPU. Pour les dossiers à dominante textuelle (journaux, code source), utilisez la compression par défaut pour des économies de taille réelles en plus.

Commandes :

• macOS/Linux : zip -0 -r archive.zip dossier/ pour aucune compression ; zip -r archive.zip dossier/ pour la compression par défaut.
• Windows : Clic droit sur le dossier → Envoyer vers → Dossier compressé. Ou utilisez 7-Zip avec Ajouter à l'archive → Niveau de compression → Stocker.
• Grands dossiers : tar -cf archive.tar dossier/ (sans compression) ou tar -czf archive.tar.gz dossier/ (gzip).

Dédupliquer avant d'archiver

Les dossiers accumulent des fichiers en double au fil du temps. Les projets de design contiennent « final_v2.psd », « final_v2_COPIE.psd », « final_v2_SAUVEGARDE.psd » — même contenu, noms différents. Un dossier de 20 Go peut régulièrement se réduire à 12 Go après déduplication.

Outils : fdupes (Linux), rmlint (Linux/macOS), Duplicate File Finder (macOS), dupeGuru (multiplateforme). La plupart fonctionnent en hachant les fichiers et en signalant les hachages identiques. Passez en revue les résultats, supprimez les doublons, puis archivez.

Pour les photographes, le catalogue Lightroom suit déjà les photos uniques ; exportez seulement les sélections marquées plutôt que des dossiers de capture entiers.

Exclure les fichiers parasites du système

Chaque dossier macOS accumule des fichiers .DS_Store (métadonnées cachées). Chaque dossier Windows contient des Thumbs.db. Les fichiers .directory Linux apparaissent depuis KDE. Ces fichiers n'apportent rien au destinataire et gonflent le nombre d'éléments de l'archive.

Pour zipper sur macOS :

zip -r archive.zip dossier/ -x "*.DS_Store" "__MACOSX"

Sur Windows via 7-Zip, excluez les motifs dans l'interface ou en ligne de commande avec -xr!Thumbs.db -xr!desktop.ini. Pour les transferts de type rsync, utilisez --exclude='.DS_Store' --exclude='Thumbs.db'.

Envois découpés en blocs parallèles

Quand le service le supporte, des flux HTTP parallèles saturent la bande passante qu'une seule connexion TCP ne peut remplir sur des chemins à haute latence. Le protocole tus.io supporte cela via des envois de blocs simultanés. Les clients comme la bibliothèque tus-js-client sont configurés par défaut sur une requête simultanée mais peuvent être paramétrés plus haut.

Pour les envois intercontinentaux (par exemple, un utilisateur en France vers un service américain), le parallélisme double ou triple le débit effectif. Pour les envois locaux, un seul flux sature généralement la bande passante montante et le parallélisme n'apporte rien.

Ajustement de la taille des blocs

Les blocs de grande taille réduisent la surcharge par requête ; les petits blocs récupèrent plus vite des défaillances réseau. L'arbitrage dépend de votre connexion :

| Type de connexion | Taille de bloc suggérée | |---|---| | Fibre gigabit, filaire | 32-64 Mo | | Fibre résidentielle, Wi-Fi | 10-20 Mo | | Haut débit bureau | 10 Mo | | Mobile 4G/5G | 2-5 Mo | | Wi-Fi instable/hôtel | 1-2 Mo |

La plupart des services grand public choisissent une valeur par défaut raisonnable (5-10 Mo) et n'exposent pas ce réglage. Les outils en ligne de commande (rclone, aws s3 cp, gsutil) permettent un ajustement précis.

La structure de dossiers compte moins que le volume total

Un mythe courant : « les dossiers profondément imbriqués ralentissent les envois ». Ce n'est pas vrai. Le format d'archive aplatit les chemins en en-têtes de chaîne quelle que soit la profondeur. Un dossier de 10 000 fichiers à 3 niveaux de profondeur s'envoie de façon identique à un dossier de 10 000 fichiers à 10 niveaux de profondeur une fois archivé.

Ce qui compte vraiment : le nombre individuel de fichiers. 10 000 petits fichiers à plat, c'est le même problème que 10 000 petits fichiers imbriqués — archivez-les.

Stratégie de compression par type de contenu

• Photos mixtes (.jpg/.heic) : .zip en mode stockage. Pas de gaspillage CPU.
• Photos RAW (.cr3/.arw/.nef) : .zip en mode stockage. Déjà compressées en interne.
• Projets vidéo (.mp4, .mov, .prproj) : .zip en mode stockage.
• Code source : 7z avec LZMA2 pour un ratio maximal.
• Fichiers journaux : 7z avec LZMA2 ; attendez-vous à une réduction de 10 à 20 fois.
• PDF : mode stockage. La plupart des PDF ont une compression interne.
• Documents bureautiques mixtes (.docx, .xlsx) : mode stockage. Ce sont déjà des XML compressés en ZIP en interne.
• Dumps de base de données (.sql) : 7z avec LZMA2. Excellente compression.

Arrière-plan vs avant-plan

Les envois par navigateur doivent garder l'onglet ouvert. Fermer l'onglet arrête généralement l'envoi. Certains services proposent des envois en arrière-plan via Service Worker qui continuent brièvement après la fermeture de l'onglet, mais c'est peu fiable sur les navigateurs mobiles et dans certains profils de navigateurs d'entreprise.

Pour les très gros envois groupés (100 Go+), les clients bureau gagnent car ils s'exécutent en tant que processus au niveau OS. rclone monte et synchronise vers n'importe quel grand cloud. Le client bureau Dropbox met les envois en file d'attente de manière fiable. Ces solutions survivent à la fermeture du couvercle et aux changements de Wi-Fi d'une façon que les navigateurs peinent à égaler.

Pour les envois groupés inférieurs à 10 Go, un service par navigateur moderne avec envois découpés via tus.io gère la charge de travail sans problème. Le chiffrement côté client de HexaTransfer ajoute une légère surcharge CPU mais n'affecte pas matériellement le débit sur le matériel actuel.

Découper les lots trop volumineux

Quand votre lot dépasse le plafond par transfert du service, découpez de façon logique plutôt que mécanique. Les dossiers « Photos par date » pour une séance d'un mois fonctionnent mieux que des découpages arbitraires en octets car les destinataires peuvent vérifier que chaque lot est complet (« 1-7 mars.zip », « 8-14 mars.zip ») plutôt que de se demander si le volume .005 manque.

Pour les services sans limites par transfert mais avec des limites de session, des envois séquentiels de plusieurs archives évite d'atteindre les plafonds d'envois simultanés.

Vérifier avant de partir

Les gros envois groupés sont tentants à lancer et oublier. Ne faites pas ça. Avant de fermer votre ordinateur :

• Confirmez que la page d'envoi affiche « terminé » et non « en cours »
• Ouvrez le lien dans un autre navigateur ou une fenêtre de navigation privée et vérifiez l'expérience du destinataire
• Vérifiez que l'archive s'ouvre correctement (un .zip corrompu pendant l'envoi est rare mais possible)
• Confirmez que les paramètres d'expiration correspondent à ce que vous vouliez

Cinq minutes de vérification valent mieux qu'un e-mail gênant le lendemain demandant si le destinataire a bien reçu les fichiers.

Conclusion

Le chemin rapide pour les envois de dossiers : archivez tout en un seul .zip (mode stockage pour les contenus déjà compressés, compression réelle pour le texte), excluez les fichiers parasites du système, déduplication si utile, et envoyez l'archive unique via un service qui supporte les envois découpés réutilisables. Pour les très gros lots, utilisez un client bureau. La différence entre « envoyer le dossier directement » à la va-vite et le chemin optimisé est souvent un facteur 10 en temps écoulé.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.