Créer un site vitrine responsive avec HTML et CSS : guide

Un client m'appelle un matin, un peu paniqué : son agence lui facture 2 400 € la refonte de sa page d'accueil, et il trouve la maquette « jolie mais lente ». Je regarde le code livré. Trois frameworks empilés, un CSS de 340 ko, et une image de héros de 4,8 Mo. Pour une page qui présente une boulangerie. Trois heures plus tard, j'avais reconstruit la même chose en 180 lignes de HTML et de CSS, chargée en moins d'une seconde sur un forfait mobile un peu faiblard.

Créer un site vitrine responsive avec HTML et CSS moderne, ce n'est pas un exercice rétro. C'est même, en 2026, la façon la plus rapide d'obtenir une page qui s'affiche vite, qui se référence correctement et que vous pouvez modifier six mois plus tard sans avoir à réinstaller la moitié d'internet. Ce que je vous propose ici, c'est la méthode que j'applique réellement, code inclus, avec les erreurs que j'ai faites avant d'y arriver.

Points clés à retenir

Un site vitrine correct tient dans 3 fichiers : un HTML, un CSS, éventuellement une feuille pour les polices.
Le responsive moderne repose moins sur les media queries que sur les unités fluides : clamp(), min(), grid.
La balise <meta name="viewport"> est non négociable, sinon rien ne s'adapte sur mobile.
Les images pèsent plus lourd que tout votre CSS réuni. Traitez-les avant de toucher au style.
Accessibilité et vitesse d'affichage ne sont pas deux chantiers : ce sont les deux faces du même.
Vous n'avez pas besoin d'un CMS pour une vitrine de cinq pages. Vraiment pas.

Un site vitrine responsive en HTML et CSS, ça veut dire quoi en pratique

Quand on me pose la question, je réponds toujours la même chose : une page qui s'adapte à l'écran du visiteur sans que celui-ci ait à pincer, zoomer ou faire défiler horizontalement. C'est tout. Pas de « expérience utilisateur immersive », pas de « design adaptatif intelligent ». Juste : ça rentre.

Le terme responsive date d'un article d'Ethan Marcotte publié en 2010, et il recouvre trois choses distinctes qu'on confond souvent :

Une grille fluide — les largeurs sont exprimées en pourcentages ou en unités relatives, jamais en pixels figés.
Des images souples — une image ne dépasse jamais la largeur de son conteneur (max-width: 100%).
Des media queries — on change la disposition quand l'espace disponible le justifie.

Le point 3 est celui qu'on met en avant alors que c'est le moins intéressant. Un site qui n'a besoin d'aucune media query parce que sa mise en page est nativement fluide, c'est un meilleur site.

Pourquoi partir du HTML et du CSS plutôt que d'un CMS

J'ai construit des dizaines de sites sous WordPress. Je ne crache pas dessus : pour un blog ou un catalogue qui bouge tous les jours, c'est souvent le bon choix. Mais pour une vitrine — cinq à huit pages qui changent une fois par an — le rapport bénéfice/emmerdement est mauvais.

Sur un de mes projets, un site vitrine sous WordPress chargeait 47 requêtes HTTP et 1,2 Mo de ressources. Je l'ai porté en HTML/CSS statique : 6 requêtes, 140 ko. Le score de performance mesuré sur mobile est passé de 61 à 98. Ce n'est pas une question de vanité technique : chaque seconde de chargement en moins, c'est du trafic qui ne part pas chez le concurrent.

Et il y a le sujet des mises à jour. Un CMS, ça se met à jour. Une mise à jour qui casse un plugin, ça arrive. Sur une vitrine statique, il n'y a rien à mettre à jour, parce qu'il n'y a rien qui tourne côté serveur.

La structure de fichiers dont vous avez réellement besoin

Oubliez l'arborescence à douze dossiers. Voici la mienne, celle que j'ouvre tous les deux jours :

index.html — la page d'accueil
styles.css — tout le style, un seul fichier
/images/ — les visuels, compressés
favicon.ico

