Mots de passe : passer à des passkeys sans chaos

On va être honnête deux secondes. Les mots de passe, c’est fini. Pas techniquement, pas partout, pas demain matin. Mais dans la tête des attaquants, dans les tableaux de bord SOC, dans les tickets support, c’est déjà un énorme point de douleur. Et le truc frustrant, c’est que ce n’est même pas un problème « avancé ». C’est basique. Réutilisation, phishing, bases dumpées, MFA contournée via fatigue, partages d’identifiants sur Teams, post it. Le quotidien.

Les passkeys arrivent comme une promesse un peu magique : plus de mot de passe à taper, plus de code à recopier, et surtout beaucoup moins de phishing qui marche. Sauf que… migrer sans casser la prod, sans paniquer les utilisateurs, sans créer une dette d’auth gigantesque, ça demande une méthode. Et quelques décisions propres.

Dans cet article, on va poser un plan de migration réaliste vers les passkeys. Pas un truc « tout le monde bascule demain ». Plutôt une montée en puissance, en gardant une porte de secours, et en évitant le chaos.

Pourquoi les passkeys changent vraiment la donne

Une passkey, dans le monde Web, c’est basé sur WebAuthn et FIDO2. Concrètement : une paire de clés cryptographiques. La clé privée reste sur l’appareil (ou dans un gestionnaire compatible), la clé publique est enregistrée côté service. À la connexion, le service envoie un challenge, l’appareil signe, et ça passe.

Deux conséquences très concrètes :

• Le phishing classique devient beaucoup moins efficace, parce que la signature est liée à l’origine (le domaine). Un faux site ne peut pas « rejouer » une passkey comme il rejoue un mot de passe.
• Les fuites de bases d’identifiants n’ont plus la même valeur. Voler des clés publiques ne sert pas à grand chose.

Ce n’est pas « invincible », rien ne l’est. Il reste des risques : compromission de session, malware sur endpoint, ingénierie sociale, récupération de compte mal gérée, enrôlement forcé, etc. Mais on coupe une énorme surface d’attaque. Et on gagne aussi côté support : moins de réinitialisations, moins de tickets « j’ai oublié mon mot de passe ».

Le vrai sujet : la migration, pas la techno

La plupart des articles s’arrêtent à « activez les passkeys ». Dans la vraie vie SISR, tu as :

• des utilisateurs sur Android, iOS, Windows, Linux, parfois vieux navigateurs
• des comptes locaux, des comptes AD, des comptes Entra ID, des applis internes
• des prestataires, des comptes partagés (oui, ça existe encore)
• des procédures de récupération pas claires
• et un SI où tout le monde n’est pas prêt à WebAuthn

Donc l’objectif, ce n’est pas de faire joli. C’est de faire robuste.

Avant de bouger : un mini audit express

Tu veux éviter le chaos ? Tu commences par savoir où tu en es.

1. Inventaire des services
   Liste : messagerie, VPN, portail SSO, GLPI, Git, hyperviseur, outils supervision, apps internes, NAS, WiFi captive, etc.
2. Méthodes d’auth actuelles
   Mot de passe seul, MFA TOTP, push, SMS (à éviter), certificats, tokens physiques.
3. Population et usages
   Qui se connecte d’où ? Postes fixes, BYOD, mobiles. Qui a des contraintes (salles info, comptes génériques, comptes admin).
4. État du SSO
   Si tu as un IdP central (Entra ID, ADFS, Keycloak, Okta), ça change tout. La migration passkeys se pilote beaucoup mieux via l’IdP que service par service.

Astuce simple : fais un tableau. Services en ligne, méthode actuelle, support WebAuthn oui/non, criticité, nombre d’utilisateurs, et « prêt pour pilote ».

Comprendre les modèles de passkeys (sinon tu vas te faire piéger)

On mélange souvent tout. Il y a des nuances importantes.

Passkeys synchronisées (multi appareils)

Typiquement via iCloud Keychain, Google Password Manager, ou certains gestionnaires. L’utilisateur crée une passkey sur un appareil, elle peut être disponible sur d’autres appareils du même compte.

Avantages : adoption facile, expérience fluide.
Inconvénients : dépendance à l’écosystème, et question de gouvernance pour l’entreprise.

Passkeys liées à l’appareil (non synchronisées)

Exemple : TPM Windows Hello, clé FIDO2 physique, ou passkey stockée localement sans sync.

Avantages : contrôle fort, utile pour admins.
Inconvénients : perte d’appareil = récupération à gérer sérieusement.

Clés matérielles FIDO2

Toujours très pertinentes pour les comptes à privilèges et les environnements exigeants.

