Optimiseur SVG — vecteurs plus petits et plus rapides

Que fait précisément cet outil ?

Vous déposez un fichier SVG (ou un dossier en mode bulk), l’outil l’envoie à travers un optimiseur SVG spécialisé et vous montre le résultat : un code source plus petit, un aperçu de rendu contre l’original et l’économie d’octets. L’optimisation tourne dans le navigateur via un moteur d’optimisation pure JavaScript — pas de téléversement, pas de compte, pas de tracking. Sortie : un fichier optimisé ou une archive ZIP en mode bulk. L’utilisation est volontairement épurée : quatre presets, un mode « Personnalisé » pour les pros et deux commutateurs de sortie (Format lisible, Passes multiples).

L’économie varie dramatiquement selon le type d’authoring. Un chemin écrit à la main avec coordonnées à trois décimales sans fioriture rétrécit de 5–15 %. Un logo exporté depuis un programme vectoriel avec espaces de noms d’éditeur, commentaires, métadonnées et précision huit décimales descend routinement de 60–80 %. Un workflow qui envoie un SVG à travers un outil d’enregistrement d’écran et un éditeur peut produire des fichiers qui sont à 90 % du lest — nous avons vu des icônes de 200 Ko rétrécir à 25 Ko sans qu’un seul pixel ne change au rendu.

Pourquoi optimiser des SVG en 2026 ?

Trois raisons qui s’additionnent. Premièrement performance du First Paint : chaque kilo-octet de SVG inline retarde votre rendu hero. Les sites modernes inlineront 8–20 icônes dans leur navigation ; économiser 3 Ko par icône allège la payload du chemin critique de 60 Ko. Deuxièmement ratio gzip : les optimiseurs trient les attributs par ordre alphabétique (sortAttrs), ce qui améliore la fenêtre du compresseur — le SVG optimisé n’est pas seulement plus petit en brut, il se compresse aussi mieux. Troisièmement intégration build-pipeline : les SVG passés par cet outil ne traînent plus le ballast d’éditeur, si bien que les outils en aval (constructeurs de fonts d’icônes, générateurs de sprites, loaders de framework) reçoivent une entrée plus propre.

Il y a aussi un aspect confidentialité qui surprend beaucoup. Les exports d’outils de design intègrent souvent des métadonnées utilisateur dans le SVG : le nom de l’auteur, le chemin du fichier sur le disque local, le timestamp de travail de l’éditeur, parfois même des images de référence non utilisées comme data-URI. Retirer commentaires et métadonnées signifie que cette information ne voyage plus avec votre asset.

Comment se distinguent les quatre presets ?

