Aller au contenu principal
Bethemesh
GuideFormats

SVG : comprendre le format vectoriel

Découvrez comment un fichier SVG décrit des formes, utilise viewBox et s’intègre dans une page Web, avec les bonnes pratiques de responsive, d’accessibilité et de sécurité.

Publié le 31 août 2026Lecture : 33 minPar Équipe Bethemesh
Débutant
Illustration d’un cercle vectoriel et de son code SVG fondé sur des coordonnées
Afficher le sommaire
  1. SVG en une phrase
  2. Raster et vectoriel : deux manières de représenter une image
  3. Pourquoi un SVG reste-t-il net lorsqu’on l’agrandit ?
  4. Quand utiliser SVG ?
  5. Logos
  6. Icônes
  7. Illustrations géométriques
  8. Schémas et diagrammes
  9. Graphiques de données
  10. Motifs et décorations
  11. Quand ne pas utiliser SVG ?
  12. SVG est-il un format d’image ou du code ?
  13. À quoi ressemble un SVG minimal ?
  14. <svg>
  15. xmlns
  16. viewBox
  17. <title>
  18. <rect>
  19. <circle>
  20. XML : quelles conséquences pratiques ?
  21. Comprendre viewBox
  22. Unités SVG et pixels CSS
  23. Pourquoi mon SVG est-il coupé ?
  24. width, height et viewBox : quelle différence ?
  25. viewBox
  26. width
  27. height
  28. Faut-il supprimer width et height ?
  29. preserveAspectRatio
  30. Les formes de base
  31. Rectangle
  32. Cercle
  33. Ellipse
  34. Ligne
  35. Polyline
  36. Polygone
  37. Chemin
  38. Pourquoi <path> est-il partout ?
  39. Coordonnées absolues et relatives
  40. Courbes de Bézier
  41. Trop de points : pourquoi est-ce un problème ?
  42. fill et stroke
  43. fill
  44. stroke
  45. HEX, RGB, HSL et SVG
  46. currentColor : une propriété très pratique
  47. Dégradés
  48. <defs> : la bibliothèque interne du SVG
  49. <use> et réutilisation
  50. Groupes avec <g>
  51. Transformations
  52. Translation
  53. Rotation
  54. Mise à l’échelle
  55. Inclinaison
  56. Clipping et masques
  57. clipPath
  58. mask
  59. Filtres SVG
  60. Le texte dans SVG
  61. Convertir le texte en tracés : bonne idée ?
  62. Quatre grandes manières d’intégrer SVG
  63. SVG avec <img>
  64. SVG en arrière-plan CSS
  65. SVG inline
  66. <object> et <iframe>
  67. <img> ou inline : comment décider ?
  68. Non
  69. Oui
  70. SVG et cache
  71. SVG et responsive
  72. SVG et images responsives
  73. SVG et écrans Retina
  74. SVG et performances
  75. Un SVG est-il toujours plus léger qu’un PNG ?
  76. Un SVG peut-il contenir une image JPEG ou PNG ?
  77. Base64 dans un SVG
  78. SVG et compression réseau
  79. SVGZ : faut-il l’utiliser ?
  80. Accessibilité : le format ne décide pas de l’alternative
  81. SVG chargé avec <img>
  82. SVG inline informatif
  83. Graphiques complexes
  84. SVG décoratif inline
  85. Icône seule dans un bouton
  86. Contraste et SVG
  87. Pourquoi la couleur seule peut poser problème ?
  88. Sécurité : pourquoi SVG mérite-t-il une attention particulière ?
  89. <img> isole-t-il davantage le SVG ?
  90. Pourquoi supprimer seulement <script> ne suffit pas ?
  91. Optimisation et sécurité : deux objectifs différents
  92. MIME type
  93. SVG et Content Security Policy
  94. Métadonnées dans SVG
  95. SVG et confidentialité
  96. Pourquoi les logiciels graphiques produisent-ils des SVG volumineux ?
  97. Pourquoi conserver le SVG original ?
  98. Que peut supprimer un optimiseur SVG ?
  99. Précision décimale
  100. Optimiser les couleurs
  101. SVG et animations
  102. Animation d’un tracé
  103. SVG et interaction
  104. SVG et SEO
  105. SVG et Core Web Vitals
  106. Faut-il utiliser un sprite SVG ?
  107. SVG ou icon font ?
  108. SVG ou Canvas ?
  109. SVG et impression
  110. Workflow recommandé pour un SVG
  111. 1. Conserver la source
  112. 2. Vérifier que SVG est approprié
  113. 3. Inspecter le viewBox
  114. 4. Choisir le mode d’intégration
  115. 5. Traiter l’accessibilité
  116. 6. Vérifier la sécurité
  117. 7. Optimiser
  118. 8. Tester
  119. Workflow avec les outils Bethemesh
  120. Les erreurs les plus fréquentes
  121. « SVG est toujours plus léger »
  122. « SVG est toujours responsive »
  123. « Un SVG n’a jamais de pixels »
  124. « Je supprime toujours width et height »
  125. « Inline est toujours mieux »
  126. « <img> empêche d’utiliser SVG correctement »
  127. « Un SVG optimisé est sécurisé »
  128. « Supprimer <script> suffit »
  129. « Je peux convertir toutes mes photos en SVG »
  130. « Je peux convertir tout le texte en paths »
  131. « Une icône SVG est automatiquement accessible »
  132. Checklist avant de publier un SVG
  133. Ce qu’il faut retenir
  134. Questions fréquentes
  135. Qu’est-ce qu’un SVG ?
  136. Pourquoi SVG reste-t-il net lorsqu’on l’agrandit ?
  137. SVG est-il meilleur que PNG ?
  138. SVG est-il meilleur que WebP ?
  139. Peut-on mettre une photo dans un SVG ?
  140. À quoi sert viewBox ?
  141. Quelle différence entre viewBox, width et height ?
  142. Faut-il supprimer width et height d’un SVG ?
  143. Pourquoi mon SVG est-il coupé ?
  144. Peut-on changer la couleur d’un SVG en CSS ?
  145. Vaut-il mieux utiliser <img> ou un SVG inline ?
  146. Un SVG est-il automatiquement responsive ?
  147. Un SVG a-t-il besoin d’une version Retina ?
  148. SVG est-il toujours plus léger ?
  149. Comment réduire le poids d’un SVG ?
  150. Un SVG peut-il contenir du JavaScript ?
  151. Un SVG chargé avec <img> est-il plus sûr ?
  152. Un optimiseur SVG sécurise-t-il un fichier ?
  153. Comment rendre un SVG accessible ?
  154. Peut-on utiliser currentColor avec SVG ?
  155. SVG ou icon font ?
  156. SVG ou Canvas ?
  157. Quelles métadonnées un SVG peut-il contenir ?
  158. Quelle est l’étape suivante ?

Un logo PNG peut sembler parfaitement net à sa taille d’origine puis révéler ses pixels lorsqu’on l’agrandit fortement. Le même logo en SVG peut rester net sur une petite icône, un écran Retina ou une affiche, parce qu’il ne mémorise pas une grille fixe de pixels : il décrit les formes à dessiner.

SVG signifie Scalable Vector Graphics, ou graphique vectoriel adaptable. Sur le Web, sa particularité est importante : SVG est à la fois un format d’image vectorielle et un langage de balisage fondé sur XML.

Cette double nature explique presque tout :

  • pourquoi un SVG peut être redimensionné sans pixellisation de ses formes ;
  • pourquoi ses couleurs peuvent parfois être pilotées en CSS ;
  • pourquoi il peut contenir du texte, des liens, des dégradés, des masques ou des animations ;
  • pourquoi un fichier SVG peut être inspecté et modifié dans un éditeur de texte ;
  • pourquoi il faut également réfléchir à son accessibilité et à sa sécurité.

