Arrêtons de masquer les mots de passe dans les formulaires de création de compte

Il y a quelques semaines, nous avons posé des codes de tracking sur tous les champs du formulaire de création de compte et d’identification du site e-commerce d’un client. L’objectif était de s’assurer qu’il n’y avait pas de points de blocage à cette étape cruciale dans le tunnel de commande.

Exemple 1 : Site GraindeMalice.fr, mot de passe masqué, et double saisie du mot de passe.

formulaire-creation-compte1

 

Exemple 2 : Site Timefy.com, mot de passe masqué, et double saisie du mot de passe.

formulaire-creation-compte2L’analyse nous a montré que le champ de saisie sur lequel les clients butent le plus est celui du mot de passe. Et notamment, lors de l’étape de création de compte où il faut confirmer le choix de son mot de passe.

Logique. Quand on saisie un texte sur un clavier, nous regardons ensuite à l’écran pour contrôler la saisie. Mais quand la saisie du texte est remplacée par des étoiles, comment fait-on pour vérifier que nous n’avons pas fait de faute de frappe ? Qu’il n’y a pas une minuscule à la place d’une majuscule ??? Un O à la place du 0. Un 1 à la place du l. Ce n’est pas possible.

Nous sommes donc en face d’une source d’erreur assurée ! Car souvent, les 2 mots de passe ne correspondent pas et génèrent un message d’erreur. Le client recommence 1 fois, 2 fois, 3 fois… Au bout d’un moment, le client est soulé, et il laisse tomber sa commande.

Et là, je me demande quel est l’idiot qui a inventé ce système de camouflage, et comment il a réussi à l’imposer sur tous les formulaires d’identification de la planète ?

Le seul intérêt de masquer la saisie du mot de passe est de garder sa confidentialité à l’écran si la personne est avec quelqu’un à côté d’elle ou dans son dos pour faire son shopping. Mais en dehors de ce cas de figure, je ne vois pas…

Conclusion

Vos concurrents convertissent plus que vous ! Contactez nous pour booster votre conversion

Nous avons proposé au client 3 petites modifications :

  • Supprimer la double saisie du mot de passe dans le formulaire de création de compte.
  • Afficher par défaut la saisie du mot de passe en clair, pour la création de compte et l’identification de son compte client (Oui… nous avons osé ! )
  • et pour les clients qui sont un peu paranoïaque, nous avons fait placer un bouton à côté du champ qui permet de passer en saisie confidentielle. Comme ça, tout le monde est content.

Exemple du formulaire de connexion de MailChimp avec le mot de passe visible.

creation-compte1

 

Avec le mot de passe masqué.

creation-compte2

 

Résultat

Il était prévisible. Le taux d’abandon du formulaire de création de compte a diminué, et plus de commandes ont été concrétisées.
Personne ne s’est plaint d’un problème de confidentialité de son mot de passe pour l’instant.

Cela tient parfois à peu de chose…

Si vous avez envie de tester la même chose sur votre site, n’hésitez pas à nous tenir informé du résultat, dans les commentaires de l’article.

Like it ? Share it !
Ludovic Passamonti - Directeur Associé
Author

Diplômé de l’ESG et travaille dans le web depuis 14 ans. Il a défini et mis en oeuvre des stratégies internet et e-commerce pour des grandes marques comme des PME, en agence web, puis en tant que consultant e-commerce freelance.
Co-fondateur de Skeelbox. Il intervient régulièrement dans des conférences, et séminaires.

