Créer un site responsive pour mobile : le guide qui booste vos conversions

Je vous vois venir : vous avez un site qui s'affiche nickel sur votre écran de bureau, et vous venez de l'ouvrir sur votre téléphone. C'est le drame. Le menu part dans tous les sens, le texte est minuscule, une bannière déborde sur le côté droit. Vous pincez, vous zoomez, vous vous énervez. Et vous vous dites : « bon, il faut que je crée un site responsive pour mobile ».

Bonne nouvelle : c'est faisable sans réécrire tout votre code. Mauvaise nouvelle : la plupart des articles sur le sujet vous expliquent pourquoi il faut le faire, jamais comment. Ils s'arrêtent pile au moment où ça devient intéressant. Je vais faire l'inverse. On va parler media queries, meta viewport, unités relatives, images adaptatives. Du concret, testé sur mes propres projets.

La ligne de code qui décide si votre site est responsive

Si vous ne devez retenir qu'une chose de cet article, retenez celle-ci. Le navigateur mobile, par défaut, se comporte comme un menteur : il affiche votre page dans une fenêtre virtuelle large de 980 pixels, puis la dézoome pour la faire entrer dans l'écran. Résultat, votre design « tient », mais le texte est illisible.

La correction est une balise dans le <head> :

<meta name="viewport" content="width=device-width, initial-scale=1">

Cette instruction dit au navigateur : « prends la largeur réelle de l'écran, pas 980 px ». C'est à partir de ce moment seulement que vos media queries ont un sens. Sur un projet e-commerce que je gérais, j'ai passé deux heures à me demander pourquoi mes styles mobiles ne s'appliquaient jamais. La balise viewport manquait. Deux heures. Pour une ligne.

Pourquoi ce n'est pas une option

Sans elle, vous ne travaillez pas sur un site responsive. Vous travaillez sur un site de bureau qu'on regarde en plissant les yeux. Tous les media queries du monde resteront sans effet, parce que le navigateur considère que l'écran fait 980 px de large — et donc que votre breakpoint à 768 px ne se déclenche jamais.

À l'inverse, une fois la balise en place, vous accédez à la vraie largeur du terminal. Et là, tout devient possible.

Les media queries : poser des points de rupture, pas des recettes

Franchement, la partie la plus mal comprise. On lit partout « faites des breakpoints à 320, 768 et 1024 px ». Comme si les téléphones avaient des tailles fixes. Ils n'en ont pas. Il y a des pliables, des tablettes en mode portrait, des fenêtres de navigateur qu'on redimensionne à la main sur desktop.

Le principe correct : vous ne ciblez pas des appareils, vous ciblez des moments où votre mise en page se casse. Vous réduisez la fenêtre progressivement, et là où ça devient laid, vous posez un point de rupture.

Un exemple concret

Prenons une grille de cartes produits sur trois colonnes. En réduisant le navigateur, à un moment les cartes deviennent trop étroites et le texte passe sur quatre lignes. C'est ce moment-là qui compte. Le CSS ressemble à ceci :

• @media (max-width: 1024px) → deux colonnes
• @media (max-width: 640px) → une colonne, pleine largeur
• À l'intérieur de la seconde, on augmente légèrement la taille de police des paragraphes, parce qu'au doigt, tout petit texte est insupportable

Notez qu'il n'y a que deux points de rupture, pas cinq. C'est volontaire. J'ai longtemps empilé les breakpoints par réflexe, jusqu'à me retrouver avec un fichier CSS de 4 000 lignes où plus personne ne comprenait rien, moi compris. Depuis, je pars du contenu et j'ajoute le minimum.

Le mobile-first, dans cette logique, veut simplement dire : écrivez d'abord les styles pour petit écran, puis ajoutez des media queries en min-width pour les écrans plus larges. Ce n'est pas une religion, c'est une commodité — ça évite de surcharger la cascade.

Avant les media queries : passez aux unités relatives

Beaucoup de développeurs sautent cette étape et se battent ensuite contre leur propre CSS. Si vos tailles sont en pixels fixes, aucun point de rupture ne vous sauvera.

L'idée : une largeur de 350 px sur un écran de 375 px ne laisse presque aucune marge. La même largeur exprimée en 90 % ou en 20rem s'adapte toute seule. Pareil pour les marges et les polices.

Pratique	Effet sur mobile	Verdict
width: 350px	Déborde dès que l'écran est plus petit	À éviter
width: 90%	S'adapte à toutes les largeurs	Bon réflexe
font-size: 16px	Aucune souplesse	Correct mais rigide
font-size: 1rem	Suit les préférences de l'utilisateur	Recommandé
width: 100vw	Peut provoquer un scroll horizontal (barre de défilement)	À manier avec prudence

