Affichez le code source d’une page, puis passez aux DevTools pour voir le DOM réellement rendu, le CSS appliqué et les requêtes qui alimentent la page. Vous obtenez un diagnostic concret : ce que les moteurs voient, ce que le navigateur exécute et ce qui génère le contenu.
En Bref : En 5 minutes, vous affichez le code source (HTML), puis vous basculez sur les DevTools. Vous explorez le DOM, le CSS et le JavaScript, et vous reliez tout ça au rendu final (SEO, contenu dynamique, performance). Résultat : moins de suppositions, plus de preuves.
| Prérequis | Délai estimé | Niveau | Outils |
|---|---|---|---|
| Aucun | 5 à 12 minutes | Débutant à intermédiaire | Navigateur (Chrome/Edge/Firefox/Safari) + DevTools |
| Accès à une page publique | 2 minutes | Facile | Ordinateur ou mobile |
| Objectif clair | 30 secondes | — | SEO, performance, sécurité côté client |
Étape 1 : afficher le code source HTML avec le navigateur (ordinateur et mobile)
Ouvrez la page, puis utilisez le menu du navigateur : « Afficher le code source de la page » (souvent via clic droit) ou « Source de la page ». Sur mobile, l’option varie selon iOS/Android et le navigateur : cherchez une vue « source » ou un équivalent, puis comparez avec ce qui s’affiche réellement.
Sur ordinateur, le clic droit reste le raccourci le plus rapide. Vous repérez tout de suite les balises SEO comme <title> et <meta name= »description »>. Petit piège : « Inspecter » ne montre pas le HTML brut ; ça affiche le rendu via le DOM.
Sur mobile, certains navigateurs affichent un HTML simplifié, d’autres demandent une action spécifique (par exemple une option « Source » dans un menu). Rechargez la page, puis vérifiez que les titres et le texte visibles sont bien présents dans la vue source. (Oui, ça arrive : la page change et la source ne correspond plus.)
Astuce anti-galère : si la page charge du contenu après coup (chargement dynamique), la vue « code source » peut sembler incomplète. Dans ce cas, passez directement aux DevTools (DOM), plus bas.
Étape 2 : ouvrir les DevTools pour explorer DOM, CSS et JavaScript
Les DevTools servent à dépasser le HTML brut : vous inspectez le DOM, vous voyez les règles CSS appliquées, et vous suivez l’exécution JavaScript. Ouvrez « Éléments » pour le DOM, « Styles » pour le CSS, et « Console » pour les erreurs. Pour aller plus vite, ajoutez « Réseau » : c’est là que les requêtes se révèlent.
Comment éviter de vous tromper entre ce que vous lisez et ce que l’utilisateur voit ? Regardez le DOM. C’est la structure réellement construite en mémoire après chargement et scripts. Dans Chrome/Edge, vous retrouvez généralement « Éléments », « Styles », « Console » et « Réseau » : parfait pour diagnostiquer vite.
Premier réflexe : ouvrez « Éléments », puis cliquez sur une zone de la page (pointeur d’inspection). Vous voyez la balise correspondante, ses classes, et parfois les attributs qui pilotent l’affichage. Deuxième réflexe : ouvrez « Styles » pour vérifier quelle règle gagne vraiment. (C’est souvent là que tout se joue.)
Troisième réflexe : la « Console ». Les erreurs JavaScript apparaissent pendant le chargement. Si vous voyez des 404, des erreurs CORS ou des exceptions liées à un script, vous tenez une cause probable d’un contenu « manquant ».
Étape 3 : comprendre la structure du code (balises, head, body, ressources)
Dans le HTML, le contenu principal se trouve dans <body>. Les métadonnées sont dans <head> : titres, description, liens, scripts. Repérez aussi les ressources : feuilles de style (<link>), scripts (<script>), images et polices. Cette lecture relie chaque élément visible à sa source.
Beaucoup regardent uniquement le corps de page. Pourtant, pour le SEO et la performance, <head> est souvent le cockpit : c’est là que se trouvent les signaux d’indexation et de chargement. Dans la plupart des pages, les balises les plus utiles sont <title> et <meta name= »description »>.
Puis, identifiez les ressources. Les feuilles de style passent par <link> (CSS), les scripts par <script> (JS). Sur les sites modernes, vous verrez parfois plusieurs fichiers, parfois regroupés en « bundles » : un gros fichier JS, puis des composants chargés côté application.
Côté <body>, cherchez les conteneurs qui portent le contenu. Sur une page classique, vous voyez le texte et les éléments HTML. Sur une page dynamique (SPA/SSR), vous pouvez voir un squelette, puis le contenu complet arrive après exécution de scripts. C’est exactement pour ça que l’étape suivante (SEO via DOM) compte autant.
et surlignées, un bloc texte autour des balises title et meta description, mains d’une personne tenant une souris, ambiance bureau, lumière douce, focus sur la syntaxe, rendu photoréaliste »>Piège à éviter : chercher un titre ou une description dans le <body>. Sur beaucoup de templates, ces éléments sont exclusivement dans <head>.
Étape 4 : utiliser le code source pour analyser le SEO et le maillage
Le code source sert à vérifier ce que les moteurs peuvent lire : <title>, meta description, headings (H1-H6), attributs d’images (alt) et liens internes (href). En DevTools, inspectez aussi le DOM pour repérer les contenus injectés par JavaScript. Vous identifiez alors oublis, duplications et incohérences.
Commencez par une checklist « SEO rapide » dans le HTML. Contrôlez <title> (présent, unique, cohérent) et la meta description. Ensuite, vérifiez la hiérarchie : un seul H1, puis des H2/H3 qui décrivent vraiment la page.
Regardez les images. Les attributs alt ne sont pas qu’une formalité : ils aident l’accessibilité et donnent un contexte utile aux moteurs. Côté liens, inspectez les href : liens internes, ancres trop génériques, et liens cassés.
Le point qui change tout sur les sites modernes : comparez le HTML initial et le DOM rendu. Sur des pages très dynamiques, le contenu peut être dans le DOM alors qu’il n’apparaît pas dans le HTML brut. Les moteurs peuvent indexer le rendu, mais la cohérence reste votre garde-fou : titre, headings et textes doivent correspondre au final.
Astuce : si un texte apparaît après interaction (onglet, filtre, chargement progressif), ouvrez DevTools et observez quand le DOM se met à jour. Si les headings changent, votre stratégie SEO doit suivre ce comportement.
Pour cadrer l’indexation et le rendu côté Google : Aide Google Search Console : comprendre l'exploration et le rendu.
Étape 5 : lire le JavaScript et repérer ce qui génère le contenu
Pour comprendre d’où vient un élément, cherchez les scripts et événements associés, puis utilisez DevTools : « Sources » pour naviguer dans les fichiers, « Réseau » pour voir les requêtes, et « Éléments » pour suivre les changements du DOM. Si un contenu apparaît après chargement, il est très souvent généré via JavaScript ou via des appels API.
Procédez en « chaîne de causalité ». D’abord, repérez les fichiers JavaScript chargés : dans le HTML ou via DevTools, identifiez les scripts et leur ordre. Ensuite, ouvrez « Réseau » et rechargez : vous verrez les requêtes (souvent des appels API ou des fichiers JSON) qui alimentent l’interface.
Le piège, c’est de lire du code sans le relier à un événement. Ici, vous reliez : quand un élément apparaît dans « Éléments » (DOM), vous cherchez la requête associée dans « Réseau ». Souvent, vous tombez sur l’endpoint qui alimente la page (ou au moins un point d’entrée).
Sur les sites SPA/SSR, le contenu est assemblé après chargement : un squelette initial est rendu, puis React/Vue/Angular (ou un framework custom) reconstruit la page. Résultat : le « code source page web » peut sembler « vide ». Le vrai contenu vit dans le DOM et dans les réponses API.
Pour mieux gérer la compatibilité (utile quand JavaScript se comporte différemment selon le navigateur), cette référence aide : Introduction aux tests multi-navigateurs (MDN).
Étape 6 : vérifier performances, erreurs et sécurité côté client
Après avoir lu le code, vous pouvez l’utiliser pour diagnostiquer : erreurs dans la Console, ressources bloquées, scripts non chargés et temps de chargement. Dans DevTools, « Performance » et « Réseau » mettent en évidence les goulots (CSS/JS trop lourds, requêtes lentes). Côté sécurité, surveillez aussi les comportements suspects : redirections, scripts externes inattendus.
Workflow simple : lancez un profilage rapide, puis cherchez la cause. Dans DevTools, ouvrez « Réseau » et relancez (reload). Les statuts 404/500, les erreurs CORS et les ressources bloquées ressortent vite.
Passez ensuite à « Performance ». Repérez les segments longs : main thread saturé, gros scripts, recalculs CSS. Si vous voyez un pic au moment où une section apparaît, vous tenez un indice clair : ce n’est pas « le site est lent », c’est « ce composant déclenche ce coût ».
Côté sécurité côté client, gardez un œil sur les scripts externes non prévus, les redirections et les comportements bizarres (popups, chargements de domaines non attendus). Ce n’est pas un audit complet, mais c’est une détection rapide de signaux d’alerte.
Pour la conformité si vous touchez à l’accessibilité et aux données : une base CNIL aide à cadrer vos obligations RGPD selon les traitements. Démarrez ici : CNIL : informations RGPD et bonnes pratiques. Pour l’accessibilité, MDN fournit un repère : Qu'est-ce que l'accessibilité (MDN).
Piège à éviter : optimiser « au hasard » après avoir repéré un seul fichier lourd. Formulez une hypothèse, vérifiez dans « Performance », puis testez une modification et mesurez à nouveau.
Résultat et prochaines étapes
Vous passez du « je regarde le code » à un mini-système d’analyse : HTML pour repérer les signaux, DevTools pour comprendre le rendu réel, Network pour trouver les sources de données, et Performance/Console pour valider la stabilité. C’est là que l’analyse devient actionnable.
Prochaines étapes : choisissez 1 page cible, faites un relevé rapide (title, H1, meta description, liens internes, alt, erreurs console, requêtes API). Puis comparez avec vos objectifs : SEO (structure et cohérence), conversion (composants qui chargent), ou performance (goulots). Si vous voulez aller plus loin côté automatisation IA, vous pouvez ensuite structurer ces observations pour alimenter un workflow (contrôle qualité avant déploiement, alertes sur titres dupliqués, détection de contenu manquant dans le DOM).
FAQ
Comment afficher le code source d'une page web sur Chrome, sans installer d'extension ?
Sur Chrome, ouvrez la page, puis cliquez droit et choisissez « Afficher le code source de la page ». Pour aller plus loin, ouvrez DevTools (Ctrl+Maj+I ou Cmd+Option+I sur Mac), puis utilisez l'onglet « Éléments » pour voir le DOM.
Quel est la différence entre code source HTML et DOM dans les outils de développement ?
Le code source HTML correspond au contenu HTML brut envoyé par le serveur. Le DOM est la structure construite après chargement et exécution des scripts (et peut donc inclure du contenu injecté dynamiquement). Sur une page JavaScript, le DOM reflète souvent ce que vous voyez à l'écran.
Pourquoi le code source affiché ne correspond-il pas à ce que je vois à l'écran ?
Parce que le contenu peut être généré ou modifié après chargement via JavaScript, des appels API, ou un rendu côté client. Dans ce cas, le HTML brut paraît incomplet, tandis que le DOM (dans DevTools) montre la version finale rendue.
Comment voir le JavaScript qui génère un élément sur une page dynamique ?
Ouvrez DevTools, puis utilisez « Réseau » pour repérer les requêtes qui alimentent la page. Ensuite, dans « Sources », cherchez les fichiers JS chargés, et dans « Éléments », suivez le changement du DOM quand l'élément apparaît.
Quel navigateur fonctionne le mieux pour consulter le code source sur mobile (iOS/Android) ?
Il n'y a pas un seul « meilleur » partout. Sur iOS, Safari est souvent le plus fiable pour accéder à une vue de source et pour l'inspection. Sur Android, Chrome fonctionne généralement bien. Le critère principal : la disponibilité d'une vue source correcte ou d'outils d'inspection utilisables.
Est-ce légal d'afficher et d'analyser le code source d'une page web publique ?
En général, consulter le code source d'une page publique est une pratique courante. Le point clé est de respecter les conditions d'utilisation du site et d'éviter une extraction abusive (scraping massif, contournement, etc.). Pour des cas sensibles (données personnelles), vérifiez aussi le cadre RGPD.
L'essentiel à retenir
- Commencez par la source HTML pour repérer rapidement balises, métadonnées et ressources.
- Passez aux DevTools pour analyser le DOM rendu, le CSS appliqué et les erreurs JavaScript.
- Reliez <head> aux signaux SEO et <body> au contenu effectivement affiché.
- Sur pages dynamiques, comparez HTML initial et DOM après rendu.
- Utilisez Network pour retrouver les appels API et comprendre d'où vient le contenu.
- Contrôlez performances et stabilité via Console, Réseau et Performance avant toute optimisation.
- Sur mobile, adaptez la méthode selon le navigateur : privilégiez une source fiable ou DevTools quand c’est possible.
Une seule idée à garder : un bon code source page web n’est pas juste à lire. C’est un point de départ pour vérifier SEO, performance et génération du contenu, puis agir avec méthode.
