Pourquoi mon PDF ne devient-il pas beaucoup plus petit ?
Une faible réduction peut être un résultat raisonnable. La compression dispose de moins de marge quand le PDF stocke déjà efficacement son contenu. Jugez la taille réelle et la lisibilité du résultat, sans attendre une économie fixe pour chaque document.
Réécrire ne garantit pas une taille inférieure
Un outil de compression lit et réécrit les données, mais leur nouvelle représentation n’est pas forcément plus petite. Les explications de Ghostscript sur l’optimisation PDF indiquent que sa sortie peut grossir. Une structure supplémentaire ou un autre encodage peut dépasser les économies réalisées ailleurs. Aucun pourcentage identique ne convient donc à tous les fichiers.
Comparez les tailles exactes avant et après traitement. Gardez la version utilisable la plus petite ainsi que l’original. Si le changement est minime, examinez le contenu avant de multiplier les traitements.
Les données déjà comprimées offrent peu de marge
Les images et les flux de données peuvent déjà bénéficier d’une compression efficace. Le manuel d’optimisation qpdf explique que les flux déjà comprimés avec Flate sont généralement conservés, sauf demande de recompression. Nettoyer la structure peut aider, mais rien ne permet de supposer que chaque PDF contient beaucoup de données superflues.
Traiter plusieurs fois un fichier optimisé peut donc apporter peu. Si vous possédez la source modifiable, examinez ses options d’export. Les images inutiles ou une résolution excessive peuvent être corrigées à cette étape, en gardant une référence lisible.
Images et texte offrent des possibilités différentes
Ghostscript décrit les images comme une composante souvent volumineuse lorsqu’elles sont présentes. Un scan fait d’images pleine page peut permettre de réduire la résolution ou de changer l’encodage. Un rapport surtout composé de texte et de dessins vectoriels peut contenir bien moins de données d’image à réduire.
Cette différence dépend du stockage du contenu ; elle ne promet pas que tout scan se compressera bien. Le nombre de pages ne prédit pas non plus le gain. Consultez le guide des PDF numérisés.
Une compression plus forte peut effacer des détails
Réduire la résolution enlève des détails. Un réencodage avec pertes peut créer des défauts visibles. Ghostscript avertit des risques de recompression JPEG ; qpdf documente aussi les artefacts JPEG. Répéter une opération avec pertes n’améliore pas sûrement le compromis entre qualité et taille.
Comparez petits caractères, tampons, traits fins et schémas à un agrandissement de lecture utile. Vérifiez toutes les pages importantes, pas seulement la couverture. Acceptez la copie réduite si les détails restants conviennent à son usage. Sinon, conservez l’original.
Décider selon les besoins du destinataire
Si plusieurs fichiers sont acceptés, divisez le PDF par taille pour préserver la lisibilité. L’organisation des pages permet de retirer celles qui sont inutiles ; vérifiez ensuite leur ordre. Pour un courriel, lisez le guide de compression et de division.
Essayez la compression PDFThin sur une copie et évaluez le résultat. Elle ne garantit pas une réduction, ne fait pas d’OCR et ne certifie pas PDF/A. Pour les archives, lisez PDF et PDF/A avant de modifier le document conservé.
Un exemple mesuré sur un scan artificiel
Le 7 octobre 2026, nous avons utilisé le traitement local PDFThin sur un scan artificiel créé pour ce test : une page contenant uniquement une image à 144 dpi. Les petits caractères avaient initialement des tailles de 6, 8, 10 et 12 points. Ce n’était ni un traitement en production ni un document client. L’entrée comptait 1 210 534 octets ; le traitement sans perte a produit 1 210 511 octets, soit seulement 23 octets économisés.
La compression d’image visait 1 Mio, soit 1 048 576 octets, avec une marge de sécurité de 262 144 octets : la cible effective était de 786 432 octets. La méthode qpdf-chunked en qualité 55 a produit 248 498 octets, environ 79,5 % de moins que l’original. Un deuxième passage avec la même cible a donné 247 683 octets, environ 0,3 % de moins. Il utilisait mutool-clean : l’entrée était déjà sous la cible, sans nécessité d’un nouveau traitement d’image avec pertes. Cela ne prouve pas que la compression maximale possible était atteinte.
Les petits caractères restaient déchiffrables, avec de légers changements des contours et des fonds. Comparez ces recadrages sans perte du texte en 8 et 6 points au même zoom. Les résultats varient : ce fichier artificiel ne garantit ni réduction ni lisibilité pour un autre document.
Un petit fichier texte peut déjà respecter la limite
Le 7 octobre 2026, nous avons aussi testé un PDF artificiel d’une page contenant du texte et des lignes vectorielles, avec les mêmes petites lignes de texte que le scan ci-dessus. Il ne pesait que 961 octets. Il utilise la police Helvetica non incorporée et des lignes simples ; les vrais documents avec des polices incorporées ou des images peuvent être bien plus lourds. Le traitement sans perte et celui visant 1 MiB ont tous deux renvoyé l’entrée de 961 octets sans modification ni compression d’image.
Avec la même cible de 1 MiB, le scan composé uniquement d’une image est passé de 1 210 534 à 248 498 octets. Ce sont des exemples indépendants, avec des fonds, des modes de stockage et une rastérisation différents, pas une comparaison contrôlée de pages identiques. Ces résultats ne définissent ni un gain général ni une limite de compression. La cible est un paramètre de test du traitement, pas un préréglage public.
Si votre fichier respecte déjà la limite du destinataire, vérifiez qu’il est utilisable et arrêtez là. Pour un gros fichier texte, examinez les images et les réglages de polices et d’export dans la source. Pour un scan, comparez les détails fins après traitement. Décidez selon le fichier réel et les conditions d’envoi.