Parcours d’apprentissage web – Part II : HTML, structure et contenus
Cet article s’inscrit dans la série Parcours d’apprentissage web. Nous entrons ici dans la seconde partie, consacrée au HTML, à la structure et aux contenus. Après avoir préparé l’environnement de travail et d’apprentissage et posé une méthode, nous abordons maintenant le langage qui constitue la base de toute page web.
Le HTML. Le HTML est un langage à balises qui permet de découper le contenu et de lui donner un sens. Un titre, un paragraphe, une image ou une navigation ne sont pas seulement affichés, ils sont identifiés. Cette identification permet au navigateur de comprendre la structure de la page, et aux autres systèmes de l’interpréter. C’est sur cette base que nous pouvons maintenant observer comment un document HTML s’organise concrètement.
Introduction, apprendre le HTML sans se perdre
Cet article n’a pas pour objectif d’enseigner le HTML au sens classique du terme. De nombreux sites le font déjà très bien, en présentant les balises une à une, avec leurs attributs et leurs usages. Ces ressources sont indispensables, et nous allons nous y appuyer, notamment la documentation MDN et la spécification officielle maintenue par le WHATWG. Mais notre objectif ici est différent. Il consiste à apprendre comment apprendre le HTML, quoi regarder en priorité, quoi ne pas négliger, et comment organiser cette découverte.
Apprendre le HTML ne consiste pas à mémoriser une liste de balises. Il s’agit de comprendre une logique de construction. Une page repose sur une structure, une hiérarchie, une architecture. Certains éléments contiennent, d’autres sont contenus. Certains décrivent, d’autres précisent. Cette organisation constitue la base sur laquelle tout le reste viendra se poser, et d’autres dimensions viennent déjà s’y rattacher.
Les métadonnées décrivent la page sans être visibles, et les attributs aria en garantissent l’accessibilité. Nous reviendrons plus loin sur ces aspects dans le chapitre « Donner du sens, accessibilité et attributs ARIA », où leur rôle sera abordé plus concrètement.
Il est également important de voir que le HTML n’est pas isolé. Depuis l’introduction de HTML5, en 2008, le navigateur n’est plus seulement un outil de consultation, mais un véritable environnement applicatif. Ne pas hésiter à lire Dive into HTML5 de Mark Pilgrim qui décortique l’historique de cette période. Le langage s’est enrichi, avec de nouvelles balises sémantiques, mais aussi avec des passerelles vers des fonctionnalités jusque là réservées aux applications installées. Ces possibilités prennent vie grâce aux API intégrées au navigateur. Elles ne sont pas extérieures au HTML, elles en sont le prolongement direct et ouvrent la voie aux interactions que nous explorerons plus loin, notamment avec JavaScript.
L’enjeu n’est donc pas d’apprendre vite, mais d’apprendre juste. Comprendre ce que nous construisons. Poser une base solide. Cette approche change profondément la manière d’aborder le HTML. Nous ne cherchons plus à reproduire, mais à structurer.
La structure minimale d’un document HTML
Avant d’explorer les différentes parties du document, il est utile de comprendre qu’une page HTML complète repose sur une structure minimale. Cette structure ne décrit pas encore le contenu, mais le cadre dans lequel il va exister.
Un document HTML commence par une déclaration qui indique au navigateur le type de document, <!doctype html>. Elle est suivie d’un élément racine, <html>, qui contient l’ensemble de la page. À l’intérieur, deux zones principales coexistent. La première, <head>, fournit le contexte du document. La seconde, <body>, accueille le contenu visible.
<!doctype html>
<html lang="fr">
<head>
<!-- Le head contient les informations sur la page -->
<meta charset="utf-8">
<title>Première page</title>
</head>
<body>
<!-- Le body contient ce qui sera affiché -->
<h1>Bonjour</h1>
<p>Ce texte fait partie du contenu visible.</p>
</body>
</html>Nous distinguons ainsi clairement le contexte du document et son contenu. Le navigateur lit cette structure et sait immédiatement où trouver les informations et ce qu’il doit afficher. Cette organisation ne doit pas être vue comme une contrainte technique, mais comme une séparation des rôles. Le document existe, il possède un contexte, et il contient des informations. Comprendre cette distinction permet de mieux situer chaque élément et d’éviter de confondre ce qui décrit la page et ce qui la compose.
Dans la pratique, il arrive souvent de manipuler des fragments HTML isolés. Pourtant, ces fragments prennent toujours place, tôt ou tard, dans cette structure complète. La connaître permet de comprendre où nous intervenons réellement.
La partie invisible, <head>, métadonnées et contexte
Lorsque nous découvrons le HTML, l’attention se porte naturellement sur ce qui est visible. Les titres, les paragraphes, les images, les liens. Pourtant, une partie essentielle de la page ne s’affiche pas directement. Elle se situe dans la section <head>.
Cette partie ne contient pas le contenu au sens classique. Elle contient des informations sur le contenu. Elle donne un contexte. Elle permet au navigateur, mais aussi à d’autres systèmes, de comprendre ce qu’ils sont en train de lire.
À ce stade, il ne s’agit pas d’apprendre en détail chaque balise, mais de comprendre leur rôle structurant. La présence de <title> montre que la page possède une identité. Les éléments <meta /> apportent des précisions techniques, comme l’encodage ou le comportement sur mobile. Les éléments <link /> établissent des relations avec d’autres ressources, comme une feuille de style ou une icône. Peu à peu, la page cesse d’être un simple affichage pour devenir un document décrit et interprété.
<head>
<!-- Encodage des caractères, indispensable pour afficher correctement les textes -->
<meta charset="utf-8">
<!-- Titre du document, utilisé par le navigateur et les moteurs de recherche -->
<title>Parcours d’apprentissage web</title>
<!-- Adaptation de l’affichage aux appareils mobiles -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Icône associée à la page -->
<link rel="icon" href="favicon.svg" type="image/svg+xml">
</head>Ces éléments ne modifient pas directement le contenu visible, mais ils conditionnent la manière dont il est compris, affiché et utilisé. La spécification officielle, Document metadata, décrit précisément ce rôle des métadonnées. Prendre conscience de cette couche change profondément la perception du HTML. La page n’est plus seulement destinée à un lecteur humain. Elle existe aussi pour des navigateurs, des moteurs de recherche, des technologies d’assistance et des systèmes automatisés.
Nous reviendrons plus loin sur cette dimension, notamment dans le chapitre consacré à « Donner du sens, accessibilité et attributs ARIA », où les métadonnées et leur portée seront abordées plus en profondeur. À ce stade, il s’agit surtout de comprendre que le HTML ne se limite pas à ce qui est visible. Il définit aussi le contexte dans lequel le contenu existe.
Construire la structure du contenu dans <body>
Nous pouvons maintenant créer nos premières pages. Qu’il s’agisse d’une page d’accueil, d’une page de contact ou d’une présentation, peu importe encore le détail du contenu. Avant toute chose, chaque page doit afficher les grands blocs de structuration qui constituent l’ossature du document.
Nous mettons en place la première couche, celle qui accueille le site lui-même. L’en‑tête contient généralement le logo et le titre. La navigation permet de circuler. La partie centrale, <main>, accueille le contenu principal. Une zone <aside> peut compléter ou enrichir cette lecture. Enfin, le pied de page clôt l’ensemble. Ce que nous construisons ici n’est pas l’apparence, mais la structure fondamentale. Le HTML n’embellit pas. Il organise. Il donne un rôle à chaque partie.
<body>
<!-- En‑tête du site : logo et titre -->
<header>
<h1>Nom du site</h1>
</header>
<!-- Menu principal de navigation -->
<nav>
<!-- Nous placerons le menu de navigation, une fois l'ensemble des pages composé -->
</nav>
<!-- Contenu principal de la page -->
<main>
<p>Contenu principal</p>
</main>
<!-- Zone complémentaire -->
<aside>
<p>Informations complémentaires</p>
</aside>
<!-- Pied de page -->
<footer>
<p>Pied de page</p>
</footer>
</body>Le résultat peut sembler brut. C’est normal. Sans feuille de style, le navigateur applique uniquement ses styles par défaut, parfois appelés naked CSS. Les éléments apparaissent les uns sous les autres, sans mise en forme particulière. Ce dépouillement permet de voir la structure seule.
Créer une navigation simple
Relier les pages entre elles transforme notre structure en véritable site. Cette étape repose sur un mécanisme simple, le lien, mais elle révèle la logique interne du projet. Chaque lien repose sur un chemin. Ce chemin indique au navigateur où trouver la ressource.
Le chemin relatif au document dépend de la position du fichier. Le chemin relatif à la racine dépend de la position du site. Cette distinction peut sembler abstraite, mais elle devient très concrète dès que le projet grandit. En mettant en place la navigation, nous voyons apparaître un réseau. Les pages cessent d’être isolées. Elles deviennent des points reliés entre eux.
<!-- Menu principal de navigation -->
<nav>
<ul>
<li><a href="index.html">Accueil</a></li>
<li><a href="a-propos.html">À propos</a></li>
<li><a href="contact.html">Contact</a></li>
</ul>
</nav>Nous créons généralement une première page nommée index.html. Ce fichier constitue le point d’entrée du site. Lorsque le navigateur accède à un dossier, il recherche automatiquement ce nom. Certains serveurs acceptent également des variantes comme default.html, ainsi que leurs équivalents serveur comme index.php ou default.php. Cette convention permet d’afficher une page sans avoir à préciser son nom.
À ce stade, peu importe le contenu exact. L’essentiel est de poser une structure claire, qui accueillera ensuite les styles, les interactions et les données. Le guide Structurer ses documents propose une exploration détaillée de cette organisation et du rôle de chaque balise.
Affiner la structure, niveaux de découpe et hiérarchie des contenus
Face au HTML, la première impression peut être déroutante. Pourtant, en prenant le temps d’observer, une logique claire et progressive apparaît. Il existe des dizaines de balises, chacune avec ses attributs, ses variantes et ses usages. À en voir la liste sur Référence des éléments HTML, chercher à tout apprendre d’un seul bloc conduit souvent à se perdre. Il est plus efficace de comprendre comment ces éléments s’organisent.
Ces éléments prennent place dans la partie visible du document, à l’intérieur de <body>. C’est dans cet espace que le contenu devient lisible, et que la structure prend tout son sens. Nous avons dans le chapitre précédent abordé la mise en place de l’ossature principale de nos pages. Dans la pratique, les zones <header>, <nav> et <footer> restent généralement stables d’une page à l’autre, car elles portent l’identité et la navigation du site. Ce sont surtout <main> et <aside> qui varient, et que nous allons maintenant remplir avec le contenu propre à chaque page.
Une première distinction apparaît rapidement, toujours celle des conteneurs et des contenus. Certains éléments servent à structurer, comme <section>, <article>, <div>, <blockquote>… D’autres portent l’information elle même, comme <h1>, <h2>, <h3>…, <p>, <a>, <form>, <svg>, <code>, <pre>… ou <img />. Pour comprendre plus finement ces organisations, la notion de Catégories de contenu apporte un éclairage complémentaire.
En attendant les données définitives, il est courant d’utiliser du texte temporaire ou des médias de substitution. Ces éléments permettent de tester la structure et d’en vérifier la cohérence, sans dépendre du contenu final. Bien que l’article ne soit pas finalisé, vous trouverez sur Utiliser des médias libres de droit ou des gardes places, un ensemble de liens vous permettant de trouver des images, des typos, du texte… et bien plus encore.
Cette distinction introduit une hiérarchie essentielle. La page devient un ensemble organisé, et non une simple succession de balises.
Structurer le texte, éléments inline et nuances sémantiques
Une fois la structure générale en place et le contenu réparti dans les diverses balises, un second niveau d’affinage apparaît. Il concerne non plus les blocs, mais le texte et les éléments eux‑mêmes.
Certains éléments permettent de préciser, nuancer et enrichir le sens à l’intérieur d’un paragraphe. Les balises <strong> ou <em> marquent une emphase. <small> introduit une information secondaire. <sup> et <sub> permettent d’exprimer une note, une référence ou une formule. La balise <span> occupe une place particulière, car elle est neutre. Elle agit comme un repère discret, sans modifier le sens lui-même. Elle ne porte pas de sens propre, mais sert à cibler ou isoler une portion de texte, notamment pour lui appliquer un style ou un comportement. Ces éléments ne structurent pas la page, mais le sens du contenu lui‑même.
<!-- Exemple minimal : un titre, un paragraphe, et quelques portions de texte isolées avec <span> -->
<h1>À propos</h1>
<p>
Nous avançons par étapes, en gardant une structure claire.
<span>Ce passage sert de repère</span> pendant la relecture.
Ensuite, nous ajoutons du contenu réel, <span>au bon endroit</span>, sans casser l’ensemble.
</p>Ce niveau plus fin complète la hiérarchie introduite précédemment. La page ne se compose plus seulement de zones et de sections, mais d’un texte dont chaque partie peut être qualifiée.
La documentation MDN propose une vue détaillée de ces éléments et de leur rôle :dans Référence des éléments HTML https://developer.mozilla.org/fr/docs/Web/HTML/Reference/Elements. Progressivement, le HTML révèle sa cohérence profonde. Des grandes zones de structure jusqu’aux nuances du texte, chaque balise contribue à décrire le contenu avec précision.
Identifier les éléments, <id>, <class> et attributs globaux
Une fois la structure en place, une nouvelle étape commence. Les différents éléments doivent pouvoir être identifiés. Jusqu’ici, ils existent, mais ils ne possèdent pas encore de références propres. Pour qu’ils puissent être ciblés, reliés ou manipulés, ils doivent recevoir des marqueurs distinctifs.
Dans le chapitre précédent, nous avons utilisé plusieurs balises <span> pour isoler des portions de texte. Pourtant, ces éléments restent difficiles à atteindre précisément. Ils existent, mais rien ne permet encore de les désigner individuellement. C’est ici qu’interviennent les attributs. Ils permettent d’affiner le sens des balises, et surtout de leur donner une identité exploitable.
Les deux attributs les plus structurants dans cette démarche sont id et class. Le premier permet d’identifier un élément de manière unique. Il désigne une occurrence précise dans la page. Le second permet de regrouper plusieurs éléments partageant une même nature, une même fonction ou un même rôle. Il ne désigne plus un point isolé, mais une famille.
<!-- Exemple enrichi avec id et class -->
<h1 id="titre-page">À propos</h1>
<p class="introduction">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere">Ce passage sert de repère</span> pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position" data-role="emphase">au bon endroit</span>,
sans casser l’ensemble.
</p>L’attribut id permet ici de désigner un élément unique, tandis que l’attribut class permet de regrouper plusieurs éléments de même nature. L’attribut data-role ajoute quant à lui une information personnalisée, exploitable ultérieurement. Cette distinction introduit une nouvelle manière de lire la structure. Certains éléments deviennent des repères uniques, d’autres deviennent des ensembles cohérents.
La manière de nommer ces identifiants n’est pas anodine. Elle influence directement la lisibilité et l’évolution du projet. Avec le temps, différentes approches ont émergé pour structurer cette nomenclature, comme OOCSS, BEM, Atomic Design, SMACSS ou ITCSS. Ces méthodes ne concernent pas uniquement le CSS. Elles prennent racine dans le HTML lui‑même, au moment où les éléments reçoivent leurs noms. Elles proposent une manière d’organiser la structure pour la rendre plus claire, plus modulaire et plus durable. Nous approfondirons ces notions dans l’article suivant consacrée au CSS (Part III).
Peu à peu, la structure cesse d’être seulement organisée. Elle devient référencée. Chaque partie peut être désignée, retrouvée, utilisée.
D’autres attributs viennent naturellement compléter cette capacité d’identification. L’attribut title permet d’ajouter une information contextuelle. L’attribut lang précise la langue d’un élément. L’attribut href établit une relation vers une ressource. L’attribut src désigne l’origine d’un média. Et les attributs data-* occupent une place particulière. Ils permettent d’attacher des données personnalisées, propres au projet, sans modifier la structure ni la sémantique du document. Ils constituent un pont précieux entre le HTML et les scripts.
<h1 id="titre-page" lang="fr" title="Présentation du site">À propos</h1>
<p class="introduction" data-section="presentation">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere" title="Point de repère temporaire">Ce passage sert de repère</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position" data-role="emphase" lang="fr">au bon endroit</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg" alt="Image de substitution" title="Illustration provisoire">
<a href="contact.html" title="Accéder à la page de contact">Nous contacter</a>Chaque attribut ajoute ici une couche d’information supplémentaire. Certains précisent la langue, d’autres la destination d’un lien, d’autres encore un rôle interne au projet. Le HTML devient ainsi non seulement structuré, mais aussi documenté et enrichi. À ce stade, il ne s’agit pas d’apprendre une syntaxe complète, mais de comprendre une logique. Chaque élément peut recevoir une identité. Cette identité lui permet d’exister non seulement dans la structure, mais aussi dans les interactions à venir.
Le HTML devient alors un point de rencontre. Il relie le contenu, la présentation et le comportement. Cette capacité d’identification constitue la première étape vers l’interconnexion des différentes couches du web.
Le flux du document et l’imbrication des éléments
Au‑delà des balises elles‑mêmes, le HTML repose sur une logique de flux. Les éléments ne sont pas simplement posés les uns à côté des autres, ils sont imbriqués. Certains contiennent, d’autres sont contenus. Cette relation crée une continuité. Cette organisation introduit une notion implicite, celle de parent et d’enfant. Un élément existe à l’intérieur d’un autre. Il hérite de son contexte. Il participe à un ensemble plus large. La page devient une structure vivante, où chaque partie prend sens par sa position.
L’ordre dans lequel les éléments apparaissent joue également un rôle. Le navigateur lit le document de haut en bas. Cette lecture progressive construit l’interprétation. Elle influence l’affichage, mais aussi les interactions futures. Comprendre cette continuité permet d’éviter une erreur fréquente, considérer les éléments comme indépendants. En réalité, ils sont profondément liés. Une balise mal placée, mal fermée ou mal imbriquée peut fragiliser l’ensemble.
Cette notion d’imbrication dépasse le HTML lui‑même. Le CSS s’appuiera sur ces relations pour appliquer ses styles. Le JavaScript utilisera cette organisation pour accéder aux éléments et les manipuler. Ce que nous découvrons ici constitue une base essentielle pour la suite.
Peu à peu, la page cesse d’être une juxtaposition. Elle devient une structure cohérente, organisée selon un flux naturel. Cette structure porte un nom, le DOM, Document Object Model. Le navigateur transforme le HTML en une arborescence d’objets, où chaque élément devient un nœud relié aux autres. Cette représentation rend la page navigable, modifiable et manipulable. Le CSS et le JavaScript n’agissent pas directement sur le texte HTML, mais sur ce DOM.
HTML<!-- Un élément HTML que le navigateur transformera en nœud du DOM --> <p id="status">Chargement...</p> <!-- Un style qui s’applique à cet élément via son identifiant --> <style> /* Le CSS cible l’élément du DOM, ici via #status */ #status { font-weight: 700; } </style> <!-- Un script qui lit et modifie ce même élément via le DOM --> <script> // Le JavaScript ne manipule pas le texte HTML brut, il manipule le DOM const el = document.getElementById('status'); el.textContent = 'Le DOM est prêt, la page peut réagir.'; </script>Pour approfondir cette notion, la référence suivante permet d’en explorer les fondements en lisant Référence du DOM sur MDN et pour voir concrètement comment il est possible d’agir sur cette structure, ce qu’on appelle le DOM-Scripting, rapprochez vous de Manipuler des documents, toujours sur MDN.
Accessibilité et attributs ARIA
À ce stade, la structure fonctionne et la sémantique HTML a déjà permis de donner du sens au document. Le contenu est organisé, hiérarchisé, interprétable. Pourtant, cette première couche, aussi essentielle soit‑elle, ne couvre pas toutes les situations de lecture. Le web n’est pas consulté uniquement dans des conditions visuelles standard. Certaines personnes utilisent des lecteurs d’écran, d’autres naviguent sans interface graphique, d’autres encore sont en situation de handicap visuel, moteur ou cognitif. La page existe alors sous d’autres formes. Ignorer cette diversité reviendrait à construire un site partiellement lisible.
Il devient donc nécessaire de prolonger la sémantique native, non pour la remplacer, mais pour la compléter. Certains attributs permettent de préciser l’intention, le rôle ou la relation entre les éléments. Ils rendent explicite ce qui, autrement, resterait implicite. Pour comprendre les enjeux et les limites de cette seule approche structurelle, nous pouvons nous appuyer sur Structure et sémantique, est ce suffisant pour être accessible ?, Qu’entend-on par accessibilité ? et Introduction to Web Accessibility. Ces ressources montrent que la sémantique HTML constitue une base essentielle, mais qu’elle doit parfois être enrichie pour garantir une accessibilité réelle.
<!-- Même exemple enrichi avec des attributs ARIA pour améliorer l’accessibilité -->
<h1 id="titre-page" lang="fr" title="Présentation du site" aria-describedby="desc-page">À propos</h1>
<p class="introduction" data-section="presentation" id="desc-page">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere" title="Point de repère temporaire" aria-label="Repère de lecture">Ce passage sert de repère</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position" data-role="emphase" lang="fr" role="note" aria-label="Emphase importante">au bon endroit</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg"
alt="Image de substitution"
title="Illustration provisoire"
role="img"
aria-label="Illustration temporaire de présentation">
<a href="contact.html"
title="Accéder à la page de contact"
role="link"
aria-label="Accéder à la page de contact">Nous contacter</a>Ces attributs aria-* n’ajoutent pas de contenu visible, mais ils fournissent des informations essentielles aux technologies d’assistance. Ils permettent par exemple à un lecteur d’écran de préciser le rôle d’un élément, son intention ou sa relation avec d’autres parties du document.
Cette réflexion est approfondie dans ces deux articles Accessibilité web : comprendre avant de coder et Accessibilité web : penser un site dès la page blanche.
Métadonnées, décrire le document au-delà du visible
Aller plus loin implique d’utiliser aussi les métadonnées, qui prolongent ce que nous avons commencé à construire. Jusqu’ici, nous avons donné une structure, puis une sémantique, puis une accessibilité. Les métadonnées introduisent une nouvelle couche. Elles ne s’adressent plus directement au lecteur humain, mais aux systèmes qui lisent la page en parallèle de lui. Métadonnées : parler aux humains et aux intelligences artificielles.
Cette dimension ne concerne pas uniquement l’organisation visuelle. Elle concerne la capacité du document à être identifié, interprété et relayé. Une page peut être analysée par un moteur de recherche, résumée par un agent automatisé, intégrée dans un partage sur un réseau, ou exploitée par une application distante. Dans ces situations, le HTML visible ne suffit plus. Il devient nécessaire de fournir des informations complémentaires, structurées et explicites.
Ces informations prennent différentes formes. Certaines sont intégrées dans la section <head> sous forme de balises <meta> comme nous avons dans le chapitre La partie invisible, <head>, métadonnées et contexte. D’autres utilisent des formats structurés comme les microdatas, les microformats, les vocabulaires de Schema.org, ou des blocs de données encodés en JSON, souvent appelés JSON‑LD. Ces mécanismes permettent par exemple de décrire un article, une personne, un événement ou une organisation. Ils donnent à la page une existence au‑delà de son affichage immédiat. Ces sujets dépassent le cadre de ce chapitre et feront l’objet d’un article dédié. Ce qu’il faut retenir ici, c’est que le HTML ne constitue pas seulement un document à lire, mais aussi une source d’information à interpréter.
<!-- Exemple précédent enrichi avec des microdonnées Schema.org directement dans le HTML -->
<div itemscope itemtype="https://schema.org/Organization">
<h1 id="titre-page"
lang="fr"
title="Présentation du site"
aria-describedby="desc-page"
itemprop="name">
À propos
</h1>
<p class="introduction"
data-section="presentation"
id="desc-page"
itemprop="description">
Nous avançons par étapes, en gardant une structure claire.
<span class="repere"
title="Point de repère temporaire"
aria-label="Repère de lecture">
Ce passage sert de repère
</span>
pendant la relecture.
Ensuite, nous ajoutons du contenu réel,
<span class="position"
data-role="emphase"
lang="fr"
role="note"
aria-label="Emphase importante">
au bon endroit
</span>,
sans casser l’ensemble.
</p>
<img src="image-temporaire.jpg"
alt="Image de substitution"
title="Illustration provisoire"
role="img"
aria-label="Illustration temporaire de présentation"
itemprop="logo">
<a href="contact.html"
title="Accéder à la page de contact"
role="link"
aria-label="Accéder à la page de contact"
itemprop="url">
Nous contacter
</a>
</div>En utilisant ces métadonnées, nous rendons le site plus clair, plus accessible et plus interopérable. La page n’est plus uniquement affichée. Elle est comprise, classée et reliée à d’autres contenus.
Valider son HTML et comprendre les erreurs
Dans la première partie de ce parcours, nous avons insisté sur l’importance d’écrire un epeu de code, d’enregistrer et de tester le résultat dans le navigateur. Et parfois, une page peut sembler fonctionner correctement à l’écran, tout en reposant sur une structure fragile. Le navigateur affiche, corrige et interprète. Il comble les oublis, referme implicitement certaines balises, et permet au document de rester lisible. Cette tolérance est précieuse, mais elle peut aussi masquer des incohérences.
Une balise mal fermée, un élément mal imbriqué ou un attribut incomplet ne bloquent pas toujours l’affichage. Pourtant, ces imprécisions altèrent la structure réelle du document. Elles compliquent l’application des styles, perturbent les scripts et fragilisent l’accessibilité. Le document fonctionne en apparence, mais il perd en fiabilité. Par exemple le code suivant contient certaines erreurs « non bloquantes ».
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Page de test</title>
</head>
<body>
<!-- Balise <p> non refermée correctement -->
<p>Premier paragraphe
<!-- Balise <strong> mal imbriquée -->
<p>Second paragraphe <strong>avec emphase</p></strong>
<!-- Attribut sans guillemets -->
<img src=https://placehold.co/200x100 alt="Image de test">
<!-- Élément placé au mauvais endroit -->
<ul>
<p>Ce paragraphe ne devrait pas être ici</p>
<li>Élément 1</li>
<li>Élément 2</li>
</ul>
</body>
</html>Valider son HTML consiste à confronter le document à une lecture stricte, indépendante de l’interprétation du navigateur. Des outils comme le validateur du W3C analysent le code et signalent les anomalies. Ces messages ne sont pas des sanctions. Ils sont des repères. Ils nous apprennent à lire autrement, à remonter à l’origine d’une erreur et à comprendre comment la page est réellement construite.
Certains éditeurs facilitent ce travail dès l’écriture du code. Dreamweaver, par exemple, intègre un linter qui analyse le document en temps réel. Les erreurs ou incohérences sont signalées directement dans l’interface, souvent par un soulignement ou un indicateur visuel. Cette assistance immédiate permet de corriger les problèmes au fur et à mesure, sans attendre la phase de validation finale. Le développeur ne découvre plus l’erreur après coup. Il la voit apparaître pendant qu’il écrit, ce qui renforce progressivement sa compréhension de la structure et des règles du langage.
Peu à peu, notre regard évolue. Nous ne nous contentons plus de ce qui s’affiche. Nous prêtons attention à ce qui existe. Cette étape possède une valeur formatrice essentielle, car elle renforce notre compréhension de la structure et consolide les bases du projet.
Un HTML valide n’est pas une exigence abstraite. C’est une fondation solide. Il facilite l’application des styles, la manipulation par JavaScript, l’accessibilité et l’évolution future du site. Il garantit que la page repose sur une structure claire, stable et durable.
Utiliser les outils du navigateur
Le navigateur ne sert plus uniquement à afficher une page. Il devient également un véritable instrument d’observation. Il nous permet de voir ce qui se passe derrière l’interface, et de comprendre comment le document est interprété.
Les outils de développement donnent accès à la structure réelle du HTML. Nous pouvons les ouvrir de deux manières. La plus directe consiste à appuyer sur la touche F12. Une autre approche consiste à effectuer un clic droit sur un élément de la page, puis à choisir Inspecter dans le menu déroulant. Le navigateur affiche alors une nouvelle interface, généralement ancrée en bas ou sur le côté de la fenêtre.
Nous accédons ainsi à une représentation fidèle du document tel qu’il existe réellement. Nous pouvons parcourir les éléments, observer leur organisation et vérifier leur relation. Ce que nous voyons n’est plus seulement le code que nous avons écrit, mais celui que le navigateur a interprété et parfois corrigé. Cette lecture rend visibles certaines incohérences, des balises refermées implicitement, des éléments déplacés ou restructurés.
La console complète cette exploration. Elle affiche les messages liés au chargement de la page. Elle signale des erreurs, des avertissements, des ressources manquantes ou des problèmes de syntaxe. Même dans un simple document HTML, elle peut révéler une image introuvable, un lien incorrect ou un attribut mal formé. Elle devient ainsi un outil de vérification précieux. Elle ne sert pas seulement à corriger, mais à comprendre. Progressivement, elle nous aide à établir un lien direct entre le code que nous écrivons et le document que le navigateur construit.
L’onglet réseau complète cette lecture. Il montre que la page n’est pas un bloc unique, mais un assemblage de ressources, fichiers HTML, feuilles de style, images, scripts. Cette vision transforme notre compréhension. La page cesse d’être un objet unique. Elle devient un ensemble de relations.
Observer ces mécanismes change notre posture. Nous ne supposons plus. Nous vérifions. Nous comprenons comment la page existe réellement.
Factoriser cette structure
Lorsque le site s’enrichit et que plusieurs pages apparaissent, une évidence s’impose. Certaines parties restent identiques, généralement l’en‑tête, la navigation et le pied de page se répètent. Au début, nous copions ces fragments d’un fichier à l’autre. Cette méthode fonctionne, mais elle révèle rapidement ses limites. La moindre modification impose de corriger chaque page. Le risque d’erreur augmente, la cohérence diminue et la maintenance devient plus lourde. Cette situation introduit naturellement une nouvelle approche, la factorisation.
Factoriser consiste à extraire les parties communes pour les centraliser. La structure n’est plus dupliquée, elle est partagée. Le site devient plus cohérent, plus lisible et plus simple à faire évoluer. Une modification appliquée à un seul endroit se répercute immédiatement sur l’ensemble. Deux approches illustrent cette logique.
- Les includes PHP : L’utilisation de PHP introduit une transformation importante. Le fichier est d’abord interprété par un serveur, qui produit le HTML final. Le navigateur ne reçoit plus un fichier source, mais un résultat. Nous abordons cet aspect plus en détail dans l’article dédié au PHP, situé dans la Part VII de ce parcours, où nous verrons comment le serveur assemble et génère les pages dynamiquement.
- Les templates Dreamweaver : Dreamweaver propose un système de modèles qui permet de définir une structure commune, puis de créer des pages qui en héritent. Certaines zones restent verrouillées, d’autres restent modifiables. Cette approche facilite la cohérence et limite les erreurs lors des mises à jour. La documentation officielle propose Apprenez à utiliser des modèles Dreamweaver pour créer une mise en page « fixe » et créer des documents basés sur le modèle en conservant la même mise en page.
Ces méthodes reposent sur un même principe, séparer la structure et le contenu. Le fichier n’est plus nécessairement transmis tel quel au navigateur. Il peut être assemblé, complété ou généré.
Introduire une première interaction avec l’utilisateur, le formulaire
Jusqu’ici, le site présente des informations et permet de circuler d’une page à l’autre. Le formulaire introduit une dimension nouvelle. La page ne se contente plus d’être consultée. Elle devient un point de contact. L’utilisateur peut écrire, sélectionner, envoyer. Même si les données ne sont pas encore traitées, leur simple présence transforme la nature du site. La page n’est plus seulement un support de lecture. Elle devient un espace d’expression. Nous découvrons alors de nouveaux éléments, <form>, <label>, <input>, <textarea>. Chacun possède un rôle précis. Certains définissent la zone d’échange, d’autres permettent la saisie, d’autres encore décrivent les informations attendues. Le HTML ne traite pas encore les données, mais il prépare leur transmission.
Cette étape révèle une idée essentielle. Une page peut désormais transmettre des informations vers une autre page, vers un script ou vers un serveur. Elle devient capable de participer à un dialogue. Nous aborderons la réception, le contrôle et la sécurisation de ces données dans la Part VII consacrée au PHP. Pour l’instant, il s’agit de comprendre que le HTML permet d’ouvrir un canal d’échange, et qu’il prépare le terrain des interactions futures avec La gestion des formulaires https://www.puce-et-media.com/la-gestion-des-formulaires/.
Le site ne se contente plus d’exister. Il commence à dialoguer.
Le contenu, matière première du HTML
Jusqu’ici, nous avons principalement observé le rôle structurant du HTML. Il organise, relie et identifie. Pourtant, il est essentiel de rappeler une réalité souvent implicite. Le HTML ne crée pas le contenu. Il l’accueille.
Le texte, les images, les tableaux, les sons ou les vidéos existent avant leur intégration. Ils sont rédigés, capturés, enregistrés ou préparés ailleurs. Le HTML intervient ensuite pour leur donner une place, une relation et un sens dans la page. Cette inversion de perspective modifie profondément notre approche. Nous ne produisons pas simplement une page. Nous organisons des ressources.
- Le contenu textuel provient fréquemment de fichiers
.txt,.docx,.md,.xlsou.csv. Leur préparation influence directement la qualité du résultat. L’encodage des caractères, la structuration des paragraphes ou l’organisation des données déterminent la lisibilité finale. Copier sans comprendre revient souvent à importer des défauts invisibles. - Les images suivent la même logique. Les formats
.jpg,.png,.webp,.avifou.svgrépondent à des usages différents. Certains conviennent à la photographie, d’autres à la transparence ou à l’interface. Leur poids et leurs dimensions influencent directement le temps de chargement. Le HTML les affiche, mais leur efficacité dépend de leur préparation.
Cette préparation inclut l’optimisation, mais aussi l’adaptation aux différents contextes de consultation. Une image trop lourde, un son mal compressé ou une vidéo surdimensionnée ralentissent le chargement. Le HTML n’en corrige pas les défauts. Il s’appuie sur des ressources déjà adaptées. Préparer un média consiste donc à trouver un équilibre entre qualité, poids et usage, et parfois à proposer plusieurs versions d’une même image afin que le navigateur choisisse la plus appropriée selon l’écran, la résolution ou la connexion. Ce mécanisme, que nous approfondissons dans l’article Images responsives : comment le navigateur choisit une image, montre que le HTML ne se limite pas à afficher une image. Il participe à la décision.
- Le format
.svgoccupe une place particulière. Il ne s’agit pas seulement d’une image, mais d’un document descriptif. Il peut être intégré, modifié et animé. Le HTML ne se contente pas de l’afficher. Il peut l’intégrer directement dans le document, et ainsi faire du visuel un élément pleinement intégré à la structure. - Cette logique s’étend à l’ensemble des médias. Les balises
<img />,<picture>,<audio>ou<video>ne servent pas uniquement à afficher. Elles décrivent la présence d’un média, ses variantes possibles et sa fonction. Le HTML devient alors l’interface entre le contenu et son contexte de diffusion. - Les tableaux suivent le même principe. Souvent préparés dans des fichiers
.xls,.xlsxou.csv, ils sont ensuite restitués dans la page. Le HTML ne crée pas ces données. Il reproduit leur organisation, voir l’article Les tableaux, et les données tabulées. - Les listes, les figures ou les tableaux permettent d’adapter la structure à la nature des informations. Les balises
<ul>,<ol>,<li>,<figure>,<figcaption>,<table>,<thead>,<tbody>,<tr>ou<td>décrivent ces relations.
Peu à peu, une autre dimension apparaît, celle de l’organisation des fichiers. Les contenus sont nommés, classés, répartis dans des dossiers. Cette organisation influence directement la maintenabilité du projet.
Le HTML n’est pas la source du contenu. Il est la structure qui lui permet d’exister, d’être relié et d’être compris.
Conclusion, le HTML, point d’ancrage des interactions
À ce stade du parcours, une idée essentielle se précise. Le HTML ne constitue pas seulement une étape initiale. Il devient le socle commun.
- Le CSS ne crée pas la structure. Il la lit, puis la met en forme. Il s’appuie sur les éléments existants.
- Le JavaScript ne crée pas la page. Il s’attache à elle. Il la parcourt, la modifie et la complète.
- Les métadonnées prolongent cette logique. Elles n’ajoutent rien de visible, mais elles décrivent le document, précisent son contexte, son auteur, sa nature ou son rôle. Elles permettent aux moteurs de recherche, aux navigateurs et aux services externes de mieux interpréter la page.
- Les API du navigateur suivent la même continuité. Elles utilisent les éléments HTML comme points d’entrée pour introduire de nouvelles capacités, manipuler les contenus ou interagir avec l’environnement.
Le HTML devient ainsi le point d’ancrage. Celui qui relie le contenu, la présentation et les interactions. Comprendre cela change profondément notre manière d’apprendre. Le HTML n’est pas une simple introduction. Il constitue une fondation durable. Les chapitres suivants, consacrés au CSS puis au JavaScript, viendront prolonger ce travail et s’appuyer directement sur cette structure.
