Créer un site web responsive avec HTML et CSS : le guide complet

Un site cassé sur mobile alors que tout semble parfait sur ordinateur ? Le coupable est souvent une seule ligne oubliée. Découvrez la méthode mobile-first complète, du meta viewport aux media queries, pour un site responsive qui tient enfin debout.

Créer un site web responsive avec HTML et CSS : le guide complet

Un client m'appelle un jour, paniqué : « Mon site est tout cassé sur mon téléphone, les gens cliquent et rien ne se passe. » Je regarde sur mon écran. Tout est parfait. Je réduis la fenêtre de mon navigateur. Tout est parfait. Le problème ? Il n'y avait pas une seule ligne de CSS responsive dans le projet. À partir d'environ 800 pixels de large, tout partait en vrille et les liens se chevauchaient. Le pire, c'est qu'il avait bien une règle média dans sa feuille de style. Une seule. Mal écrite. Et elle ne servait à rien.

Créer un site web responsive avec HTML et CSS, ce n'est pas une histoire de framework miracle ni de plugin à installer. C'est une méthode. Quelques balises bien placées, une logique de mise en page qui part du mobile et remonte, et beaucoup de rigueur sur les détails qu'on oublie. Voici comment je m'y prends aujourd'hui, avec le code.

Points clés à retenir

  • La balise <meta name="viewport"> est obligatoire. Sans elle, aucune media query ne fonctionnera correctement sur mobile.
  • Une méthode mobile-first évite 80% des bugs de débordement horizontal.
  • Les unités relatives (rem, %, vw) remplacent les pixels fixes dans presque tous les cas.
  • Flexbox gère les alignements et les lignes d'éléments. Grid gère les structures de page entières.
  • Les images ont besoin de max-width: 100% et d'un height: auto, sinon elles cassent la mise en page.
  • On teste dans les DevTools du navigateur avant de publier, jamais après.

La première ligne à écrire (et celle que tout le monde oublie)

Avant de toucher au CSS, il faut parler au navigateur. Sur un smartphone, celui-ci suppose par défaut qu'il affiche une page conçue pour un écran d'ordinateur, large de 980 pixels. Résultat : il dézoome tout pour que ça rentre, le texte devient minuscule, et vos media queries ne se déclenchent jamais comme prévu.

La solution tient en une balise, dans le <head> :

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Traduction : « prends la largeur réelle de l'appareil, et n'applique aucun zoom au chargement ». Sans cette ligne, vous pouvez écrire le plus beau CSS responsive du monde, il ne servira à rien. J'ai perdu une demi-journée là-dessus la première fois. Je cherchais un bug dans mes media queries alors que le problème était dans le HTML.

La structure HTML minimale d'une page responsive

Un squelette propre, avec les balises sémantiques qui vont bien :

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Mon site</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <header>…</header>
  <nav>…</nav>
  <main>…</main>
  <footer>…</footer>
</body>
</html>

Je sais, ça paraît basique. Mais la moitié des projets que je reprends ont un <body> rempli de <div> sans queue ni tête. Le HTML sémantique ne rend pas le site responsive à lui seul, mais il rend le CSS lisible et prévisible, ce qui revient au même au moment de déboguer.

Mobile-first ou desktop-first : quelle méthode choisir ?

Question que l'on me pose à chaque formation. Ma réponse est tranchée : commencez par le mobile. Toujours.

La raison est simple. Un site conçu d'abord pour un écran large doit ensuite être « dégradé » pour les petits écrans, et cette dégradation implique de retirer, cacher, réorganiser. Un site conçu d'abord pour un écran étroit s'enrichit ensuite quand l'espace augmente. Ajouter est toujours plus simple que retirer. C'est aussi une question de performance perçue : la majorité du trafic arrive aujourd'hui depuis un téléphone, donc concevoir pour ce cas est le choix par défaut logique.

Comment écrire une media query qui fonctionne

La syntaxe de base, avec une approche mobile-first, donc des conditions min-width :

/ Styles par défaut : mobile /
.conteneur {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 1rem;
}

/ À partir de 768px : tablette et plus /
@media (min-width: 768px) {
  .conteneur {
    flex-direction: row;
    justify-content: space-between;
    padding: 2rem;
  }
}

/ À partir de 1024px : desktop /
@media (min-width: 1024px) {
  .conteneur {
    max-width: 1200px;
    margin: 0 auto;
  }
}

Deux règles à ne pas enfreindre. Un : n'utilisez pas max-width si vous partez du mobile, vous allez dans le sens inverse et vous empilez les exceptions. Deux : ne multipliez pas les breakpoints. Trois paliers — mobile, tablette, desktop — couvrent la quasi-totalité des cas réels. J'ai vu des feuilles de style avec onze breakpoints. Ingérable.

Quels breakpoints standards utiliser ?

Il n'y a pas de chiffre magique, mais une base éprouvée :

  • 480px — petits téléphones en paysage
  • 768px — tablettes en portrait
  • 1024px — tablettes en paysage et petits ordinateurs portables
  • 1280px et au-delà — écrans de bureau confortables

Mon conseil : ne fixez pas vos breakpoints sur des appareils précis. Fixez-les là où votre design commence à casser. Ouvrez les DevTools, réduisez la fenêtre lentement, et notez la largeur exacte où la mise en page devient laide. C'est votre breakpoint.

Flexbox ou CSS Grid : lequel choisir ?

Question devenue un vrai marqueur générationnel. On me la pose comme si les deux s'excluaient. Ils ne s'excluent pas, ils travaillent ensemble.

