En quelques étapes, vous pouvez apprendre comment voir le code source d une page web et surtout comprendre ce que le navigateur affiche vraiment. Le raccourci montre le HTML “tel que reçu”, puis les DevTools (Éléments, Réseau, Sources) révèlent le DOM, les styles et les requêtes. Sur une page moderne, c’est souvent la différence entre “ce qui est envoyé” et “ce qui s’affiche”.
En Bref : commencez par Ctrl+U (Windows) ou Cmd+Option+U / Cmd+U (Mac) pour voir le HTML initial. Ensuite, ouvrez DevTools afin d’inspecter le DOM rendu (Éléments) et les ressources (Réseau). Vous identifiez plus vite d’où viennent les éléments visibles, y compris sur les pages dynamiques.
| Durée estimée | 10 à 20 minutes |
|---|---|
| Niveau | Débutant à intermédiaire |
| Outils nécessaires | Navigateur (Chrome/Firefox/Safari/Edge) + DevTools |
| Résultat attendu | HTML initial + DOM rendu + scripts/ressources responsables |
Étape 1 : ouvrir le code source via le raccourci navigateur (Ctrl+U / Cmd+Option+U)
Pour afficher le code source d’une page, utilisez le raccourci du navigateur : sous Windows, Ctrl+U ; sur Mac, Cmd+Option+U (souvent) ou Cmd+U selon le navigateur. Le HTML s’ouvre alors dans un nouvel onglet ou une fenêtre, avec le contenu “tel que reçu”. C’est pratique pour repérer la structure avant de passer aux outils de développement.
-
Choisissez le bon raccourci
- Windows : Ctrl+U est le raccourci le plus courant.
- macOS : Cmd+Option+U est souvent utilisé dans les navigateurs majeurs ; sinon Cmd+U peut fonctionner.
-
Comprenez ce que vous voyez
Le “code source” affiché correspond généralement au HTML initial envoyé par le serveur, avant l’exécution des scripts. Sur une page moderne, le contenu visible peut ensuite être modifié par JavaScript. Et c’est là que les surprises commencent…
-
Repérez l’architecture rapidement
- Les balises (ex.
<html>,<head>,<body>). - Les liens (CSS, favicons, préchargements).
- Les scripts (fichiers JS, bundles, scripts en ligne).
- Les métadonnées (title, description, Open Graph, robots).
- Les balises (ex.
Astuce “piège” : ne cherchez pas directement dans ce HTML ce que vous voyez à l’écran si la page est très dynamique. Pour ça, passez à l’inspecteur.
Étape 2 : basculer vers l’inspecteur (DevTools) pour voir le HTML rendu et les styles
Le raccourci affiche surtout le HTML brut. Pour comprendre ce qui est réellement rendu, ouvrez les Outils de développement (DevTools), puis l’onglet Éléments/Inspector. Vous pouvez parcourir le DOM, inspecter les nœuds et vérifier les styles calculés (CSS) appliqués à chaque élément. C’est la méthode la plus fiable pour analyser l’affichage réel.
-
Ouvrez DevTools
- Dans Chrome/Edge : clic droit sur la page > Inspecter.
- Dans Firefox : clic droit > Inspecter l’élément.
- Dans Safari : menu Développement > Afficher la console / Inspecteur (selon configuration).
-
Allez dans l’onglet Éléments
Vous verrez le DOM, c’est-à-dire la représentation structurée de la page telle qu’elle existe dans le navigateur au moment où vous inspectez.
-
Inspectez un élément précis
- Utilisez le sélecteur (icône “curseur”) pour pointer un bouton, un titre, un bloc.
- Dans le panneau, repérez l’élément et ses attributs (class, id, data-*, href, etc.).
-
Vérifiez les styles calculés
Dans DevTools, cherchez la zone “Styles” ou “Calculé”. Vous saurez quel CSS s’applique vraiment (et depuis quel fichier/ligne quand l’info est disponible).
-
Remontez l’arborescence DOM
En parcourant les parents (div > section > main, etc.), vous identifiez souvent la classe qui pilote la mise en forme. (C’est souvent là que le diagnostic se débloque.)
Astuce : si certains éléments ne s’affichent pas, attendez un peu ou rechargez en gardant DevTools ouvert. Certaines pages modifient le DOM après le chargement initial.
Étape 3 : analyser le JavaScript (Sources/Network) pour comprendre le chargement
Pour aller plus loin que le HTML/CSS, ouvrez l’onglet Sources dans DevTools pour parcourir les fichiers JavaScript chargés, et l’onglet Réseau (Network) pour voir quelles ressources sont appelées, quand, et depuis quelles URLs. Vous pouvez filtrer par “JS” ou “XHR/fetch” et repérer les scripts responsables d’un comportement (bouton, formulaire, rendu dynamique). Une question simple à se poser : “quand est-ce que ça apparaît, exactement ?”
-
Utilisez Réseau (Network)
- Ouvrez l’onglet Network.
- Rechargez la page (ou déclenchez l’action) pour capturer les requêtes.
- Filtrez : JS, XHR, fetch, ou “document” selon les navigateurs.
-
Reliez un comportement à un appel
Quand un bouton change l’affichage, cherchez dans Network une requête qui apparaît au même moment. Vous obtenez alors l’URL, le type de requête, et souvent un aperçu de la réponse. De quoi comprendre d’où vient le contenu.
-
Ouvrez Sources pour inspecter les scripts
Dans Sources, explorez les fichiers réellement chargés. Sur les sites avec bundles, repérez les modules et fonctions liés aux événements (clics, soumissions) ou au rendu (templates, composants).
-
Gardez une logique de diagnostic
- “Je vois un élément” → “Dans le DOM, il est généré par…”
- “Il apparaît après coup” → “Network montre une requête tardive”
- “Il a un style étrange” → “CSS calculé pointe vers une règle spécifique”
Astuce “ce qui change vraiment” : sur les pages construites avec des frameworks, le contenu peut être rendu côté navigateur. Le HTML initial peut être “vide” ou minimal, puis enrichi par JavaScript.
Étape 4 : vérifier les différences entre “Afficher le code source” et “Voir le code” d’une page
Selon le navigateur, “Afficher le code source” montre le HTML initial, tandis que l’inspecteur affiche le DOM après exécution des scripts. Résultat : certains éléments peuvent ne pas apparaître dans la source, mais être visibles dans le rendu. Pour confirmer, comparez le HTML de Ctrl+U/Cmd+U avec le DOM dans DevTools et observez ce que JavaScript ajoute ou modifie.
-
Faites une comparaison rapide
Ouvrez le code source (Ctrl+U/Cmd+Option+U), puis revenez à DevTools > Éléments. Repérez un élément visible à l’écran (un bloc de texte, un produit, un composant).
-
Vérifiez si l’élément existe dans le HTML initial
Si l’élément n’apparaît pas dans le HTML “tel que reçu”, il est probablement généré après chargement (rendu côté client).
-
Confirmez via DevTools
- Dans Éléments, observez la structure DOM et les classes.
- Dans Network, cherchez les appels qui alimentent ce rendu.
- Dans Sources, identifiez les scripts impliqués.
-
Comprenez la cause la plus fréquente
Les frameworks et CMS modernes peuvent modifier le DOM après chargement. La source reflète l’état “avant” exécution, le DOM reflète l’état “après”.
Piège : confondre “je ne le vois pas dans Ctrl+U” avec “il n’existe pas”. Sur une page dynamique, l’élément peut être présent uniquement dans le DOM rendu.
Étape 5 : résoudre les cas fréquents (pages protégées, contenus dynamiques, CSP)
Si vous ne voyez pas le code attendu, plusieurs causes reviennent souvent : contenu injecté après chargement, scripts chargés tardivement, ou restrictions de sécurité (CSP) qui limitent certains accès. Commencez par l’onglet Réseau pour repérer les requêtes et le moment du chargement. Ensuite, inspectez les éléments générés dans DevTools. En cas d’erreur, testez un autre navigateur.
-
Cas 1 : contenu injecté après chargement
Dans DevTools > Éléments, cherchez si l’élément apparaît après une action (scroll, clic, saisie). Dans Network, repérez une requête qui arrive après le chargement initial.
-
Cas 2 : scripts chargés tardivement
Filtrez Network par JS et observez les timings. Un script “de plus” peut être chargé plus tard pour activer une fonctionnalité.
-
Cas 3 : politique de sécurité (CSP)
Si vous voyez des messages d’erreur liés au chargement de scripts/ressources, la CSP peut empêcher certaines opérations. (Ce n’est pas un bug de votre navigateur.)
Référence : documentation CSP sur MDN.
-
Cas 4 : pages protégées ou sans autorisation
Sur des pages derrière authentification, le code source peut être minimal ou tronqué selon votre session. Si l’accès nécessite des droits, le navigateur ne vous montrera pas le contenu que vous n’avez pas le droit de voir.
-
Test multi-navigateurs
Si le rendu diffère, testez un autre navigateur. Les comportements peuvent varier (gestion du cache, politiques, compatibilité DevTools).
Astuce : gardez DevTools ouvert et “rejouez” l’action utilisateur. Vous verrez mieux quel moment déclenche la génération du contenu.
Étape 6 : utiliser le “copier” et la lecture structurée (balises, sections, ressources) pour diagnostiquer
Une fois le code affiché, copiez-le et lisez-le par blocs : balises <head> (métadonnées, CSS, scripts), <body> (structure), puis les ressources (liens, fichiers JS/CSS). Dans DevTools, vous pouvez aussi “copier l’élément” pour obtenir le HTML correspondant à un nœud précis. Résultat : diagnostic SEO/UX plus rapide, repérage des scripts manquants, des assets non chargés et des erreurs de rendu.
-
Lisez d’abord le
<head>- Métadonnées :
<title>,meta(description, robots, Open Graph). - Ressources :
<link>(CSS, préchargements),<script>(JS).
- Métadonnées :
-
Passez au
<body>Repérez la structure : sections, conteneurs, composants. Sur une page dynamique, vous verrez souvent des conteneurs “racine” qui seront remplis ensuite.
-
Copiez un élément précis depuis DevTools
Dans l’onglet Éléments, sélectionnez un nœud, puis utilisez l’option “Copier” (souvent “Copier l’élément”). Vous récupérez un HTML ciblé, plus facile à analyser qu’un fichier entier.
-
Recoupez avec Network
Si un style ou une fonctionnalité manque, vérifiez dans Network si les fichiers CSS/JS correspondants se chargent réellement (statut 200, absence de 404, absence de blocage).
-
Approche utile pour le SEO et l’UX
- Scripts manquants : tracking, rendu, composants.
- Assets non chargés : polices, images, CSS critique.
- Différences d’affichage : contenu généré côté client.
À retenir : au lieu de tout lire, isolez le nœud ou la ressource qui explique le problème. C’est plus rapide et plus fiable.
Résultat et prochaines étapes
À la fin, vous saurez distinguer HTML initial, DOM rendu et ressources réellement chargées. C’est le socle pour diagnostiquer un rendu qui “ne correspond pas”, comprendre un composant qui s’affiche tard, ou identifier un script responsable d’un comportement. Ensuite, affinez votre méthode : repérez d’abord le composant dans DevTools, puis cherchez la requête Network associée.
Pour tester la compatibilité et éviter les surprises entre navigateurs, vous pouvez aussi consulter ce guide MDN sur le test multi-navigateurs et la vue d’ensemble des DevTools sur Chrome DevTools.
FAQ
Comment afficher le code source d’une page web sur Windows avec le navigateur ?
Sur Windows, ouvrez la page dans votre navigateur puis utilisez le raccourci Ctrl+U. Le navigateur affiche généralement le HTML initial dans un nouvel onglet ou une fenêtre. Pour voir ce qui est réellement rendu, passez ensuite à DevTools (Éléments) et comparez le DOM.
Quel raccourci utiliser sur Mac pour voir le code source d’une page web ?
Sur macOS, essayez Cmd+Option+U (souvent pris en charge par les navigateurs majeurs). Si ce raccourci ne fonctionne pas, testez Cmd+U selon le navigateur. Comme sur Windows, le code affiché correspond le plus souvent au HTML initial avant exécution des scripts.
Comment voir le HTML rendu d’une page et pas seulement le code source brut ?
Ouvrez DevTools puis l’onglet Éléments/Inspector. Vous verrez le DOM tel qu’il est construit dans le navigateur après exécution du JavaScript. Vous pouvez inspecter un nœud précis et vérifier les styles calculés pour comprendre l’affichage réel.
Pourquoi le code source (Ctrl+U) ne correspond pas à ce que je vois à l’écran ?
Parce que Ctrl+U montre le HTML initial, avant que les scripts ne modifient la page. Sur les sites dynamiques, le contenu peut être généré ou transformé côté client : le DOM dans DevTools reflète l’état final que vous voyez à l’écran.
Comment voir les fichiers JavaScript réellement chargés par une page ?
Dans DevTools, ouvrez l’onglet Réseau (Network) puis rechargez la page. Filtrez par JS ou observez les requêtes XHR/fetch. Vous verrez quelles ressources sont réellement chargées, avec leurs timings et leurs URLs.
Est-ce que je peux voir le code source d’une page protégée ou sans autorisation ?
Vous pouvez afficher le HTML que votre navigateur reçoit avec votre session. Si la page est protégée et que vous n’avez pas les droits, le contenu peut être remplacé par une page d’accès ou un rendu partiel. Le navigateur ne peut pas afficher des éléments que le serveur ne vous envoie pas.
L’essentiel à retenir
- Commencez par Ctrl+U (Windows) ou Cmd+Option+U/Cmd+U (Mac) pour voir le HTML initial.
- Passez à DevTools (Éléments) pour inspecter le DOM réellement rendu et les styles calculés.
- Utilisez Réseau (Network) et Sources pour comprendre quelles ressources et scripts sont chargés.
- Comparez “code source” vs “DOM rendu” : c’est souvent la raison des différences sur les pages dynamiques.
- En cas d’éléments manquants, vérifiez d’abord Network (chargement tardif) puis les politiques comme CSP.
- Copiez un élément précis depuis DevTools pour diagnostiquer plus vite qu’en parcourant tout le fichier.
- Testez sur plusieurs navigateurs si le rendu ou l’accès au code diffère.
Si vous cherchez comment voir le code source d une page web pour diagnostiquer un affichage incomplet, gardez cette séquence : Ctrl+U/Cmd+U pour le point de départ, DevTools pour le rendu, puis Network/Sources pour remonter à la cause. C’est la méthode la plus directe “pour décider vite”.
Ressources utiles
Pour approfondir la sécurité côté navigateur, voir CSP sur MDN. Pour mieux comprendre les DevTools, consultez l’aperçu officiel de Chrome DevTools. Pour une approche plus large du test, utilisez le guide MDN sur le test multi-navigateurs. (Et si votre objectif touche l’accessibilité, cette ressource peut aussi aider : définition d’accessibilité sur MDN.)
