Le HTML, expliqué : le squelette de chaque page web

En une phrase

Le HTML (HyperText Markup Language) est le langage textuel standard utilisé pour créer et structurer le contenu que vous voyez sur une page web, un peu comme les plans d'un bâtiment.

Le problème qu'il résout

Imaginez le monde avant le web tel que nous le connaissons : un Far West numérique de documents déconnectés les uns des autres. Si vous étiez un physicien dans une université, partager votre dernier article de recherche avec un collègue de l'autre côté de l'océan était un vrai bazar. Vous envoyiez un fichier par e-mail, mais votre correspondant n'avait peut-être pas le bon logiciel pour l'ouvrir. La mise en forme était complètement fichue. Il n'y avait pas de liens universels, pas de moyen simple de sauter d'un document à un autre qui lui était lié.

C'est là qu'intervient Tim Berners-Lee au CERN à la fin des années 1980. Le problème auquel il était confronté était de faire en sorte qu'une bande de scientifiques brillants, occupés et dispersés géographiquement puissent partager et accéder à l'information efficacement. La solution devait être simple, indépendante de la plateforme et robuste. Il n'avait pas besoin d'un programme de mise en page sophistiqué ; il avait besoin d'un moyen de baliser un document texte brut pour lui donner une structure : ceci est un titre, ceci est un paragraphe, ceci est une liste, et surtout, ce texte-ci pointe vers cet autre document là-bas.

Cette partie « lien » était l'ingrédient magique, l'« HyperTexte » de HTML. S'inspirant d'un système plus ancien et plus complexe appelé SGML, Berners-Lee a créé une version simplifiée, facile à écrire pour un humain et, tout aussi important, facile à analyser (parser) et à afficher pour un programme informatique (un « navigateur »).

Le HTML a résolu le problème d'un format de document universel pour Internet. Il a créé un langage commun que n'importe quelle machine pouvait comprendre, transformant une collection chaotique de fichiers en une « toile » (web) d'informations interconnectées. Il n'a pas été conçu pour être joli – ça, c'est venu plus tard avec le CSS – il a été conçu pour être fonctionnel, descriptif et pour connecter le savoir du monde entier.

Comment ça marche en coulisses

Alors, comment un simple fichier texte plein de chevrons devient-il la page web riche et interactive que vous lisez en ce moment ? C'est un voyage fascinant du texte aux pixels, qui implique quelques concepts clés.

### Balises, Éléments et Attributs : Les briques de base

À la base, le HTML n'est rien de plus que du texte avec des instructions spéciales appelées balises (tags). Une balise est généralement un mot-clé court et mémorable entouré de chevrons, comme <p>.

La plupart des balises vont par paires : une balise ouvrante (<p>) et une balise fermante (</p>). Tout ce qui se trouve entre les deux — la paire de balises et son contenu — s'appelle un élément.

<p>Toute cette ligne est un élément de paragraphe.</p>

Balise (Tag) : Les parties <p> et </p> sont les balises. Elles signalent le début et la fin d'un paragraphe.
Contenu : Le texte "Toute cette ligne est un élément de paragraphe." est le contenu.
Élément : La balise ouvrante, le contenu et la balise fermante forment ensemble l'élément <p>.

Certains éléments sont « vides » ou « orphelins » (void/empty), ce qui signifie qu'ils n'ont ni contenu ni balise fermante, car ils représentent une chose unique et autonome, comme une image <img> ou un saut de ligne <br>.

Pour ajouter plus d'informations à un élément, on utilise des attributs. Ce sont des paires nom="valeur" qui se placent à l'intérieur de la balise ouvrante et fournissent une configuration supplémentaire. L'exemple le plus célèbre est l'hyperlien :

<a href="https://flowing.dev">Visitez FlowingDev</a>

Ici, <a> est la balise pour une ancre (anchor), c'est-à-dire un lien, mais elle est inutile toute seule. L'attribut href indique au navigateur où le lien doit mener.

### L'arbre DOM : du texte à l'arbre généalogique

Quand votre navigateur reçoit un fichier HTML, il ne se contente pas de le lire ligne par ligne comme un roman. Il commence immédiatement à parser le texte pour construire une représentation logique en mémoire de la structure du document. Cette structure s'appelle le Document Object Model, ou DOM.

La meilleure façon de se représenter le DOM est de l'imaginer comme un arbre généalogique. L'élément <html> est l'ancêtre de tout le reste. Il a deux enfants directs : <head> (pour les métadonnées comme le titre de la page) et <body> (pour le contenu visible). L'élément <body> a ensuite ses propres enfants, comme des titres <h1>, des paragraphes <p> et des listes <ul>, qui peuvent à leur tour avoir leurs propres enfants.

Considérez ce simple code HTML :

<html>
  <head>
    <title>Ma Page</title>
  </head>
  <body>
    <h1>Un titre principal</h1>
    <p>Du texte et un <a href="#">lien</a>.</p>
  </body>
