14 algorithmes de compression passés au crible : 4 000 résultats dans un tableau interactif
rm -fr >> all pour ce qui est de la taille finale !
Le meilleur algorithme de compression n’est pas forcément le plus rapide et vice-versa. Le meilleur choix dépend généralement des usages, mais comment faire ce choix ? Next vous aide avec 14 algorithmes, 10 catégories de données et 3 niveaux de compression. Près de 4 000 résultats vous attendent, avec un classement interactif dont vous êtes le héros !
Le 12 novembre à 11h17
5 min
Logiciel
Logiciel
Il y a quelques jours, nous avons testé le nouvel algorithme de compression OpenZL de Meta. Un autre est sorti récemment, Turbosqueeze. Son créneau est la vitesse de traitement : « Turbosqueeze propose des compressions et décompressions très rapides, ce qui le rend idéal pour les charges de travail exigeantes, les fichiers volumineux et les systèmes en temps réel ».
Spoiler sur Turbosqueeze : il est en effet rapide, mais n'est pas systématiquement premier, loin de là. Niveau compression des données, par contre, il est toujours loin de la tête de course. Ses meilleurs résultats sont dans la catégorie CSV avec la vitesse la plus élevée et un niveau de compression semblable à lz4 et lzop.

Nous l’avons intégré à un comparatif plus large, aux côtés d’autres algorithmes, avec de la décompression cette fois-ci (comme certains le demandaient). Pour améliorer notre protocole et dépendre le moins possible du stockage, nous effectuons désormais l’ensemble des tests de compression et décompression dans un ramdisk. Il s’agit pour rappel d’un espace de stockage créé en mémoire vive, bien plus rapide que les HDD et les SSD.
Les algorithmes : OpenZL, Turbosqueeze, zstd, rar, rip, brotli, zopfli…
Nous avons tout d’abord effectué un fichier d’archive avec la commande TAR. Aucune compression ici, mais un mètre étalon. Du côté des algorithmes, OpenZL avec le profil serial qui s’adapte à tous les types de fichiers. Un coup de Turbosqueeze ensuite.
Viennent ensuite des algorithmes plus classiques : zstd, xz (attention, une porte dérobée a été détectée en 2024), gzip, bzip2, 7zip, zip, lz4, rar, brotli, pixz, lzop et zopfli. Lorsque plusieurs niveaux de compression sont disponibles, nous lançons plusieurs tests avec les niveaux 1, 5 et 9.
La quantité de données qui en résulte est relativement importante puisque, pour chaque type de données, nous avons une quarantaine de tests (plus d’une dizaine d'algorithmes avec pour la plupart trois niveaux de compression).
Ci-dessous les tableaux de seulement trois des dix catégories de fichiers testés. Comme toujours, nous vous proposons également l’intégralité des résultats dans une feuille de calcul avec toutes les données exploitables.

Un score final personnalisable selon vos besoins (débit, compression)
Il reste 60% de l'article à découvrir.
Déjà abonné ? Se connecter
Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.
Accédez en illimité aux articles
Profitez d'un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
14 algorithmes de compression passés au crible : 4 000 résultats dans un tableau interactif
-
Les algorithmes : OpenZL, Turbosqueeze, zstd, rar, rip, brotli, zopfli…
-
Un score final personnalisable selon vos besoins (débit, compression)
-
Feuille de calcul à partager ou fichier ODS à télécharger, au choix
-
Précisions sur le protocole
-
Des graphiques sur le niveau de compression
Commentaires (22)
Le 12/11/2025 à 11h22
Le 12/11/2025 à 12h04
Modifié le 12/11/2025 à 12h59
shred. J'ai été étonné que ça arrive au bout de la 1ere passe. Au milieu de la 2eme passe cependant, j'ai fini par perdre le sshModifié le 12/11/2025 à 16h44
Modifié le 12/11/2025 à 19h11
Y a pas que la taille qui compte !
Le 12/11/2025 à 11h41
Le 12/11/2025 à 12h18
Le 12/11/2025 à 12h20
Modifié le 12/11/2025 à 15h54
Ceci dit, zstd a une particularité qu'aucun des autres ne possède (à ma connaissance) c'est le système de compression adaptatif.
J'essaie d'expliquer: Imaginez que vous voulez "dumper" un disque avec dd :
dd | compression > fichierdestination
On veut que le fichier de destination soit le plus compressé possible, mais sans perdre de temps.
- Si vous choisissez un taux de compression trop fort, la compression sera plus lente que la lecture du disque. Vous allez perdre du temps.
- Si vous prenez une compression plus faible, vous irez au maximum de la vitesse des disques, mais vous allez sans doute perdre de la place.
Comment choisir le taux de compression optimal ?
Et bien avec zstd il suffit d'ajouter --adapt et zstd va s'adapter aux débits entrants et sortant : Il va faire varier le taux de compression pour avoir la compression maximale sans ralentir les entrées/sorties.
Modifié le 12/11/2025 à 15h56
J'utilise zstd sous Linux pour la compression transparente de tout le système de fichier (en btrfs). La place gagné est phénoménale et zstd est tellement rapide que ça ne ralentit pas le système.
Le 12/11/2025 à 12h28
Modifié le 13/11/2025 à 09h46
Modifié le 12/11/2025 à 12h37
J'aurais aimé y voir aussi zpaq (en mode -m4), parce que ce compresseur a des particularités très intéressantes (comme une phase de déduplication avant la compression) qui sur de gros ensembles de données (>10 Go) donne bien souvent des résultats que même 7zip en mode -mx=9 ne pourra pas atteindre. (Je parle de plusieurs giga-octets de différence avec 7zip en mode 9 sur certains jeux de données).
À noter aussi qu'il est possible d'augmenter considérablement les performances de compression de 7-Zip avec des options dans la ligne de commande qui ne sont pas présente dans la documentation utilisateur, mais dans la doc technique.
Au prix d'une consommation mémoire plus élevée, on obtient de bien meilleurs taux de compression qu'avec -mx=9
Modifié le 12/11/2025 à 13h19
- non compressé : 211 938 580 octets
- 7-Zip -mx=9 : 48 688 231 octets.
- 7-Zip avec options modifiées : 47 896 854
- zpaq -m4 : 43 372 826
(on oublie le zpaq -m5 qui a des temps de compression/décompression bien trop importants pour être utilisable.)
La différence peut sembler faible, mais elle est amplifiée par la taille des données à compresser, en particulier quand votre jeu de données dépasse la taille de la "fenêtre" de compression de 7-Zip -mx=9.
C'est à dire que dès que vos données se comptent en giga-octets, l'impact sur la compression sera beaucoup plus important.
Le 12/11/2025 à 13h22
Le 12/11/2025 à 13h35
Modifié le 12/11/2025 à 15h51
Je me souviens d'autres jeux de données un peu plus volumineux qui pourraient être intéressant, par exemple celui du Hutter Prize (http://prize.hutter1.net/), justement un prix décerné aux meilleurs compresseurs. Ce jeu fait 1 Go. Et il est intéressant car il contient à la fois des données structurées et du texte. (C'est un export de Wikipedia).
Concernant mes bidouille avec 7-Zip pour compresser plus fort qu'avec -mx=9, j'ai documenté ça là : https://sebsauvage.net/links/?s0zmfA
Inconvénient : c'est plus long à compresser et ça consomme beaucoup plus de RAM (10 Go à la compression), mais ça compresse bien mieux. (À la décompression, il faut 1 Go de RAM, ce qui n'est pas excessif pour les machines actuelles).
Le 12/11/2025 à 12h40
Le 12/11/2025 à 12h59
Le 12/11/2025 à 13h48
Le 12/11/2025 à 14h26
J'étais déçu de ne pas trouver de référence, alors met les pieds dans le plat !
Le 13/11/2025 à 12h34
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?