Inspecter une page avec les DevTools

Le geste que vous allez refaire des milliers de fois

Un test automatisé ne voit pas une page web. Il ne voit pas un bouton bleu en haut à droite, ni un champ « Nom d’utilisateur » avec un liseré gris. Il reçoit une adresse — id="username", ou //button[@type='submit'] — et il va chercher, dans la structure de la page, l’élément qui correspond. S’il le trouve, le test continue. S’il ne le trouve pas, le test échoue, et l’application n’est pas forcément en cause : bien souvent, c’est l’adresse qui était mauvaise.

Tout le métier commence donc par un geste très concret : ouvrir la page, regarder comment elle est construite, et choisir une adresse qui tiendra dans le temps. C’est ce geste que vous allez faire maintenant.

Ce chapitre ne demande ni Java, ni Maven, ni Selenium, ni la moindre installation. Un navigateur et une connexion suffisent. Comptez une quinzaine de minutes, dont la moitié les mains sur le clavier.

Ce que vous saurez faire à la fin

• Ouvrir les outils de développement de votre navigateur et retrouver l’onglet qui affiche la structure de la page.
• Lire cette structure comme un arbre : parents, enfants, voisins.
• Pointer un élément à l’écran et faire apparaître, en un clic, le code qui le produit.
• Lire les attributs d’un élément et dire lesquels servent à l’identifier.
• Répondre à la seule question qui compte vraiment : lequel de ces attributs sera encore là dans six mois ?

Ce qu’il vous faut

Google Chrome, Microsoft Edge ou Mozilla Firefox, dans une version récente. Safari fonctionne aussi, moyennant une activation préalable décrite plus bas. Le vocabulaire et les raccourcis de ce chapitre suivent Chrome, qui est le navigateur utilisé dans la suite du parcours ; les équivalents Firefox sont indiqués quand ils diffèrent.

---

1. Ouvrir les outils de développement

Ouvrez d’abord la page sur laquelle nous allons travailler :

https://the-internet.herokuapp.com/login

C’est une application de démonstration publique, conçue pour l’apprentissage de l’automatisation. Elle est volontairement simple et sa structure évolue très peu — contrairement à une page d’accueil de moteur de recherche ou de site commercial, qui peut changer du jour au lendemain et faire échouer un exercice sans prévenir. C’est une règle de travail, pas une anecdote : on n’apprend pas les localisateurs sur un site que l’on ne contrôle pas.

Puis ouvrez les outils de développement — les « DevTools » :

Sous Safari, le menu développeur est masqué par défaut. Allez dans Safari → Réglages → Avancé (Safari → Préférences → Avancé sur les versions antérieures à macOS Ventura) et cochez la case qui active le menu Développement : selon la version de Safari, elle s’intitule « Afficher le menu Développement dans la barre des menus » ou « Afficher les fonctionnalités pour développeurs web ». Le raccourci fonctionne ensuite.

Il existe une troisième voie, qui marche partout et que vous utiliserez en réalité le plus souvent : clic droit sur un élément de la page → Inspecter.

Critère de réussite

Un panneau s’ouvre, à droite ou en bas de la fenêtre, avec une barre d’onglets. Le premier onglet s’appelle Elements (Chrome, Edge) ou Inspecteur (Firefox). Vous y voyez du code, avec de petits triangles à gauche des lignes. Si vous voyez cela, vous pouvez passer à la suite.

Quand ça rate

F12 ne fait rien. Sur beaucoup d’ordinateurs portables, la rangée de touches de fonction pilote par défaut le volume et la luminosité. Essayez Fn + F12, ou utilisez Ctrl + Maj + I, ou le clic droit.

Le menu du clic droit ne propose pas « Inspecter ». Certaines pages neutralisent le menu contextuel par script. Passez par le menu du navigateur : dans Chrome, ⋮ → Plus d’outils → Outils de développement.

Le panneau s’ouvre mais il est minuscule, ou dans une fenêtre séparée. Cliquez sur le ⋮ en haut à droite du panneau DevTools (pas celui du navigateur) et choisissez une position d’ancrage : à droite, en bas, ou détaché. Prenez « à droite » sur un grand écran, « en bas » sur un portable.

