Tester sur des appareils que vous n’avez pas
Un simulateur vous parle de mise en page. Il ne peut pas dire ce que donne la page sur un Android de quatre ans — et faire comme si, c’est ainsi que les bugs arrivent en production.
Simulator Panel prévisualise une page sur plusieurs tailles d’appareil à la fois, avec des DevTools intégrés — console, réseau, stockage — plus la capture d’écran sur tous les appareils, le profilage de performance et d’accessibilité, un vérificateur de contraste, un validateur de cibles tactiles et des configurations d’appareil personnalisées.
Ce qui change le flux de travail, c’est le multi-appareil. Redimensionner une fenêtre est une séquence ; voir quatre largeurs côte à côte est une comparaison — et c’est dans la comparaison qu’on remarque que la mise en page des cartes s’effondre bizarrement à exactement un point de rupture.
Quelles tailles garder ouvertes
La tentation est d’ajouter tous les appareils de la liste. Huit aperçus, c’est huit petites fenêtres, et vous n’en lisez plus aucune.
Quatre est le nombre qui reste utile :
- Un petit téléphone — la largeur la plus étroite que vous prétendez prendre en charge. C’est là que le texte passe mal à la ligne et que les boutons se chevauchent.
- Un grand téléphone — là où se trouve réellement votre trafic mobile.
- Une tablette en portrait — la taille que tout le monde oublie, et celle où les mises en page bureau apparaissent au mauvais moment.
- Un portable — pas un écran 27 pouces. La plupart des visiteurs bureau sont en 13 ou 14 pouces, et les designs conçus sur grands écrans y cassent régulièrement.
Les configurations personnalisées valent le coup une fois si vous avez un vrai biais d’audience : une résolution de borne, une tablette précise utilisée par un client. À faire une fois, enregistrer, ne plus y penser.
Les deux contrôles qui valent le coup à chaque fois
Les outils d’accessibilité ont la réputation de produire cent avertissements dont personne ne fait rien. Ces deux-là sont différents : ils échouent pour des raisons corrigeables en une minute et touchent des personnes réelles immédiatement.
Le contraste. Du texte gris sur fond blanc est le défaut d’accessibilité le plus courant du web, et il arrive généralement quand quelqu’un éclaircit une couleur pour rendre un design plus calme. Le vérificateur donne un chiffre ; s’il échoue, foncez le texte plutôt que de discuter avec le chiffre.
Les cibles tactiles. Un contrôle confortable à la souris peut être réellement difficile au pouce. Le validateur signale ce qui est trop petit, et la correction est presque toujours du remplissage, pas une refonte. Cela compte surtout sur l’aperçu du petit téléphone — c’est-à-dire celui qu’on saute.
Lancez les deux avant la revue, pas après. Un défaut de contraste trouvé en revue coûte un aller-retour ; trouvé dans le panneau, il coûte une frappe.
Des captures sur tous les appareils d’un coup
La capture groupée est plus utile qu’il n’y paraît, pour une raison précise : c’est le moyen le plus rapide de rendre un problème de mise en page discutable.
« Ça s’affiche mal sur mobile » ouvre une discussion. Quatre captures à quatre largeurs attachées à la carte en ferment une. Et comme les captures viennent du même instant, personne ne peut suggérer que vous regardiez un build périmé.
Attachez-les à la carte plutôt que de les coller dans le chat. La carte est l’endroit où quelqu’un ira voir dans trois semaines en se demandant pourquoi le remplissage a changé.
Ce qu’un simulateur ne peut pas vous dire
C’est la partie où il faut être honnête, parce que le mode d’échec est silencieux.
Un simulateur rend votre page à une taille donnée, dans votre moteur de navigateur, sur votre machine, via votre connexion. Il est exact sur la mise en page et inutile sur tout le reste.
Il ne vous dira pas que la page met onze secondes sur un Android de quatre ans, que la police s’affiche différemment sur un vrai iPhone, que l’en-tête collant masque le champ quand le clavier virtuel s’ouvre, ou que l’animation saccade sur du matériel sans GPU correct. Ce sont ces bugs-là qui arrivent en production après un passage propre au simulateur.
Donc : utilisez le panneau pour la mise en page, le contraste et les cibles tactiles — ce en quoi il est vraiment bon — et gardez un téléphone Android bon marché bien réel sur le bureau pour le reste. Un appareil physique attrape une catégorie de problèmes qu’aucun simulateur n’atteint.
Pour le volet performance, Web Analyzer mesure une page telle qu’elle est réellement servie, et non telle qu’elle se rend en local. C’est une autre question que « la mise en page tient-elle », et elle mérite d’être posée séparément avant un lancement.
Questions fréquentes
Combien d’aperçus d’appareils garder ouverts ?
Quatre : un petit téléphone, un grand téléphone, une tablette en portrait et un portable. Huit aperçus, c’est huit petites fenêtres et vous n’en lisez plus aucune. Le portable compte plus qu’un grand écran : la plupart des visiteurs bureau sont en 13 ou 14 pouces.
Quels contrôles d’accessibilité valent vraiment le coup ?
Le contraste et les cibles tactiles, à chaque fois. Les deux échouent pour des raisons corrigeables en une minute et touchent des utilisateurs réels immédiatement. À lancer avant la revue, pas après : en revue, un défaut de contraste coûte un aller-retour.
Puis-je arrêter de tester sur de vrais appareils ?
Non. Un simulateur est exact sur la mise en page et aveugle au reste : performance réelle, rendu des polices, clavier virtuel masquant un champ, animation sur matériel faible. Gardez un téléphone Android bon marché sur le bureau.
Quelle est la façon la plus rapide de signaler un bug de mise en page ?
Capturez tous les appareils d’un coup et attachez les images à la carte de tâche. Quatre largeurs du même instant transforment « ça s’affiche mal sur mobile » en fait, et la carte est l’endroit où on ira chercher plus tard.
