Passkeys en entreprise : migrer sans bloquer les comptes

Les passkeys en entreprise, ou clés d’accès, peuvent remplacer le mot de passe par une preuve cryptographique liée au bon site ou à la bonne application. Elles réduisent le risque d’hameçonnage et simplifient souvent la connexion. Mais ajouter un bouton « Se connecter avec une clé d’accès » ne suffit pas à réussir la migration.

Le chantier utile porte sur le parcours complet : créer une clé au bon moment, la retrouver sur un autre appareil, gérer plusieurs clés, réautoriser une action sensible, supprimer un accès, récupérer un compte et assister une personne bloquée. Avant de retirer le mot de passe, chaque situation doit avoir une règle serveur, une preuve observable et un chemin de secours qui ne recrée pas la faiblesse supprimée.

La recommandation WebAuthn Level 3, publiée par le W3C le 25 août 2026, stabilise le socle normatif. Elle donne un meilleur point de départ aux équipes. Elle ne remplace ni le cadrage produit, ni la vérification de la compatibilité réelle des navigateurs, systèmes, gestionnaires d’identifiants et bibliothèques retenus.

Qu’est-ce qu’une passkey et que protège-t-elle ?

Une passkey est un identifiant fondé sur une paire de clés. La clé privée reste gérée par l’appareil, une clé de sécurité ou un gestionnaire d’identifiants. Le service conserve la clé publique et l’utilise pour vérifier une réponse signée à un défi unique. Il ne reçoit ni le code de déverrouillage du terminal, ni les données biométriques utilisées localement.

WebAuthn limite aussi l’identifiant à une partie de confiance, appelée relying party, généralement liée au domaine du service. Une passkey créée pour un domaine ne peut pas être présentée à un faux domaine qui lui ressemble. Cette liaison fournit la résistance à l’hameçonnage que n’offre pas un code recopiable.

Il faut néanmoins distinguer trois décisions souvent confondues :

• authentifier le compte, ce que vérifie le serveur avec la clé publique ;
• déverrouiller la passkey, ce que le terminal ou le gestionnaire contrôle localement avec une biométrie, un code ou un autre mécanisme ;
• autoriser une action sensible, ce que l’application peut encore soumettre à une règle, un niveau de confiance ou une nouvelle vérification.

Une biométrie locale déjà présente dans une application n’est donc pas automatiquement une passkey. Elle peut seulement rouvrir une session ou déverrouiller un secret stocké sur le téléphone. Inversement, une passkey ne décide pas à elle seule si une personne peut changer un RIB, publier une campagne ou exporter des données.

Ce que change WebAuthn Level 3 pour une entreprise

Le passage de WebAuthn Level 3 au statut de recommandation du W3C transforme une spécification mouvante en référence normative stable. La FIDO Alliance résume plusieurs capacités formalisées : médiation conditionnelle pour mieux intégrer les passkeys aux parcours existants, indicateurs distinguant identifiants synchronisables et liés à un appareil, API de signaux pour rapprocher l’état du serveur et celui du gestionnaire, détection des capacités et gestion de domaines liés.

Ces capacités ne doivent pas devenir une liste de fonctionnalités à activer. Elles répondent à des frictions précises :

• proposer une passkey sans ajouter un choix incompréhensible à l’écran de connexion ;
• savoir si la continuité dépend d’une synchronisation ou d’un appareil précis ;
• éviter qu’une passkey supprimée côté serveur continue d’apparaître comme valide dans un gestionnaire ;
• adapter l’expérience aux capacités réellement disponibles ;
• traiter un produit réparti sur plusieurs domaines sans affaiblir la portée de l’identifiant.

La recommandation W3C du 25 août 2026 ne garantit toutefois pas que chaque capacité soit déployée de la même manière partout. L’application doit détecter ce qu’elle peut utiliser, conserver un comportement compréhensible en cas d’absence et tester les combinaisons réellement employées par son public.

Pourquoi la migration est un projet produit, pas un remplacement de champ

Le mot de passe concentre plusieurs usages : première connexion, reprise sur un nouvel appareil, assistance, réinitialisation et parfois réautorisation. Le retirer révèle toutes les décisions que ce mécanisme masquait.

