Best Of Webdesign — 09 septembre 2014 — 1 commentaire
Social Login: les 7 erreurs à ne pas commettre pour votre application

Il y a tellement de confusion dès que l’on parle de boutons de « Social Login ». Parfois, connecter une application à un réseau social est nécessaire pour le produit. Par exemple : “Se connecter avec Facebook” pour jouer à un jeu avec des amis ; “Se connecter avec Twitter” pour « unfav » tous vos tweets, Etc…

Sur OAuth.io nous voyons beaucoup d’applications capitalisant sur OAuth pour offrir ce genre de fonctionnalités. Pourtant, OAuth est aussi souvent utilisé pour l’authentification (si vous n’êtes pas familier avec ce standard bizarre, j’ai écrit un tutoriel sur OAuth, pas encore traduit mais ça viendra).

Dans le cas de l’authentification donc, deux partis se font face : les fournisseurs de Social Login qui expliquent que c’est un « must » pour « booster les conversions », et les outsiders se voulant un peu « cool », et qui disent « ça ne vaut pas le coup, cela est mauvais pour l’UX et c’est intrusif ».

La vérité est bien sûr quelque part entre les deux : tout dépend du but à atteindre. Il est donc très important de prêter attention aux faits, plutôt que de se laisser séduire par des titres aguicheurs.

Le paysage des Social Logins est plein de pièges, donc évitons-les. Voici les 7 erreurs à éviter, les 7 mensonges ou simplifications abusives que l’on entend trop souvent.

1- “L’utilisateur n’aura plus besoin de remplir un formulaire”

Cette déclaration sonne très bien en théorie, mais tâchons de vérifier avec un exemple. Gigya est le leader en gestion de Social Login. C’est ce qu’ils vendent, donc ils doivent maîtriser le sujet au top : pas d’excuse.

Ils proposent en effet un bon paquet de boutons sociaux : au top !

connection réseaux sociaux

Tentons de nous enregistrer avec Twitter.

twitter authorize

Whaou, ils veulent avoir le droit de suivre des gens, modifier mon profil et poster des tweets en mon nom ? Pourquoi donc ? Je ne fais que tester leur service commercial, ce n’est même pas une application. Il me font trop peur.

Essayons avec un autre fournisseur, plus professionnel : LinkedIn.

linkedin

Demande « d’accéder à mon profil et à mes connexions », OK, ça va. De cette façon, Gigya sera en mesure de remplir le formulaire de façon automatique.

Quoique.

complete profile

Oh non ! On dirait que je dois encore taper le nom de mon entreprise, ainsi que mon adresse email. Pourquoi ne récupèrent-ils pas cette info depuis LinkedIn ?

Peu importe, tentons avec… Facebook. Ouille, le formulaire ne charge pas.

giga

Essayons avec un autre navigateur.

gigya

Loupé aussi. OK j’abandonne. Je voulais juster tester le flow, mais apparemment, ce n’est pas le bon moment.

La morale de cette histoire ? Eh bien les formulaires ne se remplissent pas toujours grâce à un Social Login. Pas du tout même.

2- “Vous aurez une adresse email pré-validée”

Whouhou, excellent : plus besoin d’envoyer un email de confirmation devant être cliqué. Quel gain. Quand un utilisateur doit regarder ses emails, et parfois même fouiller dans sa boîte spam, les conversions chutent. Vous le savez bien.

Mais la réalité est encore une fois plus difficile qu’il n’y paraît. Continuons avec mon exemple Gigya : si j’étais parvenu à m’enregistrer avec Facebook, j’aurais tout de même dû taper mon adresse email. En effet, comme beaucoup de gens, mon courriel est caché dans mon profil Facebook. Oui.

Mais il y a pire : prenons un autre fournisseur d’identité bien connu. Twitter n’aurait pas retourné mon email non plus : le service de micro-blogging ne donne jamais accès à cette information. Pour avoir un email prévalidé, il aurait donc fallu s’en tenir à des fournisseurs comme Yahoo ou Gmail.

3- “Les Social Logins boostent les conversions”

