Comment compresser une image sans perdre en qualité ?

Compresser une image « sans perdre en qualité » semble contradictoire. Si aucune information ne doit disparaître, on parle de compression sans perte. Si l’objectif est plutôt de réduire fortement le poids sans que la différence soit perceptible dans le contexte d’affichage, une compression avec perte bien réglée peut être beaucoup plus efficace.

Sur le Web, cette seconde définition est souvent la plus utile.

Une photographie destinée à être affichée à 1 200 pixels de large n’a généralement pas besoin de conserver exactement toutes les données d’un original de plusieurs milliers de pixels. À l’inverse, une capture d’écran contenant de petits caractères ou une illustration aux contours nets peut très mal supporter certains types de compression.

La bonne question n’est donc pas :

« Quel pourcentage de compression dois-je utiliser ? »

mais :

« Quelle est la plus petite représentation qui conserve tout ce dont l’utilisateur a réellement besoin ? »

Cette démarche combine dimensions, format, niveau de qualité, contrôle visuel et mode de diffusion. Si vous n’avez pas encore distingué ces notions, Quelle résolution choisir pour une image ? et PNG, JPEG, WebP ou AVIF : quel format choisir ? constituent les deux meilleurs prérequis.

La méthode en six étapes

Pour une image destinée au Web :

1. conservez une source maître ;
2. supprimez les pixels inutiles en adaptant les dimensions ;
3. choisissez un format cohérent avec le contenu ;
4. ajustez la compression ;
5. inspectez les zones sensibles à la taille réelle d’utilisation ;
6. mesurez le gain dans la page, pas seulement dans le dossier de fichiers.

Le redimensionneur d’image, le convertisseur d’images et le compresseur d’images correspondent à trois étapes différentes de cette chaîne.

Compression et redimensionnement : quelle différence ?

Une image de :

4000 × 3000 px

contient 12 millions de pixels.

Si vous la réduisez à :

1200 × 900 px

elle n’en contient plus que 1,08 million.

Vous avez donc supprimé plus de 90 % des pixels avant même de parler de codec ou de curseur de qualité.

Le redimensionnement agit sur la quantité d’information spatiale à représenter.

La compression cherche ensuite à encoder cette information plus efficacement.

C’est pourquoi réduire des dimensions inutilement élevées apporte souvent un gain plus important et plus prévisible que de pousser un réglage de compression jusqu’à faire apparaître des défauts.

Le guide Quelle résolution choisir pour une image ? approfondit cette première décision.

Pourquoi une image brute prend-elle autant de place ?

Une image raster est une grille de pixels. Chaque pixel peut contenir plusieurs composantes : rouge, vert, bleu et éventuellement alpha.

Une image RGB de 4 000 × 3 000 pixels à 8 bits par canal représente, dans une approximation simple non compressée :

4 000 × 3 000 × 3 octets
= 36 000 000 octets

soit environ 36 Mo en comptage décimal, avant de considérer d’autres informations ou structures.

Pourtant, un JPEG de cette photographie peut ne peser que quelques mégaoctets, voire beaucoup moins.

Pourquoi ?

Parce que les données d’une image ne sont pas toutes indépendantes et ne possèdent pas toutes la même importance pour sa restitution perceptuelle.

Cette distinction entre information brute, redondance et représentation efficace rejoint directement les concepts présentés dans Claude Shannon et la théorie de l’information. La compression d’images en constitue une application particulièrement concrète : représenter un message avec moins de données, soit sans perdre l’information nécessaire à sa reconstruction, soit en acceptant certaines approximations contrôlées.

Qu’est-ce que la compression sans perte ?

Une compression sans perte permet de reconstruire exactement les données encodées.

L’idée n’est pas de supprimer des pixels jugés peu importants, mais de représenter plus efficacement des structures répétitives ou prévisibles.

Imaginez une ligne contenant cent pixels blancs identiques. Une représentation naïve pourrait répéter cent fois la même information. Une méthode de compression peut exploiter cette répétition.

Les algorithmes réels sont évidemment plus sophistiqués, mais le principe général est le même : profiter de la redondance.

PNG est le format sans perte le plus familier dans les usages Web. WebP possède également un mode sans perte, et d’autres formats peuvent proposer leurs propres mécanismes.

Sans perte signifie-t-il sans aucune modification ?

Il faut distinguer deux étapes.

Un fichier PNG peut compresser sans perte l’image qui lui est fournie. Mais si vous avez auparavant :

• réduit ses dimensions ;
• quantifié ses couleurs ;
• supprimé son canal alpha ;
• transformé son profil ;
• supprimé des métadonnées ;

le workflow complet a déjà modifié le fichier.

Dire « PNG est sans perte » ne signifie donc pas :

« tout ce qui se trouvait dans le fichier source sera forcément conservé ».

Cela signifie que le mécanisme d’encodage des pixels correspondant au mode utilisé n’introduit pas les pertes typiques d’un codec photographique avec perte.

Cette nuance est essentielle lorsque l’on compare des outils d’optimisation.

Qu’est-ce que la compression avec perte ?

Une compression avec perte accepte de ne pas reconstruire exactement les données originales.

