Site mobile pour TPE : 8 vérifications avant de perdre une demande
Menu, boutons, formulaire et pièces jointes : huit tests sur téléphone pour vérifier qu'un visiteur peut vous contacter et que sa demande arrive bien.
Sur cette page8 sections
Pour savoir si votre site fonctionne sur téléphone, ouvrir la page d'accueil ne suffit pas. Essayez plutôt de demander un devis avec une photo, d'appeler depuis une page de service ou de retrouver une information en revenant du formulaire. C'est là qu'on découvre parfois qu'un site très propre en capture d'écran demande beaucoup de patience à celui qui veut s'en servir.
On parle souvent de « responsive », c'est-à-dire d'une mise en page qui s'adapte à l'écran. C'est nécessaire, mais ce n'est pas la fin du travail. Un bouton peut tenir parfaitement dans la largeur du téléphone et ne rien faire d'utile quand on appuie dessus.
Voici les huit vérifications que je ferais avant de considérer le parcours mobile comme prêt.
Augmentez aussi la taille du texte et utilisez le zoom. Une personne ne devrait pas perdre le bouton de contact parce qu'elle a besoin de lire plus grand. Les longues adresses, les tableaux et les images doivent rester dans l'écran sans imposer de déplacer toute la page de gauche à droite.
Il ne s'agit pas d'enlever votre identité visuelle. Il s'agit de ne pas demander au visiteur un effort de lecture avant même qu'il ait compris ce que vous proposez.
Un menu qui s'ouvre correctement peut encore gêner le parcours si on ne sait pas où on se trouve ou comment reprendre la lecture. Gardez des intitulés qui parlent au client. Si la personne cherche vos services, elle ne devrait pas avoir à comprendre votre vocabulaire interne pour les trouver.
La zone cliquable peut être plus grande que l'icône visible. C'est utile quand on veut conserver une interface sobre sans exiger une précision chirurgicale. Le W3C traite précisément la taille et l'espacement des cibles ; en pratique, le test doit surtout confirmer qu'un appui ne déclenche pas le lien voisin.
Regardez aussi les barres fixes et les widgets. Un bouton de messagerie ne doit pas recouvrir le bouton d'envoi, et une bannière ne devrait pas occuper l'essentiel du premier écran.
Un numéro écrit dans une image ou dans une phrase peut être visible sans être cliquable. Et une adresse ancienne peut survivre dans le pied de page alors que la page contact a été corrigée. Ce contrôle prend peu de temps, mais il vérifie le résultat, pas seulement l'apparence.
Si vous proposez plusieurs moyens de contact, donnez-leur des intitulés explicites. On doit savoir si l'on va appeler, envoyer un message ou demander un devis avant de toucher le bouton.
Une bordure rouge ne suffit pas à expliquer une erreur. « Adresse e-mail incomplète » aide davantage que « saisie invalide ». Le W3C recommande des notifications compréhensibles pour les erreurs comme pour la réussite, afin que l'utilisateur sache où il en est.
Refaites ensuite un envoi complet et vérifiez la réception. Une confirmation à l'écran ne prouve pas, à elle seule, que le message est arrivé dans la bonne boîte. Contrôlez également que vous pouvez répondre à l'adresse du demandeur.
Les formats et les tailles ne seront pas forcément ceux de votre ordinateur. Un refus doit indiquer ce qui est accepté et ce que la personne peut faire, sans effacer tout le formulaire. Pendant le transfert, il faut comprendre si le fichier est encore en cours d'envoi ou s'il a bien été ajouté.
Vérifiez ensuite que la pièce jointe est reçue et accessible. Afficher un nom de fichier dans le formulaire n'est que le début du trajet. Le contrôle utile suit ce fichier jusqu'à l'endroit où vous allez travailler avec.
Regardez ce qui devient utilisable en premier. Peut-on lire la prestation et ouvrir le menu pendant que le reste arrive ? Une animation retarde-t-elle une action ? Une grande photo déplace-t-elle le bouton de contact au chargement ?
Les Core Web Vitals donnent des mesures pour comprendre ces problèmes. Mais avant le score, il y a une question simple : au moment où la personne décide de vous contacter, le site la laisse-t-il faire ?
Essayez un autre téléphone, une autre taille de texte et, si possible, un autre navigateur. On ne cherche pas une copie identique de l'écran du concepteur. On cherche un parcours qui garde son sens avec moins de place et d'autres conditions d'utilisation.
Notez l'endroit, l'action et le résultat : « sur cette prestation, le bouton est caché par le widget » sera beaucoup plus utile que « le mobile est bizarre ». Cela permet de corriger un composant et de refaire le même test, au lieu de discuter d'une impression générale.
Une autre personne et un autre écran permettent de repérer des hésitations que le concepteur ne remarque plus.
Quelques défauts localisés ne justifient pas nécessairement une refonte. On peut souvent commencer par le lien cassé, la mauvaise taille d'image ou le message de formulaire incompréhensible. Si les difficultés se répètent sur tout le parcours, on étudie alors la structure et les priorités du site.
Dans un projet de création de site web, je veux pouvoir suivre une demande du premier écran jusqu'à sa réception. La maquette permet de discuter du design. Ce trajet permet de vérifier que le site fait réellement son travail.
On parle souvent de « responsive », c'est-à-dire d'une mise en page qui s'adapte à l'écran. C'est nécessaire, mais ce n'est pas la fin du travail. Un bouton peut tenir parfaitement dans la largeur du téléphone et ne rien faire d'utile quand on appuie dessus.
Voici les huit vérifications que je ferais avant de considérer le parcours mobile comme prêt.
1 Lire sans chercher le bon angle
Sur un ordinateur, au calme, un texte gris sur une photo peut sembler élégant. Dehors, sur un écran moins lumineux, il peut devenir presque invisible. Testez les informations importantes, les textes des boutons et les indications du formulaire, pas seulement le gros titre.Augmentez aussi la taille du texte et utilisez le zoom. Une personne ne devrait pas perdre le bouton de contact parce qu'elle a besoin de lire plus grand. Les longues adresses, les tableaux et les images doivent rester dans l'écran sans imposer de déplacer toute la page de gauche à droite.
Il ne s'agit pas d'enlever votre identité visuelle. Il s'agit de ne pas demander au visiteur un effort de lecture avant même qu'il ait compris ce que vous proposez.
2 Trouver le menu puis pouvoir en sortir
Ouvrez le menu, choisissez une prestation et revenez en arrière. Essayez aussi de le fermer. Le bouton de fermeture reste-t-il visible ? La page retrouve-t-elle son défilement normal ? Le menu cache-t-il une information dont vous avez besoin ?Un menu qui s'ouvre correctement peut encore gêner le parcours si on ne sait pas où on se trouve ou comment reprendre la lecture. Gardez des intitulés qui parlent au client. Si la personne cherche vos services, elle ne devrait pas avoir à comprendre votre vocabulaire interne pour les trouver.
3 Appuyer avec un pouce, pas un pointeur
Deux petits liens côte à côte peuvent être faciles à sélectionner à la souris et agaçants sur un téléphone. Essayez les actions avec votre pouce, notamment celles des cartes, du pied de page et des formulaires.La zone cliquable peut être plus grande que l'icône visible. C'est utile quand on veut conserver une interface sobre sans exiger une précision chirurgicale. Le W3C traite précisément la taille et l'espacement des cibles ; en pratique, le test doit surtout confirmer qu'un appui ne déclenche pas le lien voisin.
Regardez aussi les barres fixes et les widgets. Un bouton de messagerie ne doit pas recouvrir le bouton d'envoi, et une bannière ne devrait pas occuper l'essentiel du premier écran.
4 Appeler le numéro qui est affiché
Appuyez réellement sur le téléphone. Le bon numéro est-il proposé ? Le lien de l'adresse e-mail lance-t-il une action adaptée à l'appareil ? Le contact depuis une prestation est-il aussi accessible que celui de la page d'accueil ?Un numéro écrit dans une image ou dans une phrase peut être visible sans être cliquable. Et une adresse ancienne peut survivre dans le pied de page alors que la page contact a été corrigée. Ce contrôle prend peu de temps, mais il vérifie le résultat, pas seulement l'apparence.
Si vous proposez plusieurs moyens de contact, donnez-leur des intitulés explicites. On doit savoir si l'on va appeler, envoyer un message ou demander un devis avant de toucher le bouton.
5 Envoyer un formulaire avec une petite erreur
Remplissez la demande comme un prospect, puis oubliez volontairement un champ obligatoire. Le site explique-t-il quoi corriger ? Conserve-t-il ce que vous avez déjà saisi ? Le clavier cache-t-il le champ ou le bouton dont vous avez besoin ?Une bordure rouge ne suffit pas à expliquer une erreur. « Adresse e-mail incomplète » aide davantage que « saisie invalide ». Le W3C recommande des notifications compréhensibles pour les erreurs comme pour la réussite, afin que l'utilisateur sache où il en est.
Refaites ensuite un envoi complet et vérifiez la réception. Une confirmation à l'écran ne prouve pas, à elle seule, que le message est arrivé dans la bonne boîte. Contrôlez également que vous pouvez répondre à l'adresse du demandeur.
6 Joindre une photo prise depuis le téléphone
Un artisan peut avoir besoin de voir une installation. Un client peut vouloir envoyer un plan. Si votre formulaire propose une pièce jointe, essayez une vraie photo issue du téléphone et un document depuis son espace de stockage.Les formats et les tailles ne seront pas forcément ceux de votre ordinateur. Un refus doit indiquer ce qui est accepté et ce que la personne peut faire, sans effacer tout le formulaire. Pendant le transfert, il faut comprendre si le fichier est encore en cours d'envoi ou s'il a bien été ajouté.
Vérifiez ensuite que la pièce jointe est reçue et accessible. Afficher un nom de fichier dans le formulaire n'est que le début du trajet. Le contrôle utile suit ce fichier jusqu'à l'endroit où vous allez travailler avec.
7 Attendre avec une connexion moins confortable
Recommencez la visite sans les fichiers déjà chargés, par exemple en navigation privée, et avec une connexion mobile ordinaire. Ce test ne garantit pas de reproduire toutes les situations, mais il change déjà le regard par rapport au Wi-Fi du bureau.Regardez ce qui devient utilisable en premier. Peut-on lire la prestation et ouvrir le menu pendant que le reste arrive ? Une animation retarde-t-elle une action ? Une grande photo déplace-t-elle le bouton de contact au chargement ?
Les Core Web Vitals donnent des mesures pour comprendre ces problèmes. Mais avant le score, il y a une question simple : au moment où la personne décide de vous contacter, le site la laisse-t-il faire ?
8 Faire essayer quelqu'un qui ne connaît pas le site
Demandez à une personne de trouver une prestation et de vous envoyer une demande. Ne lui expliquez pas le menu avant le test et ne corrigez pas son chemin en cours de route. Si elle hésite, c'est précisément l'information que vous cherchez.Essayez un autre téléphone, une autre taille de texte et, si possible, un autre navigateur. On ne cherche pas une copie identique de l'écran du concepteur. On cherche un parcours qui garde son sens avec moins de place et d'autres conditions d'utilisation.
Notez l'endroit, l'action et le résultat : « sur cette prestation, le bouton est caché par le widget » sera beaucoup plus utile que « le mobile est bizarre ». Cela permet de corriger un composant et de refaire le même test, au lieu de discuter d'une impression générale.
Une autre personne et un autre écran permettent de repérer des hésitations que le concepteur ne remarque plus.
Quelques défauts localisés ne justifient pas nécessairement une refonte. On peut souvent commencer par le lien cassé, la mauvaise taille d'image ou le message de formulaire incompréhensible. Si les difficultés se répètent sur tout le parcours, on étudie alors la structure et les priorités du site.
Dans un projet de création de site web, je veux pouvoir suivre une demande du premier écran jusqu'à sa réception. La maquette permet de discuter du design. Ce trajet permet de vérifier que le site fait réellement son travail.
