Un site « responsive » adapte sa mise en page à la largeur de l’écran : la même adresse s’affiche sur ordinateur, sur tablette et sur téléphone. Pour un hôtel ou un restaurant, la bonne question n’est pas « mon site est-il responsive ? », mais « un client peut-il, depuis son téléphone, trouver l’adresse, voir les chambres ou la carte, et réserver ? ». Voici comment le vérifier avec des outils qui fonctionnent aujourd’hui, une liste de contrôle, et quatre sites réels passés au test.
Responsive : ce que cela change, et pourquoi le tester
Avant le responsive, certains sites existaient en deux versions : un site pour ordinateur et un site réservé aux petits écrans, souvent sur une adresse du type m.exemple.com. Il fallait mettre à jour les deux. Le responsive a remplacé cette solution : une seule page, un seul contenu, des règles de mise en page qui s’ajustent à la largeur disponible.
Le test reste nécessaire, pour une raison simple : « responsive » ne dit pas « bien fait ». Un menu peut se replier sans que ses sous-menus s’ouvrent au doigt, un bandeau de dates peut sortir de l’écran, un bouton de réservation peut se cacher derrière une fenêtre. Seul un essai le montre.
Il y a aussi une raison liée à Google. Le moteur de recherche indexe la version mobile du contenu et s’en sert pour le classement : sa documentation sur l’indexation mobile d’abord demande que la version mobile porte le même contenu principal que la version pour ordinateur, avec les mêmes titres, les mêmes balises de titre et de description, les mêmes données structurées, et des images avec leur texte alternatif. Les onglets et les accordéons sont admis pour gagner de la place ; en revanche, Google prévient qu’une page mobile moins fournie que la page pour ordinateur peut perdre du trafic. Google a annoncé qu’après le 5 juillet 2024, les derniers sites encore explorés avec son robot pour ordinateur le seraient avec son robot pour smartphone : un contenu qui n’est pas du tout accessible sur un appareil mobile n’est plus indexable.
Pour la suite de votre visibilité sur Google, voir aussi comment améliorer le référencement de son hôtel, le référencement naturel pour hôtels et les techniques de référencement pour les sites de réservation.
L’outil de test de Google n’existe plus
Notre ancienne version de cet article renvoyait vers l’outil de test d’optimisation mobile de Google. Il a été retiré : Google l’avait annoncé en avril 2023, puis a confirmé que l’outil et le rapport d’ergonomie mobile de la Search Console (« Mobile Usability ») ont été retirés le 1er décembre 2023. Google précise que l’ergonomie mobile compte toujours, et cite Lighthouse parmi les ressources apparues depuis pour l’évaluer. Si un guide vous donne encore l’adresse de l’ancien outil, il est périmé.
Les outils qui fonctionnent aujourd’hui
Les outils de développement de Chrome
C’est le plus rapide. Ouvrez votre site dans Chrome, ouvrez les outils de développement, puis cliquez sur l’icône de la barre d’outils des appareils (« Toggle device toolbar » en anglais, une icône de téléphone et de tablette). Le mode appareil propose :
- le mode Responsive : vous tirez les poignées de la fenêtre ou vous saisissez une largeur et une hauteur ; les préréglages de largeur vont de 320 à 2 560 px. C’est le meilleur moyen de trouver le point où la mise en page casse ;
- une liste d’appareils pour reprendre les dimensions d’un modèle précis ;
- un type d’appareil : « Mobile » reproduit un rendu mobile et envoie des événements tactiles, ce qui révèle un menu qui ne s’ouvre qu’au survol de la souris ;
- un ralentissement du réseau et du processeur : « mobile milieu de gamme » (3G rapide, processeur 4 fois plus lent) ou « mobile d’entrée de gamme » (3G lente, processeur 6 fois plus lent).
Chrome est franc sur la limite : ce mode est une « approximation de premier ordre » ; il tourne sur votre ordinateur, pas sur un téléphone.
Safari, pour voir comme sur iPhone et iPad
Safari sur Mac a son propre mode, utile pour voir l’affichage de Safari, le navigateur d’Apple. Activez le menu Développement dans les réglages de Safari (onglet Avancé), ouvrez votre page, puis choisissez dans ce menu la commande du mode adaptatif (« Enter Responsive Design Mode » en anglais) ou tapez Ctrl + Cmd + R. Vous y trouvez des préréglages de tailles d’iPhone et d’iPad, un bouton pour faire pivoter l’écran et un réglage de densité de pixels. Apple précise que ces préréglages donnent une bonne approximation, mais pas le rendu exact d’un appareil : la barre d’adresse, le clavier à l’écran ou le comportement des champs de formulaire changent l’affichage. Avec Xcode installé, le même menu permet d’ouvrir la page dans un simulateur d’iPhone ou d’iPad, plus fidèle.
Firefox
Le mode d’affichage adaptatif de Firefox s’ouvre avec Ctrl + Maj + M (Cmd + Option + M sur Mac). Il propose une liste d’appareils, la simulation du toucher et un ralentissement du réseau, que Mozilla présente comme une approximation à ne pas utiliser pour des mesures exactes. C’est un troisième moteur d’affichage à essayer en quelques secondes.
Lighthouse et PageSpeed Insights
Lighthouse est intégré à Chrome (onglet « Lighthouse » des outils de développement). Il passe la page en revue : performance, accessibilité, bonnes pratiques, référencement, entre autres. Le même moteur sert à PageSpeed Insights (pagespeed.web.dev), sans rien installer : entrez l’adresse de la page et lisez d’abord l’onglet Mobile. Le test mobile y simule le chargement sur un téléphone de milieu de gamme, avec une connexion mobile. PageSpeed Insights ajoute aussi des données de visiteurs réels, quand il y en a assez, sur les 28 derniers jours.
Un contrôle précis intéresse notre sujet : Lighthouse vérifie que la page contient la balise viewport et que celle-ci contient width=. Sans cette balise, un téléphone affiche la page comme sur un grand écran, puis la réduit.
La Search Console, avec de vrais visiteurs
Le rapport « Signaux Web essentiels » (Core Web Vitals) de la Search Console, séparé en mobile et ordinateur, repose sur des données de visiteurs réels. Il classe les groupes de pages en « bon », « à améliorer » ou « médiocre » d’après trois mesures, dont les seuils sont publiés sur web.dev : le temps d’affichage du plus grand élément (LCP, bon jusqu’à 2,5 secondes), la réactivité (INP, bon jusqu’à 200 millisecondes) et la stabilité de la mise en page (CLS, bon jusqu’à 0,1). Il ne montre qu’un échantillon des pages indexées.
Tester sur un vrai téléphone ou une vraie tablette
Un essai sur un appareil réel révèle ce que les simulateurs oublient : la barre d’adresse qui se replie, le clavier qui masque un champ, le toucher imprécis. Commencez simplement, puis branchez l’appareil à l’ordinateur si quelque chose cloche.
- Simplement ouvrir la page. Sur votre téléphone et sur une tablette, depuis les deux navigateurs les plus courants (Safari et Chrome), faites le parcours d’un client : trouver le numéro, voir une chambre ou la carte, choisir des dates.
- Brancher l’appareil à l’ordinateur pour voir sa page dans les outils de développement. Sur Android avec Chrome, activez le débogage USB, branchez le téléphone, ouvrez
chrome://inspect#devicessur l’ordinateur et cliquez sur « Inspect » à côté de l’onglet voulu. - Faire de même avec un iPhone ou un iPad. Dans Réglages › Apps › Safari › Avancé, activez « Web Inspector », branchez l’appareil au Mac par un câble (acceptez de faire confiance au Mac si l’appareil le demande), puis choisissez la page dans le menu Développement de Safari.
La liste de contrôle
Passez-la à trois largeurs au moins : 1440 px (ordinateur), 768 px (tablette en portrait) et 375 px (téléphone). Ce sont des repères de test, pas des normes ; réduisez aussi la fenêtre en continu de 1440 à 320 px pour voir où la mise en page cède. Les « points de rupture » doivent être choisis selon le contenu, et non selon des modèles d’appareils, comme le conseille web.dev.
| Point | Comment le vérifier | Bon résultat |
|---|---|---|
| Balise viewport | Regarder le code de la page, ou lancer Lighthouse. | La balise <meta name="viewport"> contient width=device-width. |
| Pas de défilement horizontal | Réduire la fenêtre à 320, puis 375 px, et lancer la ligne de code ci-dessous. | Rien ne dépasse de l’écran ; la page ne se déplace pas de côté. |
| Menu | L’ouvrir et le fermer au doigt, en mode tactile, sous-menus compris. | Tous les liens sont atteignables sans survol de souris. |
| Réservation | Depuis l’accueil, compter les gestes jusqu’au choix des dates. | Le formulaire ou le bouton est dans le premier écran, ou à un geste dans l’en-tête. |
| Téléphone et adresse | Toucher le numéro et l’adresse. | L’appel se lance ; l’adresse est repérable sans zoom. |
| Zones tactiles | Toucher chaque bouton et chaque lien du pouce. | Au moins 24 × 24 px (niveau AA des règles d’accessibilité WCAG 2.2) ; web.dev recommande environ 48 px, espacés d’environ 8 px. |
| Texte | Lire une page entière sans pincer l’écran. | Texte lisible, y compris celui posé sur une photo. |
| Zoom | Pincer l’écran pour agrandir. | Le zoom n’est pas bloqué. |
| Images | Parcourir la page, onglet « Réseau » ouvert. | Aucune image déformée ; des dimensions déclarées pour que la page ne saute pas au chargement ; des fichiers légers. |
| Formulaires | Remplir une demande de réservation ou de contact. | Champs assez grands, clavier adapté (un champ de type tel peut ouvrir un clavier numérique), bouton d’envoi visible. |
| Fenêtres et bandeaux | Ouvrir la page en navigation privée : bandeau de cookies, fenêtre d’offre. | Rien ne masque le bouton de réservation ; tout se ferme au doigt. |
| Orientation et contenu | Faire pivoter l’écran, puis comparer avec la version pour ordinateur. | Mise en page correcte en portrait et en paysage ; mêmes textes, titres et images que sur ordinateur. |
Pour la deuxième ligne, collez ceci dans la console des outils de développement :
document.documentElement.scrollWidth > document.documentElement.clientWidthLa réponse true indique que la page est plus large que l’écran : quelque chose dépasse. Images, tableaux, bandeaux de dates et vidéos intégrées sont les premiers éléments à regarder.
Quatre sites passés au test
Nous avons ouvert quatre sites que nous avons réalisés, le 17 octobre 2026, à 1440, 768 et 375 px de large dans un navigateur, et regardé leur premier écran. Des appartements de luxe, un appart’hôtel, une maison d’hôtes et le restaurant de la même maison, qui a son propre site : à chaque fois, le point à regarder est le même, celui du client qui veut réserver ou appeler. Ces sites évoluent ; les images montrent leur état à cette date.
Augustins 1261
Appartements de luxe · Avignon
Sur ordinateur, le menu est déployé sous le logo, avec ses sous-menus. À 768 px il se replie derrière un bouton à trois barres, à gauche du logo, et le bouton « Réservation » reste à droite. À 375 px, ce bouton passe sous la barre et prend toute la largeur : on peut réserver sans ouvrir le menu.
À retenir
- Le menu se replie dès 768 px : une tablette n’est pas traitée comme un ordinateur.
- Un bouton « Réservation » visible sans ouvrir le menu, aux trois largeurs.
- Type
- Appartements de luxe, deux maisons
- Lieu
- Avignon, intra-muros (Vaucluse)
- Réservation
- En ligne, moteur Reservit
- Langues
- français, anglais, allemand
Chez MV
Appart’hôtel, villas et suites · La Ferté-Gaucher
La recherche de disponibilités (arrivée, départ, voyageurs, bouton « Rechercher ») est posée au bas du premier écran aux trois largeurs : le visiteur choisit ses dates sans faire défiler la page. Sur tablette et sur téléphone, le bouton « Rechercher » prend toute la largeur de la barre et le menu devient un bouton à trois barres.
À retenir
- La recherche de dates est dans le premier écran, quelle que soit la largeur.
- Un seul bouton « Rechercher », en pleine largeur sur tablette et téléphone.
- Type
- Appart’hôtel, villas et suites
- Lieu
- La Ferté-Gaucher (Seine-et-Marne)
- Réservation
- Recherche de disponibilités par dates
- Langues
- français, anglais, espagnol
Les Jardins de la Livrée, la maison d’hôtes
Maison d’hôtes · Villeneuve-lès-Avignon
En haut de page, une barre fine donne le type d’établissement, le numéro de téléphone, l’adresse et le choix de la langue, aux trois largeurs. Sur ordinateur, le menu est déployé à côté du logo ; à 768 px, il se replie derrière un bouton à trois barres. À 375 px, la barre du haut passe sur deux lignes et le logo se place au-dessus du bouton de menu. Le numéro de téléphone est un lien d’appel : sur un téléphone, il suffit de le toucher.
À retenir
- Le numéro de téléphone reste en haut de l’écran à toutes les largeurs, et se touche pour appeler.
- Sur téléphone, la barre du haut passe sur deux lignes au lieu de couper son texte.
- Type
- Maison d’hôtes
- Lieu
- Villeneuve-lès-Avignon (Gard)
- Réservation
- En ligne, moteur Eviivo
- Langues
- français, anglais
Les Jardins de la Livrée, le restaurant
Restaurant · Villeneuve-lès-Avignon
Sur ordinateur, le texte d’accueil est à gauche et la photo à droite. À 768 et 375 px, le texte passe en premier et la photo vient dessous ; les liens du menu (Accueil, Le restaurant, La carte, Galerie, Accès) restent visibles sans bouton de menu. Les boutons « Réserver » et « Réserver une table » sont dans le premier écran, ainsi que « Découvrir la carte ». Le site précise que la réservation se fait uniquement par téléphone.
À retenir
- La carte et la réservation sont dans le premier écran, même sur téléphone.
- Texte et photo, côte à côte sur ordinateur, s’empilent sur petit écran : le texte d’abord.
- Type
- Restaurant
- Lieu
- Villeneuve-lès-Avignon (Gard)
- Réservation
- Par téléphone
- Langues
- français, anglais
| Site | Lieu | Type | Réservation | Langues |
|---|---|---|---|---|
| Augustins 1261 | Avignon, intra-muros (Vaucluse) | Appartements de luxe, deux maisons | En ligne, moteur Reservit | français, anglais, allemand |
| Chez MV | La Ferté-Gaucher (Seine-et-Marne) | Appart’hôtel, villas et suites | Recherche de disponibilités par dates | français, anglais, espagnol |
| Les Jardins de la Livrée, la maison d’hôtes | Villeneuve-lès-Avignon (Gard) | Maison d’hôtes | En ligne, moteur Eviivo | français, anglais |
| Les Jardins de la Livrée, le restaurant | Villeneuve-lès-Avignon (Gard) | Restaurant | Par téléphone | français, anglais |
Ces captures viennent d’un navigateur sur ordinateur : elles montrent la mise en page, pas la vitesse ni le toucher, qui se jugent sur un vrai appareil. Pour d’autres sites classés par type d’établissement, voir nos exemples pour les resorts, les appart’hôtels, les love rooms, les auberges et les bungalows.
Les problèmes à chercher en priorité
- Un bandeau de dates qui sort de l’écran. Les champs d’arrivée, de départ et de voyageurs doivent passer en colonne, ou garder une ligne lisible, à 375 px. C’est la première chose à regarder pour transformer les visiteurs venus de Booking en clients directs.
- Un menu qui ne s’ouvre qu’au survol. Au doigt, il n’y a pas de survol : le menu doit s’ouvrir au toucher.
- Une carte de restaurant en image ou en PDF. Il faut pincer l’écran pour la lire. Une carte écrite dans la page s’adapte à l’écran ; voir aussi le référencement d’un restaurant.
- Une photo plein écran qui cache le texte ou le bouton. Apple note que la barre d’adresse d’un appareil réel modifie la mise en page : vérifiez que le bouton de réservation reste visible.
- Des effets de défilement trop lourds. Un effet de parallaxe agréable sur ordinateur peut ralentir un téléphone : notre article sur la parallaxe aide à les doser.
- Du contenu retiré sur mobile. web.dev conseille de ne pas masquer par défaut des informations importantes sur petit écran ; Google, on l’a vu, indexe la version mobile.
- Une page d’arrivée mal adaptée. Une publicité ou une fiche Google mène à une page de votre site : ouvrez-la sur téléphone avant de la diffuser. Voir la publicité pour hôtels et restaurants et ses pages Facebook, Instagram, TikTok, Google Ads, Google Hotel Ads et la fiche Google. Même chose pour la page où mène un e-mail à vos clients.
Dans quel ordre corriger
- Rendre la réservation accessible. Bouton ou formulaire visible dès le premier écran, numéro de téléphone qui se touche. C’est ce qui rapporte directement des réservations directes ; voir aussi l’optimisation du tunnel de réservation.
- Supprimer tout ce qui dépasse. Plus de défilement horizontal, plus de texte coupé.
- Alléger les pages. Des images à la bonne taille, un format moderne, des dimensions déclarées : le résultat se lit dans PageSpeed Insights et dans la Search Console.
- Vérifier l’équivalence avec la version pour ordinateur. Mêmes textes, mêmes titres, mêmes images, mêmes balises.
- Recommencer à chaque changement. Une mise à jour du site, une nouvelle bannière ou un nouveau module de réservation peuvent casser ce qui marchait.
Pour replacer ce travail dans une démarche d’ensemble, voir les mesures à prendre pour concevoir un site d’hôtel, le guide de webmarketing pour l’hôtellerie et la restauration et notre approche du web pour le tourisme. Pour les enjeux face aux plateformes, voir les leviers web pour reprendre la main face aux OTA et comment récupérer les données clients que Booking garde pour lui.
Les sites que nous réalisons pour les hôtels, les restaurants et les hébergements sont responsive. Si le vôtre ne passe pas la liste de contrôle, écrivez-nous : nous regardons ce qui coince.
Questions fréquentes sur le test responsive
Comment savoir si mon site est responsive ?
Ouvrez-le sur un ordinateur et réduisez la largeur de la fenêtre du navigateur : sur un site responsive, les éléments se réorganisent et le menu devient en général un bouton à trois barres. Pour aller plus loin, utilisez le mode appareil des outils de développement de Chrome, Safari ou Firefox, puis passez la liste de contrôle.
Quel outil remplace le test d’optimisation mobile de Google ?
Aucun outil ne le remplace seul. Selon Google, l’outil et le rapport d’ergonomie mobile de la Search Console ont été retirés le 1er décembre 2023. On utilise désormais le mode appareil du navigateur, Lighthouse (dans Chrome) ou PageSpeed Insights, et un essai sur un vrai téléphone.
Quelles largeurs d’écran faut-il tester ?
Au moins trois : 1440 px pour l’ordinateur, 768 px pour une tablette en portrait et 375 px pour un téléphone. Ce sont des repères. Réduisez aussi la fenêtre en continu de 1440 à 320 px pour trouver où la mise en page casse, puis essayez l’écran en paysage.
Un site responsive est-il mieux placé sur Google ?
Google indexe la version mobile du contenu et s’en sert pour le classement. Sa documentation recommande « très fortement » une version adaptée au mobile, avec le même contenu principal, les mêmes titres, les mêmes balises et les mêmes données structurées que sur ordinateur. Un site responsive sert la même page aux deux. Après le 5 juillet 2024, un contenu qui n’est pas du tout accessible sur un appareil mobile n’est plus indexable.
Le simulateur du navigateur suffit-il ?
Non. Chrome le décrit comme une « approximation de premier ordre » et Apple note que la barre d’adresse, le clavier à l’écran ou le comportement des formulaires modifient l’affichage d’un vrai appareil. Faites au moins un essai sur un téléphone et sur une tablette.
Faut-il autoriser le zoom sur mobile ?
Oui. Bloquer le zoom avec user-scalable=no empêche les personnes qui voient mal d’agrandir le texte. Selon la documentation de Mozilla, les règles d’accessibilité demandent au moins un agrandissement de deux fois ; la bonne pratique est d’autoriser cinq fois.
Que vérifier en premier sur un site d’hôtel ou de restaurant ?
Le parcours du client : trouver le numéro de téléphone, voir la chambre ou la carte, choisir ses dates et réserver, depuis l’écran d’un téléphone et sans zoomer. Ensuite, l’absence de contenu qui dépasse de l’écran, puis la vitesse.