Elle cherche à supprimer ou approximer certaines informations afin d’obtenir un fichier beaucoup plus petit.

JPEG en est l’exemple historique le plus connu sur le Web. WebP et AVIF proposent également des modes avec perte.

Le principe est particulièrement efficace pour les photographies, car une image naturelle contient énormément de variations et de détails.

Un codec peut exploiter :

• les ressemblances entre zones ;
• les propriétés de la perception visuelle ;
• la moindre sensibilité à certaines variations ;
• des représentations fréquentielles ou prédictives selon le codec.

Le résultat n’est plus identique pixel par pixel, mais peut rester visuellement très proche.

Pourquoi peut-on supprimer de l’information sans voir immédiatement la différence ?

L’œil humain n’accorde pas la même importance à toutes les variations d’une image.

Nous sommes par exemple plus sensibles à certains contours et structures qu’à certaines variations chromatiques fines.

Les codecs avec perte exploitent ces propriétés pour consacrer davantage de données aux informations perceptuellement importantes et moins aux détails qui peuvent être approximés.

Cela ne signifie pas que les pertes sont « invisibles par définition ».

Lorsque la compression devient trop forte, les approximations apparaissent :

• blocs ;
• halos ;
• contours artificiels ;
• bavures ;
• perte de texture ;
• aplats irréguliers ;
• bandes dans les dégradés.

Le travail consiste précisément à rester avant ce point de dégradation gênante.

Étape 1 : toujours conserver un original

La première règle est indépendante du format :

ne faites pas de votre fichier compressé votre seule source.

Conservez un original ou un fichier maître de qualité suffisante.

Cela peut être :

• le fichier de l’appareil photo ;
• un export haute qualité ;
• un PNG maître ;
• un fichier issu du logiciel de création ;
• un original vectoriel.

Les fichiers Web doivent être considérés comme des dérivés reproductibles.

Vous pourrez alors, dans six mois :

• générer une nouvelle largeur ;
• adopter un nouveau codec ;
• modifier la qualité ;
• créer un recadrage ;
• changer votre stratégie responsive.

Sans source maître, vous serez obligé de repartir d’une version déjà dégradée.

Qu’est-ce que la perte générationnelle ?

Supposons ce workflow :

original
→ JPEG qualité réduite
→ réouverture
→ nouvel export JPEG
→ nouvel export WebP

Chaque encodage avec perte travaille sur une image qui contient déjà les approximations de l’étape précédente.

Les défauts peuvent alors s’accumuler.

C’est la perte générationnelle.

Le bon workflow est plutôt :

                → JPEG
original maître → WebP
                → AVIF
                → miniature WebP

Chaque dérivé repart de la meilleure source disponible.

Cette architecture facilite aussi la comparaison entre formats étudiée dans PNG, JPEG, WebP ou AVIF.

Étape 2 : redimensionner avant de compresser

Une photographie de smartphone peut dépasser 4 000 pixels de large.

Si votre site l’affiche au maximum à 1 200 pixels, conserver tous les pixels de l’original est généralement inutile pour cette variante.

Commencez donc par déterminer la largeur réellement nécessaire.

Le redimensionneur d’image permet de créer une version adaptée.

Attention toutefois aux écrans à forte densité : une image affichée à 600 CSS px peut bénéficier d’une ressource plus large sur certains appareils.

La réponse n’est pas d’envoyer 4 000 px à tout le monde. Il faut produire plusieurs variantes et laisser le navigateur sélectionner la plus adaptée. Le futur guide Images responsives : comprendre srcset et sizes expliquera précisément cette étape.

Redimensionner fait-il perdre de la qualité ?

Lorsque vous réduisez une image, vous supprimez effectivement de l’information.

Mais si ces pixels ne sont pas nécessaires à l’usage final, cette perte est souhaitable.

Une miniature de 300 px n’a pas besoin de contenir les détails d’une source de 5 000 px.

La question est donc toujours contextuelle.

À l’inverse, agrandir ensuite cette miniature à 2 000 px ne recréera pas les détails supprimés.

La résolution appropriée est celle qui conserve suffisamment d’information pour la taille d’affichage et les usages prévus.

Redimensionnement ou recadrage ?

Ces deux opérations sont différentes.

Redimensionnement

Toute l’image est conservée, mais ses dimensions changent.

Recadrage

Une partie du cadre est supprimée.

Un recadrage peut parfois réduire davantage les données tout en améliorant la composition.

Imaginez une photographie où le sujet occupe seulement le centre d’un très grand cadre. Un recadrage pertinent évite d’encoder des zones qui n’apportent rien au contenu.

Mais il change évidemment le cadrage et doit donc rester une décision éditoriale.

Étape 3 : choisir le format avant le niveau de qualité

Le format influence énormément le résultat.

Une photographie enregistrée en PNG peut rester très lourde même après une optimisation poussée, car PNG cherche à conserver exactement les pixels encodés.

La même photographie en JPEG, WebP ou AVIF avec perte peut devenir beaucoup plus légère.

À l’inverse, une capture d’écran contenant de petits caractères peut être dégradée par un JPEG trop compressé alors qu’un PNG ou un WebP sans perte restera très propre.