</html>

Le navigateur transforme ce texte en cette arborescence logique :

  html
  ├── head
  │   └── title
  │       └── "Ma Page"
  └── body
      ├── h1
      │   └── "Un titre principal"
      └── p
          ├── "Du texte et un "
          └── a (href="#")
              └── "lien"
          └── "."

Cet arbre, c'est la base de tout. Ce n'est pas encore la page visuelle, mais c'est le modèle structuré que le navigateur utilise pour les étapes suivantes. Quand JavaScript doit modifier quelque chose sur la page ou que le CSS doit appliquer un style, ils ne modifient pas un fichier texte ; ils interagissent avec cet arbre DOM bien vivant.

### Le pipeline de rendu du navigateur

Une fois l'arbre DOM construit, le navigateur lance une séquence d'événements pour dessiner concrètement les pixels sur votre écran. Un visualiseur HTML est essentiellement une version miniature de ce processus (pipeline).

Analyse (Parsing) : Comme nous l'avons vu, le navigateur parse le texte HTML pour construire l'arbre DOM. En même temps, il fait de même pour tout le CSS qu'il trouve, construisant un « CSSOM » (CSS Object Model).
Calcul des styles : Le navigateur combine le DOM et le CSSOM pour créer un « arbre de rendu » (Render Tree). Cet arbre n'inclut que les éléments qui seront réellement affichés et sait quels styles CSS s'appliquent à chacun. Par exemple, il détermine que le nœud <h1> de notre DOM doit avoir un font-size: 2em et un font-weight: bold.
Mise en page (Layout ou « Reflow ») : Le navigateur se transforme alors en géomètre. Il parcourt l'arbre de rendu et calcule la taille et la position exactes de chaque élément. « Ce <h1> fait 500px de large et 40px de haut, et il se trouve à 20px du haut de la page. » Il détermine comment le texte s'enroule (wrap), comment les marges repoussent les éléments, et où chaque chose se place dans la fenêtre d'affichage (viewport).
Affichage (Painting) : Une fois les plans de la mise en page terminés, le navigateur peut enfin jouer au peintre. Il « dessine » les pixels pour chaque élément — texte, couleurs, bordures, images — dans des calques (layers).
Composition : Enfin, le navigateur prend tous les calques dessinés et les assemble (composite) dans le bon ordre pour afficher l'image finale sur votre écran. C'est cette étape qui explique pourquoi certains éléments peuvent sembler glisser par-dessus ou par-dessous d'autres.

Tout ce pipeline, de la réception du premier octet de HTML à l'affichage du dernier pixel, se déroule en une fraction de seconde.

Histoires vécues

La théorie, c'est bien, mais l'importance du HTML se révèle vraiment sur le terrain.

### Le cas du footer en fuite

Un développeur junior, Sam, devenait fou. Il avait passé trois heures à essayer de comprendre pourquoi le footer du site web apparaissait à mi-hauteur de la page, en plein milieu de la zone de contenu principal. Le CSS semblait correct, la logique du template aussi. En désespoir de cause, il a affiché le code source HTML final de la page et l'a collé dans un visualiseur. Instantanément, le rendu visuel a montré la même mise en page cassée. En parcourant le code source à côté, ses yeux l'ont repéré : une unique balise <div> non fermée, <div class="sidebar". Le navigateur, dans sa tentative héroïque de ne pas planter, a fait une supposition et a décidé que le reste de la page, y compris le footer, était censé se trouver à l'intérieur de cette sidebar.

La leçon : Les navigateurs sont incroyablement indulgents avec du HTML cassé, mais leur correction d'erreurs peut entraîner des bugs de mise en page silencieux et déroutants. Ce que vous vouliez écrire n'a pas d'importance ; ce que le navigateur parse est la seule chose qui compte.

### La promotion par e-mail qui disparaît

Une équipe marketing a passé une semaine à concevoir un magnifique e-mail HTML pour le lancement d'un nouveau produit. Dans leur éditeur en ligne, c'était parfait : des GIF animés, des polices personnalisées, des boutons stylés. Ils ont envoyé une campagne de test. Les retours sont tombés : un désastre. Pour la moitié de leur audience (surtout ceux sur Outlook en entreprise), l'e-mail était un fatras de texte, d'icônes d'images cassées et de simples liens bleus. Ils l'avaient construit comme une page web moderne. En utilisant un visualiseur HTML pour simuler un environnement de rendu plus basique, ils ont compris leur erreur. Les clients de messagerie ne sont pas des navigateurs modernes ; ce sont des capsules temporelles numériques de 2005. Les mises en page sophistiquées avec des <div>, les animations CSS et les polices web étaient ignorées ou complètement supprimées. Ils ont dû le reconstruire en utilisant des mises en page à l'ancienne avec des <table>, à l'épreuve des balles.

La leçon : Le contexte de rendu est roi. Un HTML qui fonctionne parfaitement dans Chrome peut complètement s'effondrer dans un environnement plus strict ou plus ancien comme un client de messagerie.

