Compresseur d’images d’application : WebP et JPEG sans envoi de fichier

Déposez vos visuels, choisissez un format et une qualité : chaque image ressort allégée, avec son poids avant et après en Ko et le gain obtenu, fichier par fichier. Tout se passe dans votre navigateur, du décodage à l’archive finale : vos images ne quittent jamais votre machine.

Mode d’emploi : des fichiers lourds au dossier allégé

L’outil accepte plusieurs images à la fois et les traite en série. Le parcours complet tient en cinq gestes :

1. Déposez vos fichiers dans la zone « Vos images (PNG, JPEG ou WebP, plusieurs fichiers acceptés) ». Vous pouvez les glisser directement depuis votre explorateur ou cliquer pour ouvrir le sélecteur. Chaque fichier est décodé localement et son poids d’origine s’affiche aussitôt : c’est la référence que la compression devra battre.
2. Choisissez le « Format de sortie » : « WebP (recommandé) » ou « JPEG ». Le WebP produit des fichiers nettement plus légers à qualité visuelle comparable et conserve la transparence ; le JPEG reste le choix de la compatibilité maximale, notamment pour les consoles de publication des stores qui ne l’acceptent pas encore partout.
3. Réglez le curseur « Qualité ». Il va de 50 à 95 et se trouve préréglé à 80, le point d’équilibre habituel entre poids et fidélité. Montez vers 85 ou 90 pour des captures contenant beaucoup de texte, descendez vers 60 ou 70 pour des photos d’ambiance où un léger lissage passe inaperçu.
4. Sélectionnez la « Largeur maximale » : « Largeur d’origine », « 2048 pixels », « 1600 pixels » ou « 1280 pixels ». Toute image plus large que la limite choisie est réduite proportionnellement avant compression ; les images plus petites ne sont jamais agrandies. C’est souvent ce réglage, bien plus que la qualité, qui produit les gains spectaculaires.
5. Cliquez sur « Compresser les images ». Le tableau de résultats affiche une ligne par fichier : poids avant, poids après et gain en pourcentage, avec un bouton « Télécharger » par ligne pour récupérer un fichier isolé. Le bouton « Tout télécharger en ZIP » livre l’ensemble en une archive, et la ligne de total résume le poids économisé sur le lot complet.

Un réflexe utile : comparez visuellement une image compressée avec son original à taille réelle avant de généraliser un réglage. Si aucun défaut ne saute aux yeux sur votre écran, vos visiteurs n’en verront pas davantage sur le leur.

Pourquoi le poids de vos images pèse sur tout le reste

Dans un projet d’application mobile, les images s’accumulent partout : captures d’écran des fiches de stores, visuels de la page produit, illustrations du site vitrine, images embarquées dans l’application elle-même. Chacune de ces destinations paie le poids au prix fort, pour des raisons différentes.

• Sur votre site ou votre page d’atterrissage, les images constituent la majeure partie des octets transférés. Une page produit qui charge dix visuels de 2 Mo impose 20 Mo de téléchargement à un visiteur mobile : sur une connexion cellulaire moyenne, l’attente se compte en secondes, et chaque seconde d’attente fait partir une fraction des visiteurs avant même d’avoir vu votre argumentaire.
• Dans l’application elle-même, chaque visuel embarqué grossit le binaire téléchargé depuis le store. Un poids d’installation élevé se voit sur la fiche et pèse dans la décision : à bénéfice égal, une application deux fois plus lourde s’installe moins, surtout sur les appareils au stockage saturé.
• Dans vos échanges de travail, des maquettes et captures non compressées engorgent les tickets, les messageries et les documents de spécification. Ce n’est pas un problème de production, mais c’est du temps perdu chaque jour.

La bonne nouvelle : la compression est l’optimisation au meilleur rapport effort sur résultat de tout le projet. Aucun code à modifier, aucune décision d’architecture, quelques minutes de traitement, et des gains qui se mesurent immédiatement dans le tableau de résultats. Pour situer l’enjeu budgétaire global d’un projet, le guide des prix d’une application mobile détaille ce que coûtent les vraies optimisations de performance : celle-ci est de loin la moins chère.

WebP, JPEG ou PNG : quel format pour quel visuel

