Pourquoi compresser deux fois ne divise pas deux fois par deux

La compression retire de la redondance, pas du volume

L'image mentale que porte la plupart des gens est mécanique : le fichier est une éponge, l'outil la presse, et presser plus fort ou deux fois en tire davantage. Cette image prédit qu'une seconde passe devrait aider, et elle se trompe sur ce que fait la machine. Un compresseur cherche des motifs — une séquence d'octets déjà apparue, une couleur répétée sur une zone, une entrée de dictionnaire qui peut tenir lieu d'un mot long — et remplace chaque occurrence par une référence plus courte. Ce qui sort n'est pas les mêmes données pressées plus petit. C'est une description différente, plus brève, des mêmes données.

Une fois cette réécriture faite, les répétitions sont des références et les références ne se répètent pas. Un second compresseur tombe sur un fichier qui ressemble, statistiquement, à du bruit — c'est exactement à cela que ressemblent des données bien compressées — et ne trouve rien à raccourcir. Il doit tout de même écrire son propre en-tête et son encadrement, si bien que la sortie est parfois d'un cheveu plus grosse que l'entrée. Un outil qui annonce un gain nul ou négatif au second passage n'échoue pas ; il dit la vérité sur un fichier déjà traité.

Il y a un plancher, et il a un nom

En 1948, Claude Shannon a montré que tout corps de données a une taille minimale sous laquelle aucune méthode sans perte ne peut l'amener. Ce minimum est son entropie : une mesure de la part réellement imprévisible des données. Une page de texte français est très prévisible — après « qu » un « e » est très probable — donc elle se compresse bien. Un flot de nombres aléatoires n'est pas prévisible du tout, donc il ne se compresse pas, et aucun algorithme futur n'y changera rien. Les outils de compression ne se disputent pas le droit de presser plus fort ; ils se disputent la capacité à mieux modéliser les données et à s'approcher d'une limite déjà fixée.

C'est pourquoi l'expérience familière consistant à zipper un PDF ne gagne rien qui vaille. Les flux internes du PDF sont déjà compressés en deflate et ses images sont déjà des JPEG ; le fichier est proche de son entropie, et le zip n'a pas de matière. Il en va de même d'un MP4, d'un MP3 et d'un PNG. Si un type de fichier se termine par un format conçu pour être petit, suppose que la compression a été faite et qu'un archiveur généraliste ajoutera de l'emballage plutôt qu'il n'ôtera du volume.

Avec perte, c'est une autre machine avec une autre panne

La compression avec perte n'est pas bornée par l'entropie, parce qu'elle n'a pas à reproduire l'original. Elle décide de ce qu'une personne ne remarquera pas — variations fines de couleur, détail à haute fréquence, sons masqués par des sons plus forts — et le jette. C'est pourquoi un JPEG fait le dixième de l'image brute dont il vient, et pourquoi la seconde passe se comporte si différemment : il y a toujours plus à jeter, donc le fichier rapetisse toujours, et la question passe de « est-ce possible ? » à « à quel prix ? ».

Le coût est la perte de génération, et elle se cumule d'une façon qui surprend. Chaque ré-encodage commence par décoder le résultat précédent, lequel contient déjà les artefacts introduits par la passe d'avant. La nouvelle passe traite ces artefacts comme du détail réel digne d'être préservé, dépense des bits dessus, et ajoute les siens. Cinq enregistrements à une bonne qualité produisent une sortie visiblement pire — blocs autour des contours, bavures de couleur, un empâtement général — qu'un seul enregistrement à une qualité bien plus basse atteignant la même taille. La règle qui en découle est la seule qui compte en pratique : compresse toujours depuis l'original, jamais depuis une copie compressée.

Lequel des deux fait un outil donné ?

Le comportement t'le dit. Un outil sans perte donne un gain modeste et reproductible au premier passage et à peu près nul au second, et sa sortie est identique au pixel près à l'entrée. Un outil avec perte propose un curseur de qualité ou des préréglages — léger, moyen, fort — et continue de produire des fichiers plus petits à mesure que tu pousses. Si un outil fait passer un PDF scanné de 20 Mo à 3 Mo, il ré-encode les images et il est avec perte, quoi que dise le bouton. Le compresseur de ce site est du premier type : il réécrit la structure d'objets du PDF et laisse chaque octet d'image intact, si bien qu'il ne te donnera jamais un chiffre spectaculaire sur un scan, et qu'il ne dégradera jamais en silence un document que tu te apprêtes à déposer quelque part d'officiel.

Le seul cas où une seconde passe aide réellement

