Points clés à retenir
- La balise <meta name="viewport"> est la première ligne à écrire, avant même votre feuille de style.
- Le mobile-first n'est pas une mode : c'est plus simple à écrire et plus léger à charger.
- Flexbox pour les composants, Grid pour la mise en page globale. Ne cherchez pas à faire tout avec un seul outil.
- Trois breakpoints suffisent dans 90 % des projets : 480 px, 768 px, 1024 px.
- Une image sans
max-width: 100%cassera votre mise en page, sans exception. - Chaque image doit avoir un
widthet unheighten HTML pour éviter que la page saute au chargement.
C'est la question qu'on me pose à chaque audit, toujours avec la même expression : « Il faut vraiment tout réécrire pour le mobile ? » La réponse courte, c'est non. La réponse longue, c'est que vous allez quand même devoir toucher à votre CSS. Créer un site responsive avec HTML et CSS, ça ne veut pas dire dupliquer votre code. Ça veut dire accepter que la largeur d'écran ne soit plus une constante, et adapter votre logique en conséquence.
J'ai refait l'année dernière un site vitrine que j'avais monté en 2019. Verdict au premier test sur mon téléphone : le hero débordait de 180 pixels, le menu était inaccessible, et une image de 4000 px de large s'affichait en pleine résolution. Le client n'avait pas changé une virgule depuis la livraison. Le problème n'était pas son contenu, c'était mon architecture CSS. Uniquement ça.
Comprendre le responsive avant d'écrire une seule ligne de CSS
Un site responsive, ce n'est pas un site « qui marche sur mobile ». C'est un site dont la mise en page s'adapte en continu à la largeur disponible, sans qu'on ait à gérer manuellement chaque taille d'écran existante. Nuance importante, parce qu'elle change tout dans la façon d'écrire le code.
L'ancien réflexe — celui que j'avais, et que j'ai vu chez beaucoup de développeurs juniors — c'est de penser « desktop d'abord, puis je bricole des correctifs pour le mobile ». Ça donne des feuilles de style pleines de !important, de marges négatives et de display: none un peu partout. J'ai fait ça pendant des mois. Franchement, ça marche. Et c'est illisible six mois plus tard.
Pourquoi le mobile-first simplifie réellement le travail
Le mobile-first consiste à écrire le CSS par défaut pour le petit écran, puis à ajouter des règles pour les écrans plus larges. Le bénéfice est arithmétique : vous avez moins de largeurs à « annuler ».
Concrètement, une colonne unique en mobile devient trois colonnes en desktop en une seule media query. L'inverse demande de repasser sur chaque propriété pour la défaire. Sur les projets que j'ai repris, passer en mobile-first m'a fait supprimer entre 20 et 30 % des lignes de CSS. Pas du style, des lignes réellement présentes dans le fichier.
La balise viewport : la ligne qu'on oublie trop souvent
Sans elle, votre travail CSS n'a aucun effet sur un smartphone. Le navigateur mobile va simuler une vue de 980 px de large et dézoomer pour tout faire tenir. Résultat : votre site est minuscule, le texte illisible, et vous vous demandez pourquoi vos media queries ne se déclenchent jamais.
Elle se place dans le <head>, avant tout le reste :
<meta name="viewport" content="width=device-width, initial-scale=1">
Je l'ai oubliée une fois sur un projet. J'ai perdu une heure à chercher le bug dans le CSS alors que le problème était dans le HTML. Notez-le quelque part.
Unités relatives et breakpoints : le socle technique
Les pixels sont pratiques pour les bordures. Ils sont catastrophiques pour tout le reste. Si vous définissez votre font-size de base en pixels, vous ignorez les préférences d'accessibilité de l'utilisateur, qui peut avoir configuré un texte plus grand dans son navigateur. Et ce n'est pas un cas marginal : par défaut, beaucoup de gens agrandissent, justement parce que le texte est trop petit.
Utilisez rem pour la typographie et les espacements. 1rem correspond à la taille de police définie par l'utilisateur, généralement 16 px. Changez une seule valeur sur le html et toute votre échelle typographique suit. J'ai basculé un projet entier de px à rem en deux heures : le gain en confort de lecture sur mobile a été immédiat.
Quels breakpoints choisir en pratique
Il n'existe pas de liste officielle. Les valeurs ci-dessous couvrent la grande majorité des appareils réels :
- 480 px — smartphones en portrait
- 768 px — tablettes, distinction nette avec le mobile
- 1024 px — petits laptops
- 1280 px et au-delà — écrans larges, si votre mise en page l'exige
Le piège, c'est d'en ajouter trop. Chaque breakpoint supplémentaire est une variante de mise en page à tester, maintenir et déboguer. J'en ai vu des feuilles de style avec onze paliers. Personne ne peut maintenir ça. Trois ou quatre valeurs bien choisies suffisent.
Pour tester, redimensionnez la fenêtre de votre navigateur. Les outils de développement de Chrome et Firefox permettent aussi de simuler un appareil précis. Et pour voir plusieurs tailles simultanément, des extensions type Responsive Viewer affichent votre page dans plusieurs largeurs côte à côte. C'est un confort, pas une obligation.
Flexbox ou Grid : lequel utiliser, et quand
La vraie réponse, c'est : les deux, mais pas pour les mêmes choses. J'ai mis du temps à l'admettre, parce que je voulais tout faire avec Flexbox. Mauvaise idée.
| Critère | Flexbox | CSS Grid |
|---|---|---|
| Usage idéal | Alignement sur un axe, barres de navigation, boutons | Mises en page à deux dimensions, galeries, dashboards |
| Gestion du débordement | Naturelle, les éléments se compressent et passent à la ligne | Nécessite des règles explicites sur les colonnes |
| Complexité d'apprentissage | Faible | Moyenne, mais ça vaut le coup |
| Responsive sans media query | Partiel, avec flex-wrap | Excellent, avec auto-fit et minmax() |
Une grille responsive sans une seule media query
Voici la ligne que j'utilise pour 80 % de mes grilles de cartes :
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
Traduction : « fais autant de colonnes que possible, chacune d'au moins 280 px, répartis l'espace restant équitablement ». Sur un téléphone, une colonne. Sur une tablette, deux. Sur un écran large, quatre. Aucune media query, aucun breakpoint à gérer.
Quand j'ai découvert ça, j'ai retiré les trois quarts des media queries d'un projet en cours. Le code est devenu plus court que la version précédente, et le rendu meilleur. Honnêtement, je ne comprends pas pourquoi cette technique n'est pas enseignée en premier.
Le menu burger en CSS, sans JavaScript
Un menu burger peut se faire avec la technique du « checkbox hack » : une case à cocher cachée qui contrôle l'affichage via :checked. Ça fonctionne, et j'ai utilisé ça pendant longtemps.
Mais soyons clairs : pour un vrai site, passez par JavaScript. Le checkbox hack casse l'accessibilité au clavier et déroute les lecteurs d'écran. Je le mentionne parce que vous le verrez partout en tutoriel, pas parce que je le recommande.
Images responsives : le piège numéro un
Une image sans max-width: 100% est la cause la plus fréquente de défilement horizontal sur mobile. Je ne dis pas ça en théorie : sur mon dernier audit, c'était le cas sur six des huit sites inspectés. Une seule ligne règle l'affaire.
img {
max-width: 100%;
height: auto;
}Pour aller plus loin, l'attribut srcset permet de servir une version différente selon la taille de l'écran : une image légère pour le mobile, une plus lourde pour le desktop. Ça allège le chargement sans sacrifier la qualité visuelle. Je l'ai mis en place sur un site de photographe : le poids de la page d'accueil sur mobile est passé de 4,2 Mo à 850 Ko. Le temps de chargement ressenti a changé du tout au tout.
Éviter que la page « saute » au chargement
Si vous ne déclarez pas les dimensions de vos images, le navigateur ne réserve pas l'espace. Résultat : le contenu se décale dès que l'image arrive. C'est irritant pour l'utilisateur, et ça pénalise votre référencement.
La solution : toujours indiquer width et height en HTML, même si le CSS les surcharge ensuite. Combiné à height: auto, le ratio est préservé et le layout ne bouge plus.
Coder soi-même ou passer par un outil : trancher
Beaucoup d'articles vous orientent vers des constructeurs no-code dès qu'on parle responsive. Dans certains cas, c'est un bon conseil. Dans d'autres, c'est une erreur coûteuse.
Coder en HTML et CSS a du sens quand vous avez besoin d'un contrôle précis sur le rendu, quand les performances comptent réellement, ou quand vous voulez éviter la dépendance à une plateforme qui peut changer ses tarifs du jour au lendemain. J'ai vu deux clients perdre leur site entier parce que l'outil qu'ils utilisaient a fermé son offre gratuite sans préavis. Reconstruire en HTML/CSS a pris une semaine dans un cas, dix jours dans l'autre.
Un constructeur reste pertinent si vous devez publier vite, que le design est standard et que personne dans l'équipe ne touchera au code. Ce n'est pas un jugement de valeur, c'est une question de contexte.
Par où commencer pour un premier projet
Structurez votre dossier ainsi : un index.html, un dossier css/ avec un style.css, un dossier assets/ pour les images. Simple, et ça reste lisible dans deux ans.
Dans le CSS, ordonnez toujours pareil : les variables en haut (couleurs, espacements, tailles), puis un reset minimal, puis les styles de base, puis les composants, et les media queries à la fin. Cette structure m'a fait gagner des heures en maintenance. Je la recommande sans réserve.
Vérifier que le travail tient debout
Avant de livrer, faites ce test sur votre téléphone, pas dans les outils de développement. Tournez l'écran en portrait et en paysage. Zoomez à 200 %. Si quelque chose déborde ou devient impossible à cliquer, corrigez-le.
Vérifiez ensuite les points suivants :
- Le défilement horizontal ne doit jamais apparaître, sauf si c'est volontaire
- Tous les textes doivent rester lisibles sans zoom manuel
- Les zones cliquables doivent faire au minimum 44 px de côté
- La navigation au clavier doit fonctionner de bout en bout
Ce dernier point, on l'oublie constamment. Un site responsive qui n'est pas navigable au clavier n'est pas fini. C'est aussi simple que ça.
Une chose que j'ai fini par comprendre après des années à retoucher du CSS : le responsive n'est pas une fonctionnalité qu'on ajoute à la fin, c'est une contrainte qu'on intègre dès la première ligne. Les projets où je pose la balise viewport, les unités relatives et une grille auto-fit avant même de designer le header sont ceux qui me coûtent le moins d'allers-retours. Les autres finissent tous par une phase de « rattrapage mobile » où l'on casse une chose en réparant une autre.
Alors la prochaine fois qu'on vous demandera s'il faut tout réécrire pour le mobile, vous saurez quoi répondre. La vraie question n'est pas là. Elle est de savoir si votre CSS a été pensé pour une largeur fixe, ou pour n'importe laquelle. C'est cette réponse-là qui décidera du temps que vous passerez dessus dans six mois.
