L’authentification ne se résume pas à “se connecter” : elle permet aussi de transmettre des attributs. Distinguer l’identification de l’authentification, c’est comprendre la différence entre indiquer et prouver qui l’ont est. Dans ce cadre, deux approches modernes souvent regroupées sous l’étiquette passwordless se distinguent : les passkeys et les Verifiable Credentials (VC).
Salon de la Data et de l’IA
Nantes 22 Sep 2026 09h00 – 19h00Bien que ces deux approches permettent toutes deux de s’authentifier sans identifiant ni mot de passe, les réponses apportées ne visent pas exactement les mêmes besoins. Ainsi, les passkeys offrent uniquement la possibilité d’authentifier un utilisateur déjà connu, les VC permettent simultanément l’identification et l’authentification.
Dans cet article, nous allons comparer ces deux approches afin de répondre à la question :
« Qu’est-ce que vous cherchez à prouver lors d’une authentification ? ».

Pourquoi repenser les parcours d’authentification
L’article « Authentification Web et Identité décentralisée : les défis pour une nouvelle ère de confiance numérique » évoque précisément les limites des méthodes d’authentification traditionnelle face aux exigences croissantes de sécurité et d’expérience utilisateurs.
Il met en avant une réalité opérationnelle : les parcours de connexion restent une source majeure de friction et de pertes de chiffre d’affaires (complexité, mots de passe oubliés, réinitialisations, sollicitations du support), tout en constituant une porte d’entrée pour les fraudes et les attaques.
Dans ce contexte, les organisations cherchent à remplacer les mécanismes “mot de passe + dérivés” par des approches plus robustes. Les dernières investigations menées par le site Zataz prouvent que le mot de passe reste un point faible.
Chiffres clés
Source : Site spécialisé Zataz.com – Article de Damien Bancal « Un milliard d’identifiants français sur le darkweb« .
C’est dans cet environnement que deux modes d’authentification modernes, dit passwordless, se déploient pour renforcer la sécurité et simplifier la vie des utilisateurs.
Passkey : une preuve d’authentification centrée device
Une passkey est une approche d’authentification sans mot de passe qui vise à répondre à la question : « le titulaire du moyen d’accès est-il bien celui qui initie la connexion ? ».
Concrètement, elle repose sur une cryptographie dite asymétrique, basée sur une paire de clés (valeur mathématique utilisée par un algorithme pour chiffrer, déchiffrer ou signer des données) :
- une clé publique, qui sert à vérifier une signature (ou à établir des paramètres de chiffrement). Elle peut être partagée librement et enregistrée côté service.
- une clé privée, qui sert à signer (ou à déchiffrer). Elle doit rester strictement secrète et n’être accessible que par son propriétaire.
Le mécanisme
Prenons le cas d’un utilisateur qui crée une passkey pour son compte sur un site.
- Lors de l’enregistrement, après s’être identifié, le service demande à l’appareil de créer une passkey pour ce compte précis, donc pour ce site, et selon les paramètres du navigateur/OS. L’appareil génère une paire de clés. Pour valider l’enregistrement, l’utilisateur doit déverrouiller son appareil avec un moyen d’accès (ex. empreinte digitale, code PIN…). Le service conserve la clé publique, tandis que la clé privée reste protégée sur l’appareil.
- Lors de la connexion, l’utilisateur déverrouille localement son moyen d’accès – téléphone/PC. En arrière-plan, le système produit une preuve cryptographique qui permet au service de valider l’authenticité. Le site peut alors faire le lien entre la clé privé du téléphone et la clé publique enregistré sur le site, et le cas échéant valider l’étape d’authentification.
Cette approche est dite Hardware-bound (liée au matériel) : la clé privée est générée et protégée par les mécanismes de sécurité de l’appareil. Ainsi, elle n’est pas transmise sur Internet et n’est pas exportée “en clair” vers le site. Le rôle de la biométrie/PIN est principalement de déverrouiller localement l’usage de la clé privée.
Le parcours utilisateur
Lorsqu’une méthode d’authentification par passkey est mise en place, cette dernière est généralement proposée dans l’espace compte ou paramètres. Pour l’activer, l’utilisateur doit confirmer l’enregistrement via un mécanisme de déverrouillage de son appareil (empreinte, Face ID, code).
Lors des connexions suivantes, il n’y a plus de saisie d’identifiant/mot de passe : l’utilisateur valide simplement l’action de déverrouillage, et le système génère automatiquement la preuve permettant l’accès.
Dans de nombreux scénarios, l’expérience est très simple avec à la clé une connexion rapide, parfois un support cross-device (i.e. le passage du smartphone au laptop avec le scan d’un QR code), et une validation locale via les mécanismes de l’appareil.
Les apports
- Meilleure expérience utilisateur : suppression des mots de passe à mémoriser, réduction des parcours de réinitialisation, connexion fluide.
- Sécurité renforcée : résistance au phishing améliorée (pas de secret réutilisable), limite les scénarios de compromission.
- Intégration simplifiée : standards matures et largement supportés, sans nécessiter la création d’un modèle d’attestation comme c’est le cas pour les VC.
Les limites
- Centrée sur l’authentification : la passkey prouve la possession d’un moyen d’accès, mais elle ne fournit pas nativement une logique de preuve d’attribut (rôle, statut, appartenance certifiée). Autrement dit la passkey prouve que l’utilisateur a accès à un compte, mais elle ne garantit pas, à elle seule, des éléments comme un rôle, une appartenance, un statut, ou des caractéristiques métier certifiées.
- Dépendance à un device/navigateur et au modèle de synchronisation associé : l’expérience et la portabilité peuvent dépendre des mécanismes de synchronisation (iCloud, gestionnaire de mot de passe Google… ; restaurations ; changements de contexte).
- Non conforme aux exigences eIDAS v2 : cette méthode ne couvre pas à date les enjeux et obligations liées à l’European Digital Identity Wallet (EUDI Wallet).
Verifiable Credentials (VC) : une preuve d’identité pouvant supporter l’autorisation
Les Verifiable Credentials (VC) s’inscrivent dans une approche SSI (Self Sovereign Identity) : l’utilisateur dispose d’un wallet qui contient des attestations numériques signées et vérifiables. Ici, la question n’est plus uniquement « êtes-vous le bon utilisateur ? ». Elle devient aussi :
- Quelles informations certifiées pouvez-vous présenter ?
- Sur quelle base accordons-nous l’accès ?
Le mécanisme
Un VC est une preuve numérique :
- émise par une autorité (issuer),
- signée cryptographiquement,
- stockée dans un wallet,
- présentée à un vérificateur (verifier) qui contrôle sa validité.
Une première attestation peut naturellement couvrir un cas d’usage simple : par exemple une attestation de membre pour permettre à l’utilisateur d’accéder à un compte ou à un espace client. On peut également y intégrer des attributs tels qu’un rôle (ex. Profil acheteur, profil vendeur), une affiliation (groupe VIP, …), un statut actif, des droits d’accès, un niveau d’habilitation, etc. afin que le service puisse appliquer une logique d’autorisation après vérification de la preuve.
Dans une logique standardisée VC, les échanges s’appuient sur des protocoles pour soutenir l’interopérabilité, notamment OpenID4VCI et OpenID4VP.
Authentification Web et Identité décentralisée : les défis pour une nouvelle ère de confiance numérique
Lire aussiLe parcours utilisateur
Le parcours s’organise en deux temps :
- émettre des attestations vérifiables
- présenter ces preuves au service à la demande.
Lorsqu’un utilisateur initie le parcours (depuis une application mobile ou depuis un contexte où il est déjà authentifié), il demande et reçoit une attestation vérifiable (VC) qu’il conserve dans son wallet. Cette action est généralement réalisée une seule fois (ou lors d’un renouvellement / d’un changement de statut).
Lorsque l’utilisateur souhaite se connecter à l’interface depuis un PC, le service déclenche une demande de preuve et affiche un QR code. L’utilisateur scanne le QR code avec son smartphone. Le wallet est automatiquement appelé, l’utilisateur sélectionne et/ou valide (selon la configuration) les attributs nécessaires, puis le wallet partage une preuve vérifiable au service.
Au terme de la vérification, l’utilisateur est identifié et autorisé selon les attributs présentés :
- si l’attestation prouve uniquement la qualité de “membre”, l’accès est accordé à l’espace standard,
- si l’attestation porte aussi des attributs (ex. rôle ou droits), le service peut conditionner l’accès à des zones spécifiques (parcours B2B, accès à des ressources sensibles, fonctionnalités réservées, etc.).
Cette action est à réaliser à chaque connexion.
Dans un scénario same-device, l’utilisateur reste sur son smartphone et effectue une action qui nécessite une authentification/autorisation. Le service formule une demande de preuve, et le wallet présente directement les attributs requis sans QR code.
Une trajectoire complémentaire, en 2 étapes et lié à EUDI Wallet, peut également être mise en place :
- l’utilisateur crée un compte à partir de son identité numérique européenne,
- le système émet ensuite une attestation, par exemple une attestation de membre enrichie d’attributs, qui alimente son wallet.
Cette approche permet de réutiliser la nouvelle identité et ses preuves pour les prochaines connexions, en réduisant la dépendance aux mécanismes de saisie (identifiant/mot de passe) tout en ouvrant la porte à des scénarios d’autorisation plus riches.
Les apports
- Autorisations via attestation vérifiable : la méthode ne se limite pas à “vous êtes authentifié”, elle peut intégrer “vous êtes autorisé” grâce aux attributs certifiés. Le VC permet de porter une preuve d’attributs (ex. “membre”, “employé”, “rôle”, “droit d’accès”). Le service peut alors aller au-delà de l’authentification : il valide la preuve, puis accorde l’accès (ou applique des règles) sur une base vérifiable.
- Portabilité via le wallet : au lieu d’un simple mécanisme d’accès lié à un compte et à un service particulier, les VC sont portés par un wallet. Cela favorise une logique de réutilisation des attestations dans différents parcours /interface (absence de dépendance avec un nom de domaine), selon les besoins de preuve.
- Minimisation et maîtrise des données : la présentation de preuves peut être conçue pour limiter les informations exposées.
- Préparation “EUDI Wallet / 2027” : bien que l’EUDI Wallet ne soit pas le sujet central ici, c’est un repère important. S’aligner sur les mécanismes SSI/VC revient à préparer une architecture où les preuves et l’interopérabilité “wallet” sont au cœur de l’expérience attendue à horizon 2027.
Les limites
Une approche VC n’est pas “automatiquement plug-and-play”. Elle est particulièrement pertinente lorsque le besoin métier dépasse la seule suppression du mot de passe.
Elle requiert notamment :
- Un cadrage des preuves : quels attributs (claims) sont émis, à quelle granularité, selon quelles règles de validités, quel format…
- Une gouvernance : qui émet quelles attestations ? comment le service vérifie la validité et la conformité ? comment sont gérés les listes de confiance ?
- La gestion du cycle de vie des preuves : expiration, renouvellement, révocation ou mise à jour
- Une intégration plus exigeante pour certains cas d’usage
En résumé, l’approche VC est particulièrement pertinente quand votre besoin dépasse l’authentification et inclut la vérification d’attributs métier, la gestion d’autorisations et la préparation à une trajectoire wallet/interopérabilité.
Passkey vs Verifiable Credential : ce que valide le service
Pour comparer ces approches, il faut changer l’angle : ce n’est pas “quelle technologie est la meilleure”, mais “quelle intention métier cherchez-vous à servir ?”.
| Critères | Passkey | Verifiable credential (VC) |
|---|---|---|
| Question fondamentale | Prouver la possession d’un moyen d’accès Es-tu le détenteur légitime de ce compte ? |
Prouver une identité ou un attribut certifié Prouver qui tu es ou l’attribut que tu possèdes ? |
| Ce que le service valide | Une authentification de connexion, sans mot de passe | Une Preuve vérifiable puis un accès (Authentification et autorisation) |
| Gestion des autorisations | Limitée nativement | Intégrée |
| Portée d’usage | Limité à un nom de domaine | Portable entre plusieurs services et organisations |
| Portabilité entre parcours / organisations | Dépendance à un écosystème (Apple, Google…) | Pensée pour être portable via wallet & attestations |
| Préparation EUDI | NA | Directement alignée avec l’approche wallet/VC |
| Autres usages | NA | Oui, prouver son identité pour voyager, ouvrir un compte, louer une voiture, accéder à un site spécifique… |
Quels sont les objectifs recherchés avant d’adopter une solution :
- Réduction uniquement des frictions à la connexion ou/et validation d’attributs ou d’identité (rôle, statut, droits, appartenance)
- Présence de parcours ou d’accès nécessitant des preuves certifiées (onboarding réglementé, espace B2B, accès à des ressources sensibles)
- Recherche de confidentialité et la minimisation des données structurantes (divulgation sélective, consentement)
- Préparation à la règlementation autour de l’EUDI wallet (fin 2027)
- Les niveaux de confiance et de souveraineté recherchés (authentification, ou dans la capacité à vérifier des attestations signées ; nature des technologies proposées) ?
En identifiant correctement les besoins, le choix d’architecture s’imposera.
Passkeys ou Verifiable Credentials : définissez votre objectif prioritaire
En résumé, bien que les passkeys et les Verifiable Credentials apportent une solution de passwordless, elles répondent à des besoins différents :
- Si votre objectif prioritaire est de supprimer les mots de passe et de réduire la friction, les passkeys constituent une réponse pragmatique, particulièrement adaptée aux parcours B2C / grand public.
- Si votre objectif inclut la vérification d’attributs métier et la préparation d’une trajectoire “wallet” fondée sur les attestations, l’approche Verifiable Credential apporte une valeur structurelle. Elle devient déterminante dès que le parcours exige de valider des informations métiers certifiées : souscription, vérification d’identité de type KYC, accès B2B à des espaces spécifiques, ou gestion de rôles au sein d’un système étendu.
La question clé côté organisation reste la suivante : devez-vous uniquement prouver que quelqu’un a le moyen d’accès, ou devez-vous aussi prouver des rôles et attributs métier de manière vérifiable, tout en préparant la trajectoire EUDI wallet (repère 2027) ?
En d’autres termes, les véritables enjeux consistent à déterminer où se situe la limite entre authentification et validation de preuves, et quel niveau de souveraineté vous souhaitez mettre en place.
👉 Retrouvez toute notre actu en temps réel en nous suivant sur LinkedIn
Commentaire (0)
Votre adresse de messagerie est uniquement utilisée par Orange Business, responsable de traitement, aux fins de traitement de votre demande et d’envoi de toute communication de Orange Business en relation avec votre demande uniquement. En savoir plus sur la gestion de vos données et vos droits.