Supprimer un mot de passe ne supprime pas toutes les possibilités de vol de compte. Une entreprise peut déployer des passkeys puis conserver une récupération par e-mail trop permissive, un ancien accès par mot de passe ou des sessions impossibles à révoquer. L’entrée principale devient plus solide ; la porte de secours reste ouverte.
Les passkeys apportent pourtant un changement important : l’authentification repose sur des clés cryptographiques, plutôt que sur un secret que l’utilisateur transmet au site. Leur intérêt devient concret quand le déploiement couvre le cycle de vie complet du compte, du premier équipement au départ du salarié.
Avant d’acheter des clés physiques ou d’envoyer une consigne générale, il faut donc choisir un modèle, tester les situations réelles et organiser les exceptions. La sécurité se joue autant dans ces décisions que dans le bouton de connexion.
En bref — Une passkey repose sur une paire de clés liée au service concerné. Elle peut être synchronisée entre des appareils ou rester attachée à un dispositif, selon l’implémentation. Sa résistance au hameçonnage ne protège pas automatiquement les sessions, l’appareil ni la récupération. Le pilote doit inclure perte, remplacement, accès d’urgence et départ d’un collaborateur.
Ce qui change réellement lors de la connexion
Avec un mot de passe traditionnel, le site vérifie un secret partagé. Un utilisateur peut le saisir sur une page frauduleuse qui ressemble à la page légitime. Une passkey suit une autre logique : le service conserve une clé publique, tandis que l’authentificateur utilise la clé privée pour répondre à un défi.
Le protocole WebAuthn lie cette opération au contexte du service, notamment à son identifiant et à l’origine web vérifiée. Cette liaison constitue un élément central de la résistance au hameçonnage. Une imitation visuelle du formulaire ne suffit pas à obtenir une réponse réutilisable pour un autre service.
Selon le dispositif et sa configuration, l’utilisateur confirme l’opération avec un code local, une donnée biométrique ou une clé matérielle. La donnée biométrique utilisée localement ne devient pas un mot de passe transmis au serveur du site. Il faut néanmoins vérifier le comportement réel des équipements retenus.
Une authentification résistante au hameçonnage ne rend pas toutes les attaques impossibles. Un logiciel malveillant sur l’appareil peut menacer les sessions ou les données déjà accessibles. Un mauvais contrôle des droits peut exposer une ressource après une connexion parfaitement valide. Les passkeys traitent une partie précise de la chaîne.
L’important est de ne pas leur attribuer des propriétés absentes de la configuration. Toutes les opérations ne démontrent pas automatiquement plusieurs facteurs avec le niveau exigé par votre politique. Les exigences de vérification de l’utilisateur, l’authentificateur choisi et les règles du fournisseur d’identité doivent être examinés ensemble.
Synchronisées ou attachées à un dispositif : un choix d’exploitation
Une passkey synchronisée facilite l’usage sur plusieurs appareils compatibles à travers un mécanisme de synchronisation. Une passkey attachée à un dispositif ne se déplace pas de la même manière ; perdre ce dispositif peut nécessiter un autre moyen enregistré ou une procédure de récupération.
Le premier modèle privilégie souvent la continuité d’usage. Le second peut correspondre à des exigences de contrôle plus strictes. Il n’existe pas de choix automatiquement supérieur pour chaque salarié : la décision dépend du niveau de risque, des appareils gérés et de la capacité d’assistance.
| Situation à examiner | Question opérationnelle | Point à vérifier pendant le pilote |
|---|---|---|
| Salarié équipé par l’entreprise | Les appareils et comptes associés sont-ils maîtrisés ? | Enregistrement et retrait selon la politique interne |
| Utilisateur sur plusieurs terminaux | Le même moyen peut-il être retrouvé partout ? | Compatibilité et fonctionnement de la synchronisation |
| Administrateur privilégié | Quel niveau de protection et de traçabilité est demandé ? | Moyen dédié, secours, restriction des anciennes méthodes |
| Poste partagé | Comment éviter l’enregistrement au mauvais compte local ? | Parcours de connexion et déconnexion entre utilisateurs |
| Appareil perdu | Quel autre moyen donne accès sans abaisser la sécurité ? | Identification, révocation et nouvel enregistrement |
Les appareils personnels posent aussi une question de responsabilité. Quel compte héberge la synchronisation ? L’entreprise peut-elle gérer le départ de l’utilisateur sans accéder à son espace privé ? Le dispositif respecte-t-il la politique de traitement des données et de gestion des équipements ? Ces réponses doivent être posées avant le déploiement.
Une clé matérielle peut constituer un moyen de secours utile. Elle ajoute toutefois un inventaire, une distribution, des remplacements et des situations de perte. Son coût n’est pas seulement son prix d’achat.
Commencer par l’inventaire des chemins de connexion
Un salarié ne passe pas toujours par le même portail. Il peut utiliser une application mobile, un client ancien, une interface administrateur ou un accès direct au logiciel. Renforcer uniquement la page d’authentification centrale laisse parfois subsister des chemins historiques.
Inventoriez les applications, les méthodes autorisées et les comptes qui contournent l’identité fédérée. Distinguez utilisateurs humains, comptes techniques et intégrations automatiques. Une passkey destinée à une personne ne remplace pas la gestion des secrets ou certificats d’un traitement serveur.
Pour chaque application, vérifiez le parcours complet : connexion initiale, réauthentification d’une action sensible, ouverture depuis un téléphone, expiration de session et retour après une longue absence. Une compatibilité annoncée avec WebAuthn ne suffit pas à décrire l’expérience dans votre environnement.
Les comptes privilégiés méritent une revue spécifique. Ils peuvent détenir la capacité de créer des utilisateurs, modifier des politiques ou rétablir d’autres moyens de connexion. Une procédure de secours sur ces comptes doit être particulièrement contrôlée et journalisée.
Cette démarche rejoint la gouvernance des accès aux usages numériques sensibles : une bonne méthode d’authentification n’a de valeur que si les droits attribués restent cohérents avec les tâches.
Préparer l’enregistrement sans transférer le risque au support
L’enregistrement d’une nouvelle passkey est une opération sensible. Si un attaquant déjà connecté peut ajouter son propre moyen sans contrôle adapté, il peut pérenniser un accès frauduleux. Définissez donc les conditions d’enregistrement et les notifications associées.
Pour un nouvel arrivant, vérifiez l’identité à travers le processus prévu par l’entreprise. Pour un utilisateur existant, prévoyez une réauthentification appropriée et une surveillance des changements de moyens. Les règles exactes dépendent du système d’identité et du niveau de risque, mais elles doivent être explicites.
La communication doit expliquer la différence entre code local, compte de synchronisation et service professionnel. Les utilisateurs n’ont pas besoin d’un cours de cryptographie. Ils doivent savoir quel écran est attendu, où leur moyen est enregistré et qui contacter lorsqu’un comportement paraît inhabituel.
Pendant le pilote, observez les erreurs concrètes : mauvais profil de navigateur, appareil incompatible, tentative sur un poste partagé, confusion entre deux comptes. Ces incidents révèlent les besoins de documentation bien mieux qu’un questionnaire général sur la facilité d’utilisation.
Ne désactivez pas tous les anciens moyens avant d’avoir testé les parcours nécessaires. À l’inverse, maintenir indéfiniment un mot de passe faiblement protégé peut réduire l’intérêt du changement. La transition doit avoir des critères de sortie, un calendrier et des exceptions identifiées.
La récupération est une nouvelle authentification
Une récupération permissive peut annuler les protections de la connexion normale. Si un simple appel au support suffit à remplacer une passkey, l’attaquant cherchera ce parcours plutôt que de casser la cryptographie.
Il faut définir comment la personne est reconnue, quels éléments sont vérifiés, qui autorise l’opération et quelles notifications sont envoyées. La disponibilité immédiate d’une adresse e-mail ou la connaissance d’une information publique ne constituent pas, à elles seules, une politique robuste.
Séparez les scénarios. Un utilisateur qui possède encore un second moyen enregistré n’est pas dans la même situation qu’un utilisateur qui a perdu tous ses équipements. Un administrateur avec des droits étendus mérite un traitement différent d’un compte à faible privilège.
Pour les situations sensibles, une validation additionnelle ou un délai peut être approprié, mais doit être compatible avec la continuité du travail. Documentez les exceptions et leurs contrôles compensatoires. L’urgence ne doit pas produire un procédé informel que chacun adapte au téléphone.
Le test de récupération doit aboutir à une preuve : l’utilisateur légitime retrouve l’accès, le moyen perdu est retiré selon la politique et les traces permettent de reconstruire la décision. Mesurez également le temps mobilisé par le support. Un parcours fiable mais totalement ingérable à grande échelle demandera une adaptation.
Perdre un appareil ne ferme pas automatiquement toutes les sessions
Retirer une passkey empêche l’usage de ce moyen dans les conditions prévues par le service. Cela ne signifie pas nécessairement que toutes les sessions déjà ouvertes sont terminées. Authentificateurs, sessions, jetons d’accès et autorisations applicatives ont des cycles de vie différents.
Préparez une procédure de perte d’appareil qui examine chacun de ces éléments. Peut-on révoquer les sessions du fournisseur d’identité ? Les applications fédérées appliquent-elles immédiatement cette révocation ? Des jetons autonomes restent-ils valides ? Les réponses doivent être vérifiées avec les systèmes concernés.
Le départ d’un salarié exige la même vision complète : désactivation du compte, retrait des droits, traitement des moyens enregistrés, récupération des équipements et examen des accès non fédérés. Il faut également distinguer les données professionnelles des comptes personnels associés au dispositif.
La documentation de réversibilité d’un service SaaS aide à conserver un inventaire des applications et des responsabilités. Un fournisseur d’identité central ne dispense pas de connaître les comptes qui vivent hors de lui.
Un pilote qui mesure la sécurité et la charge réelle
Sélectionnez un groupe représentatif : utilisateurs mobiles, personnes sur plusieurs appareils, collaborateurs peu habitués aux changements, administrateurs et équipe support. Évitez de limiter l’essai aux personnes qui maîtrisent déjà tous les paramètres de leur navigateur.
Le protocole peut comprendre l’enregistrement, la connexion sur un autre appareil, le remplacement d’un équipement, une perte simulée et le retrait d’un moyen. Les simulations doivent rester encadrées pour ne pas créer de compte oublié ou provoquer une interruption involontaire.
Mesurez au minimum le taux d’enregistrement abouti, le temps de première connexion, le nombre de demandes d’assistance, les récupérations réussies et la proportion d’exceptions. Un taux de connexion élevé ne révèle pas le niveau de protection si les utilisateurs passent massivement par une ancienne méthode de secours.
Exemple fictif de charge initiale : 40 utilisateurs consacrent chacun 12 minutes au changement, soit huit heures. L’administration prend quatre heures et le support trois heures. Le total atteint 15 heures ; valorisées à 45 euros, elles représentent 675 euros. Vingt clés achetées 25 euros chacune ajoutent 500 euros, soit 1 175 euros pour ce scénario. Ces montants illustrent un calcul, pas des tarifs de marché ni une économie garantie.
Ajoutez ensuite le fonctionnement récurrent : nouveaux arrivants, remplacement, contrôle des exceptions et mises à jour de compatibilité. L’analyse du coût complet d’un projet numérique évite de réduire le budget au matériel.
Écrire une politique lisible et révisable
La politique doit indiquer les méthodes acceptées, les usages nécessitant une vérification renforcée, les conditions d’enregistrement, les secours et les responsabilités. Elle précise aussi les journaux conservés et les droits d’accès à ces traces, sans collecter plus d’informations que nécessaire.
Prévoyez une revue après le pilote et après les changements importants de parc applicatif. Un nouveau terminal, un navigateur différent ou une évolution du fournisseur d’identité peuvent modifier les hypothèses initiales. La compatibilité est une propriété du parcours complet, pas une case cochée pour toujours.
Encadrer les comptes d’urgence
Un accès d’urgence peut être nécessaire lorsque le système d’identité principal ne fonctionne plus. Il doit exister avant l’incident, avec un responsable et une procédure testée. Créer dans la précipitation un compte administrateur permanent et largement partagé introduirait un risque difficile à suivre.
Définissez le périmètre autorisé, les conditions d’usage, les moyens conservés et les personnes capables de déclencher la procédure. L’ouverture de cet accès doit produire une trace examinable, puis une revue après utilisation. Si un secret ou un moyen a été exposé pendant l’intervention, son traitement ultérieur fait partie de la procédure.
La disponibilité du secours doit être vérifiée sans le banaliser. Un contrôle périodique peut confirmer que le compte est encore utilisable et que les personnes autorisées retrouvent la documentation. Il ne devrait pas conduire à employer ce compte pour les tâches quotidiennes, car on perdrait alors la distinction entre usage ordinaire et urgence.
Demandez également ce qui se passe si la personne habituelle est absente. Un accès robuste ne doit pas dépendre d’une seule mémoire ou d’un appareil détenu par un salarié indisponible. La séparation des responsabilités peut aider, à condition de ne pas rendre l’activation impossible dans le scénario visé.
Enfin, la procédure d’urgence doit respecter les objectifs de récupération. Une entreprise peut choisir un contrôle humain plus exigeant pour un administrateur que pour un utilisateur courant. Ce choix mérite d’être assumé et testé : il constitue un arbitrage de risque, pas une défaillance du dispositif.
Le bon indicateur final n’est donc pas « nombre de passkeys créées ». C’est la proportion de comptes correctement protégés, avec un parcours de récupération testé et des exceptions connues. Une entreprise gagne en sécurité lorsqu’elle rend l’attaque plus difficile sans rendre le secours improvisé. Les deux objectifs doivent progresser ensemble.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