Avantages : très robuste, moins dépendant du cloud perso.
Inconvénients : logistique, stock, perte, coût.

En pratique : tu finiras souvent avec un mix. Et c’est OK.

Plan de migration en 5 étapes (progressif et réaliste)

Étape 1 : sécuriser la base, même avant les passkeys

Avant d’introduire une nouvelle méthode, tu renforces l’existant :

• Interdire les mots de passe faibles (politiques + vérification contre listes compromises si possible)
• Activer MFA robuste là où c’est encore absent
• Réduire les comptes partagés, ou les encapsuler (coffre, PAM, comptes nominaux)
• Mettre des règles de session : durée, détection d’anomalies, géolocalisation si pertinent

Parce que si ton flux de récupération de compte est faible, les passkeys ne sauveront pas tout. Un attaquant va juste passer par « mot de passe oublié ».

Étape 2 : choisir un point de contrôle central (SSO)

Si tu peux, tu centralises via un IdP.

• Entra ID : support des passkeys, Windows Hello for Business, FIDO2
• Keycloak : WebAuthn possible, mais design et UX à travailler
• Okta, Google Workspace : support mature

L’idée : tu actives la capacité passkeys au niveau IdP, puis tu fais basculer progressivement les applications derrière le SSO.

Étape 3 : pilote sur une population limitée

Ne commence pas par « tout le lycée ». Commence par :

• l’équipe IT
• quelques utilisateurs motivés
• des profils variés (Windows, Android, iPhone)

Objectifs du pilote :

• valider la compatibilité navigateur et appareils
• mesurer les tickets support
• vérifier la récupération
• vérifier la gestion des invités et comptes externes

Tu définis des critères de réussite clairs : par exemple, 80 % de connexions sans mot de passe sur 2 semaines, et zéro incident bloquant sans solution.

Étape 4 : déploiement en vague, avec garde fous

Tu ouvres ensuite à plus large, mais en gardant :

• un fallback temporaire (mot de passe + MFA) pendant la transition
• une politique par groupe : « passkey encouragée », puis « passkey requise »
• un monitoring : taux d’enrôlement, taux d’échec, raisons

Important : tu prévois le cas « je n’ai plus mon téléphone ». Et tu évites d’improviser.

Étape 5 : durcissement final

Quand l’adoption est bonne :

• tu désactives les méthodes faibles (SMS, questions secrètes)
• tu réduis la dépendance au mot de passe (voire suppression selon service)
• tu appliques des exigences renforcées pour admins (au moins 2 facteurs résistants au phishing, ou 2 passkeys, ou passkey + clé physique)

La partie qui casse tout si tu la rates : la récupération de compte

C’est là que beaucoup d’organisations se tirent une balle dans le pied. Parce que l’utilisateur perd son téléphone, ou change de PC, ou casse son écran, et là… panique.

Quelques approches qui marchent :

• Enrôlement de plusieurs passkeys dès le départ : téléphone + PC, ou téléphone + clé FIDO2
• Codes de récupération à usage unique, imprimables, stockés hors ligne (avec sensibilisation)
• Processus helpdesk clair : vérification d’identité, délai, traçabilité, validation manager si besoin
• Comptes à privilèges : récupération encore plus stricte, et idéalement stockage de clés physiques en double sous contrôle

Tu documentes ce flux. Tu le testes. Oui, vraiment. Un exercice « perte de passkey » en conditions réelles.

Et les comptes admin, on fait quoi ?

Les comptes admin ne doivent pas suivre le même chemin que tout le monde. Pas exactement.

Recommandation simple, efficace :

• Passkey obligatoire
• Et une clé FIDO2 physique en plus, au moins comme méthode secondaire
• Pas de récupération « facile »
• Segmentation : comptes admin dédiés, pas utilisés pour lire les mails

Et si tu es dans un contexte lab ou pédagogique, c’est un super sujet de TP : comparer l’expérience utilisateur standard vs compte à privilèges, et expliquer pourquoi on n’applique pas les mêmes règles.

Cas concrets qu’on voit souvent en BTS SIO option SISR

Je le mets ici parce que c’est du vécu. Et on en parle souvent dans des labs.

« On a des PCs en salle, comptes partagés »

Les passkeys et les comptes partagés, ça ne colle pas bien. Solution : revenir à des comptes nominatifs, ou utiliser un système de sessions temporaires, ou un gestionnaire de secrets/PAM pour les accès partagés techniques.

« On a des applis internes pas compatibles WebAuthn »

Tu peux :

• passer par un reverse proxy avec authent SSO
• moderniser l’appli (long terme)
• ou maintenir mot de passe + MFA robuste en attendant, en isolant le service

