Créer un site web responsive étape par étape : le guide complet

Un client m'appelle, paniqué. Sa page d'accueil s'affiche correctement sur son iMac, mais sa femme lui montre le même site sur son iPhone : le menu déborde, les images dépassent de l'écran, il faut zoomer pour lire un bouton. « C'est quoi ce bordel ? » Verdict : il avait construit tout en largeurs fixes. En pixels. Comme en 2010. Deux heures plus tard, le site passait de honteux à propre, sans refonte graphique.

Voilà ce que signifie créer un site web responsive étape par étape : ce n'est pas une couche magique qu'on ajoute en fin de projet. C'est une discipline qui commence à la première ligne de CSS, et qui se termine par des tests sur de vrais appareils. Je vous montre comment je procède, dans l'ordre, avec les bouts de code qui comptent.

Comprendre le responsive design avant d'écrire une ligne de code

Le responsive design, c'est un site qui s'adapte à la taille de l'écran, pas un site « version mobile » séparé. Le navigateur calcule la largeur disponible, applique vos règles CSS conditionnelles, et réorganise les blocs. C'est tout. Le reste, c'est de la technique.

Deux approches existent, et je vais être franc : l'une est meilleure que l'autre.

Mobile-first ou desktop-first : laquelle choisir ?

Le mobile-first consiste à écrire d'abord le CSS pour petit écran, puis à ajouter des règles pour les écrans plus larges via min-width. Le desktop-first fait l'inverse, avec max-width.

Pourquoi je pousse le mobile-first ? Parce que votre CSS de base est forcément simple. Vous partez d'une colonne, d'un menu empilé, d'images fluides. Ensuite vous enrichissez. Dans l'autre sens, vous écrivez tout en grand, puis vous devez défaire, casser, réorganiser. J'ai passé des heures sur des !important parce que j'avais commencé par le desktop. Plus jamais.

Petit bémol : sur un projet purement B2B avec une interface dense de tableaux, le desktop-first a parfois du sens. Mais c'est l'exception, pas la règle.

Étape 1 : la balise viewport, votre passeport pour le mobile

Sans cette ligne dans le <head>, un iPhone affichera votre page comme s'il s'agissait d'un écran de 980 pixels de large, puis la réduira. Vos media queries s'activeront sur les mauvaises valeurs. Résultat : un site minuscule, illisible, avec tout le monde qui zoome.

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

width=device-width dit au navigateur d'utiliser la largeur réelle de l'appareil. initial-scale=1 empêche le zoom automatique au chargement. C'est la fondation. Tout le reste s'appuie dessus.

Étape 2 : bannir les pixels, adopter les unités relatives

Voici l'erreur que j'ai commise pendant des mois : penser qu'utiliser % partout suffisait. Faux. Les pourcentages gèrent la largeur, mais pas la typographie ni les espacements.

Mes unités de référence aujourd'hui :

• rem pour les tailles de police et les marges verticales (1 rem = taille de police racine, généralement 16px)
• % pour les largeurs de conteneurs
• vw et vh avec parcimonie, pour des éléments plein écran uniquement, jamais pour du texte
• em quand je veux qu'une taille soit relative à son parent

Un exemple concret : je remplace systématiquement font-size: 18px par font-size: 1.125rem. Si l'utilisateur augmente la police de son navigateur pour raisons d'accessibilité, l'ensemble suit. En pixels, rien ne bouge. C'est un détail qui paraît anodin et qui change tout pour les personnes malvoyantes.

Étape 3 : structurer avec Flexbox et Grid

Les float et les display: inline-block sont morts. Flexbox gère l'alignement sur un axe, Grid gère les deux dimensions. Je les combine : Grid pour le squelette des pages, Flexbox à l'intérieur des composants.

Un exemple de grille de cartes qui passe de 3 colonnes sur desktop à 1 colonne sur mobile, sans media query :

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

Cette seule ligne remplace trois media queries. auto-fit crée autant de colonnes que possible, minmax(280px, 1fr) garantit qu'aucune carte ne descend sous 280 pixels. Sur un téléphone, vous obtenez une colonne. Sur un écran de 1200 pixels, trois ou quatre. Aucune règle conditionnelle à écrire.

Je l'admets : la première fois que j'ai vu cette syntaxe, j'ai cru à une blague. Aujourd'hui, c'est mon point de départ pour toute mise en page en grille.

Étape 4 : les media queries, mais avec parcimonie

Beaucoup croient qu'un site responsive, c'est une collection de media queries. C'est faux. Les media queries servent à ajuster, pas à reconstruire.

Mes breakpoints de référence, en 2026 :

