Il y a une phrase que j'entends à chaque projet, toujours à la même réunion : « on verra le mobile plus tard ». Trois mois après, ce « plus tard » devient une urgence, le site est en ligne, il casse sur iPhone, et il faut tout reprendre. Créer un site web responsive pas à pas, ce n'est pas une case à cocher en fin de parcours. C'est une décision qu'on prend au premier jour ou qu'on paie au centuple ensuite.
Je vais vous montrer comment je procède, dans l'ordre, avec le code qui compte. Pas de théorie sur « l'importance du mobile ». Des balises, des breakpoints, et les erreurs que j'ai commises pour vous éviter de les refaire.
Points clés à retenir
- La balise meta viewport est la première ligne à écrire, avant toute autre.
- On conçoit d'abord pour le petit écran, puis on élargit : c'est le mobile-first.
- Les media queries et les grilles flexbox couvrent 90 % des besoins réels.
- Toute image doit porter
max-width: 100%, sans exception. - Un site responsive est une exigence d'accessibilité autant qu'un enjeu de référencement.
- Testez sur un vrai téléphone, pas seulement en réduisant la fenêtre de votre navigateur.
Poser les fondations avant le premier pixel
Un site responsive, c'est un site dont la mise en page s'adapte à la largeur de l'écran plutôt que de supposer une taille fixe. Rien de plus. Toute la difficulté tient dans cette phrase, parce qu'elle contredit quinze ans de réflexes hérités du desktop.
Le problème ? La plupart des débutants attrapent une maquette, la remplissent de largeurs en pixels, puis se demandent pourquoi rien ne bouge quand l'écran rétrécit. J'ai fait exactement ça sur mon premier projet sérieux. Un tableau à sept colonnes, largeur fixe, 1200 pixels. Sur un téléphone, l'utilisateur voyait trois colonnes et devait faire défiler horizontalement. Le pire, c'est que je trouvais ça acceptable.
La balise meta viewport : la ligne qu'on oublie
Sans elle, un navigateur mobile affiche votre page comme s'il avait un écran de bureau, puis la dézoome. Le texte devient minuscule, l'utilisateur pince pour lire. C'est le symptôme numéro un d'un site non responsive.
Dans le <head>, une seule ligne :
<meta name="viewport" content="width=device-width, initial-scale=1">Elle dit au navigateur : prends la largeur réelle de l'appareil et n'applique aucun zoom initial. C'est court. Et c'est la balise que j'ai oubliée pendant des mois en me demandant pourquoi mes media queries ne se déclenchaient jamais correctement.
Une structure de page compréhensible
Avant le CSS, le HTML. Une page se construit avec des balises sémantiques : header, nav, main, section, footer. Ce n'est pas de la décoration. Un lecteur d'écran s'appuie sur ces repères pour naviguer, et un moteur de recherche en tire des indications sur la hiérarchie de votre contenu.
- header : l'en-tête, souvent avec le logo et la navigation principale.
- main : le contenu unique de la page, une seule fois par document.
- section : un bloc thématique, avec son propre titre.
- footer : mentions, liens secondaires, contact.
- Les balises
divn'arrivent qu'après, pour habiller.
Une fois qu'on a cette ossature, le responsive devient mécanique. On ne déplace pas des blocs au hasard, on réorganise une structure qui existe déjà.
Adopter l'approche mobile-first : pourquoi et comment
Deux façons de concevoir un site adaptatif. Soit on part du grand écran et on compresse, soit on part du petit et on élargit. La seconde s'appelle mobile-first, et dans mon cas elle a tout changé.
Pourquoi partir du petit écran
Quand vous partez du desktop, vous ajoutez des règles CSS pour corriger ce qui déborde. Au fil des mois, la feuille de style devient un empilement de rustines que plus personne n'ose toucher. Quand vous partez du mobile, vous écrivez le minimum vital, puis vous ajoutez de la richesse à mesure que l'espace augmente. La logique est additive, jamais corrective.
Concrètement, votre CSS de base correspond au téléphone. Ensuite, chaque media query élargit la mise en page. Pas l'inverse.
Écrire ses premières media queries
Une media query applique des règles CSS seulement si une condition est remplie, le plus souvent une largeur minimale.
/ Base : mobile, rien à préciser /
.conteneur {
padding: 1rem;
}
@media (min-width: 768px) {
.conteneur {
padding: 2rem;
}
}
@media (min-width: 1024px) {
.conteneur {
max-width: 1100px;
margin: 0 auto;
}
}Trois paliers, trois intentions. Le mobile prend toute la largeur disponible. La tablette respire davantage. Le desktop se centre et se limite pour éviter les lignes de texte interminables.
Sur les valeurs exactes des breakpoints, franchement, la guerre entre écoles n'a pas de sens. Les repères 768 et 1024 pixels restent les plus répandus parce qu'ils correspondent à des familles d'appareils courantes. Mais un breakpoint doit surtout être posé là où votre mise en page casse. Je place le mien après avoir réduit la fenêtre jusqu'au moment où le contenu devient illisible, et j'y pose la règle.
Éviter l'erreur du breakpoint inutile
Ma pire période : sept media queries dans le même fichier, dont deux qui ne se déclenchaient jamais. J'avais copié un modèle sans comprendre. Chaque palier supplémentaire multiplie les combinaisons à tester. Deux ou trois suffisent pour la majorité des sites vitrine et des blogs.
Construire une grille qui se réorganise
Le responsive tient rarement à une astuce spectaculaire. Il tient à des grilles bien posées. Et là, deux outils font presque tout le travail.
Flexbox pour les alignements simples
Une barre de navigation, une rangée de cartes, un alignement horizontal qui doit passer en colonne sur téléphone : flexbox excelle.
.cartes {
display: flex;
flex-wrap: wrap;
gap: 1rem;
}
.carte {
flex: 1 1 280px;
}La propriété flex: 1 1 280px signifie : chaque carte peut grandir, peut rétrécir, et sa base est de 280 pixels. Résultat, sur un écran étroit les cartes s'empilent d'elles-mêmes, sans media query. Ce genre de raccourci m'a fait gagner des heures.
CSS Grid quand la structure est régulière
Pour une grille de galerie ou un tableau de bord, Grid est plus lisible.
.galerie {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
gap: 1rem;
}auto-fit combiné à minmax crée une grille qui place automatiquement le bon nombre de colonnes selon l'espace disponible. Deux lignes. Une galerie entièrement adaptative.
| Outil | Idéal pour | Effort d'apprentissage |
|---|---|---|
| Flexbox | Rangées, barres, alignements ponctuels | Rapide |
| CSS Grid | Galeries, mises en page à deux dimensions | Moyen |
| Media queries | Ajustements ciblés par taille d'écran | Rapide, mais tentation de surcharger |
Unités relatives (rem, %, vw) | Tout ce qui doit suivre l'échelle du texte | Immédiat |
Un mot sur les unités. Si vous fixez vos tailles de police en pixels partout, vous perdez la capacité de l'utilisateur à agrandir le texte depuis les réglages de son navigateur. Les rem respectent ce choix. C'est un détail d'accessibilité, et c'est aussi ce qui distingue un site soigné d'un site qui « marche à peu près ».
Gérer images, typographie et éléments tactiles
Une grille propre ne sert à rien si une image de 3000 pixels de large explose la mise en page. Le remède tient en une règle globale, à poser une fois pour toutes.
img, video {
max-width: 100%;
height: auto;
display: block;
}Cette règle, je l'ai mise dans ma feuille de base il y a longtemps et je ne l'ai jamais retirée. Elle empêche toute image de dépasser son conteneur, quelle que soit sa taille d'origine. Sur un ancien projet, une bannière de 2400 pixels créait un défilement horizontal sur mobile. Une ligne de CSS a réglé un bug que je traquais depuis deux jours.
La typographie sur petit écran
Sur téléphone, on lit à bout de bras, souvent dans de mauvaises conditions de luminosité. Quelques repères que j'applique systématiquement :
- Une hauteur de ligne autour de 1,5 pour le corps de texte, jamais en dessous de 1,3.
- Des lignes qui ne dépassent pas 70 caractères environ sur desktop.
- Des titres qui se réduisent proportionnellement, en
rem, pas en pixels figés.
Le piège classique : garder une taille de titre de 48 pixels sur mobile. Le titre occupe alors trois lignes et repousse le contenu sous la ligne de flottaison. La correction tient dans une media query qui redescend le titre à 28 ou 32 pixels.
Les zones tactiles
Un lien de 12 pixels de haut se clique mal avec un pouce. On vise une cible d'au moins 44 pixels de côté pour les boutons et les liens de navigation. C'est la recommandation la plus simple à retenir et la plus souvent ignorée. En agrandissant mes boutons d'action sur un site de réservation, le taux de clic sur mobile a grimpé nettement, sans que je touche au texte ni aux couleurs.
Tester et corriger
La fenêtre de votre navigateur réduite à 375 pixels ment. Elle ne reproduit ni la densité de pixels d'un vrai écran, ni les gestes, ni les performances réelles.
Comment vérifier qu'un site est correctement responsive ?
La vérification tient en trois gestes simples. D'abord, ouvrez la page sur un véritable téléphone, le vôtre suffit, et parcourez-la du pouce : le défilement horizontal est le premier symptôme à traquer. Ensuite, agrandissez le texte depuis les réglages du navigateur et regardez si la mise en page tient toujours. Enfin, testez les zones tactiles en cliquant avec le pouce, pas avec l'index et un écran posé sur un bureau.
Les outils de développement de votre navigateur offrent un mode d'émulation utile, avec des profils d'appareils prédéfinis. Je m'en sers pour gagner du temps sur les premiers réglages. Mais je ne valide jamais un site dessus, parce qu'un émulateur ne dit rien de la vitesse de rendu sur un appareil modeste.
Les erreurs que je rencontre le plus souvent
En reprenant le travail d'autres développeurs, ce sont presque toujours les mêmes points qui reviennent.
- La balise
meta viewportabsente. - Des largeurs en pixels fixes héritées d'un ancien design.
- Des media queries écrites en
max-widthalors que le reste du projet part du mobile. - Des images sans contrainte de largeur.
- Une police de corps de texte sous 14 pixels.
- Le défilement horizontal causé par un élément positionné hors du conteneur.
Bonne nouvelle : chacune se corrige en quelques minutes une fois identifiée. Ce qui prend du temps, ce n'est jamais la correction. C'est de comprendre d'où vient le débordement, ce qui, dans mon expérience, se résout en surlignant temporairement chaque bloc d'un contour coloré pour voir lequel dépasse.
Faut-il utiliser un framework CSS ?
Pas obligatoirement. Pour un site vitrine ou un blog, une centaine de lignes de CSS bien écrites font le travail. Les frameworks apportent de la vitesse sur les projets volumineux et des composants prêts à l'emploi, au prix d'un poids supplémentaire et d'une couche d'abstraction à apprivoiser. Le bon critère reste la taille de votre équipe et la durée de vie prévue du projet.
Ce qui reste quand la technique est passée
Le responsive n'est pas une étape qu'on termine. C'est une contrainte qu'on garde en tête du premier croquis jusqu'à la mise en ligne, et encore après. Chaque nouvelle section que vous ajoutez devra repasser le test du petit écran. Chaque image que vous intégrez devra respecter la règle des 100 %. Si vous acceptez cette contrainte dès aujourd'hui, le travail devient une habitude. Si vous la remettez à plus tard, vous connaîtrez la réunion dont je parlais au début, celle où l'on découvre que le site est cassé et que la livraison est pour vendredi.
La vraie question n'est donc pas de savoir si vous allez rendre votre site adaptatif. C'est de décider à quel moment vous payez : au début, en écrivant du CSS propre, ou à la fin, en reprenant trois mois de travail. Dans les deux cas, la facture arrive. Vous choisissez seulement qui la règle.
