Optimiser un site mobile pour les entreprises dont les clients viennent du téléphone

Un tuyau a éclaté, le client est dans la cave et cherche une entreprise d’une main, tandis que l’autre tient un seau. Il tape une recherche, ouvre le premier résultat utilisable et veut savoir une chose : quelqu’un vient-il, et comment le joindre ? Il ne lit pas l’histoire de l’entreprise et ne fait pas défiler trois écrans. Il cherche le bouton d’appel.

Cette image est le point de départ de cette étude, et c’est un scénario, non le compte rendu d’un projet précis. Elle représente les entreprises dont les demandes viennent majoritairement du smartphone : dépannage d’urgence, réparation, demandes de rendez-vous pendant la pause de midi, demandes depuis le chantier du client. Pour elles, le téléphone n’est pas le petit frère de l’ordinateur, mais le cas normal.

Beaucoup de sites ont pourtant été conçus sur grand écran. Les maquettes ont été validées sur moniteur, et sur le téléphone on a « vérifié rapidement que ça passe ». Le résultat passe au sens où « rien ne déborde », mais il n’est pas conçu pour la situation dans laquelle il sert.

Celui qui conseille ce type d’entreprises entend la même phrase sous diverses formes : sur mon ordinateur, tout est très bien. C’est vrai, et c’est le cœur du problème. Lors de la vérification, le dirigeant est assis au bureau, avec un bon réseau et deux mains. Ses clients, rarement. Le changement de perspective est la première tâche, avant même de concevoir quoi que ce soit.

Les défauts sont rarement spectaculaires, ils sont quotidiens. Le numéro de téléphone figure sous forme de texte dans l’en-tête et ne peut pas être touché. La navigation comporte des boutons que l’on ne touche qu’au deuxième essai. Le formulaire de contact exige douze champs, dont deux que personne n’aime remplir sur mobile. Lorsqu’on touche un champ, le clavier à l’écran repousse le bouton d’envoi hors de la vue.

À cela s'ajoute la technique en arrière-plan. Une image d'en-tête de plusieurs mégaoctets, trois graisses de police, une vidéo intégrée et un widget de chat se chargent même quand la réception est faible. Celui qui cherche dans une cage d'escalier ou à la campagne attend. Le réseau mobile n'est pas une valeur constante : il varie selon le lieu et la charge.

Le piège : l'entreprise ne voit pas la perte. Un visiteur qui abandonne ne laisse aucun message. Les demandes qui arrivent viennent de ceux qui ont tenu bon, ce qui donne à tort l'impression que tout va bien. Savoir si l'on perd des visiteurs, et combien, ne se lit que dans le comportement, pas dans la boîte de réception.

Avant de concevoir quoi que ce soit, nous clarifions trois points. Premièrement : quelles situations amènent les visiteurs sur le site ? Un dépannage urgent, une demande de rendez-vous, une comparaison de prix et une recherche le soir appellent des parcours différents. Deuxièmement : quel moyen de contact l'entreprise privilégie-t-elle réellement ? Un bouton d'appel n'aide que si quelqu'un décroche. Troisièmement : que montrent les mesures, par exemple dans la Search Console et l'analyse web, sur la part des accès mobiles ?

La zone du pouce est une règle empirique d'ergonomie. En utilisation à une main, le pouce atteint aisément le bas et le milieu de l'écran, mais à peine le coin supérieur opposé à la main qui tient l'appareil. Ce n'est pas une loi de la nature, car les gens tiennent leur téléphone de façons différentes et les appareils grandissent. Elle reste néanmoins un bon principe de conception : les actions importantes et fréquentes vont en bas, les rares en haut.

Il en découle un ordre des informations. Sur mobile, ce qui décide le visiteur de rester ou de partir doit se trouver sans défilement : qui vous êtes, où vous intervenez, quand on peut vous joindre, comment vous rejoindre. Le reste suit plus bas, dans l'ordre où les doutes apparaissent. Un visiteur qui n'appelle pas veut généralement d'abord obtenir la réponse à une question.

Une idée simple aide ici : chaque page a une tâche principale. La page d'accueil d'un service de dépannage doit inspirer confiance et mener à l'appel ; la page de prestation pour un entretien doit répondre aux questions et permettre de prendre rendez-vous. Quand une page tente les deux à la fois, elle perd sur le petit écran, où il n'y a tout simplement pas de place pour les chemins annexes. Nous définissons la tâche principale avant la première maquette.

