# Passkeys : le mot de passe qui n'existe pas

> Si le problème des mots de passe, c'est qu'un secret partagé traîne quelque part chez quelqu'un d'autre, la solution est de supprimer le secret partagé. Ce sont les passkeys — et voici ce qu'elles réparent, et ce qu'elles ne réparent pas.

2026-06-18 · David Carrero · password.es
Original: https://password.es/fr/blog/passkeys-le-mot-de-passe-qui-n-existe-pas/

---

Toutes les histoires de mots de passe finissent pareil : quelqu'un gardait ton
secret quelque part, et il l'a perdu.

Peu importe l'année. Au début, il traînait dans un fichier en clair sur un
ordinateur partagé, et il suffisait de demander au système de l'imprimer. En 1979,
Morris et Thompson ont expliqué comment saler le hachage et en renchérir le calcul
pour qu'une liste volée ne se transforme pas immédiatement en liste de mots de
passe — une avancée énorme. Puis sont arrivées les règles de composition qui nous
ont fait coller un symbole à la fin. Mais la forme du problème, elle, n'a pas bougé
d'un millimètre pendant tout ce temps : **il y a un secret, tu le connais, le
serveur peut le vérifier, et donc le serveur a quelque chose à perdre**.

Tout ce qu'on a fait depuis consiste à rendre ce secret plus long, plus bizarre,
plus salé, plus lent à casser. Personne ne s'est posé la question d'avant : et s'il
n'y avait pas de secret partagé du tout ?

## 1976 : l'idée qu'un secret peut avoir deux moitiés

En 1976, Whitfield Diffie et Martin Hellman publient *New Directions in
Cryptography*. L'idée est presque vexante de simplicité : **une clé peut se couper
en deux morceaux qui ne sont pas interchangeables**. L'un, tu le cries sur les
toits ; l'autre ne sort jamais de chez toi. Ce que tu signes avec le privé se
vérifie avec le public, mais le public, lui, ne signe rien du tout.

Relis ça en pensant à un serveur : le site n'a plus besoin de conserver quoi que ce
soit qui permette d'entrer. Seulement la moitié qui n'ouvre aucune porte.

Que l'idée ait mis près d'un demi-siècle à atteindre l'écran de ta banque ne plaide
pas franchement en faveur de notre métier. Les certificats clients existaient et
fonctionnaient ; ce qui n'existait pas, c'était une façon de s'en servir sans un
master derrière. La cryptographie était résolue. L'ergonomie, non.

## 2013 : pour une fois, tout le monde se met d'accord

En 2013 naît la **FIDO Alliance**, un consortium industriel avec un objectif
affiché et pas franchement modeste : réduire la dépendance aux mots de passe.
L'important n'était pas la technologie — elle était déjà là — mais que fabricants,
navigateurs et services acceptent de s'asseoir autour d'une table pour convenir d'un
même protocole. Ça sonne bureaucratique, et c'était exactement ce qui manquait : un
mécanisme d'authentification qui ne marche que dans un navigateur et avec un seul
service n'est pas un mécanisme, c'est une anecdote.

## 2019 : le navigateur apprend la cryptographie

En **mars 2019, WebAuthn devient recommandation du W3C**. En clair : n'importe
quelle page pouvait désormais demander au navigateur — via une API standard, sans
plugin ni pilote — de générer une paire de clés et de signer avec.

Le déroulé, sans fioritures, est le suivant. Quand tu t'inscris, ton appareil crée
une nouvelle paire de clés, propre à ce site-là. Il envoie la publique. Il garde la
privée, stockée par l'appareil lui-même et protégée par ton empreinte, ton visage ou
son code. Quand tu reviens, le site t'envoie un défi tiré au hasard, ton appareil le
signe, et le site vérifie la signature avec la publique qu'il avait déjà.

Regarde bien ce qui **n'**arrive **pas** : aucun secret ne circule. Le serveur n'a
jamais eu ta clé privée, il ne peut donc pas la perdre. Si demain toute sa base de
données fuite, ce qu'on emporte, c'est une liste de clés publiques — à peu près
l'équivalent de voler l'annuaire. Aucun hachage à faire tourner sur un GPU, aucun
dictionnaire à essayer. Ce n'est pas que c'est difficile : c'est qu'il n'y a rien
là-dedans qui vaille quelque chose.

## L'effet secondaire est plus gros que l'idée

