Ton SVG ne s'affiche pas dans le navigateur ? Causes courantes
Pourquoi ton SVG affiche une icône d'image cassée (ou rien du tout)
Les fichiers SVG sont censés être simples. En tant qu'alternative infiniment scalable aux formats raster, ils sont généralement fiables. Mais quand un SVG refuse de s'afficher, l'échec est souvent silencieux et déroutant. Tu te retrouves avec une icône d'image cassée, un rectangle blanc vide, ou juste un espace vide là où ton graphique devrait être. Un JPEG corrompu a au moins l'air clairement cassé ; un mauvais SVG peut sembler parfait dans un éditeur de texte et ne rien afficher du tout dans Chrome, Firefox ou Safari. Les problèmes se résument généralement à quelques points distincts : un type MIME incorrect de la part du serveur web, un XML mal formé à l'intérieur du fichier, des politiques de sécurité bloquant le code en ligne, ou des problèmes de dimensionnement qui affichent le SVG à une taille visible nulle. Chacun a une solution différente, et les mélanger te fera perdre des heures. Ce guide passe en revue chaque cause avec les paramètres et attributs spécifiques que tu dois vérifier, et pas seulement des conseils vagues pour 'valider ton fichier'. Une distinction importante avant de commencer : certains problèmes SVG commencent dans l'outil de conception (Illustrator, Figma) lors de l'exportation, tandis que d'autres surviennent lors de la conversion du fichier. Si tu as utilisé un outil en ligne pour convertir un fichier en SVG et qu'il a planté, c'est un problème d'une catégorie différente d'un SVG parfait que ton serveur configure mal. Nous veillerons à faire la distinction entre les deux.
Mauvais type MIME : Le problème côté serveur que la plupart des développeurs oublient
Lorsque tu utilises une balise `<img>` ou `background-image` en CSS pour afficher un SVG, le navigateur inspecte l'en-tête Content-Type envoyé par le serveur. Si cet en-tête indique `text/plain` ou `application/octet-stream` au lieu du correct `image/svg+xml`, la plupart des navigateurs refuseront simplement d'afficher l'image. Le fichier lui-même pourrait être irréprochable. C'est l'une des causes les plus courantes de SVG cassés en production, et c'est un fantôme en développement local. Pourquoi ? Parce que localement, tu ouvres probablement juste le fichier depuis ton disque, sans le servir. Le problème ne se manifeste qu'après le déploiement. Pour diagnostiquer cela, ouvre les Outils de développement de ton navigateur (F12), passe à l'onglet Réseau et recharge la page. Trouve ton SVG dans la liste des requêtes, clique dessus et regarde les en-têtes de réponse (Response Headers). La ligne `Content-Type` doit indiquer `image/svg+xml`. Si elle indique autre chose, tu as trouvé ton problème. La correction est sur le serveur, pas dans le fichier. Sur Apache, tu peux corriger cela en ajoutant `AddType image/svg+xml .svg .svgz` à ton fichier `.htaccess`. Pour les utilisateurs de Nginx, ajoute `image/svg+xml svg svgz;` à l'intérieur du bloc `types` de ton `nginx.conf`. Si tu utilises IIS, tu devras utiliser le Gestionnaire des services Internet (Internet Information Services Manager) pour ajouter une correspondance de type MIME pour l'extension `.svg` à `image/svg+xml`. Si tu utilises une plateforme gérée comme Netlify ou Vercel, cela est géré dans un fichier de configuration (`netlify.toml` ou `vercel.json`). La syntaxe de Netlify, par exemple, utilise un bloc `[[headers]]` pour définir le `Content-Type` pour un chemin donné. C'est une correction de cinq minutes qui peut te faire gagner des heures de frustration, mais seulement si tu sais où chercher dans le panneau réseau.
XML mal formé : Quand le fichier SVG lui-même est le problème
Un SVG est un document XML, ce qui signifie qu'il suit des règles d'analyse strictes. Une balise de fermeture manquante, une esperluette non échappée, ou un `id` en double peut faire échouer silencieusement le fichier entier dans certains navigateurs. Voici une astuce : si ton SVG s'affiche dans Chrome mais pas dans Firefox, le XML mal formé est le principal suspect. Firefox est beaucoup plus explicite concernant les erreurs XML. Pour t'en assurer, glisse et dépose le fichier SVG directement dans une fenêtre Firefox. Si le XML est corrompu, Firefox t'affichera un message d'erreur clair, avec le numéro de ligne et de colonne : 'Erreur d'analyse XML : mal formé à la ligne 47, colonne 12.' C'est ta carte au trésor. Ouvre le fichier dans un éditeur de texte comme VS Code et va à cet endroit précis. Que cherches-tu ? Souvent, c'est une esperluette (`&`) dans un lien qui aurait dû être écrite `&`. Ou tu pourrais trouver un élément `<path>` ou `<g>` non fermé. Les problèmes d'encodage sont un autre classique, où un outil de conception exporte des caractères en dehors de la plage ASCII standard sans déclarer l'UTF-8. Ton fichier SVG devrait toujours commencer par `<?xml version="1.0" encoding="UTF-8"?>` s'il contient des caractères non-ASCII. Les anciennes versions d'Adobe Illustrator adoraient exporter des fichiers avec des espaces de noms XML propriétaires. Bien que ce ne soit pas techniquement invalide, cela ajoute un poids inutile et peut parfois perturber les analyseurs. Le passage de ces fichiers à travers un optimiseur comme SVGO supprime généralement ces espaces de noms, ce qui est une bonne chose. Le danger est que si l'apparence du graphique dépendait d'une manière ou d'une autre de ces attributs propriétaires, le nettoyage du fichier pourrait le casser de manière inattendue. Si tu as converti un fichier en SVG avec CocoConvert et que le résultat présente des erreurs XML, merci de nous le faire savoir via le bouton de feedback sur la page de résultats. Nous recherchons et corrigeons activement ce type d'artefacts de conversion.
SVG en ligne et conflits de politique de sécurité du contenu (CSP)
Coller le balisage SVG directement dans ton HTML est une technique puissante, mais elle comporte un piège majeur : le SVG devient une partie du DOM. Cela signifie qu'il est désormais soumis à la politique de sécurité du contenu (CSP) de ta page. Une CSP stricte peut désactiver silencieusement des parties de ton SVG, entraînant de la confusion. C'est particulièrement vrai pour les SVG contenant des éléments `<script>`, des blocs `<style>` pour les animations, ou des éléments `<use>` qui référencent des définitions de symboles externes. Une directive CSP courante comme `script-src 'self'` bloquera l'exécution de tout script en ligne à l'intérieur de ton SVG. Une directive comme `img-src 'self'` pourrait empêcher le SVG de charger une image externe référencée via `<image href="https://external-domain.com/...">`. La bonne nouvelle ? Le navigateur te dira exactement ce qui ne va pas. Ouvre la console de développement du navigateur (l'onglet Console, pas Réseau) et cherche les messages d'erreur rouges. Les violations de CSP sont très explicites, indiquant quelle ressource a été bloquée et quelle directive de politique en était responsable, par exemple : 'Refus de charger le script car il viole la directive de politique de sécurité du contenu suivante : script-src self.' La façon de corriger cela dépend des besoins de ton SVG. Tu pourrais ajouter `'unsafe-inline'` à ta directive `style-src`, mais cela affaiblit ta politique de sécurité, donc je te le déconseille fortement. Une bien meilleure solution pour les SVG animés est de déplacer le CSS dans une feuille de style externe et de le lier avec `<?xml-stylesheet type="text/css" href="styles.css"?>`. Pour les éléments `<use>` pointant vers des fichiers externes, tu devras soit intégrer les symboles, soit ajuster ta politique `img-src` pour autoriser l'origine. Les SVG générés par CocoConvert ou des outils similaires n'auront pas de scripts, tu ne verras donc pas de conflits `script-src` avec eux. Cependant, des conflits `style-src` sont toujours possibles si le SVG converti utilise du CSS en ligne pour les couleurs ou les polices.
Mauvaises configurations Viewport et ViewBox qui rendent le SVG invisible
C'est le type de problème SVG le plus exaspérant. Le navigateur affiche parfaitement le SVG, mais il le fait à une taille nulle ou quelque part hors écran. Tu ne vois pas d'icône d'image cassée ; tu ne vois rien. Quiconque a fixé un espace vide dans les DevTools, voyant l'élément `<svg>` juste là mais rien à l'écran, connaît cette douleur particulière. La clé est la relation entre l'attribut `viewBox`, qui définit le système de coordonnées interne du graphique, et les attributs `width` et `height`, qui définissent l'espace que le SVG occupe sur la page. Quand ils sont manquants ou mal assortis, le chaos s'ensuit. Tu verras souvent cela avec les exportations Figma : un SVG reçoit `width="100%"` et `height="100%"` mais n'a pas de `viewBox`. Si tu places ce SVG dans un conteneur qui n'a pas de hauteur explicite, le SVG se réduit à une hauteur nulle. La solution consiste à ajouter un `viewBox` qui correspond aux dimensions originales de la zone de travail (par exemple, `viewBox="0 0 800 600"`) ou à donner une hauteur à l'élément conteneur dans ton CSS. Un autre classique est un SVG où les données de chemin sont dessinées à des coordonnées bien en dehors du `viewBox`. Si ton `viewBox` est `"0 0 100 100"` mais que tes données de chemin commencent à `M 500 500`, le graphique est dessiné à 400 unités hors écran. Cela se produit lorsque tu déplaces des formes dans un outil de conception sans réinitialiser l'origine de la zone de travail. Pour corriger cela, retourne à ton outil de conception, sélectionne tous les objets et utilise une commande 'Réinitialiser la boîte englobante' ou son équivalent, puis réexporte. Pour diagnostiquer cela, inspecte le SVG dans les DevTools. Si sa largeur ou sa hauteur calculée est de 0, le dimensionnement est le coupable. Tu peux aussi forcer le problème en ajoutant temporairement `style="border: 1px solid red; width: 200px; height: 200px;"` directement à la balise `<svg>`. Cela créera une boîte visible et révélera si une partie de ton graphique apparaît.
Échecs de chargement des polices et des ressources externes à l'intérieur du SVG
Un SVG n'est pas toujours autonome. Il peut référencer des ressources externes comme des polices, des images, des dégradés et des filtres. Lorsque ces appels externes échouent, le SVG peut s'afficher partiellement ou avoir l'air complètement faux, selon l'importance de la pièce manquante. Les échecs de police sont un casse-tête fréquent. Un SVG qui spécifie une police personnalisée dans un élément `<text>` reviendra à une police système par défaut si cette police n'est pas disponible. Cela ne rompt généralement pas complètement l'affichage, mais cela peut faire déborder le texte de son conteneur et perturber toute la mise en page. Mon conseil : convertis toujours le texte en contours (chemins) avant d'exporter un SVG pour une utilisation web. Dans Illustrator, c'est Texte > Créer des contours ; dans Inkscape, c'est Chemin > Objet en chemin. Cela élimine complètement la dépendance aux polices et toute une catégorie de problèmes. Les images externes à l'intérieur d'un SVG sont encore plus délicates. Une balise `<image>` pointant vers une URL peut échouer parce que l'URL est hors service, parce que le serveur d'images manque d'en-têtes CORS appropriés, ou parce qu'une CSP bloque l'origine. Le navigateur n'affichera pas d'icône d'erreur ; il affichera simplement un espace vide là où l'image devrait être. Vérifie ton onglet Réseau pour les requêtes avec un statut 404 ou un statut de 0, ce qui indique souvent un blocage CORS ou CSP. Si tu convertis un fichier PDF ou AI qui contient des images raster, CocoConvert intégrera ces images directement dans le SVG sous forme d'URI de données base64. Cela résout le problème des références externes mais peut rendre le fichier SVG énorme. Un PDF avec quelques photos peut facilement devenir un SVG de plus de 5 Mo. Dans ces cas-là, nous le disons clairement : la conversion en PNG ou WebP est le choix le plus pratique. Nous n'allons pas faire semblant que le SVG est toujours la bonne réponse.
Quand la conversion est la source du problème (et que faire)
Parfois, le problème ne vient pas de ton navigateur ou de ton serveur. Le fichier SVG lui-même était cassé dès le départ, victime d'un mauvais processus de conversion. Il est important de reconnaître cette possibilité, car cela signifie que tu devrais arrêter de déboguer ton environnement et commencer à examiner le fichier. Les artefacts de conversion courants incluent des données de chemin avec une précision absurdement élevée (plus de 15 décimales), ce qui gonfle les fichiers et peut provoquer des dépassements de délai pour les analyseurs ; des conversions d'espace colorimétrique incorrectes du CMJN vers des valeurs RGB non prises en charge ; et un encodage de texte cassé si un fichier source utilisait des scripts non latins. Tu pourrais également voir des déclarations d'espaces de noms manquantes lors de la conversion à partir de formats qui reposent sur du XML propriétaire. Si tu soupçonnes une mauvaise conversion, le moyen le plus rapide de vérifier est d'ouvrir le SVG dans Inkscape. C'est gratuit, multiplateforme et dispose d'un analyseur SVG très tolérant. Si le fichier semble correct dans Inkscape mais est cassé dans Chrome, le problème est probablement spécifique au navigateur. S'il est également cassé dans Inkscape, alors le processus de conversion lui-même a échoué et le résultat est corrompu. CocoConvert utilise des bibliothèques de conversion robustes, mais aucun outil automatisé n'est parfait. Un fichier AI très complexe avec des centaines de calques, ou un PDF qui repose fortement sur des effets de transparence, peut produire un résultat SVG imparfait. Dans ces situations, la voie la plus fiable est souvent d'ouvrir le fichier source dans son application d'origine, d'exporter directement en SVG, et d'utiliser CocoConvert pour les paires de formats où nous excellons, comme la conversion de PNG simples en SVG ou de SVG en PDF pour l'impression. Si tu obtiens un SVG cassé suite à une conversion, merci de le signaler en utilisant le formulaire de feedback sur la page des résultats, et d'inclure le fichier original si tu le peux. Les exemples spécifiques sont la façon dont nous améliorons le pipeline de conversion pour tout le monde, et nous prenons ces rapports au sérieux.