Compression sans perte

La compression sans perte réduit la taille des fichiers tout en préservant chaque octet de l’original. La décompression produit une sortie identique bit à bit à l’entrée. Compromis : économies moindres que la compression avec perte — réduction de taille typique de 30 à 70 % selon le contenu.

Comment ça fonctionne : les algorithmes sans perte trouvent des patterns statistiques (sous-chaînes répétées, séquences prévisibles) et les encodent avec des représentations plus courtes. Deux familles classiques :

• À base de dictionnaire (LZ77, LZ78, LZW) : construisent un dictionnaire des sous-chaînes vues et émettent des rétro-références. Fondement de DEFLATE, gzip, ZIP.
• Codage entropique (Huffman, codage arithmétique, ANS) : attribuent des codes binaires plus courts aux symboles plus fréquents. Généralement combiné avec des méthodes à dictionnaire.

Formats sans perte courants :

• PNG — images (utilise DEFLATE)
• FLAC — audio (préserve PCM 16-24 bits, typiquement 50-60 % de la taille WAV)
• ZIP, gzip, Brotli, Zstandard — données générales
• WebP et AVIF — supportent tous deux les modes sans perte
• Fichiers pack Git — stockage de dépôts de code source

Utilisez sans perte quand vous avez besoin d’une reproduction bit à bit, quand le contenu sera édité davantage, ou quand le fichier est du texte/données structurées (qui ne se compressent pas bien avec perte de toute façon).

Le plafond théorique de l’information : le papier de Claude Shannon de 1948 a établi que la compression sans perte ne peut pas descendre en dessous de l’entropie de la source — l’information moyenne par symbole. Pour les données aléatoires (octets aléatoires, texte chiffré, fichiers déjà compressés), l’entropie est maximale et la compression sans perte atteint essentiellement zéro économie. C’est pourquoi « gzip image.jpg » ne gagne presque rien ; les octets JPEG semblent déjà aléatoires à un compresseur. Le corollaire : si votre taux de compression est étonnamment bon sur des données qui devraient être à haute entropie, vous avez probablement trouvé un bug.

Sans perte sur des données avec perte — quand ça vaut : une confusion courante est de choisir FLAC plutôt qu’une source MP3 à 128 kbps, en espérant une meilleure qualité audio. Le MP3 a déjà éliminé des informations ; FLAC préserve simplement sans perte la version dégradée. Pour l’audio qui a originé en PCM 16 bits (CD, masters de studio), FLAC est le bon choix d’archivage. Pour l’audio qui a originé avec perte, transcoder en FLAC ne fait qu’augmenter la taille du fichier. La règle générale : stocker le master dans le format sans perte de la plus haute qualité que la source supporte ; livrer via le meilleur format avec perte que le consommateur peut lire. Voir aussi : DEFLATE, avec perte, entropie. Référence : Shannon CE, A Mathematical Theory of Communication (Bell Syst Tech J, 1948).

Exemple de calcul : compression d’un fichier log de 10 Mo

Un fichier log d’application typique de 10 Mo (lignes JSON avec timestamps, niveau, message, noms de champs répétés) est très redondant. Chiffres réels d’un benchmark récent sur la même entrée : gzip niveau par défaut ≈ 1,6 Mo (réduction de 84 %, 0,2 s d’encodage), Brotli niveau 6 ≈ 1,1 Mo (89 %, 0,5 s), Zstandard niveau 3 ≈ 1,3 Mo (87 %, 0,05 s), Zstandard niveau 19 ≈ 0,9 Mo (91 %, 1,8 s). Les octets aléatoires (10 Mo depuis /dev/urandom) se compressent à quelques octets près de 10 Mo dans chaque algorithme — incompressibles car haute entropie. Les images PNG déjà compressées rétrécissent de 1 à 3 % sous gzip -9, c’est pourquoi les serveurs HTTP sautent généralement Content-Encoding: gzip sur les réponses PNG/JPEG/MP4 pour économiser le CPU.

Choisir un algorithme en 2026

Pour la livraison web : Brotli au niveau 5-6 pour les actifs statiques (meilleur ratio à un temps d’encodage acceptable, supporté dans tous les navigateurs modernes depuis 2017), gzip en repli pour les clients anciens. Pour le stockage interne et les pipelines : Zstandard, qui domine la frontière Pareto ratio de compression/vitesse à la plupart des niveaux de qualité et est désormais le défaut dans tar, les modules du noyau Linux, RocksDB et le format de package npm. Pour l’archivage de masters irremplaçables : utilisez toujours un conteneur qui inclut une somme de contrôle (xz avec SHA-256, ou zip avec CRC + SHA-256 externe) — la compression elle-même ne détecte pas la pourriture des bits. Référence : RFC 8878 — Compression Zstandard et type de média application/zstd.