SVG n’est pourtant pas « meilleur » que PNG, JPEG, WebP ou AVIF. Il répond à un autre type de problème.

Pour une photographie, un format raster moderne reste généralement beaucoup plus pertinent. Pour un logo, une icône, un schéma, un graphique ou une illustration géométrique, SVG peut au contraire être le choix naturel.

SVG en une phrase

Une image raster dit essentiellement :

« voici la couleur de chacun de mes pixels ».

Un SVG dit plutôt :

« dessine un cercle ici, une courbe là, remplis cette forme avec cette couleur et applique cette transformation ».

Cette différence de représentation explique pourquoi le vectoriel peut être redessiné à différentes tailles.

Si vous souhaitez revenir à la structure d’une image raster — pixels, canaux RGB et alpha — commencez par Comment une image numérique est-elle construite ?.

Pour comparer les familles de formats, consultez également PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Raster et vectoriel : deux manières de représenter une image

Une image raster est constituée d’une grille.

Une photographie de :

1200 × 800 px

contient :

960 000 pixels

Chaque pixel stocke des informations de couleur et éventuellement de transparence.

Si l’on agrandit fortement cette image, le navigateur doit interpoler des pixels supplémentaires. Il ne découvre pas de nouveaux détails : il estime comment remplir l’espace.

Un dessin vectoriel fonctionne différemment.

Un cercle peut être décrit par :

<circle cx="50" cy="50" r="40" />

Le navigateur connaît :

  • le centre ;
  • le rayon ;
  • les propriétés graphiques.

Il peut donc recalculer la forme à la taille nécessaire.

Ce n’est pas une image « infiniment détaillée ». C’est une description géométrique qui peut être rasterisée à la résolution d’affichage.

Pourquoi un SVG reste-t-il net lorsqu’on l’agrandit ?

Parce que les formes vectorielles ne dépendent pas d’une grille de pixels source fixe.

Lorsque le navigateur doit afficher un cercle SVG plus grand, il ne grossit pas une petite matrice existante. Il redessine le cercle dans la grille de pixels de l’écran.

Cela fonctionne particulièrement bien pour :

  • lignes ;
  • courbes ;
  • contours ;
  • formes géométriques ;
  • typographies converties ou conservées sous forme appropriée ;
  • logos ;
  • pictogrammes.

Mais attention : un SVG peut contenir une image raster intégrée.

Dans ce cas, les éléments vectoriels restent redimensionnables, mais la photographie intégrée conserve ses propres limites de résolution.

L’extension .svg ne garantit donc pas que tout le contenu du fichier soit réellement vectoriel.

Quand utiliser SVG ?

SVG est particulièrement adapté aux contenus dont la structure peut être décrite avec relativement peu de formes.

Logos

Un logo géométrique doit souvent exister dans de nombreuses tailles.

SVG évite de maintenir une multitude de PNG uniquement pour conserver la netteté.

Icônes

Les pictogrammes sont souvent constitués de quelques tracés.

Ils peuvent également utiliser currentColor lorsqu’ils sont intégrés directement au HTML.

Illustrations géométriques

Formes, aplats, dégradés et courbes peuvent être très efficaces en SVG.

Schémas et diagrammes

Le vectoriel est naturellement adapté aux lignes, flèches, blocs et libellés.

Graphiques de données

Axes, courbes, points et zones peuvent être décrits sous forme d’éléments vectoriels et éventuellement rendus interactifs.

Motifs et décorations

Des formes répétitives peuvent être définies et réutilisées.

Quand ne pas utiliser SVG ?

Une photographie classique est rarement un bon candidat.

Imaginez essayer de décrire chaque détail d’un paysage avec :

  • chemins ;
  • formes ;
  • dégradés ;
  • masques.

Le document deviendrait extrêmement complexe.

Pour les photographies, JPEG, WebP ou AVIF sont généralement plus appropriés.

Le guide PNG, JPEG, WebP ou AVIF : quel format choisir ? détaille cette décision.

SVG peut également être un mauvais choix lorsqu’une illustration vectorielle est tellement complexe qu’elle contient des dizaines ou centaines de milliers de points. Un raster correctement dimensionné peut alors être plus léger et moins coûteux à rendre.

SVG est-il un format d’image ou du code ?

Les deux descriptions sont utiles.

Un fichier SVG autonome est une image que l’on peut charger ainsi :

<img src="/images/logo.svg" alt="Bethemesh">

Mais son contenu ressemble à ceci :

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 80">
  <rect width="120" height="80" fill="#E8F0FF" />
  <circle cx="60" cy="40" r="24" fill="#2457D6" />
</svg>

Il s’agit d’un document XML utilisant le vocabulaire SVG.

On peut donc :

  • l’ouvrir comme une image ;
  • lire son balisage ;
  • le modifier ;
  • le générer par programme ;
  • l’insérer directement dans du HTML.

Cette nature documentaire rend SVG extrêmement puissant, mais explique aussi pourquoi il doit être traité avec davantage de précautions qu’un simple tableau de pixels.

À quoi ressemble un SVG minimal ?

Voici un exemple autonome :

<svg
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 120 80"
  role="img"
  aria-labelledby="logo-title"
>
  <title id="logo-title">Disque bleu dans un cadre arrondi</title>
  <rect width="120" height="80" rx="12" fill="#E8F0FF" />
  <circle cx="60" cy="40" r="24" fill="#2457D6" />
</svg>

Décomposons-le.

<svg>

C’est l’élément racine.

Il délimite le document ou le fragment SVG.

xmlns

Dans un fichier SVG autonome, l’espace de noms :

http://www.w3.org/2000/svg

identifie le vocabulaire SVG.

viewBox

Il définit le système de coordonnées et le cadrage.

<title>

Il peut participer à l’alternative accessible selon le mode d’intégration.

<rect>

Il dessine un rectangle.

<circle>

Il dessine un cercle.

On comprend déjà pourquoi SVG est intéressant : le dessin reste relativement lisible même sans logiciel graphique.

XML : quelles conséquences pratiques ?

SVG utilise une syntaxe XML.

Cela implique notamment une structure correctement imbriquée.

Par exemple :

<g>
  <circle cx="20" cy="20" r="10" />
</g>

Les éléments doivent être fermés correctement.

Les attributs utilisent une syntaxe structurée :

fill="#2457D6"

Un export de logiciel graphique peut ajouter :

  • namespaces supplémentaires ;
  • métadonnées ;
  • identifiants ;
  • groupes ;
  • styles ;
  • informations propres à l’éditeur.

Une partie de ces données peut être inutile pour la diffusion Web.

C’est précisément le sujet de Comment optimiser un fichier SVG sans altérer son rendu ?.

Comprendre viewBox

viewBox est probablement l’attribut le plus important à comprendre pour utiliser SVG correctement.

Sa forme est :

viewBox="min-x min-y largeur hauteur"

Exemple :

viewBox="0 0 120 80"

Cela signifie :

  • origine horizontale : 0 ;
  • origine verticale : 0 ;
  • largeur du repère : 120 ;
  • hauteur du repère : 80.

Le dessin existe dans ce repère interne.

Ces nombres ne signifient pas nécessairement « 120 × 80 pixels physiques ».

Ils définissent un espace de coordonnées que le navigateur mettra ensuite en correspondance avec la taille d’affichage.

Unités SVG et pixels CSS

Supposons :

viewBox="0 0 120 80"

et un affichage CSS de :

600 × 400 px

Le rapport est identique :

120 / 80 = 1,5
600 / 400 = 1,5

Chaque unité du repère correspond alors, dans cette situation simplifiée, à cinq pixels CSS.

Si le SVG est ensuite affiché à :

300 × 200 px

le même dessin est recalculé.

Les coordonnées internes n’ont pas changé.

C’est cette séparation entre repère interne et taille externe qui rend SVG si flexible.

Pourquoi mon SVG est-il coupé ?

Un viewBox incorrect est une cause fréquente.

