Les passkeys site web ne doivent pas remplacer tous vos mots de passe du jour au lendemain en 2026. La bonne approche consiste plutôt à les proposer comme méthode de connexion principale, tout en gardant temporairement les mots de passe et la double authentification pour les utilisateurs non prêts. Gain attendu : moins de phishing, moins de support lié aux mots de passe oubliés, mais un projet à cadrer sérieusement côté expérience utilisateur et sécurité.
Passkeys site web : ce qui change vraiment pour votre projet
Une passkey est une clé de connexion sans mot de passe, basée sur FIDO2 et WebAuthn, le standard web utilisé par les navigateurs modernes. Concrètement, votre site stocke une clé publique, tandis que la clé privée reste chez l’utilisateur, dans son appareil ou son gestionnaire de passkeys comme iCloud Keychain, Google Password Manager, Windows Hello, 1Password ou Dashlane.
La différence avec un mot de passe est simple : rien de secret n’est saisi dans un formulaire. L’utilisateur valide sa connexion avec son empreinte, son visage, son code appareil ou une clé de sécurité. Le site vérifie ensuite une signature cryptographique, c’est-à -dire une preuve mathématique que la bonne clé privée a été utilisée.
Pour un dirigeant, l’intérêt n’est pas théorique. Les passkeys réduisent fortement le risque de phishing, car l’identifiant cryptographique est lié au domaine du site, par exemple votresite.fr. Si un pirate crée une fausse page de connexion sur un autre domaine, la passkey ne fonctionne pas comme sur le vrai site.
En mai 2026, la FIDO Alliance estimait à 5 milliards le nombre de passkeys en usage actif dans le monde. C’est massif, mais ce n’est pas une adoption universelle. La même communication parlait d’une étape, pas d’une ligne d’arrivée. Autrement dit : le sujet est mûr, pas magique.
Pourquoi les passkeys réduisent les risques sans tout régler
Le principal bénéfice des passkeys site web tient à leur résistance au phishing. Le NIST, dans SP 800-63B-4 publié en 2025, rappelle que les mots de passe ne sont pas résistants au phishing, alors que les authentificateurs FIDO/WebAuthn font partie des méthodes de MFA résistantes. MFA signifie authentification multifacteur : plusieurs preuves pour se connecter.
Cette sécurité vient du fonctionnement même de WebAuthn. À chaque connexion, le serveur génère un défi temporaire, appelé challenge. Le navigateur transmet ce défi à l’authentificateur de l’utilisateur, qui le signe avec la clé privée. Le serveur vérifie ensuite l’origine du site, le RP ID (l’identité du service), les indicateurs de vérification utilisateur et la signature.
Dit autrement, ce n’est pas seulement un bouton plus moderne. C’est une architecture de connexion différente. Elle limite les mots de passe réutilisés, les bases de données de mots de passe volées, les attaques par hameçonnage et une partie des appels au support.
Mais elle ne supprime pas tous les risques. Une mauvaise implémentation peut créer des comptes bloqués, des parcours incompréhensibles ou des failles autour de la récupération de compte. Sur les projets que nous menons, nous voyons souvent que la récupération d’accès est moins bien pensée que l’inscription. C’est pourtant là que les utilisateurs paniquent, surtout en B2B.
Remplacer les mots de passe : oui, mais rarement en une seule étape
Google recommande encore, dans ses guides développeurs 2025, de conserver les mécanismes existants comme les mots de passe et la 2FA pendant la transition. La raison est pragmatique : tous les utilisateurs ne comprennent pas les passkeys, tous les environnements ne les autorisent pas encore, et certains appareils professionnels restent verrouillés par la DSI.
Pour un site e-commerce, un extranet client ou une plateforme SaaS, la stratégie la plus sûre est progressive. Vous ajoutez d’abord les passkeys comme option après une connexion classique. Puis vous encouragez leur création. Ensuite seulement, vous les mettez en avant comme méthode par défaut pour les utilisateurs compatibles.
Le piège fréquent consiste à croire que “sans mot de passe” signifie “sans friction”. En réalité, le premier enregistrement d’une passkey doit être accompagné : message clair, appareil utilisé, méthode de secours, explication courte. Un libellé flou comme “créer une clé d’accès” peut faire chuter l’adoption si votre audience n’est pas technophile.
Cas typique où la solution évidente est mauvaise : imposer les passkeys à tous les clients d’un portail B2B dès la première connexion. Si vos utilisateurs se connectent depuis des postes partagés, des environnements Citrix, des navigateurs anciens ou des smartphones non gérés, vous risquez de déplacer le problème vers le support. À ce budget, mieux vaut une migration guidée qu’une bascule brutale.
Budget, délais et arbitrages pour une PME française
Le coût dépend moins de la passkey elle-même que de votre système d’authentification actuel. Un site WordPress simple avec comptes clients, une application Laravel, un back-office Symfony ou une plateforme React/Node.js n’ont pas le même niveau de dette technique. Le mot désigne ici le coût accumulé par les choix passés.
Pour donner un ordre de grandeur honnête sur le marché français, l’ajout de passkeys sur un site existant démarre souvent autour de 4 000 à 8 000 euros HT si l’authentification est propre et bien documentée. Pour une application métier avec rôles, SSO, mobile, audit de sécurité et scénarios de récupération, on voit plutôt des enveloppes de 12 000 à 30 000 euros HT selon les prestataires.
Les délais suivent la même logique. Une preuve de concept peut tenir en une à deux semaines. Une mise en production sérieuse prend plutôt quatre à huit semaines, car il faut tester les navigateurs, les appareils, les emails de récupération, les cas de perte de téléphone, les comptes déjà existants et les journaux de sécurité.
| Projet | Délai réaliste | Budget indicatif France | Point de vigilance |
|---|---|---|---|
| Ajout passkeys sur espace client simple | 2 à 4 semaines | 4 000 à 8 000 € HT | Compatibilité navigateur et messages utilisateur |
| Plateforme SaaS avec rôles et 2FA | 4 à 8 semaines | 10 000 à 20 000 € HT | Migration des comptes existants et support |
| Application web + mobile iOS/Android | 6 à 12 semaines | 15 000 à 35 000 € HT | Cohérence entre WebAuthn, Android, iOS et récupération |
| Refonte complète de l’authentification | 8 à 16 semaines | 25 000 € HT et plus | Architecture, RGPD, audit, SSO, supervision |
Ces montants ne remplacent pas un chiffrage, mais ils évitent un malentendu : les passkeys ne sont pas juste un plugin à activer. Elles touchent à la connexion, donc au chiffre d’affaires, aux données personnelles et à la confiance. Pour un site à faible risque, l’investissement peut attendre. Pour un espace client manipulant factures, données RH ou informations médicales, l’arbitrage change vite.
Ce qu’il faut vérifier avant de lancer le chantier
Avant de demander un devis, cartographiez les usages réels. Qui se connecte ? Depuis quels appareils ? À quelle fréquence ? Avec quels droits ? Un administrateur qui modifie des coordonnées bancaires n’a pas le même niveau de risque qu’un lecteur occasionnel de contenu premium.
Votre hébergement et vos couches de sécurité comptent aussi. Un site derrière Cloudflare, avec TLS correctement configuré, journaux d’accès et protection anti-bot, part sur de meilleures bases qu’une application ancienne exposée directement. Les questions de certificats et de chiffrement rejoignent d’ailleurs des sujets plus larges comme la migration des certificats SSL face à la cryptographie post-quantique.
Voici les critères à poser noir sur blanc avant de développer :
- Définir les comptes concernés en priorité : administrateurs, clients, partenaires, collaborateurs.
- Prévoir une méthode de récupération robuste en cas de perte d’appareil ou de départ d’un salarié.
- Conserver temporairement les mots de passe ou la 2FA pour les cas non compatibles.
- Tester Chrome, Safari, Edge, Firefox, iOS, Android, Windows Hello et macOS selon votre audience.
- Documenter les traitements de données personnelles dans le cadre du RGPD, notamment les journaux de connexion.
- Former le support client avec des scripts simples, car les premières questions seront très concrètes.
Les iframes méritent un mot. En 2026, web.dev rappelle que les navigateurs désactivent WebAuthn par défaut dans les iframes cross-origin, c’est-à -dire intégrées depuis un autre domaine, à cause de risques comme le clickjacking ou les iframes cachées. Si votre parcours de paiement, de SSO ou d’inscription repose sur des intégrations externes, ce détail peut bloquer le projet.
Impact sur l’expérience utilisateur et la conversion
Une passkey bien intégrée accélère la connexion. Sur mobile, l’utilisateur valide avec Face ID, Touch ID, Android Biometrics ou le code de l’appareil. Il n’a plus à retrouver un mot de passe, attendre un email ou recopier un code SMS.
Pour autant, la conversion dépend du moment où vous proposez la passkey. La demander trop tôt peut inquiéter. La proposer juste après une connexion réussie, avec une phrase courte du type “Connectez-vous plus vite la prochaine fois”, fonctionne souvent mieux. Honnêtement, cette technologie ne se justifie que si le parcours est plus simple que l’ancien.
L’autre arbitrage concerne l’identité de marque et les interfaces natives. Les fenêtres de création de passkey sont contrôlées par le navigateur ou le système d’exploitation. Vous ne maîtrisez pas tout le design. Pour un projet mobile, il faut aussi aligner cette expérience avec les conventions iOS et Android ; certains choix d’interface rejoignent les réflexions menées sur l’adoption des nouveaux codes visuels iOS sur le web.
Côté agence, le réflexe est de prototyper le parcours avant de coder toute l’architecture. Trois écrans testés avec quelques utilisateurs réels évitent parfois deux semaines de développement mal orienté. Simple. Mais rarement fait assez tôt.
Faut-il choisir une solution existante ou développer WebAuthn soi-même ?
Deux voies existent. Vous pouvez utiliser un fournisseur d’identité comme Auth0, Okta, Microsoft Entra ID, Firebase Authentication ou Amazon Cognito lorsqu’il correspond à votre architecture. Vous pouvez aussi intégrer WebAuthn directement dans votre backend, avec des bibliothèques maintenues pour Node.js, PHP, Python, Java ou Go.
La solution externe réduit le risque technique et accélère le lancement. En contrepartie, elle ajoute un coût récurrent, une dépendance fournisseur et parfois une rigidité dans l’expérience. Le développement interne donne plus de contrôle, mais exige une vraie compétence sécurité : challenge serveur, vérification d’origine, stockage des clés publiques, compteurs, révocation, audit.
Pour une PME, la décision se prend rarement sur la beauté technique. Elle se prend sur le risque métier. Si l’authentification n’est pas votre différenciation, un fournisseur reconnu peut être rationnel. Si votre plateforme gère des règles complexes, des applications mobiles et un SI interne, une intégration maîtrisée devient plus défendable.
Ce choix s’inscrit souvent dans une réflexion plus large sur l’architecture du site, les frameworks et l’exploitation. Les arbitrages techniques autour de JavaScript, par exemple, peuvent aussi influencer la maintenance, comme le montre le choix entre Bun, Deno et Node.js pour un projet web en 2026. Et si vous partez d’une refonte complète, le cadrage avec une agence locale pour la création de site web aide à relier sécurité, budget et objectifs commerciaux.
Les passkeys d’Apple ont beaucoup contribué à populariser le sujet auprès du grand public ; pour un rappel historique utile, l’évolution de la fonction Passkey d’Apple montre bien comment le sans mot de passe est passé d’une promesse à un usage courant.
Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : choix de migration, messages utilisateurs, sécurité de récupération, compatibilité avec l’existant. C’est souvent là qu’un regard extérieur fait gagner du temps, surtout quand la connexion conditionne directement le chiffre d’affaires ou l’accès à des données sensibles.
FAQ sur les passkeys pour site web
Les passkeys remplacent-elles totalement les mots de passe en 2026 ?
Pas encore pour la majorité des sites. Les passkeys peuvent devenir la méthode principale, mais garder un mode de connexion de secours reste recommandé pendant la transition.
Un site WordPress peut-il utiliser des passkeys ?
Oui, à condition d’utiliser une extension fiable ou un développement adapté au système de comptes. Pour un site vitrine sans espace membre, l’intérêt est limité ; pour un espace client ou administrateur, le gain de sécurité peut être réel.
Les passkeys sont-elles compatibles avec tous les navigateurs ?
Les grands navigateurs modernes les prennent en charge, notamment Chrome, Safari, Edge et Firefox selon les plateformes. Il faut tout de même tester votre audience réelle, surtout en environnement professionnel verrouillé.
Que se passe-t-il si un utilisateur perd son téléphone ?
Il peut récupérer ses passkeys via son compte Apple, Google, Microsoft ou son gestionnaire, selon la configuration. Votre site doit aussi prévoir une procédure de récupération sûre, sinon le support deviendra le point faible.
Les passkeys suffisent-elles pour être conforme au RGPD ?
Non. Elles améliorent la sécurité de l’accès, mais le RGPD couvre aussi la minimisation des données, les durées de conservation, les droits des personnes et la documentation des traitements.