Comment inspecter un élément sur un Mac, dans Chrome et dans Safari

Quelqu’un vous a probablement déjà demandé d’“ouvrir l’inspecteur et de dire ce que raconte la console”. Voici comment faire sur un Mac, dans les deux navigateurs - et Safari demande d’abord d’activer un réglage, ce qui explique pourquoi la question est posée deux fois.

Chrome

Trois façons, et la première est celle à retenir.

• Clic droit sur ce qui a l’air cassé, puis Inspecter. Le panneau s’ouvre avec cet élément déjà sélectionné, et c’est tout l’intérêt : vous posiez une question sur ce bouton, pas sur la page.
• ⌥⌘I ouvre le panneau où que vous soyez.
• ⌥⌘J l’ouvre directement sur l’onglet Console, ce que veut généralement dire quelqu’un qui demande “regarde s’il y a des erreurs”.

Le panneau s’ouvre à côté de la page ou en dessous. Tirez sur son bord s’il est trop étroit, et servez-vous du menu à trois points en haut à droite pour le déplacer en bas, ce qui est plus confortable sur un écran de portable.

Safari

Safari cache tout cela jusqu’à ce qu’on le demande, et c’est cette étape que les gens sautent.

1. Ouvrez Safari → Réglages (⌘ virgule).
2. Choisissez l’onglet Avancés.
3. Cochez Afficher les fonctionnalités pour développeurs web.

Un menu Développement apparaît dans la barre des menus, et seulement là le reste fonctionne :

• Clic droit → Inspecter l’élément sur n’importe quelle partie de la page.
• ⌥⌘I ouvre l’inspecteur web.
• ⌥⌘C l’ouvre directement sur la console.

Sur les versions plus anciennes de macOS, la case s’appelle “Afficher le menu Développement dans la barre des menus”, au même endroit. Si vous ne trouvez ni l’une ni l’autre, vous regardez les réglages d’une autre application - Safari doit être la fenêtre au premier plan.

Lire la console, ce qu’on vous demandait probablement

La console est l’onglet qui répond à “est-ce que quelque chose est cassé”. Elle contient les messages que la page a écrits pendant que vous l’utilisiez, et ils se rangent en trois catégories qu’il vaut la peine de distinguer.

Généralement pas le problème

Les avertissements en jaune, et les messages venant de l'analytique, des widgets de chat, des scripts publicitaires ou des extensions du navigateur. Longs, bruyants, et pour l'essentiel ceux de quelqu'un d'autre

À signaler

Les erreurs en rouge, et surtout la première. Une erreur qui mentionne un fichier venant de l'adresse du site lui-même a bien plus de chances d'être le bug que les douze qui nomment un tiers

Deux remarques pratiques. Les erreurs sont souvent déjà là avant que vous ne fassiez quoi que ce soit, restes du chargement, donc rechargez la page puis faites la chose qui échoue : l’erreur que vous cherchez est celle qui apparaît au moment où ça casse. Et la console a un champ de filtre : taper un bout de mot ramène cent lignes à celle dont vous avez besoin.

Pour transmettre une erreur, faites un clic droit sur la ligne rouge et copiez-la, ou sélectionnez-la et appuyez sur ⌘C. Une capture d’écran fait l’affaire aussi, tant que la ligne entière est visible.

L’onglet Réseau, pour quand rien ne charge

Si la page a l’air vide plutôt que cassée, la console ne dira peut-être rien et l’onglet Réseau dira tout. Ouvrez-le, rechargez, et regardez la colonne Statut : les nombres en 400 et en 500 sont des requêtes qui ont échoué, et l’URL à côté dit ce que la page essayait d’aller chercher. C’est la différence entre “le site est cassé” et “une requête vers une adresse est revenue en 503”.

Inspecter une page qui est sur votre iPhone

Pas sur le téléphone. L’inspecteur web de Safari tourne sur le Mac et se rattache au téléphone par un câble : activez l’inspecteur web sur le téléphone dans Réglages → Apps → Safari → Avancé, branchez-le, et l’appareil apparaît dans le menu Développement du Mac. La procédure complète, et quoi faire sans Mac, fait l’objet d’un article à part.

C’est le bon outil pour un bug qui n’arrive que sur mobile et le mauvais pour quelqu’un qui n’est pas assis à côté d’un Mac, c’est-à-dire la plupart des gens qui viennent de tomber sur un bug qui n’arrive que sur mobile.

Si c’est vous qui demandez cela à quelqu’un d’autre

Cela mérite d’être dit franchement, parce que cet article existe surtout parce que cette demande est faite.

Demander à un collègue, à un testeur ou à un client d’ouvrir les outils de développement, de trouver le bon onglet, de juger quelles lignes rouges comptent et de les copier fidèlement, c’est demander plusieurs compétences à la fois. La plupart des gens enverront la première ligne rouge qu’ils voient, qui est le plus souvent un avertissement d’analytique, et l’échange coûte deux messages et une journée.

L’instruction qui marche, si vous devez demander : rechargez, faites la chose qui casse, ouvrez la console avec ⌥⌘J, et envoyez-moi tout ce qui est en rouge. Précise, et elle met le jugement de votre côté plutôt que du leur.

L’autre solution est de ne pas demander. Si la moitié technique d’un rapport peut être capturée par la personne qui appuie sur un bouton, alors savoir où vit la console cesse d’être un préalable pour signaler un bug - et le rapport de bug arrive avec ce qui s’est passé, ce qui était attendu, et les journaux console et réseau déjà joints.

Aide-mémoire

• Chrome : clic droit → Inspecter, ou ⌥⌘I, ou ⌥⌘J pour la console.
• Safari : Réglages → Avancés → Afficher les fonctionnalités pour développeurs web, puis ⌥⌘I ou ⌥⌘C.
• Rechargez avant de reproduire, pour que les erreurs que vous voyez appartiennent à la panne.
• Les lignes rouges qui mentionnent l’adresse du site lui-même comptent le plus ; la première compte plus que les autres.