Le choix du codec vient donc avant la recherche du curseur idéal.

Pour décider, utilisez PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Quel format pour une photographie ?

Pour une photographie :

• JPEG reste une référence solide ;
• WebP avec perte est souvent très efficace ;
• AVIF peut obtenir d’excellents résultats.

Comparez plusieurs sorties depuis le même original et aux mêmes dimensions.

Ne comparez pas :

JPEG 4000 px

à :

WebP 1200 px

en concluant que le format explique tout le gain.

Pour isoler l’effet du codec, les dimensions doivent être identiques.

Quel format pour une capture d’écran ?

Les captures d’écran contiennent souvent :

• texte ;
• lignes fines ;
• aplats ;
• icônes ;
• zones répétitives.

Commencez généralement par PNG ou WebP.

Inspectez particulièrement les caractères et les bordures.

Une compression avec perte trop agressive peut créer des halos autour du texte, ce qui dégrade fortement la lisibilité pour un gain parfois médiocre.

Si la capture sert de documentation, la précision peut être plus importante que quelques kilo-octets économisés.

Quel format pour un logo ou une icône ?

Avant de compresser un logo raster, demandez-vous s’il ne devrait pas être en SVG.

Un graphisme géométrique peut être décrit par des formes plutôt que par des milliers de pixels.

SVG : comprendre le format vectoriel explique pourquoi cette représentation peut rester nette à toutes les tailles.

Si vous disposez déjà d’un SVG, l’optimiseur SVG et Optimiser un fichier SVG sans altérer son rendu sont plus pertinents qu’un compresseur raster.

Étape 4 : régler la qualité progressivement

Une fois les dimensions et le format choisis, vous pouvez chercher le niveau de compression approprié.

Pour un format avec perte :

1. partez d’une qualité relativement élevée ;
2. exportez ;
3. notez le poids ;
4. baissez par paliers ;
5. comparez ;
6. arrêtez-vous lorsque le gain supplémentaire ne justifie plus la dégradation.

Ne cherchez pas un nombre universel.

Un réglage qui fonctionne parfaitement sur un portrait peut être mauvais sur :

• du feuillage ;
• une photographie nocturne ;
• un dégradé ;
• une capture d’écran ;
• une illustration.

Le contenu de l’image influence directement la difficulté de compression.

Pourquoi « qualité 80 » ne veut-elle pas dire 80 % de l’original ?

C’est l’une des erreurs les plus fréquentes.

Un curseur affichant :

80 %

ne signifie pas :

« 80 % des informations sont conservées ».

Ce n’est pas non plus une mesure universelle de fidélité.

Chaque codec et chaque encodeur peut interpréter son paramètre de qualité différemment.

Ainsi :

JPEG qualité 80

et :

WebP qualité 80

ne sont pas deux sorties directement comparables sur une échelle absolue.

Comparez le rendu et le poids, pas les nombres des curseurs.

Peut-on utiliser la même qualité pour toutes les images ?

Techniquement oui, mais ce n’est pas optimal.

Une automatisation peut utiliser une valeur initiale commune pour simplifier le pipeline, puis appliquer des exceptions.

Par exemple :

• photographies standard : réglage de départ ;
• images héro : contrôle plus attentif ;
• miniatures : compression plus agressive ;
• captures contenant du texte : stratégie différente.

L’objectif d’une règle automatisée est de couvrir correctement la majorité des cas sans empêcher les ajustements nécessaires.

Étape 5 : savoir où regarder les défauts

La qualité d’une compression ne se juge pas uniquement en regardant l’image entière à 25 %.

Certaines zones révèlent beaucoup plus rapidement les défauts.

Cheveux et feuillage

Les détails fins et irréguliers sont difficiles à encoder.

Ciel et dégradés

Une compression trop forte peut produire du banding, c’est-à-dire des bandes visibles au lieu d’une transition douce.

Contours contrastés

Une ligne sombre sur fond clair peut révéler des halos.

Texte

Les caractères fins rendent immédiatement visibles les artefacts.

Peau

Une compression excessive peut lisser ou structurer artificiellement certaines zones.

Textures répétitives

Tissus, briques, herbe et motifs peuvent devenir pâteux.

Inspectez ces zones à 100 %, puis revenez à la taille réelle d’utilisation.

Pourquoi faut-il regarder aussi l’image à sa taille finale ?

Une différence visible à 400 % peut être totalement imperceptible lorsque l’image est affichée à 600 px.

À l’inverse, une image qui semble correcte dans une petite prévisualisation peut devenir médiocre lorsqu’elle occupe toute la largeur d’un écran.

Le critère pertinent est donc :

la qualité dans le contexte réel d’utilisation.

Pour une vignette, une perte importante de micro-détails peut être acceptable.

Pour une photographie de produit zoomable, elle peut être rédhibitoire.

Pour un document ou une capture d’écran, la lisibilité des petits caractères peut être essentielle.

Peut-on mesurer objectivement la qualité ?

Il existe des métriques permettant de comparer une image compressée à une référence, comme PSNR, SSIM ou des approches perceptuelles plus récentes.