Imaginez un cercle :

<circle cx="100" cy="50" r="30" />

Sa partie droite atteint :

130

Si le viewBox s’arrête à :

120

une partie peut être hors du cadrage.

Les contours compliquent encore la situation : un stroke possède une épaisseur qui s’étend autour du tracé.

Filtres, ombres et effets peuvent également dépasser les limites géométriques évidentes.

Lorsqu’un SVG est coupé, vérifiez :

  • les coordonnées ;
  • le viewBox ;
  • l’épaisseur des contours ;
  • les filtres ;
  • les transformations.

width, height et viewBox : quelle différence ?

Ces trois notions sont souvent confondues.

viewBox

Définit le repère interne et le cadrage.

width

Indique une largeur d’affichage ou intrinsèque selon le contexte.

height

Même rôle pour la hauteur.

Un fichier peut contenir :

<svg
  width="240"
  height="160"
  viewBox="0 0 120 80"
>

Le repère reste 120 × 80, mais la taille proposée est 240 × 160.

Le navigateur effectue la correspondance entre les deux.

Faut-il supprimer width et height ?

Pas systématiquement.

On lit parfois :

« Pour rendre un SVG responsive, supprimez toujours width et height. »

C’est trop simpliste.

Ces dimensions peuvent fournir des informations utiles sur la taille intrinsèque et contribuer à un comportement prévisible.

Le point essentiel est surtout de disposer d’un viewBox cohérent et d’utiliser CSS lorsque l’on souhaite adapter la taille.

Par exemple :

.logo {
  width: 10rem;
  height: auto;
}

Le fichier peut conserver son viewBox et être redimensionné correctement.

L’optimiseur SVG peut proposer de retirer certaines dimensions lorsqu’un viewBox existe, mais cette transformation doit correspondre à votre contexte d’intégration.

preserveAspectRatio

Que se passe-t-il si le rapport du viewBox et celui de la zone d’affichage diffèrent ?

SVG utilise preserveAspectRatio pour déterminer comment adapter le dessin.

Dans le comportement courant, les proportions sont conservées.

Cela peut produire des espaces libres si le cadre externe n’a pas le même ratio.

Une valeur comme :

preserveAspectRatio="none"

autorise l’étirement indépendant des deux axes.

Un cercle peut alors devenir une ellipse.

Ce comportement est parfois souhaité pour certains effets, mais rarement pour un logo.

Les formes de base

SVG possède plusieurs primitives graphiques.

Rectangle

<rect x="10" y="10" width="80" height="40" />

Cercle

<circle cx="50" cy="50" r="30" />

Ellipse

<ellipse cx="60" cy="40" rx="50" ry="25" />

Ligne

<line x1="10" y1="10" x2="90" y2="90" />

Polyline

<polyline points="10,80 40,20 70,80" />

Polygone

<polygon points="10,80 40,20 70,80" />

Chemin

<path d="M 10 60 L 40 20 L 70 60 Z" />

Ces primitives peuvent être combinées, groupées et transformées.

Pourquoi <path> est-il partout ?

<path> peut décrire des formes extrêmement variées.

Son attribut d contient une suite de commandes.

Exemple :

<path d="M 10 60 L 40 20 L 70 60 Z" />

On peut le lire ainsi :

  • M 10 60 : déplacer le point courant ;
  • L 40 20 : tracer une ligne ;
  • L 70 60 : tracer une autre ligne ;
  • Z : fermer la forme.

D’autres commandes permettent de dessiner :

  • courbes de Bézier ;
  • arcs ;
  • segments horizontaux ;
  • segments verticaux.

Les logiciels de création produisent énormément de chemins parce qu’ils peuvent représenter presque toutes les formes.

Coordonnées absolues et relatives

Dans les chemins, les commandes majuscules utilisent généralement des coordonnées absolues.

Par exemple :

L 80 40

signifie « aller jusqu’au point 80,40 ».

Les variantes minuscules utilisent des déplacements relatifs.

Par exemple :

l 20 10

signifie « avancer de 20 unités horizontalement et 10 verticalement depuis le point courant ».

Les coordonnées relatives peuvent parfois produire un code plus compact.

Les optimiseurs peuvent transformer certaines représentations si cela réduit le fichier sans changer le dessin.

Courbes de Bézier

Les courbes de Bézier sont essentielles dans le dessin vectoriel.

Elles permettent de créer des courbes lisses à partir de points de contrôle.

Vous n’avez pas besoin de calculer manuellement les coordonnées pour utiliser SVG : les logiciels graphiques le font.

Mais comprendre leur existence explique pourquoi une courbe peut parfois être décrite avec quelques points seulement, alors qu’une approximation composée de centaines de petits segments serait beaucoup plus lourde.

C’est également pourquoi la simplification des tracés peut réduire fortement certains SVG exportés.

Trop de points : pourquoi est-ce un problème ?

Un tracé issu d’une vectorisation automatique peut contenir des milliers de points.

Cela augmente :

  • la taille du fichier ;
  • le coût de parsing ;
  • la complexité du DOM lorsqu’il est inline ;
  • le travail de rendu ;
  • la difficulté d’édition.

Deux tracés peuvent sembler identiques à l’écran alors que l’un contient dix fois plus de coordonnées.

L’optimisation vectorielle ne consiste donc pas seulement à supprimer des espaces. Elle peut aussi chercher une représentation géométrique plus simple.

Le guide Optimiser un fichier SVG sans altérer son rendu approfondit ce sujet.

fill et stroke

Deux propriétés fondamentales contrôlent l’apparence des formes.

fill

Remplit l’intérieur.

<circle
  cx="50"
  cy="50"
  r="30"
  fill="#2457D6"
/>

stroke

Dessine le contour.

<circle
  cx="50"
  cy="50"
  r="30"
  fill="none"
  stroke="#2457D6"
  stroke-width="4"
/>

D’autres propriétés contrôlent :

  • extrémités ;
  • jointures ;
  • pointillés ;
  • opacité.

SVG partage de nombreuses notions avec CSS, ce qui facilite son intégration au design Web.

HEX, RGB, HSL et SVG

Les couleurs utilisées dans SVG peuvent employer plusieurs syntaxes du Web.

Par exemple :

fill="#2457D6"

ou selon le contexte :

fill="rgb(36 87 214)"

Ces syntaxes décrivent des couleurs, mais elles ne changent pas la nature vectorielle du dessin.

Pour comprendre leur relation, consultez RGB, HEX et HSL : comprendre les modèles de couleur du Web.

Le convertisseur de couleurs permet de passer d’une notation à une autre.

currentColor : une propriété très pratique

Une icône inline peut utiliser :

<svg viewBox="0 0 24 24" aria-hidden="true">
  <path d="..." fill="currentColor" />
</svg>

La valeur currentColor reprend la valeur CSS de color.

Vous pouvez alors écrire :

.button {
  color: rebeccapurple;
}

et l’icône suit automatiquement la couleur du composant.

Cela évite de dupliquer plusieurs fichiers uniquement pour changer une couleur.

Mais cette technique dépend du mode d’intégration.

Un SVG chargé via <img> reste isolé du DOM principal : le CSS de la page ne peut pas cibler librement ses chemins internes.

Dégradés

SVG peut définir des dégradés dans <defs>.

Exemple simplifié :

<svg viewBox="0 0 200 100">
  <defs>
    <linearGradient id="gradient" x1="0" x2="1">
      <stop offset="0%" stop-color="#2457D6" />
      <stop offset="100%" stop-color="#8B5CF6" />
    </linearGradient>
  </defs>

  <rect width="200" height="100" fill="url(#gradient)" />
</svg>

Le dégradé reçoit un identifiant, puis la forme le référence.

Cette architecture évite de répéter la définition.

Mais elle introduit aussi un sujet important lorsque plusieurs SVG inline coexistent : les identifiants doivent être gérés correctement.

