Convertir ICO en WebP

WebP est supporté par tous les navigateurs modernes, encode à 82 par défaut comme JPEG, AVIF et JXL, et supporte un canal alpha. Pour une icône qui doit être servie à des visiteurs, c’est la cible qui combine la meilleure compression, le support le plus large, et la préservation de la transparence. Notre pipeline produit un WebP lossless ou lossy selon la nature de la source, et la sortie est directement utilisable comme asset d’une page web.

Pour un ICO source de 256 × 256, le WebP à 82 pèse 4-8 Ko, contre 15-25 pour le PNG encapsulé et 200-260 pour le TIFF. Le ratio est moins favorable pour les icônes très simples, où la compression a peu de prise. Pour les icônes 32 × 32, le WebP peut être légèrement plus gros que le PNG à cause du surcoût du conteneur. Pour les icônes 64 et plus, WebP gagne systématiquement.

Un fichier .ico contient plusieurs tailles d’une seule image, le plus souvent 16, 32 et 48 pixels, parfois 64 ou 128, parfois 256 pour les icônes Mac modernes. Notre encodeur lit l’ICO, choisit la plus grande taille, décode le bitmap, et le ré-encode en WebP. Le fichier produit n’est pas multi-tailles, et il n’embarque pas la table de tailles.

Pour la majorité des icônes système, cette taille lue est 32 pixels. Le WebP produit est donc un fichier minuscule, souvent 1-2 Ko, et le gain sur le PNG encapsulé est marginal. La conversion a du sens seulement si l’ICO source est lui-même déjà une grande image, ou si le WebP est destiné à être redimensionné côté client via `<picture>` ou `srcset`.

WebP supporte un canal alpha, et notre encodeur le porte. Une icône avec ses coins arrondis et son ombre portée arrive donc en WebP avec sa transparence, posée sur rien, prête à être intégrée dans une interface qui sait la rendre. C’est la sortie correcte quand vous voulez un asset web moderne d’une icône qui a été pensée pour être détourée.

La nuance, c’est que le PNG encapsulé dans l’ICO est lui-même lossless, et WebP est ici en mode lossy à 82. La compression WebP à 82 sur un PNG lossless produit un fichier plus petit, et la décompression redonne les mêmes pixels au sens perceptuel, mais pas au sens binaire. Pour un asset graphique final destiné au web, c’est sans importance. Pour un asset qui doit subir un round-trip sans dérive, restez en PNG.

Le contrôle de qualité est partagé par les quatre codecs modernes qui l’acceptent, et notre valeur par défaut est 82. Sur une icône, 82 est très conservateur : à cette qualité, un WebP 256 × 256 tient en 4-8 Ko, et la différence avec 95 est invisible sur un visuel qui n’a pas de dégradé. Baisser à 60 économise quelques kilo-octets et commence à baver les contours des petits éléments.

Pour un favicon, 82 est surdimensionné. Pour un logo d’application 256 ou 512, 82 est dans la bonne fourchette. Pour un visuel avec beaucoup de dégradés fins, monter à 90 est utile. La valeur est partagée par les quatre codecs, et c’est une décision explicite dans le code source : les contrôles de qualité sont fixés une fois plutôt que par format, pour que la même commande produise un résultat comparable.

Notre pipeline WebP encode en lossy à la qualité demandée, et c’est explicite dans la liste des formats qui n’utilisent pas le mode lossless du codec, alors que le format le définit. Pour un ICO, c’est presque toujours le bon choix : une icône a des contours francs, peu de dégradés, et le lossless n’apporte rien de visible. Le fichier lossy est plus petit pour une qualité perçue identique.

Pour les rares cas où l’icône a des aplats critiques qui ne doivent pas bouger, le PNG reste la cible. Pour les cas ordinaires, WebP lossy à 82 est l’équilibre. Si l’icône est un logo d’entreprise qui doit rester identique au pixel près sur tous les appareils, la chaîne en aval doit imposer le PNG, pas WebP. Le navigateur ne sait pas faire la différence entre les deux pour une icône, et c’est l’auteur du site qui fixe la cible.

L’ICO encapsule un PNG, qui peut porter EXIF, XMP, ICC. Notre pipeline décode en pixels, ré-encode en WebP, et tout ce qui n’est pas pixel disparaît. Aucun tag d’auteur, de date, de logiciel source ne traverse. Le WebP produit est un fichier propre, sans aucune métadonnée technique, ce qui est en général ce que l’on veut pour un asset web.

WebP peut porter EXIF et XMP, mais notre encodeur ne les écrit pas, parce que le pipeline raster n’accepte que `ImageData` et `{ quality }` comme paramètres. C’est cohérent avec les autres cibles raster, et c’est ce qui fait que le fichier produit est léger et propre. Pour un asset qui doit porter un copyright, c’est le mauvais pipeline.

WebP supporte l’animation, et un ICO peut embarquer une animation (la convention est rare, et c’est plutôt un .cur qui le fait). Notre pipeline lit l’ICO comme une image fixe, prend la première taille, et la passe au codec. Si l’ICO source avait plusieurs frames, seule la première arrive en sortie, et le WebP est un fichier image simple, pas une animation.

Pour les rares cas où l’ICO source est animé, le bon pipeline est un outil spécialisé qui sait lire l’animation. Notre convertisseur ne le fait pas, et la page affiche le résultat comme si l’ICO était une image fixe, ce qui est le cas pour 99,9 % des fichiers .ico en circulation. Si votre ICO bouge, vous le savez probablement déjà.

L’ICO source n’est pas uploadé, le WebP produit n’est jamais transmis. La conversion se fait dans l’onglet, en mémoire, par les encodeurs chargés à la demande. C’est important pour les icônes d’application qui peuvent indiquer une suite logicielle interne, un set d’icônes client, un sigle propriétaire. Aucun fichier ne quitte l’appareil, et l’onglet réseau reste vide pendant la conversion.

Les fichiers jusqu’à 100 Mo sont pris en charge, ce qui est très large pour ce format, et l’ensemble du calcul est client pour cette paire. C’est la seule forme sous laquelle la phrase « privé » signifie quelque chose : aucune requête vers l’extérieur pendant que la conversion tourne, et l’assertion se vérifie dans l’onglet réseau des outils de développement.