C'est quoi l'authentification sans mot de passe (et comment ça marche) ?
Publié le
Dans cet article nous verrons ce qui se passe concrètement quand un service vous propose de vous connecter « sans mot de passe ». Un lien envoyé par email, un code à six chiffres reçu par SMS, votre empreinte digitale posée sur l'écran, ou simplement un bouton « Continuer avec Google »… Tout ça porte l'étiquette passwordless, mais ces méthodes n'ont pas grand-chose en commun, à part l'absence d'un champ mot de passe sur l'écran de connexion.
On ne supprime pas la preuve, on change sa nature
Un mot de passe, c'est une preuve qu'on garde dans sa tête : un secret qu'on a choisi, qu'on a en théorie mémorisé, et qu'on retape à chaque connexion.
Imaginez un digicode d'immeuble : un code à quatre chiffres que n'importe qui peut lire par-dessus votre épaule, ou retrouver écrit au feutre sur le mur d'à côté. Remplacez-le maintenant par trois scénarios différents. Premier scénario : on vous a confié une clé, qui n'ouvre que cette porte-là et que vous seul possédez. C'est le principe de la passkey (ou clé d'accès). Deuxième scénario : à chaque tentative, le gardien glisse un mot de passe à usage unique sous la porte, valable quelques minutes, c'est le lien magique ou le code OTP. Troisième scénario : le gardien de l'immeuble d'à côté vous connaît déjà, et accepte de vous faire entrer parce qu'il vous a déjà identifié avant. c'est la connexion via Google ou Apple.
Trois façons de faire très différentes mais un point commun : aucune des trois ne vous demande de retenir un mot de passe que vous retapez au clavier.
Quatre méthodes, quatre cas d’usage
Dans la pratique, ce qu'on regroupe sous l'étiquette « sans mot de passe » recouvre quatre approches bien distinctes. Voici ce qui se passe réellement derrière chacune d'elles.
Le lien magique (magic link). Vous entrez votre adresse email, le service vous envoie un lien à usage unique. Vous cliquez, vous êtes connecté. Ce lien sert de preuve : il affirme « la personne qui a accès à cette boîte mail a demandé cette connexion il y a moins de quinze minutes ».
Le code à usage unique (OTP). Une variante du même principe, mais lue à l'écran et tapée à la main plutôt que cliquée. Reçue par SMS, par email, ou générée localement par une application d'authentification, on parle alors de TOTP, pour « time-based one-time password ».
La connexion déléguée (social login). « Continuer avec Google », « Se connecter avec Apple »… On a déjà détaillé la mécanique des tokens OAuth qui rendent ça possible dans l'article précédent, pas la peine d'y revenir. Ici, on s'intéresse juste au résultat côté utilisateur : vous déléguez la vérification d'identité à un tiers que vous avez déjà authentifié ailleurs, et qui vous connaît mieux que le service que vous venez de visiter.
La passkey (WebAuthn / FIDO2). C'est la plus récente des quatre méthodes, et celle qui fonctionne de manière totalement asymétrique. À la création, votre appareil génère une paire de clés cryptographiques : une privée, qui ne quitte jamais l'appareil et reste protégée par votre biométrie ou votre code local, et une publique, envoyée au serveur. À la connexion, le service envoie un défi que votre appareil signe avec la clé privée. C'est ce mécanisme qui explique pourquoi ce système résiste nativement au phishing, contrairement à un simple code OTP.
const credential = await navigator.credentials.create({
publicKey: {
challenge, // généré côté serveur, à usage unique
rp: { name: "Mon Service" },
user: { id: userId, name: "vous@exemple.com", displayName: "Vous" },
pubKeyCredParams: [{ type: "public-key", alg: -7 }]
}
});
// Le navigateur affiche alors le prompt biométrique natif.
// Ce qui part vers le serveur, c'est une clé publique, jamais l'empreinte elle-même.
La fin du secret partagé (mais pas pour tout le monde)
Le modèle classique repose sur une information connue à la fois par vous et par le service : vous la connaissez, et le serveur en garde une version, normalement hachée, pour pouvoir le vérifier. Le problème de ce modèle, ce n'est pas seulement qu'on choisit des mots de passe faibles. C'est que si la base de données du serveur fuite, un attaquant récupère de quoi tenter de casser ces hachages hors ligne, tranquillement, pendant des semaines.
Cette approche casse ce modèle. Le serveur ne stocke qu'une clé publique, par définition inutile sans la clé privée qui reste sur votre appareil. Une fuite de base de données ne donne plus rien d'exploitable pour se connecter à votre place.
« Il n'y a plus rien à voler dans la base de données »
Factuellement, on supprime un élément sensible qui pouvait fuiter en masse. Mais « rien à voler dans la base » ne veut pas dire « rien à protéger » pour autant. La sécurité ne disparaît pas, elle se déplace vers deux autres endroits : votre appareil, qui détient la clé privée, et le compte cloud, Apple, Google, Microsoft, qui synchronise cette clé pour la restaurer si vous changez de téléphone.
Ce raisonnement ne s'applique pas au lien magique ni au code OTP. Dans les deux cas, on transmet toujours une preuve par le réseau, exactement comme un mot de passe, seule la durée de vie change. Un lien magique ou un code OTP, c'est un mot de passe qui s'autodétruit après quinze minutes, pas un mécanisme d'une autre nature. Le gain de sécurité y est réel, mais il vient de la durée, pas d'un changement de modèle.
Forces, faiblesses et risques de chaque méthode
| Lien magique | Code OTP (SMS) | Passkey | Connexion via un tiers | |
|---|---|---|---|---|
| Repose sur | L'accès à votre boîte mail | L'accès à votre carte SIM / téléphone | Votre appareil + déverrouillage local | La sécurité du compte tiers (Google, Apple…) |
| Résiste au phishing en temps réel | Non | Non | Oui (liée cryptographiquement au site) | Dépend du fournisseur (souvent une passkey en coulisses) |
| Risque principal | Prise de contrôle de l'email = accès à tout | Détournement de SIM, interception réseau | Perte de l'appareil sans synchronisation, dépendance à l'écosystème | Dépendance totale à un compte qu'on ne contrôle pas |
| Récupération en cas de perte | Aussi simple (ou compliquée) que récupérer son email | Dépend de l'opérateur téléphonique | Resynchronisation via le cloud, ou ressaisie depuis un autre appareil | Dépend entièrement de la procédure du fournisseur tiers |
Le problème ne disparaît pas
Pour le lien magique et l'OTP, la racine de confiance ne disparaît pas avec le mot de passe : elle se déplace vers le canal que vous avez utilisé pour créer le compte, le plus souvent votre boîte mail, parfois votre numéro de téléphone.
« Mon adresse email, c'est devenu mon nouveau mot de passe »
Si votre boîte mail est compromise, mot de passe réutilisé ailleurs, ancien nom de domaine récupéré par quelqu'un d'autre, ou si vous êtes hameçonnés, un attaquant peut demander un lien magique ou un code sur chaque service que vous utilisez et y accéder. Les conséquences sont finalement les mêmes.
Si vous perdez l'accès à tous les appareils qui détiennent vos clés privées, vous vous retrouvez face au même processus de récupération qu'un accès perdu : preuve d'identité auprès du fournisseur, contact du support, avec parfois plusieurs jours d'attente.
« Moins de tickets au support »
C'est l'argument qu'on entend le plus souvent en faveur du sans mot de passe, et il n'est pas faux, juste incomplet. Les tickets « mot de passe oublié » disparaissent effectivement en grande partie. Mais d'autres frictions apparaissent. Par exemple, les filtres de sécurité en entreprise (Microsoft Defender, Proofpoint...) inspectent automatiquement les liens des emails entrants pour vérifier qu'ils ne sont pas malveillants. Comme ces liens magiques sont à usage unique, le robot de sécurité les "brûle" avant même que l'utilisateur ne puisse ouvrir le message. Résultat : l'employé tombe sur un écran « lien invalide ou expiré » dès sa toute première tentative.
Alors, moins de tickets au support ? Oui pour « j'ai oublié mon mot de passe ». Non pour le volume global : on déplace le problème vers « pourquoi mon lien ne marche jamais du premier coup au bureau », ce qui n'est ni plus simple à diagnostiquer, ni gratuit à corriger.
Les bénéfices qu'on peut vraiment mesurer
Une fois ces nuances posées, il reste de vrais bénéfices, mesurables, pas seulement ressentis.
Le premier, c'est la disparition du risque de réutilisation. Le bourrage d'identifiants (credential stuffing), tester en masse des paires email/mot de passe qui ont fuité ailleurs, ne fonctionne tout simplement plus sur un compte qui n'a jamais eu de mot de passe à voler ou réutiliser.
« Le phishing, c'est terminé »
C'est vrai, mais pas pour toutes les formes d'authentification sans mot de passe. Techniquement, une passkey est liée cryptographiquement au domaine pour lequel elle a été créée : même piégée sur un faux site qui imite parfaitement l'original, elle refuse de s'authentifier, parce que l'adresse ne correspond pas. C'est une protection structurelle, pas un simple obstacle supplémentaire.
Le lien magique et l'OTP, eux, n'ont pas cette protection. Dans ces deux cas, c'est toujours l'utilisateur qui transmet la preuve permettant de se connecter : un faux écran de connexion peut intercepter un code OTP en temps réel et le rejouer immédiatement sur le vrai site, ou récupérer un lien copié dans un message. Dire que le phishing est terminé est donc vrai pour une des quatre méthodes, pas pour les trois autres.
À l'échelle, ça compte : un rapport sécurité de Microsoft portant sur 2025 indique qu'une authentification résistante au phishing bloque plus de 99 % des attaques basées sur l'identité, même quand l'attaquant possède déjà le bon mot de passe. Et la FIDO Alliance recense désormais environ 5 milliards de passkeys actives dans le monde, on est largement sorti du stade expérimental.
Sur le papier, l'adoption est massive : selon ce même rapport, environ trois quarts des internautes ont activé au moins une passkey sur un compte. Mais « activé » n'est pas « utilisé » : sur les plateformes qui proposent les passkeys, l'usage actif sur les 30 derniers jours tourne plutôt autour de la moitié de ce chiffre selon les analyses du secteur, avec un écart marqué selon le domaine d'activité, la finance, où le coût d'un piratage de compte est élevé, dépasse 60 % d'usage actif chez les utilisateurs éligibles, contre moins de 20 % dans les médias et le streaming, où l'enjeu est nettement plus faible.
Ce qu'on a tendance à minimiser
« Sans mot de passe, il n'y a plus rien à pirater »
Faux, et c'est probablement la phrase la plus trompeuse de tout ce sujet. Les attaques ne disparaissent pas. Elles visent simplement autre chose. Pour le lien magique et l'OTP, la cible devient la boîte mail ou la ligne téléphonique elle-même. Pour la passkey, la cible devient l'appareil physique, ou le compte cloud qui la synchronise.
Le cas du SMS illustre bien ce déplacement. Le détournement de carte SIM (SIM swap) et l'interception au niveau du réseau téléphonique (SS7) sont des techniques connues, documentées, et industrialisées par des groupes criminels. Ce n'est plus un risque théorique pour les régulateurs : la dernière révision du référentiel d'identité numérique du NIST américain (SP 800-63B-4) classe pour la première fois les codes envoyés par le réseau téléphonique, SMS compris, dans une catégorie « restreinte », toujours autorisée, mais sous conditions de mitigation renforcées. Et en 2026, plusieurs régulateurs financiers, notamment aux Émirats arabes unis, en Inde et aux Philippines, ont commencé à pousser les banques à s'éloigner du SMS comme facteur d'authentification principal.
La grande majorité des clés stockées dans le monde vivent dans l'un de deux écosystèmes, le trousseau iCloud d'Apple et le gestionnaire de mots de passe de Google se partagent l'essentiel du volume selon les estimations du secteur. Perdre l'accès à ce compte cloud met donc en péril, d'un coup, toutes les clés qu'il synchronisait. Et la promesse « sans friction » reste inégale selon l'appareil : les analyses de terrain montrent un taux de réussite à leur création plus élevé sur le web mobile iOS que sur le web Windows, où une bonne partie des premières tentatives échoue encore.
Comment choisir, en pratique
Pas de réponse universelle, mais quelques repères qui tiennent dans la durée.
Pour une application grand public à faible enjeu, le lien magique ou la connexion via un tiers offrent le meilleur rapport effort/résultat : rapides à mettre en place, peu de friction à l'inscription. Mais prévoyez le cas où certains liens arrivent déjà invalides chez une partie des utilisateurs, un simple bouton « renvoyer le lien » limite les dégâts.
Pour tout ce qui touche à de l'argent, à des données sensibles ou à un accès administrateur, orientez vers les clés d'accès en option par défaut, n prévoyant une solution de récupération.
Évitez de faire du SMS le seul second facteur sur un compte qui compte vraiment, le NIST le déconseille désormais explicitement, et plusieurs régulateurs financiers vont dans le même sens en 2026.
Ne comptez pas supprimer le mot de passe de votre schéma de base de données dès la première itération. Même chez les organisations qui ont déployé les passkeys de façon "agressive", l'authentification classique a reculé d'environ un quart, pas jusqu'à zéro, selon une enquête menée auprès d'entreprises. La coexistence, pas le remplacement total, reste aujourd'hui le scénario le plus réaliste.
Alors, on enterre le mot de passe ?
Pas complètement, et probablement pas tout de suite. Mais la tendance est claire, et elle ne relève plus du gadget : cinq milliards de passkeys actives, des régulateurs qui se mettent à écrire des textes pour décourager le SMS, des entreprises qui constatent une vraie baisse de l'usage du mot de passe une fois l'alternative proposée. L'adoption progresse, mais pas au même rythme partout.
De mon côté, dès qu'un service propose « Continuer avec Google », je n'invente plus de nouvelle combinaison (avec des majuscules, des chiffres, des caractères spéciaux). Pas seulement par flemme assumée, mais aussi parce que je préfère déléguer la sécurité de ce compte à une équipe dont c'est le métier plutôt qu'à moi-même. Ça ne veut pas dire qu'il faut bannir le mot de passe partout : pour un compte qu'on ouvre une fois par an, un gestionnaire correctement configuré fait très bien le travail, sans dépendre d'un tiers. Mais pour tout ce qu'on utilise souvent, Mais pour tout ce qu'on utilise souvent, le choix me semble assez clair, à condition de ne jamais perdre de vue que chaque méthode déplace un risque plutôt que de le faire disparaître.
