Optimiser ses images pour le SEO : format, poids, alt et dimensions

Les images occupent une place particulière dans le SEO : elles sont à la fois le poste de poids le plus lourd sur la grande majorité des pages web, un facteur direct du LCP (Largest Contentful Paint), et un canal de trafic à part entière via Google Images — souvent ignoré alors qu'il peut représenter une part significative des visites sur un site riche en contenu visuel (recettes, mode, immobilier, décoration). Optimiser ses images relève donc autant de la performance que d'un référencement propre, avec des règles qui se recoupent sans être identiques.

Le texte alternatif : ce qu'il doit vraiment contenir

L'attribut alt a une fonction d'abord d'accessibilité — il est lu à voix haute par les lecteurs d'écran pour les utilisateurs malvoyants — avant d'être un signal SEO. Un texte alternatif utile décrit factuellement ce que montre l'image, dans le contexte de la page : "Rapport d'audit SEO Seoditum affichant le score par catégorie" plutôt qu'une simple absence de balise, ou à l'inverse un empilement de mots-clés ("audit seo pas cher audit seo gratuit audit seo rapide") qui n'aide ni les utilisateurs ni Google, et qui s'apparente à une pratique de contenu trompeur.

Deux erreurs se rencontrent le plus souvent sur les sites audités : l'attribut alt totalement absent (pas même vide), qui prive l'image de toute description exploitable, et l'attribut rempli du nom de fichier brut ("IMG-20260317-WA0003.jpg") copié par erreur plutôt que d'une vraie description. Une image purement décorative (un fond, un séparateur visuel sans information propre) peut légitimement porter un attribut alt vide (alt="") — c'est la bonne pratique documentée par Google et les standards d'accessibilité, à ne pas confondre avec une absence totale de l'attribut.

Le format qui fait la différence sur le poids

À qualité visuelle équivalente, les formats modernes WebP et AVIF compressent nettement mieux que le JPEG ou le PNG traditionnels — AVIF peut réduire le poids d'un fichier de 30 à 50 % par rapport à un JPEG comparable. La quasi-totalité des navigateurs modernes prend désormais en charge ces deux formats, ce qui rend leur adoption presque sans compromis pour un site nouveau. Le PNG doit rester réservé aux images qui nécessitent une transparence ou un rendu net de texte/interface (logos, captures d'écran d'interface) plutôt qu'aux photographies, où il produit des fichiers disproportionnellement lourds sans bénéfice visuel.

Les dimensions réelles, pas seulement le poids du fichier

Un fichier bien compressé mais affiché à une taille physique disproportionnée par rapport à sa taille réelle d'affichage reste un gaspillage : une image de 4000 pixels de large, même en WebP, pèse inutilement plus lourd qu'une version redimensionnée à 800 pixels si c'est la largeur réellement affichée sur la page. L'attribut srcset, associé à des tailles adaptées au responsive, permet de servir la résolution appropriée selon l'appareil (mobile, tablette, desktop, écran haute densité) plutôt qu'une seule version surdimensionnée pour tous les cas.

Le nommage du fichier, un détail qui compte pour Google Images

Le nom de fichier fait partie des signaux que Google utilise pour comprendre le contenu d'une image, en complément de l'alt et du contexte textuel environnant. "rapport-audit-seo-seoditum.jpg" donne une indication claire ; "DSC04521.jpg" ou "image-finale-v2.png" n'en donne aucune. C'est un signal mineur pris isolément, mais qui ne coûte rien à corriger au moment de l'export ou de l'upload, contrairement à un renommage a posteriori sur un site déjà en ligne (qui casse l'URL existante et nécessite une redirection).

Le piège du lazy loading sur l'image visible immédiatement

Différer le chargement des images situées hors du champ de vision initial (lazy loading) est une bonne pratique de performance générale, largement recommandée par Google. Appliquée par erreur à l'image qui constitue l'élément LCP de la page — typiquement l'image principale visible dès l'arrivée sur la page — cette même technique retarde son affichage au lieu de l'accélérer, puisque le navigateur attend un signal de défilement avant même de commencer le téléchargement d'une image pourtant prioritaire. Ce point est détaillé plus en profondeur dans l'article sur les Core Web Vitals, où il est identifié comme l'une des causes les plus fréquentes d'un LCP dégradé sur un site par ailleurs bien optimisé.

Les données structurées, pour aller plus loin

Sur un site où les images jouent un rôle central dans l'intention de recherche (produit e-commerce, recette de cuisine, bien immobilier), le type ImageObject en JSON-LD, ou son intégration dans un type Product ou Recipe plus large, aide Google à associer explicitement une image à l'entité qu'elle représente — une information qui va au-delà de ce que l'alt et le nom de fichier seuls peuvent transmettre.

Les attributs width et height, contre le décalage visuel

Au-delà du poids et du format, deux attributs HTML simples et souvent oubliés — width et height, déclarés directement sur la balise image — permettent au navigateur de réserver l'espace exact que l'image occupera avant même qu'elle ait fini de se télécharger. Sans cette information, le navigateur ne connaît l'espace nécessaire qu'une fois l'image chargée, ce qui pousse brutalement le reste du contenu vers le bas de la page au moment de son apparition — l'une des causes les plus fréquentes d'un mauvais score de CLS (Cumulative Layout Shift), détaillé dans l'article sur les Core Web Vitals.

Ces attributs ne figent pas la taille d'affichage finale : associés à une règle CSS moderne comme aspect-ratio, ils permettent au navigateur de calculer le ratio correct et de réserver l'espace, tout en laissant l'image s'adapter en largeur à son conteneur responsive.

Le cas des images en arrière-plan CSS

Une image appliquée via la propriété CSS background-image plutôt que via une vraie balise img dans le HTML n'est, par défaut, ni indexée par Google Images, ni associée à un attribut alt (une image de fond CSS n'a structurellement pas cet attribut). C'est un choix technique légitime pour une image purement décorative (texture, motif répété), mais une erreur fréquente pour une image porteuse d'information réelle — une photo de produit, par exemple — intégrée en arrière-plan CSS uniquement pour des raisons de mise en page, qui la rend alors invisible pour le référencement d'image et moins accessible pour les lecteurs d'écran.

