Optimisation des images pour le SEO technique : formats et attributs

Vous connaissez cette sensation : vous ouvrez un onglet, vous attendez, la page blanche reste blanche, et l'image du hero finit par apparaître par bandes, comme un vieux fax. C'est presque toujours une image mal servie. Pas un serveur lent. Pas un mauvais hébergeur. Une image de 2,4 Mo qui aurait dû en peser 90.

Sur mon propre blog, une seule image de bannière m'a coûté cher pendant des mois : chargée en PNG, 1,9 Mo, servie à l'identique sur mobile et sur desktop. Le jour où j'ai arrêté de la traiter comme un fichier décoratif pour la traiter comme un élément technique, mon LCP est passé de 3,8 s à 1,4 s sur mobile. Le contenu n'avait pas changé d'une virgule. Voilà ce que veut dire optimisation des images pour le SEO technique : ce n'est pas de l'esthétique, c'est de la plomberie.

Choisir le bon format d'image : la décision qui change tout

Je vais être direct : la plupart des sites que j'ai audités servent encore du JPEG là où un format moderne ferait 40 % de moins. Et du PNG là où un JPEG aurait suffi. Ce n'est pas de la négligence, c'est que personne ne s'est posé la question.

Quel format pour quel usage ?

Deux familles s'opposent. La compression avec perte (JPEG, WebP, AVIF) jette de l'information pour alléger. La compression sans perte (PNG, WebP lossless) conserve tout mais pèse lourd.

• Photo, arrière-plan complexe, dégradés → WebP en priorité, AVIF si votre chaîne de build le génère, JPEG en repli.
• Logo, icône, texte incrusté → SVG quand c'est vectoriel. Sinon PNG.
• Capture d'écran d'interface → PNG ou WebP lossless. Le JPEG fait baver le texte, c'est horrible.
• Petite illustration plate de moins de 30 Ko — franchement, ne perdez pas une heure dessus. Le gain est nul.

WebP, AVIF, JPEG : ce qui change vraiment

AVIF compresse mieux que WebP, qui compresse mieux que JPEG. Sur une photo de paysage que j'ai testée à l'identique, à qualité visuelle équivalente, JPEG sortait à 340 Ko, WebP à 190 Ko, AVIF à 120 Ko. Mais AVIF consomme plus de CPU à l'encodage, ce qui compte si vous compilez des milliers d'images.

Le support navigateur n'est plus un vrai frein en 2026 : WebP est pris en charge partout depuis longtemps, AVIF également sur les navigateurs actuels. Ce qui veut dire qu'un simple <picture> avec AVIF en source et JPEG en repli couvre tout le monde.

Format	Poids relatif	Idéal pour	À éviter pour
JPEG	Référence (100 %)	Repli, vieux pipelines	Logos, texte
WebP	~55 %	Presque tout, photos	Rien de bloquant
AVIF	~35 %	Grandes photos de hero	Chaînes sans encodage AVIF
PNG	~300 %	Transparence, captures	Photos
SVG	Quelques Ko	Logos, icônes, schémas	Images photographiques

Ma règle : si une image fait plus de 200 Ko et qu'elle n'a pas besoin de transparence, elle est en WebP. Point.

L'attribut alt : ce que Google y cherche vraiment

On m'a posé cette question dix fois cette année : « il faut mettre le mot-clé dans l'alt ? » La réponse honnête est : si la description naturelle de l'image contient le mot-clé, oui. Sinon, non.

Ce qui compte, c'est que l'alt décrive ce que l'image montre, dans un contexte où un lecteur d'écran ne verrait rien d'autre. Un alt vide (alt="") est parfaitement valide pour une image purement décorative. Et c'est même la bonne pratique : un alt vide indique aux technologies d'assistance « passe, ceci n'apporte rien ».

• Image informative → alt descriptif court. « Graphique du taux de conversion entre 2024 et 2026 ».
• Image décorative → alt="". Ne remplissez pas avec « image décoration ».
• Image cliquable dans un lien → l'alt doit décrire la destination du lien, pas le visuel.

Et non, empiler les mots-clés dans l'alt ne fonctionne pas. J'ai vu une page où chaque alt contenait « meilleur logiciel de facturation pas cher » — ça ressemble à du spam parce que c'en est.

Nommer et dimensionner correctement ses fichiers