Quand ton appareil crée cette paire de clés, il l'attache au domaine. La clé qu'il a
gardée pour `votrebanque.fr` **n'est proposée qu'à `votrebanque.fr`**. Ce n'est pas
une règle, ni un avertissement, ni un bandeau rouge dans la barre d'adresse : c'est
que la clé pour `votrebanqu0-securite.com` n'existe pas. Le navigateur ne la trouve
pas parce qu'elle n'a jamais été créée.

Ça tue le phishing. Ça ne le réduit pas : ça le prive de mécanisme. Tout le fonds de
commerce du phishing, c'est que **tu peux taper ton mot de passe sur le mauvais
site**, et on essaie de corriger ça depuis des années à coups de formation des
utilisateurs et de campagnes de sensibilisation. Tout ça, c'était soigner le
symptôme. Ton œil se laisse avoir par une URL qui ressemble ; ton téléphone, non. Il
ne lit pas : il compare des chaînes de caractères.

Au passage, ça emporte aussi la réutilisation, qui était l'autre péché capital.
Chaque site a sa paire de clés. Il n'y a rien à réutiliser, même en le voulant.

## 2022 : les trois patrons signent la paix

En **mai 2022, Apple, Google et Microsoft annoncent conjointement** qu'ils vont
étendre la prise en charge des identifiants FIDO — les passkeys — sur leurs
plateformes et dans leurs navigateurs.

C'est ce qui a fait passer la chose d'une note technique à un truc que tu peux
expliquer à ta mère. Jusque-là, WebAuthn voulait presque toujours dire une clé
physique en USB : excellent, et pour trois personnes. La passkey, elle, vit là où tu
as déjà le téléphone en main, et se déverrouille avec ton visage.

## Ce que ça ne règle pas

Maintenant les petites lignes, parce que le secteur va passer les prochaines années
à faire comme si elles n'existaient pas.

**La récupération reste le point mou.** Le trou n'a pas disparu : il s'est déplacé.
Si tu perds ton appareil, il faut bien que quelqu'un décide que c'est toi, et cette
décision se prend presque toujours par e-mail, par SMS, ou en parlant à un humain
dans un centre d'appels. Cet humain est exactement la même cible qu'avant. Tu as
blindé la porte d'entrée, et celle de derrière n'a pas bougé.

**La synchronisation t'attache à un écosystème.** Les passkeys sont commodes parce
que ta plateforme les réplique entre tes appareils. Autrement dit : tes clés vivent
dans le trousseau d'une entreprise précise. En sortir n'est pas impossible, mais ce
n'est pas non plus un bouton. Tu as échangé le problème de se souvenir contre celui
d'appartenir.

**Et il faut toujours pouvoir entrer si tu perds ton téléphone.** Ce qui, en
pratique, veut dire que presque aucun site n'a supprimé le mot de passe : il l'a
caché derrière un « problème de connexion ? ». Tant que ce lien existe, le mot de
passe existe, et il est aussi mauvais qu'il l'a toujours été. La chaîne casse par la
méthode la plus faible que tu acceptes, pas par la plus élégante que tu proposes.

## Que faire en attendant

Active les passkeys partout où on te les propose, et commence par ce qui fait le plus
mal en tombant : la messagerie, la banque, le compte qui te sert à entrer dans tous
les autres. C'est l'une des rares améliorations de sécurité qui, en prime, te retire
du travail.

Et ne te raconte pas d'histoires : tu vas garder des mots de passe pendant des
années, ne serait-ce qu'en plan B. Qu'ils soient longs, différents sur chaque site,
et rangés dans un gestionnaire. Si tu en veux un qui ne sorte pas de ta tête, utilise
le [générateur](/fr/) ; si tu veux savoir si celui que tu as tient un tant soit peu,
passe-le au [vérificateur](/fr/verificateur/).

La vieille question de la sentinelle — *qui vive ?* — a enfin une autre réponse.
Pendant des décennies, on répondait en disant un mot qu'on pouvait entendre.
Maintenant on répond par une signature que seul ton appareil sait produire, sans que
le mot ait jamais eu besoin d'exister. C'est la première fois qu'on change la
question au lieu du mot.

---

*Sources : W. Diffie et M. Hellman, « New Directions in Cryptography », IEEE
Transactions on Information Theory, 1976 · R. Morris et K. Thompson, « Password
Security: A Case History », Communications of the ACM, 1979 · FIDO Alliance,
constituée en 2013 · « Web Authentication: An API for accessing Public Key
Credentials », recommandation du W3C, mars 2019 · annonce conjointe d'Apple, Google
et Microsoft sur la prise en charge des passkeys, mai 2022.*