Points clés
- Plus de 75 % des utilisateurs mobiles et une part croissante des utilisateurs desktop naviguent sur des écrans Retina ou HiDPI (source : StatCounter, 2025)
- Une image servie en résolution 1x sur un écran 2x apparaît floue — un défaut invisible sur l'écran non-Retina du développeur
- Les tests unitaires et fonctionnels ne vérifient pas la résolution des images servies au navigateur
- Le test visuel sur des viewports HiDPI capture le rendu tel que l'utilisateur le voit réellement et détecte les images sous-dimensionnées
Le test visuel, selon la définition de l'ISTQB (International Software Testing Qualifications Board), désigne « la vérification que l'interface utilisateur d'un logiciel s'affiche conformément aux spécifications visuelles attendues, en comparant des captures d'écran de référence avec l'état actuel de l'application » (ISTQB Glossary, Visual Testing).
Voici un problème que la quasi-totalité des équipes de développement web ignorent : votre site a probablement l'air flou pour la majorité de vos utilisateurs, et vous ne le savez pas.
Ce n'est pas une hyperbole. Quand Apple a lancé les écrans Retina en 2010 avec l'iPhone 4, le ratio de pixels est passé de 1x à 2x. Chaque pixel CSS est rendu par quatre pixels physiques. Depuis, cette tendance s'est généralisée. Les iPhones actuels affichent en 3x. Les MacBook Pro, les iPad, les écrans Samsung, les Google Pixel — tous utilisent des ratios de 2x ou plus. Selon les données de StatCounter pour 2025, plus de 75 % des sessions mobiles proviennent d'appareils à haute densité de pixels, et cette proportion ne cesse de croître sur desktop avec la démocratisation des écrans 4K et 5K.
Le résultat : si vous servez une image de 400×300 pixels pour un espace d'affichage de 400×300 pixels CSS, cette image est nette sur un écran 1x. Mais sur un écran 2x, le navigateur doit étirer ces 400×300 pixels physiques sur 800×600 pixels physiques. L'image devient floue. Pas catastrophiquement floue — subtilement floue. Suffisamment floue pour que votre logo perde sa netteté, que vos photos de produit paraissent « pas professionnelles », que vos icônes semblent pixelisées.
Et le pire : vous ne le voyez pas, parce que vous développez peut-être sur un écran non-Retina, ou parce que votre navigateur de développement n'émule pas le ratio de pixels réel.
Cet article défend une position sans détour : si vous ne testez pas visuellement votre site en résolution HiDPI, vous ne testez pas votre site tel que vos utilisateurs le voient. Et le test visuel automatisé est le seul moyen fiable de détecter ces problèmes à l'échelle.
Le problème Retina : un flou que les développeurs ne voient pas
Pour comprendre pourquoi les images Retina sont un problème si répandu, il faut comprendre le mécanisme du Device Pixel Ratio (DPR) et ses conséquences sur le rendu des images.
Le Device Pixel Ratio expliqué
Le Device Pixel Ratio (DPR) est le rapport entre les pixels physiques de l'écran et les pixels CSS utilisés par le navigateur. Un écran avec un DPR de 1 affiche un pixel physique par pixel CSS. Un écran avec un DPR de 2 (Retina) affiche quatre pixels physiques par pixel CSS (2×2). Un écran avec un DPR de 3 affiche neuf pixels physiques par pixel CSS (3×3).
Quand le navigateur doit afficher une image de 200×200 pixels dans un conteneur CSS de 200×200 pixels sur un écran 2x, il a besoin de 400×400 pixels physiques pour remplir cet espace. Si l'image source ne fait que 200×200 pixels, le navigateur utilise un algorithme d'interpolation pour inventer les pixels manquants. Le résultat : un flou caractéristique, particulièrement visible sur les images contenant du texte, des lignes fines, des logos ou des icônes.
Pourquoi les développeurs ne le voient pas
Voici le paradoxe : le développeur qui crée le problème ne le voit souvent pas. Plusieurs raisons à cela.
Si vous développez sur un écran non-Retina (un moniteur externe 1080p, par exemple), une image 1x s'affiche parfaitement sur votre écran. Elle est nette, les pixels correspondent un à un. Vous n'avez aucune raison de soupçonner un problème.
Si vous développez sur un MacBook avec écran Retina mais que vous testez avec les DevTools Chrome en mode responsive, le DPR émulé dépend de votre configuration. Par défaut, Chrome utilise un DPR de 1 pour les devices émulés les plus courants dans la barre de devices. Vous pouvez manuellement configurer un DPR de 2 ou 3, mais combien de développeurs le font systématiquement ?
Et même si vous développez sur un écran Retina et que vous voyez le flou, vous pouvez ne pas le remarquer. Le flou des images 1x sur un écran 2x est subtil. L'œil s'adapte. Vous devez comparer activement une image 1x et une image 2x côte à côte pour percevoir la différence — et qui fait cela régulièrement ?
L'impact sur la perception de qualité
Le flou des images sur les écrans Retina n'est pas un détail technique anodin. La recherche en psychologie cognitive montre que la netteté des images est l'un des facteurs les plus influents dans la perception de la qualité et de la crédibilité d'un site web. Une étude publiée par Google et l'Université de Bâle (Tuch et al., 2012) a démontré que les utilisateurs portent un jugement sur la crédibilité d'un site en moins de 50 millisecondes, et que la qualité visuelle est le facteur dominant dans ce jugement.
Concrètement : si votre logo est flou, si vos photos de produit manquent de netteté, si vos icônes paraissent pixelisées, vos utilisateurs perçoivent votre site comme moins professionnel et moins fiable. Et ils n'en sont probablement même pas conscients — c'est une réaction instinctive.
Pour les sites e-commerce, l'impact est encore plus direct. Des photos de produit floues réduisent la confiance dans le produit et augmentent les taux de retour. Pour les sites de marque, un logo flou est un signal d'amateurisme qui contredit tout le travail de branding.
Les solutions techniques et leurs limites
Le web a développé plusieurs mécanismes pour servir des images adaptées à la densité de l'écran. Mais leur mise en œuvre est fragile, et leur vérification est encore plus fragile.
Les attributs srcset et sizes
L'attribut HTML srcset permet de spécifier plusieurs versions d'une image pour différentes densités de pixels. Le navigateur choisit automatiquement la version la plus adaptée à l'écran de l'utilisateur. L'attribut sizes complète srcset en indiquant au navigateur la taille d'affichage prévue de l'image, ce qui lui permet de choisir la source optimale avant même de télécharger l'image.
En théorie, c'est la solution idéale. En pratique, la mise en œuvre est truffée de pièges. Vous devez générer et maintenir plusieurs versions de chaque image (1x, 2x, parfois 3x). Vous devez vous assurer que chaque version est correctement référencée dans le srcset. Si vous ajoutez une nouvelle image et que vous oubliez de générer la version 2x, le navigateur Retina tombera sur la version 1x et l'image sera floue.
Le problème est que rien dans votre pipeline de tests ne vérifie que le srcset est correct. Vos tests unitaires peuvent vérifier que l'attribut srcset existe dans le HTML, mais ils ne peuvent pas vérifier que les fichiers images référencés existent réellement et qu'ils ont la bonne résolution.
Les images CSS et les media queries
Pour les images d'arrière-plan en CSS, la technique conventionnelle utilise les media queries avec le sélecteur de résolution pour servir des images 2x sur les écrans HiDPI. Là encore, cela fonctionne — à condition de le faire pour chaque image d'arrière-plan, et de maintenir cette duplication dans le temps.
Le risque est le même que pour srcset : l'oubli ou l'erreur dans la maintenance. Un nouveau développeur qui ajoute une image d'arrière-plan sans la media query haute résolution. Un refactoring CSS qui supprime la media query par erreur. Une image 2x qui est référencée dans le CSS mais qui n'existe plus sur le serveur après une migration.
Les formats vectoriels (SVG)
Les images SVG sont insensibles au DPR par nature. Étant vectorielles, elles sont nettes à toute résolution. C'est la raison pour laquelle les icônes et les logos devraient idéalement être en SVG.
Mais tous les contenus ne peuvent pas être en SVG. Les photos, les captures d'écran, les illustrations raster complexes restent en PNG, JPEG ou WebP. Et même les SVG peuvent poser des problèmes visuels : une icône SVG dont le viewBox est mal configuré peut s'afficher avec des proportions incorrectes, ou une icône qui inclut des bitmaps embarqués peut être partiellement floue.
Le problème de la vérification manuelle
Toutes ces solutions techniques partagent une faiblesse commune : aucune ne se vérifie elle-même. Vous pouvez avoir une infrastructure parfaite de génération d'images multirésolution, mais si un maillon de la chaîne casse — un pipeline de build qui ne génère plus les images 2x, un CDN qui ne sert pas le bon fichier, un template qui oublie le srcset — le résultat est une image floue en production.
La vérification manuelle est théoriquement possible, mais pratiquement impossible à l'échelle. Vérifier chaque image de chaque page sur un écran Retina, comparer la version mobile 3x et la version desktop 2x, s'assurer que les images d'arrière-plan CSS sont en haute résolution — c'est un travail qui prend des heures et qui doit être refait à chaque déploiement.
Le test visuel HiDPI : la seule vérification fiable
C'est ici que le test visuel sur des viewports HiDPI apporte une valeur que rien d'autre ne peut fournir.
Capturer ce que l'utilisateur voit réellement
Un outil de test visuel configuré pour capturer des screenshots avec un Device Pixel Ratio de 2 ou 3 rend la page exactement comme un écran Retina le ferait. Les images sont chargées et affichées à la résolution effective de l'écran. Si une image est en 1x et que le viewport est en 2x, l'image apparaît floue dans le screenshot — exactement comme elle apparaîtrait sur l'écran de votre utilisateur.
La comparaison de ces screenshots haute résolution avec les baselines détecte automatiquement les images qui ne sont pas en résolution suffisante. Le diff visuel montre précisément les zones de la page où la netteté a changé. Pas besoin de parcourir manuellement chaque page avec un écran Retina — l'outil le fait pour vous, systématiquement, à chaque déploiement.
Détecter les régressions de résolution
Le test visuel automatisé sur des viewports HiDPI est particulièrement efficace pour détecter les régressions — les situations où une image qui était en 2x cesse de l'être. Cela arrive plus souvent qu'on ne le pense : une mise à jour du CMS qui réinitialise les variantes d'image, une migration de stockage qui oublie les versions haute résolution, un changement de template qui remplace un srcset par un src simple.
Sans test visuel, ces régressions passent inaperçues pendant des semaines ou des mois. Avec un test visuel qui capture en DPR 2, la régression est détectée au prochain build. Le diff montre clairement que l'image qui était nette est devenue floue.
Couvrir les différents ratios de pixels
Le marché des écrans est fragmenté. Les iPhones modernes utilisent un DPR de 3. Les MacBook utilisent un DPR de 2. Les écrans Android varient entre 1.5, 2, 2.75 et 3. Les écrans desktop 4K en scaling 150 % ont un DPR de 1.5.
Un test visuel complet capture vos pages à plusieurs DPR pour vérifier que les images sont nettes sur chaque type d'écran. Vous pouvez prioriser le DPR 2 (qui couvre la majorité des écrans Retina) et ajouter le DPR 3 pour les pages critiques (page d'accueil, pages produit, landing pages).
Au-delà des images : ce que le HiDPI révèle d'autre
Un screenshot testing en haute résolution ne détecte pas seulement les images floues. Il révèle les bordures CSS de 1px qui s'affichent différemment selon le DPR (hairline borders vs. double pixels). Il montre les dégradés qui présentent du banding en 2x alors qu'ils paraissent lisses en 1x. Il expose les polices personnalisées dont le rendu subpixel varie entre densités d'écran. Et il attrape les favicons et icônes d'application en résolution insuffisante — un oubli classique de la stratégie Retina.
Mettre en place le test visuel HiDPI dans votre workflow
L'intégration est simple. Commencez par trois viewports représentatifs : desktop 1440px en DPR 2 (MacBook Pro), mobile 390px en DPR 3 (iPhone 14/15), tablette 810px en DPR 2 (iPad). Priorisez les pages à images critiques : page d'accueil, pages produit, landing pages. Intégrez les captures HiDPI dans votre pipeline CI — le surcoût est de quelques secondes par page.
Arrêtez de développer en aveugle
La majorité de vos utilisateurs voient votre site sur un écran haute résolution. Si vous ne testez pas en haute résolution, vous testez une version de votre site que vos utilisateurs ne voient pas. C'est aussi simple que cela.
Le test visuel en DPR 2 et 3 n'est pas un luxe réservé aux grandes équipes. C'est une nécessité pour quiconque prend la qualité visuelle au sérieux. Et avec un outil no-code, c'est une nécessité accessible : pas de scripts, pas de configuration complexe, juste des captures en haute résolution comparées automatiquement à vos baselines.
Vos images méritent d'être nettes. Vos utilisateurs méritent de voir votre site tel que vous l'avez conçu. Le test visuel HiDPI est le moyen de garantir les deux.
FAQ
Quelle est la différence entre Retina, HiDPI et haute résolution ?
Ces termes désignent le même concept avec des origines différentes. « Retina » est le terme marketing d'Apple pour ses écrans à haute densité de pixels (DPR ≥ 2). « HiDPI » (High Dots Per Inch) est le terme technique générique utilisé par l'industrie, notamment par Google pour Android et Chrome OS. « Haute résolution » est le terme commun. Dans le contexte du test visuel, ces trois termes signifient la même chose : un écran dont le Device Pixel Ratio est supérieur à 1, nécessitant des images de résolution supérieure pour un rendu net.
Le test visuel en DPR 2 consomme-t-il plus de ressources que le DPR 1 ?
Oui, modérément. Un screenshot en DPR 2 contient quatre fois plus de pixels qu'un screenshot en DPR 1 (le double en largeur et en hauteur). Le fichier image est donc plus volumineux, le stockage nécessaire est plus important, et la comparaison de pixels prend légèrement plus de temps. En pratique, pour la plupart des projets, cette différence est négligeable. Le surcoût en temps de CI est de l'ordre de quelques secondes par page, et le surcoût en stockage est gérable avec la compression moderne des screenshots.
Mon site utilise des images WebP ou AVIF. Le problème Retina s'applique-t-il quand même ?
Oui. WebP et AVIF sont des formats de compression, pas des solutions au problème de résolution. Une image WebP de 400×300 pixels sera tout aussi floue qu'une image JPEG de 400×300 pixels sur un écran 2x. Le format de l'image détermine la qualité de la compression et la taille du fichier, pas la résolution intrinsèque de l'image. Vous avez toujours besoin de servir des images en 2x ou 3x, simplement elles seront compressées plus efficacement en WebP ou AVIF qu'en JPEG ou PNG.
Comment savoir quelles images de mon site ne sont pas en résolution Retina ?
Le moyen le plus direct est le test visuel en DPR 2. Capturez vos pages avec un outil de test visuel configuré en DPR 2, puis comparez avec les baselines en DPR 1. Les zones floues apparaîtront clairement dans le diff. Alternativement, les DevTools Chrome permettent d'émuler un DPR élevé et d'inspecter manuellement chaque image, mais cette approche est fastidieuse et non automatisable. Le test visuel automatisé est la seule méthode qui garantit une vérification exhaustive à chaque déploiement.
Le test visuel HiDPI remplace-t-il l'utilisation de srcset ?
Non. Le srcset est la solution technique côté code pour servir les bonnes images aux bons écrans. Le test visuel HiDPI est la vérification que cette solution fonctionne correctement. Les deux sont complémentaires. Le srcset est la prévention ; le test visuel est la détection. Vous avez besoin des deux, car même un srcset correctement implémenté peut casser lors d'une mise à jour de CMS, d'une migration de stockage, ou d'un changement de pipeline de build.
Faut-il tester en DPR 3 en plus du DPR 2 ?
Cela dépend de votre audience. Si une part significative de vos utilisateurs navigue sur des iPhones récents (DPR 3), tester en DPR 3 a du sens pour vos pages les plus critiques. Pour la majorité des sites, le DPR 2 couvre le cas le plus courant et détecte la plupart des problèmes de résolution. Une image qui est nette en DPR 2 (donc servie en 2x) sera légèrement moins nette en DPR 3, mais la différence est beaucoup moins perceptible que le passage de 1x à 2x. Commencez par le DPR 2, et ajoutez le DPR 3 si vos analytics le justifient.
Pour aller plus loin
- Test Visuel, Contraste et Daltonisme : Vérifier ce que vos utilisateurs voient vraiment
- Test Visuel des Iframes et Embeds Tiers : Vous Êtes Responsable de Ce Que Vous Ne Contrôlez Pas
Vos utilisateurs voient votre site en haute résolution. Vous devriez le tester de la même manière. Delta-QA capture vos pages en DPR 2 et 3 et détecte les images floues avant que vos utilisateurs ne les voient.