Web est le défaut et le plus agressif — ce dont la plupart ont besoin pour icônes et illustrations dans le navigateur. Il retire commentaires, métadonnées, <title>, <desc>, espaces de noms d’éditeur, DOCTYPE et le prologue XML. Il raccourcit les IDs, arrondit les valeurs numériques à trois décimales (à taille d’icône le plus souvent invisible), raccourcit les couleurs (#ffffff → #fff, rgb(255,0,0) → red), convertit les formes en chemins si cela économise des octets, fusionne les chemins et fait s’effondrer les transformations et groupes redondants. La viewBox n’est pas retirée ; le dimensionnement intrinsèque est trop souvent important. Réduction attendue : 40–80 % sur exports typiques.

Figma-Safe garde les IDs inchangés. Les outils de design vectoriels référencent les formes via IDs quand vous configurez des variantes de symboles ou des overrides de composants ; si les IDs sont renommés dans un SVG réimporté, le câblage des variantes casse. En plus, <title> et <desc> (accessibilité) restent, et la fusion de chemins est sautée. Réduction attendue : 30–60 %.

Editor-Safe est le preset aller-retour pour les SVG que vous voulez continuer à éditer dans un programme vectoriel. Il préserve commentaires, espaces de noms d’éditeur, IDs, titres, descriptions, marqueurs de calques — tout ce dont un éditeur a besoin pour restaurer son état de travail. Seules les minifications les plus sûres tournent. Réduction attendue : 5–20 %.

Personnalisé vous laisse cocher exactement les optimisations à exécuter. La liste est une grille à deux colonnes avec étiquettes descriptives. L’état de départ correspond au preset Web ; vous pouvez désélectionner des entrées et exécuter aussi souvent que vous voulez. Vous avez besoin de ce mode quand une régression est apparue : désélectionner l’optimisation qui a cassé l’icône et recalculer.

À quoi sert la comparaison avant/après ?

La régression visuelle est le mode d’erreur que l’optimisation agressive cache le mieux. Un chemin qui semblait bon à 24 px commence à osciller à 96 px parce que l’arrondi à trois décimales a déplacé un point de contrôle de l’ancrage. Un dégradé qui référençait un stop manquant est rendu en couleur unie après suppression des <defs> inutilisés. Aucun de ces problèmes ne détruit le SVG ; tous trois changent comment il se présente.

L’aperçu rend les deux versions dans une sandbox isolée. Vous voyez l’original à gauche, l’optimisé à droite, tous deux mis à l’échelle dans la même boîte. Si l’optimisé a l’air différent, le correctif est généralement : choisir un preset plus conservateur, augmenter la précision float en mode « Personnalisé » ou désactiver l’optimisation spécifique qui a causé la différence.

Comment fonctionne le mode bulk ?

Déposer ou sélectionner plusieurs fichiers SVG simultanément. L’outil lit chacun en mémoire, applique le preset actif à chacun et vous montre une liste par fichier avec delta de taille. Un récapitulatif batch au-dessus de la liste montre les octets totaux économisés, la réduction pondérée en pourcentage et le temps d’optimisation total. Vous téléchargez tous les fichiers optimisés en une archive ZIP.

Le mode bulk est la bonne voie quand vous avez hérité d’une bibliothèque d’icônes ou que vous voulez intégrer proprement un dossier d’illustrations dans votre build. Le preset Web sur une bibliothèque de 200 icônes économise typiquement 60–80 % des octets totaux — c’est une amélioration Lighthouse sensible pour toute page qui les délivre inline.

Que voit-on dans l’onglet réseau pendant que l’outil optimise ?

Ouvrir DevTools, onglet réseau, déposer un SVG de 1 Mo et observer. Vous voyez zéro requête sortante pour l’optimisation elle-même. L’optimiseur est chargé dynamiquement une fois après le premier idle de la page et caché par le navigateur ; tous les autres fichiers utilisent le module chargé en mémoire. Pas de ping analytics, pas d’endpoint de logging et pas d’API Background-Sync ou Reporting que certains outils utilisent pour siphonner des données silencieusement.

Ce n’est pas une promesse marketing mais une propriété vérifiable de la construction de page. L’optimiseur est un module JavaScript qui tourne dans votre onglet ; les sources SVG sont lues avec l’API FileReader du navigateur ; les sorties sont construites en mémoire et accrochées à des Blob URLs que le navigateur garde localement jusqu’à fermeture de l’onglet.

Quand cet outil n’est-il pas le bon choix ?

Quelques cas où vous devriez prendre un autre outil. Rasterisation SVG-vers-PNG : cet outil optimise SVG-en-SVG, il ne rend pas en PNG. Simplification de chemin (Ramer-Douglas-Peucker) : cet outil resserre les coordonnées de chemin mais ne change pas la topologie. Vectorisation bitmap-vers-SVG : c’est un problème complètement différent. Édition interactive qualité éditeur : c’est un optimiseur one-shot, pas un canvas de travail. Conversion WebP/AVIF : utilisez notre convertisseur de formats d’image pour les formats raster.

Ce dans quoi cet outil est vraiment bon : envoyer des icônes SVG propres, petites, prévisibles dans votre build de production, sans perdre en fidélité, sans téléverser quoi que ce soit et sans devoir apprendre un CLI.

Comment l’optimisation SVG s’inscrit-elle dans une pipeline de build ?

Trois points d’intégration habituels. Au moment de l’authoring (cet outil ou le CLI équivalent sur un dossier) : vous optimisez les SVG avant qu’ils ne soient versionnés. Au moment du build (CLI dans package.json postinstall ou script de build) : vous conservez le code source verbeux pour la convivialité d’éditeur et ne strippez qu’au passage en production. Au moment de la requête (middleware serveur qui optimise à la volée) : rare, le plus souvent surdimensionné.

Cet outil correspond exactement au premier point d’intégration : une exécution manuelle occasionnelle qui produit du SVG production-ready. La sortie que vous copiez ou téléchargez est la même séquence d’octets qu’une optimisation CLI produirait avec la même sélection de plugins.

Que mesure exactement le pourcentage de réduction ?

Le pourcentage au-dessus de la sortie correspond à (octets_original − octets_optimisé) / octets_original, calculé sur la longueur en octets encodée UTF-8. C’est la taille de fichier que vous écririez sur disque ou livreriez à un navigateur. Pour les SVG inline en HTML, c’est aussi exactement l’économie d’octets sur le téléchargement du document — chaque octet économisé ici est un octet de moins que le navigateur doit parser avant de rendre votre icône.

Deux choses que le pourcentage ne capture pas. Premièrement améliorations de ratio gzip : par le tri alphabétique des attributs et la normalisation du whitespace, le SVG optimisé se compresse souvent mieux que le delta brut ne le suggère. Empiriquement cela ajoute 10–20 % supplémentaires une fois que gzip s’applique. Deuxièmement économie de temps de parsing : un SVG plus petit avec chemins fusionnés est plus rapide à parser et dessiner pour le rendu SVG du navigateur.

Où trouver le standard et plus de contexte ?

• Spécification W3C SVG — le standard auquel l’optimiseur se conforme.
• Tutoriel MDN SVG — comment les SVG rendent dans le navigateur et quels attributs les navigateurs respectent.
• Wikipédia : Scalable Vector Graphics — contexte historique et aperçu du format.

Optimiser un SVG, voir le compteur d’octets descendre, livrer un bundle plus petit. Pas de téléversement, pas de compte, pas de tracking — vérifiable dans l’onglet réseau des DevTools de votre navigateur.