Passkeys : en finir avec les mots de passe dans vos apps web

"Mot de passe oublié." C'est probablement le lien le plus cliqué de l'internet. Et pour cause. On demande aux gens de retenir des dizaines de mots de passe uniques, complexes, avec des majuscules, des chiffres, un caractère spécial, et surtout de ne pas réutiliser le même partout. Le résultat ? Tout le monde utilise "Soleil2024!" sur les douze sites où il a un compte.

Les passkeys changent la donne. Et en 2026, ce n'est plus un concept de conférence Google I/O. C'est un standard mature, déployé à grande échelle.

Ce qu'est une passkey, concrètement

Une passkey, c'est une clé cryptographique stockée sur votre appareil : téléphone, ordinateur, clé de sécurité physique. Pour se connecter, il suffit de déverrouiller son appareil. Empreinte digitale, Face ID, code PIN. Pas de mot de passe à taper. Pas de mot de passe à retenir. Pas de mot de passe à fuiter.

Techniquement, c'est basé sur WebAuthn et FIDO2, des standards ouverts supportés par tous les navigateurs modernes. La crypto derrière est solide (paires de clés asymétriques), mais l'utilisateur final n'a besoin de comprendre aucun de ces termes. Il pose son doigt sur le capteur et c'est fait.

Pourquoi maintenant et pas il y a cinq ans

Parce que l'écosystème est enfin prêt. Google a dépassé le milliard d'authentifications par passkeys sur plus de 400 millions de comptes. Un milliard. Apple, Microsoft et Amazon ont tous intégré les passkeys dans leurs plateformes. Le support navigateur est universel : Chrome, Safari, Firefox, Edge. Les gestionnaires de mots de passe comme 1Password et Bitwarden synchronisent désormais les passkeys entre appareils, ce qui résout le problème historique du "j'ai créé ma passkey sur mon téléphone et je suis sur mon ordinateur".

Le standard est là. L'adoption grand public aussi. Ce qui manque, ce sont les applications métier. Vos applications.

Ce que ça change pour vos utilisateurs

Fini le "mot de passe incorrect" après trois tentatives. L'utilisateur touche son capteur d'empreinte et il est connecté. Le taux d'abandon à la connexion, ce chiffre que personne ne mesure mais qui coûte cher, chute drastiquement.

Fini le phishing par fausse page de connexion. Les passkeys sont liées au domaine. Une passkey créée pour votreapp.com ne fonctionnera jamais sur v0treapp.com, même si la fausse page est une copie parfaite au pixel près. Le phishing par credential harvesting devient techniquement impossible. Pas "plus difficile". Impossible.

Et fini la base de mots de passe à protéger. Si vous n'avez pas de mots de passe, il n'y a rien à fuiter. Pas de table de hash à sécuriser, pas de politique de complexité à imposer, pas de rotation forcée tous les 90 jours que tout le monde contourne en ajoutant un "!" à la fin.

Comment intégrer progressivement

Personne ne vous demande de supprimer les mots de passe du jour au lendemain. Ce serait d'ailleurs une mauvaise idée. L'approche qui fonctionne, c'est de proposer la passkey en option à la création de compte et dans les paramètres de sécurité, puis d'encourager la migration avec un bandeau discret pour les utilisateurs existants. On garde le mot de passe en fallback pendant la transition, on mesure l'adoption semaine après semaine, et on retire le mot de passe quand le taux est suffisant.

Côté technique, la plupart des frameworks auth modernes supportent WebAuthn. Next-Auth (Auth.js) a un support natif des passkeys. Supabase Auth propose une intégration WebAuthn. Et pour une implémentation sur mesure, @simplewebauthn/server et @simplewebauthn/browser sont des bibliothèques solides et bien documentées. L'intégration typique prend entre 2 et 5 jours selon la complexité de votre système d'authentification existant.

Les cas où ça ne suffit pas encore

Soyons honnête, les passkeys ne couvrent pas tout. Sur les appareils partagés (bornes, ordinateurs publics), la passkey est liée à l'appareil et pas à la personne, ce qui pose un problème évident. Certains utilisateurs peu technophiles auront besoin d'accompagnement pour comprendre le concept, même si "posez votre doigt ici" est quand même plus simple que "inventez un mot de passe de 12 caractères avec une majuscule et un symbole". Et pour les applications critiques comme la banque ou le médical, les passkeys devraient être combinées avec un deuxième facteur.

Ce ne sont pas des blocages. Ce sont des cas à anticiper dans votre parcours utilisateur.

Le coût de ne rien faire

Chaque mois passé avec des mots de passe classiques, c'est des tickets support pour des mots de passe oubliés (comptez le coût si vous ne l'avez jamais fait, le chiffre va vous surprendre), un risque de fuite de données avec les conséquences RGPD associées, des utilisateurs qui abandonnent à la connexion parce qu'ils ne retrouvent plus leur mot de passe, et une expérience utilisateur qui commence à dater face à des concurrents qui ont migré.

Le passage aux passkeys n'est pas un gadget. C'est le standard vers lequel tout converge. La question n'est plus "est-ce qu'on y passe" mais "quand".

Votre app utilise encore des mots de passe classiques ? Prenez 15 minutes pour qu'on évalue ensemble ce que la migration implique sur votre projet.