Un client m'appelle, paniqué. Sa boutique en ligne perd des ventes, et il ne comprend pas. Le site est beau, rapide, testé sur son MacBook. Le problème ? Il n'a jamais regardé ce que ça donnait sur son propre téléphone. Je l'ai ouvert sur mon écran de 6 pouces : le bouton "Ajouter au panier" sortait de l'écran, le menu débordait, et il fallait zoomer avec deux doigts comme en 2010 pour lire le titre d'un produit.
Trois semaines plus tard, on avait récupéré 38 % de conversion supplémentaire sur le trafic mobile. Pas avec un nouveau design. Juste en arrêtant de traiter le téléphone comme un ordinateur miniature.
Voilà ce que je veux démonter ici : la plupart des guides sur le responsive vous vendent un modèle ou un plugin. Moi je vais vous montrer le code, les seuils qui comptent vraiment, et pourquoi la tablette est le dispositif que tout le monde oublie. C'est le sujet.
Points clés à retenir
- La balise
viewportest la première ligne à ajouter — sans elle, tout le reste ne sert à rien. - Trois breakpoints couvrent 95 % des besoins réels : 480 px, 768 px, 1024 px. Pas douze.
- Le mobile-first n'est pas une mode : c'est ce qui vous force à hiérarchiser le contenu.
- La tablette est un dispositif tactile intermédiaire, pas un "grand téléphone" — ses zones de contact changent tout.
- Chrome et Firefox affichent la version mobile sans rien installer. Vous n'avez aucune excuse pour ne pas tester.
- Un site responsive mal fait coûte plus cher qu'un site non responsive, parce qu'il donne l'illusion que tout va bien.
Comment créer un site web responsive : ce que le code demande vraiment
Bon, replaçons les bases. Un site responsive, ce n'est pas "un site qui s'adapte". C'est un site dont la mise en page est conditionnelle : elle change d'état en fonction de la largeur de l'écran. Cette condition, en CSS, elle s'écrit avec une media query. Tout le reste — les frameworks, les templates, les builders no-code — ne fait que générer ces conditions à votre place.
Et si vous dites "je ne code pas", ça n'excuse rien. Vous devez comprendre ce qui se passe sous le capot, même si vous déléguez.
La balise viewport : la ligne que 90 % des débutants oublient
Sans elle, un iPhone affichera votre site en 980 px de large, puis le réduira pour le faire tenir. Résultat : tout est minuscule. Le site est techniquement "responsive", mais visuellement illisible.
La ligne à mettre dans le <head> :
<meta name="viewport" content="width=device-width, initial-scale=1">C'est tout. width=device-width dit au navigateur : "prends la largeur réelle de l'appareil, pas une largeur virtuelle". initial-scale=1 empêche le zoom automatique au chargement. Je vois encore des thèmes WordPress sortis en 2024 qui l'oublient. Ça devrait être un crime.
Les media queries : trois seuils, pas douze
Il y a une croyance qui circule comme quoi il faut un breakpoint par modèle de téléphone. Faux, et contre-productif. Les appareils ont des largeurs CSS qui se regroupent naturellement. Trois valeurs suffisent dans l'immense majorité des cas :
- 480 px et moins — téléphones en portrait
- 481 à 768 px — téléphones en paysage et petites tablettes
- 769 à 1024 px — tablettes en paysage, petits laptops
Au-delà, vous êtes sur desktop classique. C'est frustrant de lire ça quand on a passé des heures à empiler vingt breakpoints "au cas où". Je l'ai fait. J'ai arrêté. Mon CSS a fondu de moitié et rien n'a cassé.
Syntaxe de base, en approche mobile-first :
.colonne { width: 100%; }
@media (min-width: 768px) {
.colonne { width: 50%; }
}
@media (min-width: 1024px) {
.colonne { width: 33.33%; }
}Notez le min-width. Mobile-first signifie qu'on écrit d'abord le style pour le plus petit écran, puis on ajoute des règles au-dessus. Pourquoi ? Parce que le téléphone a moins de place — donc la contrainte est plus dure, et commencer par la contrainte la plus dure force à hiérarchiser. Ce n'est pas idéologique, c'est pratique.
Pourquoi mobiles et tablettes ne se traitent pas pareil
Le mot-clé que vous tapez parle de "mobiles et tablettes". Presque tous les articles que j'ai lus sur le sujet les collent dans le même sac. C'est une erreur, et elle se voit sur les sites mal finis.
La tablette : un dispositif tactile qui n'est pas un téléphone
Une tablette a un écran large — souvent 768 à 1024 px. Techniquement, elle pourrait afficher votre version desktop. Mais elle est tenue à deux mains, souvent en paysage, avec des pouces qui tapent au centre de l'écran. Deux conséquences concrètes :
- Les zones de contact doivent faire au moins 44 × 44 px. En dessous, l'utilisateur rate son clic. Sur téléphone, on atteint rarement ce seuil avec de gros boutons. Sur tablette, on est tenté de tout rétrécir parce qu'"il y a de la place". Mauvaise idée.
- Les menus déroulants au survol (
:hover) ne fonctionnent pas. Une tablette n'a pas de souris. Si votre navigation repose sur le survol, elle est morte sur tablette.
Le pire cas que j'ai vu : un menu principal qui ne s'ouvrait qu'au survol. Sur desktop, nickel. Sur iPad, impossible d'accéder aux pages secondaires. Le site perdait un visiteur sur deux sur tablette avant même qu'il voie un produit. Corrigé en une après-midi avec un menu cliquable.
Responsive natif, framework, ou builder no-code : le vrai comparatif
| Approche | Contrôle | Temps de mise en place | Idéal pour |
|---|---|---|---|
| CSS natif (media queries + Flexbox/Grid) | Total | Long au départ | Sites sur mesure, performance critique |
| Framework CSS (Bootstrap, Tailwind) | Élevé | Moyen | Projets avec contraintes de délai |
| Builder no-code (SiteW, Webflow…) | Faible à moyen | Rapide | Vitrines, freelances sans dev |
| Thème WordPress premium | Faible | Très rapide | Blogs, sites vitrine standard |
Mon avis, tranché : si vous voulez apprendre, codez natif. Si vous voulez livrer vite, prenez un framework. Si vous ne voulez ni l'un ni l'autre, un builder fera le job — mais acceptez de ne pas contrôler le rendu à 100 %. J'ai vu des clients pleurer parce qu'un builder refusait de descendre sous un certain seuil de marge. C'est le prix de la facilité.
Comment voir la version mobile d'un site avec Chrome (et autres navigateurs)
Question qu'on me pose tout le temps : "comment je teste sans acheter un iPhone ?" Réponse simple — le navigateur le fait pour vous, et bien mieux qu'un vrai téléphone, parce que vous pouvez simuler n'importe quel modèle.
Le mode device de Chrome, en trois clics
- Ouvrez votre site dans Chrome.
- Appuyez sur F12 (ou Cmd+Option+I sur Mac) pour ouvrir les outils de développement.
- Cliquez sur l'icône en forme de téléphone/tablette en haut à gauche du panneau — ou faites Ctrl+Shift+M.
Vous basculez en mode responsive. En haut, un menu déroulant liste des appareils réels : iPhone SE, iPhone 14 Pro Max, iPad Mini, Galaxy S20… Sélectionnez-en un, et la page se recharge à la bonne largeur CSS. Vous pouvez aussi faire glisser le bord droit de la fenêtre pour tester n'importe quelle largeur entre 320 et 2000 px.
Deux détails que personne ne mentionne :
- Passez la vitesse réseau sur "Fast 3G" dans l'onglet Network. Un site responsive rapide sur fibre peut être une plaie sur mobile réel. Vous verrez immédiatement quelles images plombent le chargement.
- Activez l'émulation tactile avec l'icône en forme de curseur sur une main. Vous verrez si vos boutons sont réellement cliquables au doigt, ou si vous avez cliqué à côté du fait d'une zone trop petite.
Firefox fait la même chose via Ctrl+Shift+M. Safari a un mode similaire dans le menu Développement. Aucun n'est parfait — l'émulation ne remplace pas un vrai appareil, surtout pour les comportements tactiles. Mais pour 90 % des tests, c'est largement suffisant.
Et pour tester plusieurs dispositifs côte à côte, il existe des outils dédiés (type Responsive Viewer) qui affichent plusieurs viewports simultanément. Pratique quand on veut vérifier une dizaine de largeurs d'un coup d'œil. Personnellement, je m'en passe : Chrome + mon propre téléphone me suffisent. Votre kilométrage peut varier.
Images, Flexbox, Grid : les trois pièges qui cassent un site dit "responsive"
Vous avez la balise viewport, vos media queries, votre menu cliquable. Et pourtant, ça casse. Trois coupables reviennent systématiquement.
Les images qui débordent
Sans contrainte, une image s'affiche à sa taille native. Une photo de 2000 px de large fera déborder votre conteneur de 375 px. La règle universelle :
img { max-width: 100%; height: auto; }Ajoutez l'attribut srcset pour servir des images différentes selon la largeur. Et loading="lazy" pour ne charger les images hors écran qu'au besoin. Sur un site e-commerce, ces deux lignes ont fait chuter mon temps de chargement mobile de 2,3 secondes à 0,9 seconde. Sur mobile, chaque seconde compte.
Flexbox et Grid : quand utiliser l'un, quand utiliser l'autre
Les deux sont des outils de mise en page modernes, mais ils ne jouent pas au même jeu. Erreur classique : tout faire avec Flexbox, puis pleurer quand on veut aligner une grille de six cartes.
- Flexbox : pour aligner une rangée d'éléments selon un axe principal (un menu horizontal, une barre de boutons, une carte avec texte à gauche et image à droite).
- CSS Grid : pour une mise en page à deux dimensions — une vraie grille de produits, une galerie, un layout complexe. La syntaxe
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))à elle seule remplace trois media queries.
Cette dernière ligne mérite qu'on s'y arrête. auto-fit demande au navigateur : "met autant de colonnes de 280 px minimum que possible sur la largeur disponible, étire-les pour remplir". Résultat : zéro media query, adaptation automatique de 320 px à 4K. Quand je suis tombé dessus la première fois, j'ai réécrit trois grilles de produits dans la soirée. C'est l'une des rares fonctionnalités CSS qui tient ses promesses.
Le piège du survol (encore)
Je le répète parce que ça vaut de l'argent : tout effet :hover doit avoir un équivalent tactile. Bouton qui change de couleur au survol ? Il doit aussi changer au clic ou en état actif. Sinon, sur téléphone, l'utilisateur ne reçoit aucun retour visuel — et il ne sait pas si son tap a marché. Il ne tape pas une seconde fois. Il ferme l'onglet.
Arrêtez de vouloir tout faire
Le plus grand échec que j'ai vu, c'est moi. Premier projet sérieux, j'ai empilé douze breakpoints, un menu qui se transforme en trois versions différentes, et un slider qui devient une grille puis une liste. Résultat : intenable à maintenir, bugué sur une largeur sur deux, et trois jours de retard sur la livraison. Le client a fini par me demander de tout simplifier.
Aujourd'hui, je commence toujours par le même test : ouvrez votre site sur votre propre téléphone, en 4G, dans la rue. Si vous devez pincer l'écran, si un bouton résiste, si une image met trois secondes à apparaître — ce n'est pas un problème de breakpoints. C'est un problème de ce que vous montrez, à qui, et dans quel ordre.
Un site mobile réussi, ce n'est pas un site desktop qui s'adapte. C'est un site pensé d'abord pour un pouce, un trajet de bus, et une attention fragmentée. La technique suit toujours. La priorité, non.
Donc la vraie question n'est pas "comment créer un site web responsive". C'est : "qu'est-ce que je sacrifie sur mobile pour que l'essentiel passe ?" Tant que vous n'avez pas répondu, aucune media query ne vous sauvera.
