Pour bien tester un responsive design, faites trois passes : balayez lentement la largeur du viewport d’environ 320 px à 1 920 px pour repérer où la mise en page casse, vérifiez des appareils précis avec leur vrai user agent et leur densité de pixels, puis malmenez la mise en page avec des contenus longs et un zoom à 200 %. La plupart des bugs responsive se cachent entre les breakpoints et dans des contenus qui n’étaient pas prévus par la maquette, c’est pourquoi vérifier trois tailles fixes (« mobile, tablette, ordinateur ») les laisse passer.
Pourquoi trois tailles ne suffisent pas
Une mise en page est conçue à quelques largeurs, mais utilisée à toutes. Un titre qui tient à 375 px peut mal passer à la ligne à 344 px (certains téléphones pliants fermés). Une barre de navigation qui tient à 1 024 px peut déborder à 1 100 px dès qu’un intitulé s’allonge. Les bugs se concentrent :
- juste en dessous et au-dessus de chaque breakpoint ;
- à des largeurs pour lesquelles personne n’a conçu, comme 600 à 700 px (petites tablettes, écran partagé) ;
- avec des contenus réels plus longs que ceux de la maquette.
Passe 1 : le balayage des largeurs
- Ouvrez Chrome DevTools, activez la barre d’appareils (
Ctrl + Maj + M, ouCmd + Maj + Msur Mac) et choisissez Responsive. - Réglez la largeur sur 320 px et tirez lentement le bord droit jusqu’à la plus grande taille que vous prenez en charge.
- Surveillez : barres de défilement horizontales, textes qui se chevauchent, boutons qui passent sur deux lignes, images étirées, grilles avec une carte orpheline, éléments qui sautent au changement de breakpoint.
- Quand quelque chose casse, notez la largeur exacte affichée dans la barre.
Activez Show media queries dans le menu de la barre d’appareils pour voir vos breakpoints sous forme de barres colorées au-dessus du viewport. Un clic sur une barre vous amène à cette largeur. L’aide pas à pas sur le mode appareil se trouve dans le guide de l’émulateur mobile Chrome.
Une bonne habitude : testez chaque breakpoint à sa valeur exacte et un pixel en dessous. Les erreurs d’un pixel entre max-width: 768px et min-width: 768px sont fréquentes.
Passe 2 : de vrais profils d’appareils
La largeur n’est qu’une partie de ce que transmet un téléphone. Les appareils envoient aussi un user agent mobile, ont une densité de pixels de 2 ou 3, et peuvent déclencher un comportement différent côté serveur ou en JavaScript. Vérifiez vos pages clés sur des profils précis :
- un petit téléphone (environ 360 à 375 px de large) ;
- un iPhone récent (393 à 402 px) et un grand iPhone (430 à 440 px) ; les valeurs sont dans le tableau des tailles d’écran iPhone ;
- un téléphone Android (360 à 412 px) ;
- une tablette dans les deux orientations (guide iPad et tablettes).
Les préréglages d’appareils de DevTools conviennent. Une extension de test responsive comme Mobile View Extension va plus vite quand il faut parcourir beaucoup de pages : elle recharge l’onglet avec le user agent, la taille d’écran et la densité de pixels de l’appareil, conserve l’appareil pendant la navigation et permet de comparer côte à côte plusieurs vues d’une même page.
Passe 3 : malmenez le contenu
Les maquettes utilisent un contenu parfait. Pas les vrais sites. Essayez :
- Mots et chaînes longs : un nom de produit à rallonge, une traduction allemande, une adresse e-mail ou une URL dans une colonne étroite. Ajoutez
overflow-wrap: anywherelà où c’est nécessaire. - Plus ou moins d’éléments : un menu à huit entrées au lieu de cinq, une grille de sept cartes au lieu de six.
- Images manquantes : à quoi ressemble la carte quand l’image ne charge pas ou est encore en cours de chargement ?
- Grand texte : réglez la taille de police par défaut du navigateur sur 20 px ou plus. Une mise en page en
remdoit suivre ; les blocs à hauteur fixe vont couper le texte. - Zoom à 200 % et 400 % sur ordinateur : le zoom rétrécit le viewport CSS, donc à 400 % une fenêtre de 1 280 px se comporte comme un écran de 320 px. Les WCAG 2.2 exigent qu’à cette taille le contenu se réorganise sans défilement dans deux directions, sauf pour des contenus comme les cartes et les tableaux de données.
Passe 4 : automatisez les captures
Les passes manuelles trouvent un bug une fois, et une capture d’écran mobile jointe à un ticket montre la largeur exacte où il s’est produit. Les captures automatisées le repèrent quand il revient. Avec un outil comme Playwright, un court script peut ouvrir vos pages clés à 360, 768, 1 024 et 1 440 px, par exemple, dans Chromium, Firefox et WebKit, et comparer les captures avec la version précédente à chaque pull request. Ce type de test de régression visuelle convient bien aux design systems et aux pages marketing qui changent souvent.
Les testeurs responsive en ligne
Les sites qui affichent votre URL dans plusieurs cadres à la fois donnent un aperçu rapide. Ils ont leurs limites : ils chargent la page depuis leurs serveurs ou dans des iframes, ne peuvent donc pas accéder à localhost ni aux pages derrière un identifiant, beaucoup de sites refusent d’être affichés en iframe, et les cadres ne changent en général que la largeur, pas le user agent. Servez-vous-en pour un coup d’œil, pas pour valider.
Checklist de test responsive
| Contrôle | Comment |
|---|---|
| Aucun défilement horizontal à partir de 320 px | Balayage des largeurs |
| Breakpoints corrects à la valeur exacte et 1 px en dessous | Show media queries, saisie des largeurs |
| Navigation fonctionnelle à toutes les largeurs | Balayage + profils d’appareils |
| Images nettes sur écrans 2x et 3x | Profils d’appareils avec densité de pixels |
| Contenu réorganisé à 400 % de zoom | Zoom du navigateur sur ordinateur |
| Les contenus longs ne cassent pas les composants | Test de contenu extrême |
| Même résultat dans WebKit et Gecko | Safari ou simulateur, Firefox |
| Pas de régression après modification | Captures automatisées |
Pour les vérifications plus larges avant mise en ligne (formulaires, vitesse, SEO), utilisez la checklist de test d’un site mobile.
Questions fréquentes
Comment tester rapidement si un site est responsive ?
Ouvrez Chrome DevTools, choisissez le mode Responsive dans la barre d’appareils et faites glisser la largeur à partir de 320 px. Tout ce qui déborde ou se chevauche est un bug responsive.
Quelles tailles d’écran tester en responsive design ?
Balayez toutes les largeurs dès 320 px, puis vérifiez 360, 375, 390 à 402, 412 et 430 à 440 px pour les téléphones, environ 768 à 834 px et 1 024 px pour les tablettes, et 1 280 à 1 920 px pour les ordinateurs.
Redimensionner la fenêtre du navigateur, est-ce un vrai test responsive ?
C’est un vrai test des breakpoints CSS, mais les navigateurs de bureau ne descendent pas sous 500 px environ et n’envoient pas de user agent mobile. Pour les largeurs de téléphone, utilisez le mode appareil ou une extension d’affichage mobile.