Plus d'articles de cet auteur
Stay in touch :
  1. Romain BOYER dit :

    Je vois que nos avis se rejoignent, l’exemple de MailChimp me semble sympa effectivement !

  2. Benoit Gaillat - Directeur Associé Benoit dit :

    Mailchimp a pour moi un des meilleurs formulaire à ce niveau. On peut voir que Windows 8 exploite aussi cette fonctionnalité (peut être la seule bonne idée du système…)

  3. Jérôme dit :

    C’est effectivement une bonne idée de laisser le choix à l’utilisateur. Je suis toutefois surpris par cette analyse. Beaucoup d’utilisateurs bloqueraient au moment du mot de passe au point d’abandonner ? J’ai du mal à y croire. La création d’un compte en ligne est devenu extrêmement banal, même ma mère y est rompue ! Je suis surpris que des utilisateurs bloquent car beaucoup d’entre eux utilisent le même mot de passe pour tous leurs comptes (ceci est un autre débat).
    Quel était le taux d’échec à ce niveau ?

  4. Ludovic Passamonti - Directeur Associé Ludovic Passamonti dit :

    Bonjour Jérôme,
    Je n’ai pas dit que « beaucoup » d’utilisateurs abandonnaient, j’ai écrit que ce système de double saisie du mot de passe n’est pas optimal car il génère plus d’erreurs qu’une saisie unique. Certain ont effectivement abandonné, faute d’arriver à faire matcher la double saisie en aveugle.

  5. Benoit Gaillat - Directeur Associé Benoit dit :

    La création de compte est pourtant un calvaire pour la plupart des internautes, trouver un mot de passe (car oui tout le monde ne’utilise pas le même partout) est une réelle corvée …

  6. Benjamin dit :

    Le test est intéressant, il s’agit maintenant de voir si les renouvellements de mot de passe n’explosent pas.

    Si les clients ont du mal à taper un mot de passe similaire deux fois de suite, même en clair le fait de ne pas le réécrire deux fois peut créer des erreurs de saisie.

    Si ça améliore la conversion pourquoi ne pas le faire ?

    Les deux exemples sont bons parce que ce sont deux cas différents : sur l’un il faut cliquer pour voir que l’on s’est trompé et sur l’autre le javascript fait le travail en live.
    La deuxième solution est donc bien meilleur et évite au client de piétiner.

    Mais le problème majeur de votre solution et que cela crée une faille de sécurité…

    Le fait de mettre un attribut text à la place d’un attribut password change le comportement du navigateur et lorsque l’on clique sur « précédent » on voit le mot de passe en clair alors qu’il aurait été effacé avec un attribut password.

    L’idiot qui a inventé ça doit être vieux, mais les idiots des navigateurs l’ont suivi et ont créé des comportements qui sont en adéquation avec sa création…

    Attention donc aux fausses bonnes idées… Mais si on ne test pas on avance jamais !

  7. Benjamin dit :

    Il faut ajouter un « autocomplete = « off » » dans le formulaire pour que le navigateur ne le prenne pas en compte.

  8. Arnaud dit :

    Je crois que ça a été inventé par mesure de sécurité, pas seulement pour masquer la saisie si une personne est derrière mais parce qu’à l’époque, les écrans CRT générait un champ magnétique qui pouvait être capté par des « espions ». J’ai lu ça dans un livre écrit par un mec de la CIA.
    Pour info, tout le monde utilise une carte bancaire et ça n’a jamais choqué personne que le code ne s’affiche pas à l’écran.
    Les systèmes peuvent être améliorés mais le « mec » qui a inventé ce système n’a rien d’idot.
    D’ailleurs, si je tombe sur un site qui n’utilise pas de champs password lorsque je rentre mon mot de passe, je fais tout de suite demi-tour !
    Pour le coup du « Un O à la place du 0 », afficher le mot de passe ne changera pas le problème, surtout si le champs utilise une police sans-serif ou les 2 caractères sont assez proches.

    Je pense que le bon système est de masqué par défaut, de proposer un bouton pour l’afficher. Dans le cas ou on l’affiche, on fait disparaître le second champs de vérification qui ne sert plus a rien.

  9. Yann dit :

    Effectivement, garder de la confidentialité peut être intéressant, mais il faut voir à l’usage. Une messagerie et probablement plus critique qu’un Ecommerce de Piano sur lequel tu te connecte très probablement de chez toi a l’abri des regards.

    En tout cas j’aime beaucoup l’idée, j’aurais bien testé sur mon site, mais il n’y a heureusement pas de double saisie 😀

  10. Mathieu dit :

    Intéressant, mais comment mettre en place cette technique sur le formulaire d’inscription de Prestashop ?

  11. Rahan13 dit :

    Il ne faut pas tout mélanger

    Il n’y a aucune sécurité derrière un champ en « password ». Le navigateur masque visuellement la saisie, mais le mot de passe est géré strictement de la même manière. dailleurs, la plupart des navigateur ont des adds-on qui permettent d’afficher en clair les mot de passe même dans les zones apssword : s’ils existent, c’est qu’il y a un besoin, parce qu’effectivement il y a des utilsateurs que ça gène de ne pas le voir.

    Au final, si le site n’est aps en https, le mot de passe est transmis en clair au serveur : vous imaginiez quoi ? que le serveur reçoit des **** et devine ??

    Donc, aucun problème de sécurité à mettre la zone en clair. Je dirais qu’en plus de faciliter la vie des internautes, ça réduit aussi le support.

  12. Rahan13 dit :

    « lorsque l’on clique sur « précédent » on voit le mot de passe en clair alors qu’il aurait été effacé avec un attribut password. »

    => oui, et ré-affichable en un clic… il suffit de regarder la clause « value » du source html ou d’installer un add-on pour voir le mot de passe en clair… le fait de masquer le mot de passe apporte un sentiment de sécurité extrêmement trompeur : la sécurité est nulle… la faille dont vous parlez inexistance…..

    Il est illusoire de masquer des données que l’utilisateur tape sur son clavier : elle sont forcément connues en clair sur votre pc ou mac. Une personne mal intentionnée la retrouvera localement, attribut password ou pas. Il l’a retrouvera d’autant plus facilement que le fait de croire que l’attribut password vous protège fait que vous ne prenez pas d’autres sécurité, telle que naviguer en mode privé, ou vider vos caches, etc…

    La sécurisation ne peut avoir lieu qu’au moment du transfert de cette information au serveur : le mot de passe sera en clair sur un site http et crypté sur un site https…. au même titre que toutes les autres information du formulaire.

  13. PHILIPPE dit :

    Bonjour,
    Le site de MailChimp n’affiche plus le mot de passe par défaut à ce jour.

    Il y a eu un problème avec l’affichage du mot de passe par défaut ?

    Cordialement
    Philippe

Laisser une réponse