Le nom de fichier est un signal faible mais réel : graphique-taux-conversion-2026.webp vaut mieux que IMG_4821.webp. Pas besoin d'en faire un roman, trois à cinq mots séparés par des tirets suffisent.

Quant aux dimensions : ne chargez jamais une image de 3000 px pour l'afficher dans un conteneur de 600 px. Ce n'est pas de l'optimisation, c'est du gaspillage de bande passante. Redimensionnez au double de la taille d'affichage maximale (pour les écrans à forte densité) et pas plus.

Lazy loading et images responsives : les deux attributs qu'on oublie

Le lazy loading est évoqué partout. Implémenté correctement, rarement.

Comment fonctionne réellement loading="lazy" ?

Un seul attribut, loading="lazy", et le navigateur diffère le chargement jusqu'à ce que l'image approche du viewport. Le gain est immense sur les pages longues : sur un article de blog avec dix images, j'ai mesuré environ 60 % de données économisées au premier rendu.

Mais voici le piège que j'ai découvert à mes dépens. Le navigateur applique un « seuil de distance » assez généreux, et sur mobile, ça peut retarder le chargement d'une image située juste en dessous de la ligne de flottaison. Résultat : vous grattez quelques centaines de millisecondes en bas de page et vous en perdez 400 sur le défilement.

La règle que j'applique désormais :

• Image LCP (celle visible en haut de page) → loading="eager" explicite, ou rien du tout.
• Le reste → loading="lazy".
• Jamais de lazy sur les images d'un carrousel visible au chargement.

srcset : servir la bonne taille au bon écran

srcset permet de déclarer plusieurs variantes d'une même image, et le navigateur choisit. C'est du HTML, pas du JavaScript. Trois lignes :

1. Vous générez vos variantes (480, 960, 1440 px de large).
2. Vous les listez avec leurs descripteurs de largeur (w).
3. Vous ajoutez sizes pour indiquer la largeur d'affichage attendue.

Le téléphone reçoit 480 px, le grand écran 1440 px. Sur une grille de vignettes que j'ai reprise l'an dernier, cette seule modification a réduit le poids moyen par image de 210 Ko à 64 Ko sur mobile. Sans toucher à la qualité perçue.

Images et Core Web Vitals : ce qui compte pour le référencement

Trois métriques, une seule vraiment pilotée par les images : le LCP (Largest Contentful Paint). Dans la majorité des pages que j'audite, l'élément LCP est une image, pas du texte. Donc toute votre optimisation d'images est en réalité une optimisation de LCP.

Ce qui fait gagner du temps, dans l'ordre d'impact :

1. Le format et le poids. Passer du PNG au WebP sur l'image LCP, c'est souvent 1 à 2 secondes gagnées sur mobile.
2. Les dimensions réservées (width et height explicites) pour éviter le décalage de mise en page, qui pénalise le CLS.
3. Le preload de l'image LCP, quand elle est vraiment critique et servie par un CDN fiable.
4. Tout le reste.

J'ai passé des semaines à tester des astuces de préconnexion DNS avant de comprendre que le vrai levier était plus bête : mon image de hero pesait 1,2 Mo. Réduire le fichier a réglé le problème en une après-midi.

Un article SEO, c'est quoi ?

C'est une page web conçue pour être comprise par les moteurs de recherche et utile aux lecteurs, en travaillant trois couches : le contenu (ce qui est dit), la structure (titres, liens internes, données structurées) et la technique (vitesse, HTML propre, images optimisées). L'optimisation d'images appartient à la troisième couche. C'est la moins glamour, et souvent celle qui rapporte le plus vite.

SEO images : par où commencer quand on débute ?

Trois actions, dans cet ordre, sans rien installer : renommez vos fichiers avec des mots descriptifs, écrivez un alt honnête pour chaque image porteuse de sens, et redimensionnez les images trop grandes. Ces trois gestes corrigent environ 70 % des problèmes que je rencontre sur les sites de petites structures. Le reste — WebP, srcset, AVIF — vient après, quand la base est propre.

Ce que je vois le plus souvent, ce n'est pas un manque d'outils. C'est une image de 2 Mo qui traîne depuis deux ans au même endroit, que personne n'a jamais rouverte parce qu'elle « fonctionne ». Elle fonctionne. Elle vous coûte juste des positions.