Ce qu’il faut retenir
- Une passkey protège l’authentification grâce à une clé cryptographique liée au service. Elle ne sécurise pas automatiquement toute la vie du compte.
- La perte d’un appareil, la récupération et l’ajout d’une nouvelle clé demandent une politique explicite.
- Pour un compte sensible, les opérations de récupération doivent produire une preuve, une notification et, selon le risque, une restriction temporaire.
Le bouton « Se connecter avec une passkey » règle une partie visible du parcours. Le jour où le téléphone disparaît, la décision se déplace vers le support et les options de secours. Si une simple réponse à un courriel suffit à remplacer toutes les clés, la robustesse de la connexion habituelle ne protège plus le compte. Le produit doit donc concevoir l’enrôlement, l’authentification et la récupération comme un même système.
Ce que la clé prouve exactement
Une passkey repose sur une paire de clés : le service conserve la clé publique, tandis qu’un authentificateur détient la clé privée. Le standard WebAuthn du W3C encadre l’utilisation de ces identifiants par le navigateur. Le serveur vérifie notamment la réponse à un défi et son rattachement au service attendu. Un site frauduleux ne peut pas simplement obtenir la même preuve en imitant l’écran de connexion.
Le déverrouillage local peut employer un code ou une biométrie. Le service n’a pas besoin de recevoir l’empreinte digitale pour vérifier la réponse cryptographique. Le choix entre une clé liée à un appareil et une clé synchronisée change toutefois les dépendances : la synchronisation facilite le changement d’appareil, mais renvoie aussi à la sécurité et aux procédures de récupération du compte du fournisseur concerné.
La FIDO Alliance présente ces modes d’authentification et leur résistance au phishing. Il faut limiter cette promesse à l’authentification correctement mise en œuvre. Une session déjà volée, une autorisation métier trop large ou une récupération trompée restent des chemins d’attaque. Les risques liés aux agents logiciels illustrent cette distinction : savoir qui se connecte ne décide pas de ce qu’il peut faire.
Préparer trois parcours distincts
Enregistrer une clé quand le compte est encore maîtrisé
L’ajout d’une clé est une action sensible : il donne un accès durable à son détenteur. Le produit demande une authentification récente et vérifie le contexte selon le risque. Il présente un nom lisible pour chaque clé, sa date de création et un moyen de la retirer. Il évite d’afficher des détails techniques inutiles tout en permettant à l’utilisateur de distinguer son téléphone et sa clé physique.
Un service B2B peut recommander une seconde clé indépendante pour les administrateurs. « Deux clés » ne signifie pas nécessairement « deux moyens de secours » si elles dépendent du même compte de synchronisation. La question utile porte sur les pannes communes : appareil perdu, fournisseur inaccessible, compte de synchronisation bloqué, clé physique cassée. Le parcours d’inscription doit faire comprendre ce risque sans transformer chaque connexion en cours de cryptographie.
Récupérer avec des preuves proportionnées
La récupération n’a pas une règle universelle. Un forum et un compte qui autorise des virements n’ont pas les mêmes conséquences d’une usurpation. Définir les preuves acceptables, le rôle du support et les opérations gelées après récupération produit une décision lisible. Les codes de secours, s’ils existent, sont secrets, à usage unique et conservés sous une forme adaptée côté serveur ; ils ne doivent pas devenir des mots de passe permanents recopiés dans des tickets.
Une adresse électronique prouve un accès à une boîte, pas nécessairement l’identité de la personne ni son droit actuel sur une entreprise. Un support peut confronter plusieurs signaux, mais une connaissance d’informations publiques ne constitue pas une preuve forte. Les exceptions destinées à aider un client pressé doivent avoir un chemin documenté, avec un contrôle renforcé pour les comptes à pouvoir élevé.
Traiter les sessions après la récupération
Remplacer une clé ne ferme pas toujours les sessions existantes. Le service doit décider lesquelles révoquer, comment demander une nouvelle authentification et comment notifier les autres canaux déjà enregistrés. Une alerte décrit l’événement et le moyen de le contester, sans exposer de secret. Pour les opérations les plus sensibles, une restriction temporaire ou une validation indépendante peut réduire le risque après un changement de moyen d’accès.
Un administrateur perd son téléphone
Exemple hypothétique : une PME utilise un SaaS pour gérer ses contrats. Son administratrice perd le téléphone contenant sa passkey synchronisée. Elle dispose aussi d’une clé physique enregistrée auparavant. Elle se connecte avec cette clé, retire l’identifiant du téléphone si nécessaire, examine les sessions actives et ajoute un nouveau moyen d’accès après vérification. La continuité ne dépend pas d’un agent de support persuadé par téléphone.
Si aucun moyen de secours ne subsiste, le dossier passe dans une procédure de récupération dédiée. Dans ce scénario, l’organisation a désigné deux administrateurs et peut confirmer la demande par l’autre compte. Le service ne suppose pas que toutes les PME peuvent fournir cette preuve : les comptes individuels ont un autre parcours. La différence doit être définie au contrat produit, puis testée avec le support.
Les décisions à écrire avant la première perte d’appareil
| Événement | Question produit | Contrôle attendu |
|---|---|---|
| Ajout d’une clé | Qui autorise l’accès durable ? | Authentification récente et notification |
| Retrait du dernier moyen | Le compte restera-t-il récupérable ? | Alternative vérifiée ou procédure explicite |
| Récupération manuelle | Quelle preuve justifie l’exception ? | Trace, validation proportionnée et restrictions |
| Suspicion de vol de session | Quels accès restent actifs ? | Révocation et réauthentification |
Tester ce que le parcours normal ne révèle pas
La recette inclut le changement de navigateur, l’utilisation d’un appareil sans synchronisation, l’annulation d’une demande, un compte avec plusieurs clés et un compte sans secours. Elle vérifie que les messages restent compréhensibles et que le clavier permet de terminer l’action. L’échec de connexion ne doit pas divulguer inutilement l’existence d’un compte. Le support doit connaître le résultat attendu pour chaque cas.
Des tests d’abus confrontent une demande de récupération simultanée à une connexion légitime, un lien expiré, un code déjà consommé et une tentative de réutilisation d’une session révoquée. Le serveur, pas seulement l’interface, applique les règles. La cohérence entre API et interfaces intégrées est essentielle : une route oubliée peut autoriser l’ajout d’une clé sans le contrôle visible sur le web.
Mesurer l’adoption sans cacher le coût du secours
Le taux de connexion réussie, l’abandon et les demandes de récupération sont des indicateurs complémentaires. Séparer le premier enrôlement, les connexions suivantes et la récupération évite une moyenne flatteuse qui masque un parcours bloquant. Comparer les utilisateurs et les appareils selon des critères nécessaires au diagnostic, avec une collecte limitée, rend le résultat interprétable.
La réduction de la saisie peut améliorer le parcours, mais elle ne justifie pas une promesse de conversion chiffrée sans mesure locale. L’approche rejoint les questions de mesure de la conversion : identifier l’étape qui échoue et valider un changement concret. La prochaine amélioration utile consiste à jouer une perte totale de moyens d’accès avec le support et à vérifier qu’il sait aider sans contourner la politique.
Sources et références
Mise à jour du 1er octobre 2026 : références vérifiées à cette date. Les mécanismes décrits sont durables ; les options exactes restent à vérifier dans la version du produit utilisée.
- W3C — Web Authentication, Level 2 (2021) — modèle de clé publique et vérification par le service
- FIDO Alliance — Passkeys — terminologie et parcours d’authentification
