Optimisation site mobile : audit en 10 points pour un hôtel

Optimisation site mobile : pour un hôtel, la question n’est pas « le site s’affiche-t-il sur un téléphone ? », mais « un voyageur peut-il, d’une main, voir une chambre, choisir ses dates et réserver, sans attendre ? ». Voici comment le vérifier : trois mesures à relever d’abord, un audit en dix points, la place de l’intelligence artificielle, et le parcours de réservation en trois écrans.

Mesurer d’abord, avant de toucher à quoi que ce soit

Google indexe la version mobile d’un site et s’en sert pour le classement (sa documentation). Mais l’optimisation sert d’abord le voyageur : une page lente, ou qui bouge pendant qu’il touche l’écran, se quitte. Aucun réglage ne garantit une place dans les résultats ; ce qui se vérifie, c’est l’expérience.

Google la résume en trois mesures, les « Core Web Vitals », dont web.dev publie les seuils « bon » et les seuils « médiocre » ; entre les deux, la mesure est « à améliorer ».

Ces seuils s’appliquent au 75^e centile des visites, séparément sur mobile et sur ordinateur : pour être jugée « bonne », une page doit l’être pour trois visites sur quatre. Les données de terrain viennent de visiteurs réels, sur 28 jours ; la Search Console et PageSpeed Insights les affichent quand il y a assez de visites. Les données de laboratoire viennent d’un test simulé, avec un téléphone de milieu de gamme ; elles servent à chercher la cause d’un défaut. Les outils sont détaillés dans notre article sur le test d’un site responsive.

Optimisation site mobile : les 10 points d’un audit

Chaque point se termine par un contrôle à faire sur votre propre site, avec un téléphone ou le mode appareil d’un navigateur.

1. Des images légères, dans un format moderne. MDN compte environ 50 % de moins pour une image AVIF que pour un JPEG de qualité visuelle proche, avec un JPEG en repli pour les navigateurs qui n’affichent pas l’AVIF. Servez plusieurs largeurs, comme sur cette page : un téléphone n’a pas besoin de la photo d’un grand écran. Pour l’image d’en-tête, web.dev recommande de ne jamais la charger en différé (loading="lazy" est pour les images plus bas) et de lui donner fetchpriority="high", sur une ou deux images au plus. Des attributs width et height sur chaque image réservent sa place et limitent les sauts de mise en page. Vérifier : poids et format de l’image d’en-tête, et absence de loading="lazy" sur elle.
2. Des polices légères, servies par le site. web.dev conseille le format WOFF2, de ne charger que les caractères utiles, de choisir une stratégie font-display et d’ajuster la police de repli avec size-adjust pour limiter le saut de texte au changement de police. Vérifier : le nombre de fichiers de polices chargés, et si le texte bouge quand la police arrive.
3. Peu de JavaScript, surtout venu de services tiers. Un chat, un carrousel, un module d’avis ou un outil de suivi sollicitent le processeur du téléphone : le mode appareil de Chrome le simule 4 fois (milieu de gamme) ou 6 fois (entrée de gamme) plus lent que l’ordinateur du test. web.dev cite les longues tâches de script au démarrage parmi les causes d’un mauvais délai de réponse. Vérifier : la liste des scripts dans l’onglet Réseau ; retirer ceux qui ne servent ni à lire ni à réserver.
4. Un bouton « Réserver » visible sans défiler. Dans l’en-tête ou dans une barre fixe, avec un libellé écrit et pas seulement une icône. Une barre fixe ne doit pas non plus cacher entièrement l’élément qui reçoit le focus au clavier : c’est le critère 2.4.11 de WCAG 2.2, de niveau AA. Des exemples sont dans l’article sur les réservations directes. Vérifier : sur l’accueil et sur une page de chambre, le bouton est-il visible sans défiler, et le reste-t-il quand on descend ?
5. Un calendrier fait pour le doigt. Le champ de date natif a un défaut pour un hôtel : MDN explique que son aspect varie selon le navigateur et le système ; la page décrit un minimum, un maximum et un pas, mais aucun moyen de marquer des nuits déjà prises. Un bon calendrier de réservation s’ouvre au toucher du champ, grise les jours passés, marque les jours indisponibles et se ferme sans effort (voir plus bas). Vérifier : choisir une arrivée et un départ d’une main, sans zoomer ni se tromper de jour.
6. Un formulaire qui se remplit vite. web.dev recommande l’attribut autocomplete sur chaque champ, le type email ou tel pour afficher le bon clavier, et inputmode="numeric" pour un champ de chiffres. Vérifier : le clavier qui s’ouvre pour le téléphone et pour l’adresse e-mail, et la proposition de remplissage automatique.
7. Des zones de toucher assez grandes. web.dev recommande environ 48 pixels, espacés d’environ 8 pixels. Le critère 2.5.8 de WCAG 2.2, de niveau AA, fixe un plancher de 24 sur 24 pixels CSS, avec des exceptions, dont celle des cibles bien espacées. Vérifier : le menu, la croix de fermeture, les boutons plus et moins du nombre de voyageurs : les touche-t-on du premier coup avec le pouce ?
8. Un texte lisible, un zoom libre. Le contraste doit atteindre 4,5 pour 1 pour le texte courant, 3 pour 1 pour le grand texte ; le cas fréquent en hôtellerie est un titre posé sur une photo dont le fond change d’un endroit à l’autre. Ne bloquez pas le zoom : MDN avertit que user-scalable=no empêche les personnes malvoyantes de lire la page. Vérifier : le titre de l’accueil et le texte des boutons, au soleil comme à luminosité réduite, et le pincement pour agrandir.
9. Peu de fenêtres et de bandeaux. La documentation de Google sur les fenêtres intrusives vise celles qui masquent le contenu ; elle recommande plutôt un bandeau qui n’occupe qu’une petite part de l’écran, et ne parle pas des bandeaux de cookies. Sur un site de réservation relevé en octobre 2026 dans un navigateur émulant un téléphone de 390 pixels de large, un bandeau de consentement à trois boutons couvrait près de la moitié du premier écran. Vérifier : la part de l’écran couverte à la première visite, et ce qui apparaît ensuite (inscription, promotion).
10. Un parcours de réservation aussi rapide que l’accueil. Un accueil rapide peut cacher un tunnel lent. Vérifier : testez dans PageSpeed Insights la page de résultats de recherche, puis faites tout le parcours sur un vrai téléphone, jusqu’à la confirmation. Détail des étapes dans l’optimisation du tunnel de réservation ; effet de la lenteur dans pourquoi un site lent fait gagner de l’argent à Booking.

