Créer un site responsive : 7 bonnes pratiques à adopter

Créer un site responsive : ce qui change vraiment (et ce que les tutos oublient)

La question qu'on me pose le plus souvent en début de mission, ce n'est pas « comment on fait un site responsive ». C'est : « pourquoi mon site responsive rame sur mon téléphone alors que le desktop est nickel ? » Et là, 9 fois sur 10, le diagnostic tombe en cinq minutes. Le développeur a empilé des media queries comme on pose des rustines, sans repenser la structure. Le site s'affiche. Il ne se comporte pas.

La conception réactive, ou responsive web design, c'est une approche qui vise à ce que vos pages s'affichent correctement sur toutes les tailles et résolutions d'écran, avec une utilisabilité correcte. Voilà pour la définition. Sauf que cette phrase décrit un résultat, pas une méthode. Et c'est exactement là que tout le monde se plante.

Je vais vous montrer la mécanique réelle, dans l'ordre où elle compte. Pas la liste de courses habituelle.

Qu'est-ce qu'un site responsive, au-delà de la définition ?

Un site responsive, c'est un site dont la mise en page se réorganise selon l'espace disponible. Pas qui se réduit. Qui se réorganise.

La nuance paraît sémantique. Elle est structurelle. Quand vous réduisez, vous obtenez une colonne de texte large de 320 pixels avec une sidebar écrasée à droite. Quand vous réorganisez, la sidebar descend sous le contenu, la navigation se replie dans un bouton, les titres changent d'échelle. Ce ne sont pas les mêmes décisions de conception.

Un précurseur qu'on a oublié : la conception mobile

Avant que le responsive devienne l'approche standard, on parlait de conception adaptée au mobile. L'objectif était déjà le même : garantir qu'un site fonctionne sur les appareils du marché, quelles que soient leurs caractéristiques. La différence tenait à l'exécution. On créait une version séparée, souvent sur un sous-domaine dédié, avec son propre code. Deux bases à maintenir. Deux fois les bugs.

J'ai vécu ce cauchemar sur un projet e-commerce il y a longtemps. On avait une version m. et une version desktop. Un correctif de prix passé sur l'une, oublié sur l'autre. Trois jours de commandes à tarif erroné avant que quelqu'un s'en aperçoive. C'est ce genre d'incident qui a tué la conception mobile séparée, pas une mode esthétique.

Ce que « responsive » ne veut pas dire

Trois confusions que je vois encore régulièrement dans des audits :

• Confondre responsive et adaptatif. Un site adaptatif détecte l'appareil et sert une version figée. Un site responsive, non : il s'adapte en continu à la fenêtre.
• Croire qu'un framework CSS règle le problème. Il fournit des points de rupture par défaut, pas une stratégie pour votre contenu.
• Penser que le responsive concerne le visuel. Il concerne d'abord l'interaction : un bouton trop petit ou trop proche d'un autre reste inaccessible même si la grille est propre.

Bon. Maintenant, le concret.

Comment faire un site responsive : la mécanique, dans l'ordre

Il y a une séquence qui fonctionne, et l'inverser coûte cher. Voici comment je procède, et pourquoi.

Le meta viewport, ou la ligne qu'on oublie

Sans cette balise dans le <head>, votre navigateur mobile suppose que vous affichez une page de bureau et la dézoome pour la faire tenir. Résultat : tout paraît minuscule, l'utilisateur pince pour lire, et aucune de vos media queries ne se déclenche comme prévu.

C'est la première chose que je vérifie sur un site qui « ne réagit pas ». Une fois sur deux, c'est ça. Une seule ligne, et tout le comportement change.

Mobile-first ou desktop-first : trancher

Deux approches existent. Elles ne sont pas équivalentes.

Le desktop-first consiste à concevoir pour grand écran puis à empiler des correctifs descendants. Le mobile-first fait l'inverse : vous partez du plus petit, puis vous enrichissez à mesure que l'espace augmente.

Franchement, je défends le mobile-first, et je défendrai cette position longtemps. Non par idéologie. Parce qu'un écran étroit vous force à hiérarchiser. Quand vous n'avez la place que pour une chose, vous choisissez la plus importante. Sur grand écran, l'espace pardonne l'indécision. Sur un téléphone, jamais.

Le coût caché du desktop-first, c'est l'accumulation de !important et de règles de contournement. J'ai repris une base comme ça une fois : 1 400 lignes de CSS dont près d'un tiers en surcharges défensives. Personne ne savait plus quelle règle gagnait. On a tout réécrit.

Les unités relatives plutôt que les pixels

Unité	Ce qu'elle mesure	Quand je l'utilise
%	La taille du parent	Largeurs de blocs, fluides par nature
rem	La taille de police racine	Typographie, espacements verticaux, marges cohérentes
em	La taille de police de l'élément	Composants qui doivent scaler avec leur propre texte
vw / vh	1 % de la largeur / hauteur de fenêtre	Sections pleine hauteur, avec parcimonie
px	Le pixel CSS	Bordures fines, détails qui ne doivent pas varier

