FlowingDev

Le HTML, expliqué : le squelette numérique de toute page web

Apprenez les bases du HTML, le langage de balisage standard utilisé pour créer et structurer le contenu des pages et des applications web.

Essayer l'outil: Éditeur HTML

En une phrase

Le HTML (HyperText Markup Language) est le langage standard pour créer la structure et le contenu des documents qui sont affichés sur le World Wide Web.

Le problème qu'il résout

Imaginez Internet avant le web tel que nous le connaissons. C'était un Far West de nerds, plein de documents déconnectés les uns des autres. Des universitaires du CERN pouvaient avoir un article de recherche sur leur système local dans un format, tandis qu'une université dans un autre pays avait des travaux connexes dans un format complètement différent et incompatible. Partager et, plus important encore, connecter ces informations était un cauchemar numérique.

C'est là qu'intervient Tim Berners-Lee. À la fin des années 80 et au début des années 90, il n'essayait pas de créer une plateforme pour des vidéos de chats ; il tentait de résoudre un problème très concret pour les scientifiques : comment partager et lier nos documents entre différents ordinateurs et réseaux de manière simple et universelle ?

La solution était un trio gagnant : le protocole HTTP (pour demander et envoyer des documents), les URL (une adresse pour chaque document) et le HTML (un langage pour écrire les documents).

Le génie du HTML, c'était sa simplicité. Il fournissait un ensemble de « balises » que n'importe qui pouvait apprendre, permettant de baliser un document en texte brut. Cette balise disait à un navigateur : « Ce morceau est un titre », « Ceci est un paragraphe » et, de manière cruciale, « Ce texte-ci est un hyperlien vers cet autre document là-bas ». Cette capacité à créer des hyperliens, c'est le « HT » dans HTML, et c'est ce qui a transformé une collection de fichiers isolés en une véritable « toile » (web) d'informations interconnectées. Le HTML est devenu la lingua franca du navigateur, le plan universel d'une page web.

Comment ça marche sous le capot

À première vue, le HTML ressemble à du texte brut avec des chevrons un peu bizarres. Mais en coulisses, le navigateur exécute un processus d'analyse sophistiqué pour transformer ce texte en la page web vivante et interactive avec laquelle vous interagissez.

Balises, Éléments et Attributs : la Sainte Trinité

La syntaxe du HTML repose sur trois concepts fondamentaux. Une fois que vous pigez ça, vous maîtrisez 80 % du HTML.

  • Balise (Tag) : Une instruction entourée de chevrons, comme <p> ou <img>. La plupart des balises viennent par paires : une balise ouvrante (<p>) et une balise fermante (</p>). La balise fermante a une barre oblique.
  • Élément (Element) : Le package complet — la balise ouvrante, le contenu, et la balise fermante. La totale, quoi.
  • Attribut (Attribute) : Une information ou un réglage supplémentaire pour un élément, placé dans la balise ouvrante. Ils se présentent sous la forme de paires nom="valeur".

Décortiquons un exemple simple :

<a href="https://flowing.dev" class="main-link">Visitez FlowingDev</a>
  • Les balises sont <a> et </a>. Le a signifie « anchor » (ancre), et est utilisé pour les hyperliens.
  • L'élément est la ligne entière, de <a... à ...</a>.
  • Le contenu est le texte « Visitez FlowingDev ».
  • Il a deux attributs :
    • href="https://flowing.dev" : L'attribut « hypertext reference » (référence hypertexte), qui indique au navigateur où aller lorsque le lien est cliqué. C'est l'attribut le plus important pour une balise <a>.
    • class="main-link" : Un attribut « class », qui sert de point d'ancrage (hook) pour le CSS qui va styler l'élément, ou pour le JavaScript qui va le cibler.

Le Document Object Model (DOM)

Quand un navigateur reçoit votre fichier HTML, il ne se contente pas de le lire ligne par ligne comme un livre. Il analyse (parse) le texte et construit en mémoire une structure logique en arbre appelée le Document Object Model (DOM).

Voyez le code source HTML comme le plan d'architecte d'une maison. Le DOM, c'est la charpente de la maison une fois construite — une structure tangible que vous pouvez inspecter et modifier.

Considérez cette page HTML de base :

<!DOCTYPE html>
<html>
  <head>
    <title>Ma Page</title>
  </head>
  <body>
    <h1>Un Titre</h1>
    <p>Un peu de texte.</p>
  </body>
</html>

Le navigateur voit l'imbrication des balises et construit cet arbre DOM :

  • html
    • head
      • title
        • (texte) "Ma Page"
    • body
      • h1
        • (texte) "Un Titre"
      • p
        • (texte) "Un peu de texte."

Cette structure en arbre, c'est la clé de tout. Le CSS applique des styles aux nœuds de cet arbre. Le JavaScript peut manipuler cet arbre — en ajoutant de nouveaux nœuds (éléments), en supprimant d'anciens, ou en modifiant leurs attributs — ce qui permet aux pages web modernes de devenir dynamiques et interactives sans avoir besoin de se recharger. Le DOM est le pont entre votre HTML statique et une application dynamique.

Éléments de bloc vs. en ligne

Tous les éléments ne naissent pas égaux. En termes de mise en page, ils se répartissent en deux grandes familles.

  • Éléments de bloc (Block-level Elements) : Ce sont les poids lourds. Ils sont structurels. En général, ils commencent sur une nouvelle ligne et occupent toute la largeur disponible, comme un paragraphe dans un livre.

    • Exemples : <div>, <p>, <h1>-<h6>, <ul>, <li>, <form>, <article>.

  • Éléments en ligne (Inline Elements) : Eux sont plus subtils. Ils ne commencent pas sur une nouvelle ligne et n'occupent que la largeur nécessaire à leur contenu. Ils s'insèrent dans le flux du texte qui les entoure.

    • Exemples : <a>, <span>, <strong>, <em>, <img>, <input>.

Comprendre cette distinction est crucial pour la mise en page en CSS. Essayer de définir une largeur sur un élément en ligne ne fonctionnera souvent pas comme prévu, et se demander pourquoi deux éléments sont côte à côte alors qu'on les voulait l'un sous l'autre est un casse-tête classique de la différence bloc/inline.

<div style="background-color: #eee;">
  Ce div est un élément de bloc. Il prend toute la largeur.
</div>
<div style="background-color: #ddd;">
  Voici un second div. Il commence sur une nouvelle ligne.
</div>
<p>
  Voici un paragraphe qui contient un 
  <a href="#">lien en ligne</a> et du 
  <strong>texte en gras en ligne</strong>. Remarquez comme ils restent tous
  dans le flux du texte.
</p>

Histoires vécues

Le bouton « Acheter » mal aligné

Un développeur junior avait pour tâche d'ajouter une description de produit et un bouton « Acheter ». Il a écrit ce qui semblait logique : <p>Super Produit ! Seulement 9,99 € ! <button>Acheter</button></p>. Sur son grand écran de bureau, tout semblait parfait. Le bouton se trouvait joliment à la fin de la phrase. Le code est mis en prod.

Quelques jours plus tard, les stats ont montré une baisse des conversions sur mobile. Un développeur senior a enquêté et a affiché la page sur un téléphone. Le texte « Super Produit ! Seulement 9,99 € ! » passait à la ligne, et le bouton « Acheter » suivait le mouvement, se retrouvant bizarrement indenté sous le début de la phrase. Ça avait l'air tout cassé. Le dev junior avait mis un élément de type bloc (un <button> se comporte souvent comme tel) à l'intérieur d'un paragraphe, créant un comportement de retour à la ligne imprévisible.

La solution était simple : séparer la structure du contenu. Le texte est allé dans sa propre balise <p>, et le bouton dans son propre <div>. Désormais, le paragraphe pouvait aller à la ligne autant qu'il le voulait, et le bouton, en tant que bloc distinct, apparaîtrait toujours proprement en dessous, quelle que soit la taille de l'écran.

La leçon : Comprendre le modèle de boîtes (box model) HTML et la distinction bloc/inline n'est pas négociable pour créer des mises en page prévisibles qui ne cassent pas sur différents appareils.

Le blog que les robots ne pouvaient pas lire

Une startup a lancé un nouveau blog très chic, propulsé par un framework JavaScript de pointe. C'était rapide, animé, et on aurait dit une application native. Le code source HTML de tout le site se résumait en gros à <div id="app"></div> et une énorme balise <script> qui construisait la page dans le navigateur de l'utilisateur. Ils étaient fiers de leur technologie.

Six mois plus tard, ils avaient un problème : zéro trafic organique de Google. Ils étaient invisibles. Quand un robot d'indexation (crawler) visitait leur site, il ne voyait pas de beaux articles et des titres ; il voyait un <div> vide. Même si le robot de Google est devenu meilleur pour exécuter le JavaScript, c'est une étape supplémentaire, coûteuse, et qui n'est pas infaillible. Le blog ne communiquait pas sa structure ou son contenu dans la langue maternelle du crawler : du bon vieux HTML sémantique.

L'équipe a dû revoir l'architecture de son site pour utiliser le rendu côté serveur (Server-Side Rendering ou SSR), où le serveur génère le HTML complet de chaque page avant de l'envoyer au navigateur. Dès qu'ils ont déployé le changement, leurs pages ont commencé à être correctement indexées.

La leçon : Le HTML sémantique (<article>, <h1>, <p>) n'est pas juste une suggestion ; c'est votre façon de communiquer le sens et la hiérarchie de votre contenu aux moteurs de recherche et autres outils automatisés.

Le cauchemar de l'accessibilité

Une entreprise a déployé un nouveau tableau de bord interne. Pour obtenir le look au pixel près que les designers voulaient, les développeurs ont utilisé des éléments <div> pour absolument tout. Un <div> avec un border-radius et un événement JavaScript onClick est devenu un bouton. Un autre <div> avec un onClick est devenu un lien.

Le tableau de bord était inutilisable pour un employé qui dépendait d'un lecteur d'écran (screen reader). Le lecteur d'écran annonçait « groupe » pour chaque élément interactif, n'offrant aucune idée s'il s'agissait d'un bouton, d'un lien ou d'autre chose. De plus, comme les <div> ne sont pas focalisables par défaut, la navigation avec la touche Tab était impossible.

Un consultant en accessibilité a été appelé et a été horrifié. La correction a nécessité un refactoring fastidieux mais essentiel : remplacer les <div onClick="..."> par des <button>, des <a>, et d'autres éléments sémantiques appropriés. Ces balises natives embarquent gratuitement une quantité énorme de fonctionnalités d'accessibilité — focus clavier, annonce correcte du rôle, et plus encore.

La leçon : Utilisez la bonne balise HTML pour le bon usage. Vous ne dites pas seulement au navigateur comment dessiner quelque chose ; vous dites aux technologies d'assistance ce que cette chose est.

Erreurs et pièges courants

  • La « div-ite » aiguë. L'abus de <div> et <span> alors que des balises plus spécifiques et sémantiques comme <nav>, <main>, <article>, <aside>, ou <button> décriraient mieux le rôle du contenu.
  • Oublier les bases de l'accessibilité. L'absence d'attributs alt sur les balises <img> est un grand classique. Cela laisse les utilisateurs malvoyants sans aucune information sur l'image. De même, utiliser <b> pour mettre en gras au lieu de <strong> (qui indique l'importance) est une occasion manquée d'être sémantique.
  • L'imbrication incorrecte des balises. On ne peut pas mettre n'importe quelle balise dans n'importe quelle autre. Une erreur fréquente est d'envelopper un élément de bloc (comme un <div>) dans un élément en ligne (comme un <a>). Même si les navigateurs feront de leur mieux pour l'afficher, le DOM résultant peut être un vrai bazar et entraîner un comportement étrange.
  • Ignorer la balise <head>. La section <head> est vitale. Oublier de définir l'encodage des caractères (<meta charset="UTF-8">) peut entraîner du texte illisible. Oublier la balise meta viewport (<meta name="viewport" content="width=device-width, initial-scale=1.0">) est la raison numéro un pour laquelle les sites mobiles apparaissent dézoomés et minuscules.
  • Penser que le vocabulaire est figé. Le HTML est un langage vivant. De nouvelles balises et de nouveaux attributs sont ajoutés au fil du temps (par ex., <main>, <picture>). Se baser sur des pratiques de 2010 signifie que vous passez à côté de manières plus robustes et sémantiques de structurer vos documents.

Pourquoi ça doit vous intéresser

Si vous touchez au web de près ou de loin dans un cadre professionnel, le HTML n'est pas une option.

  • Pour les développeurs front-end, c'est le socle. Les frameworks comme React, Vue et Svelte sont puissants, mais au final, ils crachent tous du HTML. Comprendre le produit final fait de vous un développeur bien plus efficace.
  • Pour les développeurs back-end, vous générez souvent des bouts de HTML, vous construisez des API qui seront consommées par des front-ends en HTML, ou vous travaillez avec des moteurs de template qui produisent du HTML. Connaître ses règles vous évite de livrer du balisage cassé ou non sémantique.
  • Pour les designers UI/UX, comprendre les briques de base du HTML (div, span, p, h1) vous aide à créer des designs qui sont réalistes à construire et qui correspondent bien aux composants natifs du web.
  • Pour les spécialistes SEO et les content managers, une bonne maîtrise du HTML (en particulier les titres, les balises title et les meta descriptions) est fondamentale pour votre métier.

Le HTML est le langage le plus durable, rétrocompatible et universel de l'ère numérique. Une page web écrite en 1995 s'affichera encore aujourd'hui. C'est la compétence qui est restée essentielle à travers chaque cycle de hype et chaque guerre des frameworks, et elle n'est pas près de disparaître.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Éditeur HTML