Le débutant tombe presque toujours dans le même piège. Il décide d'apprendre le HTML, ouvre une page qui liste les 142 balises existantes par ordre alphabétique, et se met à apprendre par cœur. <abbr>, <bdi>, <wbr>... Au bout d'une heure il a oublié les dix premières, n'a construit aucune page, et il en conclut qu'il n'est « pas fait pour ça ».
Le HTML ne s'apprend pas comme un dictionnaire. C'est un langage qu'on apprend en construisant de vraies pages, un élément à la fois, dans un ordre où chaque brique sert immédiatement à quelque chose de visible. Voici la méthode que je conseille, après des années à écrire du HTML et à voir des débutants accrocher ou abandonner.
Pourquoi mémoriser les balises ne sert à rien
Il existe environ 110 balises HTML encore utiles aujourd'hui. Personne ne les connaît toutes de tête, pas même les devs qui en vivent. Et c'est normal : on n'en utilise qu'une vingtaine au quotidien. Les autres, on les retrouve en trois secondes quand le besoin se présente, parce qu'on sait quoi chercher.
Mémoriser une liste de balises hors contexte, c'est apprendre du vocabulaire sans jamais former de phrase. Tu peux réciter <figcaption>, mais si tu n'as jamais affiché une image avec sa légende, le mot ne veut rien dire. La bonne approche est inverse : tu construis une page, tu te heurtes à un besoin réel (« il me faut un lien », « je veux une liste »), et tu apprends la balise à ce moment-là. Elle s'ancre parce qu'elle est liée à un problème que tu venais d'avoir.
Le HTML décrit le sens du contenu : ceci est un titre, ceci un paragraphe, ceci un lien. Tu ne mémorises pas des balises, tu apprends à nommer correctement les morceaux d'une page. Et ça, ça se fait en faisant.
Le bon ordre d'apprentissage
Le HTML a une progression naturelle, du squelette d'une page jusqu'aux détails qui font la différence. Chaque étape réutilise la précédente : on pose d'abord la structure, puis on la remplit, puis on la rend propre et accessible.
1. La structure d'une page. Avant tout, le squelette : <!DOCTYPE html>, puis <html> qui contient un <head> (les métadonnées invisibles : titre de l'onglet, encodage) et un <body> (tout ce qui s'affiche). Tant que ce moule n'est pas clair, le reste flotte dans le vide. Une fois posé, tu as une page valide qui s'ouvre dans le navigateur.
2. Le texte. Le contenu d'abord : les titres de <h1> à <h6> qui hiérarchisent, les paragraphes <p>, la mise en valeur avec <strong> et <em>. C'est la partie que tu écriras le plus souvent : un site, c'est avant tout du texte structuré.
3. Les liens et les images. Ce qui fait du « web » un web : le lien <a href="..."> qui relie les pages entre elles, et l'image <img src="..." alt="...">. Deux balises minuscules, mais c'est là que ta page cesse d'être un document isolé pour devenir vivante.
4. Les listes et les tableaux. Pour organiser le contenu : les listes à puces <ul>, numérotées <ol>, et les tableaux <table> pour les vraies données tabulaires (pas pour la mise en page, ça c'est le rôle du CSS). Tu commences à structurer de l'information, pas juste à l'aligner.
5. La sémantique. L'étape qui sépare le bricolage du travail propre : <header>, <nav>, <main>, <footer>, <section>, <article>. Au lieu d'empiler des <div> anonymes, tu nommes les zones de ta page. Le navigateur, Google et les lecteurs d'écran comprennent enfin ce que chaque bloc représente.
6. Les formulaires. Quand la page doit dialoguer : <form>, <input>, <label>, <button>. Champs texte, cases à cocher, boutons d'envoi. C'est aussi le moment où l'on découvre les nombreux types d'input (email, date, nombre) qui font gratuitement la moitié du travail de validation.
7. Les attributs et les bonnes pratiques. En dernier, ce qui distingue le HTML correct du HTML soigné : les attributs (id, class, title), l'accessibilité (un alt qui décrit vraiment l'image, des labels reliés à leurs champs), et l'habitude de valider son code. C'est ici que les « bonnes pratiques » prennent enfin un sens, parce qu'elles répondent à des problèmes que tu as maintenant rencontrés.
Pratiquer sans rien installer
Le frein classique, c'est de croire qu'il faut un éditeur compliqué, un serveur, une configuration. Pour le HTML, c'est faux : un fichier texte et un navigateur suffisent. Mais le vrai déclic, c'est de voir le résultat changer en direct quand on modifie une balise. Sans ça, on écrit à l'aveugle et on se décourage.
C'est exactement ce que j'ai construit dans le cours HTML gratuit et interactif de ce site : chaque étape ci-dessus a sa leçon, avec des exemples que tu modifies directement dans la page et dont tu vois le rendu aussitôt, plus des exercices et des quiz. Tu écris du vrai HTML dès la première leçon, dans l'ordre qui marche, sans jamais rien installer.
Et une fois la page structurée, la suite logique c'est de l'habiller : c'est le rôle du cours CSS, qui prend le relais exactement là où le HTML s'arrête. HTML pour le sens, CSS pour l'apparence : c'est la base de tout le métier.
Conclusion
La meilleure façon d'apprendre le HTML n'est pas de lire sur le HTML, encore moins de mémoriser ses balises : c'est de construire des pages, dans le bon ordre, en voyant le résultat à chaque étape. Les balises ne sont pas un vocabulaire à réciter, ce sont des outils qu'on attrape au moment où on en a besoin.
Au fond, le débutant qui apprenait sa liste par cœur n'avait pas un problème de mémoire. Il avait juste commencé par la fin. Remets la pratique en premier, et le HTML cesse d'être une liste à retenir pour devenir ce qu'il a toujours été : une façon simple de dire au navigateur ce que ton contenu signifie.