La première fois que j'ai ouvert un site que je venais de finir sur mon téléphone, j'ai cru que le CSS avait sauté. Titre collé au bord, texte qui débordait, un bouton large comme trois doigts. Le site était parfait sur mon écran 24 pouces. Sur mobile, c'était une catastrophe.
Créer un site web responsive avec HTML et CSS, ce n'est pas une option qu'on ajoute à la fin. C'est une façon de coder dès la première ligne. Et la bonne nouvelle, c'est qu'il n'y a rien de magique là-dedans : quelques balises, quelques règles CSS, et beaucoup de discipline.
Points clés à retenir
- La balise viewport dans le
<head>est non négociable : sans elle, rien d'autre ne fonctionne sur mobile. - Une mise en page fluide (pourcentages,
rem,clamp()) règle 70 % du problème avant même d'écrire une media query. - L'approche mobile-first évite de repenser toute votre grille à la fin.
- Les images ont besoin d'une largeur maximale à 100 % et, quand c'est pertinent, d'un attribut
srcset. - Flexbox pour les composants d'une ligne, Grid pour les structures de page. Les deux, pas l'un contre l'autre.
- Testez dans le navigateur, pas dans votre tête : le mode responsive des DevTools reste votre meilleur allié.
Comprendre ce que "responsive" veut vraiment dire avant d'écrire une ligne de code
Le responsive design, ce n'est pas « faire des petites versions du site ». C'est un seul document HTML, une seule feuille CSS, qui s'adapte à la largeur disponible. Un iPhone, une tablette, un écran de bureau, un écran pivoté en portrait : tout le monde lit le même code.
Franchement, la définition officielle que vous trouverez partout est correcte mais trompeuse, parce qu'elle fait croire que c'est une technique. C'est une contrainte de conception.
Une contrainte, pas une technique
Quand vous partez du principe que la largeur de l'écran est variable, toute une série de décisions changent. Vous ne placez plus un bloc « à 300 px de la gauche », vous le laissez respirer dans son conteneur. Vous n'écrivez plus « 16 px » pour un texte, vous parlez en rem pour que la taille de police du système entre en jeu. Ce changement de posture explique pourquoi certains professionnels produisent du site responsive presque sans y penser, et pourquoi d'autres, avec les mêmes outils, produisent des sites qui se cassent au premier redimensionnement.
Ce que "responsive" n'est pas
- Ce n'est pas un thème WordPress qu'on installe en cinq clics. Un CMS vous aide, il ne code pas à votre place.
- Ce n'est pas trois sites (mobile, tablette, bureau) cachés derrière des redirections.
- Ce n'est pas seulement du CSS. La structure HTML compte tout autant, voire plus.
- Ce n'est pas une case à cocher en fin de projet.
Les étapes concrètes pour rendre un site responsive en HTML et CSS
Prenez le problème dans l'ordre. Sauter la première étape, c'est perdre deux heures à comprendre pourquoi rien ne se passe sur votre téléphone.
Étape 1 : la balise viewport, ou rien ne fonctionne
Sans cette ligne dans le <head>, le navigateur mobile va simuler un écran de 980 px de large et réduire toute la page. Vos media queries se déclencheront sur une largeur fausse et votre design paraîtra minuscule.
<meta name="viewport" content="width=device-width, initial-scale=1">Deux attributs, et c'est tout ce qu'il vous faut. width=device-width aligne la largeur de rendu sur celle de l'appareil, initial-scale=1 empêche le zoom automatique. Je vois encore des sites en 2026 qui l'oublient. C'est la première chose que je vérifie quand on me demande pourquoi « ça s'affiche mal sur iPhone ».
Étape 2 : rendre la mise en page fluide
Avant d'ajouter la moindre media query, votre page doit déjà pouvoir se réduire sans casser. Trois habitudes suffisent :
- Remplacer les largeurs fixes par des pourcentages ou des unités relatives.
width: 80%plutôt quewidth: 960px. - Utiliser
max-widthplutôt quewidthpour les conteneurs. Un conteneur àmax-width: 1200pxse comporte bien partout. - Basculer les tailles de police en rem. Un utilisateur qui a configuré son téléphone en police large vous remerciera.
À ce stade, votre site n'est pas encore responsive au sens strict. Il est juste moins rigide. Et c'est déjà énorme.
Étape 3 : Flexbox et Grid pour la structure
C'est ici que le travail change de nature. Flexbox gère très bien une rangée d'éléments (une barre de navigation, une carte, une liste d'auteurs). Grid gère les pages entières (une grille d'articles, un tableau de bord).
Pour une grille de cartes qui s'adapte toute seule, une seule ligne fait des merveilles :
.grille {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
gap: 1.5rem;
}Traduit du CSS en français : « mets autant de colonnes que possible, chacune d'au moins 280 px, et rembourre l'espace restant ». Sur un grand écran, vous obtenez quatre colonnes. Sur une tablette, deux. Sur un téléphone, une. Pas une media query nécessaires. J'ai adopté ce pattern il y a deux ans sur un site éditorial, et le nombre de correctifs liés à la grille a chuté presque à zéro.
Étape 4 : traiter les images et les médias
Les images sont la première cause de débordement horizontal. La règle de base tient en une ligne :
img, video {
max-width: 100%;
height: auto;
display: block;
}Pour aller plus loin, l'attribut srcset permet de servir une image plus légère sur mobile. Et pour les vidéos intégrées (YouTube, Vimeo), un conteneur avec un ratio fixe évite les mises en page qui sautent au chargement :
.video {
aspect-ratio: 16 / 9;
width: 100%;
}Étape 5 : les media queries, avec parcimonie
Vous pouvez maintenant écrire vos points de rupture. Le piège classique : en mettre partout. Un site bien conçu se contente souvent de deux ou trois paliers.
En pratique, je vois trois ordres de grandeur qui reviennent : autour de 480 px pour les très petits écrans, 768 px pour la frontière mobile/tablette, et 1024 px pour les écrans moyens. Ce ne sont pas des valeurs magiques. Elles correspondent à des appareils courants, mais un design peut très bien fonctionner avec des paliers à 600 px et 900 px si le contenu l'exige.
@media (min-width: 768px) {
.carte { flex-direction: row; }
}Notez le min-width. On l'oublie trop souvent : écrire ses media queries avec min-width au lieu de max-width vous force à penser mobile-first. Vous définissez d'abord le style pour le plus petit écran, puis vous enrichissez au fur et à mesure. C'est la seule méthode que je recommande. Je sais, ça demande un petit effort de discipline au début. Mais je vous assure que vous ne voudrez plus revenir aux max-width empilés.
Mobile-first ou desktop-first : faut-il vraiment choisir ?
Oui. Et honnêtement, dans la plupart des cas, c'est mobile-first.
La raison est simple : il est beaucoup plus facile d'ajouter de la complexité que d'en retirer. Concevoir pour un écran de 360 px vous contraint à hiérarchiser. Vous décidez ce qui est vraiment important. Quand vous passez ensuite à 1440 px, vous ne faites qu'ajouter des colonnes, agrandir les marges, autoriser des grilles plus riches. L'inverse — partir d'un site riche en trois colonnes et le dégrader — produit presque toujours un mobile bancal, où l'on a sacrifié des choses au hasard.
| Critère | Mobile-first | Desktop-first |
|---|---|---|
| Direction du code | Styles de base pour petits écrans, media queries min-width | Styles complets, media queries max-width |
| Effort initial | Plus élevé (il faut hiérarchiser tôt) | Plus confortable (on étale tout) |
| Maintenance | Plus simple, chaque media query ajoute | Fragile, chaque media query retire |
| Résultat sur mobile | Naturel, priorisé | Souvent dégradé, bricolé |
| Quand le choisir | Blog, contenu, e-commerce, la majorité des cas | Applications métier, webs denses en données, contraintes historiques |
Il reste un cas où desktop-first se défend : un back-office ou un outil de gestion utilisé principalement sur ordinateur, dont la version mobile est secondaire. Mais pour un site vitrine, un blog ou une boutique en ligne, la réponse ne fait aucun doute.
Tester et éviter les pièges qui plombent un site responsive
Un site responsive qui n'a jamais été ouvert ailleurs que sur votre écran n'est pas un site responsive. C'est une impression.
Comment tester sans acheter cinq téléphones
Le mode responsive des DevTools de votre navigateur est l'outil le plus sous-estimé du lot. Il vous permet de simuler des dizaines de tailles, de forcer l'émulation tactile, et de voir immédiatement où ça casse. Vous le trouvez avec un raccourci : F12, puis l'icône « appareil » en haut à droite dans la plupart des navigateurs.
Trois vérifications qui ne prennent jamais plus de cinq minutes :
- Réduisez la fenêtre jusqu'à environ 320 px de large. Un défilement horizontal apparaît ? Vous avez un débordement quelque part.
- Regardez la zone cliquable de vos liens et boutons. Un doigt humain fait environ 45 px de large. Si vos boutons font 20 px de haut, vous rendez la navigation pénible.
- Zoomez à 200 %. Le texte reste-t-il lisible sans casser la mise en page ?
Les pièges qui reviennent tout le temps
Celui qui m'a coûté le plus de temps : un tableau HTML large à l'intérieur d'un conteneur. Sur mobile, il déborde, et tout le reste de la page se retrouve avec un défilement horizontal. La solution propre est d'envelopper le tableau dans un conteneur avec overflow-x: auto. La solution sale, c'est de cacher la colonne gênante en mobile. Faites la première.
Autre classique : un menu de navigation qui reste à l'horizontale. Sur mobile, il faut presque toujours basculer vers un menu replié (le fameux « hamburger »). Ce n'est pas qu'une question d'espace : c'est une question d'ergonomie tactile.
Et enfin, la performance. Sauver la mise en page, c'est bien. Livrer une page mobile qui pèse 4 Mo, c'est un autre problème — mais qui n'est plus vraiment du responsive au sens strict. Retenez simplement qu'une image de 3 000 px de large servie à un téléphone qui en affiche 400, c'est du gaspillage pur. srcset et le format WebP règlent la plupart des cas.
Ce que je retiens après plusieurs projets
Le responsive n'est pas une compétence qu'on coche. C'est une façon de penser l'interface. Quand elle est acquise, elle disparaît de l'équation : vous codez naturellement fluide, vous testez au fur et à mesure, et vous ne vous dites même plus « tiens, il faut que je fasse du responsive ».
Si vous retenez trois choses de cet article :
- La balise viewport d'abord. Toujours.
- Une mise en page fluide avant les media queries, jamais l'inverse.
- Mobile-first comme posture par défaut, sauf contre-indication métier sérieuse.
Et pour finir, une question qui vaut la peine d'être posée à n'importe quel projet : quand une nouvelle taille d'écran apparaîtra dans trois ans, est-ce que votre code s'adaptera tout seul, ou faudra-t-il repasser dessus ? La réponse est un bon indicateur de la qualité du travail.