Chaque format d’image fait un pari différent, et la plupart des fichiers trop lourds sont simplement des fichiers rangés dans le mauvais format. Le tableau résume les forces de chacun :

La règle pratique qui en découle : WebP pour tout ce qui s’affiche sur le web, où tous les navigateurs actuels le lisent ; JPEG pour ce qui doit passer par une console de publication ou circuler vers des destinataires dont vous ignorez l’équipement ; PNG uniquement quand la netteté absolue ou la transparence sont non négociables, comme pour une icône. Pour ce dernier cas, le générateur d’icônes d’application produit directement toutes les tailles exigées par iOS et Android à partir de votre fichier maître.

Un piège classique mérite d’être nommé : la capture d’écran d’interface enregistrée en PNG. C’est le bon format à la prise de vue, car le texte y reste net. Mais si cette capture part ensuite sur une page web telle quelle, elle pèse cinq à dix fois son poids utile. Convertie en WebP à qualité 85, elle garde un texte lisible pour une fraction du poids.

Ce que fait vraiment la compression avec perte

Le curseur « Qualité » ne retire pas des pixels au hasard. La compression avec perte exploite les limites de la perception humaine : l’œil distingue finement les variations de luminosité, beaucoup moins les variations de teinte, et très mal les détails d’une zone chargée. L’encodeur simplifie donc en priorité ce que vous ne regardez pas.

Concrètement, trois choses se produisent au moment où vous cliquez sur « Compresser les images » :

1. L’image est décodée puis redessinée par le moteur graphique du navigateur, à la largeur maximale choisie si l’original la dépasse. Réduire les dimensions est l’opération la plus rentable qui soit : diviser la largeur et la hauteur par deux divise le nombre de pixels par quatre, avant même toute compression.
2. Le réencodage supprime les métadonnées. Un fichier issu d’un téléphone transporte des données EXIF : modèle d’appareil, date, réglages, parfois coordonnées GPS de la prise de vue. Le passage par le canvas du navigateur les élimine : le fichier de sortie ne contient que l’image. C’est un gain de poids marginal, mais un gain de confidentialité réel avant toute publication.
3. L’encodeur applique le niveau de qualité choisi. À 80, les simplifications restent en dessous du seuil de perception dans la grande majorité des cas : c’est le préréglage de l’outil. En dessous de 60 apparaissent les artefacts caractéristiques, blocs dans les dégradés et halos autour des contours nets. Au-dessus de 90, le poids grimpe très vite pour un gain visuel que plus personne ne distingue.

D’où une méthode simple : gardez 80 par défaut, montez à 85 ou 90 uniquement pour les images où du texte fin doit rester impeccable, et réservez les valeurs basses aux images d’arrière-plan qui seront recouvertes d’autres éléments.

Les règles des stores pour vos visuels

Si vos images sont destinées aux fiches App Store ou Google Play, la compression doit respecter les contraintes officielles des consoles de publication. Les voici, telles que les plateformes les documentent :

Deux conséquences pratiques. D’abord, le WebP ne sert à rien pour les fiches : les deux consoles attendent du PNG ou du JPEG, choisissez donc « JPEG » comme format de sortie pour ces fichiers précis. Ensuite, la limite de 8 Mo de Google Play se franchit plus vite qu’on ne croit avec des captures 3840 pixels issues d’un outil de design : un passage en qualité 85 les ramène très en dessous du seuil sans dégradation visible. Pour composer des captures aux dimensions exactes avec cadre de téléphone, accroche et fond, l’encadreur de captures d’écran complète naturellement ce compresseur.

Les erreurs qui ruinent une compression

Les mauvais résultats viennent rarement de l’outil, presque toujours du fichier d’entrée ou du réglage inadapté. Les cas qui reviennent sans cesse :

