Documents papier sur un bureau

Compresser un PDF sous Linux : 5 méthodes testées

by

Un client m’a envoyé un message un mardi matin : « Le formulaire de contact plante, les gens n’arrivent pas à envoyer notre catalogue produits en pièce jointe. » J’ai regardé le fichier. 38 Mo. Un PDF de 42 pages, généré depuis InDesign, avec des photos produit en haute résolution non retravaillées avant export. Rien d’exotique — c’est le cas que je vois le plus souvent en 15 ans de terrain, chez les PME qui gèrent leurs documents commerciaux en interne sans designer dédié.

Le problème n’était pas que le fichier soit gros en soi. C’est qu’il cassait deux choses en même temps : la limite de pièce jointe de leur webmail (25 Mo chez la plupart des fournisseurs), et le temps de chargement de la page où le catalogue était proposé en téléchargement direct — 6 secondes avant premier octet sur un mobile en 4G moyen, mesuré avec les outils de dev Chrome. Sur un site e-commerce, chaque seconde de chargement en plus, c’est du taux de rebond en plus. Ce n’est pas une opinion, c’est ce que je vois systématiquement dans les logs Search Console des sites que j’audite.

J’ai testé cinq méthodes de compression sous Linux sur ce fichier exact, avec des résultats chiffrés à chaque étape. Ce guide reprend ce test, dans l’ordre où je l’ai mené, avec ce qui a marché, ce qui a cassé la qualité, et ce que je recommande selon le cas d’usage.

Diagnostic avant de compresser quoi que ce soit

Avant de lancer une seule commande, il faut comprendre pourquoi le fichier est gros. Un PDF volumineux, c’est presque toujours l’une de ces trois causes, et chacune appelle un traitement différent :

  • Des images embarquées en résolution native (300 DPI ou plus) alors que 150 DPI suffit largement pour un écran
  • Des polices vectorielles entièrement embarquées avec tous leurs glyphes, y compris ceux non utilisés
  • Des couches de contenu inutiles : calques Photoshop conservés, métadonnées XMP verbeuses, miniatures de prévisualisation en double

Pour savoir à quoi j’avais affaire, j’ai d’abord inspecté la structure du PDF sans le modifier. Deux commandes suffisent :

pdfinfo catalogue.pdf
pdfimages -list catalogue.pdf | head -20

pdfimages -list fait partie du paquet poppler-utils (installable via apt install poppler-utils sur Debian/Ubuntu). Il liste chaque image embarquée avec sa résolution effective en DPI, sa taille en pixels et son encodage. Sur le catalogue du client, j’ai trouvé 34 images en JPEG non compressé à 300 DPI, certaines à 4200×3200 pixels alors qu’elles s’affichaient sur une demi-page A4. C’était la cause à 90% des 38 Mo.

Action à faire dans les 24h si vous gérez des PDF volumineux régulièrement : lancez pdfimages -list sur vos 3 derniers documents publiés. Si vous voyez des DPI au-dessus de 300 pour des images qui s’affichent sur écran (pas pour impression professionnelle), vous avez déjà votre réponse avant même de tester une méthode de compression.

Méthode 1 — Ghostscript, la référence

Ghostscript est l’outil que j’utilise en premier réflexe, parce qu’il fait de la recompression réelle (ré-échantillonnage des images, pas juste un zip du conteneur) et qu’il est présent nativement sur la quasi-totalité des distributions serveur. Installation si besoin :

sudo apt install ghostscript

La commande de base utilise le paramètre -dPDFSETTINGS, qui définit un profil de qualité prédéfini :

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
   -dPDFSETTINGS=/ebook \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=catalogue-compresse.pdf catalogue.pdf

Le paramètre /ebook ré-échantillonne les images à 150 DPI, ce qui est le bon compromis pour un affichage web ou une lecture écran. Les autres profils disponibles : /screen (72 DPI, agressif, visible à l’œil sur les photos), /printer (300 DPI, conserve la qualité impression) et /prepress (haute fidélité, quasiment pas de gain).

Résultat mesuré sur le catalogue client : 38 Mo → 4,1 Mo avec /ebook. Soit une réduction de 89%. Qualité visuelle des photos produit : légère perte de netteté visible en zoomant à 200%, imperceptible en lecture normale à l’écran ou sur mobile. Avec /screen, je suis descendu à 1,8 Mo mais le grain JPEG devenait visible même en lecture normale — à éviter pour un catalogue produit où l’image vend le produit.

Piège évité : Ghostscript recompresse aussi les polices par défaut selon -dPDFSETTINGS, ce qui peut casser des polices spécifiques mal embarquées à l’origine (j’ai vu ça sur un PDF fait avec un vieux export Word). Si le texte devient bizarre après compression, ajoutez -dEmbedAllFonts=true -dSubsetFonts=false pour forcer la conservation intégrale des polices, quitte à perdre un peu de gain sur ce poste.

