L’homme qui hululait à l’oreille des formulaires

Contrôler la validité des champs avec trop d’enthousiasme

Votre adresse e‑mail est invalide ; veuillez en saisir une autre.

Il y a quelques années, j’ai décidé d’ouvrir un compte dans une banque en ligne. Après avoir hésité entre les deux principaux concurrents, j’ai fait mon choix et démarré le processus d’inscription.

Quelle ne fut pas ma consternation lorsque ma tentative d’inscription fut abruptement stoppée dès la première étape par le message suivant : « L’adresse e‑mail saisie est invalide ».

Étrange ! J’étais pourtant bien placé pour savoir que c’était faux puisque c’était… eh bien… mon adresse. Toujours est-il que j’ai fini par m’inscrire chez le concurrent.

N’est-il pas dommage de dépenser des millions en campagnes marketing pour refuser l’inscription à vos nouveaux clients pour un excès de zèle technique ?

Le format d’une adresse e‑mail pouvant être fort complexe (en), mieux vaut éviter de sortir des expressions régulières de son chapeau. La seule et unique manière de vérifier la validité et l’existence d’une adresse, c’est d’y envoyer un e‑mail.

Le problème n’existe pas que pour les champs de type « e‑mail ». Nous avons souvent beaucoup de préconceptions sur les formes possibles que peuvent revêtir certains types de valeurs.

Pour s’en convaincre, on pourra par exemple consulter ce fascinant article du W3C sur les noms de personnes à travers le monde et les cultures.

Imaginons la frustration de l’internaute qui se voit rétorquer que son « nom est trop court » ou qu’il « contient des caractères invalides », ou a qui on demande de fournir son nom de famille alors qu’il n’en a pas, ou qu’il en a deux, etc.

Quand on est dev un peu tatillon, on a tendance à vouloir faire un peu trop bien les choses en ajoutant des barrières sur les différents champs « au cas où » (mon moi du passé plaide coupable) ; ayons l’humilité d’accepter qu’il est impossible de considérer toutes les situations potentiellement légitimes.

Donc, pour éviter de frustrer des gens : abstenons-nous d’inventer des règles de validation fantaisistes.

Imposer des contraintes fantaisistes sur les mots de passe

Votre mot de passe doit contenir deux chiffres, trois signes de
ponctuations, un hiéroglyphe et la recette complète de la vraie pâte à crêpes bretonne.

Le principal critère permettant de déterminer le niveau de protection d’un mot de passe n’est pas sa complexité mais sa longueur.

Pour le dire autrement : un mot de passe difficile à mémoriser n’est pas nécessairement un mot de passe difficile à casser par une entité mal intentionnée disposant des outils adéquats.

Par conséquent, il est plus pertinent d’imposer une taille de mot de passe minimale plutôt qu’une politique complexe à base de types de caractères différents, qui rendraient le mot de passe difficile à retenir pour l’utilisateur et paradoxalement augmenteraient les chances qu’il se retrouve affiché sur un Post-it collé au moniteur.

On imagine aussi très bien qu’il est parfaitement déraisonnable d’imposer une taille maximale aux mots de passe saisis et de telles contraintes ne peuvent provenir que d’esprits tordus, dérangés ou appartenant à des stagiaires laissés sans surveillance un lendemain de soirée d’intégration du comité d’entreprise.

Si le besoin de sécurité est important (e.g compte d’entreprise, service bancaire, paiement en ligne, etc.), il est souvent plus pertinent de mettre en place des mécanismes de protection supplémentaires : double authentification, blocage des comptes, etc.

À la saisie du mot de passe, il est bien évidemment important d’afficher directement toutes les contraintes imposées, plutôt que d’attendre la saisie pour renvoyer un message d’erreur.

Enfin, peut-être est-il pertinent de tout simplement se passer de mots de passe ?

Voici le résultat d’une même expérience menée sur deux sites réalisés ces derniers mois :

Sur Aides-territoires et Mamie Note, deux projets sur lesquels je suis intervenu en parallèle, le processus de connexion suivant a été mis en place :

1. pour créer un compte, un utilisateur n’a besoin que de saisir son adresse e‑mail ;
2. il reçoit alors le traditionnel e‑mail de confirmation, contenant un lien de validation ;
3. au clic sur le lien, l’utilisateur est connecté et il peut éventuellement saisir un mot de passe dans son profil ;
4. sinon, le formulaire de récupération de mot de passe peut servir de mécanisme de « connexion sans mot de passe ».

Ce mécanisme fluidifie l’inscription. En revanche, sur Aides-territoires, nous avons reçu beaucoup de message d’utilisateurs perdus qui n’arrivaient pas à se connecter. Moralité : en fonction de la cible, respecter les habitudes est parfois plus important que proposer une simplification.

Imposons une longueur minimale aux mots de passe, mais n’obligeons pas nos utilisateur·ices à choisir des mots de passe difficile à retenir.

Confondre les attributs labels et placeholder

En HTML, il existe deux principaux attributs permettant de décrire l’usage d’un champ : les labels et les placeholders. Chaque champ de formulaire doit être associé à une étiquette (RGAA 4, Critère 11.1)

Labels et placeholders remplissent deux rôles différents et ne sont pas interchangeables.

