Les mots de passe échouent rarement parce que les équipes sont “négligentes”. Ils échouent surtout parce que le modèle est structurellement fragile : un secret réutilisable circule entre un humain, un navigateur, un service distant, parfois un gestionnaire, et finit par être recopier, sauvegardé, ou intercepté.

Les trois problèmes récurrents

• Phishing : l’utilisateur est amené à saisir son mot de passe (et parfois son code MFA) sur un faux site. Même avec une sensibilisation régulière, les scénarios deviennent crédibles et contextualisés.
• Réutilisation et fuites : un mot de passe robuste ne protège pas si le même secret se retrouve sur plusieurs services. Une fuite sur un outil secondaire peut ouvrir une porte sur des ressources plus critiques.
• Dette opérationnelle : réinitialisations, verrouillages, comptes compromis, onboarding/offboarding. Le mot de passe a un coût caché (support, interruptions, risque).

La “fatigue MFA” et ses limites

La MFA a amélioré le niveau de sécurité, mais peut créer une friction quotidienne : notifications répétées, codes temporaires à recopier, dépendance au réseau, perte de téléphone. Cette friction conduit à des contournements (sessions trop longues, exceptions non maîtrisées, comptes partagés). Certaines MFA sont aussi sensibles au phishing (codes OTP) ou à des attaques de type approbation abusive (notifications push).

Au fond, le problème n’est pas seulement “un mot de passe faible” : c’est la dépendance à un secret saisissable et réutilisable. C’est précisément ce que les passkeys cherchent à éliminer.

Une passkey est une méthode d’authentification basée sur la cryptographie asymétrique (standards FIDO2/WebAuthn). En pratique, l’utilisateur ne tape plus de mot de passe : il valide une demande de connexion avec un appareil (téléphone, ordinateur) déverrouillé par biométrie ou code.

Comment ça marche (sans jargon inutile)

• Lors de l’enrôlement, un appareil crée une paire de clés : clé privée (gardée sur l’appareil) et clé publique (stockée côté service).
• À la connexion, le service envoie un défi cryptographique.
• L’appareil signe ce défi avec la clé privée après validation utilisateur.

Ce mécanisme réduit fortement les risques de phishing, car la signature est liée au contexte du site/app ciblé. L’utilisateur n’a pas de secret “rejouable” à saisir sur un faux site.

Avantages entreprise

• Moins de phishing sur les applications compatibles.
• Moins de réinitialisations : pas de mot de passe oublié.
• Expérience fluide : un geste (biométrie/code) remplace une saisie.
• Compatible SSO et Zero Trust : les passkeys peuvent s’intégrer dans une stratégie d’accès conditionnel et d’identité.

Limites et points d’attention

• Couverture applicative : toutes les applications n’acceptent pas encore les passkeys (ou seulement via un IdP/SSO).
• Gestion du cycle de vie : perte/changement d’appareil, renouvellement, départ d’un collaborateur.
• Postes partagés : la logique “un appareil = une personne” peut être plus complexe.
• Gouvernance : il faut décider où se gère la passkey (compte Microsoft/Google/Apple, IdP, solution IAM) et comment on maîtrise les risques.

Les passkeys ne “suppriment” pas immédiatement tous les mots de passe : elles permettent une migration progressive, avec des exceptions maîtrisées.

L’erreur classique consiste à chercher une règle unique pour tout le SI. En pratique, le bon design est par usage, selon le niveau de risque, l’impact d’un compte compromis, et la réalité terrain.

Une approche simple : classer par criticité

1. Comptes administrateurs et actions sensibles : création de comptes, changements de droits, accès console cloud, réinitialisations.
2. Accès distant et exposition Internet : VPN, VDI, portails exposés, accès partenaires.
3. Messagerie et collaboration : e-mails, suites bureautiques, partage de documents.
4. SaaS métier : CRM, ERP, outils RH/finance.

Choisir les facteurs adaptés

• Passkeys (FIDO2/WebAuthn) : recommandées quand c’est possible, surtout pour les comptes à privilèges et la messagerie via un IdP/SSO. Elles réduisent les risques de phishing car il n’y a pas de code à recopier.
• Clés de sécurité matérielles : utiles pour les profils à risque (admin, dirigeants, fonctions sensibles), et dans des contextes où le téléphone n’est pas fiable ou autorisé.
• Applications d’authentification : une option intermédiaire, efficace mais à cadrer (politique anti-phishing si disponible, limitation des méthodes faibles).
• SMS/OTP : à réserver aux cas transitoires ou exceptionnels, car ce sont des méthodes plus exposées aux attaques et à l’ingénierie sociale.

Exemples de politique réaliste

• Messagerie + SSO : passkeys privilégiées, sinon application d’authentification.
• VPN : MFA obligatoire, avec contrôle de conformité du poste si possible.
• Admin : passkey ou clé matérielle, plus contrôle d’accès conditionnel et principes de moindre privilège.

L’objectif : maximiser la protection là où l’impact est le plus élevé, sans imposer une friction identique à tous les usages.

Déployer passkeys et MFA n’est pas qu’un projet technique. C’est un changement de geste quotidien. Un plan court, itératif et mesurable évite le rejet.

1. Cadrer l’architecture d’identité

• Choisir le point central : IdP/SSO (souvent la voie la plus simple) et les applications intégrées.
• Fixer les objectifs : réduction du phishing, simplification du support, conformité.

2. Définir une politique d’authentification par population

• Administrateurs, bureau, terrain, prestataires.
• Prévoir les contraintes : BYOD, terminaux durcis, zones sans réseau, téléphonie interdite.