Cible	Breakpoint	Ce qu'on ajuste
Smartphones	base, aucun media query	CSS mobile-first
Tablettes	min-width: 768px	Passage en 2 colonnes, menu horizontal
Desktop	min-width: 1024px	3 colonnes, marges généreuses
Très grand écran	min-width: 1440px	Largeur maximale du conteneur

Trois ou quatre points suffisent sur la majorité des sites. Si vous en avez quinze, c'est que votre CSS de base est mal fichu.

Comment rendre un site responsive en HTML et CSS ?

Trois choses, dans cet ordre. La balise meta viewport dans le HTML. Des unités relatives partout dans le CSS. Et une mise en page qui ne repose pas sur des largeurs fixes. Si votre HTML et votre CSS respectent ces trois règles, votre site est responsive. Les frameworks ne sont qu'un confort, pas une condition.

Étape 5 : les images, principal coupable des sites lents

Une image de 4000 pixels de large chargée à 100 % de sa taille sur mobile, c'est plusieurs mégaoctets pour un affichage de 375 pixels. Le navigateur télécharge tout, puis réduit. Catastrophique pour la performance.

Deux solutions. La plus simple :

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

Trois lignes, appliquées globalement, éviteront 90 % des débordements d'images. La plus fine : l'attribut srcset, qui propose plusieurs versions de la même image et laisse le navigateur choisir la plus adaptée au réseau et à l'écran.

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Description">

Le gain de performance est mesurable : sur un projet récent, passer au srcset a fait tomber le temps de chargement de la page d'accueil sur 4G de 4,2 secondes à 1,8 seconde. Sans rien changer d'autre. C'est le type d'optimisation qui rapporte immédiatement.

Étape 6 : tester et déboguer, la partie que tout le monde saute

Vous avez votre CSS. Vous ouvrez le mode responsive des DevTools, vous passez de 375 à 1440 pixels. Tout est propre. Félicitations, vous n'avez rien testé.

Le DevTools ment. Il simule une largeur, pas un appareil réel. Les tailles de police système diffèrent, les zones tactiles se comportent autrement, certains navigateurs mobiles interprètent le viewport de façon inattendue.

Ma routine, systématique :

1. DevTools sur les breakpoints principaux, pour la structure
2. Un vrai téléphone Android et un vrai iPhone, pour le tactile
3. Une tablette, en portrait puis en paysage
4. Zoom navigateur à 150 %, pour vérifier que rien ne déborde
5. Test avec police agrandie dans les paramètres système, pour l'accessibilité

Le cinquième point, je l'ai ajouté après qu'un utilisateur m'a envoyé une capture d'écran : avec la police système agrandie, tout son menu passait sous le logo. Je n'y avais pas pensé. C'était une leçon à 30 minutes de correction.

Une application responsive, c'est la même recette ?

Oui, avec une différence de taille. Une application web utilise les mêmes principes CSS, mais ajoute souvent une gestion d'états et d'interactions tactiles. Les media queries restent, mais on les combine avec des détections de capacités (présence du tactile, préférence de thème, orientation). Le socle HTML/CSS décrit ici reste valable. Seule la couche applicative change.

Les pièges qui coûtent cher

Trois erreurs m'ont fait perdre des journées entières, et je les vois encore régulièrement dans des projets que l'on me confie.

Les hauteurs fixes. Un height: 600px sur une section fonctionne sur desktop et casse tout sur mobile en paysage. Préférez min-height ou aucune hauteur du tout.

Le débordement horizontal. Un élément plus large que le viewport crée une barre de défilement horizontale, et tout le site semble cassé. La cause est souvent un width: 100vw combiné à un padding, car 100vw inclut la barre de défilement elle-même. Je le remplace maintenant quasi systématiquement par width: 100%.

Les tableaux non traités. Un tableau de dix colonnes sur un écran de 375 pixels, c'est l'enfer. Soit on le transforme en cartes empilées via CSS, soit on l'enveloppe dans un conteneur à défilement horizontal avec overflow-x: auto. Ne laissez jamais un tableau se débrouiller seul.

Ce qui reste après avoir tout appliqué

Un site responsive correctement construit ne se voit pas. Personne ne dit « tiens, ce site est responsive ». Les gens lisent, cliquent, achètent. C'est le signe que ça marche.

La question que je me pose aujourd'hui n'est plus « comment rendre ce site responsive », mais « jusqu'où pousser l'adaptation ». L'écran pliable, la montre connectée, les affichages embarqués dans les voitures, tout cela pose des questions que le viewport tel qu'on le connaît ne résout pas entièrement. La prochaine étape n'est peut-être plus la taille de l'écran, mais le contexte d'usage : debout, en mouvement, à une main. Et ça, aucune media query ne sait encore le détecter.