Compresser les fichiers avant envoi : réduire la taille

Compressez les fichiers texte, le code source, les journaux, les CSV et les formats d'image non compressés comme .bmp ou .tiff avant de les envoyer — attendez-vous à une réduction de taille de 3 à 10 fois. Ne compressez pas les fichiers .jpg, .png, .mp4, .mp3, .docx, .xlsx, .pdf ou .zip — ils sont déjà compressés en interne, et un second passage n'apporte que 2 à 3 % d'économies au prix d'une charge CPU élevée. Pour regrouper plusieurs petits fichiers en un seul envoi, utilisez .zip en mode stockage (sans compression). Pour un ratio maximal sur des données compressibles, 7z avec LZMA2 surpasse généralement .zip de 30 à 40 %. RAR est globalement équivalent à 7z mais exige que le destinataire ait WinRAR ou 7-Zip installé — .zip est supporté universellement.

Quand la compression aide vraiment

Les fichiers texte se compressent considérablement. Un fichier serveur .log de 10 Mo se réduit souvent à 800 Ko avec .zip (rapport 12:1), et à 550 Ko avec 7z (rapport 18:1). La compression fonctionne parce que les journaux contiennent des motifs très répétitifs — horodatages, adresses IP, codes d'état HTTP — que les algorithmes exploitent efficacement.

Catégories similairement compressibles :

Code source : .js, .py, .java, .cs, .go — typiquement 3 à 5 fois de compression
Données CSV : 4 à 10 fois selon la redondance du contenu
JSON/XML : 5 à 8 fois en raison des noms de champs répétés
Images non compressées : .bmp (5-10 fois), .tiff non compressé (4-8 fois)
Bases de données : fichiers .sql, SQLite avec pages libres (2-4 fois)
Calats plats PSD : 2 à 3 fois si non déjà compressés RLE en interne

Un tarball Git d'un projet de taille moyenne se compresse souvent 4 à 5 fois, c'est pourquoi git archive enveloppe l'arborescence en .tar.gz par défaut.

Quand la compression ne sert à rien

Les formats déjà compressés ne deviennent pas plus petits. Les données sous-jacentes ont déjà subi DEFLATE, H.264, la quantification DCT JPEG ou un schéma similaire — l'entropie est déjà proche du minimum théorique.

Fichiers sans bénéfice :

.jpg, .jpeg, .heic : compression avec perte déjà appliquée
.png : compression DEFLATE intégrée
.mp4, .mov, .mkv : compression H.264 ou H.265 déjà appliquée
.mp3, .aac, .flac, .ogg : audio déjà compressé
.pdf : les flux d'objets internes sont généralement compressés avec DEFLATE
.docx, .xlsx, .pptx : ce sont en réalité des archives ZIP de XML — les re-zipper est redondant
.zip, .7z, .rar, .gz, .bz2, .xz : archives compressées ; un second passage est inutile
.apk, .jar, .war : archives Java/Android basées sur ZIP

Compresser ces fichiers gaspille du CPU et parfois grossit légèrement le fichier à cause de la surcharge des métadonnées d'archive.

ZIP vs 7z vs RAR

| Format | Ratio typique | Vitesse | Compatibilité destinataire | Chiffrement | |---|---|---|---|---| | .zip (DEFLATE) | Référence | Rapide | Universel (intégré à Windows, macOS, Linux) | ZIP 2.0 (faible), AES-256 (outils modernes) | | .zip (DEFLATE64) | 5-10 % mieux | Rapide | Windows intégré, 7-Zip, certains outils macOS | Identique à .zip | | 7z (LZMA2) | 30-40 % mieux que .zip | Plus lent | Nécessite 7-Zip, Keka ou The Unarchiver | AES-256 intégré | | .rar (RAR5) | ≈25-35 % mieux que .zip | Moyen | Nécessite WinRAR ou 7-Zip ; pas gratuit à créer | AES-256 intégré | | .tar.gz | Similaire à .zip | Rapide | Intégré à macOS, Linux ; nécessite 7-Zip sur Windows | Aucun natif | | .tar.zst (Zstandard) | Entre .zip et 7z | Très rapide | Nécessite zstd (pas encore universel) | Aucun natif |

Pour la portabilité, .zip reste le choix le plus sûr. Pour le ratio, 7z gagne. Pour la vitesse et l'efficacité moderne, Zstandard (.zst) est excellent mais les destinataires ont besoin d'outils compatibles.

Le mode « stockage » pour regrouper des fichiers

Si vous envoyez 200 photos .jpg en un seul transfert, vous voulez quand même les regrouper dans une archive pour que le destinataire clique sur « télécharger » une seule fois. Utilisez .zip avec un niveau de compression 0 (mode « stockage »). L'archive pèse la somme des tailles de fichiers plus quelques kilo-octets de répertoire — et le coût CPU de création est quasi nul.

