L'article précédent testait des images finales déjà compressées une fois par le site, et ImgZilla a encore économisé 46,8 %. Celui-ci part à l'autre extrême : des photos originales sorties directement d'un appareil photo ou d'un smartphone, sans jamais avoir été traitées par aucun outil. Là encore, aucune statistique sectorielle citée : uniquement un test réel et les résultats, avec la méthode de comparaison.
1. Objet du test : de véritables « photos originales »
L'échantillon précédent avait un prérequis : les images avaient déjà subi une compression à leur entrée dans la base du site ; ce n'étaient donc plus des images brutes. Cette fois, le prérequis est supprimé : on teste des JPEG exportés directement par un appareil photo / un smartphone, sans outil de compression, sans « enregistrer sous », sans second encodage.
Taille de l'échantillon : 32 188 JPEG, répartis dans 16 sous-répertoires « bucket », sans tri ni nettoyage pour le test.
Le volume total de ces fichiers : 99,9 Go (environ 93 Gio).
Les caractéristiques d'image sont elles aussi très typiques — toutes les résolutions standard de sortie d'un appareil photo / smartphone :
| Résolution | Nombre d'images | Part |
|---|---|---|
| 4000×3000 (12 MP) | 19 867 | 61,7 % |
| 4032×3024 (12 MP, iPhone) | 3 529 | 11,0 % |
| 3456×4608 (16 MP, portrait) | 2 631 | 8,2 % |
| Autres (3120×4208, 4608×3456, 2448×3264…) | 6 161 | 19,1 % |
En moyenne : 11,5 mégapixels et 2,96 Mo par image ; la plus grande fait 18,3 Mo et 30 mégapixels. Voilà le genre de photos que l'on prend avec un téléphone ou un appareil photo et qu'on ne retouche jamais.
Question : sur ces photos originales que personne n'a touchées, combien un outil de compression spécialisé peut-il encore faire perdre ?
2. Résultat : 76,8 % économisés, 99,9 Go réduits à 23,1 Go
Les 32 188 images ont été compressées une à une sur place, sans changer les noms de fichiers, l'arborescence ni la résolution :
| Volume | Par rapport à l'original | |
|---|---|---|
| Photos originales de l'appareil | 99,9 Go | — |
| Après compression ImgZilla | 23,1 Go | -76,8 % |
Une seule compression économise environ 76,7 Go ; le résultat ne pèse plus qu'un quart du volume initial. Les 32 188 chemins relatifs, noms de fichiers et niveaux de répertoires restent strictement identiques avant/après — c'est directement vérifiable sur les données réelles.
Comparaison avec l'article précédent :
| Lot testé | Source des images | Taux de compression ImgZilla |
|---|---|---|
| Article précédent (4 624 images) | Images finales déjà compressées une fois par le site | -46,8 % |
| Cet article (32 188 images) | Photos originales issues directement d'appareil photo / smartphone | -76,8 % |
Conclusion directe : plus l'image est brute, plus il reste de matière à exploiter. La compression faite à l'entrée du site a déjà éliminé une partie de la redondance ; il en restait 46,8 % pour ImgZilla. Dans les photos issues directement de l'appareil, cette redondance est restée intacte, et ImgZilla peut en retirer 76,8 % en une seule passe.
3. Pourquoi les photos originales d'appareil photo se compressent-elles autant ?
Quand un appareil photo ou un smartphone génère un JPEG, sa priorité est « ne pas perdre de détails », pas « faire le fichier le plus petit possible ». Résultat : le JPEG contient beaucoup de volume sans aucun apport pour la qualité d'image.
- Paramètres de qualité prudents : les JPEG directement produits utilisent souvent des tables de quantification allant de 90 à 98 ; l'œil ne distingue plus la différence apportée par une qualité supérieure, mais le nombre d'octets, lui, varie beaucoup.
- Codage entropique générique et non optimal : le codage direct utilise des tables de Huffman standard fixées, sans calculer le codage optimal pour chaque image, sans quantification trellis ni optimisation du balayage progressif.
- Un paquet de métadonnées annexes : EXIF, GPS, champs propriétaires du fabricant, miniature d'aperçu incluse, profil colorimétrique — le tout pèse souvent plusieurs dizaines, voire centaines de Ko.
ImgZilla applique aux JPEG un recodage à perte visuellement imperceptible : il réorganise le codage entropique avec une stratégie plus efficace, ramène les paramètres de quantification dans une plage indiscernable pour l'œil et supprime les métadonnées redondantes. Au niveau des pixels, il y a bien une modification, mais les paramètres sont choisis pour qu'elle soit quasiment invisible. Sur un matériau aussi riche en redondance que des photos originales, une passe suffit à en retirer les trois quarts.
Précisons un terme souvent mal employé : « sans perte visible » ne signifie pas « sans perte ». Le sans perte (pixels absolument identiques) ne concerne que le PNG (oxipng) et le SVG ; JPEG, WebP, AVIF, HEIC et GIF sont par nature des recodages avec perte, mais avec des paramètres placés dans la plage visuellement sans perte. Si vous ne voulez pas nous croire sur parole, ImgZilla intègre une fenêtre de comparaison avant/après, en écran partagé, avec un zoom jusqu'à la taille réelle pour une vérification pixel par pixel. Regardez par vous-même.
4. Détail : ratio de compression par fichier, dimensions, cas extrêmes
Le chiffre de 76,8 % ci-dessus est la comparaison du volume total des 32 188 images. En descendant à l'échelle du fichier, on voit plusieurs choses plus précises.
La grande majorité des images perdent 70 % à 90 %
En appariant les 32 188 images une à une (« octets avant → octets après ») puis en les classant par pourcentage économisé :
| Pourcentage économisé | Nombre d'images | Part |
|---|---|---|
| 90 %–100 % | 866 | 2,7 % |
| 80 %–90 % | 11 375 | 35,3 % |
| 70 %–80 % | 15 244 | 47,4 % |
| 60 %–70 % | 3 349 | 10,4 % |
| 50 %–60 % | 398 | 1,2 % |
| Moins de 50 % | 956 | 3,0 % |
82,7 % des photos économisent entre 70 % et 90 %. La moyenne arithmétique du ratio par fichier est de 76,6 %, presque identique au 76,8 % calculé sur les volumes totaux — la répartition des gains est donc homogène sur le plan du poids, sans être faussée par quelques très gros fichiers.
En quantiles : plus de la moitié des photos économisent 77 % ou plus ; même les 10 % les moins performants économisent environ 68 % ; seul 1 % environ des photos (p99) descendent sous 40 % d'économie.
Dimensions en pixels : pas un pixel n'a changé
En comparant la résolution des 32 188 images : dimensions_changed vaut false partout — 100 % gardent leur résolution d'origine. ImgZilla ne redimensionne ni ne recadre : les 76,7 Go économisés proviennent uniquement du recodage, pas d'une réduction du nombre de pixels. C'est la moitié de la définition de « compression sur place » qu'on oublie souvent : non seulement les noms de fichiers et les chemins restent identiques, mais la résolution aussi.
Quelques cas extrêmes
| Type | Original | Après compression | Économie |
|---|---|---|---|
| Meilleur ratio de compression | 3,55 Mo (4000×3000) | 100 Ko | 97,2 % |
| Plus grosse économie sur une photo | 17,90 Mo (4000×3000) | 1,13 Mo | 16,8 Mo |
| Cas le moins rentable | 70 Ko (1242×1242) | 68,8 Ko | 2,1 % |
Les images au meilleur ratio (au-delà de 95 % d'économie) sont en général des photos prises avec des paramètres de très haute qualité et chargées de métadonnées. Les moins rentables sont de petites images déjà traitées depuis longtemps. En moyenne, chaque photo pèse 2,38 Mo de moins.
5. Traduction en facture mensuelle : que valent ces 76,8 % ?
Quand le volume diminue, on ne le ressent vraiment que sur la facture. Aucune statistique du genre « la compression améliore le taux de conversion » n'est citée ici. On fait une seule chose : on prend les 76,8 % mesurés, on les multiplie par les tarifs publics actuels de quelques fournisseurs cloud, et on fait un calcul arithmétique.
Économie de stockage = volume économisé (Go) × prix unitaire (yuan ou dollar / Go / mois)
Économie de trafic sortant = volume économisé (Go) × nombre de téléchargements du mois × prix unitaire (yuan ou dollar / Go)
Frais de stockage
| Taille initiale de la photothèque | Volume économisé | Alibaba Cloud OSS Standard 0,09 ¥ / Go / mois |
AWS S3 Standard 0,023 $ / Go / mois |
Google Cloud Storage 0,020 $ / Go / mois |
Cloudflare R2 0,015 $ / Go / mois |
|---|---|---|---|---|---|
| 10 Go | 7,68 Go | 0,69 ¥/mois | 0,18 $/mois | 0,15 $/mois | 0,12 $/mois |
| 100 Go | 76,8 Go | 6,91 ¥/mois | 1,77 $/mois | 1,54 $/mois | 1,15 $/mois |
| 1 To | 786 Go | 70,8 ¥/mois | 18,1 $/mois | 15,7 $/mois | 11,8 $/mois |
| Le lot mesuré ici (99,9 Go) | 76,7 Go | 6,90 ¥/mois | 1,76 $/mois | 1,53 $/mois | 1,15 $/mois |
C'est un coût récurrent mensuel : on compresse une fois, puis chaque mois on est facturé sur le nouveau volume — un investissement unique, un bénéfice continu.
Frais de trafic : le vrai poste important
Le coût du trafic est le produit volume × nombre de téléchargements : plus les images sont consultées, plus la compression rapporte. Exemple : une photothèque de 100 Go génère 500 Go de trafic sortant via un CDN dans le mois (l'équivalent d'environ 5 téléchargements complets de la bibliothèque). Le trafic diminue dans la même proportion que le volume, soit -76,8 %.
| Tarif de sortie CDN (premier palier) | Trafic mensuel avant compression | Après compression | Économie / mois | Économie / an |
|---|---|---|---|---|
| Alibaba Cloud CDN, Chine (0,15 ¥/Go) | 75,0 ¥ | 17,4 ¥ | 57,6 ¥ | 691 ¥ |
| AWS CloudFront, Asie-Pacifique (0,12 $/Go) | 60,0 $ | 13,9 $ | 46,1 $ | 553 $ |
| Google Cloud CDN, Amérique du Nord / Europe (0,08 $/Go) | 40,0 $ | 9,3 $ | 30,7 $ | 369 $ |
Ce sont les tarifs les plus bas de chaque palier ; les paliers réels sont souvent plus élevés, et plus la facture est grosse, plus l'économie absolue est significative. Cloudflare R2 fait exception : son trafic sortant coûte 0 $, l'essentiel du gain se situe donc sur le stockage.
Les tarifs listés proviennent des offres publiques 2026 des plateformes ; les prix réels varient selon la région, les remises du compte et les paliers — consultez les prix en vigueur sur le site officiel. Le nombre de téléchargements est une hypothèse de l'exemple ; remplacez-le par le chiffre réel de votre facture.
6. En local : combien de temps d'attente économisé en déplaçant ces données ?
Réduire le volume de 76,8 % raccourcit d'autant le temps de transfert. Cela ne dépend d'aucune facture cloud : on le voit directement lors des copies et sauvegardes.
- Disque dur externe USB 3 : débit soutenu estimé à 120 Mo/s.
- SSD externe USB 3 : débit estimé à 450 Mo/s.
- Réseau filaire Gigabit : 105 Mo/s après déduction des frais de protocole.
| Scénario | Volume économisé | Disque dur mécanique USB 3 | SSD USB 3 | Réseau Gigabit |
|---|---|---|---|---|
| Le lot testé dans cet article | 76,7 Go | ≈ 11 min | ≈ 2,9 min | ≈ 12,5 min |
| Photothèque de 10 Go | 7,68 Go | ≈ 66 s | ≈ 17 s | ≈ 75 s |
| Photothèque de 100 Go | 76,8 Go | ≈ 11 min | ≈ 2,9 min | ≈ 12,5 min |
| Photothèque de 1 To | 786 Go | ≈ 112 min | ≈ 30 min | ≈ 128 min |
Comme pour le stockage, c'est un investissement unique, rentabilisé au fil du temps : copier sur un disque externe ou en extraire, synchroniser un NAS, lancer Time Machine, migrer vers une nouvelle machine, l'envoyer à un collègue — tant que ces données sont déplacées, chaque opération fait gagner du temps selon la même proportion.
7. Et si la compression avait lieu avant l'envoi par l'utilisateur ?
Les calculs précédents concernaient le bilan « une fois les images stockées ». Mais il y a un autre trajet encore plus intéressant : entre le moment où l'utilisateur appuie sur Envoyer et la fin de la barre de progression, c'est la bande passante montante de l'utilisateur qui est utilisée — et elle est presque toujours le maillon le plus lent de toute la chaîne. Une photo brute issue d'un appareil pèse plusieurs Mo, soit un ordre de grandeur de plus que les images finales de l'article précédent, déjà compressées par le site et pesant en moyenne 299 Ko. La différence de temps est donc beaucoup plus sensible.
Avec le volume moyen mesuré sur ce lot : les photos originales font en moyenne 2,96 Mo, et après compression ImgZilla 0,69 Mo, soit environ 2,27 Mo économisés par photo.
| Bande passante montante (fourchette typique des tests de débit publics, simple indication) | Une photo 2,96 Mo → 0,69 Mo |
Envoi d'un album de 50 photos ≈ 148 Mo → 34 Mo |
Envoi de toutes les 32 188 photos du lot 99,9 Go → 23,1 Go |
|---|---|---|---|
| Réseau mobile (combiné 4G/5G, pris à 30 Mbps) | ≈ 0,6 s économisée | ≈ 30 s économisées | ≈ 5,7 h économisées |
| Connexion domestique courante en upload (25 Mbps) | ≈ 0,7 s économisée | ≈ 36 s économisées | ≈ 6,8 h économisées |
| Fibre symétrique Gigabit (1000 Mbps) | ≈ 0,02 s économisée | ≈ 0,9 s économisée | ≈ 10 min économisées |
0,6 s par photo, ce n'est pas flagrant, mais quand on envoie tout un album d'un coup, ou qu'on importe en masse plusieurs centaines de photos brutes, les minutes gagnées sont bien réelles — surtout pour un utilisateur mobile dont l'upload est déjà limité.
Les chiffres viennent de statistiques publiques de tests de débit locaux. Les vitesses réelles varient fortement selon l'opérateur, la région, l'appareil et la congestion ; à ne prendre que comme ordre de grandeur.
8. Données et note méthodologique
- Périmètre de l'échantillon : les données de cet article proviennent de la mesure réelle de ces 32 188 JPEG directement issus d'appareils photo / smartphones. Elles décrivent le résultat de cet échantillon, pas une « moyenne ImgZilla à 76,8 % ». Selon les appareils et les modèles, les résultats changent ; pour des images déjà finement optimisées, la marge sera nettement plus faible.
- Sélection de l'échantillon : l'ensemble des fichiers n'a fait l'objet d'aucun filtrage ni nettoyage : les 16 sous-répertoires existants ont été compressés globalement. Il n'y a pas eu de sélection d'images favorables.
- Comparabilité avec l'article précédent : 46,8 % dans l'article précédent, 76,8 % dans celui-ci ; la différence vient presque entièrement du fait que le matériau a déjà été compressé ou non. La plupart des photothèques se situent entre ces deux valeurs — proches de 46,8 % si une compression a eu lieu à l'entrée, plus proches de 76,8 % pour des images brutes envoyées pour la première fois.
- Méthode de calcul : les 76,8 % correspondent à « octets économisés ÷ octets d'origine, sur le total ». Le ratio de compression par fichier a une moyenne arithmétique de 76,6 % et une médiane de 77,3 % ; les deux approches sont indiquées dans le texte. L'unité de volume suit la convention 1 Go = 10⁹ octets.
- Paramètres de compression : ils sont fixes et l'interface n'a pas de curseur de qualité. C'est un choix de conception : chaque format a été réglé au point d'équilibre de la plage visuellement sans perte. Les utilisateurs qui aiment régler les paramètres manuellement doivent le savoir.
- Environnement d'exécution : tout s'est déroulé localement sur cette machine ; les images ne quittent pas ce Mac et aucune connexion réseau n'est nécessaire (sauf pour la validation de l'achat sur l'App Store).
Sources de prix (offres publiques 2026, consulter les tarifs en temps réel sur les sites officiels) : AWS S3 Pricing, Tarification Alibaba Cloud OSS, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Tarification Alibaba Cloud CDN, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Envie de vérifier par vous-même ? Téléchargez ImgZilla directement depuis le Mac App Store et testez sur quelques images déjà traitées de votre site avant de décider de continuer.
Mac App Store : https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
En savoir plus : https://imagetool.app/ImgZilla
Configuration requise : macOS 12.3 ou version ultérieure.