Le scénario frustrant
Vous avez déjà été dans cette situation. Un collègue vous envoie un rapport PDF de 50 Mo. Vous le trouvez trop volumineux pour l'envoyer par e-mail, alors vous le déposez dans 7-Zip, poussez la compression sur « ultra » et patientez. Résultat ? Une archive de 49 Mo. Vous l'envoyez quand même, le destinataire l'extrait, et le fichier fait toujours 50 Mo — pas un octet de moins.
Ce n'est pas un accident. Prenez un MP4, un JPG ou un PDF déjà compressé, glissez-le dans un fichier ZIP, et la taille bouge à peine. En revanche, passez le même 7-Zip sur un dossier de fichiers TXT, BMP ou CSV bruts, et l'archive peut se réduire au dixième de sa taille initiale.
Pourquoi une telle différence ? La réponse tient à une distinction que la plupart des gens ne connaissent jamais : la compression d'archive et la compression de contenu sont deux opérations fondamentalement différentes. Comprenez la différence, et vous arrêterez de perdre du temps à compresser des fichiers qui refusent de rétrécir — et vous commencerez à choisir le bon outil au bon moment.
Compression d'archive : l'art du conteneur
La compression d'archive opère au niveau du conteneur. Elle fait deux choses : regrouper plusieurs fichiers dans un seul conteneur, et appliquer un algorithme de compression sans perte pour éliminer la redondance statistique du flux d'octets.
Les formats d'archive familiers — ZIP, 7Z, TAR.GZ, RAR — reposent tous sur des algorithmes similaires en interne. ZIP utilise DEFLATE par défaut, qui combine LZ77 et le codage de Huffman. LZ77 repère les séquences d'octets répétées et les remplace par des références de distance et de longueur ; le codage de Huffman attribue ensuite des codes binaires plus courts aux caractères les plus fréquents et des codes plus longs aux plus rares. Le format 7Z de 7-Zip utilise LZMA par défaut, qui étend LZ77 avec un codage par plage et gère des fenêtres de dictionnaire beaucoup plus grandes, obtenant généralement de meilleurs ratios que DEFLATE.
Voici le point crucial : la compression d'archive ne modifie jamais le contenu des fichiers. Elle traite chaque fichier comme un flux opaque d'octets et traque les motifs statistiques dans ce flux. Quand vous extrayez une archive ZIP, les fichiers reviennent identiques octet pour octet aux originaux — pas un seul pixel ne change.
Cela explique le scénario d'ouverture. Un PDF a déjà compressé en interne ses flux d'images et de polices avec DEFLATE. Un JPG est lui-même un format compressé. Un MP4 utilise H.264 ou H.265 pour compresser les images vidéo. Ces fichiers ont déjà vu leur redondance éliminée, donc les algorithmes d'archive n'ont presque plus rien à exploiter. En revanche, les bitmaps BMP, l'audio WAV non compressé et les fichiers CSV en texte brut regorgent de répétitions compressibles — c'est là que la compression d'archive excelle.
Là où la compression d'archive excelle vraiment, c'est dans l'élimination de la redondance entre plusieurs fichiers. Supposez qu'un dossier contienne 100 captures d'écran, chacune portant le même filigrane de logo et une barre d'outils similaire. Le grand dictionnaire de LZMA peut identifier ces répétitions inter-fichiers et obtenir une bien meilleure compression qu'en compressant chaque fichier individuellement. C'est pourquoi regrouper des fichiers dans une seule archive est plus efficace que de les compresser un par un.
Il vaut la peine de comprendre ici le rôle du dictionnaire de compression. Aussi bien DEFLATE que LZMA maintiennent une fenêtre coulissante des données récemment vues — le dictionnaire — par rapport à laquelle les nouveaux octets sont mis en correspondance. La fenêtre de DEFLATE est fixée à 32 Ko, ce qui limite la distance de recherche des répétitions. LZMA permet de configurer des dictionnaires de 64 Mo ou plus, ce qui signifie qu'un motif apparu dans le premier fichier d'un lot peut encore être référencé lorsqu'il réapparaît dans le dernier. C'est pourquoi une seule grande archive de nombreux fichiers similaires se comprime bien mieux que de nombreuses petites archives : le dictionnaire dispose de plus de matière, et la redondance inter-fichiers est captée. Quand chaque fichier est emballé séparément, chaque archive démarre avec un dictionnaire vide et la redondance entre fichiers est entièrement perdue.
Compression de contenu : reconstruire de l'intérieur
La compression de contenu emprunte une autre voie. Elle ne se soucie pas du nombre de fichiers que vous avez, et ne regroupe rien. Au lieu de cela, elle plonge dans la structure interne d'un seul fichier et optimise les données selon le type spécifique de ce fichier.
Les techniques varient entièrement selon le type de fichier :
Les images peuvent être rééchantillonnées (réduire un original de 4000×3000 à 1920×1080), réencodées (convertir un PNG en WebP ou AVIF), ou voir leur profondeur de couleur réduite (24 bits en 8 bits indexé). Une photo de téléphone de 8 Mo, avec des ajustements raisonnables de résolution et de qualité, se compresse couramment à moins de 500 Ko sans différence visible à l'œil.
Les PDF peuvent voir leurs images intégrées sous-échantillonnées, leurs flux de polices non compressés convertis en CFF sous-ensemble, leurs objets non référencés supprimés, et leurs XObjects dupliqués fusionnés. Un document de conception de 50 Mo truffé d'illustrations en haute résolution peut souvent se réduire à 5-8 Mo après compression de contenu.
Les PDF sont un exemple particulièrement instructif car ils sont eux-mêmes des conteneurs. Un PDF stocke chaque image comme un objet de flux, chaque police comme un autre flux, et le texte comme des flux de contenu codé. La plupart des producteurs appliquent déjà DEFLATE aux flux de texte et de polices, et JPEG ou DCT aux images photographiques. C'est pourquoi un PDF passé à un outil d'archive rétrécit à peine — les gains faciles sont déjà pris. La compression de contenu réexamine en revanche chaque flux : elle sous-échantillonne les images dont la résolution dépasse ce dont l'affichage cible a besoin, convertit les flux d'images sans perte en JPEG lorsque c'est acceptable, supprime les métadonnées comme les vignettes intégrées et les calques cachés, et aplatit les XObjects de formulaire dupliqués. Le résultat n'est pas un emballage plus fin autour des mêmes données ; c'est un document fondamentalement plus léger.
Les polices peuvent être sous-ensemblees, ne conservant que les quelques dizaines de glyphes réellement utilisés dans un document plutôt que de livrer un fichier de police entier avec des dizaines de milliers de caractères.
La vidéo et l'audio peuvent être réencodés avec des codecs plus efficaces — passer de H.264 à H.265, par exemple, divise à peu près par deux le débit à qualité équivalente.
La compression de contenu possède une caractéristique déterminante : elle modifie les données internes du fichier, et est souvent avec perte. Une image compressée ne peut pas être restaurée à ses pixels d'origine ; une police sous-ensemblee ne peut pas être réassemblée en une typographie complète. La contrepartie, c'est que le fichier devient plus petit à la source — aucune extraction nécessaire, il est prêt à l'emploi tel quel.
Une comparaison visuelle
Le diagramme ci-dessous illustre la différence fondamentale de flux de travail entre les deux approches :
Le chemin de gauche est un cycle « regrouper–transmettre–extraire–restaurer » où le contenu des fichiers ne change jamais. Le chemin de droite est un processus à sens unique « analyser–optimiser–générer » où le fichier lui-même est reconstruit.
Exemples de code : voir la différence
Python rend la distinction parfaitement claire.
Compression d'archive avec zipfile
import zipfile
import os
# Compression d'archive : regrouper plusieurs fichiers dans un seul zip
source_files = ['report.pdf', 'photo.jpg', 'data.csv']
archive_name = 'bundle.zip'
with zipfile.ZipFile(archive_name, 'w', zipfile.ZIP_DEFLATED) as zf:
for file in source_files:
zf.write(file)
# Mesurer le résultat
original = sum(os.path.getsize(f) for f in source_files)
packed = os.path.getsize(archive_name)
print(f"Original total: {original / 1024 / 1024:.2f} MB")
print(f"Archive size: {packed / 1024 / 1024:.2f} MB")
print(f"Ratio: {packed / original * 100:.1f}%")
# Résultat typique (fichiers déjà dans des formats compressés) :
# Original total: 58.30 MB
# Archive size: 57.10 MB
# Ratio: 97.9%
Remarquez le ratio — presque aucun changement. Comme ces fichiers sont déjà dans des formats compressés, la compression d'archive est impuissante.
Compression de contenu avec PIL
from PIL import Image
import os
# Compression de contenu : optimiser les données de l'image elles-mêmes
src = 'photo.jpg'
dst = 'photo_optimized.jpg'
img = Image.open(src)
before = os.path.getsize(src)
# Compression de contenu en trois volets
img.thumbnail((1920, 1080)) # réduire la résolution
img.save(dst, 'JPEG',
quality=75, # qualité plus basse
optimize=True, # optimiser les tables de Huffman
progressive=True) # encodage progressif
after = os.path.getsize(dst)
print(f"Original size: {before / 1024 / 1024:.2f} MB")
print(f"Optimized size: {after / 1024:.2f} KB")
print(f"Ratio: {after / before * 100:.1f}%")
# Résultat typique :
# Original size: 8.20 MB
# Optimized size: 480.50 KB
# Ratio: 5.7%
Même mot — « compression » — pourtant l'un transforme 58 Mo en 57 Mo tandis que l'autre transforme 8 Mo en 480 Ko. L'écart vient de ce que chacun touche : le premier se contente de réorganiser le conteneur, le second réécrit le contenu.
Comparaison en un coup d'œil
| Dimension | Compression d'archive | Compression de contenu |
|---|---|---|
| Ce qu'elle fait | Regroupe les fichiers et élimine la redondance | Optimise les données internes d'un fichier |
| Cible | Conteneur de fichiers (niveau multi-fichiers) | Contenu du fichier (niveau des données) |
| Méthode | DEFLATE / LZMA et autres algorithmes sans perte | Rééchantillonnage / transcodage / sous-ensemble |
| Perte | Sans perte ; entièrement restaurable à l'extraction | Surtout avec perte ; non réversible |
| Utilisation | Doit être extrait avant usage | Utilisé directement, sans extraction |
| Scénario typique | Transfert de plusieurs fichiers, sauvegardes | Réduction de taille, optimisation web, pièces jointes |
| Efficacité | Dépend de la redondance ; quasi nulle sur les fichiers déjà compressés | Peut atteindre des ratios de compression de 10x et plus |
Étude de cas : deux destins d'un PDF de 50 Mo
Prenez un vrai PDF de 50 Mo (plusieurs pages d'images numérisées en haute résolution) et comparez :
Approche A : compression d'archive
- Outil : 7-Zip, LZMA2 ultra
- Résultat : 50 Mo → 49,2 Mo
- Pourquoi : les flux d'images internes du PDF sont déjà compressés en JPEG avec DCTDecode, et les flux de polices utilisent FlateDecode. La compression d'archive ne trouve aucune redondance à exploiter.
Approche B : compression de contenu
- Opérations : sous-échantillonner les images intégrées à 150 DPI, abaisser la qualité JPEG à 75, sous-ensembler les polices, supprimer les objets non référencés
- Résultat : 50 Mo → 6,8 Mo
- Pourquoi : la compression cible le gros du PDF — les numérisations haute résolution. À 150 DPI, la lecture à l'écran paraît virtuellement identique, pourtant le fichier est sept fois plus petit.
Les deux « compressions » produisent un écart de 7x. Si votre objectif est d'envoyer ce PDF par e-mail, l'approche B est la réponse ; l'approche A gaspille juste de l'effort.
Choisir la bonne approche
Avec les deux outils en main, la décision devient simple. Demandez-vous ce que vous cherchez à accomplir :
- Besoin de déplacer plusieurs fichiers à la fois ? Optez pour la compression d'archive. Elle regroupe, contrôle et élimine la redondance inter-fichiers en une seule étape — idéale pour les sauvegardes, la distribution de code source et le transfert de structures de dossiers.
- Besoin qu'un seul fichier soit plus petit ? Optez pour la compression de contenu. Un PDF de 50 Mo destiné à un e-mail ne rétrécira pas dans un ZIP, mais il rétrécira considérablement une fois ses images internes sous-échantillonnées.
- Besoin des deux ? Appliquez d'abord la compression de contenu sur chaque fichier, puis regroupez les résultats avec la compression d'archive. L'ordre n'est pas négociable : l'optimisation du contenu doit avoir lieu tant que les éléments internes du fichier sont encore accessibles, avant d'être scellés dans une archive.
Un modèle mental utile : la compression d'archive réduit le coût du transport, tandis que la compression de contenu réduit le coût du stockage. Si votre fichier est déjà assez petit pour être transporté mais vit durablement sur un serveur, la compression de contenu rapporte en bande passante économisée à chaque téléchargement. Si vous livrez simplement un lot de fichiers une fois, la compression d'archive est l'option la plus légère.
Questions fréquentes
Q1 : Pourquoi 7-Zip réduit-il à peine les PDF, JPG ou MP4 ?
Parce que ces fichiers sont déjà des formats compressés. Les PDF compriment les flux d'images et de polices en interne avec DEFLATE ; les JPG compriment les données d'image avec des transformations DCT ; les MP4 compriment les images vidéo avec H.264/H.265. Les algorithmes d'archive font face à des données déjà pressées, il ne reste donc aucune redondance statistique à retirer. La compression d'archive est efficace sur les données brutes non compressées — BMP, WAV, texte brut.
Q2 : La compression de contenu perd-elle en qualité ? Comment équilibrer taille et qualité ?
La plupart des compressions de contenu sont avec perte, mais le degré de perte est contrôlable. Pour les images, vous échangez la taille contre la netteté en ajustant la résolution et la qualité — 72-96 DPI à qualité 75 convient généralement aux écrans, tandis que l'impression exige 300 DPI. Le sous-ensemblement des polices est sans perte et n'affecte pas l'affichage. L'essentiel est d'adapter le niveau de compression au cas d'usage, et non d'appliquer un réglage universel.
Q3 : La compression d'archive et la compression de contenu peuvent-elles être utilisées ensemble ?
Oui, et elles le sont souvent. Le flux de travail type : appliquer d'abord la compression de contenu pour réduire chaque fichier à la source, puis appliquer la compression d'archive pour regrouper les fichiers plus petits en vue du transfert. L'ordre compte — contenu d'abord, archive ensuite. Inverser l'ordre verrouille la structure du fichier à l'intérieur de l'archive, empêchant la compression de contenu d'intervenir. Optimisez le contenu d'abord, puis regroupez, et vous captez les avantages des deux.
Conclusion
La compression d'archive et la compression de contenu portent toutes deux le nom de « compression », mais elles opèrent sur des couches différentes. La compression d'archive agit au niveau du conteneur — regroupant et éliminant la redondance sans perte, avec un effet limité sur les fichiers déjà compressés. La compression de contenu agit au niveau des données — reconstruisant les éléments internes du fichier, souvent avec perte, mais le réduisant à la source.
La prochaine fois que vous vous retrouverez devant un fichier « compressé » qui n'a pas rétréci, demandez-vous : est-ce que je comprime le conteneur, ou le contenu ? Choisissez la bonne couche, et la compression fera enfin son travail.
Lectures associées :
- Guide complet de la compression de fichiers : principes et méthodes de compression PDF/image/vidéo/document
- Compression sans perte vs compression avec perte
Besoin de compresser des fichiers ? Essayez SmartSlim
Basé sur un moteur de compression Rust développé en interne, prenant en charge 10 catégories et plus de 40 formats dont PDF, images, vidéo, Office et OFD, avec une compression locale qui conserve vos données sur place.