La solution courante s'appelle le design adaptatif (responsive) : une grille qui rétrécit, des colonnes qui s'empilent. C'est nécessaire, mais insuffisant. Qui se contente d'empiler conserve les priorités du bureau, simplement les unes sous les autres. D'un large en-tête avec logo, menu et numéro de téléphone naît un bloc haut qui remplit le premier écran et repousse l'essentiel vers le bas.

Le mobile-first inverse le sens du travail. La version mobile est conçue d'abord, avec ce qui y compte, puis nous l'étendons aux écrans plus grands. Cela oblige à décider : qu'est-ce qui est vraiment important, qu'est-ce qui peut disparaître, qu'est-ce qui va à la fin ? Le bureau en profite aussi, car ce n'est pas un original surchargé dont on retire péniblement des éléments.

Une alternative consisterait en des pages mobiles distinctes ou une application séparée. Nous écartons les deux pour les petites entreprises. Deux versions doublent la maintenance, et une application exigerait une installation là où quelqu'un, dans l'urgence, se contente de taper. La troisième option, une Progressive Web App, vaut pour les visiteurs récurrents, rarement pour des demandes ponctuelles. Pour notre cas de figure, un site léger et rapide reste la voie la plus adaptée.

Un mot sur les plugins mobiles automatiques qui « rendent une page compatible mobile ». Ils traitent les symptômes, par exemple par des scripts supplémentaires, et laissent les priorités intactes. Ils constituent parfois une solution transitoire, mais ils ne remplacent pas la question de ce qui doit figurer en premier sur le petit écran. Lorsqu'un constructeur de site ou un CMS impose des modèles, nous vérifions dans quelle mesure ils sont adaptables avant de nous engager sur quoi que ce soit.

Le nombre de ressources plaide aussi pour les garder réduites. Moins il y a de scripts et de widgets, moins il y a de risques de blocage sur un appareil d'entrée de gamme. Nous remplaçons donc dès que possible des fonctions par des éléments standard du navigateur : des liens plutôt que des scripts, des champs de formulaire plutôt que des développements sur mesure.

Le cœur de la conception est un moyen de contact qui fonctionne sans réfléchir. Le numéro de téléphone devient un lien qui, d'une pression, ouvre le composeur. À côté peut figurer un bouton WhatsApp, si l'entreprise y répond réellement aux messages. Qui le propose doit aussi l'assurer, sinon il suscite une attente que personne ne satisfait. Cela suppose d'indiquer clairement les horaires.

La taille des zones tactiles est un levier souvent sous-estimé. À titre indicatif, on retient environ 44 par 44 pixels ; les directives de conception d'Apple indiquent 44 points, le Material Design de Google 48. Les règles d'accessibilité WCAG 2.2 exigent au niveau AA au moins 24 pixels, avec un espacement par rapport aux éléments voisins. Nous prévoyons les valeurs les plus grandes, car les pouces sont plus épais que les pointeurs de souris et les visiteurs en déplacement tapent souvent d'une main.

La barre de contact fixe (sticky) en bas de l'écran garde l'appel toujours accessible. Elle a ses pièges, que nous écartons d'avance : elle ne doit couvrir ni le contenu ni le pied de page, c'est pourquoi la page reçoit une marge intérieure en bas. Elle doit passer devant le clavier à l'écran ou se masquer lorsqu'un champ de formulaire est actif. Et elle ne doit pas être plus haute que nécessaire, car sinon il ne reste guère de surface de lecture sur les petits appareils.

Pour le formulaire, chaque champ a un coût. Pour une demande de rendez-vous, le nom, le numéro de téléphone ou l'adresse e-mail, une brève description et le consentement au traitement des données suffisent souvent. Tout le reste peut être précisé lors du rappel. Lorsque des informations complémentaires sont utiles, comme le code postal pour la zone d'intervention, elles figurent en champs facultatifs, non obligatoires.