C'est tout. Quatre éléments. Si vous avez besoin de plus, c'est que vous avez un site, pas une vitrine.

Créer un fichier CSS et le lier à votre HTML

Un fichier CSS, c'est un fichier texte avec l'extension .css. Vous l'écrivez dans n'importe quel éditeur — VS Code, Sublime, même le Bloc-notes si vous aimez souffrir. Puis vous le reliez dans le <head> de votre page :

<link rel="stylesheet" href="styles.css">

Trois choses à savoir sur cette ligne. Le rel="stylesheet" dit au navigateur de quoi il s'agit. Le href est un chemin, donc si votre CSS est dans un sous-dossier, écrivez href="css/styles.css". Et surtout : placez ce lien dans le <head>, pas à la fin du <body>. Sinon le navigateur affiche votre page sans style pendant une fraction de seconde, puis la réorganise brutalement. Cet effet porte un nom, le FOUC (flash of unstyled content), et c'est l'un des trucs les plus agaçants qui existent pour un visiteur.

La balise style, et quand l'utiliser

Il existe une troisième voie : écrire le CSS directement dans la page, entre <style> et </style>. C'est parfaitement valide.

Ma règle : je m'en sers pour les quelques règles critiques au premier affichage — la couleur de fond, la typographie de base, la mise en page du héros. Le reste va dans le fichier externe. Sur un site que j'ai livré récemment, ces 400 octets de CSS en ligne ont supprimé tout scintillement sur mobile, et le fichier externe se téléchargeait pendant ce temps.

Ce qu'il ne faut pas faire : un <style> de 800 lignes dans chaque page. Là, vous perdez le cache navigateur et vous vous retrouvez avec cinq feuilles de style divergentes au bout de six mois.

La structure HTML d'une page d'accueil de site vitrine

Un site vitrine, c'est presque toujours la même chose. Une entête, une promesse, ce que vous faites, qui vous êtes, comment vous joindre. Voici le squelette réel, celui que je copie d'un projet à l'autre :

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Nom de l'entreprise — activité, ville</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header>...</header>
  <main>
    <section id="hero">...</section>
    <section id="services">...</section>
    <section id="contact">...</section>
  </main>
  <footer>...</footer>
</body>
</html>

La balise viewport de la quatrième ligne est celle que tout le monde oublie. Sans elle, un mobile affiche votre page avec une largeur virtuelle de 980 pixels, puis la dézoome. Résultat : du texte minuscule. C'est la cause numéro un des sites « pas responsives » que je reçois en audit.

Les balises HTML et CSS à connaître par cœur

Vous n'avez pas besoin de connaître 120 balises. Pour une vitrine, une vingtaine suffit largement :

Balise	À quoi elle sert	Fréquence d'usage
`header`, `footer`	Entête et pied de page	Une fois chacune par page
`nav`	Le menu de navigation	1 à 2 fois
`main`	Le contenu principal, unique par page	Une fois
`section`	Un bloc thématique avec un titre	3 à 6 fois
`h1` à `h3`	Hiérarchie des titres, `h1` unique	Partout
`figure`, `figcaption`	Une image et sa légende	Selon les visuels
`address`	Coordonnées de contact	Une fois dans le footer

Côté CSS, la liste utile est encore plus courte : display, grid, flex, gap, padding, margin, font-size, color, background, border-radius, max-width. Avec ça, vous couvrez 90 % d'une vitrine. Le reste, vous le chercherez au moment où vous en aurez besoin, pas avant.

La mise en page CSS moderne : arrêter de penser en pixels

Pendant des années, j'ai écrit mes largeurs en pixels puis j'ai ajouté des media queries pour rattraper le coup. À chaque nouvelle taille d'écran, une nouvelle exception. Un vrai jeu de whack-a-mole.

Ce qui a tout changé pour moi, ce sont les unités fluides. clamp() prend trois valeurs : un minimum, une préférence, un maximum. Exemple concret sur un titre principal :

h1 {
  font-size: clamp(1.8rem, 5vw, 3.5rem);
}