<defs> : la bibliothèque interne du SVG

<defs> contient des éléments définis mais non rendus directement.

On peut y placer :

  • dégradés ;
  • filtres ;
  • masques ;
  • symboles ;
  • motifs ;
  • chemins réutilisés.

Exemple :

<defs>
  <circle id="dot" cx="0" cy="0" r="4" />
</defs>

Puis :

<use href="#dot" x="20" y="20" />
<use href="#dot" x="40" y="20" />

Cela peut réduire la duplication.

<use> et réutilisation

<use> permet de réutiliser une définition.

Cette technique est pratique pour :

  • motifs ;
  • symboles ;
  • éléments répétés ;
  • systèmes d’icônes.

Mais lorsque du SVG est intégré inline dans une grande page, les identifiants peuvent entrer en collision si plusieurs fichiers utilisent les mêmes noms génériques comme :

gradient
clip0
mask0

Un pipeline de génération doit donc éviter les collisions ou préfixer les identifiants lorsque nécessaire.

Groupes avec <g>

<g> regroupe plusieurs éléments.

<g fill="#2457D6">
  <circle cx="20" cy="20" r="10" />
  <circle cx="50" cy="20" r="10" />
</g>

Les deux cercles héritent ici du remplissage.

Les groupes servent également à appliquer une transformation commune :

<g transform="translate(20 10)">
  ...
</g>

Les logiciels graphiques utilisent abondamment les groupes.

Mais un export peut en produire beaucoup plus que nécessaire.

Transformations

SVG peut transformer les coordonnées.

Translation

translate(20 10)

déplace le contenu.

Rotation

rotate(45)

le fait tourner.

Mise à l’échelle

scale(2)

double l’échelle.

Inclinaison

Des transformations skewX et skewY existent également.

Plusieurs transformations peuvent être combinées.

Les optimiseurs peuvent parfois fusionner ou simplifier ces opérations, mais une modification incorrecte peut déplacer le dessin. Le contrôle visuel reste indispensable.

Clipping et masques

SVG peut limiter la visibilité d’un contenu.

clipPath

Découpe selon une forme.

mask

Contrôle plus finement l’opacité.

Ces mécanismes permettent des compositions complexes sans convertir l’ensemble en pixels.

Mais ils augmentent également la complexité du document.

Un logo simple exporté avec de nombreux masques et groupes mérite parfois d’être nettoyé.

Filtres SVG

SVG propose des filtres capables de créer :

  • flous ;
  • ombres ;
  • modifications de couleur ;
  • combinaisons d’images ;
  • effets plus complexes.

Ils sont puissants mais peuvent être coûteux à rendre.

Pour une petite icône répétée des centaines de fois, un filtre complexe peut être moins judicieux qu’une solution CSS ou une simplification graphique.

L’objectif n’est pas d’éviter les filtres, mais de les utiliser lorsqu’ils apportent réellement quelque chose.

Le texte dans SVG

SVG possède un élément <text>.

Cela peut être utile dans :

  • graphiques ;
  • diagrammes ;
  • annotations.

Mais le texte SVG pose plusieurs questions :

  • police disponible ;
  • dimensions ;
  • accessibilité ;
  • sélection ;
  • adaptation à de petites tailles ;
  • traduction.

Pour une interface classique, du texte HTML est souvent plus flexible.

Pour un graphique, le texte SVG peut être logique, à condition de fournir une alternative accessible lorsque le graphique transmet des informations importantes.

Convertir le texte en tracés : bonne idée ?

Les logiciels graphiques proposent souvent de convertir une typographie en chemins.

Avantage :

  • le rendu ne dépend plus de la présence de la police.

Inconvénients :

  • le texte n’est plus réellement du texte ;
  • le fichier peut devenir plus lourd ;
  • l’accessibilité se complique ;
  • la traduction devient difficile ;
  • la sélection et la recherche disparaissent.

Pour un logotype où la forme typographique fait partie du dessin, cela peut être approprié.

Pour des paragraphes ou des données, c’est généralement une mauvaise stratégie.

Quatre grandes manières d’intégrer SVG

Le mode d’intégration détermine ce que vous pouvez faire avec le fichier.

Les quatre scénarios les plus courants sont :

  1. <img> ;
  2. arrière-plan CSS ;
  3. SVG inline ;
  4. document embarqué avec <object> ou <iframe>.

Ils ne sont pas équivalents.

SVG avec <img>

Exemple :

<img
  src="/images/logo.svg"
  alt="Bethemesh"
  width="160"
  height="48"
>

C’est souvent la meilleure option pour une image statique.

Avantages :

  • syntaxe simple ;
  • cache comme une ressource image ;
  • alternative via alt ;
  • document SVG isolé ;
  • faible couplage avec le HTML.

Inconvénient principal :

  • le CSS de la page ne peut pas cibler librement les formes internes.

Pour un logo qui ne change pas de couleur dynamiquement, ce compromis est souvent excellent.

SVG en arrière-plan CSS

Exemple :

.decoration {
  background-image: url("/images/motif.svg");
}

Cette approche convient aux éléments décoratifs.

Une image de fond n’offre pas d’attribut alt.

Si le dessin transmet une information nécessaire, ne comptez pas sur le background pour la rendre accessible.

Utilisez plutôt un élément sémantique approprié.

SVG inline

Vous pouvez placer directement le balisage dans le HTML :

<button class="button">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="..." fill="currentColor" />
  </svg>
  Enregistrer
</button>

Avantages :

  • style CSS ;
  • currentColor ;
  • interactions ;
  • animations ;
  • accès aux éléments internes ;
  • contrôle fin.

Inconvénients :

  • HTML plus lourd ;
  • répétition potentielle ;
  • collisions d’identifiants ;
  • davantage de responsabilités d’accessibilité et de sécurité.

Utilisez l’inline lorsque ses capacités sont réellement nécessaires.

<object> et <iframe>

Ces éléments chargent le SVG comme un document séparé.

Ils peuvent être utiles dans des cas particuliers nécessitant un document autonome ou une interaction spécifique.

Pour une simple icône ou un logo, ils sont généralement inutilement complexes.

Ils demandent davantage d’attention sur :

  • accessibilité ;
  • politique de sécurité ;
  • échanges entre documents ;
  • chargement.

Le choix le plus simple compatible avec le besoin reste généralement préférable.

<img> ou inline : comment décider ?

Posez une question simple :

Ai-je besoin d’accéder aux éléments internes du SVG depuis la page ?

Non

Utilisez probablement <img>.

Oui

L’inline peut être pertinent.

Exemples nécessitant potentiellement l’inline :

  • icône suivant currentColor ;
  • parties interactives d’un graphique ;
  • animation de chemins ;
  • changement dynamique de propriétés internes.

Ne mettez pas tous les SVG inline uniquement parce que c’est possible.

SVG et cache

Un fichier externe :

<img src="/icons/search.svg" alt="">

peut être mis en cache indépendamment de la page.

Un SVG inline fait partie du HTML.

S’il est répété sur de nombreuses pages, le même balisage peut donc être retransmis avec chaque document, même si la compression HTTP réduit cette répétition.

Pour une icône minuscule, l’impact peut être négligeable.

Pour une illustration complexe répétée partout, un fichier externe peut être plus efficace.

Le choix doit tenir compte de l’ensemble de l’architecture.

SVG et responsive

SVG est scalable, mais cela ne signifie pas qu’un diagramme complexe devient automatiquement utilisable sur mobile.

Prenons un graphique contenant :

  • vingt libellés ;
  • une légende ;
  • plusieurs courbes ;
  • annotations.

Le réduire de 1 000 px à 280 px conserve des lignes nettes, mais les textes peuvent devenir minuscules et les zones interactives trop petites.

Le problème n’est plus la résolution. C’est la composition.