Même si l’utilisateur doit encore remplir des formulaires pas commodes, il est vrai que le mot de passe n’est lui plus requis. Fantastique, car cela simplifie le processus d’enregistrement. Mais il y a un sacrifice.

N’oubliez pas que l’utilisateur aura besoin de cliquer deux fois : premièrement pour ouvrir un popup géré par le fournisseur d’identité, et deuxièmement pour autoriser l’application. Cela signifie que lors d’un signup, la personne quitte votre interface pour quelques secondes.

Pas si terrible, certes, mais loin d’être optimal. Laissez-moi vous expliquer.

Lors d’un enregistrement, vous voulez aller droit à l’essentiel et minimiser les frictions. Prenons sur un exemple extrême : le formulaire de signup pour Stripe.

Voyez ? Vous pouvez même “Skip this step”, soit « Sauter cette étape » !

stripe

Si vous choisissez cette option, vous serez ensuite redirigé vers le tableau de bord où vous pourrez expérimenter le produit, et si vous le souhaitez, une option « Sauvegarder le compte » est à votre disposition. La création de compte est aussi simple que si vous sauvegardiez un texte.

stripe2

Magique. Cerise sur le gateau : le formulaire de sauvegarde revient sous un format hyper-simplifié : email / mot de passe, c’est tout.

stripe3

Peut-être que n’importe quelle marque ne peut pas procéder ainsi. Mais mon objectif est juste d’illustrer que minimiser la friction est toujours votre objectif numéro 1. C’est LE point crucial (après avoir un bon produit, bien sûr).

La science vient même confirmer ce point : « obtenir qu’une personne donne son accord pour une demande contraignante, en commençant par une demande limitée » est une règle bien connue de psychologie sociale, appelée la technique du « pied-dans-la-porte« .

Pour parvenir à cela, le bouton de Social Login est une option, mais ce n’est pas toujours la meilleure :

  • Email + mot de passe peuvent être plus léger qu’un double clic avec un popup ;
  • Demander un enregistrement direct n’est pas non plus toujours la bonne solution.

Si vous êtes un media en ligne, peut-être qu’un Facebook connect se révèlera idéal. Mais dans d’autre cas, il peut y avoir de meilleures solutions : pas de règle universelle.

4- “Les futures connexions seront facilitées”

L’argument est le suivant : si un utilisateur s’enregistre avec Facebook, il n’aura pas à se souvenir du mot de passe. La prochaine fois qu’il se connecte, il n’y aura pas de péripétie du type « J’ai oublié mon mot de passe ». Par conséquent, cela boostera la fidélité et la CLV….

La réalité est moins reluisante. Les gens s’enregistrent à beaucoup de services différents, avec plein de comptes de réseaux sociaux. Tout développeur vous le dira : empêcher les duplicata d’utilisateurs est un casse-tête quasi impossible à résoudre.

Un utilisateur s’enregistrerait avec Twitter, puis reviendrait en se connectant avec Facebook, et il n’y aurait aucun moyen de recouper les deux identités comme étant une seule et même personne.

Peut-être qu’un cookie pourra aider à proposer le bon bouton, mais nous vivons dans un mode multi-supports : téléphones, tablettes, PC… Il n y a pas de solution parfaite.

Le plus vous proposerez de boutons de Social Login différents, le plus de confusion vous créerez.

5- “Les utilisateurs peuvent ainsi contrôler leurs données”

Les Social Logins s’appuient toujours sur des permissions données par l’utilisateur. Cela est supposé être génial. De cette façon, les applications tiers ne sont pas en mesure d’accéder à tout et n’importe quoi.

Le concept a récemment été poussé un cran plus loin, avec l’annonce de Facebook, concernant son « login anonyme » (d’ailleurs, connaissez-vous quelqu’un ayant effectivement utilisé cette fonctionnalité ?).

Mais on oublie alors que la confidentialité est asymétrique. Les gens oublient que ce n’est effectif que d’un seul côté : les fournisseurs d’identité (Facebook par ex.) savent ainsi exactement quelles applications sont consommées, par qui et comment.

