La première fois que j'ai ouvert un fichier .html, j'ai écrit « Bonjour » dedans, j'ai sauvegardé, et j'ai regardé le navigateur. Rien. Pas de page. Un fichier texte. J'avais oublié les balises. Ce petit raté résume bien tout : le HTML et le CSS ne pardonnent pas l'à-peu-près, mais ils pardonnent tout le reste — la maladresse, les noms de fichiers bancals, les couleurs douteuses. C'est probablement pour ça que je continue à conseiller ce point de départ à quiconque veut créer son premier site, en 2026, même à l'heure des constructeurs visuels.
Les bases du HTML et du CSS tiennent en une soirée. Sérieusement. Pas pour devenir développeur, mais pour avoir une page en ligne à vous, que vous comprenez de bout en bout.
Points clés à retenir
- Le HTML décrit le sens du contenu, le CSS décide de son apparence. Deux rôles, deux fichiers, une seule page.
- Un site minimal, c'est un fichier
index.html, un fichierstyle.css, et une ligne<link>qui les relie. - Les balises s'ouvrent et se ferment. La structure est hiérarchique, pas décorative.
- Trois sélecteurs CSS suffisent à styliser une page entière : la balise, la classe, l'identifiant.
- La mise en ligne n'est pas une étape avancée : GitHub Pages héberge un site statique gratuitement, sans carte bancaire.
- L'erreur n°1 des débutants n'est pas une faute de syntaxe, c'est un mauvais nom de fichier.
Pourquoi HTML et CSS sont le duo fondamental d'un premier site
Le navigateur ne voit pas votre page comme vous. Il lit un flux de texte, ligne après ligne, et il se demande à chaque balise : « qu'est-ce que c'est ? ». Un titre ? Une liste ? Une image ? Un paragraphe ?
Le HTML répond à cette question. Le CSS répond à une autre : « à quoi ça ressemble ? ». Et c'est tout. Toute la confusion des débutants vient de là — on essaie de faire faire au HTML un travail de CSS, ou l'inverse.
Séparer le fond de la forme, la seule bonne habitude à prendre tout de suite
J'ai vu passer des pages où chaque titre portait son attribut style="color: blue; font-size: 32px" directement dans la balise. Ça marche. Ça marche même très bien jusqu'au jour où vous voulez changer le bleu. Là, vous ouvrez le fichier, vous cherchez toutes les occurrences, vous en oubliez deux, et votre site a l'air bricolé.
Avec un fichier CSS séparé, vous changez une ligne, et les quarante titres suivent. C'est la différence entre repeindre une pièce et refaire la peinture de tout l'immeuble à la main.
| Ce que vous voulez faire | Qui s'en occupe | Balise ou propriété |
|---|---|---|
| Dire « ceci est un titre de niveau 1 » | HTML | <h1> |
| Dire « ce texte est un paragraphe » | HTML | <p> |
| Poser un lien vers une autre page | HTML | <a href="…"> |
| Changer la couleur de tous les titres | CSS | h1 { color: … } |
| Espacer les paragraphes entre eux | CSS | margin-bottom |
| Centrer le contenu de la page | CSS | max-width + margin: auto |
Cette séparation n'est pas une coquetterie d'expert. C'est ce qui rend un site modifiable six mois plus tard, quand vous aurez oublié pourquoi vous aviez mis du violet partout.
Le squelette d'une première page, à recopier tel quel
Voici le fichier que j'aurais aimé qu'on me donne au départ. Vous le copiez, vous l'enregistrez sous le nom index.html, vous double-cliquez dessus, et il se passe quelque chose dans le navigateur.
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Mon premier site</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<h1>Bienvenue chez moi</h1>
<p>Ceci est mon tout premier paragraphe.</p>
<a href="https://example.com">Un lien vers ailleurs</a>
</body>
</html> Trois choses méritent qu'on s'y arrête.
Le doctype, la langue et l'encodage : les trois lignes qu'on saute et qu'on regrette
La première ligne, <!DOCTYPE html>, dit au navigateur « applique les règles modernes ». Sans elle, il bascule dans un mode de compatibilité hérité des années 2000, et vos marges se comportent bizarrement. Vous passerez une heure à chercher pourquoi votre width ne fait pas ce que vous voulez.
lang="fr" sert aux lecteurs d'écran et aux moteurs de recherche. <meta charset="utf-8"> empêche les accents de s'afficher en caractères illisibles. Si vous voyez un « é » à la place d'un « é », c'est cette ligne qui manque.
Et la ligne <link rel="stylesheet" href="style.css"> : c'est le pont entre vos deux fichiers. Sans elle, votre page reste en Times New Roman noir sur blanc, et vous vous demandez pourquoi votre CSS « ne marche pas ». Neuf fois sur dix, le problème est là. Le fichier existe, mais le navigateur ne le trouve pas — souvent parce qu'il est dans un autre dossier, ou parce que le nom est écrit Style.css avec une majuscule.
CSS : les sélecteurs qu'on utilise à 90 %
Le CSS se présente toujours de la même façon : un sélecteur, des accolades, des propriétés avec leurs valeurs. Trois sélecteurs couvrent l'immense majorité de ce que vous ferez sur un premier site.
- La balise —
p { }cible tous les paragraphes. - La classe —
.encadre { }cible tous les éléments qui portentclass="encadre". Réutilisable à volonté. - L'identifiant —
#entete { }cible l'unique élément qui porteid="entete". Un seul par page.
La règle que je répète sans arrêt : pour du style, utilisez des classes, jamais des identifiants. Les identifiants sont trop puissants — ils écrasent tout — et on finit par se battre contre sa propre page.
Un fichier style.css qui rend cette page lisible en dix lignes :
body {
font-family: system-ui, sans-serif;
max-width: 700px;
margin: 2rem auto;
padding: 0 1rem;
line-height: 1.6;
}
h1 { color: #1a5276; } Le max-width: 700px avec margin: auto centre le contenu et l'empêche de s'étaler sur toute la largeur de l'écran. Ce n'est pas un détail esthétique : un texte qui court sur 1200 pixels est pénible à lire, et c'est la première chose qui trahit un site fait à la va-vite.
Les erreurs qu'on fait tous, et pourquoi elles font perdre du temps
J'ai perdu une soirée entière sur un fichier nommé index.HTML en majuscules. Le navigateur, sur un serveur Linux, ne sait pas faire l'équivalent. Mon fichier s'appelait Index.html, mon lien pointait vers index.html, et il ne se passait rien. Le message d'erreur ne dit jamais « vérifie la casse », il dit « 404 ».
« Mon CSS ne s'applique pas » : la checklist dans l'ordre
Avant de soupçonner votre code, vérifiez ceci, dans cet ordre :
- Le fichier s'appelle bien
style.css, tout en minuscules, dans le même dossier que le HTML. - La ligne
<link>est bien placée dans le<head>, pas après</head>. - L'accolade ouvrante et l'accolade fermante sont présentes. Une accolade oubliée et tout le bloc suivant est ignoré en silence.
- Le point-virgule termine bien chaque propriété. Lui aussi fait échouer la ligne sans rien dire.
- Vous avez bien rechargé avec Ctrl + Maj + R (ou Cmd + Maj + R). Le cache du navigateur garde l'ancienne version du CSS avec un entêtement remarquable.
Ce dernier point m'a fait douter de mes compétences plus souvent que n'importe quelle erreur de syntaxe. Le navigateur affichait mon ancien design, et je corrigeais un fichier que personne ne lisait.
Pourquoi je déconseille l'attribut style directement dans les balises
Sauf pour un test de trente secondes, jamais. Une fois qu'un style est posé en ligne, il devient prioritaire sur votre feuille externe, et vous ne le voyez plus dans style.css. Vous cherchez pendant vingt minutes une règle qui n'existe pas dans le fichier que vous éditez. Ce n'est pas une question de propreté théorique : c'est du temps perdu, concrètement.
Mettre son site en ligne pour de vrai
C'est le chaînon que tout le monde saute. On code une page qui s'affiche en local, on est content, et on s'arrête là — parce que personne n'explique l'étape suivante. Or elle tient en quinze minutes.
Comment héberger un site statique sans payer
Un site HTML/CSS est ce qu'on appelle un site statique : des fichiers, rien d'autre. Pas de base de données, pas de serveur à administrer. GitHub Pages héberge ce type de site gratuitement, et sans carte bancaire. Vous créez un dépôt, vous y déposez index.html et style.css, vous activez Pages dans les réglages du dépôt, et vous obtenez une adresse publique de la forme votrepseudo.github.io. Netlify et Vercel font la même chose avec un simple glisser-déposer de dossier.
Le nom de domaine, lui, reste payant — comptez une dizaine d'euros par an pour un .fr. C'est un choix, pas une obligation : l'adresse fournie par l'hébergeur suffit largement pour un premier site.
Un point que je n'ai compris qu'après coup : une page locale s'ouvre avec l'adresse file:///…, et une page publiée avec https://…. Certaines ressources se comportent différemment selon le cas. Si quelque chose marche en local et pas en ligne, cherchez de ce côté avant de remettre en cause votre code.
Faut-il tout apprendre avant d'écrire la première ligne ?
Non, et c'est probablement le conseil qui m'a le plus servi. J'ai passé des heures, au début, à lire des pages sur des propriétés que je n'ai jamais utilisées. Le CSS moderne compte des centaines de propriétés. Vous en manipulerez une quinzaine sur un site simple.
La bonne boucle ressemble à ça : vous voulez un encadré autour d'un paragraphe → vous cherchez « bordure CSS » → vous trouvez border, vous l'appliquez, vous voyez le résultat. Vous avez appris une propriété et sa raison d'être. Trente secondes, contre dix minutes de lecture théorique.
Les outils de développement du navigateur, accessibles avec F12, complètent le dispositif. Vous cliquez sur un élément, vous voyez exactement quelles règles CSS s'appliquent et lesquelles sont barrées. La première fois qu'on comprend que les règles barrées sont celles qui ont perdu la bataille, beaucoup de choses s'éclairent.
Faut-il apprendre le JavaScript tout de suite ?
Pas pour un premier site vitrine, une page de présentation ou un portfolio. Le HTML et le CSS suffisent à produire quelque chose de propre et de fonctionnel. Le JavaScript viendra quand vous voudrez un menu qui s'ouvre au clic, un formulaire qui réagit, ou du contenu chargé sans recharger la page. Y toucher trop tôt, c'est empiler trois technologies qu'on ne maîtrise aucune.
Mon avis, et je l'assume : mieux vaut une page HTML/CSS terminée, en ligne, imparfaite mais réelle, que dix tutoriels suivis sans jamais publier. La mise en ligne est ce qui transforme une exercice en site. C'est aussi le moment où l'on découvre qu'on ne savait pas ce qu'était un chemin relatif.
Et ce fichier index.html que vous ouvrirez dans deux ans, avec ses couleurs mal choisies et son mauvais espacement — vous le relirez avec un mélange de gêne et de tendresse. C'est le signe que vous avez progressé. Le reste, c'est de la répétition.