Le sitemap d'images, pour les sites à forte densité visuelle

Pour un site dont une part significative du trafic potentiel passe par Google Images (photographie, décoration, mode, immobilier, recettes de cuisine), un sitemap XML dédié aux images — qui liste explicitement les URLs d'images associées à chaque page, avec éventuellement leur légende — aide Google à découvrir des images qui ne seraient pas trouvées aussi vite par le seul crawl classique, en particulier celles chargées dynamiquement via JavaScript après le rendu initial de la page.

Comment compresser sans perte de qualité visible

La compression d'image se décline en deux approches : sans perte (lossless), qui réduit le poids du fichier sans aucune dégradation visuelle en supprimant des métadonnées et en optimisant l'encodage, et avec perte (lossy), qui réduit davantage le poids en sacrifiant une partie de l'information visuelle, généralement imperceptible à l'œil nu en dessous d'un certain seuil de compression. Pour la photographie, une compression avec perte réglée entre 70 et 85 % de qualité (selon l'échelle habituelle des outils d'export) offre le meilleur compromis dans la quasi-totalité des cas, avec une perte de qualité visuelle indétectable à l'écran pour un gain de poids souvent supérieur à 50 %.

Plusieurs CDN et services d'hébergement d'images modernes automatisent entièrement cette étape : ils reçoivent une image source en haute résolution, puis génèrent et servent automatiquement la version compressée, au format et à la taille adaptés à chaque appareil qui la demande — une approche qui élimine le risque d'oubli humain, au prix d'une dépendance technique supplémentaire à maintenir.

Les métadonnées EXIF : à garder ou à supprimer ?

Une photo issue directement d'un appareil photo ou d'un smartphone embarque des métadonnées EXIF : modèle d'appareil, réglages de prise de vue, date, et parfois des coordonnées GPS précises si la géolocalisation était activée au moment de la prise de vue. Ces données n'ont aucun effet direct documenté sur le classement Google, mais leur présence pose deux questions distinctes : la confidentialité (des coordonnées GPS exactes intégrées par erreur à une photo publiée peuvent révéler une adresse personnelle ou professionnelle sensible), et le poids du fichier, les métadonnées EXIF ajoutant quelques dizaines de kilo-octets superflus une fois l'image déjà publiée sur le web, où ces informations techniques n'ont plus d'utilité. La plupart des outils de compression les suppriment automatiquement au moment de l'export.

L'élément picture, pour servir le bon format à chaque navigateur

Basculer entièrement vers AVIF ou WebP sans filet de sécurité expose, en théorie, les quelques visiteurs utilisant un navigateur ancien ou peu courant qui ne prend pas en charge ces formats à une image cassée. L'élément HTML picture résout ce problème proprement : il permet de déclarer plusieurs sources dans un ordre de préférence (AVIF en premier, WebP en repli, puis JPEG en dernier recours), le navigateur choisissant automatiquement la première qu'il sait afficher, sans aucun script ni détection côté serveur. C'est la méthode recommandée pour adopter les formats nouvelle génération sans sacrifier la compatibilité, et la plupart des CDN d'images modernes la génèrent automatiquement à partir d'une seule image source.

Le badge "Sous licence" dans Google Images