Le bon moment pour créer la clé

Les parcours recommandés par Google proposent notamment la création pendant ou après une connexion réussie, dans les paramètres de sécurité, après une récupération ou après une réautorisation. Le point commun est un niveau de confiance déjà établi. Une simple session ancienne ne doit pas permettre silencieusement d’ajouter une nouvelle méthode d’accès durable.

Le produit doit aussi traiter l’annulation et l’échec. Si la boîte de dialogue système est fermée, la personne doit comprendre que rien n’a été créé, pouvoir continuer sa tâche et retrouver plus tard une action claire. Une invitation répétée à chaque visite transforme rapidement un gain de simplicité en obstacle.

La continuité entre appareils

Certaines passkeys sont synchronisées par un gestionnaire ; d’autres restent liées à un appareil ou à une clé physique. Un téléphone peut également approuver une connexion sur un ordinateur proche. Ces chemins ne sont pas interchangeables pour l’utilisateur, le support ou la sécurité.

La page de gestion doit donc nommer les clés disponibles, leur provenance lorsque celle-ci est connue, leur date de création ou de dernière utilisation et la manière de les supprimer. Les informations techniques telles que l’AAGUID peuvent aider à présenter le fournisseur, mais ne doivent pas être transformées sans attestation en preuve absolue sur le terminal.

La récupération du compte

Une migration vers les passkeys ne supprime pas la récupération. Elle oblige à la concevoir. Si l’e-mail ou le téléphone permet de recréer immédiatement une passkey après un contrôle faible, ce chemin devient le véritable niveau de sécurité du compte.

La récupération doit répondre à quatre questions : quel événement la déclenche, quelles preuves sont nécessaires, quelles actions sont temporairement limitées et comment l’utilisateur est informé. Pour un compte sensible, la reprise peut imposer un délai, une validation supplémentaire ou une intervention du support. Pour un service à faible risque, un lien d’accès peut être proportionné. Le choix dépend des conséquences d’une prise de contrôle, pas du prestige de la technologie.

La matrice Zence : relier parcours, terminal et preuve

Une migration pilotée uniquement par le taux d’activation risque d’augmenter le nombre de clés tout en laissant les cas difficiles au support. La matrice suivante donne un propriétaire et une preuve à chaque situation.

Parcours	Terminal ou source	Niveau de confiance attendu	Preuve observable	Secours	Responsable
créer une première passkey	appareil déjà connecté	session récente ou réautorisation	clé publique enregistrée et notification envoyée	reprendre sans bloquer la tâche	produit et identité
se connecter	même écosystème	vérification utilisateur conforme à la règle	défi unique validé, origine et compteur contrôlés selon le contexte	autre passkey ou méthode autorisée	backend identité
utiliser un autre appareil	synchronisation ou appareil proche	consentement sur l’appareil détenteur	connexion attribuée au bon compte	clé physique ou récupération	produit et support
ajouter une nouvelle clé	paramètres de sécurité	réautorisation récente	nouvelle clé nommée et visible	annulation réversible	produit
supprimer une clé	page de gestion	session forte	clé publique refusée côté serveur	conserver au moins un accès viable	identité
exécuter une action sensible	web ou mobile	niveau adapté au risque	nouvelle vérification et décision journalisée	contrôle humain ou autre facteur	métier et sécurité
récupérer le compte	aucun accès utilisable	preuve proportionnée à l’impact	reprise, restrictions et notification tracées	support encadré	support et sécurité
quitter l’entreprise	appareil ou clé professionnelle	décision administrative vérifiée	sessions et identifiants révoqués	transfert de responsabilité documenté	administration

La preuve ne doit pas contenir de clé privée, de donnée biométrique ni de secret. Elle décrit un événement utile au diagnostic : identifiant technique pseudonymisé, résultat, méthode, contexte, date, version et éventuel motif de refus. Le niveau de détail doit rester proportionné à la sécurité et à la protection des données.

Dix scénarios de recette avant de retirer le mot de passe