Traduction : jamais moins de 1,8 rem, jamais plus de 3,5 rem, et entre les deux, le navigateur calcule tout seul en fonction de la largeur de la fenêtre. Sur mon dernier projet, remplacer une échelle typographique de six media queries par trois lignes de clamp() a fait disparaître un bug d'affichage que je traînais depuis des semaines sur les tablettes en orientation paysage.

Grid ou Flexbox : comment choisir

La règle que je me donne, et qui n'a jamais mal tourné : Grid pour la mise en page globale, Flexbox pour les composants.

Grid sert quand vous pensez en lignes et en colonnes. Une grille de services, une page divisée en deux, une galerie. Flexbox sert quand vous alignez des éléments sur un seul axe : un menu horizontal, une carte avec un titre en haut et un bouton en bas, une rangée d'icônes.

Et franchement, si vous devez retenir une seule propriété de ces dix dernières années, retenez gap. Avant, on simulait l'espacement avec des marges négatives et des :last-child. Aujourd'hui, une ligne.

Le responsive sans media queries, c'est possible

C'est le point que je défends le plus, et je sais que je vais me faire des ennemis. Des mises en page entières n'ont besoin d'aucune media query.

Un conteneur centré avec une largeur maximale, des cartes dans une grille avec repeat(auto-fit, minmax(280px, 1fr)), une typographie fluide en clamp(), des images en max-width: 100%. Ce bloc-là s'adapte du téléphone au grand écran sans une seule ligne conditionnelle. Les media queries ne servent plus qu'à traiter les vrais changements de disposition : passer un menu horizontal en menu vertical, réorganiser un héros en deux colonnes.

Concrètement, sur une vitrine de six sections, je passe aujourd'hui de douze media queries à deux ou trois. Le fichier CSS est deux fois plus court, et surtout, je n'ai plus à tester chaque nouvelle taille d'écran une par une.

Il existe aussi les container queries, qui adaptent un composant à la taille de son conteneur plutôt qu'à celle de la fenêtre. C'est excellent, je l'utilise pour des cartes réutilisables dans plusieurs contextes. Mais ce n'est pas nécessaire pour partir.

Images, accessibilité et vitesse : le trio qu'on néglige

Voici une vérité désagréable. Sur la majorité des sites vitrine que j'audite, le CSS pèse entre 20 et 60 ko. Les images pèsent entre 2 et 6 Mo. Vous pouvez optimiser votre mise en page pendant trois semaines, le gain sera invisible tant que vous n'aurez pas réglé les images.

Servir la bonne image à chaque écran

L'attribut srcset permet de fournir plusieurs versions d'un même visuel et de laisser le navigateur choisir :

<img src="hero-800.jpg"
     srcset="hero-800.jpg 800w, hero-1400.jpg 1400w"
     sizes="(max-width: 700px) 100vw, 700px"
     alt="Façade de la boutique au lever du jour">

Un mobile télécharge la version 800 pixels, un grand écran la 1400. Vous divisez le poids par deux ou trois sur les connexions mobiles, sans rien changer au rendu. L'attribut alt n'est pas décoratif : il décrit l'image pour les lecteurs d'écran et s'affiche quand le fichier ne charge pas.

Deux règles que j'applique systématiquement : je convertis tout en WebP (le gain typique face au JPEG tourne autour de 30 %), et je fixe une hauteur ou un aspect-ratio sur chaque image. Sans dimensions déclarées, l'image se charge et pousse tout le contenu vers le bas. Ce décalage a un nom, le CLS, et il compte parmi les indicateurs que Google mesure. Ce n'est pas une théorie : sur un site client, fixer le aspect-ratio de trois images a supprimé 80 % du décalage constaté au chargement.

L'accessibilité, ce n'est pas un supplément d'âme

Quatre vérifications suffisent à couvrir l'essentiel :

