Remplacer le couple identifiant / mot de passe par des passkeys, c’est supprimer le secret partagé : plus rien de réutilisable ne circule entre l’utilisateur et votre serveur, donc plus rien à voler, à rejouer ou à hameçonner. La norme existe, elle s’appelle FIDO2 (WebAuthn côté navigateur, CTAP côté appareil), elle est implémentée par Apple, Google et Microsoft, et elle est déployable aujourd’hui. La vraie question n’est plus technique : elle est de savoir jusqu’où l’authentification vous emmène, et à partir de quel moment il vous faut autre chose.
Un mot de passe est un secret partagé. Vous le connaissez, votre utilisateur le connaît, votre base de données en garde une empreinte, et parfois un prestataire en garde une copie qu’il n’aurait pas dû garder. Chaque acteur ajouté est une surface d’attaque supplémentaire. Le credential stuffing ne casse rien : il rejoue des identifiants déjà fuités ailleurs, en masse, sur des utilisateurs qui recyclent leurs mots de passe parce que la mémoire humaine n’est pas une infrastructure de sécurité.
La réponse classique a été d’empiler : politique de complexité, rotation forcée, code SMS, notification push. Résultat, un utilisateur qui note son mot de passe, qui valide un push sans lire, et qui appelle le support tous les trimestres. C’est le MFA subi : un coût de friction permanent pour un gain de sécurité qui s’érode dès qu’un attaquant sait fatiguer sa cible ou intercepter un SMS.
À l’inscription, l’appareil de l’utilisateur génère une paire de clés cryptographiques. La clé privée reste dans l’élément sécurisé du téléphone, de l’ordinateur ou de la clé matérielle, protégée par la biométrie ou le code de l’appareil. Seule la clé publique part chez vous. À la connexion, votre serveur envoie un défi, l’appareil le signe, vous vérifiez la signature. Vous ne stockez plus aucun secret exploitable.
Une passkey est liée à l’origine du site (le domaine) lors de sa création. Un faux site, même parfaitement cloné, présente une origine différente : le navigateur refuse tout simplement de signer. Ce n’est pas une meilleure vigilance de l’utilisateur, c’est une impossibilité protocolaire. C’est la différence de nature entre un code à six chiffres, que l’on peut se faire dicter au téléphone par un faux conseiller, et une signature cryptographique liée au domaine.
Les spécifications sont publiques et stables : WebAuthn au W3C, les certifications d’authentificateurs à la FIDO Alliance. Il n’y a plus de pari technologique à faire.
Le malentendu le plus fréquent en comité de direction : croire que la passkey est un facteur de plus. C’est l’inverse. Une passkey combine déjà la possession (l’appareil) et l’inhérence ou la connaissance (biométrie ou code local). Elle constitue une authentification à deux facteurs en un seul geste. Vous ne rajoutez pas une étape, vous en supprimez deux.
Concrètement, l’utilisateur pose son doigt ou regarde son écran, et il est connecté. Pas de code à recopier, pas d’attente de SMS, pas d’application tierce à installer. Sur des parcours grand public où chaque seconde de friction se paie en abandon, ce n’est pas un détail de confort : c’est une variable de conversion.
La récupération de compte. Un système sans mot de passe dont la procédure de secours repose sur un lien par e-mail retombe au niveau de sécurité de la boîte mail. Prévoyez au minimum deux authentificateurs par compte, ou une récupération assistée avec preuve d’identité réelle.
Le parc hétérogène. Les passkeys synchronisées via le trousseau de la plateforme sont pratiques, mais elles suivent l’écosystème de l’utilisateur. Pour les comptes à privilèges, exigez des passkeys liées à un appareil ou une clé matérielle, et vérifiez l’attestation.
Le partage de compte. Une passkey est individuelle. Si votre modèle métier tolérait le partage silencieux d’identifiants, vous allez le découvrir brutalement. Anticipez les usages multi-utilisateurs légitimes.
Une passkey prouve une chose, et une seule : celui qui se connecte aujourd’hui est bien celui qui s’est inscrit. Elle ne dit rien de son identité réelle, de sa majorité, ni de sa qualité professionnelle. Or c’est précisément ce que le régulateur exige désormais. La loi SREN et le référentiel de l’Arcom ne demandent pas aux plateformes de mieux authentifier leurs comptes : ils leur demandent de s’assurer de l’âge de leurs visiteurs, y compris de ceux qui n’ont pas de compte du tout.
C’est là que la plupart des projets dérapent. Pour vérifier, on demande une pièce d’identité, on la stocke, on crée un fichier de personnes associant une identité civile à une consommation de contenus. On a résolu la conformité en fabriquant le risque de fuite le plus grave qui soit. La CNIL a été claire sur ce point en recommandant le double anonymat.
C’est le principe que nous avons industrialisé chez IDxLAB avec GreenBadg : le vérificateur d’identité ne sait pas quel service vous consultez, et le service ne sait pas qui vous êtes. Il ne reçoit qu’une attestation cryptographique : cette personne est majeure, ce professionnel est habilité. Rien d’autre. Sur des environnements exigeants comme ceux de l’industrie du contenu adulte, où nous travaillons avec des acteurs de la taille de Dorcel, cette séparation n’est pas une posture éthique : c’est la seule architecture qui survit à la fois à un contrôle de l’Arcom et à un audit RGPD.
Les passkeys pour l’accès, une attestation anonyme pour le droit d’accès. FIDO2 supprime le secret partagé, le double anonymat supprime la base de données d’identités. Dans les deux cas, la logique est la même et c’est celle que nous défendons depuis l’écosystème French Tech Aix-Marseille : la meilleure façon de protéger une donnée, c’est de ne pas la détenir.
Oui, dans la majorité des cas. Une passkey combine la possession de l’appareil et un déverrouillage local par biométrie ou code : elle vaut déjà une authentification à deux facteurs. Ajouter un code SMS par-dessus n’améliore pas la sécurité et dégrade l’expérience.
Si la passkey est synchronisée par le trousseau de la plateforme, elle se restaure sur le nouvel appareil après authentification au compte système. Si elle est liée à l’appareil, il faut un second authentificateur enregistré ou une procédure de récupération assistée. C’est le point à concevoir en premier, pas en dernier.
Non. La SREN porte sur la vérification de l’âge des visiteurs, pas sur la robustesse de la connexion. Une passkey authentifie un compte existant, elle ne prouve pas la majorité. Il faut un mécanisme de vérification d’âge distinct, idéalement en double anonymat.
Le garder comme méthode de repli annule une grande partie du bénéfice : l’attaquant visera toujours le maillon faible. Mieux vaut une phase de coexistence limitée dans le temps, puis un retrait du mot de passe pour les comptes disposant de plusieurs authentificateurs.
L’intégration WebAuthn elle-même est rapide pour une équipe technique. Ce qui prend du temps, ce sont les parcours de récupération, la gestion du parc d’appareils et la conduite du changement côté support. Prévoyez le budget sur ces trois postes, pas sur le protocole.