Relancer le même algorithme deux fois ne sert à rien. En lancer un autre sur le même original, si. Une méthode plus forte, avec un meilleur modèle des données — un archiveur moderne plutôt qu'un classique, ou un format d'image plus récent plutôt qu'un ancien — peut battre le premier résultat, parce que c'est une meilleure tentative sur la même limite et non une seconde tentative sur un problème déjà résolu. Ré-encoder un JPEG en AVIF ou en WebP depuis le fichier d'origine donne typiquement plus petit à qualité égale ; rezipper un zip, non.

Deux conséquences pratiques. Garde les originaux : dès que tu n'as plus que la copie compressée, toute amélioration future des formats t'est fermée, parce que tu ne peux plus compresser depuis quelque chose d'intact. Et quand un fichier reste obstinément trop gros après une passe honnête, cesse d'attraper le compresseur et change plutôt quelque chose de structurel — moins de pages, une résolution plus basse, un extrait plus court, un découpage en deux fichiers. Ce sont des décisions sur le contenu, et c'est dans le contenu que sont réellement les octets restants.

Que faire au lieu de rappuyer sur le bouton

Fais la passe sans perte une fois et prends le chiffre qu'elle donne pour la vérité sur ce fichier. Si cela ne suffit pas, identifie où sont les octets avant toute autre chose : dans un PDF, divise la taille par les pages ; dans une vidéo, multiplie la durée par le débit ; dans une image, regarde les dimensions en pixels. Puis agis sur cette chose précise, une fois, depuis l'original. Deux décisions prises délibérément valent mieux que cinq passes fais avec espoir, et elles te laissent un fichier plus petit qui n'est pas passé cinq fois à la moulinette.

Questions fréquentes

Mon fichier a grossi après compression. Comment est-ce possible ?

Parce que le compresseur doit tout de même écrire sa propre comptabilité — un en-tête, un dictionnaire, un encadrement autour des données — et s'il ne trouve aucune redondance à retirer, cette comptabilité est un pur ajout. C'est le résultat normal sur des données déjà compressées ou réellement aléatoires, et c'est un signal plutôt qu'une faute : le fichier était déjà à son plancher ou tout près. Garde l'original et passe à un changement structurel.

Cela veut-il dire que la compression sans perte est faible ?

Non — cela veut dire qu'elle est honnête. Sur des données à redondance réelle elle est très efficace : un export de base, un fichier de journal ou un PDF riche en texte peuvent perdre une grande part de leur taille sans qu'un seul bit d'information change. Ce qu'elle ne fera pas, c'est inventer de la place là où il n'y en a pas, et elle ne dégradera pas ton document pour produire un plus joli chiffre. Sur tout ce que tu pourrais avoir à défendre plus tard — un dépôt, un contrat signé, un scan original — c'est exactement la propriété que tu veux.

La perte de génération est-elle visible dès un seul ré-enregistrement ?

Rarement, à un réglage de qualité raisonnable et si rien d'autre n'a changé. Elle devient visible quand les ré-enregistrements s'accumulent, quand le réglage de qualité est bas, ou quand l'image est aussi redimensionnée entre deux enregistrements — le redimensionnement force un ré-encodage complet et interagit mal avec les artefacts de blocs déjà présents. La bonne habitude n'est pas de compter les passes mais d'éviter la situation : garde l'original, et produis chaque sortie dont tu as besoin directement depuis lui plutôt que depuis le dernier export.

Pourquoi le même outil gagne-t-il 40 % sur un PDF et 2 % sur un autre ?

Parce que le gain dépend entièrement de la redondance que portait le fichier, et celle-ci varie énormément selon la façon dont il a été fabriqué. Un PDF exporté plusieurs fois depuis un éditeur, ou produit par un système de modèles qui répète une définition à chaque page, est plein de duplication retirable. Un PDF écrit une fois par une bibliothèque bien élevée, ou qui est essentiellement une pile de photographies, n'en a presque pas. Le pourcentage est un fait sur l'histoire du fichier, pas une note attribuée à l'outil.

Faut-il ajouter un archiveur plus fort par-dessus, comme 7-Zip ?

Seulement sur des données pas encore compressées. Un archiveur plus fort a un meilleur modèle et battra un plus faible sur du texte, du code source, des bases de données et des exports bruts — parfois nettement. Sur un PDF, un JPEG, un MP3 ou un MP4, il travaille sur des données déjà proches de leur plancher, et le gain sera d'un ou deux pour cent pour le prix d'un conteneur que le destinataire doit décompresser. Utilise l'archiveur fort là où vit la redondance, pas sur des fichiers à qui on a déjà retiré la leur.