### Le hold-up du SEO

Le trafic de Google pour le produit phare d'un site e-commerce, les « Moulins à café artisanaux », a soudainement chuté. La page semblait identique pour les utilisateurs. Une consultante SEO, Maria, a été appelée. Elle n'a pas seulement regardé la page ; elle a regardé son squelette. Faisant un clic droit sur « Afficher la source », elle a copié le HTML. Son analyse a été rapide : une refonte récente du site avait remplacé le titre principal de la page, qui utilisait correctement une balise <h1>Moulins à café artisanaux</h1>, par un simple <span class="big-fancy-title">Moulins à café artisanaux</span>. Pour un humain, le texte semblait identique. Pour le robot de Google, la page n'avait plus de titre principal clair. Le signal sémantique le plus important sur le sujet de la page avait été effacé.

La leçon : Le HTML ne sert pas qu'à la mise en forme ; il transmet du sens. Utiliser la bonne balise pour le bon usage (HTML sémantique) est essentiel pour l'accessibilité et le référencement (SEO).

Erreurs et pièges courants

La div-ite aiguë : Utiliser des <div> pour tout est une erreur classique. Besoin d'un bouton ? Utilisez <button>. Besoin d'une barre de navigation ? Utilisez <nav>. Besoin d'une liste ? Utilisez <ul>. L'utilisation de balises sémantiques rend votre site plus accessible aux lecteurs d'écran et plus compréhensible pour les moteurs de recherche.
Oublier le texte alt : Chaque balise <img> qui transmet une information devrait avoir un attribut alt décrivant l'image. Si l'image ne se charge pas, le texte alt est affiché. Plus important encore, c'est ce que les lecteurs d'écran annoncent aux utilisateurs malvoyants. alt="" est réservé aux images purement décoratives.
Imbrication incorrecte : Les balises doivent être fermées dans l'ordre inverse de leur ouverture. <b><i>Gras et Italique</i></b> est correct. <b><i>Gras et Italique</b></i> est incorrect. Les navigateurs modernes l'afficheront souvent correctement, mais c'est techniquement invalide et peut causer un comportement imprévisible, surtout avec des manipulations complexes du DOM.
Utiliser des éléments de bloc dans des éléments en ligne : Vous ne devriez pas mettre un élément de type bloc (comme un <div> ou <p>) à l'intérieur d'un élément en ligne (comme un <span> ou <a>). Même si les navigateurs peuvent l'afficher, cela viole la norme HTML et peut entraîner des problèmes de mise en page et de style étranges.
Supposer que le rendu sera identique partout : La beauté et la malédiction du web, c'est que votre HTML est interprété par des dizaines de moteurs de rendu différents sur des milliers d'appareils différents. Ce qui semble parfait dans votre visualiseur ou sur Chrome pour ordinateur de bureau peut être légèrement différent sur Safari pour iOS. Testez toujours sur les appareils cibles clés.

Pourquoi vous devriez vous y intéresser

Que vous soyez un puriste du backend, un data scientist ou un designer UI/UX, vous ne pouvez pas échapper au HTML. C'est la lingua franca du web.

Pour le débogage : Lorsque votre super framework JavaScript vous sort une interface utilisateur bizarre, le responsable final est le HTML qu'il a généré. Être capable de lire et de comprendre le DOM final est une compétence de débogage fondamentale.
Pour la performance : Un HTML lourd et profondément imbriqué ralentit les temps de mise en page et d'affichage. Comprendre la structure HTML est la première étape pour construire des sites rapides et réactifs.
Pour la sécurité : Une mauvaise compréhension du HTML peut entraîner des failles de sécurité. Par exemple, si vous injectez des données fournies par l'utilisateur dans votre HTML sans les assainir correctement, vous pourriez être vulnérable aux attaques de Cross-Site Scripting (XSS).
Pour la communication : Quand un designer vous donne une maquette, ou que vous devez expliquer un bug frontend à un collègue, être capable de parler couramment des éléments HTML, des attributs et de l'arbre DOM rend la conversation dix fois plus efficace.

En bref, si votre travail touche de près ou de loin à un navigateur web, une solide maîtrise des fondamentaux du HTML n'est pas une option, c'est la base.

Pour aller plus loin

MDN Web Docs : Les bases du HTML - Le meilleur endroit pour commencer pour tout développeur web. Clair, complet et plein d'exemples.
HTML Living Standard (WHATWG) - La spécification officielle et canonique du HTML. C'est dense et très technique, mais c'est la source de vérité ultime.
L'histoire du HTML sur Wikipedia - Un excellent aperçu de l'évolution du HTML, de ses racines académiques à la norme HTML5 que nous utilisons aujourd'hui.
Service de validation du balisage du W3C - Pas seulement un outil, mais une leçon. Passer votre HTML dans un validateur est un excellent moyen d'apprendre les règles et les bonnes pratiques.