J'ai enregistré une démonstration de 5 secondes, exportée en GIF : 18 Mo.
Coller dans un document, envoyer dans un groupe, mettre dans un README... soit l'upload échoue, soit ça tourne en boucle avant d'afficher l'image.
Comment un "animé" peut-il être plus lourd qu'une vidéo ? Et comment le réduire sans qu'il soit plein de grain ou de bruit ?

Comprendre d'abord : pourquoi les GIF sont-ils si lourds ?

Le format GIF est de 1987, et ses caractéristiques intrinsèques le rendent "gros" :

Chaque frame est une image complète. Il n'y a pas de compression entre les frames comme dans les vidéos — sauf si optimisé à l'export, 100 frames = 100 images.
L'algorithme de compression est ancien. Le GIF n'utilise que la compression LZW sans perte, excellente pour les zones de couleur unie, mais inefficace avec les dégradés, les photos ou les textures fines.
Maximum 256 couleurs par frame. Si la palette manque de couleurs, l'outil utilise du "dithering" — des points de couleur variés pour simuler les transitions. Ces points de bruit sont imperceptibles à l'œil nu, mais pour LZW, ce sont les données les plus difficiles à compresser.

Le volume d'un GIF dépend donc principalement de : taille × nombre de frames × complexité de l'image. Les méthodes ci-dessous visent ces trois leviers.

Six méthodes, classées par perte de qualité croissante

1. Optimisation de frames : ne garder que la partie qui change (sans perte)

De nombreux outils d'enregistrement d'écran ou logiciels de design exportent des GIF où chaque frame contient toute l'image. Or, dans une démo, seule la souris et une petite zone bougent.

L'optimisation de frames fait ceci : conserve pour chaque frame uniquement la zone rectangulaire qui diffère de la précédente ; le reste est représenté par des pixels transparents. Une fois liés, ces pixels transparents permettent à LZW de compresser très efficacement.

L'image ne perd pas un seul pixel, l'animation reste identique, seule la méthode de stockage change. C'est particulièrement utile pour les GIF "fond fixe, mouvement local" (captures d'écran, démos UI, emojis).

2. LZW avec perte : "un peu de souplesse" dans l'algorithme (visuellement sans perte)

C'est l'idée derrière l'option --lossy de gifsicle : autoriser une légère erreur de couleur lors du codage, de sorte que plus de pixels soient considérés comme "de la même couleur" et puissent être regroupés, augmentant ainsi l'efficacité de LZW.

Cela ne réduit pas le nombre de couleurs, ne change pas la taille ni le nombre de frames, mais introduit un léger grain. Plus la valeur est élevée, plus la compression est forte et le grain visible. Pour une utilisation légère (par exemple --lossy=30~40), il est souvent indétectable à l'œil nu.

3. Réduction du nombre de couleurs : de 256 à 128 ou 64

Réduire la palette de 256 à 128 ou 64 couleurs signifie que chaque pixel contient moins d'information, ce qui améliore le taux de compression.

Pour les illustrations plates, les icônes animées ou les captures UI où les couleurs sont peu variées, cette réduction est presque sans perte. En revanche, pour les photos ou les images riches en dégradés, on observe des bandes de couleur et des blocs visibles.

4. Réduction des frames : baisser le taux d'images

De nombreux GIF sont exportés à 30 ou 60 fps, or le format GIF n'est pas optimisé pour les hautes fréquences ; 10~15 fps suffisent souvent pour la plupart des scénarios.

Couper le nombre de frames par deux réduit généralement le poids de moitié. L'inconvénient est une animation moins fluide — cela n'impacte pas les démos d'opération, mais peut être gênant pour les animations nécessitant de la fluidité.

5. Réduire la taille de l'image

Le poids est proportionnel au nombre de pixels : réduire la largeur et la hauteur de moitié divise le nombre de pixels par quatre.

Les captures faites sur des écrans Retina font souvent plusieurs milliers de pixels de large, alors qu'elles sont affichées ensuite sur une largeur de 600~800 pixels. Exporter en fonction de la taille réelle d'affichage est souvent la méthode la plus rentable. Attention toutefois : l'image sera plus floue si agrandie, et le texte doit rester lisible.

6. Changer de format : passer du GIF à la vidéo ou WebP

Si la plateforme le permet, la méthode la plus radicale est de ne pas utiliser GIF :

MP4 / WebM : les codecs vidéo modernes utilisent la compression entre les frames, ce qui permet d'obtenir un poids souvent inférieur d'un facteur 5 à 10 pour le même contenu. Sur le web, <video autoplay loop muted playsinline> permet d'obtenir le même effet.
WebP animé / APNG : supportent plus de couleurs et une meilleure compression, lisibles par la plupart des navigateurs modernes.

L'inconvénient est la compatibilité : beaucoup d'applications de discussion, forums, outils de documentation ou clients de messagerie ne reconnaissent que le GIF. Changer de format peut entraîner une impossibilité d'affichage ou l'absence de lecture automatique.

Tableau récapitulatif des compromis