« On a des utilisateurs sans smartphone »

Ça arrive. Tu peux proposer :

• passkey sur poste (Windows Hello)
• clé FIDO2
• ou maintien temporaire d’une méthode alternative, mais avec restrictions et suivi

Bonnes pratiques de déploiement (petites, mais vitales)

• Communication courte : une page « pourquoi, comment, quoi faire si problème »
• Une procédure en 5 minutes avec captures d’écran
• Une FAQ helpdesk
• Un canal de support dédié les premiers jours
• Des métriques visibles : adoption, échecs, top 3 des incidents

Et surtout : ne vends pas ça comme « plus jamais de problème ». Vends ça comme « moins de phishing, moins d’oublis, plus simple au quotidien ». Plus vrai. Plus crédible.

Un mini lab à faire pour se former (idée pour le Tech Lab)

Si tu veux pratiquer, tu peux monter un petit lab :

• Keycloak + une appli de test derrière
• activer WebAuthn
• enrôler 2 passkeys par utilisateur test
• simuler une perte et tester le flux de récupération
• puis écrire un petit retour d’expérience

C’est typiquement le genre de contenu qu’on peut publier sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : un tutoriel clair, une config reproductible, et les pièges rencontrés. Même si tout n’est pas parfait. Surtout si tout n’est pas parfait, en fait.

Ce qu’il faut retenir

Les passkeys, ce n’est pas un gadget. C’est une vraie évolution, déjà mature sur beaucoup de services. Mais la réussite dépend moins du bouton « activer WebAuthn » que de trois choses très terre à terre :

• un déploiement progressif
• une récupération de compte béton
• un traitement à part pour les comptes à privilèges

Si tu veux éviter le chaos, tu fais simple, par étapes, et tu testes les scénarios moches. Perte. Changement d’appareil. Utilisateur pressé. Admin en urgence. C’est là que ton design d’auth se prouve.

Et si tu as envie de pousser plus loin, garde l’idée : documenter ton pilote, faire des captures, et publier un retour d’expérience sur le blog. Ça aide les autres. Et ça te force à rendre le truc propre.

Questions fréquemment posées

Pourquoi les mots de passe sont-ils considérés comme un point de douleur majeur en sécurité informatique ?

Les mots de passe posent problème car ils sont souvent réutilisés, vulnérables au phishing, exposés via des bases de données compromises, contournés par fatigue MFA, partagés sur des plateformes comme Teams ou même notés sur des post-it. Cela engendre une surface d'attaque importante et un volume élevé de tickets support liés aux oublis ou réinitialisations.

Qu'est-ce qu'une passkey et comment change-t-elle la donne en matière d'authentification ?

Une passkey est une paire de clés cryptographiques basée sur WebAuthn et FIDO2 : la clé privée reste sur l'appareil, la clé publique est stockée côté service. Lors de la connexion, le service envoie un challenge que l'appareil signe. Cela réduit fortement le phishing car la signature est liée à l'origine (domaine), et rend les fuites d'identifiants beaucoup moins critiques.

Quels sont les principaux défis lors de la migration vers les passkeys dans un système d'information ?

La migration doit gérer une diversité d'utilisateurs (Android, iOS, Windows, Linux), différents types de comptes (locaux, AD, Entra ID), des prestataires avec comptes partagés, des procédures de récupération parfois floues et un SI pas toujours prêt pour WebAuthn. L'objectif est une montée en puissance robuste sans casser la production ni paniquer les utilisateurs.

Comment préparer efficacement la migration vers les passkeys ?

Il faut commencer par un mini audit express comprenant : 1) un inventaire complet des services utilisés ; 2) l'analyse des méthodes d'authentification actuelles ; 3) comprendre la population et leurs usages (postes fixes, BYOD, mobiles) ; 4) évaluer l'état du SSO et si un IdP central est en place. Un tableau synthétique aide à piloter cette préparation.

Quels bénéfices concrets apporte l'adoption des passkeys pour le support informatique ?

Les passkeys réduisent significativement les demandes liées aux mots de passe oubliés ou perdus. Elles diminuent aussi le nombre de réinitialisations nécessaires grâce à une authentification plus sécurisée et fluide, ce qui allège la charge du support et améliore l'expérience utilisateur.

Quelles sont les différences entre les modèles de passkeys synchronisées et leurs avantages ?

Les passkeys synchronisées fonctionnent via des gestionnaires comme iCloud Keychain ou Google Password Manager. Une passkey créée sur un appareil est disponible sur plusieurs appareils du même compte utilisateur. Cela facilite l'accès multi-appareils tout en conservant une sécurité élevée grâce à la cryptographie sous-jacente.