Passkeys et FIDO2 : l'authentification sans mot de passe en 2026
Les mots de passe sont structurellement brisés. Pas en théorie — en pratique, documentée, chiffrée. Selon le rapport Verizon DBIR 2025, 81 % des violations de données impliquent des credentials compromis : mots de passe volés par phishing, réutilisés depuis une autre fuite, ou déduits par brute force sur des hachages faibles. La réponse de l'industrie n'est pas un nouveau type de mot de passe plus fort : c'est l'élimination du mot de passe comme concept d'authentification. Les passkeys sont cette réponse, et leur adoption massive est en cours en 2026.
Pourquoi les mots de passe sont une impasse en 2026
Le coût des violations liées aux mots de passe est documenté avec précision. IBM Security estime le coût moyen d'une violation de données à 4,88 millions de dollars en 2024, avec les credentials compromis comme premier vecteur d'entrée. Ce chiffre ne capture pas la totalité des coûts indirects : atteinte à la réputation, perte de clients, remédiation technique prolongée.
La réutilisation des mots de passe est endémique. Les utilisateurs gèrent en moyenne plus de 100 comptes en ligne. Même avec les meilleurs gestionnaires de mots de passe, une fraction significative de la population réutilise les mêmes credentials sur plusieurs services. Quand une base de données est compromise, les attaquants testent immédiatement les couples identifiant/mot de passe sur d'autres services populaires — c'est le credential stuffing. Des outils automatisés permettent de tester des millions de combinaisons par heure.
La résistance au phishingdes mots de passe est nulle. Un utilisateur qui entre son mot de passe sur un site imitant son service bancaire l'a définitivement compromis, même si ce site est hébergé depuis cinq minutes. Le MFA par SMS ou par TOTP (application d'authentification) améliore la situation mais ne la résout pas : les attaques de phishing en temps réel capturent le code OTP en même temps que le mot de passe. Le coût de gestion est lui aussi réel : les resets de mots de passe représentent 20 à 50 % des tickets de support dans les grandes organisations.
FIDO2, WebAuthn, passkeys : démêler les termes
La terminologie peut sembler confuse. FIDO Alliance est le consortium industriel (Apple, Google, Microsoft, Amazon, et des centaines d'autres) qui définit les standards d'authentification forte. FIDO2 est le standard technique global, composé de deux spécifications complémentaires : WebAuthn (Web Authentication API, spécification W3C implémentée par les navigateurs) et CTAP2 (Client to Authenticator Protocol, protocole de communication entre le navigateur et un authenticator externe comme une YubiKey).
Les passkeys sont l'implémentation grand public de FIDO2, co-standardisée par Apple, Google et Microsoft sous le nom de multi-device FIDO credentials. La distinction clé avec les clés FIDO2 traditionnelles : les passkeys sont synchronisées entre les appareils de l'utilisateur via le cloud (iCloud Keychain, Google Password Manager, Windows Hello). Un passkey créé sur iPhone est disponible sur MacBook. Cette synchronisation résout le problème d'adoption des clés FIDO2 hardware — la perte de l'appareil ne signifie plus la perte des credentials.
Le mécanisme fondamental : lors de la création d'un compte, une paire de clés asymétriques est générée spécifiquement pour ce site. La clé privée reste sur l'appareil (jamais transmise au serveur), la clé publique est enregistrée sur le serveur. Il n'y a pas de secret côté serveur : même si la base de données est compromise, les clés publiques ne permettent pas d'usurper l'identité des utilisateurs. La résistance au phishing est cryptographique: la paire de clés est liée à l'origine (domaine) du site. Un site imitateur ne peut pas utiliser les clés d'un autre domaine — la vérification échoue automatiquement.
Comment fonctionnent les passkeys techniquement
Chaque passkey est une paire de clés asymétriques spécifique à un domaine. Lors de l'enregistrement, l'authenticator génère la paire de clés, stocke la clé privée dans un environnement sécurisé, et retourne la clé publique ainsi qu'un identifiant de credential (credential ID) au serveur. Lors de l'authentification, le serveur envoie un challenge aléatoire, l'authenticator signe ce challenge avec la clé privée, et le serveur vérifie la signature avec la clé publique stockée.
L'authenticator peut prendre plusieurs formes. Le TPM (Trusted Platform Module) intégré aux PC, le Secure Enclave des appareils Apple, le TrustZone des appareils Android, ou une clé hardware externe (YubiKey, clé FIDO2) constituent des authenticators matériels qui protègent la clé privée dans un environnement isolé du système d'exploitation. La vérification de l'utilisateurse fait localement sur l'appareil — empreinte digitale, Face ID, PIN — sans que cette information biométrique ne soit jamais transmise au serveur. C'est une distinction fondamentale : le serveur ne voit jamais la biométrie.
L'authentification cross-device permet d'utiliser un passkey stocké sur un smartphone pour se connecter sur un autre appareil. Le flux utilise Bluetooth pour vérifier la proximité physique, puis le smartphone signe le challenge. La synchronisation via iCloud Keychain, Google Password Manager ou Windows Hello permet la disponibilité des passkeys sur tous les appareils du même écosystème. Les clés résidentes (discoverable credentials) permettent l'authentification sans identifiant préalable — l'authenticator retrouve automatiquement la clé associée au domaine, ce qui est la base du flux usernameless.
Implémenter WebAuthn dans une application web
L'implémentation WebAuthn se décompose en deux flows distincts. Le flow d'enregistrement utilise navigator.credentials.create() : le serveur génère un challenge aléatoire, le client appelle l'API avec les options de création (incluant le challenge, l'identifiant du relying party, les informations utilisateur et les paramètres cryptographiques), l'authenticator demande la vérification de l'utilisateur (biométrie ou PIN), génère la paire de clés et retourne une attestationsignée. Le serveur vérifie l'attestation et stocke la clé publique.
Le flow d'authentification utilise navigator.credentials.get() : le serveur génère un nouveau challenge, le client appelle l'API avec l'identifiant de credential attendu (ou vide pour un flux usernameless), l'authenticator signe le challenge, et le serveur vérifie la signature avec la clé publique stockée. La vérification côté serveur doit contrôler : le rpId (doit correspondre exactement au domaine), l'origine, le challenge (doit être consommé, évitant les attaques par rejeu), le flag user presence (UP) et optionnellement le flag user verification (UV).
Les bibliothèques recommandées simplifient l'implémentation. SimpleWebAuthn (JavaScript/TypeScript) couvre client et serveur avec une API claire. py_webauthn gère la vérification côté serveur en Python. webauthn(crate Rust) offre une implémentation sûre et performante. Côté serveur, les clés publiques sont stockées en base de données, associées à l'identifiant utilisateur et à l'identifiant de credential. Un utilisateur peut enregistrer plusieurs passkeys (plusieurs appareils), donc la relation est un-à-plusieurs.
Stratégie de migration depuis les mots de passe
La migration vers les passkeys ne se fait pas en un basculement brutal. L'approche de progressive enhancementest la seule viable en production. Dans une première phase, les mots de passe sont conservés comme méthode principale et les passkeys sont proposés comme option supplémentaire. Les utilisateurs qui les adoptent bénéficient immédiatement d'une expérience améliorée sans que les autres soient perturbés. L'instrumentation des métriques d'adoption guide les décisions : quand le taux de passkeys dépasse un seuil significatif, les mots de passe peuvent être rendus optionnels, puis supprimés.
La gestion des appareils multiplesnécessite une interface dédiée dans les paramètres de compte. Les utilisateurs doivent pouvoir voir leurs passkeys enregistrés, en ajouter depuis de nouveaux appareils et en révoquer en cas de perte. Le nommage automatique des passkeys (basé sur l'user agent ou la plateforme) aide à l'identification, mais permettre à l'utilisateur de renommer ses passkeys est une bonne pratique d'UX.
Les recovery flows sans mot de passesont le défi le plus délicat. En l'absence de mot de passe comme filet de sécurité, des alternatives doivent exister : magic links envoyés par email, codes de récupération à usage unique générés lors de l'enregistrement initial, ou support humain vérifié. La communication utilisateur lors de la migration doit être proactive — expliquer ce qu'est un passkey, ses avantages, et comment récupérer l'accès en cas de perte d'appareil. L'abandon du processus d'enregistrement est le principal risque d'adoption.
Considérations de sécurité avancées
L'attestation permet de vérifier que l'authenticator est digne de confiance. Lors de l'enregistrement, l'authenticator peut fournir un certificat signé par son fabricant, prouvant son modèle exact et ses caractéristiques de sécurité. Pour les environnements à haute sensibilité (finance, administration), valider l'attestation garantit que seuls des authenticators certifiés FIDO2 Level 2 ou Level 3 sont acceptés. Le FIDO Metadata Service(MDS) fournit les informations de certification pour des milliers d'authenticators.
Le mécanisme anti-clonageest intégré au protocole. Chaque réponse d'authentification inclut un compteur qui s'incrémente à chaque utilisation. Si le serveur reçoit une réponse avec un compteur inférieur ou égal au dernier compteur connu, cela signale une possible copie de l'authenticator — un événement qui doit déclencher une alerte et forcer une réauthentification. Les passkeys synchronisés ne garantissent pas ce compteur (par conception), mais les clés hardware FIDO2 si.
La révocation de passkeys doit être possible depuis l'interface de gestion de compte et depuis un canal alternatif (support, email vérifié) en cas de perte d'appareil. En contexte enterprise, le déploiement de hardware keys (YubiKey, clés FIDO2 certifiées) est préférable aux passkeys synchronisés : les clés ne quittent pas l'environnement contrôlé de l'entreprise. La gestion centralisée des clés via des MDM (Mobile Device Management) et des annuaires LDAP/AD est nécessaire à grande échelle. Les appareils partagés posent un problème spécifique : les passkeys liés à un profil utilisateur sur un appareil partagé doivent être gérés par des politiques organisationnelles claires.
Les passkeys ne sont pas une amélioration du mot de passe — ils en sont le remplacement. Par conception, ils éliminent le phishing, le credential stuffing et la réutilisation. La question n'est plus de savoir s'il faut migrer, mais à quelle vitesse.
L'adoption des passkeys est irréversible. Apple, Google et Microsoft ont intégré le support nativement dans leurs plateformes. Les grands services — GitHub, Google, Apple, PayPal — ont déployé les passkeys pour leurs centaines de millions d'utilisateurs. Le standard WebAuthn est stable, implémenté dans tous les navigateurs majeurs, et supporté par des bibliothèques matures dans tous les langages. Pour les équipes qui construisent ou maintiennent des systèmes d'authentification, la question pratique est celle de la stratégie de migration : progressive, mesurée, avec des fallbacks bien conçus, en investissant dans la communication utilisateur. L'ère du mot de passe se termine — et c'est une bonne nouvelle pour la sécurité de tous.