Il peut être nécessaire de :

  • simplifier ;
  • masquer certains détails ;
  • modifier la disposition ;
  • fournir une variante mobile ;
  • rendre le graphique défilable.

« Vectoriel » résout la pixellisation, pas toutes les questions de responsive design.

SVG et images responsives

Les mécanismes srcset et sizes sont surtout associés aux images raster, où plusieurs résolutions permettent d’éviter de transférer trop de pixels.

Un SVG réellement vectoriel n’a généralement pas besoin d’une version 1x, 2x et 3x uniquement pour rester net.

C’est l’un de ses avantages.

Mais un site peut toujours avoir besoin :

  • de compositions différentes ;
  • de cadrages différents ;
  • de SVG différents selon le contexte.

Le futur article Images responsives : comprendre srcset et sizes permettra de bien distinguer résolution responsive et art direction.

SVG et écrans Retina

Un logo raster de 200 × 60 px peut sembler moins net lorsqu’il est affiché sur un écran à forte densité s’il ne contient pas suffisamment de pixels.

Un SVG n’a pas besoin d’une variante @2x pour ses formes vectorielles.

Le navigateur les rasterise directement à la densité nécessaire.

C’est une raison importante pour laquelle SVG est particulièrement adapté :

  • logos ;
  • icônes ;
  • éléments graphiques d’interface.

SVG et performances

Un petit fichier SVG peut être extrêmement efficace.

Mais la taille en octets n’est qu’un aspect.

Le navigateur doit également :

  1. parser le document ;
  2. construire les structures nécessaires ;
  3. calculer les styles ;
  4. appliquer transformations et filtres ;
  5. rasteriser le résultat.

Un SVG de 20 Ko contenant des milliers d’éléments peut être plus coûteux qu’un fichier raster simple de taille comparable.

Il faut donc considérer :

  • poids réseau ;
  • complexité du document ;
  • fréquence de réutilisation ;
  • coût de rendu ;
  • animations.

Le futur guide Optimiser les images pour les performances Web replacera SVG dans cette analyse globale.

Un SVG est-il toujours plus léger qu’un PNG ?

Non.

Un logo simple :

quelques chemins + quelques couleurs

peut être extrêmement léger.

Une illustration complexe issue d’une vectorisation automatique peut être énorme.

Et un fichier SVG contenant une photographie encodée en base64 peut être plus lourd et moins pratique que le fichier raster original.

Comparez toujours :

  • le contenu réel ;
  • le poids ;
  • la complexité ;
  • l’usage.

Ne choisissez pas SVG uniquement parce qu’il est vectoriel.

Un SVG peut-il contenir une image JPEG ou PNG ?

Oui.

SVG possède notamment un élément <image> permettant d’intégrer ou de référencer une ressource raster.

Cela peut être utile pour certaines compositions mixtes.

Mais cela signifie que :

« mon fichier est SVG »

ne veut pas dire :

« tout mon contenu est vectoriel ».

Une photographie intégrée reste une photographie raster.

Si vous l’agrandissez au-delà de ses informations disponibles, elle ne gagne pas magiquement de nouveaux détails.

Base64 dans un SVG

Une image raster peut être encodée directement dans le document sous forme de données.

Cela rend le fichier autonome, mais augmente souvent la taille textuelle et empêche parfois une gestion indépendante du cache de la ressource.

Pour un gros raster, il faut donc se demander si l’intégration apporte réellement un avantage.

Un optimiseur SVG ne transformera pas automatiquement une photographie embarquée en représentation vectorielle efficace.

SVG et compression réseau

Comme SVG est du texte XML, il peut généralement bénéficier efficacement de la compression HTTP lorsqu’il est transféré.

Les répétitions de balises, attributs et nombres se compressent bien.

Cela signifie qu’une réduction de quelques octets dans le fichier source ne se traduit pas toujours par le même gain sur le réseau.

Il reste utile de nettoyer le document, notamment pour :

  • simplifier sa maintenance ;
  • réduire le parsing ;
  • supprimer des données inutiles ;
  • améliorer les performances globales.

Mais mesurez également le poids transféré dans les outils réseau.

SVGZ : faut-il l’utiliser ?

SVGZ désigne historiquement un SVG compressé avec gzip.

Dans une architecture Web moderne, le serveur ou CDN peut compresser les fichiers SVG lors du transfert sans nécessiter une extension .svgz.

Utiliser des SVG classiques correctement servis et une compression HTTP adaptée simplifie généralement le workflow.

L’important est surtout que le serveur fournisse le bon type de contenu et une stratégie de compression/cache cohérente.

Accessibilité : le format ne décide pas de l’alternative

Un SVG peut être :

  • informatif ;
  • décoratif ;
  • fonctionnel ;
  • complexe.

Son alternative accessible dépend de son rôle, pas de son extension.

Cette règle est la même que pour les autres images.

Une icône décorative n’a pas besoin d’être annoncée.

Un graphique présentant des données importantes doit transmettre ces informations autrement qu’uniquement par ses formes.

SVG chargé avec <img>

Pour un SVG utilisé comme image :

<img
  src="/images/logo.svg"
  alt="Bethemesh"
>

l’attribut alt de <img> joue le rôle principal.

Si l’image est décorative :

<img src="/images/decor.svg" alt="">

Un texte alternatif ne doit pas décrire mécaniquement chaque forme.

Il doit transmettre l’information ou la fonction utile.

SVG inline informatif

Pour un SVG inline simple, on peut utiliser un titre accessible.

Exemple :

<svg
  role="img"
  aria-labelledby="chart-title"
  viewBox="0 0 400 240"
>
  <title id="chart-title">
    Progression des inscriptions de janvier à juin
  </title>
</svg>

Les détails exacts doivent être testés avec les technologies d’assistance ciblées, car les comportements peuvent varier selon les structures et contextes.

Pour un graphique complexe, un simple titre ne suffit généralement pas.

Graphiques complexes

Supposons un graphique montrant l’évolution de trois séries sur douze mois.

Le SVG peut être visuellement très clair, mais un utilisateur ne percevant pas le graphique doit également accéder à l’information.

Selon le cas, fournissez :

  • un résumé ;
  • les tendances essentielles ;
  • les valeurs importantes ;
  • un tableau de données.

L’accessibilité ne consiste pas à « rendre le SVG lisible par un lecteur d’écran à tout prix ». Elle consiste à rendre l’information accessible.

SVG décoratif inline

Si un SVG n’apporte aucune information et accompagne simplement un libellé déjà explicite, il peut être masqué des technologies d’assistance.

Exemple :

<button>
  <svg aria-hidden="true" viewBox="0 0 24 24">
    ...
  </svg>
  Télécharger
</button>

Le bouton possède déjà son libellé.

Annoncer en plus « icône flèche vers le bas » serait généralement inutile.

Icône seule dans un bouton

Situation différente :

<button>
  <svg>...</svg>
</button>

Si aucun texte visible n’existe, le bouton doit tout de même posséder un nom accessible.

Par exemple via un libellé approprié sur le bouton.

Le SVG ne doit pas devenir le seul moyen fragile d’identifier l’action.

Contraste et SVG

Les règles de contraste ne disparaissent pas parce que le dessin est vectoriel.

Une icône fonctionnelle ou un composant graphique peut devoir respecter des exigences de contraste selon son rôle.

De même, un graphique ne devrait pas utiliser uniquement une différence rouge/vert si cela empêche certains utilisateurs de distinguer les séries.

Utilisez également :

  • motifs ;
  • formes ;
  • libellés ;
  • styles de lignes ;
  • marqueurs.

Pour approfondir, consultez Contraste WCAG : comment rendre les couleurs accessibles ?.

Pourquoi la couleur seule peut poser problème ?

Imaginez deux courbes :

  • verte = réussite ;
  • rouge = échec.

Sans légende directement identifiable, motifs ou formes distinctes, certains utilisateurs peuvent avoir du mal à les différencier.

