Les passkeys ont franchi le point de bascule — Les mots de passe perdent du terrain

Pendant des années, l'avenir sans mot de passe n'était qu'une diapositive PowerPoint — prometteuse, perpétuellement « à venir », et n'arrivant jamais vraiment. Cela a changé. D'ici la mi-2026, les passkeys sont passées du statut de fonctionnalité expérimentale à celui d'authentification par défaut pour des centaines de millions de comptes. Google, Apple, Microsoft, Amazon, GitHub, Shopify, PayPal et WhatsApp ont tous soit adopté les passkeys par défaut, soit en ont fait le principal identifiant recommandé. La transition n'est plus théorique. Elle a lieu, et les données de sécurité qui la sous-tendent sont frappantes.

Ce que sont réellement les Passkeys

Les passkeys sont une implémentation du standard FIDO2/WebAuthn, une spécification développée conjointement par la FIDO Alliance et le W3C. À leur cœur, les passkeys utilisent la cryptographie asymétrique à clé publique : lorsque vous enregistrez une passkey auprès d'un service, votre appareil génère une paire de clés. La clé privée ne quitte jamais votre appareil (ou votre trousseau synchronisé). Le service ne stocke que la clé publique. Lorsque vous vous authentifiez, le service envoie un défi cryptographique ; votre appareil le signe avec la clé privée ; le serveur vérifie la signature avec la clé publique stockée.

Aucun mot de passe n'est transmis. Aucun secret partagé n'existe sur le serveur à voler. Une violation de base de données qui divulgue chaque identifiant stocké ne révèle que des clés publiques — inutiles pour un attaquant sans les clés privées correspondantes qui restent sur les appareils des utilisateurs.

Passkeys liées à un appareil vs. synchronisées

Il existe deux modèles de déploiement fondamentalement différents, et la distinction est importante tant pour la sécurité que pour la convivialité :

• Passkeys liées à un appareil (également appelées identifiants liés au matériel ou non découvrables) sont stockées dans un module de sécurité matériel — une puce TPM sous Windows, l'Enclave Sécurisée sur les appareils Apple, ou une clé matérielle FIDO2 comme un YubiKey. La clé privée est physiquement non exportable. Si l'appareil est perdu, la passkey est perdue. C'est le modèle le plus sécurisé et il est approprié pour les entreprises, les comptes à haute valeur, et les personnes soucieuses de la sécurité prêtes à gérer des clés de sauvegarde.
• Passkeys synchronisées sont stockées dans un trousseau soutenu par le cloud — le iCloud Keychain d'Apple, le Google Password Manager, ou un gestionnaire tiers comme 1Password ou Bitwarden. La matière de la clé privée est cryptée, synchronisée entre vos appareils, et peut survivre à la perte d'un appareil. Cela sacrifie une garantie étroite d'attestation matérielle en échange d'une bien meilleure convivialité et récupération. Pour la grande majorité des cas d'usage grand public, les passkeys synchronisées représentent une énorme amélioration de sécurité par rapport aux mots de passe, sans inconvénient significatif dans le monde réel.

La mise à jour des spécifications de la FIDO Alliance en 2023 a officiellement normalisé les passkeys synchronisées après avoir reconnu que les passkeys uniquement matérielles créaient une barrière à l'adoption qui maintenait les utilisateurs sur les mots de passe — le pire résultat pour la sécurité globale.

Le Flux d'Authentification, Étape par Étape

Comprendre ce qui se passe sous le capot lors d'une authentification WebAuthn aide à clarifier pourquoi les attaques de phishing échouent contre les passkeys :

• Enregistrement : Le navigateur appelle navigator.credentials.create() avec un défi du serveur. L'authentificateur (appareil, plateforme ou clé matérielle) génère une paire de clés limitée à l'ID exact de la partie de confiance (le domaine). La clé publique et un ID d'identifiant sont envoyés au serveur et stockés.
• Authentification : Le serveur émet un nouveau défi aléatoire. Le navigateur appelle navigator.credentials.get(). L'authentificateur vérifie que l'origine et l'ID de la partie de confiance correspondent exactement — une passkey enregistrée pour google.com refusera de signer un défi provenant de g00gle.com. Après vérification biométrique ou par code PIN, la clé privée signe le défi. Le serveur vérifie la signature.
• La barrière anti-phishing : Parce que la passkey est liée à l'origine exacte lors de l'enregistrement, un site de phishing ne peut pas intercepter ou réutiliser les identifiants. Même si un utilisateur est amené à visiter un site similaire, l'authentificateur refuse de produire une signature valide pour une origine différente. C'est le mécanisme derrière le taux de phishing quasi nul pour les comptes utilisant des passkeys.