• Recompresser un JPEG déjà très compressé. Chaque passage avec perte ajoute sa couche de dégradation aux artefacts existants. Si le fichier source est déjà léger et montre des blocs visibles, le gain sera faible et le résultat pire. Repartez du fichier original le plus propre disponible, idéalement l’export direct de votre outil de design ou du simulateur.
• Partir d’une image agrandie. Agrandir une petite image n’invente aucun détail : cela produit du flou, que la compression transforme ensuite en bouillie. L’outil ne propose volontairement aucun agrandissement, et la règle vaut en amont : ne travaillez jamais au-dessus de la définition de la prise de vue d’origine.
• Écraser une capture pleine de texte en qualité basse. Le texte fin est le pire cas de la compression avec perte : les contours des lettres bavent dès que la qualité descend. Pour une capture d’interface, restez entre 85 et 90, ou conservez le PNG si l’image est destinée à un document de référence.
• Convertir en JPEG une image qui a besoin de sa transparence. Le JPEG ignore la transparence : les zones transparentes sont aplaties sur un fond blanc au moment de la conversion. Si le visuel doit se poser sur un fond coloré, gardez le WebP, qui la conserve intégralement.
• Appliquer le même réglage à tout un dossier hétérogène. Une photo d’ambiance, une capture d’interface et un logo n’appellent pas la même qualité. L’outil traite le lot avec un réglage commun : faites plutôt deux ou trois passes, une par famille d’images, chacune avec son réglage.
• Oublier de vérifier le sens du gain. Sur une image déjà optimale, la conversion peut produire un fichier plus lourd que l’original, et le tableau l’affiche alors sans détour. Un gain négatif est une information, pas un dysfonctionnement : conservez l’original et passez au fichier suivant.

Dernier conseil de méthode : compressez en fin de chaîne, une seule fois. Travaillez vos retouches et recadrages sur les fichiers sources sans perte, et n’appliquez la compression qu’au moment de produire les fichiers de publication. Vous pouvez d’ailleurs juger le résultat en situation : l’aperçu de fiche App Store permet de voir vos captures compressées dans un gabarit d’iPhone avant soumission.

Questions fréquentes

Mes images sont-elles envoyées sur un serveur ?

Non. La lecture, le redimensionnement, la compression et la création du ZIP sont exécutés par votre navigateur, sur votre machine ; aucune requête ne transporte vos fichiers, et fermer l’onglet efface tout, ce qui rend l’outil utilisable même sur des visuels confidentiels.

Pourquoi le gain varie-t-il autant d’une image à l’autre ?

Parce que le gain dépend du contenu et du format d’origine : un PNG photographique fondra de 80 à 95 %, un JPEG déjà optimisé ne perdra presque rien, et une image réduite par la largeur maximale cumule la baisse de définition et la compression, d’où des écarts parfaitement normaux dans le tableau.

Quelle qualité choisir pour des captures destinées aux stores ?

Entre 85 et 90 en JPEG : les captures d’interface contiennent du texte fin qui se dégrade en dessous, et ces valeurs suffisent largement à passer sous les 8 Mo par capture exigés par Google Play, tout en restant impeccables à l’œil sur la fiche.

Le WebP est-il accepté par l’App Store et Google Play ?

Pas pour les visuels de fiche : les deux consoles de publication attendent du PNG ou du JPEG. Le WebP reste en revanche un excellent choix pour votre site web, vos pages d’atterrissage et les images embarquées dans une application Android, qui le lit nativement.

La compression modifie-t-elle mes fichiers originaux ?

Jamais : l’outil produit de nouveaux fichiers que vous téléchargez ligne par ligne ou en ZIP, et vos originaux restent intacts sur votre disque, ce qui vous permet de refaire une passe avec d’autres réglages à tout moment.

Puis-je compresser une image déjà en WebP ?

Oui, l’outil l’accepte en entrée comme le PNG et le JPEG ; le gain sera simplement plus modeste si le fichier était déjà bien encodé, et le tableau vous montrera immédiatement si l’opération vaut la peine d’être conservée.

Que devient la transparence de mes PNG ?

En sortie WebP, elle est conservée à l’identique ; en sortie JPEG, format qui ne connaît pas la transparence, les zones transparentes sont aplaties sur un fond blanc, ce qu’il faut anticiper si le visuel doit se superposer à un fond coloré.

Pourquoi limiter la largeur à 1280, 1600 ou 2048 pixels ?

Parce que très peu d’usages web affichent une image au-delà de 2048 pixels de large : ces trois paliers couvrent les écrans haute densité courants, et réduire les dimensions avant compression divise le poids bien plus efficacement que n’importe quel réglage de qualité.