Méthode	Impact sur la qualité	Idéal pour	À éviter
Optimisation de frames	Aucune (pixels inchangés)	Tous les GIF, surtout captures et animations locales	— (doit être appliqué systématiquement)
LZW avec perte (léger)	Légère granulosité	La plupart des GIF	Pixel art très sensible au grain
Réduction des couleurs	Bandes de couleur sur les dégradés	Illustrations plates, icônes, UI	Photos, images riches en dégradés
Réduction des frames	Mouvement moins fluide	Démos d'opération, animations statiques	Animations nécessitant fluidité
Réduction de la taille	Moins de détails	Images plus grandes que leur affichage final	Contenu nécessitant de lire du petit texte
Changement de format	Souvent meilleur	Sites web, plateformes maîtrisées	Plateformes ne reconnaissant que le GIF

L'ordre recommandé est : appliquer d'abord les méthodes sans perte ou à très faible perte, puis, si nécessaire, passer aux étapes suivantes. Si les deux premières étapes suffisent à réduire le poids, il n'est pas nécessaire de sacrifier les couleurs, le nombre de frames ou la résolution.

Les deux premières étapes, faites en masse avec ImgZilla

Si vous avez un lot de GIF — collection d'emojis, animations dans des documents, répertoires de ressources web — paramétrer un outil en ligne image par image est fastidieux.

ImgZilla est un outil de compression d'images pour macOS qui applique exactement les deux premières méthodes de ce tableau :

Basé sur gifsicle : effectue d'abord une optimisation de frames maximale (équivalent à -O3), puis ajoute une compression LZW avec perte légère (équivalent à --lossy=40).
Pas de réduction de couleurs, de suppression de frames, de changement de taille ou de boucle. L'animation reste inchangée, le nombre de frames, la durée et la résolution sont conservés, seul le fichier est plus léger.
Compression "in-place" : le nom, le chemin et le format du fichier ne changent pas. Le demo.gif référencé dans un document, une page web ou un Markdown reste demo.gif après compression, sans changer les liens.
Glisser-déposer un dossier entier : analyse récursivement les sous-dossiers et traite les GIF avec les autres formats d'images (JPG, PNG, WebP, etc.).
Pas de "surcompression" forcée : les fichiers déjà optimisés avec un taux de compression inférieur à 0,4 % sont marqués "déjà minimal" et conservés tels quels, sans consommer de quota.
Déplacement de l'original vers la corbeille : si le résultat ne vous convient pas, un clic droit sur "Restaurer" replace le fichier d'origine.
Traitement entièrement local : aucun envoi vers un serveur, pas de limitation par fichier ou par nombre de fichiers comme sur les outils en ligne — même des GIF de plusieurs dizaines de Mo sont gérés sans problème.

Le gain dépend de la qualité d'origine du GIF. Ceux qui n'ont pas été optimisés en frames et qui comportent beaucoup de zones fixes sont généralement les plus gros économies. Les GIF déjà traités par des outils professionnels peuvent ne laisser que peu de marge, voire être marqués "déjà minimal" — c'est normal.

Ce que ImgZilla ne fait pas

Pour préserver l'apparence de l'animation, ImgZilla ne s'occupe pas des étapes 3 à 6. Si le résultat après les deux premières étapes reste trop volumineux, et que vous devez absolument rester sous une limite de taille, vous devrez décider vous-même de ce que vous sacrifiez :

bash

Avec gifsicle en ligne de commande : passer à 128 couleurs, largeur réduite à 640, compression plus forte

gifsicle -O3 --lossy=80 --colors 128 --resize-width 640 input.gif -o output.gif

Avec ffmpeg pour convertir le GIF en MP4 (poids généralement beaucoup plus faible)

ffmpeg -i input.gif -movflags +faststart -pix_fmt yuv420p
-vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" output.mp4

Pour des opérations nécessitant de sélectionner des frames ou de couper la durée, des éditeurs en ligne comme ezgif sont plus intuitifs.

Une meilleure habitude : éviter d'exporter des GIF trop lourds dès la source

Trois conseils pour réduire le nombre de compressions futures :

Réduire la fenêtre d'enregistrement : ne filmer que la zone nécessaire, pas toute la surface de l'écran Retina.
Exporter à 10~15 fps : suffisant pour la plupart des démonstrations.
Compresser rapidement après l'export : appliquer l'optimisation de frames et la compression LZW légère — cette étape ne nécessite pas de jugement et est adaptée à un traitement par lots.

Le GIF est un format ancien, mais il reste le "grand commun diviseur" pour l'auto-lecture partout. Plutôt que de se demander s'il faut l'abandonner, autant faire en sorte que chaque GIF occupe juste l'espace nécessaire.

ImgZilla est actuellement disponible uniquement sur macOS (version 12.3 et supérieure), disponible sur l'App Store Mac. La version gratuite permet de compresser 10 GIF par jour ; le quota est compté uniquement sur les compressions réussies — glissez votre dossier rempli de GIF et voyez ce que vous pouvez économiser.

Comment réduire la taille des GIF : six méthodes, classées par perte de qualité croissante