Chiffres d'Adoption : Ce que Montrent les Données

Google a rapporté à Google I/O 2024 que plus de 800 millions de comptes Google avaient activé les passkeys, contre 400 millions à la fin de 2023. Début 2025, Google a commencé à inciter les utilisateurs à créer des passkeys lors des flux de connexion et a commencé à paramétrer par défaut les nouveaux comptes vers une approche passkey en premier. Des données internes de Google citées dans leur blog de sécurité montraient que les connexions par passkey se terminaient à un rythme 4 fois plus rapide que les flux mot de passe + 2FA par SMS.

Plus important encore : les métriques internes de phishing de Google pour les comptes ayant migré vers une authentification uniquement par passkey montraient des taux de compromission par phishing proches de zéro — comparé à une base de référence de comptes avec mot de passe où même avec 2FA, les attaques de phishing par SIM-swap et AiTM (adversaire au milieu) continuaient de réussir.

Apple a déployé la prise en charge des passkeys dans iOS 16 et macOS Ventura (2022) et d'ici 2025 avait fait des passkeys la méthode suggérée par défaut dans le gestionnaire d'identifiants de Safari. Microsoft a activé les passkeys pour les comptes Microsoft grand public en 2023 et les a étendus à Entra ID (Azure AD) pour les entreprises en 2024. GitHub a rendu les passkeys généralement disponibles en 2023 et a constaté une adoption particulièrement forte parmi les comptes développeurs — un segment de cible à haute valeur où la résistance au phishing est critique.

Support des Plateformes et de l'Écosystème

Apple : Passkeys iCloud Keychain

L'implémentation d'Apple synchronise les passkeys de manière chiffrée de bout en bout via iCloud Keychain. Les passkeys fonctionnent sur iPhone, iPad, Mac et — depuis iOS 17 — peuvent être partagées avec des membres de la famille ou utilisées sur des appareils non Apple via une authentification de proximité par QR code. L'Enclave Sécurisée impose une vérification biométrique (Face ID ou Touch ID) avant toute opération de signature. Apple prend également en charge les clés de sécurité matérielles comme authentificateurs de passkey via leur API d'authentificateur de plateforme.

Google : Passkeys du Gestionnaire de Mots de Passe

Le Google Password Manager synchronise désormais les passkeys sur Android et Chrome sur n'importe quelle plateforme, y compris Windows et macOS. La synchronisation est chiffrée de bout en bout avec le code PIN du compte Google de l'utilisateur. Un ajout significatif en 2024 : Google a commencé à prendre en charge l'exportation de passkeys dans certains flux et a ajouté le support des passkeys à leur Programme de Protection Avancée — auparavant le domaine exclusif des clés de sécurité physiques.

Windows Hello

Windows Hello fournit des passkeys liées à un appareil, attachées à la puce TPM et déverrouillées par reconnaissance faciale, empreinte digitale ou code PIN. L'implémentation de Microsoft est étroitement intégrée au magasin d'identifiants Windows. Dans les environnements d'entreprise, Windows Hello for Business étend cela à l'authentification par certificat avec Entra ID, permettant des flux sans mot de passe dans les environnements d'entreprise gérés.

Gestionnaires de Mots de Passe Tiers

1Password et Bitwarden ont tous deux ajouté le stockage de passkeys en 2023-2024, traitant les passkeys comme un nouveau type d'identifiant aux côtés des mots de passe. C'est significatif : cela dissocie le stockage des passkeys des fournisseurs de plateforme, permet une utilisation multiplateforme des passkeys sans enfermement chez Google ou Apple, et donne aux entreprises un chemin pour gérer les passkeys dans l'infrastructure de coffre existante. L'implémentation open-source de Bitwarden a été auditée de manière indépendante.

Les Problèmes Difficiles qui Persistent

Perte d'Appareil et Récupération de Compte

La perte d'appareil est l'obstacle émotionnel le plus important à l'adoption des passkeys. La bonne réponse — et celle qui nécessite une éducation explicite de l'utilisateur — est d'enregistrer plusieurs passkeys sur différents appareils ou authentificateurs avant d'en avoir besoin. Enregistrez une passkey sur votre téléphone, votre ordinateur portable et une clé matérielle rangée dans un endroit sûr. La plupart des services qui implémentent bien les passkeys invitent à cela. Mais la réalité est que la plupart des utilisateurs n'enregistrent qu'une seule passkey et ne découvrent le problème de récupération que lorsque leur appareil a disparu.