Critère Flexbox CSS Grid
Nature Une dimension (ligne ou colonne) Deux dimensions (lignes et colonnes)
Cas d'usage idéal Barre de navigation, alignement d'icônes, rangée de boutons Grille de cartes, mise en page globale, galerie
Gestion du débordement Automatique avec flex-wrap Moins naturelle, nécessite des tailles de piste explicites
Courbe d'apprentissage Douce Plus raide, mais plus puissante
Compatibilité Excellente, y compris anciens navigateurs Excellente partout depuis plusieurs années

Ma règle personnelle : Grid pour le squelette de la page (header, main, footer, sidebar), Flexbox pour tout ce qui vit à l'intérieur de ces blocs. Une carte de produit ? Grid pour le placement des cartes, Flexbox pour aligner le prix et le bouton à l'intérieur.

Un piège classique : la grille qui ne devient jamais responsive parce que les colonnes sont définies en pixels fixes. Utilisez repeat(auto-fit, minmax(280px, 1fr)) et la grille s'adapte toute seule au conteneur, sans media query :

.galerie {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 1.5rem;
}

Cette ligne m'a fait gagner des heures sur mon dernier projet. Plus besoin de breakpoint pour la galerie, elle se réorganise toute seule.

Les erreurs qui cassent un site responsive (et comment les corriger)

Elles sont toujours les mêmes. Je les retrouve dans presque tous les projets que l'on me confie pour audit.

Les erreurs qui cassent un site responsive (et comment les corriger)

Les images qui débordent de leur conteneur

Une image non contrainte impose sa largeur naturelle. Si elle fait 1200 pixels et que l'écran fait 375, elle pousse tout le reste hors de la page. Deux lignes règlent le problème :

img {
  max-width: 100%;
  height: auto;
}

J'applique aussi display: block sur les images, pour éliminer l'espace fantôme sous la ligne de base. Détail mineur, mais qui gêne dans les mises en page serrées.

Le débordement horizontal inexpliqué

Vous faites défiler vers la droite et la page continue. Frustrant, et souvent invisible sur grand écran. La cause est presque toujours un élément plus large que son parent : un width: 100vw combiné à une barre de défilement, un padding qui s'ajoute à une largeur déjà à 100%, ou un tableau non contraint.

Pour diagnostiquer, j'ajoute temporairement cette règle, qui surligne tous les éléments trop larges :

* {
  outline: 1px solid red;
}

L'élément fautif saute aux yeux immédiatement. Ensuite, on corrige : soit on remplace les width: 100% par max-width: 100%, soit on passe en box-sizing: border-box dès le départ — ce que je fais systématiquement avec une règle globale.

Les tableaux qui refusent de s'adapter

Un tableau de données a une largeur minimale imposée par son contenu. Sur mobile, il déborde. Trois solutions, par ordre de préférence :

  1. Le rendre défilable horizontalement dans un conteneur dédié : overflow-x: auto
  2. Le transformer en « cartes » empilées via des media queries (plus de travail, meilleure lecture)
  3. Masquer les colonnes secondaires sur petit écran

L'option 1 est rapide et souvent suffisante. Je mets toujours un tabindex="0" sur le conteneur pour que le défilement reste accessible au clavier.

Comment tester son site responsive avant publication

Ouvrez les DevTools de votre navigateur, activez le mode appareil (F12, puis l'icône de téléphone). Vous pouvez simuler n'importe quelle taille, y compris des appareils précis. Mais attention : ce n'est pas un vrai test. Le simulateur ne reproduit ni la puissance d'un vieux téléphone, ni la connexion lente, ni les comportements tactiles réels.

Ma méthode : DevTools pour déboguer pendant le développement, puis test sur un vrai téléphone, avec une vraie connexion, avant la mise en ligne. C'est là que l'on trouve les vrais problèmes : zones tactiles trop petites, textes illisibles, images surdimensionnées qui ralentissent le chargement.

Passez aussi un audit dans le navigateur. Les outils intégrés signalent les images trop lourdes, les ressources bloquantes, les problèmes d'accessibilité de base. Le responsive et la performance sont liés, pas séparés : une image de 4 Mo qui se « contente » de rétrécir sur mobile reste une image de 4 Mo à télécharger.

Responsive ou adaptive : quelle différence ?

La confusion revient souvent. Un site responsive s'adapte en continu à toutes les largeurs possibles, grâce aux unités relatives et aux media queries. Un site adaptatif (adaptive) est conçu pour quelques tailles précises : une version mobile, une tablette, une desktop, avec des sauts entre les deux. Le responsive est plus souple, plus élégant, et c'est ce que l'on fait aujourd'hui dans l'immense majorité des cas.

Ce qui compte vraiment

Retenez trois choses, dans cet ordre. La balise viewport, sans laquelle rien ne fonctionne. La méthode mobile-first, qui élimine la majorité des bugs par construction. Et un test sur un vrai appareil, qui révèle ce que le simulateur cache.

Le reste, c'est de la pratique. Vous pouvez lire dix tutoriels sur Flexbox sans jamais réussir à aligner un bouton correctement jusqu'au jour où vous le faites dans un vrai projet, avec un vrai chaos de départ. C'est là que ça rentre.

La prochaine fois que vous verrez votre page se casser sur un écran étroit, ne cherchez pas un framework. Ouvrez le HTML, vérifiez la balise viewport, puis remontez la liste de vos media queries. Neuf fois sur dix, le coupable est déjà là.

Damien Marchand

Damien Marchand

Damien Marchand est un spécialiste reconnu en sécurité des réseaux, en tests d'intrusion et en cryptographie appliquée. Au fil de sa carrière, il a accompagné de nombreuses organisations dans le renforcement de leurs défenses et la protection de leurs données sensibles. Passionné par la transmission, il partage volontiers son expertise pour aider les équipes à mieux appréhender les enjeux actuels de la cybersécurité.

Voir tous les articles →

Articles similaires