Elles peuvent être utiles pour :

• automatiser des comparaisons ;
• tester des codecs ;
• analyser de grands corpus ;
• détecter des régressions.

Mais aucune métrique simple ne remplace totalement le contrôle humain pour tous les usages.

Une différence mathématique peut être peu visible, tandis qu’un petit artefact placé sur un visage ou un texte peut être très gênant.

Pour un site éditorial, une stratégie raisonnable associe donc automatisation et inspection visuelle des cas importants.

Étape 6 : mesurer le gain réel

La formule de réduction est :

réduction (%) =
(taille initiale - taille finale)
÷ taille initiale
× 100

Exemple :

500 Ko → 200 Ko

donne :

(500 - 200) / 500 × 100
= 60 %

Mais un pourcentage élevé n’est pas automatiquement une réussite.

Passer de :

500 Ko → 80 Ko

avec une photographie visiblement dégradée peut être moins intéressant que :

500 Ko → 140 Ko

avec un rendu pratiquement indiscernable.

Le bon objectif est le poids minimal acceptable, pas le poids minimal possible.

Pourquoi quelques kilo-octets peuvent-ils compter ?

Sur une seule image, économiser 20 Ko semble négligeable.

Sur une page contenant 30 miniatures :

20 Ko × 30 = 600 Ko

Sur plusieurs pages consultées depuis un réseau mobile, l’impact devient réel.

Il faut donc raisonner à deux échelles :

• l’image individuelle ;
• le budget global de la page.

À l’inverse, passer une heure à économiser 2 Ko sur une image chargée rarement n’est probablement pas rentable.

L’optimisation est aussi une question de priorité.

Le poids sur disque est-il le poids transféré ?

Pas toujours exactement.

Le réseau peut être influencé par :

• cache ;
• CDN ;
• en-têtes ;
• réutilisation de ressources ;
• protocole ;
• comportement du navigateur.

Pour une image déjà compressée comme JPEG, WebP ou AVIF, une compression HTTP supplémentaire apporte généralement peu comparée au travail du codec d’image lui-même.

Mesurez donc les ressources dans les outils réseau du navigateur lorsque vous évaluez les performances réelles.

Compression et images responsives

Une seule image fortement compressée n’est pas forcément une bonne stratégie.

Supposons que vous créez :

hero-2000.webp

et que vous la compressez parfaitement.

Un téléphone qui n’a besoin que de 600 ou 800 px télécharge malgré tout la grande ressource si aucune variante n’est proposée.

Une meilleure architecture peut produire :

hero-640.webp
hero-960.webp
hero-1280.webp
hero-1920.webp

puis laisser le navigateur choisir.

Le futur article Images responsives : comprendre srcset et sizes détaillera ce mécanisme.

La compression répond donc à :

comment réduire chaque fichier ?

Les images responsives répondent à :

quel fichier faut-il envoyer à cet utilisateur ?

Les deux sont complémentaires.

Compression et écrans Retina

Les écrans à forte densité compliquent légèrement la décision.

Une image affichée à :

400 CSS px

peut nécessiter une ressource plus large pour rester nette.

Mais il ne faut pas en conclure :

« servons toujours une image deux fois plus grande ».

La densité, la largeur d’affichage et les capacités du navigateur peuvent être combinées dans une stratégie responsive.

L’objectif est de fournir suffisamment de pixels, sans envoyer systématiquement la variante maximale.

Compression et LCP

Une grande image héro peut être le Largest Contentful Paint d’une page.

Dans ce cas, réduire son poids peut améliorer son temps de chargement.

Mais la compression ne suffit pas.

Le résultat dépend aussi :

• de la découverte de la ressource ;
• de sa priorité ;
• du serveur ou CDN ;
• de la taille réellement demandée ;
• du cache ;
• de la stratégie responsive.

Le futur article Optimiser les images pour les performances Web réunira toutes ces dimensions.

Ne cherchez donc pas à compresser excessivement une image LCP pour compenser une architecture de chargement inefficace.

Compression et CLS

Le Cumulative Layout Shift n’est pas directement résolu par la compression.

Une image très légère peut tout de même provoquer un déplacement de mise en page si son espace n’est pas réservé avant son chargement.

Définir correctement largeur, hauteur ou rapport d’aspect permet au navigateur d’anticiper l’espace nécessaire.

Cette distinction est importante :

• compression → volume de données ;
• dimensions déclarées → stabilité de mise en page.

Une stratégie de performance doit traiter les deux.

Les métadonnées font-elles partie de la compression ?

Pas exactement.

Une image peut contenir des données qui ne sont pas les pixels visibles :

• EXIF ;
• GPS ;
• date ;
• appareil ;
• XMP ;
• profil colorimétrique ;
• informations de droits ;
• miniature embarquée.

Les supprimer peut réduire le fichier, mais ce n’est pas la même opération que réduire la complexité des données d’image.

Et surtout, certaines informations peuvent être utiles.

Le futur article Métadonnées d’image : les lire, les conserver ou les supprimer expliquera comment décider. Le lecteur de métadonnées permet déjà d’inspecter ce qu’un fichier contient.