Techniquement, beaucoup de choses sont plus simples qu'il n'y paraît si l'on utilise des éléments standard. Un appel est un lien avec tel: et le numéro au format international. Un message WhatsApp passe par un lien wa.me avec un texte suggéré facultatif. Les deux fonctionnent sans script, sans plugin et sans temps de chargement. Sur ordinateur, où l'on n'a pas de téléphone sous la main, le même lien peut apparaître comme un numéro en texte avec une aide à la copie.

Dans le formulaire, quelques attributs règlent le confort. Le type de champ tel ouvre le pavé numérique, email le clavier avec l'arobase, et autocomplete permet à l'appareil de proposer nom et adresse. La taille de police dans les champs de saisie devrait être d'au moins 16 pixels, sinon Safari sur iPhone zoome au toucher et détruit la mise en page. Les messages d'erreur s'affichent au niveau du champ, et non regroupés en haut, hors de vue.

Pour la barre fixe, nous utilisons position: fixed sur le bord inférieur, la marge de sécurité env(safe-area-inset-bottom) pour les appareils dotés d'une barre de gestes et un padding-bottom correspondant en fin de page. Nous indiquons les hauteurs en dvh plutôt qu'en vh, car sur les navigateurs mobiles la barre d'adresse apparaît et disparaît, et vh repousse alors le contenu derrière la barre. Les sauts vers des ancres reçoivent scroll-margin pour que les titres ne se retrouvent pas sous la barre.

Pour le temps de chargement, nous visons les seuils des Core Web Vitals : LCP jusqu'à 2,5 secondes, INP jusqu'à 200 millisecondes, CLS jusqu'à 0,1. Nous chargeons tôt l'élément visible le plus grand, en général l'image principale, dans une taille appropriée, avec srcset pour différentes largeurs et des formats modernes comme WebP ou AVIF. Les images situées sous le premier écran se chargent en différé, l'image principale non. Nous limitons les polices à l'essentiel et les hébergeons nous-mêmes.

Les cas particuliers n'apparaissent que sur de vrais appareils. Le plus fréquent : le formulaire est impeccable sur ordinateur, mais sur mobile le clavier repousse le bouton d'envoi hors de l'écran, et le visiteur le cherche jusqu'à renoncer. La parade est une mise en page qui, lorsqu'un champ prend le focus, fait défiler ce champ dans la zone visible, et une barre fixe qui se masque pendant la saisie.

Deuxièmement, la réception faible. Si la connexion tombe à l'envoi, le texte que quelqu'un vient de saisir péniblement est perdu. Nous conservons donc les saisies dans le formulaire jusqu'à ce que l'envoi soit confirmé, et signalons clairement l'échec éventuel. La mention « Vous pouvez aussi nous appeler directement » doit figurer à côté du message d'erreur, pas dans le pied de page.

Troisièmement, les bandeaux de cookies et les pop-ups. Un bandeau qui couvre la moitié de l'écran recouvre aussi le bouton d'appel. Nous concevons la demande de consentement de façon sobre et la faisons apparaître de sorte que les moyens de contact restent accessibles, dans la mesure où la solution retenue le permet. L'évaluation juridique relève de l'examen de protection des données, mais une mention de cette tension a sa place dans la conception.

Quatrièmement, l'articulation avec la recherche locale. Celui qui arrive sur le site depuis la fiche d'établissement Google a souvent déjà vu les horaires et le numéro. La page doit présenter ces informations de manière cohérente et ne pas allonger le chemin vers l'itinéraire ou l'appel. Des horaires contradictoires entre la fiche et le site font perdre en confiance et provoquent des appels à des moments inopportuns.

Enfin, la diversité des appareils. Un ancien appareil Android à faible mémoire, un iPhone avec une grande taille de texte dans les réglages système, un appareil en mode sombre : chacun peut solliciter la mise en page différemment. Nous testons donc avec une police système agrandie et une connexion bridée, pas seulement avec l'appareil le plus récent en Wi-Fi.

Une meilleure expérience mobile ne se chiffre pas de façon générale, et nous n'annonçons donc aucun pourcentage. Il est réaliste d'attendre que moins de visiteurs butent sur des obstacles : plus de pressions sur le bouton d'appel, plus de formulaires envoyés, moins d'abandons dans les champs de saisie. L'ampleur de l'effet dépend de la situation de départ, de l'offre et de la demande.