Ce que l’IA aide à faire dans un audit

L’intelligence artificielle ne remplace pas la mesure, mais elle accélère le tri. Trois usages tiennent la route :

• Regrouper les alertes. Un rapport PageSpeed Insights ou Lighthouse enregistré en fichier se colle dans un assistant, qui range les alertes par cause : images, scripts, polices, mise en page.
• Relire le code d’une page. Un assistant repère vite les images sans width ni height, la photo d’en-tête différée, un champ sans autocomplete.
• Revoir le formulaire. Il propose de supprimer ou de regrouper des champs, et de reformuler un libellé ou un message d’erreur.

Ses limites sont nettes. Il ne tient pas de téléphone : il ne voit pas qu’un bandeau couvre l’écran ni qu’un bouton se touche mal. Il peut affirmer une mesure qu’il n’a pas faite : tout chiffre se relit dans l’outil de mesure. Et la décision, comme retirer un module d’avis trop lourd, revient à l’établissement.

Réservation mobile : le parcours en 3 écrans

Trois écrans suffisent à jalonner l’audit : c’est là que la réservation se gagne ou se perd.

1. La recherche. Les champs d’arrivée, de départ et de voyageurs, et le bouton de recherche, sont dans le premier écran de la page de réservation.
2. Le calendrier. Il s’ouvre au toucher du champ, indique ce qui est disponible, et laisse choisir les deux dates sans zoomer.
3. Le choix et le paiement. Le récapitulatif du séjour reste visible, le total est lisible avant la saisie de la carte, et le retour en arrière ne vide pas la recherche.

Voici les deux premiers écrans de la page de réservation de la Villa Arty Riviera, relevés en octobre 2026 dans un navigateur qui émule un iPhone de 390 pixels de large (et non sur un vrai téléphone).

À gauche, les quatre champs se voient sans défiler, le bouton « Chercher » affleure en bas de l’écran, et les champs mesurent 72 pixels de haut. À droite, le calendrier s’ouvre au toucher de « Date d’arrivée » : les jours passés sont grisés, les jours indisponibles sont marqués en rose, et une croix ferme la fenêtre.

Si l’un de ces écrans cloche, la solution passe autant par le moteur de réservation que par les pages : voir le site avec moteur de réservation, le site vitrine, le référencement naturel et les techniques de référencement pour les sites de réservation. Documents cités lus en octobre 2026 ; les seuils pouvant évoluer, vérifiez-les sur web.dev.

Questions fréquentes sur l’optimisation mobile d’un site d’hôtel