Le rem mérite qu'on s'y arrête. En le construisant sur la taille de police racine, vous rendez tout votre espacement dépendant d'un seul paramètre. Le jour où l'utilisateur agrandit le texte de son navigateur pour raisons d'accessibilité, votre mise en page suit au lieu de casser. C'est le genre de détail qui ne se voit pas dans une démo, et qui se remarque immédiatement en conditions réelles.

Les media queries : corriger, pas construire

Une media query teste une condition et applique des règles si elle est vraie. C'est tout. Ce n'est pas un outil d'architecture.

L'erreur classique consiste à en mettre partout, par palier d'appareil : téléphone, tablette, petit portable, grand écran. Résultat, une forêt de points de rupture qui ne correspondent à rien de réel. Les tailles d'écran changent chaque année. Votre contenu, lui, a des points de rupture naturels.

Ma règle : je place un point de rupture quand la mise en page commence à mal se tenir, pas quand un modèle d'appareil populaire l'exige. Sur mon dernier projet en cours, ça a donné quatre paliers seulement, dont deux dans une plage de 200 pixels. C'est bizarre à lire dans un fichier, et parfaitement logique à l'écran.

Flexbox et CSS Grid

Flexbox gère une dimension : vous alignez et répartissez des éléments le long d'un axe. CSS Grid gère deux dimensions : vous définissez des lignes et des colonnes qui se chevauchent si besoin.

Pour un menu de navigation ou une rangée de cartes, Flexbox suffit et reste plus simple. Pour une page entière avec zone latérale et contenu principal, CSS Grid est plus direct. J'ai longtemps tout fait en Flexbox par habitude. Mauvaise habitude. Dès qu'il faut aligner verticalement et horizontalement sur plusieurs blocs, je repars sur Grid.

Le vrai gain de Grid vient avec ses fonctions de dimensionnement automatique. Vous pouvez demander des colonnes d'au moins 280 pixels, répétées autant de fois que la largeur le permet. Le navigateur calcule le nombre de colonnes lui-même. Plus besoin de media query pour ce cas de figure. Dès que je l'ai découvert, j'ai supprimé environ 40 % de mes règles de point de rupture sur le projet concerné.

Les images, premier poste de poids

Trois choses, dans cet ordre :

1. max-width: 100% sur toutes vos images, pour qu'elles ne dépassent jamais leur conteneur.
2. Des sources multiples via srcset et sizes, pour que le navigateur serve une version adaptée à la densité d'écran.
3. Un format moderne, avec un repli pour les navigateurs anciens.

J'ai audité un site de 120 articles l'an dernier. Le poids moyen d'une page d'article était de 4,8 Mo. Sur une connexion mobile médiocre, ça se traduit par une attente qui fait fuir. Après conversion des images et mise en place de srcset, on est descendus sous 900 Ko par page. Le taux de rebond sur mobile a chuté de plusieurs points dans les semaines qui ont suivi. Pas de magie. Juste des octets en moins.

Le piège du viewport sur mobile : la hauteur

Un point que personne ne mentionne et qui m'a coûté une journée entière. Sur mobile, l'unité vh ne correspond pas à la hauteur visible. La barre d'adresse du navigateur s'escamote au défilement, et la valeur change en cours de route. Une section en height: 100vh provoque un saut visuel désagréable.

La parade : utiliser les unités dynamiques de hauteur de fenêtre, qui suivent l'espace réellement disponible. Le support est là depuis quelques années, vous pouvez y aller. Mais si vous visez des navigateurs plus anciens, prévoyez une valeur de repli. Je me suis fait avoir en pensant que vh était stable. Il ne l'est pas.

Comment créer un site interactif sans casser le responsive

Un site interactif, c'est un site qui réagit aux actions : survol, clic, saisie, défilement. Le problème, c'est que l'interactivité pensée pour une souris se traduit mal en tactile.

Le survol n'existe pas sur mobile

C'est la règle à retenir. Un menu qui s'ouvre au survol ne s'ouvre jamais sur un écran tactile. Une infobulle déclenchée à la souris reste invisible. Un effet qui se déclenche au passage du curseur ne se déclenche pas.

La solution n'est pas de dupliquer. C'est de concevoir l'état par défaut comme un état accessible, puis d'enrichir au survol pour ceux qui en ont un. Si le menu s'ouvre au clic et gagne juste une animation au survol sur desktop, vous avez gagné.

Les états de focus, souvent oubliés

Quand vous naviguez au clavier, un élément doit montrer qu'il a le focus. Beaucoup de reset CSS suppriment ce contour par souci d'esthétique. C'est une très mauvaise idée, à la fois pour l'accessibilité et pour la testabilité.

La bonne approche : redéfinir le contour pour qu'il soit visible et cohérent avec votre charte, plutôt que de le supprimer. Si vous le supprimez sans remplacement, vous rendez votre site inutilisable pour une partie de vos visiteurs. Et vous vous privez d'un outil de débogage précieux.

