Un écran de 375 pixels de large. C'est là que se joue la première impression de votre site, bien avant le grand moniteur du développeur qui l'a codé. Et c'est précisément là que la plupart des projets que j'ai repris en cours de route partaient en vrille : une maquette superbe sur desktop, un carnage sur téléphone.
Je récupère régulièrement des sites « responsive » qui n'en ont que le nom. Le symptôme est toujours le même : un `meta viewport` oublié, trois media queries bricolées à la fin, et un `position: absolute` qui tient tout debout par miracle. Corriger ça, sur mon dernier chantier, m'a pris deux jours. Le refaire proprement en mobile-first m'aurait pris une demi-journée de plus au départ.
Voici ce que j'applique aujourd'hui pour créer un site web responsive — pas la théorie qu'on trouve partout, mais les pratiques CSS qui tiennent quand un vrai utilisateur scrolle avec les pouces dans le métro.
Points clés à retenir
- Commencez par le mobile, élargissez ensuite : c'est plus simple d'ajouter de la complexité que d'en retirer.
- Réservez le `max-width` aux conteneurs et aux images, jamais aux blocs de texte.
- Utilisez Flexbox pour aligner, Grid pour structurer une page entière.
- Préférez `clamp()` aux media queries quand seule une taille doit varier.
- Testez sur un vrai téléphone, pas seulement en redimensionnant la fenêtre du navigateur.
- Une zone tactile en dessous de 44 px de haut, c'est un bouton raté une fois sur deux.
Pourquoi le mobile-first n'est pas une mode mais une contrainte technique
La question que je pose toujours avant de toucher à une feuille de style : dans quel sens votre CSS est-il écrit ? Si la réponse est « je pars du desktop et je réduis », vous vous êtes déjà compliqué la vie.
Raison technique, pas idéologique. Un CSS écrit en desktop-first accumule des `max-width` media queries qui doivent annuler des règles précédentes. À chaque nouvelle règle, vous héritez du désordre du dessus. En mobile-first, vous partez d'une base minimale et vous ne faites qu'ajouter. Quand je suis passé à cette logique sur un projet client, mon fichier CSS est passé de 980 à 640 lignes. Mêmes fonctionnalités, moins de `!important`, moins de `@media` en cascade.
L'ordre des media queries, le piège numéro un
Une media query en mobile-first se lit `min-width`. Toujours. Si vous mélangez `min-width` et `max-width` dans le même fichier, vous créez des zones grises où deux règles s'appliquent en même temps et où l'ordre de déclaration décide de tout. J'ai vu un menu disparaître entre 768 px et 820 px à cause de ça. Trois heures de recherche pour un `max-width: 819px` mal placé.
Les seuils que j'utilise sur presque tous mes projets :
- 480 px — petits téléphones en portrait
- 768 px — tablettes verticales
- 1024 px — tablettes horizontales, petits laptops
- 1280 px et au-delà — écrans larges
Ce ne sont pas des lois gravées dans le marbre. Ce sont des points de rupture qui correspondent à des appareils réels. Taillez vos breakpoints selon votre contenu : si votre grille casse à 900 px, mettez un seuil à 900 px, pas à 1024 px parce que « c'est la norme ».
Les bonnes pratiques CSS concrètes qui font tenir un site responsive
Le `meta viewport` d'abord. Sans lui, tout le reste est décoratif :
<meta name="viewport" content="width=device-width, initial-scale=1">Ensuite, deux règles de base que j'inscris dans chaque projet dès la première ligne :
- `* { box-sizing: border-box; }` — sans ça, chaque padding s'ajoute à la largeur déclarée et vos colonnes débordent.
- `img { max-width: 100%; height: auto; }` — une image fluide par défaut. C'est bête, mais c'est la première chose qui pète sur un site non préparé.
Unités relatives : rem, %, vw — et quand éviter le vh
Le `rem` pour les tailles de police. Le `%` et le `fr` pour les largeurs de conteneur. Le `vw` pour les éléments qui doivent suivre la largeur d'écran. Le `vh`, je m'en méfie depuis que les barres d'adresse mobiles se cachent au scroll et font sauter la hauteur de page. Sur une bannière plein écran, ça donne un saut visuel très désagréable.
Pour les tailles de texte fluides, `clamp()` remplace élégamment deux ou trois media queries :
h1 { font-size: clamp(1.75rem, 5vw, 3rem); }Une ligne. Le titre s'adapte entre 28 px et 48 px sans qu'aucun media query n'intervienne. J'ai refait un composant entier comme ça la semaine dernière, j'ai supprimé quatre media queries.
Flexbox ou Grid : la règle que je suis
| Besoin | Outil | Pourquoi |
|---|---|---|
| Aligner une barre de navigation | Flexbox | Flux en une dimension, alignement simple |
| Structurer une page en zones | Grid | Deux dimensions, zones nommées |
| Liste de cartes qui passent de 1 à 3 colonnes | Grid | `grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))` fait tout |
| Centrer un élément dans son parent | Flexbox | Trois lignes, aucun calcul |
Cette dernière ligne de Grid mérite qu'on s'y arrête. `repeat(auto-fit, minmax(280px, 1fr))` crée une liste de cartes qui s'adapte toute seule au nombre de colonnes disponibles. Pas de media query. Pas de breakpoint. La grille se recompose au fur et à mesure que la fenêtre change. C'est probablement l'astuce CSS la plus rentable que j'ai apprise ces dernières années.
Tester et rendre accessible — la partie que tout le monde saute
Redimensionner la fenêtre de son navigateur ne teste rien. Ça teste un cas d'usage artificiel dans un environnement où tout est rapide, où le réseau est stable et où votre pouce n'existe pas.
Ce que je fais systématiquement avant de livrer :
- Ouvrir le site sur un vrai téléphone, avec le vrai réseau, en marchant
- Passer le site au clavier uniquement, sans souris, sur desktop
- Vérifier les contrastes de texte à l'aide des outils du navigateur
- Réduire la vitesse de connexion à 3G dans l'inspecteur
- Activer le mode « texte très agrandi » du système pour voir si la mise en page tient
L'accessibilité et le responsive partagent un objectif : rendre le contenu lisible dans des conditions que vous n'avez pas prévues. Une zone tactile de 40 px de côté, c'est un bouton qui rate une fois sur deux sur mobile. La recommandation est de 44 px minimum. Je force cette taille sur tous mes boutons et liens d'action, même quand le design voudrait les faire plus petits. Le design s'adapte.
Performance : ce que le responsive coûte vraiment
Un site responsive mal optimisé télécharge les mêmes images lourdes sur un téléphone que sur un écran 4K. Deux attributs règlent ça :
- `loading="lazy"` sur les images sous la ligne de flottaison
- `srcset` et `sizes` pour servir l'image adaptée à la résolution réelle
Sur un projet de galerie photo, passer au `srcset` a divisé par trois le poids transféré sur mobile. Le temps de chargement perçu est passé de ce qui ressemblait à une éternité à quelque chose d'instantané. Ça change tout, surtout quand on sait qu'une bonne partie de l'audience abandonne avant que la page ne soit complète.
Quelles sont les unités CSS relatives à privilégier en responsive ?
Les unités relatives sont rem, em, %, vw et vh. Pour la typographie, partez sur rem — il se base sur la taille de police racine et respecte les préférences d'accessibilité de l'utilisateur.
Pour les conteneurs, utilisez % ou les fractions fr de Grid. Réservez vw aux éléments qui doivent suivre la largeur exacte de la fenêtre, et méfiez-vous de vh sur mobile à cause des barres d'adresse qui apparaissent et disparaissent au scroll. Évitez les px pour tout ce qui touche au texte.
Combien de breakpoints faut-il prévoir ?
Il n'existe pas de nombre magique. Je travaille généralement avec trois à cinq points de rupture, définis par les endroits où ma mise en page commence visuellement à casser, pas par une liste d'appareils à la mode.
Si vous devez absolument partir quelque part : 480 px, 768 px et 1024 px. Ajoutez-en un si votre contenu l'exige, retirez-en si vous ne vous en servez jamais. Un breakpoint qui n'est activé par aucun changement réel dans votre CSS est un breakpoint à supprimer.
La checklist que j'applique avant chaque mise en ligne
Rien de spectaculaire. Juste les vérifications que je fais à chaque fois, et qui m'ont sauvé plus d'une livraison :
- Meta viewport présent, sans
maximum-scalequi bloque le zoom - Aucun débordement horizontal — pas de barre de défilement latérale sur mobile
- Texte lisible sans zoom : pas de police en dessous de 16 px sur mobile
- Zones tactiles d'au moins 44 px
- Images fluides par défaut, avec
srcsetsur les visuels importants - Aucun contenu qui disparaît complètement en dessous d'un certain seuil sans alternative
- Formulaire utilisable au pouce, champs suffisamment espacés
Le point sur le débordement horizontal mérite un mot. C'est le symptôme le plus fréquent d'un responsive raté, et il vient presque toujours d'un élément en `width` fixe qui refuse de rétrécir. La règle `img, video, iframe { max-width: 100%; }` règle la majorité des cas en une ligne. Pour le reste, l'inspecteur du navigateur vous montre le coupable en quelques secondes.
Vous pouvez avoir le plus beau design du monde sur un écran de 27 pouces. Si votre visiteur le découvre sur un téléphone et que la moitié du contenu est coupée, ce design n'a jamais existé pour lui. Le responsive, ce n'est pas une fonctionnalité qu'on ajoute à la fin — c'est la façon dont on écrit le CSS depuis le départ, ou pas du tout.