La recette doit combiner navigateurs, systèmes et gestionnaires représentatifs du parc réel. Une démonstration réussie sur l’ordinateur de l’équipe ne prouve pas le parcours d’une personne qui change de téléphone ou perd son seul accès.

1. Créer une première passkey après une connexion forte. Vérifier le succès, l’annulation, le doublon et la notification de sécurité.
2. Se connecter avec la saisie automatique. Confirmer que l’option apparaît sans masquer les méthodes encore nécessaires pendant la transition.
3. Utiliser une passkey synchronisée sur un second appareil. Vérifier le bon compte, le nom affiché et l’absence de ressaisie inutile.
4. Se connecter depuis un appareil qui ne possède pas la clé. Tester le parcours avec un téléphone proche, puis son annulation et l’indisponibilité du Bluetooth ou du réseau.
5. Gérer plusieurs passkeys. Créer, renommer ou distinguer les entrées, puis supprimer une seule clé sans bloquer les autres.
6. Supprimer la clé côté service. Google précise que retirer la clé publique du serveur ne supprime pas automatiquement la clé privée du gestionnaire ; le produit doit expliquer l’état et utiliser les signaux compatibles sans les supposer universels.
7. Perdre le dernier appareil disponible. Exécuter la récupération complète, mesurer son délai et contrôler les actions sensibles après la reprise.
8. Réautoriser une action à fort impact. Tester la règle lorsque la vérification utilisateur est disponible, refusée ou insuffisante pour le niveau demandé.
9. Révoquer un compte professionnel. Retirer sessions, clés et droits, puis confirmer qu’un appareil ancien ne rouvre pas le service.
10. Rejouer les états dégradés. Bibliothèque indisponible, défi expiré, heure incohérente, origine non autorisée, navigateur sans capacité attendue et journal incomplet doivent produire une erreur compréhensible et exploitable.

Chaque scénario se termine par un statut : passé avec preuve, bloqué avec responsable et date, ou non applicable avec justification. Cette discipline transforme l’authentification en propriété vérifiable du produit.

Faut-il construire, acheter ou déléguer l’authentification ?

La bonne décision dépend moins du nombre de comptes que du coût d’une erreur et de la spécificité des règles.

Acheter un service d’identité est souvent pertinent lorsque les parcours sont standards, que le fournisseur couvre les plateformes visées et que l’équipe veut transférer une partie de l’exploitation. Il faut néanmoins vérifier export, tarification, disponibilité, journaux, domaines, politiques de récupération et procédure de sortie.

Intégrer une bibliothèque WebAuthn maintenue peut convenir lorsqu’un backend existant porte déjà l’identité et que l’équipe maîtrise les défis, origines, sessions, révocations et mises à jour de sécurité. La documentation serveur de Google recommande d’utiliser une bibliothèque plutôt que de réimplémenter le protocole sans nécessité.

Construire des règles propres devient justifié lorsque l’identité dépend de rôles métier, d’organisations multiples, d’appareils administrés, de délégations ou d’actions très sensibles. Même dans ce cas, le cœur cryptographique doit reposer sur des standards et des composants éprouvés. Le sur-mesure porte sur la politique, l’expérience et l’intégration, pas sur l’invention d’un nouveau protocole.

Pour une application Apple, la documentation d’Authentication Services rappelle notamment la liaison entre l’application, son domaine associé et l’identifiant de la partie de confiance. Un prototype qui fonctionne sur le web ne prouve donc pas automatiquement le parcours natif ou une WKWebView.

Cette décision prolonge le choix entre logiciel standard, no-code et sur-mesure : comparez le coût complet, la maîtrise des règles, la sortie et la responsabilité d’exploitation, pas seulement le prix de l’écran de connexion.

Déployer progressivement sans créer deux systèmes éternels

Une migration saine commence par l’observation. Mesurez les connexions réussies, les échecs par étape, les récupérations, les contacts support et les appareils réellement utilisés. Cette référence permet de savoir si les passkeys retirent une friction ou la déplacent.

Ouvrez ensuite la création à un groupe interne ou volontaire. Conservez temporairement les méthodes existantes, mais définissez leur règle de retrait avant le pilote : taux de réussite stable, parcours de récupération éprouvé, support formé, couverture suffisante des environnements et absence d’incident non expliqué.

