Le fonctionnement des algorithmes de compression d'images : DCT, LZW et AVIF

Mis à jour le: June 28, 2026

La compression d'image réduit la taille d'un fichier en supprimant des informations que votre œil a du mal à percevoir. Les algorithmes derrière JPEG, PNG, GIF, WebP et AVIF ne sont pas de la magie — ce sont une pile d'étapes mécaniques spécifiques. Comprendre cela vous explique pourquoi un JPEG à qualité 80 semble correct, pourquoi le PNG gonfle sur une photographie, et pourquoi l'encodage AVIF est si lent. Ceci est un guide pratique des mathématiques réelles, pas un concours de popularité de formats.

Réponse rapide : comment fonctionnent les algorithmes de compression d'image ?

Chaque format effectue les mêmes trois tâches en séquence. Premièrement, il transforme les pixels pour que l'information importante se concentre dans quelques nombres. Deuxièmement, il quantifie — arrondit les nombres qui contribuent le moins (c'est la partie avec perte, et les formats sans perte la sautent). Troisièmement, il encode en entropie les valeurs restantes afin que les valeurs fréquentes prennent moins de bits que les valeurs rares.

La division entre les formats se situe surtout à la première étape. JPEG et AVIF utilisent une transformée de fréquence (DCT). PNG et WebP-lossless utilisent un filtrage prédictif. GIF utilise l'encodage par dictionnaire (LZW). Les ratios de compression que vous voyez sur le marché sont déterminés par la manière astucieuse dont chaque format jette ou emballe les données.

Quelle est la différence entre la compression avec perte et sans perte ?

La distinction la plus importante en matière de compression d'image est de savoir si des données sont jetées.

La compression sans perte (Lossless) reconstruit l'original pixel par pixel. Elle ne peut supprimer que la redondance — octets répétés, gradients prévisibles, séries de couleurs identiques. Son plafond est l'entropie de l'image : un bruit purement aléatoire se comprime à peine. PNG, GIF et WebP-lossless vivent ici.

La compression avec perte (Lossy) jette définitivement des informations, pariant que ce qu'elle supprime est en dessous de votre seuil perceptuel. Le pari porte généralement sur les détails haute fréquence (texture fine, bords) et sur la résolution des couleurs (vos yeux perçoivent le contraste beaucoup plus nettement que la teinte). JPEG, WebP-lossy, AVIF et HEIC vivent ici.

Le gain est dramatique. Pour une photographie typique, le résultat avec perte est souvent 5 à 10 fois plus petit que l'équivalent sans perte à un niveau de qualité qu'aucun spectateur ne peut distinguer de l'original. Le coût est l'irréversibilité : chaque réencodage avec perte accentue les artefacts, raison pour laquelle vous conservez toujours un fichier maître propre.

Comment fonctionne réellement la compression DCT de JPEG ?

JPEG est le pipeline avec perte canonique. Il fonctionne en cinq étapes, et la Transformée Cosinus Discrète (DCT) en est le cœur. Les cinq étapes sont :

Voici un exemple concret de l'étape DCT. Prenons un bloc 8x8 où chaque pixel a la même valeur de luminance de 200. L'encodeur effectue d'abord un décalage de niveau en soustrayant 128, laissant un bloc plat de 72. La DCT 2D produit ensuite 64 coefficients — mais comme l'entrée est parfaitement plate, seul le coefficient supérieur gauche (le terme DC) n'est pas nul, et il égale 8 fois 72, soit 576. Les 63 autres coefficients sont exactement zéro.

Vient maintenant l'étape avec perte. La matrice de quantification de luminance standard JPEG divise le coefficient DC par 16, donnant 36, et divise chaque coefficient AC haute fréquence par un nombre plus grand. Puisque les coefficients AC sont déjà à zéro, la quantification ne change rien ici. Après l'ordonnancement en zigzag, tout le bloc de 64 valeurs est stocké comme une seule valeur DC de 36 suivie d'un marqueur de fin de bloc. Soixante-quatre pixels sont devenus environ deux nombres.

