Les passkeys expliqués : au-delà des mots de passe

Les mots de passe nous font défaut depuis trente ans, et aucune règle de complexité n'y a rien changé. Les gens les réutilisent, des pages de phishing les dérobent, et des bases de données entières fuitent chaque semaine. Les passkeys sont la réponse du secteur, et en 2026 ils sont passés d'une idée prometteuse à une norme par défaut qu'Apple, Google et Microsoft imposent désormais sur des milliards d'appareils. Ce guide explique ce qu'est réellement un passkey, les compromis auxquels vous serez confronté, et un plan concret pour l'ajouter à votre produit.

Ce qu'est réellement un passkey

Un passkey est un identifiant de connexion fondé sur la cryptographie à clé publique plutôt que sur un secret partagé. Lorsqu'un utilisateur en crée un, son appareil génère une paire de clés. La clé privée reste verrouillée sur l'appareil, protégée par la même biométrie ou le même code PIN qui déverrouille le téléphone ou l'ordinateur portable. La clé publique est envoyée à votre serveur. Il n'y a aucun mot de passe à saisir, aucun secret stocké dans votre base de données, et rien qu'une fausse page de connexion puisse capturer.

Le socle technique repose sur la norme WebAuthn du W3C, combinée aux protocoles FIDO2. Vous n'avez pas besoin de mémoriser les acronymes, mais il est utile de connaître les rôles :

• L'authentificateur est l'élément qui détient la clé privée. Ce peut être le téléphone, l'ordinateur portable, ou une clé de sécurité matérielle comme une YubiKey.
• La partie de confiance est votre application, identifiée par son domaine. Ce lien avec votre domaine exact est ce qui rend les passkeys résistants au phishing.
• La cérémonie est l'échange au cours duquel votre serveur envoie un défi, l'appareil le signe avec la clé privée, et votre serveur vérifie la signature à l'aide de la clé publique stockée.

Parce que l'identifiant est cryptographiquement lié à votre domaine, un passkey créé pour yourbank.com ne se proposera tout simplement pas sur yourbank-login.co. Le site imitateur de l'attaquant ne voit jamais rien qu'il puisse réutiliser. Cette seule propriété élimine la plus grande catégorie de piratage de comptes que nous observons sur le terrain.

Passkeys synchronisés ou passkeys liés à l'appareil

Il existe deux variantes, et choisir entre elles constitue une véritable décision de conception.

Les passkeys synchronisés sont sauvegardés sur un trousseau cloud, comme iCloud Keychain, Google Password Manager, ou un gestionnaire tiers tel que 1Password ou Bitwarden. L'utilisateur peut créer un passkey sur son téléphone et l'utiliser sur son ordinateur portable quelques instants plus tard. C'est l'option la plus conviviale pour le grand public et celle qui favorise l'adoption, car perdre un appareil ne vous enferme pas dehors.

Les passkeys liés à l'appareil ne quittent jamais le matériel sur lequel ils ont été créés. Une clé de sécurité matérielle en est l'exemple classique. Ils sont plus robustes pour les scénarios à haut niveau d'assurance (pensez aux consoles d'administration, à la finance, à la santé) car la clé privée ne peut physiquement pas être copiée, mais ils exigent un plan de récupération, puisqu'une clé perdue signifie un identifiant perdu.

La plupart des produits grand public devraient privilégier les passkeys synchronisés et proposer les clés liées à l'appareil comme option de renforcement pour les comptes sensibles.

Pourquoi les passkeys surpassent les mots de passe et même la MFA classique

Il vaut la peine d'être précis sur les gains, car « plus sécurisé » à lui seul ne justifie pas le temps d'ingénierie.

1. Résistance au phishing par conception. L'identifiant ne fonctionne que sur le domaine réel. Cela ferme l'attaque qui déjoue les codes SMS et même la plupart des applications d'authentification.
2. Rien de réutilisable à voler. Votre serveur stocke des clés publiques. Une violation de base de données divulgue des données inutiles pour un attaquant, ce qui modifie votre profil de risque et vos obligations de divulgation.
3. Aucun secret partagé en transit. Aucun mot de passe ne traverse le réseau pour être intercepté, et pas de bourrage d'identifiants (credential stuffing), car il n'existe aucune liste de mots de passe à exploiter.
4. Connexion plus rapide. Un scan du visage ou une empreinte digitale battent la saisie d'un mot de passe suivie de la copie d'un code depuis une seconde application. D'après notre expérience, la conversion à l'étape de connexion s'améliore généralement une fois la friction réduite.
5. Charge de support réduite. Les réinitialisations de mot de passe font partie des tickets les plus fréquents pour tout produit. Les passkeys en suppriment discrètement une large part.

Les passkeys ne remplacent pas un programme de sécurité complet. Ils s'y inscrivent. Si vous réfléchissez à l'identité de manière plus large, ils s'intègrent naturellement au modèle que nous décrivons dans l'architecture zéro confiance expliquée, où une identité forte est le fondement de chaque décision d'accès.

Les compromis que personne ne mentionne dans la keynote

Les passkeys sont excellents, mais bien les déployer implique d'être honnête sur les aspérités.