Faut-il supprimer toutes les métadonnées ?

Non.

Certaines données peuvent être inutiles pour la publication et potentiellement sensibles, comme une localisation GPS.

D’autres peuvent être importantes :

• droits ;
• crédit ;
• profil colorimétrique ;
• informations de workflow.

Une politique saine consiste à définir ce qui doit être :

• conservé dans le fichier ;
• conservé ailleurs dans le CMS ;
• supprimé avant publication.

La confidentialité et l’optimisation se rencontrent ici, mais elles ne poursuivent pas exactement le même objectif.

Un profil ICC est-il du poids inutile ?

Pas nécessairement.

Un profil colorimétrique peut contribuer à l’interprétation correcte des couleurs.

Supprimer aveuglément un profil pour gagner quelques kilo-octets peut modifier le rendu dans certains workflows.

Avant toute suppression, comprenez le rôle de la donnée.

C’est particulièrement important pour :

• photographie ;
• e-commerce ;
• œuvres ;
• identités visuelles.

L’optimisation ne doit pas détruire une information nécessaire à la fidélité.

Compression et transparence

La transparence ajoute une composante supplémentaire à gérer.

PNG, WebP et AVIF peuvent représenter un canal alpha.

JPEG classique ne le peut pas.

Si vous convertissez une image transparente en JPEG, il faut la composer sur un fond.

Sinon, vous risquez :

• un fond noir ;
• un fond blanc inattendu ;
• des franges autour du détourage.

Pour comprendre ce canal supplémentaire, consultez Comment une image numérique est-elle construite ?.

Pourquoi voit-on parfois un halo autour d’un objet détouré ?

Un halo peut provenir de plusieurs étapes :

• pixels de bord issus de l’ancien fond ;
• prémultiplication alpha ;
• redimensionnement ;
• compression ;
• composition sur un nouveau fond.

Le problème n’est donc pas toujours « le format ».

Testez une image transparente sur :

• fond blanc ;
• fond sombre ;
• couleur vive.

Cela révèle rapidement les franges invisibles sur le fond d’origine.

Compresser une image contenant du texte

Soyez plus prudent.

Une photographie tolère souvent mieux certaines approximations qu’une capture d’écran.

Autour des caractères, une compression avec perte peut produire :

• halos ;
• bavures ;
• perte de netteté.

Pour une documentation ou un tutoriel, un fichier un peu plus lourd mais parfaitement lisible est souvent préférable.

Testez PNG et WebP sans perte ou à haute qualité avant d’appliquer une compression photographique agressive.

Compresser une photographie

Pour une photographie :

1. redimensionnez ;
2. testez JPEG, WebP et éventuellement AVIF ;
3. choisissez un niveau de qualité ;
4. inspectez les zones détaillées ;
5. comparez les poids.

Les photographies constituent le cas où la compression avec perte peut apporter les gains les plus spectaculaires.

Mais les images ne réagissent pas toutes pareil.

Un portrait sur fond uni et une forêt extrêmement détaillée peuvent nécessiter des réglages différents.

Compresser une illustration

Identifiez d’abord sa nature.

Illustration à aplats

Testez PNG ou WebP sans perte.

Illustration texturée

WebP ou AVIF avec perte peuvent devenir intéressants.

Illustration vectorielle

Ne la rasterisez pas inutilement. Utilisez SVG et, si nécessaire, l’optimiseur SVG.

La catégorie « illustration » ne suffit donc pas à choisir le codec.

Compresser un SVG

On ne compresse pas un SVG comme une photographie JPEG.

SVG est un document vectoriel basé sur du texte structuré.

Son optimisation peut consister à :

• supprimer des métadonnées inutiles ;
• simplifier certains nombres ;
• retirer des éléments redondants ;
• nettoyer des attributs ;
• réduire la structure.

Le guide Optimiser un fichier SVG sans altérer son rendu traite précisément ce cas.

Ne convertissez pas un SVG en WebP uniquement pour pouvoir utiliser un compresseur raster : vous perdriez l’un de ses principaux avantages, son indépendance vis-à-vis d’une résolution fixe.

Pourquoi PNG peut-il parfois devenir plus lourd après « compression » ?

Plusieurs raisons sont possibles :

• l’outil réencode avec une stratégie différente ;
• le fichier source était déjà très optimisé ;
• des métadonnées ont été ajoutées ;
• la palette a changé ;
• l’outil n’utilise pas un encodeur spécialisé.

Une opération appelée « compresser » ne garantit pas mathématiquement que le résultat sera plus petit.

Le pipeline doit comparer :

taille avant
taille après

et conserver l’ancienne version si la nouvelle n’apporte rien.

Pourquoi un WebP peut-il être plus lourd qu’un JPEG ?

Même principe.

Un JPEG très optimisé peut battre un WebP mal réglé.

Le poids dépend :

• du codec ;
• de l’encodeur ;
• du réglage ;
• de l’image ;
• des métadonnées ;
• des dimensions.

Le nom de l’extension ne suffit jamais à prédire le résultat.

C’est pourquoi le choix du format doit rester expérimental lorsque les performances comptent réellement.