Étendez par segment plutôt que par pourcentage arbitraire. Les comptes administrateurs, les équipes terrain, les clients utilisant des postes partagés et le grand public n’ont pas les mêmes terminaux ni les mêmes conséquences en cas de blocage. Une passkey synchronisée peut être idéale pour un compte personnel et inadaptée à une fonction qui exige un identifiant lié à un appareil administré.

Qui tranche les cas limites ?

Avant le pilote, désignez une personne capable d’arbitrer entre produit, sécurité, support et métier. Elle ne valide pas seule la cryptographie : elle décide quel parcours reste acceptable lorsqu’un appareil manque, qu’une vérification échoue ou qu’une récupération contredit une règle d’accès. Chaque exception doit préciser sa durée, son propriétaire, les actions encore autorisées et la preuve conservée.

Le support a besoin d’un diagnostic lisible, pas d’un accès aux secrets. Une fiche courte peut indiquer l’étape atteinte, la capacité détectée, la méthode proposée, le résultat serveur et la prochaine action sûre. Les demandes répétées deviennent alors un signal produit mesurable. Si un cas n’a ni règle, ni preuve, ni responsable, il ne doit pas être masqué par une reprise manuelle improvisée : il reste bloquant pour le retrait du mot de passe.

Enfin, retirez le mot de passe seulement lorsque son remplacement complet est prouvé. Le laisser indéfiniment comme secours maintient sa surface d’attaque ; le supprimer trop tôt crée des reprises manuelles risquées. La transition doit avoir une date de revue, un propriétaire et une condition de retour limitée.

Les limites à garder visibles

Les passkeys résistent à l’hameçonnage grâce à leur liaison au service, mais elles ne corrigent pas un terminal compromis, une session déjà volée, des droits excessifs ou une récupération faible. Elles réduisent la valeur d’une fuite de base de mots de passe, sans rendre inutile la protection des clés publiques, des sessions, des journaux et des comptes d’administration.

Pour un éditeur, un intégrateur ou un support qui intervient depuis l’extérieur, la recette des accès distants au logiciel métier complète l’authentification par des droits temporaires, des seuils et des alertes exploitables.

Le vocabulaire mérite aussi de rester précis. Une clé « synchronisable » n’est pas forcément synchronisée au moment du test. Une passkey liée à un appareil protège différemment la continuité. Une information de fournisseur améliore la gestion, mais ne constitue pas toujours une attestation de confiance. Une capacité définie dans Level 3 doit encore être détectée et éprouvée dans les environnements supportés.

La migration réussie n’est donc pas celle qui affiche le plus vite un nouveau bouton. C’est celle qui réduit une faiblesse sans transférer l’incertitude vers la récupération et le support.

Commencer par la plus petite preuve complète

Le premier livrable peut rester court : l’inventaire des méthodes actuelles, la matrice des huit parcours, un prototype de création et de gestion, puis trois scénarios exécutés de bout en bout — connexion, second appareil et perte du dernier accès. Cette preuve révèle si le risque principal vient du navigateur, du mobile, du serveur, de la politique de sécurité ou du support.

Zence conçoit des logiciels métier sur mesure et des applications iOS et Android en reliant identité, parcours, architecture et exploitation. Pour cadrer une transition adaptée au parc et au risque réel, faites relire votre migration vers les passkeys.

Sources officielles et techniques

• W3C — Web Authentication Level 3, recommandation publiée le 25 août 2026.
• FIDO Alliance — WebAuthn Level 3 devient une recommandation W3C, publié le 31 août 2026 au sujet de l’événement du 25 août.
• Google for Developers — parcours utilisateur des clés d’accès, création, connexion, gestion et récupération.
• Google for Developers — créer une passkey, enregistrement, capacités, états d’erreur et API de signaux.
• Apple Developer — prendre en charge les passkeys, application, domaine associé, création, connexion et réinitialisation.
• Microsoft Learn — API WebAuthn pour l’authentification sans mot de passe, Windows Hello, clés de sécurité et gestionnaires de passkeys.