Il y a six mois, j’ai rouvert un vieux projet e-commerce dont la charte graphique reposait intégralement sur Adobe CS2. Le designer utilisait encore Photoshop CS2 pour les visuels produits, Illustrator CS2 pour les icônes, et InDesign CS2 pour les fiches PDF. Résultat : des JPEG gonflés de métadonnées EXIF héritées de l’appareil, des SVG contenant des balises private Adobe, et des PDF de 4 Mo qui plombaient le LCP de la page de support. La migration vers des équivalents open source n’a pas été un caprice de puriste : c’était le seul moyen de reprendre le contrôle sur chaque octet servi et de faire enfin baisser le poids des pages sans sacrifier la qualité visuelle.
Photoshop CS2 alourdit vos JPEG : la preuve par les métadonnées
La première chose que j’ai inspectée, c’est l’export standard du designer. Chaque image produit sortait de Photoshop CS2 avec une case « Enregistrer pour le Web » cochée, mais le résultat contenait encore un profil ICC complet, des métadonnées EXIF, et parfois des commentaires XML. Photoshop CS2 ajoute par défaut un tag Adobe_CM et des boutons de calques fantômes qu’un navigateur ne lit jamais. Pour un JPEG de 45 Ko affiché en bannière sur une fiche produit, ces données superflues représentaient entre 6 et 9 Ko. Sur une galerie de dix visuels, l’équivalent d’une ressource complète était gaspillé.
Un premier passage sur tous les assets avec un outil de purge des métadonnées a suffi pour regagner 18 % de poids total, sans altérer un seul pixel. Mais le vrai gain n’est venu qu’en remplaçant le flux de travail. Ouvrir Photoshop CS2 pour chaque retouche et devoir penser à décocher les bonnes options à l’export n’était pas fiable. La solution durable, c’était de changer d’outil.
GIMP 3 : l’export pour le web n’est pas une option secondaire
J’ai installé GIMP 3 sur la machine du designer, en gardant l’interface aussi proche que possible de ses habitudes. Le dialogue d’export web natif de GIMP est plus sobre que celui de Photoshop CS2 : il expose directement une option de stripping des métadonnées, le choix du sous-échantillonnage de la chroma, et la possibilité de sauvegarder en WebP ou en AVIF dès le premier enregistrement. Pas de plugin payant, pas de « Export As… » en version bridée.
On a repris un lot de 200 images produits. Avec GIMP, le designer a pu créer des profils d’export : un pour les miniatures (WebP, qualité 75, sans métadonnées), un pour les fonds de bannière (AVIF, effort 4). La taille cumulée de ce lot est passée de 8,7 Mo à 5,1 Mo. Le gain s’est répercuté directement sur le LCP des pages catalogue, comme on le verra plus loin.
Pour ceux qui viennent d’Adobe, GIMP demande une semaine d’adaptation. Mais une fois que le pipeline est configuré, il n’y a plus de retour en arrière. On a même couplé GIMP à un script Bash qui vérifie le poids de chaque image avant commit. Si un JPEG dépasse 60 Ko, le commit est rejeté.
💡 Conseil : Dans les préférences de GIMP, décochez « Enregistrer les aperçus d’images » et « Enregistrer les informations EXIF » par défaut. Vous n’aurez plus à y penser à chaque export.
Inkscape et l’optimisation SVG : ce qui échappe à Illustrator CS2
Le deuxième gros chantier concernait les icônes et les illustrations vectorielles. Le designer utilisait Illustrator CS2 et enregistrait tout en SVG 1.0, avec un viewBox souvent absent et des attributs sodipodi ou inkscape qui polluaient le code. Pourtant, seule une partie des assets était ouverte dans Inkscape : le designer faisait un export depuis Illustrator CS2, mais le fichier contenait un markup hérité d’un import précédent. Chaque icône pesait 2 à 3 Ko de trop.
Avec Inkscape, on a repris tous les SVG à zéro. La fonction « Nettoyer le document » retire automatiquement les namespaces inutilisés, les définitions vides et les styles en double. Ensuite, on a activé l’optimiseur SVGO directement depuis l’interface, en configurant une suppression des commentaires et des attributs d’éditeur. Le résultat est un fichier minimal, sans rien qui alourdisse le DOM.
Pour un set de 40 icônes, la masse est passée de 98 Ko à 31 Ko. Dans une application React qui charge ces icônes en inline, ce sont 67 Ko de bundle JavaScript évité. Comme notre state management reposait déjà sur une approche légère avec Zustand, rajouter un rendu conditionnel pour les icônes a été naturel, mais une gestion trop fine du state peut devenir un anti-pattern si on n’y prend pas garde. On a documenté ce risque sur le site en parlant de state management React et Zustand.
Au passage, Inkscape exporte nativement en SVG optimisé pour le web, sans les balises xmp qu’Illustrator CS2 insérait qu’on le veuille ou non.
Scribus pour des PDF légers, sans sacrifier le print
Le site proposait une douzaine de fiches techniques téléchargeables en PDF. Elles étaient composées sous InDesign CS2, exportées avec le préréglage « Presse ». Le moindre PDF pesait entre 3 et 5 Mo. Pour un mobile sur un réseau lent, le clic sur un lien de téléchargement déclenchait un véritable calvaire. On a testé la même composition dans Scribus, l’équivalent libre de la PAO, en gardant les polices exactes et les images en résolution print.
Scribus offre un export PDF avec un paramétrage fin de la compression des images. On a calé les JPEG internes en qualité haute mais sans suréchantillonnage, on a intégré les polices sous forme de sous-ensembles plutôt que de fichiers complets. Les PDF sont passés sous la barre des 800 Ko, sans baisse visible de la qualité en impression. Le score CLS des pages concernées a cessé de fluctuer, car le navigateur n’avait plus besoin de réserver une zone en attente d’un document lourd à charger.
Automatiser les exports avec un script Python et Git
Faire confiance aux bonnes pratiques manuelles, ce n’est pas suffisant. Sur un projet où trois personnes peuvent toucher les visuels, l’erreur revient vite. J’ai écrit un petit script Python qui, à chaque build, parcourt le répertoire assets/images et vérifie :
- Qu’aucun fichier ne dépasse un seuil de poids défini par type (JPEG < 70 Ko, PNG < 50 Ko, SVG < 10 Ko).
- Que tous les fichiers sont bien enregistrés avec une extension correspondant à leur format réel (un
image.jpgqui est en réalité un PNG redirigé, c’est arrivé). - Qu’aucun SVG ne contient d’attributs non désirés.
Le script est déclenché dans le pipeline CI. Si un contrôle échoue, le build casse avant la mise en production. Pour pondre ce script rapidement sans passer deux heures sur la syntaxe pillow, j’ai utilisé un assistant IA dans l’éditeur. À ce moment-là, je testais justement plusieurs IDE pour du pair programming, ce qui m’a donné l’occasion de comparer finement Claude Code et Cursor. Le premier m’a fourni un squelette fonctionnel plus propre, mais le second offrait un meilleur auto-complètement pour le traitement par lot.
Ce que la migration a changé sur les Core Web Vitals
Avant la migration, le LCP de la page catalogue plafonnait autour de 2,9 secondes sur mobile, en 4G lente. Le plus gros élément était systématiquement l’image de bannière produit, exportée depuis Photoshop CS2. Après le basculement complet vers GIMP et l’adoption du WebP avec les profils standardisés, le LCP est descendu à 1,7 seconde en moyenne sur les mêmes segments de test. Ce n’est pas juste un résultat de la compression : c’est aussi la suppression des profils ICC qui évite au navigateur des conversions chromatiques coûteuses au décodage.
Le nitro-serve n’a pas bougé, mais le time-to-first-byte du cache navigateur s’est amélioré, car les ressources transférées étaient mécaniquement plus petites. Comme on l’avait écrit dans le dossier sur les Core Web Vitals en contexte e-commerce, le poids de l’image critique est un levier direct sur le LCP, bien plus que le lazy-loading quand celui-ci est déjà actif.
La migration vers des équivalents open source n’est pas un simple exercice de substitution. Elle force à réinterroger chaque réglage d’export, chaque pipelining d’image, chaque option laissée par défaut depuis quinze ans. Adobe CS2 n’est plus maintenu, et ses remplaçants libres vous donnent aujourd’hui des armes que Photoshop CS2 ne pouvait tout simplement pas offrir sans bidouille. Le gain en performance est mesurable, reproductible, et il survit aux changements de version.
Questions fréquentes
Faut-il désinstaller Adobe complètement pour ces gains ? Non. Beaucoup d’équipes conservent Illustrator ou InDesign pour des besoins print très spécifiques tout en basculant la production web sur Inkscape et GIMP. L’important, c’est de séparer les pipelines. Ne laissez pas le fichier natif CS2 devenir votre export web final, quelle que soit la suite que vous gardez par ailleurs.
Quid des plugins Photoshop qui n’ont pas d’équivalent sur GIMP ? C’est le nerf de la guerre. Certains filtres ou scripts d’automatisation n’existent qu’en version Photoshop. Dans ce cas, on peut conserver un poste avec l’outil propriétaire uniquement pour cette étape, puis exporter l’image brute et la finaliser dans GIMP pour le web. L’objectif n’est pas la pureté idéologique, c’est la maîtrise du poids final.