SVG permet facilement d’ajouter :

  • pointillés ;
  • marqueurs ;
  • labels ;
  • symboles.

Profitez de cette flexibilité au lieu de compter uniquement sur la couleur.

Sécurité : pourquoi SVG mérite-t-il une attention particulière ?

Un PNG est essentiellement traité comme une image raster.

SVG est un document.

Selon le contexte, il peut contenir ou référencer :

  • liens ;
  • styles ;
  • ressources externes ;
  • animations ;
  • éléments interactifs ;
  • scripts ou mécanismes actifs dans certains contextes.

Un SVG provenant d’une source non fiable ne doit donc pas être injecté directement dans le DOM sans traitement approprié.

C’est particulièrement important pour :

  • upload utilisateur ;
  • contenu communautaire ;
  • CMS autorisant du SVG ;
  • fichiers téléchargés depuis des sources inconnues.

<img> isole-t-il davantage le SVG ?

Lorsqu’un SVG est chargé comme une image via <img>, les navigateurs appliquent des restrictions correspondant au contexte image.

Cela réduit fortement les possibilités actives par rapport à un SVG inline ou chargé comme document.

Cette isolation est l’une des raisons pour lesquelles <img> constitue un bon choix par défaut pour une image SVG statique.

Mais cela ne dispense pas d’une politique de sécurité cohérente pour les fichiers non fiables.

Pourquoi supprimer seulement <script> ne suffit pas ?

La sécurité d’un langage de document ne se résume pas à une seule balise.

Un assainissement doit considérer selon la politique retenue :

  • éléments autorisés ;
  • attributs autorisés ;
  • URL ;
  • références externes ;
  • styles ;
  • événements ;
  • namespaces ;
  • constructions potentiellement dangereuses.

Il faut donc utiliser une stratégie d’assainissement conçue pour SVG plutôt qu’une simple expression régulière supprimant :

<script>

Un optimiseur de poids n’est pas automatiquement un sanitizer.

Optimisation et sécurité : deux objectifs différents

Un optimiseur cherche à produire un document plus petit ou plus simple.

Un sanitizer cherche à supprimer ou neutraliser les constructions interdites par une politique de sécurité.

Ces objectifs peuvent se recouper sur certains éléments, mais ils ne sont pas équivalents.

Un fichier peut être :

  • très optimisé et dangereux ;
  • sûr mais non optimisé ;
  • sûr et optimisé.

L’optimiseur SVG doit donc être utilisé pour l’optimisation d’un document de confiance, pas comme garantie universelle de sécurité pour un SVG hostile.

MIME type

Un fichier SVG servi sur le Web doit utiliser un type de contenu cohérent :

image/svg+xml

Une configuration serveur incorrecte peut provoquer :

  • affichage inattendu ;
  • téléchargement au lieu du rendu ;
  • comportements de sécurité différents.

La bonne extension ne suffit pas : le serveur doit également répondre correctement.

SVG et Content Security Policy

Une Content Security Policy peut limiter certaines catégories de ressources et de comportements.

Elle constitue une couche de défense utile dans une architecture Web.

Mais elle ne remplace pas l’assainissement d’un contenu non fiable que vous injectez volontairement dans votre DOM.

La sécurité doit être pensée en profondeur :

  • validation ;
  • assainissement ;
  • contexte d’intégration ;
  • en-têtes ;
  • isolation.

Métadonnées dans SVG

Un logiciel graphique peut ajouter des informations comme :

  • nom de l’éditeur ;
  • version ;
  • données de document ;
  • commentaires ;
  • informations RDF ;
  • identifiants ;
  • noms de calques.

Certaines sont inutiles pour la diffusion.

D’autres peuvent être nécessaires à votre workflow ou à vos obligations.

Ne supprimez donc pas tout automatiquement sans comprendre le rôle de ces données.

Le futur article Métadonnées d’image : les lire, les conserver ou les supprimer replacera cette question dans un cadre plus général.

SVG et confidentialité

Un SVG exporté peut révéler des informations qui ne sont pas visibles dans le rendu :

  • noms de calques ;
  • noms internes ;
  • commentaires ;
  • données du logiciel ;
  • texte masqué ;
  • éléments invisibles ;
  • références.

Avant de publier un fichier provenant d’un document de travail sensible, inspectez sa structure.

Cette précaution est comparable à l’examen des métadonnées EXIF d’une photographie, même si les données concernées ne sont pas les mêmes.

Pourquoi les logiciels graphiques produisent-ils des SVG volumineux ?

Un outil de création cherche d’abord à préserver :

  • fidélité ;
  • éditabilité ;
  • structure interne ;
  • compatibilité avec son propre workflow.

Il ne cherche pas forcément à produire le plus petit fichier possible pour un navigateur.

Un export peut donc contenir :

  • groupes redondants ;
  • précision décimale excessive ;
  • styles répétés ;
  • métadonnées ;
  • identifiants longs ;
  • données propres à l’éditeur ;
  • formes invisibles.

C’est normal pour un fichier de travail.

Pour la diffusion, une variante optimisée peut être préférable.

Pourquoi conserver le SVG original ?

Comme pour une photographie, conservez une source maître.

L’optimisation peut :

  • fusionner des structures ;
  • réduire la précision ;
  • supprimer des métadonnées ;
  • supprimer des noms utiles ;
  • rendre l’édition future moins confortable.

Le fichier optimisé est une version de diffusion, pas nécessairement le meilleur fichier de travail.

Cette logique rejoint celle expliquée dans Comment compresser une image sans perdre en qualité ?.

Que peut supprimer un optimiseur SVG ?

Selon sa configuration, un optimiseur peut notamment :

  • retirer des commentaires ;
  • supprimer des métadonnées ;
  • enlever des informations propres à l’éditeur ;
  • réduire les espaces ;
  • raccourcir certaines valeurs ;
  • diminuer la précision décimale ;
  • simplifier des transformations ;
  • fusionner certains éléments ;
  • supprimer des attributs inutiles.

Chaque transformation doit être évaluée selon le document.

Certaines optimisations très agressives peuvent modifier le rendu ou le comportement.

Précision décimale

Un export peut contenir :

42.123456789

alors que :

42.12

produit peut-être un rendu indiscernable.

Réduire la précision sur des milliers de coordonnées peut diminuer le poids.

Mais si l’on va trop loin :

42

la forme peut changer.

Les effets sont particulièrement visibles sur :

  • petites icônes ;
  • courbes fines ;
  • alignements ;
  • géométries précises.

L’optimiseur SVG permet d’expérimenter, mais le résultat doit toujours être contrôlé.

Optimiser les couleurs

Un SVG peut contenir une couleur sous différentes syntaxes.

Selon le contexte, certaines représentations peuvent être plus compactes.

Mais l’optimisation ne doit pas modifier la couleur.

Si vous travaillez sur des palettes ou des identités visuelles, utilisez le convertisseur de couleurs pour comprendre les équivalences et RGB, HEX et HSL pour leur fonctionnement.

SVG et animations

SVG peut être animé de différentes manières selon la technique employée :

  • CSS ;
  • JavaScript ;
  • mécanismes propres à SVG.

On peut animer :

  • opacité ;
  • transformations ;
  • couleurs ;
  • tracés.

Les animations peuvent être élégantes, mais elles doivent rester utiles et respecter les préférences utilisateur, notamment la réduction des mouvements lorsque pertinente.

Une animation complexe augmente également le coût de rendu.

Animation d’un tracé

Un effet fréquent consiste à donner l’impression qu’une ligne se dessine progressivement.

Il exploite souvent :

  • stroke-dasharray ;
  • stroke-dashoffset.

L’effet peut être visuellement intéressant pour :

  • schéma ;
  • signature ;
  • illustration.

Mais ne transformez pas une information essentielle en animation difficile à percevoir ou trop lente à obtenir.