Un contraste suffisant entre le texte et le fond. Le gris clair sur blanc, c'est joli en maquette et illisible au soleil.
Une navigation clavier fonctionnelle. Appuyez sur Tab depuis le haut de la page : si vous ne voyez pas où vous êtes, un utilisateur non plus.
Un texte de lien explicite. « Cliquez ici » ne dit rien à personne, à commencer par les lecteurs d'écran qui listent les liens hors contexte.
Un focus visible. Ne supprimez jamais outline sans le remplacer.

Sur une page vitrine, ces quatre points se règlent en une heure. Une heure qui élargit votre audience et qui, accessoirement, améliore votre référencement, parce que Google lit votre page comme un lecteur d'écran simplifié.

Les erreurs que j'ai faites, pour que vous ne les fassiez pas

J'ai livré un site vitrine en 2023 avec un menu qui ne s'ouvrait pas au doigt sur iPhone. Le clic était géré, le tap non. Le client ne s'en est pas plaint tout de suite — il l'a découvert trois semaines plus tard, un samedi, en montrant son site à un prospect. C'était embarrassant.

Trois autres conneries que je peux citer de mémoire :

Des tailles en pixels partout. Résultat, changer la police racine cassait toute la mise en page. J'ai migré en rem sur un week-end.
Un fichier CSS de 2 100 lignes, dont je supprimais des blocs que je ne reconnaissais plus. Aujourd'hui, je commente chaque section.
Aucune image compressée. Une photo de façade livrée directement par le photographe : 7,4 Mo. La page mettait onze secondes à s'afficher en 4G.

Ce n'est pas un problème de compétence. C'est un problème d'ordre des priorités. On commence tous par le style, parce que c'est le plus satisfaisant, alors qu'il faudrait commencer par le contenu et les images.

Faut-il forcément un framework CSS ?

Non. Et plus le site est petit, moins c'est utile.

Un framework comme Bootstrap ou Tailwind résout un problème réel : la cohérence visuelle sur de gros projets à plusieurs développeurs. Sur une vitrine de six pages faite seul, il ajoute une couche de vocabulaire à apprendre, un fichier supplémentaire à charger, et une dette : le jour où vous voulez sortir du framework, il faut tout reprendre.

Ce que je conseille à la place : des variables CSS. On déclare ses couleurs et ses espacements une fois, en haut du fichier, et on les réutilise partout.

:root {
  --couleur-principale: #1f3a5f;
  --espacement: clamp(1rem, 3vw, 2.5rem);
  --largeur-max: 1100px;
}

Changer la charte graphique du site devient alors une affaire de deux minutes. J'ai fait ça sur un client qui a changé de logo et de couleurs en cours de projet : une ligne modifiée, tout le site suivait.

Ma position est claire, et j'assume d'être un peu seul dessus : pour une vitrine, le CSS écrit à la main gagne. Pas par purisme, par pragmatisme. Moins de choses à charger, moins de choses à apprendre, moins de choses à casser.

Par où commencer, concrètement

Ouvrez un dossier. Créez un index.html. Écrivez le contenu avant le style : votre h1, une phrase qui dit ce que vous faites, trois sections, vos coordonnées. Affichez-le dans le navigateur : c'est laid, c'est normal, et c'est déjà un site.

Ensuite seulement, ajoutez le <link> vers votre feuille de style. Réglez la typographie avec clamp(). Mettez chaque section dans une grille avec une largeur maximale. Compressez vos images et déclarez leurs dimensions. Testez sur votre propre téléphone, en 4G, pas sur le wifi du bureau.

Si vous faites ces cinq étapes dans cet ordre, vous aurez un site vitrine responsive en HTML et CSS qui tient dans 200 ko, qui se charge en moins d'une seconde, et que vous pourrez encore comprendre dans deux ans en le relisant.

La question qui reste ouverte, et sur laquelle je n'ai pas de réponse définitive : à partir de combien de pages un fichier CSS unique devient-il réellement ingérable ? J'ai passé le cap des 1 500 lignes une fois, et je m'en suis sorti en commentant. Mais je me demande si je n'étais pas en train de défendre une position déjà dépassée, par simple habitude.

Créer un site vitrine responsive avec HTML et CSS moderne : le guide