Pourquoi AVIF n’est-il pas une solution magique ?

AVIF peut fournir d’excellents résultats, mais :

• son encodage peut être plus coûteux ;
• certaines images réagissent mieux que d’autres ;
• les gains peuvent être faibles sur de petits fichiers ;
• une mauvaise configuration peut dégrader le rendu.

Pour une grande bibliothèque, le temps de build peut également devenir un paramètre opérationnel.

Le meilleur pipeline n’est pas celui qui produit théoriquement le fichier le plus petit à n’importe quel coût. C’est celui qui équilibre :

• poids ;
• qualité ;
• temps de génération ;
• compatibilité ;
• maintenance.

Peut-on automatiser la compression ?

Oui, et c’est même souhaitable lorsque le site contient beaucoup d’images.

Un pipeline peut :

1. prendre la source maître ;
2. déterminer plusieurs dimensions ;
3. générer les formats retenus ;
4. appliquer des réglages de qualité ;
5. supprimer certaines métadonnées selon la politique ;
6. produire un rapport de poids.

Mais l’automatisation doit inclure des garde-fous.

Par exemple :

• ne pas remplacer un fichier par une sortie plus lourde ;
• conserver la source ;
• signaler les images anormalement volumineuses ;
• permettre une exception pour une image sensible.

Faut-il fixer un poids maximal par image ?

Un seuil peut être utile comme alerte, mais une limite universelle est rarement pertinente.

Une image héro pleine largeur et une icône n’ont pas le même budget.

Il vaut mieux définir des catégories :

icônes
miniatures
cartes
illustrations
images héro
galeries

puis des budgets adaptés.

L’objectif est d’éviter les anomalies évidentes, pas de forcer tous les fichiers sous une valeur arbitraire.

Peut-on fixer un budget d’images par page ?

Oui, et c’est souvent plus pertinent.

Une page peut contenir vingt fichiers individuellement « raisonnables » mais devenir très lourde au total.

Le budget peut considérer :

• poids initial visible ;
• images chargées plus tard ;
• nombre de requêtes ;
• importance du contenu ;
• contexte mobile.

Cela encourage une optimisation globale plutôt qu’une obsession pour chaque fichier isolé.

Le futur guide Optimiser les images pour les performances Web approfondira cette vision système.

Lazy loading et compression : même problème ?

Non.

La compression réduit la taille d’une ressource.

Le lazy loading retarde le chargement de certaines ressources qui ne sont pas immédiatement nécessaires.

Les deux peuvent être combinés.

Une image située loin sous la ligne de flottaison peut être :

• correctement compressée ;
• correctement dimensionnée ;
• chargée plus tard.

À l’inverse, une image héro importante ne doit pas être retardée aveuglément sous prétexte que le lazy loading est une « optimisation ».

Chaque technique répond à une question différente.

Cache et compression

Une image bien mise en cache n’est pas retéléchargée à chaque navigation.

Cela réduit énormément son coût lors des visites suivantes.

Mais le cache ne justifie pas de servir un fichier inutilement lourd lors de la première visite.

Compression et cache sont complémentaires :

• compression → moins de données par transfert ;
• cache → moins de transferts répétés.

Le workflow complet d’optimisation Web doit tenir compte des deux.

CDN et transformation à la volée

Certains CDN d’images peuvent :

• redimensionner ;
• convertir ;
• ajuster la qualité ;
• sélectionner un format ;
• mettre en cache les variantes.

Cette architecture peut être très efficace pour un site dynamique.

Mais elle déplace une partie de la complexité vers le service de transformation.

Il faut alors surveiller :

• coûts ;
• cache ;
• URLs ;
• qualité ;
• dépendance au fournisseur ;
• comportement en cas de panne.

Pour un site statique, générer les variantes au build peut être plus simple.

Compression locale et confidentialité

Lorsque l’image est traitée localement dans le navigateur, le fichier peut rester sur l’appareil de l’utilisateur selon l’implémentation de l’outil.

Cela peut être intéressant pour des fichiers privés.

Mais il faut distinguer :

• la promesse générale d’un service ;
• le fonctionnement concret de chaque outil.

Un traitement local n’empêche pas non plus qu’un fichier exporté conserve éventuellement des métadonnées sensibles.

C’est pourquoi le lecteur de métadonnées et le futur article sur les métadonnées et la confidentialité restent complémentaires.

Compression et couleurs

Une compression peut modifier légèrement les couleurs ou leurs transitions.

Sur une photographie ordinaire, cela peut être imperceptible.

Sur :

• un nuancier ;
• une identité visuelle ;
• une capture d’interface ;
• un test de contraste ;

la fidélité colorimétrique peut être plus importante.

Si vous extrayez ensuite une palette depuis une image compressée, les couleurs obtenues peuvent différer légèrement de celles de la source.

Pour comprendre ce workflow, consultez Créer une palette de couleurs à partir d’une image.

Compression et contraste WCAG

Une image fortement compressée peut dégrader les contours d’un texte intégré ou d’un élément graphique.

Cela ne transforme pas la compression en méthode de calcul WCAG, mais rappelle qu’un rendu visuel doit être évalué dans son état final.