Tester avec un vrai doigt, pas une souris

Les outils de développement permettent de simuler un écran tactile. C'est utile. Ce n'est pas suffisant.

Une fois le squelette en place, je sors mon téléphone, je le tiens d'une main, et je navigue. À une main. Dans le métro. C'est brutal et révélateur. La simulation vous dit si le layout tient. Elle ne vous dit pas si votre bouton principal est atteignable avec le pouce. Elle ne vous dit pas si votre formulaire devient pénible quand le clavier virtuel recouvre la moitié de l'écran.

Le clavier virtuel, d'ailleurs, c'est un classique. Un champ de saisie en bas de page, et paf, le clavier le masque. Si vous n'avez jamais testé ce cas, vous allez le découvrir en production.

Qu'est-ce que le mode responsive (et comment s'en servir pour tester)

Le mode responsive désigne l'affichage d'un contenu qui s'adapte à la taille et à l'orientation de l'écran. Dans les navigateurs de bureau, il désigne aussi une fonction des outils de développement qui imite différents appareils.

Comment activer ce mode dans les outils de développement

Sur la plupart des navigateurs de bureau, vous ouvrez les outils de développement, puis vous activez le mode d'émulation d'appareil. Vous pouvez alors choisir un modèle, une résolution, une orientation, et simuler une connexion lente.

Ce dernier point est sous-utilisé. Le throttling réseau vous montre ce que vit vraiment votre visiteur en 4G dégradée, et là, les surprises arrivent : les polices qui clignotent, les scripts qui bloquent le rendu, les images qui arrivent une par une. C'est dans ces conditions que j'ai découvert que deux de mes polices personnalisées représentaient à elles seules 340 Ko. J'ai gardé une seule graisse en critique et chargé le reste en différé.

Les limites de la simulation

La simulation vous ment sur plusieurs points :

• Les performances réelles d'un appareil modeste. Un émulateur tourne sur votre machine puissante.
• Le comportement du clavier virtuel et des zones sûres.
• Les particularités d'un moteur de rendu mobile, qui n'est pas exactement celui de votre navigateur de bureau même quand le cœur est partagé.

Bref, testez sur du matériel réel. Un vieux téléphone d'entrée de gamme dans un tiroir vaut mieux que dix émulateurs. Le mien a six ans et je ne m'en sépare pas.

Trois choses que j'aurais aimé savoir plus tôt

Le contenu dicte les points de rupture, pas l'inverse

Je fixais mes paliers à l'avance, par convention. Puis je passais des heures à corriger ce qui débordait. Aujourd'hui, je réduis la fenêtre lentement en regardant ce qui craque. Chaque craquement est un point de rupture. Ça paraît artisanal. C'est en fait la méthode la plus fiable que j'aie trouvée.

Un layout qui tient n'est pas un layout testé

Vérifier que rien ne déborde, c'est la partie facile. Ce qui casse, ce sont les cas limites : un titre très long, un nom d'utilisateur sans espace, une image absente, un texte traduit deux fois plus long que la version d'origine. Injectez volontairement des données hostiles dans votre interface. Le titre de 180 caractères. L'adresse e-mail de 60 caractères sans point. C'est là que le responsive se révèle, ou pas.

Les formulaires, angle mort permanent

Presque tous les sites ont un formulaire. Presque personne ne le teste en conditions mobiles réelles. Les champs trop petits, les claviers inadaptés au type de saisie, les messages d'erreur qui restent hors de vue après validation. J'ai passé une demi-journée sur un formulaire de contact qui semblait impeccable en émulation, et qui devenait inutilisable sur un vrai téléphone. Le champ de message était masqué dès qu'on tapait.

Un mot sur les claviers, justement. Indiquer le bon type de champ change tout : un type adapté à la saisie affiche le bon clavier, avec le bon jeu de touches. Ça paraît anecdotique, ça ne l'est pas quand votre utilisateur doit basculer manuellement sur les chiffres pour saisir un numéro.

Ce qui compte vraiment, en fin de compte

Un site responsive n'est pas une case à cocher dans un cahier des charges. C'est une posture : considérer dès le départ que l'écran sera petit, que la connexion sera mauvaise, que le doigt tremblera, que la ligne sera coupée. Chaque décision que vous prenez dans cet état d'esprit vous fait gagner du temps plus tard, et vous fait perdre de l'argent maintenant. C'est ce trade-off qui dérange.

La bonne nouvelle : les techniques sont stables. La balise viewport, les unités relatives, les grilles fluides, les points de rupture dictés par le contenu, les images adaptatives. Rien de tout ça ne change chaque printemps. Ce qui change, ce sont les appareils, et c'est exactement pour ça qu'il ne faut pas construire pour eux.

La prochaine fois qu'on vous demandera comment faire un site responsive, posez une seule question : « on part de quel écran ? » Si la réponse est « le desktop, on adaptera après », vous savez déjà comment la suite va se passer. Et vous savez quel genre de dette technique vous allez devoir rembourser.