<label for="field_name">
    Votre nom complet :
    <small>C'est ainsi que nous nous adresserons à vous</small>
</label>
<input type="text" id="field_name" name="name" placeholder="Georges Brassens" />

Le label sert à indiquer le nom du champ en ajoutant éventuellement une description plus détaillée ; le placeholder sert à suggérer des exemples de saisie et préciser le format attendu.

Malheureusement, sûrement dans l’optique d’épurer au maximum leurs mises en page, on trouve encore des designers qui semblent utiliser le placeholder en guise de label.

<input type="text" id="field_name" name="name" placeholder="Votre nom complet" />

C’est évidemment une mauvaise idée pour de nombreuses raisons qui ont déjà été détaillées ailleurs (je vous laisse travailler un peu, vous trouverez facilement).

En résumé, l’information donnée par l’attribut placeholder n’est pas toujours accessible. Soit parce que le champ a reçu focus ; ou parce qu’il s’agit d’un formulaire avec des valeurs préremplies ; ou parce que l’attribut n’est pas pris en charge par le type de navigateur utilisé ; ou parce que le style par défaut du navigateur ne propose pas un contraste suffisant ; etc.

La pratique consistant à omettre les labels est donc source de problèmes d’ergonomie et d’accessibilité.

Une alternative devenue courante consiste à utiliser les « labels flottants » tels que décrits dans le design system Material porté par Google.

Cette approche a ses détracteurs car elle n’est pas non plus sans défaut (en).

Proposition : dans 99% des cas, mieux vaut faire simple et laisser labels et placeholders à leur place attendue. Pour des exemples de bonnes pratiques, on se référera au très bon Basic Style Guide chez Romy Duhem-Verdière.

Obliger à utiliser la souris pour saisir des mots de passe

Vouliez-vous dire « maux de passe » ?
— Mon correcteur orthographique

Une terrible épidémie a envahi les sites de banques du monde entier : les claviers virtuels à manipuler au curseur.

Avant, quand je voulais accéder au site de ma banque, mon gestionnaire de mot de passe pouvait automatiquement remplir le formulaire de connexion en une parfaite alliance entre confort et sécurité.

Maintenant, je dois méticuleusement utiliser mon touchpad avec la grâce d’un ourson à trois pattes pour faire voler mon curseur d’un chiffre à l’autre sur un clavier virtuel afin de laborieusement saisir mon mot de passe trop court et ridiculement facile à deviner, mot de passe que tous les passagers du train peuvent de toute façon apercevoir depuis l’autre bout du wagon avec une déconcertante facilité, tout ça pour ne même pas être protégé d’éventuels keyloggers qui maintenant prennent des captures de l’image sous le curseur à chaque clic.

Notez bien : je comprends. Je comprends que les banques aient un important besoin de sécurité et s’adressent à une large population sans éducation sur la question.

Les claviers visuels offrent une protection contre certains vecteurs d’attaque comme les keyloggers les plus primitifs ou le vol de laptops, mais présentent leur propre surface de vulnérabilité, notamment le fait que toute personne avec vue sur mon écran peut désormais voir mon code.

Il y a certes également l’effet psychologique : « regardez, nous avons un mécanisme de sécurité complexe, c’est que nous sommes sécurisés, ayez confiance ».

Toujours est-il que ce type d’interface est absolument infernal à utiliser pour l’utilisateur sans souris, avec les doigts un peu gourds ou utilisant une navigation vocale.

S’il n’existe pas de mécanisme capable de garantir une sécurité absolue tout en étant parfaitement utilisable (ça se saurait), il serait bénéfique de proposer au moins un mécanisme de connexion alternatif.

Il existe par exemple des solutions d’authentification à base de mots de passes à usage uniques et de jetons d’authentification.

Reporter la complexité du processus sur l’utilisateur·ice

On trouve de plus en plus de formulaires de connexion en plusieurs étapes, par exemple sur le site des impôts, chez le fournisseur de service de sauvegarde Crashplan ou sur l’interface de WordPress.

Sur ces sites, le formulaires de connexion présente un champ unique « nom d’utilisateur » (ou équivalent) et il faut une première soumission pour faire apparaître le champ suivant « mot de passe ».

Un tel processus paraît inutilement alambiqué ; un formulaire de connexion n’est-il pas chose triviale ?! Un champ « nom d’utilisateur », un champ « mot de passe », et vogue la galère, nom d’un saucisson à trois bouts !

Pourtant, en matière de développement, les choses sont souvent plus compliquées qu’il n’y paraît. Ainsi, ces formulaires sont probablement conçus pour accommoder des mécanismes de connexion alternatifs comme l’authentification unique.

Oui mais voilà : l’utilisateur dont le besoin est simple se retrouve confronté à cette complexité bien malgré lui ; en l’occurrence, ces formulaires sont laborieux à utiliser avec certains gestionnaires de mots de passe.

Ce n’est pas parce que le processus d’authentification est complexe que cette complexité dois se refléter dans l’interface. Une alternative satisfaisante serait de présenter le formulaire par défaut et d’offrir un chemin vers les voies alternatives. C’est ce qu’on trouve chez le prestataire de paiement Stripe.

L’usager se fiche de la complexité de notre algorithme comme de colin-tampon ; c’est à nous de nous casser la tête, pas à lui.