• La récupération de compte devient le problème difficile. Vous avez déplacé le risque de « le mot de passe se fait hameçonner » vers « l'utilisateur perd l'accès à son authentificateur ». Votre flux de récupération devient la partie la plus sensible du système en matière de sécurité, car c'est le nouveau chemin qu'un attaquant ciblera.
• L'histoire inter-écosystèmes reste inégale. Déplacer un passkey synchronisé d'un compte Apple vers un compte Android n'est pas encore fluide. Les utilisateurs ancrés dans un seul écosystème s'en sortent bien. Ceux qui mélangent les appareils sont parfois désorientés.
• La gestion des appareils en entreprise ajoute des contraintes. Les ordinateurs portables gérés, les postes de travail partagés et les navigateurs verrouillés peuvent compliquer les endroits où les passkeys sont autorisés à se synchroniser.
• Vous ne pouvez pas supprimer les mots de passe dès le premier jour. Pendant une longue transition, vous ferez fonctionner les deux, ce qui signifie deux chemins de code et deux ensembles de cas limites à tester.
• Le vocabulaire de l'expérience utilisateur est peu familier. De nombreux utilisateurs n'ont jamais entendu le mot passkey. Des textes clairs et de bonnes solutions de repli comptent autant que la cryptographie.

Aucun de ces points ne devrait vous arrêter. Ils ont simplement leur place dans votre plan plutôt que dans une mauvaise surprise après le lancement.

Une liste de contrôle pratique pour le déploiement

Voici la séquence que nous suivons lorsque nous ajoutons des passkeys au produit d'un client. Parcourez-la dans l'ordre plutôt que de sauter à la partie excitante.

1. Auditez votre authentification actuelle. Documentez chaque chemin de connexion : web, mobile, API, administration, et tout flux hérité. Vous ne pouvez pas ajouter proprement une nouvelle méthode tant que vous ne connaissez pas toutes les portes déjà existantes.
2. Ajoutez les passkeys en complément des mots de passe, pas à leur place. Proposez d'abord la création de passkeys comme une amélioration sur la page de sécurité du compte. Laissez les utilisateurs volontaires opter, tandis que tous les autres continuent de fonctionner.
3. Implémentez WebAuthn avec une bibliothèque maintenue. Ne codez pas la cérémonie à la main. Utilisez une bibliothèque serveur bien prise en charge (par exemple SimpleWebAuthn dans l'écosystème Node) et un SDK de plateforme réputé sur mobile. C'est un domaine où réinventer la roue invite des bugs de sécurité subtils.
4. Prenez en charge l'interface conditionnelle (autofill). Laissez le navigateur faire apparaître le passkey dans le champ du nom d'utilisateur afin que les utilisateurs qui reviennent se connectent d'un seul geste. Ce simple détail génère l'essentiel du gain d'adoption.
5. Concevez la récupération avant le lancement. Décidez de votre chemin de secours : un second passkey, une vérification par e-mail ou téléphone, des codes de récupération, ou un processus assisté par le support avec contrôles d'identité. Rédigez le modèle de menace pour chacun.
6. Limitez le débit et journalisez les cérémonies. Traitez l'enregistrement et l'authentification comme des événements sensibles. Alertez sur les anomalies de la même manière que pour les réinitialisations de mot de passe.
7. Sollicitez les utilisateurs existants au bon moment. Après une connexion réussie par mot de passe, proposez de créer un passkey « pour une connexion plus rapide et plus sûre la prochaine fois ». Les invitations contextuelles convertissent bien mieux qu'une bannière que personne ne lit.
8. Mesurez, puis resserrez. Suivez l'adoption des passkeys, le taux de réussite des connexions et les tickets de support. Une fois l'adoption saine sur un compte, vous pouvez envisager de rendre les mots de passe optionnels pour ces utilisateurs.

Si vous construisez le backend autour de cela, le même soin s'applique à la façon dont vous exposez les points de terminaison. Nos notes sur la conception d'API que les développeurs adorent couvrent la clarté et la discipline de versionnage qui maintiennent une surface d'authentification maintenable à mesure qu'elle grandit.

Erreurs d'implémentation courantes

Quelques schémas causent la majeure partie des difficultés que nous observons lors des revues.

• Considérer le passkey comme toute la sécurité. Il protège la connexion. Il ne corrige pas une gestion de session faible, l'absence de limitation de débit ou un flux d'e-mail de récupération non sécurisé.
• Oublier l'identifiant de la partie de confiance. Une mauvaise configuration du lien de domaine est le bug le plus fréquent, et il casse la connexion ou, pire, affaiblit la protection contre le phishing pour laquelle vous êtes venu.
• Aucun plan pour les appareils perdus. Lancer sans flux de récupération garantit une vague d'utilisateurs bloqués dès que quelqu'un change de téléphone.
• Négliger la piste d'audit. Si vous ne pouvez pas voir quand et où les passkeys ont été enregistrés, vous ne pourrez pas enquêter plus tard sur un passkey suspect.
• Supposer que chaque utilisateur est prêt. Conservez une solution de repli claire et une aide en langage simple. L'adoption est une courbe, pas un interrupteur.

Comment Innovation T peut vous aider

Chez Innovation T, nous construisons et sécurisons les systèmes qui se trouvent derrière la boîte de connexion. Lorsqu'un client demande une connexion sans mot de passe, nous ne nous contentons pas de câbler WebAuthn et de partir. Nous cartographions la surface d'authentification existante, concevons un flux de récupération qui tient face à un vrai modèle de menace, implémentons les cérémonies avec des bibliothèques maintenues, et mettons le résultat sous pression. Si vous utilisez déjà des mots de passe, nous planifions une migration progressive qui ajoute les passkeys sans casser un seul utilisateur existant.

Les passkeys sont un contrôle au sein d'un tableau plus large, aussi associons-nous souvent ce travail à une revue plus étendue. Un audit de sécurité ciblé pour votre site web vous indique où se situe l'authentification parmi vos risques réels, et où la prochaine heure d'ingénierie rapporte le plus.

Si vous voulez une authentification sans mot de passe que vos utilisateurs apprécient réellement et que vos auditeurs approuvent vraiment, explorez nos services d'ingénierie logicielle et cloud ou contactez-nous. Nous vous aiderons à décider quoi construire, dans quel ordre, et comment le déployer en toute sécurité.