La mesure se fait par événements. Un clic sur le lien tel:, sur le bouton WhatsApp et sur l'envoi du formulaire sont enregistrés comme objectifs, séparés par type d'appareil. Si vous utilisez une analyse web, vous devriez d'abord vérifier si un consentement est nécessaire et étudier des solutions économes en données. En complément, le rapport sur l'expérience utilisateur de la Search Console indique si les pages atteignent les seuils des Core Web Vitals.

Un clic d'appel n'est pas un appel. Qui appuie sur le bouton puis raccroche l'a pressé, mais n'a rien provoqué. C'est pourquoi un recoupement avec l'entreprise est utile : combien d'appels aboutissent réellement, combien sont manqués, et à quelles heures ? Parfois, le plus grand levier ne se trouve pas sur le site, mais dans le fait que personne ne décroche le soir.

Prévoyez plusieurs semaines pour l'évaluation et, pour les métiers saisonniers, également une comparaison avec l'année précédente. Les journées isolées en disent peu, car la météo, les vacances et les promotions déplacent le volume. Ce que l'on ne peut pas promettre : un nombre précis de demandes ou une meilleure position dans la recherche. L'amélioration de l'utilisabilité crée des conditions favorables, mais ne pilote pas la demande elle-même.

Premièrement : testez sur de vrais appareils, pas seulement dans l'émulateur du navigateur. L'affichage appareil des outils de développement montre des tailles, mais ni la sensation des zones tactiles, ni le comportement du clavier, ni la barre de gestes. Deux à trois appareils réels d'âge et de système d'exploitation différents révèlent la majeure partie des erreurs. Cela inclut un test en déplacement, en données mobiles plutôt qu'en Wi-Fi.

Deuxièmement : bridez la connexion lors des tests. Lighthouse et PageSpeed Insights simulent un réseau mobile lent et un appareil moins puissant. Les valeurs de laboratoire ne sont qu'un repère ; les données de terrain du rapport de la Search Console montrent la réalité. Si les deux divergent fortement, il vaut la peine d'examiner les scripts tiers qui ne se chargent pas en laboratoire mais font perdre du temps aux visiteurs réels.

Troisièmement : moins d'éléments, mais plus grands. Un menu de quatre entrées claires vaut mieux qu'un menu de neuf. Un bouton libellé « Appeler maintenant » vaut mieux qu'une icône sans texte. Les contrastes doivent rester lisibles en plein soleil, car un téléphone en extérieur est souvent utilisé dans de mauvaises conditions. Ces décisions coûtent peu, mais il faut les prendre.

Quatrièmement : entretenez le site en pensant au mobile. Les nouvelles images qu'un collaborateur téléverse devraient être automatiquement ramenées à une taille adaptée, sinon le temps de chargement augmente à chaque mise à jour. Cela relève du processus éditorial, pas seulement de la création. Une simple liste de contrôle après chaque modification importante suffit.

Si vos clients viennent du mobile, le site mobile est votre vitrine, et non un complément. Cela ne signifie pas qu'il doive être sophistiqué. Un premier écran clair, un bouton d'appel à portée de pouce, des zones tactiles suffisamment grandes, un formulaire court et une livraison légère font plus qu'une profusion d'animations et de widgets qui plombent l'appareil.

Les améliorations sont mesurables, mais pas garanties. Elles lèvent des obstacles sur le chemin de la demande, elles ne créent pas de demande. Qui le sait peut planifier avec lucidité : d'abord les moyens de contact, puis la vitesse, puis la finition. Et qui garde l'entreprise en vue comprend que même la meilleure page ne sert à rien si personne ne répond au téléphone.

Pour situer l'effort : sur un petit site de quelques pages, une refonte selon ce schéma est réalisable dans un délai raisonnable, car il s'agit de priorités et de moyens de contact, pas de nouveaux contenus. Cela devient plus conséquent avec de nombreux modèles, un logiciel spécifique ou des connexions à des systèmes de rendez-vous. Nous indiquons le cadre après un premier examen, pas avant.

La prochaine étape est modeste. Prenez votre téléphone, rendez-vous dans une pièce où la réception est faible et essayez de contacter votre propre entreprise. Comptez combien de pressions et de secondes il faut avant que le téléphone sonne. Si c'est laborieux, un coup d'œil au site s'impose. Nous l'examinons volontiers avec vous et vous disons honnêtement ce qui vaut la peine.