Si une image contient une information nécessaire, ne sacrifiez pas sa lisibilité pour quelques kilo-octets.

Pour les couples de couleurs et les exigences associées, consultez Contraste WCAG : comment rendre les couleurs accessibles ?.

Comment comparer deux versions proprement ?

Utilisez une procédure reproductible.

Même source

Ne comparez pas deux fichiers issus de générations différentes.

Mêmes dimensions

Sinon, vous mesurez à la fois le redimensionnement et le codec.

Même contexte

Affichez les versions à la même taille.

Plusieurs zones

Inspectez les parties faciles et difficiles.

Poids réel

Notez la taille exacte des fichiers.

Décision

Choisissez la version qui offre le meilleur compromis pour l’usage.

Cette méthode est plus fiable qu’un jugement fondé sur l’extension ou le curseur.

Exemple : photographie héro

Source :

4000 × 2667 px
3,8 Mo

Supposons qu’elle soit affichée au maximum autour de 1 400 px.

Première étape :

1400 × 933 px

Puis vous générez plusieurs essais :

JPEG haute qualité
WebP haute qualité
WebP qualité intermédiaire
AVIF haute qualité
AVIF qualité intermédiaire

Vous comparez ensuite :

• poids ;
• visage ;
• cheveux ;
• arrière-plan ;
• dégradés.

Vous retenez non pas le plus petit fichier, mais le premier dont la réduction supplémentaire commence à devenir visuellement coûteuse.

Ensuite, vous pourrez produire plusieurs largeurs pour le responsive.

Exemple : capture d’écran de documentation

Source :

1800 × 1000 px

La capture contient du code et du petit texte.

Ici, une compression photographique agressive est risquée.

Testez :

• PNG optimisé ;
• WebP sans perte ;
• WebP avec perte à qualité élevée.

Zoomez sur les caractères.

Si le WebP avec perte économise 20 % mais ajoute des halos qui rendent le code moins confortable à lire, conservez la version sans perte.

La qualité fonctionnelle prime sur le ratio de réduction.

Exemple : miniature de carte

Une miniature est affichée à environ :

320 × 180 px

La source mesure 2 400 px.

Le principal gain vient du redimensionnement.

Une fois la variante créée, vous pouvez accepter une compression plus forte qu’avec l’image héro, car les micro-détails ne sont pas nécessaires.

Mais ne servez pas cette miniature lorsque l’utilisateur ouvre ensuite une vue agrandie : utilisez une ressource adaptée à chaque contexte.

Exemple : logo transparent

Si vous possédez le SVG original, gardez-le vectoriel.

Si vous ne disposez que d’un PNG :

• évitez JPEG à cause de la transparence ;
• testez WebP sans perte ;
• comparez le poids ;
• inspectez les contours sur plusieurs fonds.

Si le gain est de quelques centaines d’octets seulement, la simplicité peut justifier de conserver PNG.

Toutes les optimisations n’ont pas besoin d’être appliquées.

Une compression peut-elle augmenter le poids ?

Oui.

Si l’image source est déjà très optimisée, un nouvel encodeur peut produire un fichier plus lourd.

Cela arrive notamment lorsque :

• le réglage est trop élevé ;
• le codec est mal adapté ;
• des métadonnées sont ajoutées ;
• l’encodeur est moins efficace pour ce contenu.

Un pipeline sérieux doit donc avoir une règle simple :

ne remplacez pas automatiquement un fichier par une version plus lourde sans raison fonctionnelle.

Quand arrêter d’optimiser ?

Arrêtez lorsque le gain marginal ne justifie plus :

• la perte visuelle ;
• le temps de travail ;
• la complexité ;
• le coût de build ;
• le risque de régression.

Passer de 1,5 Mo à 250 Ko mérite clairement une attention.

Passer de 42 Ko à 39 Ko peut ne pas justifier une nouvelle variante et une règle supplémentaire.

L’optimisation Web est une recherche de rendement, pas une compétition de compression.

Checklist avant publication

Avant de publier une image :

• ai-je conservé une source maître ?
• les dimensions correspondent-elles à l’usage ?
• ai-je besoin de plusieurs largeurs ?
• le format correspond-il au contenu ?
• la transparence est-elle préservée si nécessaire ?
• ai-je comparé plusieurs réglages ?
• les détails importants restent-ils lisibles ?
• ai-je inspecté l’image à sa taille réelle ?
• le fichier final est-il réellement plus léger ?
• les métadonnées nécessaires sont-elles conservées ?
• les métadonnées sensibles ont-elles été examinées ?
• les dimensions sont-elles déclarées dans la page ?
• la stratégie de chargement correspond-elle à la position de l’image ?

Si plusieurs réponses sont « non », pousser davantage le curseur de qualité n’est probablement pas la priorité.

Les erreurs les plus fréquentes

Compresser avant de redimensionner

Vous optimisez des pixels qui ne seront jamais utilisés.

Écraser l’original

Vous perdez la possibilité de régénérer proprement les dérivés.

Réencoder un JPEG déjà dégradé

Les pertes s’accumulent.

Utiliser qualité 100 par principe