3. Lancer un pilote limité et représentatif

• Un petit groupe mêlant métiers et IT.
• Critères de succès : activation simple, taux d’adoption, incidents, satisfaction.
• Tester les parcours : enrôlement, connexion, changement d’appareil, récupération.

4. Traiter les exceptions avant le déploiement massif

• Applications non compatibles : passer par SSO, ou définir une MFA alternative.
• Comptes de service : inventaire, rotation des secrets, limitation des droits.

5. Outiller le support et la communication

• Guides courts : “comment activer”, “comment se connecter”, “que faire en cas de perte”.
• Scripts de helpdesk : vérifications, ré-enrôlement, escalade.
• Messages internes : expliquer le “pourquoi” (phishing) et le “comment” (moins de frictions).

6. Généraliser progressivement et verrouiller

• Déploiement par vagues, avec fenêtre de transition.
• Retirer progressivement les méthodes faibles.
• Mettre en place des contrôles : journaux d’authentification, alertes, revues d’accès.

Ce plan limite les surprises. Le succès vient moins d’une “grande bascule” que d’une migration guidée, avec des exceptions explicites et temporaires.

Les cas “difficiles” font échouer les déploiements quand ils ne sont pas anticipés. Les passkeys et la MFA restent compatibles avec ces environnements, à condition de clarifier les scénarios et d’éviter les faux bons plans (comptes partagés permanents, numéros de téléphone mutualisés, boîtes mail d’équipe).

Postes partagés (atelier, point de vente, accueil)

• Éviter le compte unique partagé pour des actions nominatives.
• Préférer des sessions utilisateurs (SSO) avec déconnexion rapide et verrouillage automatique.
• Selon le contexte, utiliser des supports d’authentification dédiés (clé matérielle attribuée) plutôt qu’un téléphone personnel.

Intérim et saisonniers

• Processus d’onboarding rapide : compte nominatif, durée limitée, droits minimaux.
• Mécanisme de récupération simple, géré par le support ou un référent.
• Offboarding strict : désactivation immédiate, révocation des facteurs.

Prestataires et partenaires

• Séparer les accès : comptes externes dédiés, accès conditionnel, segmentation applicative.
• Exiger un niveau MFA cohérent avec le risque, sans imposer un outillage impossible.
• Pour les accès ponctuels, privilégier des solutions d’accès temporaires, traçables, et révocables.

Ce qu’il faut éviter

• Les “exceptions définitives” non documentées.
• Les contournements type “on garde un compte de secours” utilisé au quotidien.
• La confusion entre identité (qui) et appareil (sur quoi).

Un bon design accepte la diversité des situations, mais impose une règle : chaque accès doit être attribuable, révocable, et proportionné au risque.

Sans mesure, l’authentification forte reste perçue comme une contrainte. Avec des indicateurs simples, elle devient un projet de performance opérationnelle et de réduction de risque.

Indicateurs sécurité (orientés risque)

• Nombre d’alertes liées à des tentatives de connexion suspectes.
• Volume de compromissions de comptes (ou comptes à risque) détectées.
• Part des authentifications utilisant des méthodes résistantes au phishing (quand l’IdP permet cette classification).

Indicateurs support (orientés coûts cachés)

• Tickets “mot de passe oublié” et “compte verrouillé”.
• Délai moyen de reprise (temps pour rétablir l’accès).
• Nombre de ré-enrôlements (changement/perte d’appareil), pour ajuster la procédure.

Indicateurs expérience (orientés adoption)

• Taux d’activation par population.
• Taux de succès à la première connexion après enrôlement.
• Retours qualitatifs : points de friction récurrents (VPN, mobile, applications legacy).

Exploiter les mesures

• Prioriser les applications à intégrer au SSO : celles qui génèrent le plus d’incidents ou qui exposent le plus de risque.
• Ajuster les règles d’accès conditionnel : réduire les demandes MFA inutiles, augmenter la protection sur les actions sensibles.
• Documenter les exceptions et fixer une date de sortie.

Les gains les plus visibles arrivent souvent côté support et continuité d’activité. La sécurité s’améliore, mais surtout elle devient plus prévisible et plus pilotable.

Cette checklist synthétise les décisions et actions qui font la différence entre une “MFA imposée” et une authentification forte adoptée.

Gouvernance et cadrage

• Définir un responsable de la politique d’authentification (IT + métiers).
• Cartographier les applications : SSO possible, MFA existante, exposition Internet, population concernée.
• Classer les comptes : utilisateurs, admins, comptes techniques, prestataires.

Politique et parcours utilisateur

• Définir les méthodes autorisées : passkeys, clés matérielles, application, et les méthodes transitoires.
• Écrire les parcours : enrôlement, première connexion, récupération, changement d’appareil, départ.
• Définir les règles d’accès : par usage (messagerie, VPN, admin, SaaS), pas une règle unique.

Préparer le déploiement

• Pilote avec un groupe représentatif (dont profils terrain).
• Support prêt : procédures, scripts, droits helpdesk, escalade.
• Communication : messages courts, bénéfices concrets, calendrier par vagues.

Gérer les cas difficiles

• Postes partagés : stratégie nominative et traçable.
• Intérim : comptes temporaires, offboarding immédiat.
• Prestataires : accès séparés, contrôles et révocation.

Mesure et amélioration continue

• Indicateurs : adoption, tickets support, méthodes d’authentification utilisées.
• Revue mensuelle des exceptions et des applications non intégrées.
• Planifier la réduction progressive des mots de passe là où c’est possible.

Si cette checklist tient sur une page et est comprise par le support et les managers, vous avez une base solide pour déployer sans friction inutile.