LeBonCoin : quand la sécurité produit casse l'expérience utilisateur

Récemment, en me reconnectant à mon compte sur l'appli Leboncoin, la plateforme m'a demandé de confirmer si mon email et mon numéro de téléphone étaient toujours corrects.

Très bonne pratique de sécurité.

C'est rassurant :

• les données restent à jour,
• les comptes sont plus sécurisés,
• cela limite les fraudes et les comptes volés.

Mais en essayant de modifier le numéro de téléphone, je suis tombé sur un problème produit assez intéressant.

Pour changer le numéro, LeBonCoin envoie un code… sur l'ancien numéro.

Et si on n'a plus accès à ce numéro ?

Impossible de continuer.

Le paradoxe sécurité vs récupération

D'un point de vue sécurité, la logique est clairement compréhensible :

• vérifier que le propriétaire actuel du compte autorise bien le changement,
• éviter qu'un attaquant remplace le numéro,
• limiter les prises de contrôle de compte.

Le problème, c'est qu'un numéro de téléphone est probablement l'information la plus susceptible de changer (changement d'opérateur sans garder le numéro).

Résultat : il faut faire un ticket au support si on veut changer son numéro.

Le vrai problème produit

Le problème n'est pas la vérification, au contraire. Le problème, c'est l'absence de fallback, de prise en compte des « edge cases ».

En product management, un bon flow doit toujours prévoir :

• le cas nominal,
• mais aussi les cas réels, les cas alternatifs.

Et "je n'ai plus accès à mon ancien numéro" n'est pas un edge case.

C'est un scénario potentiellement fréquent.

Ce qu'un meilleur flow pourrait faire

Plusieurs options existent pour garder un bon niveau de sécurité sans bloquer l'utilisateur.

Vérification multi-facteurs

• ancien numéro ou email,
• ancien numéro ou appareil déjà connu (j'aime bien celui-là),
• ancien numéro ou pièce d'identité — ils le font déjà pour les profils vérifiés, ils auraient pu utiliser le même process.

Délai de sécurité

Autoriser le changement après 48h ou 7 jours avec notification :

"Votre numéro sera modifié prochainement si cette demande vient bien de vous."

C'est ce que font beaucoup de services bancaires ou plateformes sensibles.

Analyse de risque contextuelle

Le niveau de sécurité pourrait dépendre du contexte :

• appareil déjà utilisé,
• localisation habituelle,
• session active connue,
• historique du compte.

Un utilisateur connecté depuis son appareil habituel depuis 5 ans n'a pas le même profil de risque qu'une connexion inconnue depuis un autre pays.

Une bonne leçon produit

Ce genre de détail paraît mineur.

Mais c'est exactement le type de friction qui :

• génère des tickets support,
• frustre les utilisateurs,
• peut bloquer des comptes légitimes,
• dégrade la confiance.

Les meilleurs produits ne sont pas seulement "sécurisés". Ils sont capables de gérer les exceptions humaines sans casser l'expérience.

Et souvent, toute la difficulté du product management est là :

Trouver le bon équilibre entre le besoin de sécurité et l'UX.