Rien ne s’ouvre, sur aucun raccourci, sur un poste d’entreprise. Les DevTools peuvent être désactivés par une stratégie d’administration. Pour le vérifier sans ambiguïté, ouvrez chrome://policy dans un onglet et cherchez une ligne DeveloperToolsAvailability. Si elle est présente et positionnée sur la valeur qui bloque, aucun raccourci n’y changera rien : il faut passer par votre service informatique, ou faire cet exercice sur une machine personnelle.

Les libellés sont en anglais alors que mon navigateur est en français. C’est normal et sans conséquence. Les DevTools ont leur propre réglage de langue, et la documentation du métier est très majoritairement en anglais. Habituez-vous à Elements, Console, Network : ce sont les mots que vous lirez partout.

---

2. Ce que vous regardez : un arbre, pas un fichier

Dans l’onglet Elements, dépliez les triangles jusqu’au formulaire. Vous devez arriver à ceci — c’est le code réel de la page :

<form name="login" id="login" action="/authenticate" method="post">
  <div class="row">
    <div class="large-6 small-12 columns">
      <label for="username">Username</label>
      <input type="text" name="username" id="username">
    </div>
  </div>
  <div class="row">
    <div class="large-6 small-12 columns">
      <label for="password">Password</label>
      <input type="password" name="password" id="password">
    </div>
  </div>
  <button class="radius" type="submit"><i class="fa fa-2x fa-sign-in"> Login</i></button>
</form>

Ce n’est pas un texte, c’est un arbre. Chaque balise est un nœud, et chaque nœud a une position dans une hiérarchie :

• Le <form> est le parent des deux <div class="row"> et du <button>.
• Le premier <input> est un descendant du <form>, mais pas son enfant direct : il y a deux <div> entre les deux.
• Le <label> et l’<input> du premier bloc sont frères : même parent, même niveau.
• Le <i> est un enfant du <button>.

Ce vocabulaire n’est pas décoratif. Quand vous écrirez des expressions XPath, dans un chapitre ultérieur, vous direz littéralement « l’input qui est un descendant du form », ou « le frère suivant du label ». Cette structure porte un nom : le DOM, pour Document Object Model. C’est la représentation de la page que le navigateur tient en mémoire, et c’est exactement ce que Selenium interroge.

Le piège qui coûte le plus de temps aux débutants

Le DOM n’est pas le fichier HTML envoyé par le serveur. Il en part, puis le JavaScript de la page le modifie — parfois un peu, parfois entièrement.

Faites la démonstration vous-même, elle prend trente secondes. Ouvrez un nouvel onglet sur :

view-source:https://www.saucedemo.com/

Vous lisez le fichier brut tel que le serveur l’a envoyé. Cherchez le formulaire de connexion. Il n’y est pas. Tout le <body> tient en deux lignes utiles, dont celle-ci :

<div id="root"></div>

Maintenant ouvrez https://www.saucedemo.com/ normalement, et inspectez le champ Username avec le clic droit. Vous y trouvez un formulaire complet, des dizaines d’éléments, des attributs. Rien de tout cela n’existait dans le fichier envoyé : c’est le JavaScript qui l’a construit dans le navigateur.

La règle qui en découle : ne cherchez jamais vos localisateurs dans le code source (Ctrl + U, Cmd + Option + U sous macOS). Cherchez-les toujours dans l’onglet Elements, qui affiche le DOM vivant. Sur une application qui construit son interface en JavaScript, le code source est souvent vide de tout ce qui vous intéresse.

---

3. Sélectionner un élément avec précision

Repartez sur https://the-internet.herokuapp.com/login.

Il y a un outil fait pour ça, et c’est celui que vous utiliserez tout le temps. En haut à gauche du panneau DevTools, la première icône représente un curseur dans un rectangle. Son raccourci dépend du navigateur :

Activez-la, puis promenez la souris sur la page. Chaque élément survolé se surligne, et une petite étiquette affiche sa balise et ses dimensions. Cliquez sur le champ Username : le panneau Elements saute directement sur la ligne correspondante et la met en surbrillance.

Regardez maintenant le bas du panneau Elements. Une ligne de fil d’Ariane affiche le chemin complet depuis la racine :

html  body  div.row  div#content  div.example  form#login  div.row  div.large-6.small-12.columns  input#username

Ce fil d’Ariane est un outil de navigation à part entière : cliquez sur form#login et vous sélectionnez le formulaire entier. C’est le moyen le plus rapide de « remonter » d’un élément vers son conteneur.

Quand ça rate

Le survol surligne le mauvais élément — vous visez le texte d’un bouton, c’est la <div> entière qui se surligne. Cliquez quand même, puis utilisez les flèches ↑ et ↓ du clavier dans l’arbre pour descendre nœud par nœud jusqu’au bon. La flèche → déplie un nœud, la flèche ← le replie.

L’élément disparaît dès que je bouge la souris. Certains éléments (menus déroulants, infobulles) ne sont là que tant que la souris est dessus. Cliquez d’abord une fois dans le panneau DevTools pour lui donner le focus clavier — sans ce focus, le raccourci qui suit ne fera rien. Placez ensuite la souris sur l’élément et pressez F8 : l’exécution de la page se met en pause et le menu reste ouvert. Pressez F8 à nouveau pour reprendre. Sur les pages de ce chapitre, vous n’en aurez pas besoin.

Je ne retrouve pas la ligne dans l’arbre, elle est noyée. Sélectionnez l’élément avec l’outil, puis faites un clic droit dessus dans l’arbre et choisissez Scroll into view (Firefox : Faire défiler jusqu’à cet élément), ou repliez les branches voisines avec ←.

---

4. Lire les attributs d’un élément

Sélectionnez le champ Username. Sa ligne est courte, et tout est dedans :

<input type="text" name="username" id="username">

Chaque paire nom="valeur" est un attribut. Voici ce que chacun vous dit :

Notez au passage que le <label> juste au-dessus porte for="username" : c’est lui qui relie le libellé affiché au champ. Cette liaison se fait par l’id. C’est déjà un indice sur la valeur de cet attribut.

Deux gestes utiles sur la ligne sélectionnée :

• Double-clic sur une valeur d’attribut : vous pouvez la modifier. La page se met à jour immédiatement. Rien n’est envoyé au serveur, et un simple F5 remet tout en ordre. C’est le bac à sable idéal pour comprendre ce qu’un attribut pilote réellement.
• Clic droit → Copy → Copy selector : le navigateur vous propose un sélecteur CSS pour cet élément. Ici, il produit #username. Retenez ce geste, nous allons nous en servir dans une seconde — et aussi nous en méfier.

---

5. La question qui compte : lequel tiendra six mois ?

Vous savez maintenant lire les attributs d’un élément. Il reste à choisir. Et c’est là que se joue la différence entre une suite de tests que l’équipe continue d’utiliser et une suite qu’elle finit par abandonner.

Le critère n’est pas « est-ce que ça marche aujourd’hui ». N’importe quel localisateur marche aujourd’hui : vous venez de le prendre sur la page. Le critère est : est-ce que cette valeur a une raison d’exister indépendamment de l’apparence de la page ?

L’échelle de stabilité

La démonstration du rang 6

Refaites un clic droit sur le champ Username dans l’arbre, mais choisissez cette fois Copy → Copy full XPath. Vous obtenez une expression de cette forme — les indices peuvent varier légèrement selon la version du navigateur :

/html/body/div[2]/div/div/form/div[1]/div/input

Lisez-la à voix haute : « le body, son deuxième div, son div, son div, le form, son premier div, son div, son input ». Cette expression ne contient pas une seule information sur ce qu’est cet élément. Elle décrit un itinéraire.

Maintenant, imaginez la modification la plus banale du monde : un développeur ajoute un bandeau d’information au-dessus du contenu. Une <div> de plus dans le <body>. div[2] désigne désormais autre chose, et ce localisateur pointe dans le vide — ou pire, sur le mauvais élément. Le test échoue, et l’application n’a pourtant aucun défaut.

Le même élément, adressé par #username, aurait survécu sans une ligne de code à modifier.

Retenez ceci : cette option est à un clic de souris — « Copy full XPath » dans Chrome et Edge, « Copier → XPath » dans Firefox — et c’est presque toujours le plus mauvais localisateur possible. Le fait qu’un outil vous propose quelque chose ne le rend pas correct.

Le piège du texte, en vrai

Sélectionnez maintenant le bouton Login. Vous lisez :

<button class="radius" type="submit"><i class="fa fa-2x fa-sign-in"> Login</i></button>

Trois observations, et chacune vous servira :

1. Ce bouton n’a ni id ni name. Cela arrive tout le temps. Il faut se rabattre sur autre chose : ici, button[type='submit'], qui est acceptable parce qu’il n’y a qu’un seul formulaire sur la page.
2. Le mot « Login » n’appartient pas au <button>. Il est à l’intérieur du <i>, l’élément qui porte l’icône. Un localisateur qui cherche un <button> dont le texte est exactement Login ne trouvera rien, alors que le mot est visible à l’écran. C’est une source d’incompréhension classique.
3. Il y a une espace avant le mot : <i ...> Login</i>. Une comparaison stricte sur "Login" échoue ; il faut normaliser les espaces. Vous verrez la fonction qui fait cela dans le chapitre consacré à XPath.

Rien de tout cela n’est deviné : vous venez de le lire dans le DOM. C’est précisément pour cette raison qu’on inspecte avant d’écrire, et jamais l’inverse.

---

6. Vérifier un localisateur sans écrire une ligne de code

Un localisateur qui désigne trois éléments au lieu d’un est un bug qui ne se déclenchera que le jour où l’ordre des éléments changera. Il faut donc toujours vérifier le nombre de correspondances. Deux méthodes, sans aucun outil supplémentaire à installer.

Méthode 1 — la recherche dans l’onglet Elements

Cliquez dans l’arbre, puis Ctrl + F (Cmd + F sous macOS). Un champ de recherche apparaît en bas du panneau. Il accepte du texte, mais aussi des sélecteurs CSS et des expressions XPath.

Tapez #username. Le compteur affiché à droite du champ doit indiquer une seule correspondance — il s’écrit 1/1 ou 1 of 1 selon la version des DevTools. Une seule correspondance : le localisateur est sans ambiguïté.

Tapez maintenant #login input. Le compteur passe à deux correspondances : les deux champs du formulaire. Les touches Entrée et Maj + Entrée font défiler les correspondances.

Méthode 2 — la console

Passez sur l’onglet Console et saisissez ces trois lignes, une par une, en validant à chaque fois :

document.querySelectorAll("#username").length;
document.querySelectorAll("#login input").length;
document.querySelectorAll("button[type='submit']").length;

Vous devez lire, dans l’ordre : 1, puis 2, puis 1. Cette méthode a un avantage sur la précédente : le nombre est sans équivoque, quelle que soit la version du navigateur.

Un dernier raccourci qui relie les deux panneaux : sélectionnez un élément dans Elements, revenez dans Console, tapez $0 et validez. La console vous renvoie l’élément que vous venez de sélectionner. C’est le moyen le plus rapide de passer de « je le vois » à « je peux l’interroger ».

Quand ça rate

La console refuse ce que je colle et affiche un avertissement. Chrome bloque le collage dans la console tant que vous n’avez pas tapé à la main, dans la console, la phrase allow pasting suivie d’Entrée. C’est une protection contre une arnaque courante. Faites-le une fois : vous n’aurez pas à le retaper à chaque collage.

J’obtiens 0 alors que je vois l’élément. Trois causes, dans l’ordre de fréquence : une faute de frappe dans le sélecteur ; vous êtes sur la mauvaise page ou le mauvais onglet ; l’élément est dans une iframe, et la console interroge par défaut le document principal. Ce dernier cas est traité plus loin dans le parcours.

J’obtiens un nombre supérieur à 1 pour un id. Cela signifie que la page contient un id en double. C’est invalide au sens de la norme HTML, et cela arrive en production. Dans ce cas, l’id n’est plus un localisateur fiable : il faut le combiner avec autre chose.

---

7. Exercice guidé

Comptez cinq minutes. Ne lisez la correction qu’après avoir rempli le tableau.

Page de travail : https://the-internet.herokuapp.com/login

1. Ouvrez les DevTools et activez l’outil de sélection (Ctrl + Maj + C sous Windows et Linux ; Cmd + Maj + C sous macOS avec Chrome ou Edge, Cmd + Option + C avec Firefox).
2. Inspectez successivement les trois éléments interactifs de la page : le champ Username, le champ Password, le bouton Login.
3. Pour chacun, relevez : la balise, l’id, le name, et la ou les classes.
4. Pour chacun, proposez le localisateur que vous utiliseriez, et vérifiez-le avec Ctrl + F dans l’onglet Elements.

Critère de réussite

Vous avez réussi si, et seulement si, ces cinq points sont vrais :

• Votre tableau indique que le bouton Login n’a ni id ni name, et que sa seule classe est radius.
• Vous avez remarqué que le texte « Login » est porté par un élément <i> enfant du bouton, et non par le bouton lui-même.
• Les recherches #username et #password donnent chacune une seule correspondance.
• La recherche button[type='submit'] donne une seule correspondance.
• Vous pouvez expliquer, en une phrase, pourquoi vous n’avez retenu radius pour aucun des trois.

Si vous voulez un chiffre à la place d’un compteur à interpréter, refaites la vérification dans la console avec document.querySelectorAll("…").length.

Correction

Sur le dernier point : radius est une classe de présentation — elle demande des coins arrondis. Elle peut être appliquée à n’importe quel autre bouton du site, et elle disparaîtra le jour où quelqu’un décidera que les boutons seront carrés. Elle ne dit rien de l’identité de cet élément.

Prolongement, deux minutes

Allez sur https://www.saucedemo.com/ et inspectez le champ Username. Vous y trouverez à la fois un id et un attribut data-test, et les deux valeurs ne sont pas identiques. Relevez-les.

Cette différence n’est pas un hasard : l’id est utilisé par le code de l’application, l’attribut data-test a été ajouté pour les tests, et c’est celui-là que vous choisiriez. Quand une application vous offre cet attribut, prenez-le : c’est un contrat explicite entre l’équipe de développement et vous.

---

Ce que ce chapitre ne couvre pas

Soyons précis sur les limites, pour que vous sachiez ce qu’il vous reste à apprendre :

• Écrire des expressions XPath et des sélecteurs CSS à la main. Ici, vous avez lu des attributs et vérifié des localisateurs simples. La syntaxe complète — axes, fonctions, conditions multiples — fait l’objet d’un chapitre dédié.
• Le code Selenium. Pas une ligne de Java dans ce chapitre. Les méthodes findElement et les classes By arrivent plus tard, une fois l’environnement installé.
• Les autres onglets des DevTools. Console n’a été utilisé que comme vérificateur ; Network, Sources, Performance et Application ne sont pas abordés.
• Les iframe et le Shadow DOM. Ce sont deux raisons fréquentes pour lesquelles un élément parfaitement visible reste introuvable. Ils demandent un traitement particulier, traité plus loin.
• Les éléments qui apparaissent après un délai. Inspecter une page statique et automatiser une page qui charge ses données en arrière-plan sont deux problèmes différents. Le second s’appelle la synchronisation, et c’est un sujet à lui seul.

À retenir

• L’onglet Elements affiche le DOM, c’est-à-dire la page telle que le navigateur la tient en mémoire. Le code source (Ctrl + U, Cmd + Option + U sous macOS) n’est pas le DOM et peut être quasiment vide.
• Le DOM est un arbre. Parent, enfant, frère : ce vocabulaire est celui que vous emploierez pour écrire vos localisateurs.
• L’outil de sélection (Ctrl + Maj + C, Cmd + Maj + C sous macOS avec Chrome ou Edge) pointe un élément à l’écran et le trouve dans l’arbre. C’est le geste de base.
• Un bon localisateur s’appuie sur une identité — data-test, id, name — et non sur une apparence ou une position.
• « Copy full XPath » est à un clic de souris, et c’est presque toujours le pire choix disponible.
• Un localisateur se vérifie : la recherche dans l’onglet Elements doit donner une seule correspondance. Si elle en donne plusieurs, le problème est déjà là, même si le test passe aujourd’hui.