Dans 7-Zip : Ajouter à l'archive → Niveau de compression → Stocker. Dans le Finder macOS : Clic droit → Compresser (utilise DEFLATE par défaut, ce qui n'aide pas sur .jpg mais ne nuit pas beaucoup). En ligne de commande : zip -0 bundle.zip *.jpg.

Chiffrement lors de la compression

Les fichiers ZIP protégés par mot de passe utilisant AES-256 (pas le chiffrement ZIP 2.0 historique) sont une solution raisonnable pour les contenus sensibles quand vous ne pouvez pas vous fier à la sécurité du canal de transfert. WinRAR, 7-Zip et l'Utilitaire d'archive macOS supportent tous le chiffrement ZIP AES-256.

Le piège : l'échange du mot de passe. N'envoyez pas le mot de passe dans le même message que le fichier ZIP. Envoyez le fichier, puis partagez le mot de passe via Signal, iMessage ou un canal séparé. Encore mieux : utilisez un service de transfert avec protection par mot de passe intégrée, qui gère cette complexité pour vous.

Le chiffrement ZIP 2.0 historique (parfois encore la valeur par défaut dans les anciens outils) est cryptographiquement cassé — récupérable en quelques secondes avec des attaques à texte clair connu. Vérifiez toujours que vous utilisez AES-256 si vous comptez sur le chiffrement d'archive pour la sécurité.

Le compromis : temps CPU vs octets économisés

La compression est un arbitrage entre temps et taille. La compression 7z maximale sur une archive texte de 5 Go peut prendre 30 minutes sur un portable et économiser 2 Go par rapport à .zip. Si le transfert est limité en taille (un service avec un plafond de 2 Go), ça vaut le coup. Si le transfert est limité en temps et que la bande passante est bon marché, ces 5 Go s'envoient en 90 secondes en fibre — la demi-heure de compression vous aurait coûté plus de temps qu'elle n'en aurait économisé.

Règle empirique : compressez quand le réseau est lent par rapport au CPU ; ne vous en donnez pas la peine quand le réseau est rapide par rapport au CPU.

Découper les archives volumineuses

Quand un fichier dépasse le plafond d'un service de transfert, le découpage en volumes est une option. 7-Zip et WinRAR supportent tous deux les archives en plusieurs parties (.7z.001, .7z.002, ou .part1.rar, .part2.rar). Chaque partie peut être envoyée séparément ; le destinataire télécharge toutes les parties et extrait.

Ça fonctionne mais c'est fragile — si une seule partie manque, toute l'archive est inutilisable. Mieux, si possible : utilisez un service avec un plafond plus grand. Le plafond de 50 Go de SwissTransfer supprime le besoin de découpage dans la plupart des cas réalistes.

La compression avec perte comme alternative

Parfois l'objectif n'est pas la compression d'archive mais la compression de format de fichier. Un fichier audio .wav de 200 Mo devient un .mp3 à 320 kbit/s de 15 Mo — avec perte mais quasi transparent pour une écoute courante. Une photo .tiff non compressée de 60 Mo devient un .jpg de haute qualité de 5 Mo. Une vidéo .mov 4K réencodée en H.265 à un débit raisonnable peut rétrécir de 3 à 5 fois.

Utilisez ceci avec discernement. Pour les fichiers maîtres, la conversion avec perte détruit de l'information. Pour les aperçus ou les livrables, c'est le bon outil. Outils : FFmpeg pour la vidéo/audio, HandBrake pour la vidéo, ImageMagick pour les images, et les boîtes de dialogue d'export dans Photoshop, Final Cut Pro ou Premiere.

Ce que fait de toute façon le service de transfert

La plupart des services de transfert compriment dans une certaine mesure en transit — la compression TLS est désactivée pour des raisons de sécurité, mais gzip HTTP ou brotli sur la couche API s'active parfois pour les métadonnées. La charge utile du fichier réelle n'est pas compressée côté serveur parce que la plupart des contenus sont déjà dans des formats compressés.

HexaTransfer et les services sans connaissance similaires ne peuvent pas comprimer les charges utiles côté serveur du tout car ils reçoivent du texte chiffré. La compression doit avoir lieu côté client avant le chiffrement — après le chiffrement, le texte chiffré ressemble à des données aléatoires et est incompressible. Cela signifie que la compression côté client est la seule façon de réduire la taille avec un service E2EE.

Conclusion

Compressez quand les données sont compressibles — texte, journaux, code source, bases de données. Ne compressez pas quand les données sont déjà compressées — photos, vidéos, audio, PDF, documents de bureautique. Pour regrouper des fichiers, utilisez ZIP en mode stockage. Pour un ratio maximal sur du texte, utilisez 7z avec LZMA2. Chiffrez avec des mots de passe d'archive AES-256 uniquement en complément d'un canal de transfert sécurisé, jamais à sa place.

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