Pour les sites qui vendent ou licencient des images (banques d'images, photographes professionnels, illustrateurs), Google propose un balisage spécifique en JSON-LD (les propriétés license et acquireLicensePage d'ImageObject) qui fait apparaître un badge "Sous licence" directement dans les résultats de Google Images, avec un lien vers les conditions d'utilisation ou la page d'achat. C'est un signal de niche, utile uniquement pour ce cas d'usage précis, mais qui illustre que le balisage d'image va au-delà de la simple description — il peut aussi porter une information commerciale ou juridique directement exploitable par Google.

Images décoratives et accessibilité : la nuance à ne pas rater

La distinction entre image "informative" et image "décorative" mérite d'être appliquée avec rigueur plutôt que par automatisme. Une icône à côté d'un lien (une enveloppe pour un contact par email, par exemple) est généralement décorative si le texte du lien porte déjà l'information complète — dans ce cas, un alt vide évite une répétition inutile pour un utilisateur de lecteur d'écran, qui entendrait sinon "icône enveloppe, contactez-nous" au lieu du seul "contactez-nous" attendu. À l'inverse, un graphique, un schéma ou une capture d'écran qui porte une information non répétée ailleurs dans le texte doit impérativement avoir un alt descriptif complet — l'absence d'alt sur ce type d'image prive un utilisateur non-voyant d'une partie du contenu réel de la page, pas seulement d'un détail cosmétique.

Un cas concret : auditer les images d'un site e-commerce

Sur une boutique en ligne de plusieurs centaines de fiches produits, les problèmes d'images se concentrent presque toujours au même endroit : des photos fournies directement par les fabricants ou grossistes, réutilisées telles quelles sans recompression (souvent plusieurs mégaoctets pièce), nommées par une référence interne sans rapport avec le produit ("REF-88213-V2.jpg"), et sans attribut alt renseigné parce que l'import a été fait en masse via un flux de données sans ce champ. Multiplié par plusieurs centaines ou milliers de fiches, l'effet cumulé sur le poids total du site et sur l'absence de signal pour Google Images devient largement plus coûteux que sur un site éditorial de quelques dizaines de pages, où chaque image est ajoutée manuellement.

La correction la plus efficace dans ce scénario n'est pas de reprendre chaque fiche une par une, mais de corriger le modèle d'import pour les nouveaux produits (recompression automatique, génération d'un alt à partir du nom du produit et de ses attributs) et de traiter le stock existant par lot, en priorisant les fiches qui reçoivent déjà du trafic plutôt que l'intégralité du catalogue d'un coup.

Questions fréquentes

Faut-il traduire l'attribut alt sur un site multilingue ? Oui — l'alt doit être rédigé dans la langue de la page sur laquelle l'image apparaît, au même titre que le reste du contenu textuel, pour rester cohérent avec la langue déclarée de la page et utile aux lecteurs d'écran dans cette langue.

Une image peut-elle à elle seule faire remonter une page dans Google Images sans trafic sur la recherche classique ? Oui, ce sont deux canaux largement indépendants : une page peut très bien ne jamais apparaître dans les dix premiers résultats web classiques tout en générant un trafic régulier via Google Images, si l'image elle-même répond bien à une recherche visuelle fréquente — un schéma courant sur les sites de recettes, de bricolage ou de décoration intérieure.

Combien de temps Google met-il à indexer une nouvelle image ? Généralement le même délai que pour le texte de la page qui l'héberge — de quelques jours à quelques semaines selon la fréquence de crawl du site. Le sitemap d'images, quand il existe, peut accélérer légèrement cette découverte pour les images qui ne seraient pas trouvées rapidement par le crawl HTML classique.

Dupliquer la même image sur plusieurs pages pose-t-il un problème de contenu dupliqué ? Non, pas au sens où Google l'entend pour le texte — une même photo de produit déclinée en plusieurs coloris sur des fiches différentes, par exemple, est une pratique normale et ne déclenche aucune pénalité. La vigilance porte plutôt sur le contenu textuel autour de l'image (title, description, alt) qui, lui, ne doit pas être strictement identique d'une fiche à l'autre si les pages sont censées se différencier aux yeux de Google.

Checklist rapide

• Chaque image porteuse d'information a un attribut alt descriptif ; chaque image purement décorative a un alt vide plutôt qu'absent.
• Le format utilisé est WebP ou AVIF plutôt que JPEG/PNG pour les photographies, PNG réservé aux logos et captures d'interface.
• La taille physique du fichier correspond à sa taille réelle d'affichage, avec un srcset pour les variations responsive.
• Le nom de fichier décrit le contenu de l'image plutôt qu'un identifiant technique généré par l'appareil photo ou le logiciel.
• Le lazy loading est actif sur les images hors champ de vision initial, mais explicitement désactivé sur l'image LCP.

Seoditum vérifie ce point automatiquement, avec preuve à l'appui, sur l'ensemble de votre site.