Les outils de compression affirment le plus souvent des chiffres invérifiables, comme « une réduction de 70 % ». Cet article ne cite aucune statistique sectorielle : il présente uniquement un ensemble de résultats de test réels, accompagnés d'une méthode comparative complète que chacun peut reproduire.
1. Objet du test : des images déjà compressées, et non des fichiers bruts
La plupart des tests de compression utilisent des images brutes directement issues de l'appareil photo, des conditions trop idéales. Ce test se rapproche volontairement d'un scénario métier réel : un site qui permet aux utilisateurs de téléverser des images a déjà appliqué une compression standard à l'entrée en base — autrement dit, l'objet du test n'est pas une image brute non traitée, mais une image finale qui a déjà été « compressée une fois ».
Taille de l'échantillon : 78 dossiers, soit 4 624 images (principalement des JPG), avec une structure de répertoires typique « un album par dossier », sans filtrage ni nettoyage.
Le volume total initial de ces fichiers sur le serveur : 1.41 GB.
Question centrale : une image déjà traitée par un outil de compression remise à un autre outil de compression permet-elle encore d'économiser de l'espace ? L'intuition de la plupart des utilisateurs est « qu'une fois compressée, c'est fini ; refaire une passe n'a pas d'intérêt ».
2. Groupe de contrôle : combien un zip peut-il économiser ?
Avant d'exécuter ImgZilla, on compresse le même lot de fichiers dans un zip sans modification, pour observer l'effet d'un algorithme de compression générique :
| Volume | Par rapport à l'original | |
|---|---|---|
| Fichiers d'origine déjà compressés par le site | 1.41 GB | — |
| Archive zip | 1.41 GB | -0.2 % |
Quasi aucun changement. La raison n'est pas compliquée : JPEG est lui-même un format compressé, les données image ont déjà subi un codage entropique, et les algorithmes génériques (zip utilise DEFLATE) parviennent difficilement à compresser des données déjà compressées — que l'image initiale ait été traitée par le site ou non, zip n'y peut rien.
3. Re-compression réelle avec ImgZilla
Glissez les fichiers ci-dessus dans ImgZilla et lancez une compression en place. Les 78 dossiers et 4 624 images conservent intégralement leurs noms de fichiers et leur arborescence :
| Volume | Par rapport à l'original | |
|---|---|---|
| Fichiers d'origine déjà compressés par le site | 1.41 GB | — |
| Archive zip | 1.41 GB | -0.2 % |
| Après re-compression ImgZilla | 0.75 GB | -46.8 % |
Sur la base de la compression déjà réalisée par le site, ImgZilla économise encore environ 662 MB, soit près de la moitié du volume. Tous les chemins de dossiers, noms de fichiers et niveaux de hiérarchie sont strictement identiques avant/après — ce sont des données réelles, vérifiables, et non un argument marketing.
Cela montre un fait essentiel : « compressé lors de l'envoi sur le site » et « compression fine avec des paramètres spécifiques au format » sont deux choses différentes. La plupart des sites effectuent à l'entrée en base une compression unique et plutôt prudente (souvent limitée au paramètre de qualité ou aux dimensions), loin d'exploiter tout l'espace de codage de chaque format. ImgZilla règle des paramètres dédiés pour chaque format et applique au JPEG un ré-encodage visuellement sans perte — au niveau des pixels, des changements existent effectivement, mais les paramètres se situent dans une plage quasi imperceptible à l'œil nu, ce qui permet de continuer à gagner de l'espace sur une base déjà compressée.
Il faut clarifier un concept souvent confondu : « sans perte visuelle » ne signifie pas « sans perte ». Le sans perte au sens strict (pixels strictement identiques) ne s'applique qu'au PNG (oxipng) et au SVG ; JPEG, WebP, AVIF, HEIC et GIF sont, par principe, des ré-encodages avec perte, mais les paramètres de compression sont maintenus sous le seuil du sans perte visuel. ImgZilla intègre une fenêtre de comparaison avant/après, en affichage côte à côte, avec zoom à la taille réelle pour un contrôle pixel par pixel.
4. Analyse détaillée : taux de compression par fichier, dimensions en pixels et durée de la tâche
Le taux de compression global de 46.8 % présenté plus haut est le résultat agrégé des 4 624 images. En descendant au niveau des fichiers individuels, on obtient des informations supplémentaires.
Le taux de compression varie selon les images
En calculant un à un le taux de compression de chaque image (octets après compression / octets avant compression), la fourchette va de 32.3 % à 85.8 % :
- Le lot au taux de compression le plus élevé : environ 765 KB compressés à 109 KB, soit 85.8 % — ces images ont généralement bénéficié d'une compression initiale insuffisante et offrent encore une marge de ré-encodage notable.
- Le lot au taux le plus faible : environ 572 KB compressés à 387 KB, soit 32.3 % — ces images ont déjà été fortement compressées et offrent peu de marge.
- La moyenne arithmétique des taux de compression des 4 624 images est de 46.44 %, proche mais non identique aux 46.8 % calculés sur le volume total — la première est une simple moyenne des taux individuels, la seconde est « nombre total d'octets économisés ÷ nombre total d'octets d'origine ». L'écart montre que les fichiers ayant des taux différents n'ont pas un poids symétrique dans le volume total : quelques fichiers volumineux pèsent davantage sur le total.
On notera que toutes les images ont un taux de compression positif, sans aucun cas « déjà réduit à la taille minimale, ignoré » — c'est-à-dire que chacune de ces images déjà compressées par le site peut encore être réduite par ImgZilla.
Dimensions en pixels : strictement inchangées
En relevant les dimensions en pixels des 4 624 images, le format le plus courant est 1600×2400 (1 756 images) et sa variante paysage 2400×1600 (500 images). Les dimensions s'étendent de la plus petite 450×675 (environ 300 000 pixels) à la plus grande 3000×2000 / 2000×3000 (environ 6 millions de pixels).
La vérification par échantillonnage avant/après compression donne des dimensions strictement identiques, aucune modification :
| Fichier (exemple) | Dimensions d'origine | Dimensions après compression |
|---|---|---|
| Échantillon 1 | 1600×1066 | 1600×1066 |
| Échantillon 2 | 2000×3000 | 2000×3000 |
| Échantillon 3 | 1416×2128 | 1416×2128 |
C'est l'autre moitié souvent oubliée de la définition de « compression en place » : non seulement les noms de fichiers et les chemins restent inchangés, mais la résolution est également fixe. ImgZilla ne redimensionne pas ni ne recadre ; toute la réduction de volume provient du ré-encodage, et jamais d'un sacrifice de pixels.
Durée de la tâche : 4 624 images traitées en 51 min 32 s, soit 0.669 s par image en moyenne
Environnement de test : Mac mini avec puce Apple M1, 8 GB de mémoire unifiée ; les images sont stockées sur un disque dur NAS connecté en réseau filaire 2.5G.
La progression de la tâche est suivie via l'horodatage de dernière écriture de chaque image (c'est-à-dire le moment où ImgZilla a terminé la compression et réécrit le fichier sur disque) : la première écriture a eu lieu à 16:06:09, la dernière à 16:57:41, le traitement complet a duré 51 min 32 s, soit une moyenne de 0.669 s par image.
Cette donnée correspond à la conception « en série » du produit : les images sont traitées une par une, dans l'ordre, et non écrites en parallèle dans le désordre. Cela représente environ 90 images par minute. La vitesse réelle dépend du volume des images et des performances de la machine ; la valeur indiquée ici est seulement le temps réel observé pour ces images d'environ 305 KB en moyenne dans cet environnement, et ne constitue pas une référence universelle.
5. Pourquoi choisir la compression « en place » plutôt qu'une copie séparée
Si ce test avait utilisé un outil qui « enregistre une version compressée séparée », le résultat aurait été : fichier d'origine 1.41 GB + version compressée 0.75 GB, soit 2.16 GB au total, prenant encore plus de place et générant de nombreux fichiers xxx-min.jpg à trier manuellement, avec en plus la mise à jour des références dans la base de données ou les tableaux produits.
ImgZilla adopte l'écrasement en place : le résultat de la compression est directement réécrit au même emplacement, et les 4 624 noms de fichiers dans les 78 dossiers restent inchangés — un point crucial pour les sites qui ont déjà enregistré les chemins des images dans une base de données, un CDN ou des références CMS. Après la compression, aucune modification de lien n'est nécessaire. La contrepartie est qu'il modifie le fichier d'origine ; il déplace donc par défaut l'image originale vers la corbeille du système avant d'écrire le résultat compressé. En cas de regret, on peut faire un clic droit dans la corbeille et choisir « Remettre à l'emplacement d'origine ».
6. Analyse des bénéfices : du cas concret à la facture mensuelle
À qui ces données sont-elles réellement utiles ?
- Sites / développeurs qui gèrent des images téléversées par les utilisateurs : le stockage des images et le trafic CDN sont généralement facturés au GB ; diviser le volume par deux signifie diviser la facture par deux — et le coût du trafic est engagé à chaque consultation. Plus le trafic est important, plus l'effet composé est visible. Même si une compression standard est déjà appliquée à l'entrée en base, ce test montre qu'une passe supplémentaire avec des paramètres adaptés peut encore apporter des gains substantiels.
- Serveurs à espace restreint / utilisateurs de disques de faible capacité : les outils de nettoyage suppriment en général les caches et les doublons, mais ces éléments s'accumulent à nouveau après quelques mois ; l'espace dégagé par la compression provient du fait que les fichiers en cours d'utilisation deviennent plus petits, sans effet revenir en arrière. Ce lot de 78 dossiers a directement libéré 662 MB d'espace disponible, et il s'agit d'un gain permanent.
- Utilisateurs qui déplacent souvent des données : lors d'une copie, d'une synchronisation ou d'une sauvegarde, la réduction du volume de 46.8 % raccourcit le temps de transfert dans les mêmes proportions. Compressez une fois, et chacun des transferts ultérieurs sera plus rapide.
Converti en facture mensuelle : combien valent vraiment ces 46.8 % ?
Pour être convaincante, la réduction de volume doit se refléter sur la facture. Le calcul ci-dessous ne s'appuie sur aucune statistique du type « la compression améliore la conversion » : il multiplie simplement les 46.8 % mesurés par les tarifs publics de stockage/trafic des principaux fournisseurs cloud, pour une projection purement arithmétique.
Économie sur le stockage = volume économisé (GB) × prix unitaire (¥ ou $ / GB / mois)
Économie sur le trafic sortant = volume économisé (GB) × nombre de téléchargements/visites dans le mois × prix unitaire (¥ ou $ / GB)
Réduire le volume de moitié réduit globalement ces deux postes de moitié — c'est une question de calcul, pas de spéculation.
Coûts de stockage : plus la bibliothèque est grande, plus le bénéfice est visible
Fournisseurs chinois :
| Taille d'origine de la bibliothèque d'images | Volume économisé | Alibaba Cloud OSS Standard ¥0.09/GB/mois |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/mois |
| 100 GB | 46.8 GB | ¥4.21/mois |
| 1 TB | 479 GB | ¥43.1/mois |
Fournisseurs internationaux :
| Taille d'origine de la bibliothèque d'images | Volume économisé | AWS S3 Standard $0.023/GB/mois |
Google Cloud Storage $0.020/GB/mois (Régional, États-Unis) |
Azure Blob Storage $0.018/GB/mois (Hot, LRS) |
Cloudflare R2 $0.015/GB/mois |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/mois | $0.09/mois | $0.08/mois | $0.07/mois |
| 100 GB | 46.8 GB | $1.08/mois | $0.94/mois | $0.84/mois | $0.70/mois |
| 1 TB | 479 GB | $11.02/mois | $9.58/mois | $8.62/mois | $7.19/mois |
Plusieurs grands fournisseurs internationaux ont des prix de stockage très proches (écart de moins de 30 %). L'important n'est pas de savoir lequel est le moins cher, mais que, quel que soit le fournisseur, diviser le volume par deux divise ce poste de facture par deux, de façon récurrente chaque mois. Une seule compression, puis la facturation est faite sur le nouveau volume tous les mois : c'est un investissement ponctuel dont le bénéfice se concrétise sur le long terme.
Coûts de trafic : le vrai poste important, amplifié par les visites
Le trafic mérite plus d'attention que le stockage, car il s'agit du produit volume × nombre de téléchargements — plus une image est consultée, plus le gain apporté par la compression est élevé. Supposons une bibliothèque d'images de 100 GB qui génère 500 GB de trafic descendant via un CDN dans le mois (l'équivalent d'environ 5 téléchargements complets de la bibliothèque) :
| Tarif CDN / trafic sortant (premier palier) | Facture mensuelle de trafic avant compression | Après compression (trafic réduit de -46.8 %) | Économie mensuelle | Économie annuelle |
|---|---|---|---|---|
| Alibaba Cloud CDN Chine (palier bas ¥0.15/GB) | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront Asie-Pacifique ($0.12/GB) | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN Amérique du Nord / Europe ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door Standard Zone 1 ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
Les prix ci-dessus correspondent au palier le plus bas de chaque fournisseur ; en réalité, les paliers supérieurs sont souvent plus élevés (le trafic CDN chinois d'Alibaba Cloud peut atteindre ¥1.31/GB au palier le plus haut), et plus la facture est importante, plus l'économie absolue liée à la compression est significative. Par ailleurs, l'offre Azure actuelle est Front Door Standard : outre le trafic sortant facturé au GB, elle comprend un forfait de base d'environ $35/mois, qui ne peut pas être réduit par la compression et n'est pas inclus dans les économies indiquées.
Cloudflare R2 fait exception : son trafic sortant est déjà de $0 — si votre bucket utilise R2, le bénéfice de la compression se reporte presque entièrement sur le stockage, le trafic n'ayant pas de facture en soi. Cela diffère d'une architecture de facturation « stockage + trafic » (par exemple Alibaba Cloud OSS+CDN, AWS S3+CloudFront). Il s'agit de structures de coûts différentes ; avant de choisir un fournisseur, il faut bien identifier vos propres postes de facturation.
Les prix unitaires ci-dessus sont issus des tarifs publics des plateformes en 2026 ; les prix réels dépendent de la région, de la remise appliquée au compte et des paliers. Seuls les tarifs officiels en temps réel font foi. Le nombre de téléchargements et de visites est une hypothèse d'exemple ; remplacez-le par les valeurs réelles issues de votre facture pour faire votre estimation.
7. Gain de temps de transfert et de téléversement
Réduire le volume de moitié réduit d'autant le temps de transfert — cette règle ne dépend pas des factures cloud ; elle vaut pour les copies locales, les sauvegardes, et également pour l'étape du téléversement par l'utilisateur.
Scénario local : USB 3 et réseau gigabit
- Disque dur mobile mécanique USB 3 : le débit de lecture/écriture soutenu se situe couramment entre 100 et 150 MB/s ; prenons la médiane, 120 MB/s.
- SSD mobile USB 3 : le débit est nettement supérieur, couramment 400 à 500 MB/s ; prenons 450 MB/s.
- Réseau filaire gigabit (1000 Mbps) : la limite théorique est de 125 MB/s ; en ôtant les frais de protocole, le débit soutenu mesuré se situe autour de 100 à 110 MB/s ; prenons 105 MB/s.
Ces valeurs sont des estimations dans les plages couramment mesurées ; la vitesse réelle dépend du support du disque, de la qualité de l'interface et de l'environnement réseau. Elles ne servent qu'à donner un ordre de grandeur pour l'estimation.
| Scénario | Volume économisé | Disque mécanique USB 3 @120 MB/s | SSD USB 3 @450 MB/s | Réseau gigabit @105 MB/s |
|---|---|---|---|---|
| Le lot d'images de ce test | 662 MB | ≈5.5 s | ≈1.5 s | ≈6.3 s |
| Bibliothèque d'images de 10 GB | 4.68 GB | ≈40 s | ≈10 s | ≈45 s |
| Bibliothèque d'images de 100 GB | 46.8 GB | ≈6.5 min | ≈1.7 min | ≈7.4 min |
| Bibliothèque d'images de 1 TB | 479 GB | ≈66 min | ≈18 min | ≈76 min |
Pour ce lot testé, les 662 MB semblent peu à l'échelle d'une seule fois — quelques secondes. Mais comme pour les coûts de stockage, c'est un investissement ponctuel au bénéfice durable : que vous copiiez vers un disque externe, synchronisiez un NAS, lanciez une sauvegarde Time Machine, migriez vers un nouveau Mac ou transmettiez les fichiers à un collègue, tant que vous continuez à manipuler ces données, vous gagnez du temps dans les mêmes proportions à chaque opération. Compressez une fois, et chaque transfert ultérieur sera plus rapide.
Si la compression a lieu avant le téléversement : un temps d'attente réduit
Les calculs précédents concernent les bénéfices après le stockage des images — stockage, trafic CDN, transfert local. Il reste un maillon encore plus intéressant : le temps d'attente entre le moment où l'utilisateur appuie sur le bouton « Envoyer » et la fin de la barre de progression. Ce temps utilise la bande passante montante de l'utilisateur, qui est souvent le goulot d'étranglement le plus lent de toute la chaîne — sur la plupart des offres grand public, le débit montant ne représente qu'un dixième à un cinquième du débit descendant, et c'est encore plus vrai sur mobile. Si, avant l'envoi par l'utilisateur, le site ou l'application compresse d'abord les images avec ImgZilla, le volume économisé se traduit directement en temps d'attente en moins.
En prenant le volume moyen d'une image de ce test : l'image déjà compressée par le site pèse en moyenne 299 KB ; après la re-compression ImgZilla, elle pèse en moyenne 159 KB, soit une économie moyenne d'environ 140 KB par image.
| Bande passante montante (fourchettes typiques de mesures publiques, à titre indicatif) | Une image 299KB→159KB |
Téléversement d'un album de 50 photos ≈15.0MB→8.0MB |
Téléversement de la totalité des 4 624 images du test 1.41GB→0.75GB |
|---|---|---|---|
| Réseau mobile (moyenne 4G/5G, médiane des mesures publiques chinoises d'environ 10–50 Mbps, retenons 30 Mbps) | gain ≈0.04 s | gain ≈1.9 s | gain ≈3 min |
| Bande passante montante d'une box grand public courante (offres fibre/câble avec descente 100 Mb/s ou 1 Gb/s, montée souvent limitée, environ 20–30 Mbps, retenons 25 Mbps) | gain ≈0.04 s | gain ≈2.2 s | gain ≈3.5 min |
| Bande passante montante symétrique gigabit (rares opérateurs ou liaisons professionnelles, 1000 Mbps) | gain ≈0.001 s | gain ≈0.06 s | gain ≈5.3 s |
| Référence internationale : débit montant moyen du fixe aux États-Unis (données Ookla, 2026) | gain ≈0.02 s | gain ≈1 s | gain ≈1.5 min |
À l'échelle d'une image, ce tableau peut sembler dénué d'intérêt — 0.04 s est presque imperceptible. C'est un résultat honnête : ce lot de test est lui-même assez léger (les images ont déjà été compressées avant d'entrer en base, environ 299 KB en moyenne). Deux scénarios montrent réellement l'intérêt : le téléversement groupé d'un album complet ou de plusieurs dizaines d'images en une seule opération, et les fichiers sources plus volumineux (comme des JPEG directement issus d'un appareil photo ou des contenus générés par les utilisateurs envoyés une première fois sans compression préalable par le site, qui pèsent souvent plusieurs MB au lieu de quelques centaines de KB) — à taux de compression identique, le nombre de secondes économisées augmente dans les mêmes proportions. Pour les utilisateurs mobiles dont le débit montant est déjà lent, la réduction du temps d'attente sera d'autant plus sensible.
Les fourchettes pour le réseau mobile et le haut débit fixe s'appuient sur les statistiques publiques de débit en Chine (médianes 4G/5G, ratios montants/descendants habituels) ; la vitesse réelle varie fortement selon l'opérateur, la région, l'appareil et la congestion du réseau. Elles ne fournissent qu'un ordre de grandeur. Les données de débit montant fixe américain proviennent des rapports Ookla Speedtest.
Envie de vérifier par vous-même ? Téléchargez directement ImgZilla depuis le Mac App Store, faites un test avec quelques images déjà traitées de votre site, puis décidez si vous souhaitez compresser le reste.
Mac App Store : https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
En savoir plus : https://imagetool.app/ImgZilla