Le voyageur choisit sa chambre, puis il disparaît
Un dimanche soir, un couple ouvre votre site depuis son canapé. Il fait défiler vos photos, choisit une chambre supérieure pour deux nuits en septembre, arrive sur l'écran de paiement. Puis il ferme l'onglet.
Le lendemain matin, il réserve la même chambre, chez vous, aux mêmes dates. Sur une plateforme de réservation, en trois pressions du pouce, avec la carte déjà enregistrée dans l'application.
Vous ne saurez jamais que cela s'est produit. Vous verrez la réservation arriver, vous paierez la commission, et vous conclurez que la plateforme travaille mieux que votre site. Ce n'est pas faux. Ce n'est simplement pas pour la raison que vous croyez.
Ce qui suit ne parle pas de design ni de vitesse d'affichage. Cela décrit huit endroits précis, répartis le long du parcours, où un voyageur muni d'un téléphone renonce. Quatre d'entre eux se corrigent sans toucher au code de votre site. Le dernier ne vous appartient qu'en partie, et c'est le plus coûteux.
Votre téléphone n'est pas celui de votre voyageur
Commençons par la raison pour laquelle le problème vous échappe.
Vous avez déjà ouvert votre site sur votre propre appareil. Vous l'avez trouvé correct, peut-être même agréable. Vous avez raison : sur votre appareil, il l'est.
Votre téléphone est récent, ou au moins entretenu. Il est connecté au réseau sans fil de votre établissement. Le navigateur a mémorisé votre adresse, votre nom, votre numéro. Vous connaissez vos propres tarifs, vos catégories de chambres, la différence entre votre « supérieure » et votre « deluxe ». Et vous testez assis, avec deux mains, sans intention d'acheter.
Votre voyageur est ailleurs. Il tient son téléphone d'une main, l'autre occupée. Il est dans un train, dans une salle d'attente, ou debout dans une cuisine. Sa connexion faiblit par intermittence. Son écran est plus petit que le vôtre, ou son téléphone plus ancien. Il ne connaît ni vos catégories ni vos usages. Et il compare, en ce moment même, avec deux autres onglets ouverts.
Ce n'est pas le même parcours. Ce n'est pas non plus la même personne.
La part de vos visiteurs qui arrivent par téléphone, un outil de mesure d'audience vous la donne, dans le rapport qui distingue les appareils. Ce chiffre vous appartient et personne d'autre ne peut vous le fournir. Il détermine à lui seul l'importance de tout ce qui suit.
La vitesse d'affichage n'est presque jamais la cause, et c'est une bonne nouvelle
Lorsqu'un site reçoit des visiteurs sans recevoir de réservations, la première réponse proposée porte sur la vitesse. Compresser les images, réduire les scripts, améliorer les mesures de performance.
Ces travaux sont utiles. Ils ne règlent pas ce dont il est question ici.
Un site lent perd le visiteur avant qu'il ne voie quoi que ce soit. C'est un problème d'arrivée. Or votre couple du dimanche soir a vu vos photos, lu vos descriptions, choisi une chambre et atteint l'écran de paiement. La lenteur n'est pas ce qui l'a fait renoncer.
Ce qui l'a fait renoncer, c'est un geste qu'il n'a pas réussi à accomplir, ou une information qui a changé sous ses yeux.
La bonne nouvelle tient là. Un problème de vitesse impose une intervention technique et une facture. Un problème de parcours se répare souvent par un réglage, une phrase réécrite, une case décochée dans l'interface de votre moteur de réservation — l'outil qui affiche vos disponibilités et encaisse le règlement, que celui-ci soit intégré à votre site ou fourni par un prestataire.
Sept points de décrochage se rencontrent avant l'étape bancaire
Ils sont présentés dans l'ordre où votre voyageur les traverse.
1. Un panneau recouvre l'écran avant la première photo
Il arrive sur votre page d'accueil. Avant même de voir une photo, un panneau se déploie : le bandeau qui demande son accord pour les cookies, une offre de réduction contre une adresse électronique, une invitation à télécharger une application.
Sur un ordinateur, ce panneau occupe un tiers de l'écran et laisse voir le reste. Sur un téléphone, il occupe tout. Votre voyageur ne voit plus votre établissement : il voit une porte fermée qu'il faut ouvrir avant d'entrer.
Google traite ce sujet dans sa documentation destinée aux propriétaires de sites, et sa recommandation s'applique telle quelle : ne recouvrez pas la page entière, et ne renvoyez pas la personne vers une page séparée pour obtenir son consentement ou une saisie. Google réserve des exceptions aux obligations légales, par exemple une vérification d'âge.
La conséquence pratique : si un panneau doit s'afficher, qu'il occupe une bande, pas la page.
2. Le bouton de réservation est trop bas et trop petit
Un doigt n'est pas un curseur de souris. Il couvre une surface, il masque ce qu'il touche, et il vise mal lorsque l'appareil bouge. Trois références encadrent la question — la norme d'accessibilité internationale, les recommandations d'Apple, celles d'Android — et elles ne fixent pas la même valeur minimale.
Vous n'avez pas à arbitrer entre elles : retenez la plus exigeante, celle d'Android, qui demande quarante-huit unités de référence de côté. L'unité de référence est la mesure avec laquelle le navigateur dimensionne tout ce qu'il affiche, indépendamment de la finesse de l'écran ; c'est le langage dans lequel votre prestataire travaille. Un bouton dimensionné ainsi satisfait les deux autres références.
La norme d'accessibilité prévoit d'ailleurs des exceptions, dont une qui vous concerne directement : les commandes dimensionnées par le navigateur lui-même — le sélecteur de dates du système, notamment — échappent à la règle, sauf si votre site en modifie l'apparence. Un calendrier redessiné sur mesure perd donc l'exemption. Ce qui conduit au point suivant.
3. Le calendrier se manipule au pouce, mois par mois
Votre voyageur veut deux nuits en septembre. Le calendrier s'ouvre sur le mois en cours. Il doit atteindre une petite flèche, la toucher plusieurs fois de suite sans dépasser, puis viser une case de quelques millimètres, deux fois — une pour l'arrivée, une pour le départ.
C'est le geste qui demande le plus de précision de tout le parcours, et il arrive au tout début, alors que le voyageur n'a encore rien investi dans sa démarche. Il renonce d'autant plus facilement qu'il n'a encore rien décidé.
Deux réglages allègent nettement ce moment. Le calendrier s'ouvre sur le premier mois où il reste de la disponibilité, plutôt que sur le mois courant. Et les dates indisponibles restent visibles, grisées, plutôt que d'être supprimées : une case barrée informe, une case absente laisse penser que le site fonctionne mal.
Ces deux points relèvent de la configuration de votre moteur de réservation, pas de votre site.
4. Le prix affiché n'est pas le prix demandé
Il choisit une chambre à un tarif. Trois écrans plus loin, le total a augmenté. Frais de service, taxe de séjour, supplément pour la troisième personne, petit-déjeuner qu'il croyait compris.
Ce qui se joue là n'est pas le montant. C'est le sentiment d'avoir été conduit quelque part — et ce sentiment contamine le reste de la page, y compris votre politique d'annulation, qu'il relira avec méfiance.
Certains pays encadrent ce point. En France, un arrêté du 18 décembre 2015 sur la publicité des prix des hébergements touristiques pose que le prix annoncé s'entend toutes taxes comprises, et que ce qui ne peut pas y être inclus se mentionne juste à côté.
Ce que le pays où vous exercez impose sur ce point relève d'un professionnel du droit et non d'un article de blog. Retenez en revanche le principe, qui n'a rien de juridique : le premier prix qu'il voit doit être celui qu'il paiera, et tout ce qui s'ajoute doit être annoncé au même endroit, à la même taille de caractères.
5. Il doit créer un compte avant de pouvoir réserver
Il a choisi sa chambre. L'écran suivant lui demande une adresse électronique, un mot de passe, la confirmation du mot de passe, et la validation d'un message envoyé dans sa boîte.
Il voulait deux nuits. On lui demande de s'inscrire.
Sur ce point, la documentation publiée par l'équipe de Chrome à l'intention des développeurs est explicite : n'imposez pas la création d'un compte avant le paiement.
Ce réglage se trouve dans l'interface d'administration de votre moteur de réservation, sous une formulation du type « réservation en tant qu'invité » ou « commande sans compte ». Il se change en une minute, sans intervention technique. Vérifiez-le ce soir : il fait partie des quatre corrections qui ne demandent aucune intervention technique.
6. Le clavier qui s'affiche n'est pas le bon, et l'écran zoome de lui-même
Il touche le champ du numéro de téléphone. Le clavier alphabétique apparaît. Il doit basculer vers les chiffres, puis revenir. Il touche le champ du code postal, même manœuvre.
Le navigateur sait pourtant afficher le clavier adapté, à condition qu'on le lui dise. Un attribut prévu par le standard du langage des pages web permet d'annoncer le type de saisie attendue, et le clavier suit. Un second attribut, distinct, autorise le navigateur à proposer ce qu'il a déjà mémorisé : le nom, l'adresse, le numéro. Sur un téléphone, ces deux réglages changent la nature même de la saisie.
S'y ajoute un comportement propre au navigateur de l'iPhone, que vous avez sans doute constaté sans l'expliquer : lorsqu'un champ affiche un texte plus petit qu'une certaine taille, l'écran zoome automatiquement au moment où l'on touche le champ. La page se décale, le bouton sort du cadre, et il faut pincer l'écran pour revenir. Le seuil est documenté de longue date par les développeurs : seize unités de référence. Un champ dont le texte atteint cette taille ne déclenche pas le zoom.
La solution de facilité consiste à interdire purement et simplement l'agrandissement de la page. Ne le faites pas. La norme d'accessibilité exige qu'un texte puisse être agrandi jusqu'au double sans perte de contenu ni de fonction. Vous régleriez un inconfort en créant une exclusion.
7. Le champ de la carte refuse ce que le navigateur lui propose
Le numéro d'une carte s'écrit en quatre groupes de quatre chiffres. Certains formulaires le découpent en quatre cases distinctes, ou refusent les espaces, ou imposent un format de date d'expiration à l'aide d'un sélecteur maison.
Chacun de ces choix empêche la même chose : la capacité du navigateur à remplir le champ tout seul. Les navigateurs conservent les cartes enregistrées et savent les proposer, à condition que les champs soient nommés selon des étiquettes normalisées, documentées et identiques partout.
La documentation de Chrome ajoute une consigne que le formulaire ne trahit pas au premier regard : le bouton doit se désactiver après le premier appui, afin qu'une double pression n'envoie pas deux fois la demande.
Ce point-là se vérifie à part, dans une fenêtre ordinaire : la navigation privée n'a accès à aucune carte enregistrée, et vous montrerait un formulaire muet quel que soit son état. Ouvrez donc votre page de paiement sur votre téléphone, dans votre navigateur habituel, et touchez le champ du numéro de carte. Si rien ne vous est proposé alors qu'une carte est bien enregistrée dans cet appareil, vous venez de constater le défaut.
Le huitième point se joue en dehors de votre site
Il a saisi sa carte. Il touche « Payer ». Et votre site disparaît.
À sa place s'affiche une page aux couleurs de sa banque, qui lui demande un code. Ce code arrive par message, parfois avec du retard. Il quitte la page pour ouvrir ses messages, recopie le code, revient. Si le retour s'effectue mal, il se retrouve sur une page blanche, ou sur votre page d'accueil, sans savoir si sa chambre est réservée et si son compte a été débité.
Ce mécanisme porte un nom dans le métier : l'authentification du porteur de carte. L'organisme qui publie la spécification décrit deux chemins possibles. Sur les transactions jugées peu risquées, rien ne se passe : le paiement est approuvé sans étape supplémentaire. Sur les autres, la banque émettrice peut exiger une vérification — un code à usage unique, une question, une empreinte biométrique.
En Algérie, l'étape existe et elle est décrite publiquement. La société qui opère les transactions interbancaires indique qu'un mot de passe dédié au paiement en ligne, composé de six chiffres, sert à valider les opérations, et qu'après trois saisies erronées ce mot de passe est bloqué pour ce service — les retraits et les paiements en magasin continuant de fonctionner. Votre voyageur peut donc échouer sans que rien ne soit en cause chez vous.
Voilà pourquoi ce point est le plus coûteux des huit. Il survient au moment où tout paraissait acquis, il vous échappe presque entièrement, et il reste invisible depuis un appareil récent bien connecté, sur lequel le retour vers votre site s'effectue proprement.
Trois choses restent pourtant de votre ressort, et elles suffisent souvent.
Annoncez l'étape avant qu'elle n'arrive. Une phrase sous le bouton : votre banque vous demandera un code envoyé par message pour valider le règlement. Une personne prévenue attend. Une personne surprise ferme.
Vérifiez la page de retour. Après le paiement, votre voyageur doit atterrir sur un écran qui nomme votre établissement, ses dates, son numéro de réservation. Pas sur votre page d'accueil.
Envoyez la confirmation immédiatement, et faites en sorte qu'elle contienne l'essentiel dès l'objet du message. C'est ce que votre voyageur regardera dans les secondes qui suivent, avant même de relire votre page.
| # | Où cela se produit | Ce que votre voyageur vit | Se corrige sans toucher au site ? |
|---|---|---|---|
| 1 | À l'arrivée sur la page | Un panneau recouvre l'écran entier avant la première photo | Oui — réglage du bandeau |
| 2 | Page de la chambre | Le bouton de réservation est hors du cadre, ou trop petit pour le pouce | Non |
| 3 | Choix des dates | Le calendrier s'ouvre sur le mauvais mois, les cases se ratent | Oui — réglage du moteur |
| 4 | Récapitulatif | Le total a augmenté depuis l'écran précédent | Oui — affichage et texte |
| 5 | Avant le formulaire | Il faut créer un compte pour aller plus loin | Oui — réglage du moteur |
| 6 | Saisie des coordonnées | Le mauvais clavier apparaît, l'écran zoome et se décale | Non |
| 7 | Saisie de la carte | Le navigateur ne propose pas la carte enregistrée | Non |
| 8 | Validation du paiement | Il quitte le site pour sa banque, attend un code, revient mal | Partiellement — annonce et page de retour |
Le vrai test se fait debout, à une main, sur le téléphone le plus ancien de l'établissement
Ce test demande un quart d'heure et ne coûte rien.
Prenez le téléphone le plus ancien de l'établissement. Celui d'un membre de l'équipe, celui du tiroir de la réception.
Coupez le réseau sans fil. Passez en données mobiles, et si possible depuis un endroit où la réception est médiocre : un couloir, un sous-sol, l'arrière du bâtiment.
Ouvrez une fenêtre de navigation privée — dans Chrome, les trois points en haut à droite, puis « Nouvelle fenêtre de navigation privée ». Vous obtenez une session vierge de tout ce que votre navigateur a mémorisé sur vous : celle d'un voyageur qui arrive chez vous pour la première fois. Elle ne reproduit pas tout — votre voyageur, lui, garde ses coordonnées enregistrées. C'est pour cette raison que le septième point se vérifie à part, dans une fenêtre ordinaire.
Tenez-vous debout, le téléphone dans une seule main, l'autre le long du corps. C'est la posture réelle de votre voyageur, et celle qui révèle les problèmes de visée.
Allez jusqu'au bout du parcours. Une chambre, deux nuits, dans trois mois. Poussez jusqu'au bouton qui déclenche le paiement, sans le toucher.
Comptez trois choses au fil du parcours. Le nombre d'écrans entre le choix de la chambre et l'écran de paiement. Le nombre de champs que vous avez remplis à la main. Le nombre de fois où vous avez dû pincer l'écran pour agrandir, ou reprendre une saisie.
Ces trois nombres sont votre diagnostic. Refaites la mesure après chaque correction : ce sont eux qui doivent baisser.
Une fois par an, allez jusqu'au bout avec votre propre carte, puis annulez la réservation selon votre propre politique. C'est le seul moyen de voir l'écran de retour de votre banque, celui du huitième point.
Trois réflexes aggravent le problème au lieu de le régler
Ils sont tous les trois naturels.
Faire optimiser la vitesse d'affichage sans toucher au parcours. Vous obtiendrez une meilleure note sur un outil de mesure, sans qu'aucun des huit points ci-dessus ait bougé.
Ajouter un bandeau promotionnel au-dessus du bouton. Une offre de dernière minute, un compte à rebours, une réduction pour les réservations directes. L'intention est bonne. Sur un écran de téléphone, ce bandeau peut repousser le bouton de réservation hors du cadre visible, et votre message le plus important masque alors votre action la plus importante.
Exiger la création d'un compte pour offrir un avantage au client direct. L'avantage est réel, l'inscription le rend inaccessible. Accordez la réduction sans compte, et proposez l'inscription après la confirmation, quand la réservation est acquise.
Questions fréquentes
Faut-il refaire tout le site pour corriger ces huit points ?
Non. Quatre d'entre eux se règlent sans intervention technique : le panneau qui recouvre l'écran, dans les paramètres de l'outil qui l'affiche ; le mois d'ouverture du calendrier et le compte obligatoire, dans l'interface d'administration de votre moteur de réservation ; l'affichage du prix complet, qui relève du texte et de la mise en page. Trois autres demandent une intervention technique limitée : la taille du bouton, le comportement des claviers, les champs de la carte. Le huitième ne vous appartient qu'en partie : l'étape bancaire vous échappe, mais l'annonce qui la précède et la page de retour qui la suit vous appartiennent.
Mon moteur de réservation est fourni par un prestataire. Puis-je agir ?
En partie. Les réglages accessibles depuis votre interface d'administration vous appartiennent. Pour le reste — la taille des boutons, le comportement des champs, la page de retour après paiement — vous relevez le problème par écrit, avec une capture d'écran datée prise sur un téléphone, et vous le transmettez. Ce que votre contrat permet d'exiger dépend de ce contrat.
Combien d'écrans un parcours de réservation devrait-il compter ?
Il n'existe pas de nombre juste, et personne ne peut vous en donner un sans mesurer votre parcours. Ce qui est vérifiable, en revanche, c'est le vôtre : comptez-le, notez-le, et vérifiez que chaque écran demande une information que vous utiliserez réellement. Un champ qui n'alimente aucune décision de votre part est un champ à supprimer.
Les plateformes de réservation ont-elles simplement de meilleurs sites ?
Elles ont surtout un avantage que vous n'aurez jamais : le voyageur y est déjà connecté, sa carte y est enregistrée, son adresse aussi. Vous ne pouvez pas concurrencer cela, et il n'est pas nécessaire de le faire. Ce qui se joue est un rapport : l'effort que votre parcours demande, face à l'écart de prix qu'il fait gagner au voyageur. Ce rapport-là, vous pouvez le travailler.
Un test automatisé peut-il détecter ces problèmes ?
Partiellement. Un outil vérifie la taille des zones à toucher, la présence des étiquettes normalisées sur les champs, la configuration de l'agrandissement. Il ne verra ni le prix qui change entre deux écrans, ni le calendrier qui s'ouvre sur le mauvais mois, ni la page blanche au retour de la banque. Ces trois-là demandent un doigt humain.
Le paiement échoue chez certains clients. Est-ce mon site ?
Pas nécessairement. L'étape de validation appartient à la banque du client : code expiré, mot de passe bloqué après plusieurs erreurs, message qui n'arrive pas. Ce que vous pouvez faire, c'est prévenir avant, soigner la page de retour, et laisser un numéro de téléphone visible sur l'écran de paiement pour la personne qui reste bloquée.
Pour aller plus loin
Ouvrir le paiement par carte : ce qui dépend de votre banque, et ce qui n'en dépend pas — le huitième point de décrochage, celui qui ne se corrige pas depuis votre site.
Les trois vérifications qu'un visiteur étranger fait avant de regarder votre offre — écrit pour les agences réceptives, mais ces vérifications précèdent le premier écran du parcours décrit ici.
Ce que la publication d'une annonce rend public, et pour longtemps — rapprochement latéral : pour un logement sans site, le parcours de réservation appartient à la plateforme, avec ses contraintes propres.
Ce soir, quinze minutes
Ne planifiez rien.
Allez chercher le téléphone le plus ancien de l'établissement. Coupez le réseau sans fil. Ouvrez une fenêtre de navigation privée, tapez l'adresse de votre site, et engagez une réservation pour dans trois mois — debout, une seule main.
Arrêtez-vous devant le bouton qui déclenche le paiement.
Notez trois nombres : les écrans traversés, les champs remplis, les fois où vous avez dû agrandir ou recommencer.
Rouvrez ensuite la même page de paiement dans votre navigateur habituel, sans navigation privée, et touchez le champ du numéro de carte : c'est le seul moyen de voir si votre carte enregistrée vous est proposée.
Vous saurez alors, en un quart d'heure, ce que la plupart des établissements n'apprennent jamais : lesquels des sept premiers points vous coûtent des réservations, et lesquels ne vous coûtent rien. Le huitième attend l'essai annuel, votre carte en main.
INSEN STUDIO
On regarde votre situation ensemble ?
Vous repartez avec une lecture claire, avec ou sans nous.
Demander un audit digitalSources
Les règles et recommandations décrites ici sont publiées par leurs auteurs respectifs. Elles ont été reformulées, non recopiées, et ces documents évoluent : ce qui suit vaut à la date de consultation et se revérifie à la source.
W3C, *Understanding WCAG 2.2*, critère 2.5.8 « Target Size (Minimum) », niveau AA, w3.org/WAI/WCAG22/Understanding/target-size-minimum.html, consulté le 10 août 2026.
W3C, *Understanding WCAG 2.2*, critère 1.4.4 « Resize Text », niveau AA, w3.org/WAI/WCAG22/Understanding/resize-text.html, consulté le 10 août 2026.
Apple, *UI Design Dos and Don'ts*, developer.apple.com/design/tips, consulté le 10 août 2026.
Android Developers, *Make apps more accessible*, developer.android.com/guide/topics/ui/accessibility/apps, consulté le 10 août 2026.
Google Search Central, *Interstitials and dialogs*, developers.google.com/search/docs/appearance/avoid-intrusive-interstitials, consulté le 10 août 2026.
Chrome for Developers, *Payment and address form best practices*, web.dev/articles/payment-and-address-form-best-practices, consulté le 10 août 2026.
MDN Web Docs, attribut HTML autocomplete et ses valeurs normalisées, developer.mozilla.org, consulté le 10 août 2026.
MDN Web Docs, attribut global inputmode, developer.mozilla.org, consulté le 10 août 2026.
CSS-Tricks, *16px or Larger Text Prevents iOS Form Zoom*, css-tricks.com, consulté le 10 août 2026.
EMVCo, *EMV 3-D Secure*, description des flux sans friction et avec vérification, emvco.com, consulté le 10 août 2026.
SATIM, *Foire aux questions*, mot de passe de paiement en ligne à six chiffres et blocage après trois saisies erronées, satim.dz, consulté le 10 août 2026.
Légifrance, arrêté du 18 décembre 2015 relatif à la publicité des prix des hébergements touristiques marchands autres que les meublés de tourisme et les établissements hôteliers de plein air, legifrance.gouv.fr, consulté le 10 août 2026.