C'est pourquoi les régions plates d'un JPEG se compressent si bien. Le mode de défaillance est l'inverse : un bloc avec un bord vertical net disperse l'énergie sur de nombreux coefficients AC. La quantification met à zéro ceux haute fréquence, le bord s'adoucit, et à faible qualité vous voyez les artefacts classiques de bloc 8x8. Pour une analyse complète étape par étape incluant les mathématiques du sous-échantillonnage chroma, consultez l'image compression deep dive connexe.

Qu'est-ce que le codage Huffman et la compression en entropie ?

Une fois que la DCT et la quantification ont transformé un bloc en un flux d'entiers majoritairement petits (avec de longues séries de zéros), l'étape finale emballe ces entiers dans le moins de bits possible. C'est le codage en entropie, et le codage Huffman est le moteur principal.

Le codage Huffman attribue des codes binaires courts aux valeurs fréquentes et des codes longs aux valeurs rares. Si la valeur zéro apparaît 60 % du temps dans vos données quantifiées, elle pourrait obtenir un code de 2 bits, tandis qu'un coefficient rare et grand obtient 12 bits. Le format stocke une table de codes au début afin que le décodeur puisse l'inverser. Cette étape est entièrement réversible — elle n'introduit aucune perte — mais c'est là qu'une grande partie des économies d'octets apparaît réellement, car la quantification produit exactement la distribution biaisée que le codage Huffman exploite.

Les couches JPEG effectuent un encodage par longueur de séquence en plus : une série de quinze coefficients zéro identiques est encodée comme un seul symbole de saut plutôt que quinze valeurs séparées. L'article Wikipedia sur JPEG documente l'ordre de balayage zigzag exact et la structure de table Huffman si vous voulez le mettre en œuvre vous-même.

Les formats modernes vont plus loin. WebP et AVIF peuvent utiliser le codage arithmétique, qui extrait environ 5 à 10 % de plus que Huffman au prix d'un décodage plus lent. Brotli, utilisé ailleurs dans le transport web, combine un modèle de contexte plus grand avec Huffman ; la spécification Brotli (RFC 7932) vaut la peine d'être lue pour voir comment est construit un encodeur en entropie moderne.

Comment PNG et GIF utilisent-ils LZW et Deflate ?

Les formats sans perte ne peuvent pas quantifier, ils dépendent donc entièrement de la recherche et de la suppression de redondances. PNG et GIF empruntent des chemins différents.

PNG effectue deux étapes. Premièrement, le filtrage par ligne (row filtering) : chaque ligne de balayage est transformée à l'aide de l'un des cinq prédicteurs (None, Sub, Up, Average, Paeth), stockant la différence entre chaque pixel et une supposition basée sur un voisin au lieu de la valeur brute. Dans un gradient lisse, ces différences sont petites, regroupées près de zéro, et beaucoup plus faciles à compresser. Deuxièmement, Deflate : les octets filtrés passent par LZ77, qui remplace les séquences d'octets répétées par des références arrière, suivis du codage Huffman. Deflate est le même algorithme que ZIP utilise.

GIF prend un chemin plus simple avec LZW (Lempel-Ziv-Welch). LZW construit un dictionnaire de motifs à la volée : il commence par toutes les valeurs d'octets uniques, et au fur et à mesure qu'il lit les données, il ajoute des séquences de plus en plus longues qu'il a déjà vues. Lorsqu'une séquence se répète, elle est émise comme un seul index de dictionnaire. LZW est rapide et ne nécessite aucune table de codes stockée, raison pour laquelle GIF pouvait décoder sur du matériel des années 1990.