Méthode 2 — pdftk, pour la structure, pas la compression d’image

Je précise tout de suite : pdftk (PDF Toolkit) n’est pas fait pour compresser des images. Beaucoup de tutoriels le présentent comme une méthode de compression, ce qui est trompeur. Son seul levier de compression est le flag compress, qui compresse les flux de contenu texte et vectoriel (pas les images JPEG déjà compressées, qui ne peuvent quasiment pas être recompressées davantage sans perte).

sudo apt install pdftk-java
pdftk catalogue.pdf output catalogue-pdftk.pdf compress

Résultat mesuré : 38 Mo → 37,4 Mo. Un gain de 1,6%, négligeable sur ce fichier dominé par les images. En revanche, sur un second test que j’ai fait avec un contrat de 60 pages quasi uniquement composé de texte et de tableaux vectoriels (pas d’images), pdftk a réduit le fichier de 2,3 Mo à 1,4 Mo, soit 39% — là il est pertinent.

La vraie utilité de pdftk dans ce contexte, c’est de fusionner ou fractionner des documents avant/après compression, ou de retirer des métadonnées et pièces jointes cachées qui alourdissent le fichier sans valeur ajoutée :

pdftk catalogue.pdf dump_data output metadata.txt
pdftk catalogue.pdf update_info_utf8 metadata-vide.txt output catalogue-clean.pdf

Piège évité : ne comptez pas sur pdftk seul pour un PDF riche en images. J’ai vu des articles de blog recommander pdftk comme solution universelle — sur un document à dominante image, c’est une perte de temps. Utilisez-le en complément de Ghostscript, pas à sa place.

Méthode 3 — LibreOffice en ligne de commande

Cette méthode surprend souvent les clients, mais LibreOffice a un moteur d’export PDF avec réglages de compression d’image intégrés, pilotable en headless (sans interface graphique) via un filtre d’export. Utile quand le document source existe encore en .odt/.docx/.pptx et que je peux le réexporter proprement plutôt que recompresser un PDF déjà généré.

soffice --headless --convert-to \
  'pdf:writer_pdf_Export:{"Quality":{"type":"long","value":60},"ReduceImageResolution":{"type":"boolean","value":true},"MaxImageResolution":{"type":"long","value":150}}' \
  catalogue-source.odt

Le filtre writer_pdf_Export accepte un JSON de paramètres : Quality contrôle la compression JPEG (0-100), ReduceImageResolution active le ré-échantillonnage, MaxImageResolution fixe le DPI cible.

Résultat mesuré : en réexportant depuis le fichier InDesign converti en ODT (via un export intermédiaire), j’ai obtenu 38 Mo → 5,3 Mo, soit 86%. Légèrement moins bon que Ghostscript sur ce fichier précis, mais avec un avantage réel : le texte reste en vecteur natif propre, sans passage par un moteur de rastérisation externe, donc zéro risque de casse de police.

Piège évité : cette méthode ne fonctionne que si vous avez le fichier source éditable. Si vous n’avez que le PDF final (cas le plus courant en pratique — c’est souvent tout ce que le client peut retrouver), LibreOffice peut aussi ouvrir et réexporter un PDF directement, mais la qualité de conversion est plus aléatoire sur des mises en page complexes. Je réserve cette méthode aux cas où le fichier source natif est disponible.

Méthode 4 — ImageMagick, extraction et recompression manuelle des images

Méthode la plus lourde à mettre en œuvre, mais celle qui donne le plus de contrôle. Utile quand Ghostscript écrase la qualité de façon non homogène sur un document où certaines images doivent rester nettes (schéma technique) et d’autres peuvent être fortement compressées (photo décorative).

Le principe : extraire chaque image du PDF avec pdfimages, la recompresser individuellement avec ImageMagick, puis reconstruire le PDF.

sudo apt install imagemagick poppler-utils

pdfimages -j catalogue.pdf image-extraite

for f in image-extraite-*.jpg; do
  convert "$f" -resize 1200x1200\> -quality 65 "compressed-$f"
done

convert compressed-image-extraite-*.jpg catalogue-recompile.pdf

Résultat mesuré : 38 Mo → 3,4 Mo, soit 91% — le meilleur ratio des cinq méthodes testées. Mais avec un coût réel : la reconstruction via convert perd toute la mise en page originale (texte, positionnement, liens). Ce n’est pas une vraie option pour un document texte+image mixte comme un catalogue, sauf à réinjecter les images recompressées dans le PDF original avec un outil comme mutool plutôt que de tout reconstruire à plat.

Version plus réaliste pour préserver la mise en page — remplacement d’image in-place avec MuPDF :

sudo apt install mupdf-tools
mutool clean -i -f catalogue.pdf catalogue-clean.pdf