L’expérience utilisateur reste prioritaire.

SVG et interaction

Un SVG inline peut contenir des zones interactives ou réagir à des événements.

Cela peut être utile pour :

  • carte ;
  • graphique ;
  • diagramme ;
  • configurateur.

Mais dès qu’un élément devient interactif, il faut traiter les mêmes questions que pour n’importe quelle interface :

  • navigation clavier ;
  • focus ;
  • nom accessible ;
  • état ;
  • cible tactile ;
  • contraste.

Le fait qu’une zone soit dessinée avec <path> ne la dispense pas des exigences d’un contrôle interactif.

SVG et SEO

Un logo SVG n’obtient pas un avantage SEO simplement parce qu’il est vectoriel.

Les bénéfices sont indirects :

  • qualité visuelle ;
  • poids potentiellement réduit ;
  • performances ;
  • adaptation aux écrans.

Pour les images de contenu, la sémantique de l’intégration et les alternatives restent plus importantes que l’extension seule.

Ne convertissez donc pas des images en SVG dans l’espoir d’un « bonus SEO ».

SVG et Core Web Vitals

Un SVG peut contribuer à de bonnes performances s’il remplace efficacement un raster lourd.

Mais il peut également devenir coûteux s’il est :

  • énorme ;
  • complexe ;
  • animé ;
  • injecté inline en masse.

Pour le CLS, réservez correctement son espace comme pour les autres contenus.

Pour une ressource importante au chargement initial, considérez également :

  • découverte ;
  • cache ;
  • priorité ;
  • taille du HTML si inline.

Le futur article Optimiser les images pour les performances Web réunira ces arbitrages.

Faut-il utiliser un sprite SVG ?

Un sprite rassemble plusieurs symboles réutilisables.

Cela peut être efficace pour une bibliothèque d’icônes.

Mais les architectures modernes offrent plusieurs options :

  • composants inline ;
  • fichiers individuels ;
  • sprites ;
  • bibliothèques générées.

Le meilleur choix dépend :

  • du framework ;
  • du nombre d’icônes ;
  • du cache ;
  • du besoin de style ;
  • du coût de maintenance.

Évitez d’adopter un sprite uniquement parce qu’il était une pratique courante à une époque où les contraintes réseau étaient différentes.

SVG ou icon font ?

Les polices d’icônes ont été largement utilisées pour regrouper des pictogrammes.

SVG offre généralement davantage de contrôle graphique et s’intègre mieux à la sémantique moderne des composants.

Une icône SVG peut :

  • avoir plusieurs formes ;
  • utiliser des couleurs ;
  • être dimensionnée précisément ;
  • être manipulée sans dépendre d’un caractère de police.

Les icon fonts restent possibles, mais SVG est souvent plus naturel pour les interfaces modernes.

SVG ou Canvas ?

SVG et <canvas> peuvent tous deux dessiner des graphiques, mais leurs modèles diffèrent.

SVG conserve une structure d’objets dans le document.

Canvas fonctionne davantage comme une surface de dessin raster pilotée par script.

SVG est souvent pratique lorsque :

  • le nombre d’objets reste raisonnable ;
  • l’accessibilité ou l’interaction avec des éléments individuels compte ;
  • le dessin doit rester structuré.

Canvas peut devenir plus adapté pour certains rendus contenant énormément d’éléments ou nécessitant des mises à jour graphiques particulières.

Il n’existe pas de gagnant universel.

SVG et impression

La nature vectorielle de SVG peut être avantageuse pour l’impression de logos, schémas et graphiques.

Mais le résultat dépend :

  • du logiciel ;
  • du navigateur ;
  • des polices ;
  • des effets utilisés ;
  • de la chaîne d’impression.

Pour un document destiné à l’impression professionnelle, d’autres formats et workflows peuvent être nécessaires.

SVG reste avant tout ici étudié dans son contexte Web.

Workflow recommandé pour un SVG

1. Conserver la source

Gardez le fichier original ou le document de création.

2. Vérifier que SVG est approprié

Le contenu est-il réellement vectoriel ?

3. Inspecter le viewBox

Le cadrage est-il correct ?

4. Choisir le mode d’intégration

<img>, inline ou background selon le rôle.

5. Traiter l’accessibilité

Décoratif, informatif ou fonctionnel ?

6. Vérifier la sécurité

Le fichier est-il de confiance ?

7. Optimiser

Supprimez les données inutiles et réduisez la complexité raisonnablement.

8. Tester

Contrôlez :

  • rendu ;
  • tailles ;
  • mobile ;
  • zoom ;
  • thèmes ;
  • accessibilité ;
  • performances.

Ce workflow évite de réduire SVG à une simple question de poids.

Workflow avec les outils Bethemesh

Pour un SVG :

  1. ouvrez le document dans l’optimiseur SVG ;
  2. comparez le poids avant et après ;
  3. inspectez l’aperçu ;
  4. testez différents niveaux de précision si nécessaire ;
  5. conservez l’original ;
  6. si vous modifiez les couleurs, utilisez le convertisseur de couleurs ;
  7. vérifiez le contraste des éléments fonctionnels avec l’outil de contraste WCAG.

Pour une image qui devrait plutôt être raster, revenez au convertisseur d’images et au guide PNG, JPEG, WebP ou AVIF.

Les erreurs les plus fréquentes

« SVG est toujours plus léger »

Faux. Cela dépend de la complexité du dessin.

« SVG est toujours responsive »

Il reste net, mais une composition complexe peut devenir illisible sur petit écran.

« Un SVG n’a jamais de pixels »

Il peut embarquer une image raster.

« Je supprime toujours width et height »

Pas sans comprendre leur rôle.

« Inline est toujours mieux »

Il donne davantage de contrôle mais augmente le couplage, le HTML et les responsabilités.

« <img> empêche d’utiliser SVG correctement »

Au contraire, c’est souvent un excellent choix pour une image statique.

« Un SVG optimisé est sécurisé »

Optimisation et assainissement sont deux opérations différentes.

« Supprimer <script> suffit »

Une politique de sécurité doit examiner bien plus que cette seule balise.

« Je peux convertir toutes mes photos en SVG »

Le vectoriel n’est pas adapté à la représentation efficace d’une photographie classique.

« Je peux convertir tout le texte en paths »

Cela peut nuire à l’accessibilité, au poids et à la traduction.

« Une icône SVG est automatiquement accessible »

Son rôle et son intégration déterminent l’alternative nécessaire.

Checklist avant de publier un SVG

Vérifiez :

  • le contenu est réellement adapté au vectoriel ;
  • le viewBox est correct ;
  • rien n’est coupé ;
  • le fichier ne contient pas de raster inutile ;
  • la complexité des paths reste raisonnable ;
  • les identifiants ne provoquent pas de collisions ;
  • le mode d’intégration est approprié ;
  • l’alternative accessible est définie ;
  • les couleurs et contrastes sont adaptés ;
  • le fichier est de confiance ou correctement assaini ;
  • les métadonnées ont été examinées ;
  • le fichier original est conservé ;
  • l’optimisation n’a pas modifié le rendu ;
  • les petites tailles ont été testées ;
  • les animations respectent l’expérience utilisateur ;
  • le serveur utilise un type MIME approprié.

Ce qu’il faut retenir

SVG est puissant parce qu’il ne stocke pas simplement une grille de pixels. Il décrit un dessin.

Cette propriété lui apporte :

  • mise à l’échelle nette ;
  • structure ;
  • possibilités de style ;
  • réutilisation ;
  • interaction ;
  • animation.

Mais cette puissance crée également des responsabilités supplémentaires :

  • structure XML ;
  • viewBox ;
  • mode d’intégration ;
  • accessibilité ;
  • sécurité ;
  • complexité de rendu.

Pour un logo ou une icône, SVG est souvent un excellent choix.

Pour une photographie, choisissez généralement un format raster avec PNG, JPEG, WebP ou AVIF.