Le 1rem a un avantage que peu de gens exploitent : si un utilisateur a réglé son téléphone pour afficher du texte plus grand (option d'accessibilité), votre site suivra. Avec des pixels, il restera bloqué à la taille que vous avez décidée, et l'utilisateur devra zoomer. Vous avez perdu.

Les images : le poste que tout le monde oublie

Vous pouvez avoir le CSS le plus propre du monde. Si vous chargez une image de 2 400 px de large sur un téléphone en 4G, votre page mettra trois secondes à afficher quelque chose. Sur mon propre blog, la première fois que j'ai passé un coup de Lighthouse sur mobile, le score était de 34. L'essentiel du problème venait des images, pas du reste.

La solution : srcset et sizes

L'attribut srcset permet de fournir plusieurs versions d'une même image, et de laisser le navigateur choisir celle qui convient :

• Une version légère (par exemple 400 px de large) pour les téléphones
• Une version intermédiaire pour les tablettes
• La version pleine résolution pour les grands écrans
• Un format moderne type WebP ou AVIF, quand c'est possible, avec un fallback JPEG pour les navigateurs anciens

Le navigateur télécharge la version adaptée. Pas celle que vous auriez choisie à sa place. Après avoir corrigé ce point sur ce même blog, mon score Lighthouse mobile est passé de 34 à 78, sans toucher une ligne de JavaScript.

Concrètement, ça ressemble à :

<img src="photo-800.jpg" srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w" sizes="(max-width: 640px) 100vw, 50vw">

Ça paraît intimidant la première fois. Ça ne l'est pas. Et le gain vaut largement les vingt minutes passées à comprendre la syntaxe.

Responsive ou site mobile dédié : le vrai arbitrage

Question qu'on me pose souvent : « est-ce que je fais un vrai site mobile séparé, genre m.monsite.com ? » Ma réponse a changé en quelques années. Aujourd'hui, je vous le dis franchement : non.

Le site mobile dédié a eu son heure. Il obligeait à maintenir deux bases de code, deux jeux de contenus, deux systèmes de suivi. Chaque correction devait être faite deux fois. Et quand un utilisateur partageait un lien depuis la version mobile, il tombait sur une URL qui n'existait que pour son appareil. Cauchemar.

Le responsive porte une seule base de code. Le référencement se traite sur une seule adresse. La maintenance vous remercie. La seule raison sérieuse de séparer les deux, à mon sens, c'est un cas d'usage radicalement différent — par exemple une application interne où le mobile sert à faire du reporting rapide et le desktop à gérer des paramètres complexes. Ça reste rare.

Et l'adaptive design ?

L'adaptive design, c'est l'entre-deux : plusieurs mises en page figées, choisies en fonction de l'appareil détecté. Plus de contrôle, plus de travail. Pour 95 % des sites, ce n'est pas rentable. Je le mentionne parce qu'on me le demande, pas parce que je le recommande.

Tester pour de vrai : ce qui marche, et ce qui ne marche pas

Vous avez posé le viewport, écrit deux breakpoints, converti vos unités en rem. Bravo. Maintenant, vérifiez.

Les outils du navigateur

Les DevTools de Chrome, Firefox ou Safari intègrent un mode simulation. Vous choisissez un modèle de téléphone, vous redimensionnez, vous regardez. C'est pratique, rapide, et ça couvre 80 % des problèmes d'affichage. Mais ce n'est pas suffisant, et voici pourquoi.

Le test qui compte

DevTools ne vous dira pas que votre bouton est impossible à cliquer avec un pouce. Il ne vous dira pas que votre menu, une fois ouvert, couvre un tiers de l'écran. Il ne vous dira pas que votre texte est trop petit pour être lu dans le métro, avec le reflet du soleil sur l'écran.

Sortez le téléphone. Cliquez sur le bouton avec votre pouce, vraiment. Faites défiler dans les deux sens — si ça part latéralement, c'est qu'une largeur fixe traîne quelque part. Testez avec le mode avion activé pour voir ce que votre page charge réellement.

Les zones tactiles, c'est le point qu'on sous-estime le plus. Un élément cliquable en dessous de 44 px de côté se rate systématiquement avec un doigt. Je l'ai appris à mes dépens sur une page de paiement. Le taux d'abandon sur cette page était deux fois plus élevé sur mobile que sur desktop. En cause : un petit bouton « valider » placé à côté d'un champ. Un correctif d'une ligne CSS a tout remis d'aplomb.

Ce que je fais, concrètement, sur un nouveau projet

Un ordre que je suis scrupuleusement, dans cet ordre précis :

1. Meta viewport dans le head. Avant tout le reste.
2. Toutes les dimensions en unités relatives dès la première ligne CSS.
3. Écriture des styles mobile d'abord, media queries en min-width ajoutés ensuite.
4. Images avec srcset et un format moderne, dès qu'une image entre dans le projet.
5. Test sur téléphone réel avant chaque mise en ligne.

Ce n'est pas spectaculaire. Ce n'est pas une méthode marketing. C'est juste du travail propre.

Et une dernière chose. Je vois encore des sites lancés en 2026 avec une largeur fixe à 1200 px et un message « veuillez consulter ce site sur ordinateur ». Cette phrase existe encore. Elle est le symbole d'un malentendu tenace : celui d'un web où le mobile serait une option. Ce n'est plus le cas depuis longtemps. Il n'y a qu'un web, et il est étroit.