Pour les passkeys synchronisées, iCloud Keychain et Google Password Manager ont tous deux des mécanismes de récupération de compte. Si vous perdez votre iPhone mais pouvez récupérer votre compte iCloud (via une clé de récupération ou un appareil de confiance), vous récupérez vos passkeys. Cela déplace la frontière de sécurité de la possession de l'appareil à la sécurité du compte — ce qui peut être une régression si votre compte iCloud ou Google a une sécurité faible. La solution est de traiter votre compte cloud principal comme une racine de haute sécurité : une clé de récupération forte, une 2FA matérielle, rien de plus faible.

Déploiement en Entreprise : Active Directory et LDAP

Les environnements d'entreprise présentent une complexité réelle. Les applications héritées qui s'authentifient via Active Directory ou LDAP ne parlent pas WebAuthn. Relier les passkeys à ces environnements nécessite soit une fédération via un fournisseur d'identité (Entra ID, Okta, Ping Identity) qui peut traduire l'authentification WebAuthn en jetons SAML ou OIDC, soit attendre la modernisation des applications. La plupart des grandes entreprises sont dans un état hybride : passkeys pour les applications cloud-native et les portails SSO, mots de passe ou cartes à puce pour les applications métier héritées. Le déploiement complet des passkeys en entreprise est un programme pluriannuel, pas un simple interrupteur de configuration.

Interopérabilité Android/iOS

L'utilisation de passkeys multiplateforme — se connecter sur un appareil iOS avec une passkey stockée sur un téléphone Android, ou vice versa — fonctionne via le transport hybride CTAP2 (flux de code QR de proximité Bluetooth). En pratique, cela fonctionne de manière fiable lorsque les deux appareils sont modernes, le Bluetooth est activé et l'utilisateur comprend ce qu'il fait. Ce n'est pas transparent pour les utilisateurs moins techniques et ajoute des frictions dans des scénarios comme emprunter l'appareil de quelqu'un d'autre. C'est un domaine où l'expérience utilisateur est encore en retard sur la capacité cryptographique sous-jacente.

Appareils Hérités sans Données Biométriques

Les passkeys nécessitent une certaine forme de vérification de l'utilisateur — données biométriques (empreinte digitale, visage) ou un code PIN d'appareil. Les appareils sans capteurs biométriques peuvent utiliser un code PIN, mais un code PIN court sur un vieil appareil Android est une vérification d'utilisateur plus faible que Face ID. Les clés de sécurité matérielles (clés FIDO2 avec code PIN + toucher) résolvent ce problème pour les utilisateurs prêts à en porter une, mais l'adoption parmi les utilisateurs non techniques est minime.

Le Point de Vue du Développeur : Implémenter WebAuthn

Si vous construisez l'authentification, l'implémentation de WebAuthn est maintenant bien supportée. Les bibliothèques matures et activement maintenues en 2026 incluent :

• SimpleWebAuthn (TypeScript/Node.js) — la bibliothèque JS la plus utilisée, gère à la fois l'enregistrement et l'authentification, excellente documentation, gère la cérémonie correctement, y compris la vérification du défi et les modèles de stockage d'identifiants.
• py_webauthn (Python) — l'implémentation Python de référence, utilisée dans la pile de Duo Security, supporte à la fois FIDO2 et l'ancien U2F pour la compatibilité ascendante.
• webauthn4j (Java) — la bibliothèque Java mature utilisée par le support WebAuthn de Spring Security ; gère la validation d'attestation, l'intégration du service de métadonnées et fonctionne bien dans les applications Spring Boot.
• go-webauthn/webauthn (Go) — l'implémentation Go standard, API propre, activement maintenue.

La compatibilité des navigateurs n'est plus un problème pour l'API WebAuthn de base : Chrome 67+, Firefox 60+, Safari 14+ et Edge 18+ la supportent tous. L'écart de compatibilité restant concerne l'UI conditionnelle (invites de passkey pilotées par l'autocomplétion), qui nécessite des versions de navigateur légèrement plus récentes mais est maintenant largement déployée.

Erreurs d'implémentation clés à éviter : ne pas lier le défi à la session côté serveur (vecteur d'attaque par rejeu), ne pas vérifier le rpId et l'origine dans la validation côté serveur, sauter la validation d'attestation dans les contextes de haute sécurité, et ne pas implémenter les flux d'enregistrement multi-appareils dès le départ.

Recommandations Pratiques

Activez les passkeys d'abord sur vos comptes les plus importants, dans cet ordre de priorité :

• Fournisseur de messagerie — votre email est le mécanisme de récupération pour tout le reste. Un compte email compromis a des répercussions sur tous les autres comptes. Activez les passkeys sur Gmail ou iCloud Mail immédiatement.
• Gestionnaire de mots de passe — si votre gestionnaire de mots de passe prend en charge la connexion par passkey (1Password et Bitwarden le font), activez-la. C'est la clé maîtresse de votre coffre d'identifiants.
• Comptes financiers — les banques et court