Pour réduire un fichier vectoriel existant, la prochaine étape logique est Comment optimiser un fichier SVG sans altérer son rendu ?.

Et dans une stratégie d’images complète, SVG doit ensuite être replacé aux côtés des images responsives, des métadonnées et de l’optimisation des images pour les performances Web.

Questions fréquentes

Qu’est-ce qu’un SVG ?

SVG est un format graphique vectoriel fondé sur XML. Il décrit des formes, tracés, textes, styles et transformations plutôt qu’une grille fixe de pixels.

Pourquoi SVG reste-t-il net lorsqu’on l’agrandit ?

Parce que ses formes vectorielles sont recalculées à la taille d’affichage au lieu d’agrandir une matrice fixe de pixels.

SVG est-il meilleur que PNG ?

Pas dans l’absolu. SVG est généralement meilleur pour les formes vectorielles comme les logos et icônes. PNG est un format raster utile notamment pour certains contenus sans perte et transparents.

SVG est-il meilleur que WebP ?

Ils répondent à des usages différents. WebP est adapté aux images raster ; SVG aux dessins vectoriels.

Peut-on mettre une photo dans un SVG ?

Oui, un SVG peut embarquer ou référencer une image raster. La photographie conserve alors ses limites de résolution et le conteneur SVG n’apporte pas automatiquement un avantage.

À quoi sert viewBox ?

Il définit le repère interne et le cadrage du dessin. Il permet ensuite de mettre ce repère en correspondance avec différentes tailles d’affichage.

Quelle différence entre viewBox, width et height ?

viewBox définit les coordonnées internes. width et height participent à la taille d’affichage ou intrinsèque selon le contexte.

Faut-il supprimer width et height d’un SVG ?

Pas systématiquement. Cela dépend de l’intégration. Conservez surtout un viewBox correct et contrôlez explicitement le comportement souhaité.

Pourquoi mon SVG est-il coupé ?

Le contenu, son contour ou ses filtres peuvent dépasser le viewBox. Vérifiez les coordonnées et le cadrage.

Peut-on changer la couleur d’un SVG en CSS ?

Oui facilement lorsqu’il est inline, notamment avec currentColor. Un SVG chargé avec <img> reste isolé et ses formes internes ne sont pas directement ciblables par le CSS de la page.

Vaut-il mieux utiliser <img> ou un SVG inline ?

Utilisez généralement <img> pour une image statique. Préférez l’inline lorsque vous avez réellement besoin de styler, animer ou manipuler les éléments internes.

Un SVG est-il automatiquement responsive ?

Il peut être redimensionné sans pixellisation, mais sa composition ne se réorganise pas automatiquement. Un graphique complexe peut rester illisible sur mobile.

Un SVG a-t-il besoin d’une version Retina ?

Les formes vectorielles n’ont généralement pas besoin de variantes @2x ou @3x. Elles sont rasterisées à la densité nécessaire.

SVG est-il toujours plus léger ?

Non. Un dessin complexe avec des milliers de points peut être plus lourd et plus coûteux qu’une image raster adaptée.

Comment réduire le poids d’un SVG ?

Supprimez les données inutiles, simplifiez la structure et ajustez prudemment la précision. Utilisez l’optimiseur SVG et consultez Comment optimiser un fichier SVG sans altérer son rendu ?.

Un SVG peut-il contenir du JavaScript ?

SVG est un format documentaire pouvant comporter du contenu actif selon son contexte. Ne faites jamais confiance à un SVG arbitraire simplement parce que son extension est .svg.

Un SVG chargé avec <img> est-il plus sûr ?

Le contexte image applique des restrictions importantes par rapport à l’injection inline. Pour un contenu statique, c’est une raison supplémentaire de privilégier <img>. Une politique de sécurité reste néanmoins nécessaire pour les contenus non fiables.

Un optimiseur SVG sécurise-t-il un fichier ?

Non. L’optimisation réduit ou simplifie le document. L’assainissement de sécurité applique une politique destinée à retirer les constructions non autorisées.

Comment rendre un SVG accessible ?

Cela dépend de son rôle. Avec <img>, utilisez un alt adapté. Pour un SVG inline, gérez son nom et son rôle. Un graphique complexe doit également fournir l’information sous une forme accessible.

Peut-on utiliser currentColor avec SVG ?

Oui. C’est particulièrement pratique pour les icônes inline qui doivent suivre la couleur CSS du composant.

SVG ou icon font ?

SVG offre généralement davantage de contrôle graphique et s’intègre bien aux composants modernes. Les icon fonts restent possibles mais ne sont plus l’unique solution pour des bibliothèques d’icônes.

SVG ou Canvas ?

SVG conserve une structure d’objets manipulables. Canvas est une surface de dessin. Le meilleur choix dépend du nombre d’éléments, des interactions et des performances recherchées.

Quelles métadonnées un SVG peut-il contenir ?

Selon son origine : informations d’éditeur, commentaires, noms de calques, RDF, identifiants et autres données de document. Le guide Métadonnées d’image : les lire, les conserver ou les supprimer approfondira cette question.

Quelle est l’étape suivante ?

Après avoir compris la structure du format, passez à Comment optimiser un fichier SVG sans altérer son rendu ? pour apprendre à réduire un SVG tout en contrôlant son apparence.

Outils associés

Images & graphisme

Optimiseur SVG

Réduisez le balisage SVG localement tout en conservant un fichier modifiable.

100 % local
Utiliser l’outil
Images & graphisme

Convertisseur de couleurs

Convertissez une couleur entre HEX, RGB et HSL avec ses valeurs équivalentes.

100 % local
Utiliser l’outil

Sources et références

  1. 1.W3C — Scalable Vector Graphics (SVG) 2
  2. 2.W3C — SVG 2, Coordinate Systems, Transformations and Units
  3. 3.MDN Web Docs — Introduction à SVG
  4. 4.MDN Web Docs — SVG as an image
  5. 5.W3C Web Accessibility Initiative — Images Tips and Tricks

Collection

Images pour le Web

  1. 01Comment une image numérique est-elle construite ?
  2. 02Quelle résolution choisir pour une image ?
  3. 03RGB, HEX ou HSL : quelle notation choisir ?
  4. 04Comment créer une palette de couleurs à partir d’une image ?
  5. 05Contraste WCAG : comment rendre les couleurs accessibles ?
  6. 06PNG, JPEG, WebP ou AVIF : quel format choisir ?
  7. 07Comment compresser une image sans perdre en qualité ?
  8. 08SVG : comprendre le format vectoriel
  9. 09Optimiser un fichier SVG sans altérer son rendu
  10. 10Images responsives : comprendre srcset et sizes
  11. 11Optimiser ses images pour le Web sans perdre en qualité
  12. 12WebP, AVIF, JPEG XL : quels formats d’image choisir en 2026 ?
  13. 13Métadonnées d’image : les lire, les conserver ou les supprimer
  14. 14Optimiser les images pour les performances Web
GuideFormatsDébutant

PNG, JPEG, WebP ou AVIF : quel format choisir ?

Choisissez le bon format d’image pour une photo, une capture, un visuel transparent ou une interface, sans sacrifier inutilement la qualité ni les performances.

31 août 202627 minLire
GuideBonnes pratiquesIntermédiaire

Optimiser un fichier SVG sans altérer son rendu

Apprenez à alléger un SVG en supprimant les données inutiles, en réduisant la précision avec prudence et en vérifiant que le rendu, l’accessibilité et les licences restent intacts.

31 août 202630 minLire
RéférenceConcepts et technologiesDébutant

RGB, HEX ou HSL : quelle notation choisir ?

Comprenez comment RGB, HEX et HSL décrivent les couleurs sRGB afin de choisir une notation CSS lisible et de convertir les valeurs sans confusion.

31 août 202623 minLire

Cet article vous a-t-il été utile ?