La première fois que j'ai ouvert un fichier HTML, j'ai écrit « Bonjour » dedans, j'ai sauvegardé, j'ai double-cliqué et j'ai vu une page blanche avec trois mots moches en Times New Roman. Pas de mise en page, pas de couleur, rien. Je me souviens très bien de ma réaction : « C'est ça, le web ? »
Oui. C'est ça. Et c'est probablement la meilleure nouvelle que vous lirez aujourd'hui, parce que ce que vous voyez sur les sites que vous admirez repose exactement sur ce mécanisme : un fichier texte, un navigateur, et deux langages qui n'ont rien de magique. Apprendre le HTML et le CSS pour créer son premier site, ce n'est pas apprendre à programmer au sens informatique du terme. C'est apprendre à décrire une structure, puis à décider à quoi elle ressemble.
Ce qui suit est l'ordre dans lequel je ferais les choses si je repartais de zéro aujourd'hui. Avec les erreurs que j'ai commises, celles qui m'ont coûté des semaines, et un angle que la plupart des cours en ligne survolent : mettre réellement votre site en ligne.
Points clés à retenir
- HTML décrit la structure, CSS décide de l'apparence. Confondre les deux est l'erreur n°1 des débutants.
- Trois fichiers suffisent :
index.html,style.css, et le dossier d'images. - On apprend 10 fois plus vite en cassant un code existant qu'en lisant une documentation linéaire.
- Le responsive n'est pas une option de fin de projet : il se pense dès la première balise.
- Un site non mis en ligne n'existe pas. GitHub Pages et Netlify le font gratuitement en moins de dix minutes.
- Les DevTools du navigateur sont votre meilleur professeur. Ils ne mentent jamais.
HTML et CSS : la séparation que personne ne vous explique vraiment
On répète partout que HTML sert au fond et CSS à la forme. C'est vrai, mais ça ne dit pas pourquoi la distinction compte en pratique. Voici le pourquoi : le jour où vous voudrez changer la couleur de tous vos titres sur 40 pages, vous n'aurez pas 40 fichiers à modifier. Un seul.
J'ai appris ça de la mauvaise façon. Sur mon premier projet, je mettais les styles directement dans les balises (« inline », comme on dit), parce que c'était plus rapide sur le moment. Résultat au bout de deux mois : un fichier de plus de 900 lignes où je ne retrouvais plus rien, et une refonte complète à faire à la main. Trois jours perdus. Une leçon retenue.
Ce que chacun fait, concrètement
Le HTML est un langage de balisage. Vous enveloppez du contenu dans des balises qui lui donnent un sens : ceci est un titre, ceci est un paragraphe, ceci est une liste, ceci est un lien. Rien de plus. Le CSS, lui, vient se brancher dessus pour dire : les titres de niveau 2 seront en gris anthracite, avec une graisse de 600, et un espace de 2rem au-dessus.
- Une balise
<h1>signale le titre principal de la page aux moteurs de recherche et aux lecteurs d'écran. - Une balise
<a>crée un lien — sanshref, elle ne fait rien du tout. - Une
<div>ne veut rien dire sémantiquement. On l'utilise pour regrouper, pas pour signifier. - Les balises sémantiques (
<header>,<nav>,<main>,<footer>) existent depuis HTML5 : elles décrivent la fonction d'une zone, et ça change la vie pour l'accessibilité.
À quoi ressemble un vrai fichier de départ
C'est la question qu'on me pose le plus souvent : « montre-moi à quoi ça ressemble, juste un exemple ». Voilà un squelette minimal, celui que je recopie encore aujourd'hui quand j'ouvre un nouveau projet :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Mon premier site</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<header>
<h1>Bienvenue</h1>
</header>
<main>
<p>Ceci est mon premier paragraphe.</p>
</main>
</body>
</html>Deux lignes valent plus que toutes les autres ici. La balise meta viewport dit au navigateur mobile de ne pas simuler un écran de bureau — sans elle, votre site apparaîtra minuscule sur téléphone. Et le <link rel="stylesheet"> est le pont entre vos deux langages. Si votre CSS ne s'applique pas, c'est neuf fois sur dix ce chemin-là qui est cassé.
La méthode qui fonctionne (et celle qui fait perdre des mois)
Le piège classique : avaler un cours complet de A à Z avant d'écrire la moindre ligne. J'ai vu beaucoup de gens démarrer comme ça. Presque aucun n'est allé au bout. Le cerveau ne retient pas une propriété CSS qu'il n'a jamais eu besoin d'appliquer.
Ce qui marche, dans mon expérience, c'est l'inverse : une page à construire, et vous cherchez les morceaux au fur et à mesure. Vous voulez une barre de navigation horizontale ? Vous découvrez display: flex parce que vous en avez besoin ce jour-là. Deux semaines plus tard vous ne l'aurez pas oublié.
Trois projets, dans cet ordre précis
- Une page de présentation personnelle : un titre, trois paragraphes, une photo, une liste de liens. Objectif : maîtriser la structure HTML et les couleurs de base.
- Une page de recettes ou de fiches produits : deux colonnes, une grille, des cartes répétées. Objectif : comprendre le modèle de boîte (box model), les marges, les bordures.
- Une page responsive complète avec en-tête fixe et pied de page. Objectif : media queries et unités relatives.
Le passage du projet 2 au projet 3 est le vrai mur. C'est là que la plupart des débutants que j'ai accompagnés décrochent. Pas parce que c'est difficile, mais parce qu'ils découvrent que ce qu'ils ont construit en pixels fixes s'écroule dès qu'on réduit la fenêtre.
Le responsive, dès la première balise
Un site pensé pour ordinateur puis « adapté » après coup, c'est un chantier de démolition. Un site pensé mobile d'abord, c'est une extension. En pratique : utilisez des unités relatives (rem, %, vw) plutôt que des pixels partout, posez la meta viewport dès le départ, et construisez votre CSS de la petite fenêtre vers la grande.
Rappelons le contexte : en 2026, la majorité du trafic web mondial passe par des terminaux mobiles. Un site non responsive n'est pas « perfectible », il est cassé pour la plupart de vos visiteurs. Franchement, c'est la compétence que je placerais au même niveau que le HTML lui-même.
Mettre son site en ligne : l'étape que tout le monde saute
Curieux constat. La plupart des ressources pour débutants s'arrêtent net une fois la page jolie dans votre navigateur local. Comme si le projet était terminé. Il ne l'est pas : tant que votre site n'est accessible qu'à vous, vous n'avez pas créé un site, vous avez créé un fichier.
L'ironie, c'est que c'est la partie la plus simple. J'ai déployé mon premier vrai projet sur GitHub Pages un dimanche après-midi, en 12 minutes montre en main, sans rien payer. Netlify fait la même chose par glisser-déposer.
| Solution | Coût | Difficulté de mise en place | Bon choix pour… |
|---|---|---|---|
| GitHub Pages | Gratuit | Moyenne (notions Git requises) | Un site statique que vous versionnez |
| Netlify | Gratuit sur l'offre de base | Faible (glisser-déposer un dossier) | Déployer en cinq minutes, sans ligne de commande |
| Hébergeur classique + nom de domaine | Quelques euros par mois | Élevée (FTP, DNS, certificats) | Quand vous voulez une adresse à vous |
Faut-il un nom de domaine et du HTTPS ?
Pour un premier projet, non — l'adresse fournie par la plateforme suffit largement. En revanche, dès que vous voulez partager le lien sérieusement (portfolio, candidature, client), un domaine à vous coûte une dizaine d'euros par an et change complètement la perception. Le HTTPS, lui, n'est plus un choix : les deux solutions gratuites citées ci-dessus l'activent automatiquement. Ne construisez jamais un site qui demande un mot de passe sur une connexion non chiffrée.
Les outils, et les erreurs que j'ai vraiment commises
Un éditeur de code correct (VS Code est le standard de fait), un navigateur récent, et c'est tout. Pas besoin d'environnement de développement complexe pour du HTML et du CSS. Les DevTools, accessibles par F12, sont votre meilleur professeur : vous modifiez une valeur CSS en direct et vous voyez immédiatement l'effet. J'y ai passé des heures au début, et honnêtement, j'ai appris plus là-dedans qu'en lisant trois tutoriels.
- Oublier de fermer une balise et passer 40 minutes à chercher pourquoi la mise en page est décalée.
- Écrire
style.cssdans le lien alors que le fichier s'appellestyles.css. Le pluriel. Toujours le pluriel. - Utiliser
!importantpour « réparer » un conflit CSS. Ça marche. Puis ça vous explose au visage trois semaines plus tard. - Mélanger les identifiants et les classes sans logique. Aujourd'hui je n'utilise quasiment que des classes pour le style.
Un mot sur les validateurs : passez votre code dans le validateur du W3C de temps en temps. Ce n'est pas obligatoire, mais une page valide est une page qui s'affichera de la même façon dans tous les navigateurs, ce qui n'est pas un luxe quand on débute.
Combien de temps avant de savoir faire un site ?
Question honnête, réponse honnête : avec une heure par jour, comptez environ six semaines pour produire une page statique correcte et responsive, en autonomie. Trois mois si vous ajoutez la mise en ligne, un peu d'accessibilité et un vrai souci du détail visuel.
Ce qui fait la différence n'est pas le talent, c'est de toucher le code tous les jours, même vingt minutes. J'ai vu des gens progresser plus vite en 30 minutes quotidiennes qu'en sessions de six heures le week-end. La régularité gagne. Toujours.
Faut-il apprendre JavaScript avant le HTML et le CSS ?
Non, et c'est même l'ordre inverse qui a du sens. Le HTML et le CSS n'ont pas de logique de programmation : ce sont des langages de description. Les apprendre d'abord vous donne une base visuelle concrète, sur laquelle le JavaScript viendra ensuite se brancher pour ajouter de l'interaction.
Un framework CSS comme Bootstrap, c'est une bonne idée pour débuter ?
Plus tard. Un framework masque le fonctionnement réel des grilles et des marges. Si vous commencez par lui, vous saurez assembler des composants sans comprendre pourquoi ils s'alignent. Faites au moins deux projets en CSS « à la main » avant d'envisager un framework.
Il y a une chose que je n'avais pas anticipée quand j'ai écrit mon premier « Bonjour » dans ce fichier HTML : la sensation de voir quelque chose apparaître à l'écran, et de savoir exactement pourquoi. C'est bête, mais c'est ce qui accroche. Le premier site que vous mettrez en ligne sera probablement laid. Le deuxième aussi, un peu moins. Le dixième, quelqu'un vous demandera qui l'a fait — et vous pourrez répondre : moi, avec un fichier texte et beaucoup de tâtonnements.