Le fichier peut grossir énormément pour un bénéfice imperceptible.

Utiliser une valeur unique comme vérité universelle

Chaque image réagit différemment.

Choisir PNG pour une photographie uniquement parce qu’il est sans perte

Vous pouvez obtenir un fichier disproportionné pour un bénéfice inutile à l’écran.

Convertir un logo SVG en raster

Vous perdez l’avantage du vectoriel.

Juger uniquement à 25 %

Les artefacts fins passent inaperçus.

Juger uniquement à 400 %

Vous pouvez rejeter une compression dont les différences seraient totalement invisibles à l’usage.

Supprimer toutes les métadonnées aveuglément

Certaines peuvent être nécessaires.

Oublier les variantes responsives

Un fichier très bien compressé peut encore être beaucoup trop grand pour un petit écran.

Ce qu’il faut retenir

Compresser une image sans perte visible n’est pas une valeur de curseur. C’est une méthode.

Elle commence avant la compression :

• conserver un original ;
• choisir les bonnes dimensions ;
• sélectionner le format adapté.

Elle continue avec :

• un réglage progressif ;
• une comparaison visuelle ;
• une mesure du poids.

Et elle se termine dans le contexte réel :

• variante responsive ;
• chargement ;
• cache ;
• performance de la page.

La distinction fondamentale reste la suivante :

sans perte signifie que les données encodées peuvent être reconstruites exactement ;

avec perte maîtrisée signifie que certaines informations sont supprimées pour obtenir un gain supérieur tout en conservant une qualité suffisante pour l’usage.

Pour comprendre pourquoi certains formats se prêtent mieux à l’une ou l’autre approche, revenez à PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Pour préparer la prochaine étape de la collection, poursuivez avec SVG : comprendre le format vectoriel.

Et lorsque les articles 10 à 12 seront finalisés, Images responsives : comprendre srcset et sizes, Métadonnées d’image : les lire, les conserver ou les supprimer et Optimiser les images pour les performances Web permettront de replacer la compression dans une stratégie de diffusion complète.

Questions fréquentes

Peut-on vraiment compresser une image sans aucune perte ?

Oui, avec une compression sans perte. Mais pour une photographie Web, une compression avec perte visuellement imperceptible produit souvent un fichier beaucoup plus petit.

Quelle qualité choisir pour JPEG ?

Il n’existe pas de valeur universelle. Partez d’une qualité relativement élevée, baissez progressivement et comparez le rendu avec le poids.

Quelle qualité choisir pour WebP ?

Même principe. La valeur numérique n’est pas directement comparable à celle d’un encodeur JPEG. Jugez le fichier produit.

Qualité 80 signifie-t-elle que 80 % de l’image est conservée ?

Non. Le nombre est un paramètre d’encodeur, pas un pourcentage universel d’information ou de fidélité.

PNG peut-il être compressé ?

Oui. PNG utilise une compression sans perte, et différents encodeurs ou transformations peuvent réduire son poids. Mais un curseur de « qualité » n’a pas le même sens que pour JPEG.

Pourquoi un PNG est-il énorme après conversion d’un JPEG ?

Parce qu’un PNG doit représenter sans perte les pixels déjà décodés du JPEG. Il ne récupère pas les détails perdus et peut nécessiter beaucoup plus de données.

Pourquoi mon fichier compressé est-il plus lourd ?

La source peut déjà être optimisée, le format peut être inadapté ou les réglages peuvent produire davantage de données. Comparez toujours avant de remplacer le fichier.

Faut-il redimensionner avant de compresser ?

Généralement oui. Supprimer les pixels inutiles est souvent le premier gain important.

Réduire les dimensions détruit-il la qualité ?

Cela supprime de l’information, mais cette information peut être inutile si l’image n’est jamais affichée à sa taille originale.

Peut-on compresser plusieurs fois le même JPEG ?

C’est possible mais déconseillé. Chaque réencodage avec perte peut ajouter des dégradations. Repartez de l’original.

Comment savoir si la compression est visible ?

Inspectez les zones sensibles à 100 %, puis regardez le fichier à sa taille réelle d’affichage. Comparez contours, textures, dégradés et texte.

AVIF compresse-t-il toujours mieux que WebP ?

Non. Il peut être excellent sur certaines images, mais le résultat dépend du contenu et des réglages.

Dois-je supprimer les métadonnées pour gagner du poids ?

Pas automatiquement. Certaines sont inutiles ou sensibles, d’autres peuvent être importantes. Inspectez-les d’abord avec le lecteur de métadonnées.

La compression suffit-elle pour optimiser les images d’un site ?

Non. Il faut également gérer dimensions, variantes responsives, format, chargement et cache. Le guide Optimiser les images pour les performances Web réunira ces étapes.

Quel outil Bethemesh utiliser ?

Utilisez le redimensionneur pour les dimensions, le convertisseur pour le format et le compresseur pour expérimenter sur le poids et la qualité.

Quel rapport avec la théorie de l’information ?

La compression cherche à représenter des données plus efficacement en exploitant leur structure et leur redondance. Pour le contexte historique et conceptuel, consultez Claude Shannon et la théorie de l’information.