La vraie limitation de GIF n'est pas la compression. C'est la palette de couleurs forcée de 256 couleurs, appliquée avant l'exécution de LZW. Pour une photographie, cette quantification de couleur cause plus de dommages visibles que ce que la compression ne pourrait jamais faire. C'est pourquoi GIF persiste principalement pour les courtes animations malgré le fait que LZW soit parfaitement sain en soi.

Conseils pratiques pour PNG et GIF :

• Utilisez PNG-8 (indexé, jusqu'à 256 couleurs) pour les graphiques plats et les logos — il est beaucoup plus petit que PNG-24.
• Choisissez PNG ou WebP-lossless pour les captures d'écran et l'interface utilisateur riche en texte, où la quantification avec perte brouillerait les bords.
• Supprimez les blocs inutiles (EXIF, profils ICC non utilisés, un canal alpha sur des images opaques) avant de publier.
• Évitez GIF pour tout ce qui est photographique ; le plafond de 256 couleurs est le goulot d'étranglement, pas LZW.

Pourquoi WebP est-il plus petit, et pourquoi AVIF le bat-il ?

WebP et AVIF sont les deux formats modernes que la plupart des équipes utilisent aujourd'hui, et tous deux puisent dans les codecs vidéo. Ils gagnent en prédisant des blocs sur l'ensemble du cadre, et pas seulement à l'intérieur d'une grille fixe de 8x8 comme JPEG.

WebP-lossy utilise le codec vidéo VP8. Il applique la prédiction de blocs sur des tailles de blocs variables, utilise les transformations 4x4 et 8x8, et un meilleur encodeur en entropie que le JPEG de base. Le résultat est environ 25 à 34 % plus petit que JPEG avec une qualité visuelle équivalente. WebP-lossless empile jusqu'à 13 modes de prédiction, une transformation d'espace couleur et une variante LZ77, battant généralement PNG de 20 à 26 %.

AVIF va plus loin en réutilisant les outils intra-frame du codec vidéo AV1. Les tailles de blocs variables vont de 4x4 jusqu'à 128x128, il y a 67 modes de prédiction directionnelle, et le filtrage en boucle adoucit les artefacts avant que le cadre ne soit finalisé. AVIF bat généralement WebP-lossy d'encore 20 à 30 % sur les photographies.

Le compromis honnête est la vitesse. L'encodage AVIF est environ 5 à 10 fois plus lent que WebP, car la prédiction et le filtrage sont coûteux en calcul. Pour une étape de construction exécutée une seule fois, c'est acceptable. Pour une conversion en temps réel dans un chemin de requête actif, cela peut nuire. HEIC, le conteneur d'Apple pour les images HEVC, offre des gains similaires à AVIF mais entraîne un fardeau plus lourd de licences de brevets, raison pour laquelle le web ouvert s'est standardisé sur AVIF à la place.

Quels paramètres de qualité de compression devriez-vous utiliser ?

Commencez par ces valeurs par défaut, puis ajustez en fonction de votre contenu spécifique. Ce sont des points de départ, pas des lois.

Deux règles sont plus importantes que le nombre exact. Premièrement, comparez les formats à une qualité visuelle équivalente, et non à des nombres de qualité correspondants — AVIF à 60, WebP à 75 et JPEG à 85 semblent globalement similaires, donc comparer les trois à "80" est sans signification. Deuxièmement, redimensionnez toujours avant de compresser. Un original photo de 4000 pixels exporté à qualité 80 reste un téléchargement de 4000 pixels ; le passage à une taille d'affichage réduit plus d'octets que n'importe quel ajustement de qualité.

J'ai mesuré cela directement. J'ai encodé la même photographie de 1200x800 à JPEG q75, WebP q75 et AVIF q60, jugée visuellement équivalente à la taille d'affichage. Le JPEG faisait 174 KB, le WebP faisait 128 KB et l'AVIF faisait 96 KB — soit environ 26 % de moins que WebP et 45 % de moins que JPEG, pour une image que je ne pouvais pas distinguer de manière fiable en A/B aveugle. Vos chiffres varieront avec le contenu, mais l'ordre est constant. Pour un outil ciblé afin d'exécuter ces comparaisons vous-même, essayez Image Compressor ou lisez la comparaison AVIF vs WebP.

Comment choisir le bon algorithme pour chaque image ?

La décision est dictée par le contenu, et non par le format le plus récent.

• Photographies et gradients complexes : WebP ou AVIF lossy. Les octets les plus petits, et l'œil cache la perte.
• Texte net, captures d'écran d'interface utilisateur, art linéaire, logos : PNG ou WebP lossless. La quantification brouillerait les bords et l'aliasing.
• Découpes transparentes : WebP ou PNG lossless. Méfiez-vous des artefacts de halo sur les bords alpha.
• Courtes animations simples : WebP animé (ou AVIF). Évitez GIF pour tout ce qui est détaillé.
• Maîtres d'archives : conservez l'original RAW ou un JPEG de haute qualité. Ne traitez jamais une exportation avec perte comme un maître.
• Solution de repli à compatibilité maximale : JPEG, servi via un élément <picture> afin que les navigateurs modernes reçoivent toujours AVIF ou WebP.

Un flux de travail pratique, dans l'ordre : conserver un maître propre, redimensionner à la plus grande boîte d'affichage avec Image Resizer, choisir le format selon le contenu, exporter deux ou trois candidats qualité, supprimer les métadonnées inutiles, et inspecter le résultat à la taille d'affichage finale. Le guide de compression d'images sans perte passe en revue l'intégralité du processus. Vous pouvez également consulter le guide de format d'image de Google pour les notes sur la compatibilité des navigateurs lorsque vous configurez les solutions de repli.

Erreurs courantes de compression

• Recompresser un JPEG déjà avec perte. Chaque encodage ajoute des artefacts. Modifiez toujours à partir d'un maître.
• Utiliser PNG pour toutes les photographies parce que cela semble sûr. PNG n'a pas d'étape de quantification, donc une photo reste énorme.
• Faire confiance à un seul nombre de qualité sur tous les formats. Les échelles JPEG, WebP et AVIF ne sont pas comparables.
• Optimiser avant de redimensionner. Réduisez la taille en premier — c'est le plus grand gain d'octets disponible.
• Servir AVIF ou WebP sans solution de repli JPEG. Les anciens navigateurs et la plupart des clients de messagerie ne rendent rien.
• Laisser un sous-échantillonnage chroma 4:2:0 sur du texte coloré. Cela étale les rouges et les bleus ; utilisez 4:4:4 ou PNG pour le texte.
• Ignorer le coût d'encodage. Les gains d'AVIF sont réels, mais l'encoder à chaque requête peut dominer le CPU.

Résumé : les algorithmes sont un moyen, pas une fin

Les algorithmes de compression ne sont pas des victoires gratuites. AVIF vous donne les fichiers les plus petits, mais son coût d'encodage peut être punitif dans un chemin actif, et son décodage est plus lourd que JPEG sur les appareils peu puissants. PNG est parfaitement sans perte, mais le servir pour une photo héroïque gonflera votre Largest Contentful Paint sans bénéfice visible. La bonne réponse est presque toujours une décision format-par-contenu servie avec un mécanisme de repli, et non un seul paramètre global.

La compétence la plus utile n'est pas de mémoriser les matrices de quantification — c'est de juger chaque image à sa taille d'affichage réelle, de conserver un maître propre, et de réencoder une seule fois au lieu de cumuler les pertes. Maîtrisez ce flux de travail et le format spécifique devient un choix secondaire.

Crédits d'images

• Motif pixélisé abstrait bleu et rose — photo par Suzy Hazelwood sur Pexels
• Barres d'essai colorées — photo par Tim Mossholder sur Pexels
• Gros plan sur du code source coloré sur un écran — photo par Pixabay sur Pexels