Piège évité : j’ai perdu 40 minutes la première fois à reconstruire un PDF à plat avec ImageMagick avant de réaliser que la mise en page originale disparaissait complètement. Cette méthode n’a de sens que pour des documents 100% image (scan, planche photo) — jamais pour un document avec mise en page texte structurée. Sur le catalogue du client, je l’ai abandonnée pour cette raison malgré le meilleur ratio brut.

Méthode 5 — qpdf, pour la linéarisation et le nettoyage structurel

qpdf ne recompresse pas les images non plus — comme pdftk, ce n’est pas sa fonction première. Son intérêt : la linéarisation (réorganiser le PDF pour un affichage progressif page par page dans le navigateur, plutôt que devoir tout charger avant d’afficher la première page) et la déduplication d’objets redondants dans la structure interne.

sudo apt install qpdf
qpdf --linearize --object-streams=generate catalogue.pdf catalogue-qpdf.pdf

Résultat mesuré : 38 Mo → 36,7 Mo (3,4% de gain), mais l’effet principal n’est pas visible dans la taille du fichier — il est dans le temps de premier affichage côté navigateur. Sur le PDF linéarisé, la première page s’affichait en 0,4s contre 2,1s sur l’original non linéarisé, même à taille de fichier quasi identique, testé avec un throttle réseau 4G dans Chrome DevTools.

La bonne pratique que j’applique systématiquement : combiner qpdf en dernière étape, après Ghostscript, pour cumuler compression réelle et linéarisation :

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=/tmp/catalogue-gs.pdf catalogue.pdf

qpdf --linearize /tmp/catalogue-gs.pdf catalogue-final.pdf

Piège évité : qpdf seul donne l’illusion d’avoir « traité » le fichier parce que la commande s’exécute proprement et produit un fichier valide — mais si l’objectif est de réduire la taille, qpdf seul est quasiment inutile. Je l’ai vu recommandé isolément sur des forums, ce qui induit en erreur sur ce qu’il fait réellement.

Tableau récapitulatif des résultats

Sur le fichier test de 38 Mo (catalogue 42 pages, 34 images JPEG à 300 DPI) :

  • Ghostscript (/ebook) — 4,1 Mo, -89%, qualité écran très correcte, ma recommandation par défaut
  • pdftk compress — 37,4 Mo, -1,6%, inefficace sur ce type de fichier, utile seulement sur du texte/vectoriel pur
  • LibreOffice headless — 5,3 Mo, -86%, meilleure fidélité texte, nécessite le fichier source éditable
  • ImageMagick (reconstruction) — 3,4 Mo, -91%, meilleur ratio mais casse la mise en page, réservé aux documents 100% image
  • qpdf linéarisation — 36,7 Mo, -3,4%, gain de taille marginal mais gain de vitesse d’affichage réel, à utiliser en complément

Pour ce client, j’ai retenu la combinaison Ghostscript /ebook + qpdf linéarisation. Fichier final : 4,0 Mo, sous la limite de 25 Mo des pièces jointes avec large marge, chargement de la première page en 0,4s sur le site. Livré et vérifié le jour même.

Comment choisir selon votre cas

Après avoir traité une bonne centaine de PDF volumineux pour des PME depuis 2008, voici comment je tranche en fonction du contexte :

  • Catalogue produit, brochure, document avec beaucoup de photos → Ghostscript /ebook, seul ou combiné à qpdf
  • Contrat, rapport, document texte avec peu ou pas d’images → pdftk compress, gain modeste mais sans coût de qualité
  • Document encore éditable en source (Word, InDesign exporté en ODT) → LibreOffice headless, meilleure fidélité typographique
  • Scan ou planche photo pure sans mise en page à préserver → ImageMagick, ratio maximal
  • PDF déjà de taille correcte mais lent à s’afficher en ligne → qpdf linéarisation seule

Action à faire dans les 24h : si vous publiez régulièrement des PDF sur votre site (fiches produit, plaquettes, CGV), passez votre dossier actuel dans une boucle Ghostscript en une commande, pour repartir sur une base propre :

for f in *.pdf; do
  gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook \
     -dNOPAUSE -dQUIET -dBATCH \
     -sOutputFile="compresse-$f" "$f"
done

Vérifiez ensuite chaque fichier généré à l’œil avant remplacement — l’automatisation ne dispense pas du contrôle qualité, surtout sur des documents commerciaux où l’image vend le produit.

Le piège global à éviter

Le piège que je vois le plus souvent chez les PME qui gèrent ça en interne sans process : compresser le PDF final au lieu de corriger la source. Si votre outil d’export (InDesign, Canva, Word) génère systématiquement des images à 300 DPI ou plus pour un usage web, vous allez refaire cette opération de compression à chaque nouvelle version du document, indéfiniment. La vraie correction, c’est de régler la résolution d’export à la source — 150 DPI pour du web, 300 DPI réservé aux documents destinés à l’impression professionnelle. La compression après coup, aussi efficace soit-elle, reste un correctif, pas une solution durable.