Quoi qu’il en soit, cela ne vous impacte pas directement en tant que développeur d’application. Même si cela peut être une question éthique, le fait qu’un fournisseur d’identité connaisse vos utilisateurs n’est pas un problème. Attendez. Sauf si ce fournisseur est votre concurrent évidemment… Oups.

6- “Les Social Logins sont la source d’un Nascar Effect”

Voici un des points mis en avant par le CEO de Mailchimp, Ben Chestnut : il demanda de retirer les Social Logins de son interface, à cause de l’effet que cela pourrait avoir sur l’image de marque. Comme nous l’avons vu, l’enregistrement est une phase cruciale du parcours client. Donc aurait-il raison ?

Avoir des logos Facebook, Twitter, Google, etc. sur votre site, reviendrait à transformer votre propre produit en Nascar :

auto

Diluer la marque en affichant des logos de tiers, peut distraire votre cible et diluer votre impact. Lorsque vous regardez comment Mailchimp gère son Signup, il est vrai qu’inclure un bouton Facebook pourrait perturber l’expérience :

mailchimp

Beau design. Il ne faudrait pas tout gâcher. Mais penchons-nous sur un autre cas.

Voyez ci-dessous ? Pensez-vous vraiment que le bouton « Signup with Google » dissout la marque Trello ?

trello

Réponse : de mon point de vue, non. M. Mailchimp en fait donc un peu trop.

Et je préfère mille fois m’enregistrer avec Google, plutôt que de créer un nouveau nom d’utilisateur arbitraire, dont je devrais me souvenir à chaque fois que je reviens.

D’ailleurs, Mailchimp encombre mon cerveau : pourquoi ne puis-je pas fournir une simple adresse email en tant qu’identifiant ? Pourquoi faut-il que j’invente un énième nom d’utilisateur ?

Ils doivent penser que cela va créer une atmosphère et une relation spéciale avec la marque, mais c’est au fond vraiment énervant. J’ai vérifié avec quelques personnes autour de moi, et je ne suis pas le seul à toujours oublier ce satané nom d’utilisateur.

Les boutons sociaux ne transforment pas obligatoirement votre site web en « Nascar ». Continuons avec un dernier mythe répandu par nos amis de chez Mailchimp.

7- “Les boutons de Social Login ne valent pas le coup”

Haha, peut-être avez-vous reconnu le titre d’un fameux billet du blog de Mailchimp. Il ne s’agit néanmoins que d’un « linkbait » ayant causé de longues files de commentaires en 2012. Lorsque vous lisez leur texte pour de vrai, vous réalisez que ce n’est rien d’autre qu’un titre pour faire cliquer.

On y apprend essentiellement qu’une seule chose : grâce à de meilleurs messages d’information pour les champs utilisateur / mot de passe, les erreurs de connexion ont chuté de 66%, et les réinitialisations de mots de passe de 42%. Très intéressant certes, mais cela n’a rien à voir avec le titre aguicheur, qui répand encore un mythe à propos des Social Logins.

Et ce sera donc ma conclusion : impossible de faire une règle générale concernant les boutons de Social Logins. Dire que c’est un must, ou que c’est inutile, voici qui est stupide dans les deux cas.

Cela détourne des vraies problématiques, sur lesquelles devraient se pencher le développeur de l’application, le Product Manager et l’expert en UX.

Bien sûr, s’appuyer sur un tiers pour l’authentification n’est pas parfait. Néanmoins, participer à la création de nouveaux noms d’utilisateurs ou mots de passe est aussi très mauvais pour internet.

Souvenez-vous de toujours construire votre stratégie en vous basant sur votre produit, et non en écoutant ce que d’autres tentent de dicter de façon unilatérale.

Articles similaires

Articles Recommandés



L'auteur



1 Commentaire

  1. Sympa l’article !

    Concernant le point 1 cela me semble indispensable de rajouter un formulaire derrière : ainsi les inscrits s’inscrivent réellement sur le site avec leur vrai email et on est pas dépendant à vie de l’api Facebook ou Twitter. (ce qui me semble être un pari risqué)

    Pour moi l’avantage principal du login social c’est le fait qu’un user puisse ensuite se logger en un clic sans saisir aucune info (si il est deja loggé sur Facebook par exemple)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *