---
url: 'https://www.corbado.com/fr/blog/passkeys-prestataire-paiement-sdk-tiers'
title: 'Passkeys pour les prestataires de paiement : comment créer un SDK tiers'
description: 'Découvrez comment créer des passkeys cross-origin en tant que prestataire de paiement. Comparez les iframes et les redirections, offrez une expérience utilisateur digne d''Apple Pay et utilisez les données analytiques pour une meilleure adoption.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2025-07-15T13:24:52.541Z'
lastModified: '2026-04-15T06:03:31.525Z'
keywords: 'psp, prestataire de services de paiement, passkeys prestataire de paiement'
category: 'Passkeys Strategy'
---

# Passkeys pour les prestataires de paiement : comment créer un SDK tiers

## 1. Introduction : Pourquoi les prestataires de paiement ont-ils besoin des passkeys ?

Les passkeys s'imposent comme la méthode la plus efficace pour sécuriser et autoriser les
transactions en ligne, améliorant considérablement la sécurité et la commodité par rapport
à l'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) multifacteur
(MFA) traditionnelle. Récemment,
[PayPal a adopté les passkeys comme principale solution MFA autonome](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/),
lançant une tendance claire pour les prestataires de [paiement](https://www.corbado.com/passkeys-for-payment) du
monde entier.

Cependant, les passkeys ont été initialement conçus pour des contextes dits « first-party
», ce qui signifie qu'ils fonctionnent de manière optimale lorsque les utilisateurs
s'authentifient directement sur le site web ou l'application qui détient les informations
d'identification. Les prestataires de [paiement](https://www.corbado.com/passkeys-for-payment), en revanche,
opèrent généralement dans des contextes tiers, où leurs services (tels que les formulaires
de [paiement](https://www.corbado.com/passkeys-for-payment) ou les SDK) sont intégrés aux sites web et
applications des commerçants. Cette inadéquation fondamentale entre la conception des
passkeys et les modèles opérationnels des prestataires de paiement présente des limites
critiques pour une intégration transparente. Pour relever ces défis, nous devons explorer
deux questions essentielles :

**1. Quelles sont les limites actuelles de l'utilisation des passkeys dans des contextes
tiers pour les prestataires de paiement ?** **2. Comment les prestataires de paiement
peuvent-ils surmonter ces limites pour réussir l'implémentation d'intégrations de passkeys
tierces ?**

En examinant ces questions, nous révélerons que les efforts continus de l'industrie pour
adapter les passkeys aux contextes tiers – en particulier via des standards web comme la
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) – sont bloqués par
des barrières stratégiques implicitement imposées par Apple. Plus précisément, le support
limité d'Apple pour la création de passkeys [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)
dans Safari et l'absence de support pour le standard
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) représentent un obstacle
majeur, compliquant l'adoption transparente de
l'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) basée sur les
passkeys par les prestataires de paiement tiers. Comprendre et surmonter ces obstacles est
essentiel pour tout prestataire visant à offrir des expériences de paiement fluides et
sécurisées.

## 2. Les avantages des passkeys dans l'écosystème des paiements

Les passkeys apportent une [connexion biométrique](https://www.corbado.com/fr/faq/banques-passkeys) et résistante
au [phishing](https://www.corbado.com/glossary/phishing) à chaque maillon de la chaîne de paiement. Voici une
analyse des avantages que chaque acteur de la chaîne de valeur des paiements peut tirer de
l'intégration de
l'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) par passkey.

### 2.1 Les passkeys pour les commerçants

**Impact :** Paiement plus rapide, conversion plus élevée, moins d'abandons de panier.
**Opportunité :** Les commerçants proposant des passkeys via des SDK ou des flux de
redirection peuvent reproduire une expérience utilisateur digne
d'[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) et réduire la dépendance aux mots de passe ou
aux codes OTP, ce qui renforce la confiance et augmente les ventes.

### 2.2 Les passkeys pour les titulaires de carte / clients

**Impact :** [Authentification sans mot de passe](https://www.corbado.com/fr/faq/banques-passkeys) et
transparente sur tous les appareils. **Opportunité :** Les passkeys offrent une meilleure
expérience utilisateur que les codes OTP ou SMS et éliminent le risque de
[phishing](https://www.corbado.com/glossary/phishing). Une adoption large pourrait faire des passkeys le nouveau
standard pour la vérification des titulaires de carte.

### 2.3 Les passkeys pour les émetteurs (banque émettrice)

**Impact :** Prévention de la fraude renforcée. **Opportunité :** Les émetteurs peuvent
proposer une [authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) basée sur les passkeys dans
les flux 3DS, réduisant les [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ûts des OTP et
améliorant la satisfaction des utilisateurs.

### 2.4 Les passkeys pour les acquéreurs (banque acquéreuse)

**Impact :** Taux d'acceptation des transactions plus élevé et moins d'échecs
d'authentification. **Opportunité :** Le support des passkeys via les
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) peut améliorer les résultats des
commerçants et réduire les frictions lors du paiement ou des flux de facturation
récurrente.

### 2.5 Les passkeys pour les prestataires de services de paiement (PSP) / passerelles de paiement

**Impact :** Réduction de la fraude, meilleure expérience utilisateur pour les commerçants
et conformité améliorée. **Opportunité :** En intégrant ou en redirigeant les flux de
passkeys, les [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) peuvent fournir une
authentification de nouvelle génération tout en maintenant la compatibilité entre les
navigateurs et les applications natives.

### 2.6 Les passkeys pour les processeurs de paiement

**Impact :** Approbations de transactions simplifiées avec moins de
[paiements](https://www.corbado.com/passkeys-for-payment) refusés. **Opportunité :** Les
[sociétés de traitement des paiements](https://dashdevs.com/blog/best-payment-processing-companies/)
peuvent intégrer la vérification par passkey dans leurs API pour réduire les risques et
supporter des alternatives biométriques à
l'[authentification forte](https://www.corbado.com/fr/blog/passkeys-dsp2) du client (SCA) pour des flux
conformes.

### 2.7 Les passkeys pour les fournisseurs de tokenisation et de portefeuilles électroniques

**Impact :** Stockage sécurisé des identifiants et réauthentification fluide.
**Opportunité :** Les fournisseurs de portefeuilles comme
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) et [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay)
utilisent déjà des flux similaires aux passkeys.

## 3. Quels prestataires de paiement ont déployé les passkeys ?

Ci-dessous, nous examinons brièvement les principaux prestataires de paiement et de cartes
de crédit et analysons s'ils ont implémenté les passkeys et de quelle manière :

### 3.1 Les passkeys Mastercard

![utilisation d'un passkey de paiement Mastercard](https://www.corbado.com/website-assets/using_mastercard_payment_passkey_7f8121856f.png)

[Mastercard](https://www.corbado.com/blog/mastercard-passkeys) a officiellement lancé son **Payment Passkey
Service**, offrant une expérience
d'[authentification sans mot de passe](https://www.corbado.com/fr/faq/banques-passkeys) intégrée aux flux EMV
3DS. Les utilisateurs peuvent créer et utiliser des passkeys liés au domaine
d'authentification de [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) (par ex.
verify.[mastercard](https://www.corbado.com/blog/mastercard-passkeys).com), permettant une
[connexion biométrique](https://www.corbado.com/fr/faq/banques-passkeys) sécurisée chez les commerçants
participants. Ce déploiement représente une étape majeure vers une authentification
résistante au [phishing](https://www.corbado.com/glossary/phishing) et conforme à la
[DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) dans l'industrie des
paiements. En savoir plus : Les [passkeys Mastercard](https://www.corbado.com/fr/blog/mastercard-passkeys)

### 3.2 Les passkeys Visa

[Visa](https://www.corbado.com/blog/visa-passkeys) a introduit son **Visa Payment Passkey Service**, intégrant
les passkeys dans le flux « Click to Pay ». En permettant aux utilisateurs de
s'authentifier de manière transparente à l'aide de la
[biométrie](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) au lieu de mots de
passe ou de codes OTP, [Visa](https://www.corbado.com/blog/visa-passkeys) vise à moderniser l'expérience de
paiement en ligne avec une sécurité et une commodité accrues pour l'utilisateur. En savoir
plus : Les [passkeys VISA](https://www.corbado.com/fr/blog/visa-passkeys)

### 3.3 Les passkeys American Express

American Express n'a pas encore lancé publiquement d'offre de passkeys. Cependant, en tant
que membre du conseil d'administration de la [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), il
est probable qu'American Express déploiera une solution d'authentification basée sur les
passkeys dans un avenir proche, conformément aux tendances plus larges de l'industrie.

### 3.4 Les passkeys PayPal

![connexion paypal avec passkeys](https://www.corbado.com/website-assets/paypal_login_passkeys_3c664c9248.png)

[PayPal](https://www.corbado.com/blog/paypal-passkeys) a été l'un des premiers prestataires de paiement à adopter
les passkeys. Leur déploiement prend en charge la
[connexion biométrique](https://www.corbado.com/fr/faq/banques-passkeys) transparente pour les comptes personnels
et professionnels sur tous les appareils. Le passkey est lié au domaine de
[PayPal](https://www.corbado.com/blog/paypal-passkeys) et est déjà disponible dans de nombreuses régions.
Cependant, leur implémentation peut être améliorée, notamment en ce qui concerne les flux
multi-appareils et la détection de plateforme. En savoir plus : Les
[passkeys PayPal](https://www.corbado.com/fr/blog/passkeys-paypal)

### 3.5 Les passkeys Klarna

Klarna n'a pas encore officiellement introduit le support des passkeys. D'après nos
observations, Klarna s'appuie fortement sur les **WebViews intégrées** dans son
application et ses SDK de paiement. Étant donné que Safari et
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) restreignent la création de passkeys dans les
iframes / WebViews, cela pourrait être une raison pour laquelle Klarna n'a pas encore
déployé les passkeys.

### 3.6 Les passkeys Block (Square)

Square a introduit la connexion par passkey pour son tableau de bord développeur et sa
console de gestion, permettant un accès sécurisé et
[sans mot de passe](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) aux outils
internes. Cependant, aucune annonce n'a été faite concernant le support des passkeys dans
les flux de paiement ou les API pour les utilisateurs finaux ou les commerçants.

### 3.7 Les passkeys Stripe

Stripe a déployé la connexion par passkey pour son tableau de bord, permettant aux
développeurs de s'authentifier à l'aide de la
[biométrie](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique). Les passkeys pour
Stripe Checkout ou Elements ne sont pas encore disponibles. Compte tenu de la forte
promotion par Stripe des **flux basés sur la redirection**, il est probable que les
passkeys, s'ils sont implémentés dans les [paiements](https://www.corbado.com/passkeys-for-payment), suivraient
cette même architecture de redirection.

### 3.8 Les passkeys BILL

À ce jour, BILL n'a fait aucune annonce publique ni mise à jour de produit concernant les
passkeys pour l'authentification.

### 3.9 Les passkeys Remitly

Remitly n'a divulgué aucun plan ni information publique sur l'implémentation de
l'authentification par passkey dans ses services.

### 3.10 Les passkeys Payoneer

Il n'y a aucun rapport public ou documentation de produit indiquant que Payoneer a adopté
ou teste la connexion ou les flux de transaction basés sur les passkeys.

### 3.11 Les passkeys Adyen

Adyen n'a pas encore introduit les passkeys dans ses flux d'authentification ou de
paiement. Aucune déclaration publique ou documentation pour les développeurs ne mentionne
le support des passkeys.

### 3.12 Les passkeys Worldpay

Worldpay n'a annoncé aucun support pour les passkeys à ce jour. Leur pile
d'authentification repose toujours sur des méthodes traditionnelles telles que les mots de
passe, les OTP et les flux basés sur 3DS.

### 3.13 Les passkeys Checkout.com

Checkout.com n'a pas encore déployé publiquement le support des passkeys. Il n'y a pas de
mises à jour pour les développeurs, d'articles de blog ou d'annonces officielles
concernant l'adoption des passkeys.

### 3.14 Les passkeys AliPay

AliPay n'a pas officiellement lancé les passkeys. Compte tenu de la tendance croissante de
l'authentification biométrique dans les écosystèmes de paiement chinois, un déploiement
pourrait avoir lieu à l'avenir, mais aucune documentation actuelle ne le confirme.

### 3.15 Les passkeys Mollie

Mollie n'a fait aucune déclaration publique ni mise à jour de produit concernant
l'adoption des passkeys dans ses systèmes d'authentification ou de paiement.

### 3.16 Les passkeys Amazon Pay

Amazon a déployé le support des passkeys pour les connexions des utilisateurs sur sa
plateforme principale. Étendre cette technologie à **Amazon Pay** serait une prochaine
étape naturelle, d'autant plus que de nombreux utilisateurs ont déjà un passkey enregistré
auprès d'Amazon, ce qui simplifierait considérablement l'intégration des utilisateurs lors
du paiement.

### 3.17 Les passkeys Braintree

Braintree, une société de [PayPal](https://www.corbado.com/blog/paypal-passkeys), n'a pas encore officiellement
adopté l'authentification par passkey. Leur documentation actuelle ne mentionne pas les
passkeys dans le contexte de la connexion des utilisateurs ou des API pour les
commerçants.

### 3.18 Les passkeys Link

Link, la solution de paiement en un clic de Stripe, a déployé les passkeys, ce qui
pourrait servir de base à la stratégie de passkeys de Stripe dans les
[paiements](https://www.corbado.com/passkeys-for-payment) grand public. Cependant, Stripe n'a pas officiellement
annoncé le support des passkeys pour Link ni de plans spécifiques de déploiement.

![connexion link avec passkeys](https://www.corbado.com/website-assets/link_passkeys_login_88b6b731dd.png)

### 3.19 Les passkeys Afterpay

Afterpay n'a publié aucune déclaration ou fonctionnalité liée au support des passkeys.
Comme Klarna, leur intégration de paiement est fortement basée sur l'application, ce qui
peut poser des obstacles techniques à l'adoption des passkeys en raison des contraintes
des [WebView](https://www.corbado.com/blog/native-app-passkeys) intégrées.

## 4. Pourquoi les efforts de l'industrie pour standardiser les passkeys sont-ils bloqués par Apple ?

L'adoption des passkeys par les prestataires de paiement tiers se heurte à des obstacles
stratégiques, principalement dus aux politiques restrictives d'Apple dans Safari. Deux
tentatives de standardisation critiques ont été constamment entravées :

- [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC)
- La création de passkeys tiers dans les iframes

### 4.1 Où Apple bloque-t-il la Secure Payment Confirmation (SPC) ?

La Secure Payment Confirmation (SPC) représente l'effort le plus important de
l'industrie - principalement mené par Google - pour permettre une utilisation transparente
et [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) des passkeys, spécifiquement conçue pour
les autorisations de paiement sécurisées. La [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
standardise la manière dont les prestataires de paiement authentifient les utilisateurs
sur plusieurs sites marchands sans compromettre la sécurité ou l'expérience utilisateur.
Cependant, Apple a constamment refusé de prendre en charge la
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) dans Safari, probablement une décision
stratégique pour s'assurer qu'[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) reste la solution de
paiement préférée et la plus fluide au sein de son écosystème. Le refus d'Apple d'adopter
la [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) non seulement limite le déploiement
généralisé des passkeys dans des contextes tiers, mais retarde également l'adoption plus
large par l'industrie d'une authentification de paiement standardisée.

Lisez cet article de blog sur la SPC si vous voulez en savoir plus sur les détails.

### 4.2 Comment les restrictions d'iframe de Safari affectent-elles la création de passkeys tiers

Une autre barrière critique concerne la restriction délibérée par Apple de la création de
passkeys dans des iframes [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn). Alors que Safari
autorise l'utilisation de passkeys existants pour l'authentification
(`navigator.credentials.get()`) dans un [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) tiers, il
bloque explicitement l'enregistrement de passkeys (`navigator.credentials.create()`) dans
de tels contextes.

Cette limitation restreint sévèrement les prestataires de paiement qui dépendent de la
création transparente de nouveaux passkeys pendant le flux de paiement du commerçant. Par
conséquent, les prestataires sont contraints soit d'adopter des approches basées sur la
redirection, soit de s'appuyer sur des passkeys existants préalablement établis
directement sur leurs propres domaines. Cette décision d'Apple affecte directement la
praticité et la fluidité des intégrations marchandes, créant un point de friction
important pour les consommateurs et les prestataires.

## 5. Comment créer un SDK de paiement tiers avec des passkeys pour le web

### 5.1 Stratégie A : Intégrer un iframe cross-origin (avantages et inconvénients)

Dans cette approche, le commerçant inclut votre formulaire de paiement dans un `<iframe>`
servi depuis le domaine de votre prestataire de paiement - par exemple,
`https://pay.provider.com`. L'utilisateur reste sur le domaine du commerçant (par ex.
`https://www.maboutique.com`), voit votre interface de paiement dans
l'[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) intégré et s'authentifie avec un passkey lié à
l'ID de la [Relying Party](https://www.corbado.com/glossary/relying-party) `pay.provider.com`.

Points clés :

- **Cross-Origin** : Comme l'[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) se trouve sur un
  domaine différent, vous devez configurer des politiques de permission pour
  [publickey-credentials-get](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
  et
  [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-create)
  pour autoriser les opérations de passkeys à l'intérieur de l'iframe.

- **Limitation de la création** : Certains navigateurs (en particulier les anciennes
  versions et Safari) n'autorisent toujours pas la création de passkeys dans les iframes
  cross-origin. L'authentification (`navigator.credentials.get()`) est plus largement
  supportée, mais l'enregistrement (`navigator.credentials.create()`) peut échouer dans
  certains environnements, notamment sur Safari.

- **Activation par l'utilisateur** : Les flux de passkeys nécessitent généralement une
  [« activation transitoire »](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
  (par exemple, un clic direct sur un bouton par l'utilisateur). Assurez-vous que votre
  interface iframe déclenche la cérémonie du passkey dans le cadre d'un événement initié
  par l'utilisateur.

- **Sécurité et expérience utilisateur** : L'approche par iframe offre une expérience de
  paiement fluide et intégrée, mais si le navigateur d'un utilisateur bloque ou restreint
  les cookies tiers ou le stockage local, cela peut perturber le flux du passkey.

![Iframe cross-origin](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/embedding_cross_origin_iframe_8b52f6996e.png)

### 5.2 Stratégie B : Approche basée sur la redirection pour une compatibilité plus large

Avec un flux basé sur la redirection, vous envoyez l'utilisateur du domaine du commerçant
vers votre domaine de paiement, ou ouvrez un nouvel onglet/fenêtre pointant vers quelque
chose comme `https://pay.provider.com/checkout`. Les passkeys sont alors créés ou utilisés
directement sur votre domaine dans un contexte first-party.

Points clés :

- **Simplicité First-Party** : L'ensemble du flux de travail du passkey (création,
  authentification) se déroule sur le domaine du prestataire de paiement, il n'y a donc
  pas de restrictions cross-origin.
  [Tous les principaux navigateurs supportent la création et la connexion par passkey](https://passkeys.eu/device-support)
  dans des contextes first-party.

- **Expérience utilisateur de la redirection** : L'utilisateur quitte la page du
  commerçant (ou voit une pop-up) pour terminer l'authentification. Cela peut être moins
  fluide, mais simplifie l'architecture du flux de passkey et réduit les complexités
  cross-origin.

- **Solution de repli pour les navigateurs incompatibles** : Vous pouvez dégrader
  gracieusement si les passkeys ne sont pas disponibles (par ex. navigateurs plus anciens)
  en fournissant des méthodes de connexion alternatives sur votre domaine de paiement sans
  avoir besoin de gérer des permissions cross-origin supplémentaires.

![Approche par redirection pour une compatibilité plus large](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 6. SDK de paiement tiers avec des passkeys pour les applications natives

L'intégration des passkeys dans les applications mobiles natives présente des défis
uniques par rapport aux scénarios web. Les applications natives pour les commerçants (sur
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) et
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) intègrent souvent les flux de paiement
dans l'application à l'aide de WebViews intégrées pour maintenir une expérience
utilisateur transparente. Cependant, l'implémentation de l'authentification par passkey
tiers dans ces contextes intégrés peut être problématique en raison des politiques
strictes d'origine du navigateur et des limitations spécifiques à la plateforme.

### 6.1 Pourquoi les passkeys des fournisseurs de passkeys ne peuvent pas être utilisés directement dans les applications natives des commerçants

Les passkeys sont intrinsèquement liés à un domaine spécifique (l'« ID de la
[Relying Party](https://www.corbado.com/glossary/relying-party) »), un principe de sécurité fondamental
garantissant que les identifiants ne peuvent pas être utilisés de manière abusive sur des
sites web ou des applications non liés. Lorsqu'un prestataire de paiement crée des
passkeys sous son propre domaine - par exemple, pay.provider.com - ces passkeys sont
strictement limités à ce domaine sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) et
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Par conséquent, une
[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) d'un commerçant (qui
fonctionne naturellement sous son propre identifiant d'application et son propre domaine)
ne peut pas invoquer directement les passkeys du prestataire en tant qu'identifiant «
first-party ». Cela nécessiterait un partage de clés privées cross-origin, ce que les
systèmes d'exploitation et les spécifications WebAuthn interdisent explicitement pour
empêcher le phishing et le vol d'identifiants.

Du point de [vue](https://www.corbado.com/blog/vuejs-passkeys) de l'appareil,
l'[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) du commerçant est une «
origine » différente de celle du domaine du prestataire de paiement. Tenter de
s'authentifier nativement avec des identifiants enregistrés pour une origine distincte
briserait le modèle de sécurité fondamental des passkeys lié à l'origine. C'est
précisément pourquoi l'utilisation de passkeys tiers dans un contexte marchand dépend d'un
navigateur système ou d'une [WebView](https://www.corbado.com/blog/native-app-passkeys) système (comme
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) sur iOS ou les onglets
personnalisés Chrome sur [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)). Ces flux
spéciaux préservent le contexte du domaine d'origine du prestataire - garantissant que les
passkeys restent solidement liés à leur origine - tout en permettant aux utilisateurs de
s'authentifier auprès du prestataire de paiement à l'intérieur de l'application d'un
commerçant. Dans les sections suivantes, nous explorerons comment cela fonctionne.

### 6.2 Les défis des WebViews intégrées : pourquoi elles cassent les passkeys

Les WebViews intégrées (par ex., [WKWebView](https://www.corbado.com/blog/native-app-passkeys) sur iOS ou la
[WebView](https://www.corbado.com/blog/native-app-passkeys) d'Android) sont très appréciées car elles permettent
aux applications d'intégrer du contenu web directement dans leurs interfaces natives,
offrant une intégration étroite et une cohérence de l'expérience utilisateur. Cependant,
ces environnements intégrés sont considérablement restreints lorsqu'il s'agit de gérer des
passkeys tiers en raison des politiques d'origine et de sécurité :

- **Incompatibilité d'origine** : Les passkeys reposent strictement sur les origines de
  domaine pour une gestion sécurisée des identifiants. Une WebView intégrée fonctionne
  sous le domaine du contenu qu'elle affiche (souvent celui du commerçant), ce qui rend
  difficile, voire impossible, la création ou l'authentification de passkeys liés
  explicitement au domaine d'un prestataire de paiement tiers.

- **Contraintes de sécurité de la plateforme** : Apple (iOS) et Google (Android) ont
  progressivement restreint les capacités des WebViews intégrées pour l'authentification,
  en particulier lorsqu'il s'agit d'identifiants sécurisés. Ces contraintes sont conçues
  pour protéger la confidentialité des utilisateurs et la sécurité, mais rendent
  l'implémentation de passkeys tiers nettement plus compliquée.

Dans l'ensemble, bien que les WebViews intégrées soient attrayantes pour les commerçants
du point de [vue](https://www.corbado.com/blog/vuejs-passkeys) de l'expérience utilisateur, elles introduisent
des limitations pratiques importantes pour la mise en œuvre de flux d'authentification par
passkey tiers robustes.

### 6.3 Utiliser une WebView système ou une redirection pour les passkeys tiers

Compte tenu des limitations associées aux WebViews intégrées, les prestataires de paiement
adoptent généralement l'une des deux stratégies alternatives pour implémenter de manière
fiable les passkeys tiers dans les applications mobiles natives :

#### 6.3.1 Utiliser une WebView système

**iOS (ASWebAuthenticationSession) :**

Apple fournit [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) comme un
environnement sécurisé de type navigateur, en dehors du contexte de l'application hôte. Il
partage le stockage des cookies avec le navigateur Safari par défaut et prend en charge
les passkeys tiers de manière fiable car les identifiants s'alignent sur le domaine
d'origine du prestataire de paiement.

L'exemple suivant montre la fonctionnalité « Payer avec PayPal » dans
l'[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) BOSS. Il montre comment une
WebView système [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) est ouverte,
partageant son état avec les cookies de Safari, ce qui permet au dialogue du passkey de
démarrer immédiatement.

![passkeys asweb ios e-commerce](https://www.corbado.com/website-assets/ios_asweb_passkeys_e_commerce_34ecd03796.jpeg)

**Android (Onglets personnalisés Chrome) :**

De même, les onglets personnalisés d'Android offrent un environnement quasi-navigateur
permettant une création et une authentification de passkeys cohérentes. Comme
ASWebAuthenticationSession, les onglets personnalisés s'exécutent séparément du contexte
de l'application du commerçant, garantissant l'intégrité du domaine et des identifiants.

Voici le même exemple de l'application native BOSS sur Android :

![passkeys asweb android paypal](https://www.corbado.com/website-assets/android_asweb_passkeys_paypal_5eb366dce2.jpeg)

#### 6.3.2 Redirection vers le navigateur par défaut

Une autre approche consiste à rediriger les utilisateurs de l'application native vers le
navigateur web par défaut de l'appareil mobile (Safari sur iOS, Chrome sur Android). Cela
garantit que le flux de paiement - et donc la gestion des passkeys - se déroule
entièrement dans un contexte first-party de confiance associé au domaine du prestataire de
paiement. Les utilisateurs retournent ensuite à l'application du commerçant après une
authentification ou un paiement réussi. Cette option est très peu pratique pour les
clients car ils doivent quitter l'application.

Les deux solutions nécessitent de faire transiter temporairement les utilisateurs hors de
l'environnement de l'application native du commerçant. Bien que légèrement moins fluides
par rapport aux solutions intégrées, ces approches améliorent considérablement la
compatibilité, la sécurité et la fiabilité des opérations de passkeys tiers.

En fin de compte, les prestataires de paiement développant des SDK natifs doivent
soigneusement équilibrer les considérations d'expérience utilisateur avec les contraintes
techniques pratiques. Malgré les préférences des commerçants pour des expériences
entièrement intégrées, l'utilisation de WebViews système ou de redirections vers un
navigateur externe reste la meilleure pratique pour garantir une authentification par
passkey tiers sécurisée et fiable dans les applications natives.

![Redirection vers le navigateur par défaut](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_to_default_browser_48b9e771a3.png)

## 7. Iframe ou redirection : quelle approche pour le paiement par passkey ?

Choisir entre une approche intégrée (iframe) et une approche basée sur la redirection pour
l'intégration de passkeys tiers dans les SDK de paiement implique d'évaluer les compromis
en matière d'expérience utilisateur, de compatibilité des navigateurs, de complexité
technique et de préférences des commerçants.

### 7.1 Tableau comparatif détaillé des approches intégrée et par redirection

Les deux solutions présentent des avantages et des inconvénients distincts, que les
prestataires de paiement doivent examiner attentivement en fonction de leur marché cible,
de l'expérience utilisateur souhaitée et de l'infrastructure technique.

| **Aspect**                                   | **Approche intégrée (Iframe)**                                                                                                                                                                                                                                                                | **Approche par redirection**                                                                                                                                                                                                                                                                                                                                                     |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Expérience utilisateur**                   | ✅ Très fluide ; les utilisateurs restent sur le site du commerçant pendant tout le processus de paiement, ce qui renforce la cohérence de la marque du commerçant.                                                                                                                           | ⚠️ Potentiellement perturbateur ; les utilisateurs quittent le site du commerçant ou rencontrent des pop-ups/nouveaux onglets, ce qui introduit des frictions.                                                                                                                                                                                                                   |
| **Compatibilité des navigateurs**            | ⚠️ Limitée en raison du blocage par Safari d'Apple de la création de passkeys cross-origin et des restrictions des navigateurs plus anciens ; support partiel, principalement pour les flux d'authentification.                                                                               | ✅ Robuste ; largement compatible avec tous les principaux navigateurs car elle fonctionne dans un contexte de domaine first-party.                                                                                                                                                                                                                                              |
| **Support des applications natives**         | ⚠️ Mauvais support ; ne fonctionne pas dans les webviews intégrées en raison de politiques d'origine strictes et de contraintes de sécurité.                                                                                                                                                  | ✅ Support solide ; facilement géré via les webviews système ou les navigateurs externes, conformément aux directives de la plateforme (iOS et Android).                                                                                                                                                                                                                         |
| **Attractivité pour les commerçants**        | ✅ Plus élevée ; les commerçants préfèrent les expériences entièrement intégrées car ils conservent le contrôle sur l'expérience utilisateur et l'image de marque.                                                                                                                            | ⚠️ Moyenne ; la redirection peut causer des frictions, ce qui peut avoir un impact sur les taux de conversion des commerçants et la satisfaction des clients, sauf si elle est gérée avec soin.                                                                                                                                                                                  |
| **Complexité de l'implémentation technique** | ⚠️ Complexité plus élevée ; nécessite une configuration précise des politiques de permission et la gestion de diverses bizarreries de navigateurs avec des limites sur les applications natives.                                                                                              | ✅ Complexité plus faible ; simple à mettre en œuvre en raison de la simplicité du first-party, ce qui réduit les pièges potentiels de l'intégration.                                                                                                                                                                                                                            |
| **Compatibilité des passkeys**               | ⚠️ Partielle ; l'authentification est largement supportée, mais la création de passkeys est particulièrement problématique en raison des limitations cross-origin.                                                                                                                            | ✅ Complète ; support total pour l'enregistrement et l'authentification des passkeys sans restrictions cross-origin.                                                                                                                                                                                                                                                             |
| **Maintenance et support**                   | ⚠️ Charge de travail plus élevée en raison des mises à jour fréquentes des navigateurs et des défis de compatibilité.                                                                                                                                                                         | ✅ Charge de travail plus faible ; maintenance plus simple, moins de mises à jour de compatibilité cross-origin requises.                                                                                                                                                                                                                                                        |
| **Exemple de bonne pratique**                | Klarna : Klarna s'est toujours extrêmement concentré sur les expériences utilisateur intégrées et a déconseillé l'utilisation des WebViews système. Pour cette raison, Klarna peine à offrir une expérience de passkey tiers complète à ses clients au moment de la rédaction de cet article. | PayPal : PayPal a toujours redirigé les utilisateurs vers son site web, imposant une approche basée sur la redirection en raison de sa puissance sur le marché et de sa longue histoire. Par conséquent, l'intégration des passkeys dans les flux de paiement a été simple et rapide à réaliser, même dans des contextes tiers, car les WebViews système étaient déjà utilisées. |

### 7.2 Résumé : Choisir le meilleur flux pour votre SDK de paiement

L'approche intégrée (iframe) offre une expérience utilisateur transparente et à l'image du
commerçant, très attrayante pour ces derniers, mais elle est entravée par une
compatibilité limitée des navigateurs, en particulier le refus de Safari d'autoriser la
création de passkeys cross-origin. Cette limitation contraint les commerçants et les
prestataires à des solutions complexes basées sur des contournements qui compromettent
souvent la fonctionnalité ou conduisent à un support incomplet de l'enregistrement des
passkeys.

Inversement, l'approche par redirection offre une compatibilité complète sur les
navigateurs et les plateformes mobiles natives en fonctionnant dans un contexte de domaine
first-party. Elle simplifie considérablement l'intégration, améliore la fiabilité et
garantit un support complet de la création et de l'authentification des passkeys. Le
principal inconvénient est la friction potentielle créée par la redirection des
utilisateurs hors du site web ou de l'application du commerçant, bien que cela puisse être
atténué par une conception UX soignée, des attentes clairement communiquées ou des
intégrations avec des plateformes de confiance comme Corbado.

Compte tenu de ces considérations, une approche hybride est souvent idéale, permettant aux
prestataires de paiement de tirer parti du modèle d'iframe intégré lorsque le navigateur
de l'utilisateur le prend en charge et de basculer gracieusement vers une approche de
redirection dans le cas contraire. Cette stratégie combinée maximise la compatibilité,
l'attractivité pour les commerçants et la satisfaction des clients dans divers
environnements.

## 8. Bonnes pratiques et recommandations pour les SDK de passkeys cross-origin

L'implémentation d'un SDK de paiement tiers avec des passkeys implique de trouver un
équilibre entre l'expérience utilisateur, la compatibilité des navigateurs, les
contraintes des applications natives, l'analytique et la sécurité - en particulier compte
tenu des obstacles spécifiques à Apple (par ex. blocage de la création de passkeys
cross-origin, absence de support SPC). Vous trouverez ci-dessous des recommandations clés
pour garantir le meilleur résultat possible lors de l'intégration des passkeys dans les
flux de paiement web ou natifs.

### 8.1 Comment mettre en place une approche SDK pour les flux de passkeys

En raison de la prise en charge variable des navigateurs et des comportements incohérents
d'Apple, il est essentiel de prendre en charge à la fois une approche intégrée (basée sur
un iframe) et une approche par redirection :

- **Paiement par Iframe (intégré)**
    - Fournit une expérience transparente sur la page pour les navigateurs modernes qui
      autorisent les opérations de passkeys cross-origin (principalement pour
      l'authentification).

    - Doit définir la bonne [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) pour
      `publickey-credentials-get`/`publickey-credentials-create`.

    - Notez que Safari et certains navigateurs plus anciens bloquent la création de
      passkeys cross-origin dans les iframes.

- **Flux de redirection**
    - Prend en charge de manière fiable l'enregistrement et la connexion par passkey dans
      un contexte first-party.

    - Légèrement plus de friction en raison de la redirection ou de la pop-up
      supplémentaire, mais universellement plus sûr pour la compatibilité entre
      navigateurs.

    - Solution de repli idéale pour Safari, qui n'autorise actuellement pas la création de
      passkeys tiers dans les iframes.

En proposant les deux approches, vous pouvez décider dynamiquement - ou laisser les
commerçants décider - laquelle utiliser, maximisant ainsi la compatibilité pour tous les
environnements utilisateur.

### 8.2 Détecter les capacités du navigateur (Safari vs. Chrome vs. Edge vs. Firefox)

La détection précise des capacités du navigateur reste difficile en raison de la
granularité réduite du [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
et du support incohérent des
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) sur les différentes
plateformes.

#### 8.2.1 Complexité de l'analyse du User-Agent

L'analyse traditionnelle est de moins en moins fiable car les navigateurs réduisent les
détails dans les chaînes [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
pour protéger la confidentialité des utilisateurs. Différencier les détails essentiels -
tels que Windows 10 vs. [Windows 11](https://www.corbado.com/blog/passkeys-windows-11), les versions précises de
macOS ou les architectures de CPU - est maintenant difficile, voire impossible, en
utilisant uniquement le [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).

#### 8.2.2 Support incohérent des Client Hints

Bien que les [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
fournissent des données à haute entropie d'une manière respectueuse de la vie privée,
seuls les navigateurs basés sur Chromium les prennent entièrement en charge. Safari et
Firefox n'offrent aucun support pour les
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), ce qui restreint
sévèrement la détection précise des fonctionnalités sur les appareils Apple.

#### 8.2.3 Contraintes des applications intégrées et natives :

Les WebViews intégrées restreignent généralement l'accès aux informations détaillées de
l'appareil et prennent rarement en charge les Client Hints. Cette limitation rend la
détection des capacités de passkey particulièrement difficile dans les contextes
d'applications natives.

Compte tenu de ces contraintes, la détection fiable du support des passkeys cross-origin -
en particulier dans les SDK de paiement tiers - nécessite une combinaison minutieuse de
requêtes dynamiques de Client Hints (lorsqu'elles sont disponibles), d'heuristiques de
User-Agent en solution de repli et de comportements par défaut conservateurs pour les
navigateurs comme Safari et Firefox.

### 8.3 Gérer les applications natives avec soin : WebView intégrée vs. WebView système

Les applications marchandes natives intègrent souvent du contenu web dans
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) (iOS) ou Android WebView, qui sont très
restrictives pour les passkeys. Les stratégies courantes incluent :

- **Sessions de navigateur système** : Utilisez ASWebAuthenticationSession (iOS) ou les
  onglets personnalisés (Android) pour déplacer la création/connexion par passkey vers un
  contexte de navigateur « first-party » sécurisé.

- **Redirection vers le navigateur par défaut** : Une approche moins transparente mais
  très fiable pour garantir l'intégrité du domaine pour les opérations de passkeys.

### 8.4 Assurer la sécurité et la conformité (PCI)

En tant que prestataire de paiement, une sécurité forte et la conformité réglementaire
(PCI, [DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) SCA, etc.) sont
essentielles :

- **En-têtes et sécurité du contenu** : Implémentez des en-têtes
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) stricts et des règles CSP robustes
  pour les flux cross-origin.

- **Journalisation et surveillance** : Journalisez minutieusement les événements de
  création et d'utilisation des passkeys pour la prévention de la fraude et les audits de
  conformité.

- **Stockage minimal de PII** : Associez les utilisateurs aux passkeys à l'aide
  d'identifiants hachés, réduisant ainsi l'exposition en vertu du
  [RGPD](https://www.corbado.com/fr/glossary/divulgation-selective) ou de lois similaires sur la protection des
  données.

- **Pistes d'audit** : Journalisez chaque événement de création et d'authentification de
  passkey pour détecter les anomalies et satisfaire les audits de conformité.

### 8.5 Test et surveillance continus des passkeys

Les passkeys sont encore en évolution, vous aurez donc besoin de vérifications continues :

- **Tests multi-navigateurs et multi-OS** : Automatisez les tests sur Safari, Chrome,
  Edge, Firefox et les principales versions d'OS mobiles.

- **Mises à jour fréquentes** : Suivez les changements dans les spécifications WebAuthn du
  W3C, les directives de la [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) ou les propositions
  SPC.

- **Commentaires des utilisateurs et taux d'erreur** : Journalisez les erreurs de passkey
  (création ou connexion) pour résoudre rapidement les problèmes, en particulier pour les
  utilisateurs basés sur Apple.

### 8.6 KPI essentiels des passkeys : comment suivre la création et la connexion

Un cadre de KPI robuste vous aide à suivre si votre intégration de passkeys tiers améliore
réellement la sécurité et l'expérience utilisateur. Même si cet article porte sur
l'implémentation de SDK, il est important de garder à l'esprit que l'adoption des passkeys
est également essentielle dans ce cas d'utilisation. Le taux de création et le taux
d'utilisation des passkeys nécessitent une analyse et une optimisation minutieuses.

#### 8.6.1 Taux d'acceptation des passkeys

- **Définition** : Pourcentage d'utilisateurs qui créent un passkey avec succès lorsqu'on
  le leur propose (par ex. lors du paiement ou de la création de compte).

- **Pourquoi c'est important** : Un taux de création élevé signifie que votre flux
  d'intégration/incitation pour les passkeys est convaincant et sans friction.

- **Cible** : Vous devriez viser un taux de 50 à 80 %.

#### 8.6.2 Taux de réussite de la création de passkeys

- **Définition** : Parmi les utilisateurs qui commencent la cérémonie de création
  (cliquent sur « [Créer un passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) »),
  combien la finalisent sans abandonner ni rencontrer d'erreur ?

- **Pourquoi c'est important** : Indique à quel point votre flux cross-origin ou de
  redirection fonctionne bien.

- **Cible** : Idéalement, vous avez un chiffre d'environ 95 à 100 % une fois qu'un
  utilisateur a choisi de participer.

#### 8.6.3 Taux d'utilisation des passkeys

- **Définition** : Le pourcentage total d'autorisations de paiement (ou de connexions)
  effectuées via des passkeys, par opposition aux méthodes de repli.

- **Pourquoi c'est important** : La création n'a pas de sens si les utilisateurs
  reviennent par défaut aux anciennes méthodes.

- **Cible** : Un taux de 50 à 80 % signale une forte adoption des passkeys.

#### 8.6.4 Taux de réussite de la connexion par passkey

- **Définition** : Pourcentage de tentatives de connexion par passkey qui réussissent sans
  erreur ni repli.

- **Pourquoi c'est important** : Un reflet de votre convivialité en conditions réelles.

- **Cible** : En général, vous devriez dépasser 90 à 95 % pour considérer les passkeys
  comme « sans friction ».

#### 8.6.5 Utilisation du repli

- **Définition** : À quelle fréquence les utilisateurs échouent-ils avec les passkeys en
  pleine cérémonie et passent-ils à un mot de passe ou un OTP ?

- **Pourquoi c'est important** : Une utilisation élevée du repli suggère que des obstacles
  techniques ou d'expérience utilisateur empêchent les passkeys de remplacer les méthodes
  héritées.

- **Cible** : Idéalement, l'utilisation du repli est inférieure à 1-5 %.

#### 8.6.6 Métriques de conversion et de fraude

Pour les prestataires de paiement, mesurez si les passkeys réduisent la fraude, accélèrent
le paiement ou diminuent l'abandon de panier. Combinez les données d'utilisation des
passkeys avec les métriques de conversion de paiement ou de succès de
[3-D Secure](https://www.corbado.com/glossary/3d-secure) pour une [vue](https://www.corbado.com/blog/vuejs-passkeys) d'ensemble.

La surveillance de ces KPI vous aide à identifier les environnements ou les parcours
utilisateur qui nécessitent une amélioration - par exemple, si Safari sur iOS a un taux
d'abandon plus élevé en raison des blocages cross-origin, vous pouvez systématiquement
diriger ces utilisateurs vers un flux de redirection.

## 9. Comment Corbado aide les prestataires de paiement à réussir avec les passkeys

### 9.1 Création de passkeys transparente : environnements bancaires, de plateforme et marchands

L'un des défis les plus critiques dans la création d'un SDK de passkeys tiers est
d'orchestrer un flux de création fluide et cohérent - où les utilisateurs enregistrent
réellement leurs passkeys. Que cela se produise dans le portail d'une banque, dans les
paramètres de compte du prestataire de paiement ou directement sur la page de paiement
d'un commerçant, les étapes fondamentales de l'enregistrement d'un passkey sont très
similaires. Par conséquent, l'approche de la création de passkeys ne change pas
fondamentalement selon que vous intégrez le flux dans un iframe ou que vous redirigez
l'utilisateur vers une page first-party ; ce qui compte le plus, c'est de fournir des
écrans clairs et conviviaux, de gérer les contraintes cross-origin et de suivre les
métriques essentielles qui montrent avec quelle efficacité les utilisateurs adoptent les
passkeys. Voici les aspects clés d'un flux de création de passkeys exemplaire et comment
Corbado les prend en charge :

#### 9.1.1 Écrans de création et composants d'interface utilisateur uniformes

Peu importe où un utilisateur est invité à
[créer un passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) - que ce soit dans
l'environnement de [banque](https://www.corbado.com/passkeys-for-banking) en ligne d'une banque, sur le site
web/l'application du prestataire de paiement ou lors du paiement d'un commerçant - Corbado
fournit des composants pré-construits et personnalisables pour les invites utilisateur,
les confirmations de succès et la gestion des erreurs.

Ces composants garantissent une apparence cohérente tout en permettant un marquage en
marque blanche afin que chaque banque ou commerçant puisse conserver ses propres éléments
de conception si nécessaire.

Voir le composant d'interface utilisateur suivant pour l'écran de
[création de passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) avec la marque
[VicRoads](https://www.corbado.com/blog/vicroads-passkeys) :

![UX optimisée pour les passkeys par Corbado](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 9.1.2 Suivi et analytique centralisés

Corbado collecte et unifie les données de tous les points de terminaison de création :

- Les sites web ou applications des banques où les passkeys sont initialement proposés.

- Les paramètres de compte personnels du prestataire de paiement (où les utilisateurs
  peuvent gérer leurs identifiants).

- Les pages de paiement des commerçants qui permettent éventuellement la création de
  passkeys « à la volée ».

Cette approche unifiée facilite la mesure du taux de création de passkeys, du taux de
réussite de la création, des points d'abandon des utilisateurs et de toute erreur
technique - quel que soit le canal qui initie l'enregistrement du passkey.

#### 9.1.3 KPI et tests A/B

Corbado propose des fonctionnalités de test A/B pour affiner les instructions à l'écran,
le texte des boutons et le moment des invites. Des changements subtils dans la formulation
(par exemple, « Créez un passkey maintenant - plus de mots de passe ! » contre « Sécurisez
votre prochain paiement avec un passkey ! ») produisent souvent des différences
significatives dans l'acceptation par les utilisateurs.

Sur la base des résultats du test A/B, les KPI suivants peuvent être optimisés :

- **Taux de création** : Pourcentage d'utilisateurs qui, une fois invités, configurent
  avec succès un passkey.

- **Taux de réussite de la création** : La part des utilisateurs qui terminent la
  cérémonie sans abandonner ni rencontrer d'erreur.

- **Utilisation du repli** : Le taux auquel les utilisateurs ignorent la création de
  passkey au profit d'anciennes méthodes de connexion.

- **Impact sur la conversion** : Pour les commerçants, mesurez si la
  [création de passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) lors du paiement
  réduit l'abandon de panier.

#### 9.1.4 Contexte de création flexible : banque, prestataire de paiement ou commerçant

Les utilisateurs peuvent créer des passkeys dans les contextes suivants :

- **Contexte bancaire** : Flux de création déclenchés après qu'un utilisateur se connecte
  à sa banque, tirant parti de la confiance et de la familiarité de l'environnement
  [bancaire](https://www.corbado.com/passkeys-for-banking).

- **Paramètres de compte du prestataire de paiement** : Les utilisateurs configurent les
  passkeys directement dans leurs paramètres « Mon profil » ou « Sécurité » du domaine du
  prestataire de paiement.

- **Paiement du commerçant** : Invite à la dernière étape du paiement, surtout si
  l'utilisateur n'a pas créé de passkey auparavant. Cela peut être intégré (iframe) ou via
  une redirection.

Dans chaque scénario, la cérémonie de passkey sous-jacente suit les mêmes étapes -
confirmation de l'utilisateur, invite biométrique/PIN et enregistrement de l'identifiant.
Le SDK de Corbado garantit que les contraintes cross-origin (si intégré) ou le contexte de
domaine first-party (si redirigé) sont gérés de manière transparente en arrière-plan.

#### 9.1.5 Métadonnées et liaison d'identifiants cohérentes

Corbado attache chaque nouveau passkey à l'identifiant utilisateur approprié - que ce soit
« préfixeBanque_idUtilisateur » ou une référence utilisateur interne dans le système du
prestataire de paiement - afin que toute utilisation ultérieure soit traçable jusqu'au bon
compte utilisateur.

Ces métadonnées sont également cruciales pour l'analytique avancée : par exemple, voir
comment les campagnes de création de passkeys de RBC se comparent à celles de TD, ou
comment les taux de création diffèrent entre les paiements des commerçants et les flux
directs de « paramètres de compte ».

#### 9.1.6 Interface utilisateur adaptative et gestion des erreurs

La même logique du SDK Corbado peut s'adapter selon que la création de passkeys
cross-origin est autorisée (dans les versions modernes de Chrome ou Edge) ou doit basculer
gracieusement vers une redirection pour Safari.

Le rapport d'erreurs intégré aide à identifier si un sous-ensemble d'utilisateurs échoue
systématiquement à la création de passkeys (par ex., anciennes versions d'iOS, appareils
d'entreprise Windows), afin que l'équipe produit puisse affiner les instructions ou les
stratégies de repli.

#### 9.1.7 La grande expérience de Corbado dans les flux de création de passkeys

Notre équipe a mené de nombreuses expériences de création de passkeys avec des clients
entreprises, apprenant quelles phrases, quels emplacements de boutons et quel timing
donnent les meilleurs taux d'adoption.

Nous intégrons ces meilleures pratiques dans chaque écran de création, tout en permettant
une personnalisation complète pour les besoins de marque et de conformité.

Dans l'ensemble, la création de passkeys est la phase la plus importante pour garantir une
adoption élevée : même le flux de connexion par passkey le plus élégant n'aura pas
d'importance si les utilisateurs n'enregistrent jamais d'identifiants en premier lieu. En
offrant des écrans de création uniformes et traçables sur tous les canaux possibles -
banque, domaine du prestataire de paiement ou paiement du commerçant - et en les
instrumentant avec des analyses de KPI et des tests A/B, Corbado aide les prestataires de
paiement à stimuler une adoption de passkeys véritablement évolutive, reproduisant
l'expérience utilisateur de solutions natives comme Apple Pay.

### 9.2 Maximiser l'utilisation des passkeys pour un paiement de type Apple Pay

Une fois qu'un utilisateur a créé un passkey, l'étape suivante consiste à s'assurer qu'il
utilise réellement ce passkey pour des paiements rapides et fluides, comme le présente
Apple Pay dans un flux de paiement Apple Pay.

![paiement par passkeys apple pay](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

Chez Corbado, nous avons développé un mécanisme de «
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
» qui détecte automatiquement lorsque l'environnement d'un utilisateur contient
probablement un passkey valide, permettant une véritable expérience de paiement en
[un clic](https://docs.corbado.com/corbado-connect/features/one-tap-login). Voici les
éléments essentiels qui rendent cela possible.

#### 9.2.1 Flux en un clic : pas de nouvelle saisie d'identifiants

Lorsqu'un utilisateur connu est reconnu, le front-end de Corbado affiche un bouton dédié
(par ex. « Payer avec Passkey ») plutôt que de forcer la saisie d'identifiants de repli.

![Une capture d'écran d'une page de connexion. Le contenu généré par l'IA peut être incorrect.](bc386dced8be285ec3788060ed5cdb7b.png)

Un seul clic sur ce bouton déclenche le flux WebAuthn `get()` (ou l'invite de passkey
native), permettant à l'utilisateur de s'authentifier instantanément via la
[biométrie](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique)/PIN - sans étapes
supplémentaires ni saisie de formulaire.

#### 9.2.2 Passkey Intelligence : détection et notation de l'environnement

Le SDK de Corbado recueille des signaux (par ex. cookies de stockage local, utilisation
antérieure réussie de passkey, détections d'environnement) pour prédire si l'appareil + le
navigateur actuels ont probablement un passkey valide pour cet utilisateur.

Si les cookies sont supprimés ou indisponibles, Corbado se rabat sur des heuristiques
supplémentaires (par ex., environnement connu existant de l'utilisateur, indices
utilisateur fournis par le commerçant) pour décider s'il est sûr de démarrer
automatiquement un flux de passkey.

Si les preuves sont insuffisantes pour suggérer la présence d'un passkey, l'interface
utilisateur propose gracieusement des flux de repli ou invite l'utilisateur à confirmer
qu'il a un passkey.

#### 9.2.3 Pas de stockage de PII, mais sensible au contexte

Corbado ne stocke pas d'informations personnellement identifiables (PII) comme les e-mails
complets ou les noms.

Au lieu de cela, le commerçant peut passer un identifiant haché ou masqué (par ex. un
hachage d'e-mail ou un ID utilisateur interne). Corbado l'utilise pour rechercher des
enregistrements de passkeys potentiels, puis décide de démarrer une authentification par
passkey ou de revenir à une approche plus générique. Si le prestataire de paiement le
prend en charge, nous pouvons rechercher les informations fournies par le commerçant pour
trouver l'ID utilisateur interne.

Cela garantit la confidentialité de l'utilisateur tout en permettant une correspondance
d'environnement de haute précision.

#### 9.2.4 Logique de repli et récupération automatique

Dans les scénarios où le passkey de l'utilisateur aurait pu exister mais ne peut pas être
détecté (par ex., cookies effacés, nouvel appareil), la
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
de Corbado analyse soigneusement s'il est judicieux de démarrer automatiquement une invite
de passkey.

Au lieu de cela, l'utilisateur verrait des flux de repli alternatifs ou une option «
scanner le passkey depuis un autre appareil » tout en préservant un chemin rapide vers
l'utilisation du passkey si l'utilisateur peut confirmer manuellement qu'il en a un.

#### 9.2.5 Suivi avancé et informations sur la couverture

![aperçu des déclencheurs d'événements de processus](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Chaque fois que Corbado choisit d'initier ou d'ignorer une invite de passkey en
[un clic](https://docs.corbado.com/corbado-connect/features/one-tap-login), cette décision
est enregistrée. Au fil du temps, vous pouvez voir précisément quels navigateurs ou types
d'appareils offrent la plus grande couverture de passkeys par rapport à ceux qui
reviennent fréquemment au repli.

Cette boucle de rétroaction analytique vous permet d'identifier les environnements
sous-performants (par ex., des versions spécifiques d'iOS ou d'Android) ou les segments
d'utilisateurs où l'utilisation des passkeys reste faible - afin que vous puissiez affiner
les stratégies d'intégration ou d'éducation.

#### 9.2.6 Expérience unifiée en un clic pour tous les cas d'utilisation

Que l'utilisateur arrive d'une campagne de création de passkeys d'une banque ou
directement au paiement d'un commerçant, la logique en
[un clic](https://docs.corbado.com/corbado-connect/features/one-tap-login) reste
cohérente.

Corbado garantit que si un passkey est trouvé (basé sur les cookies de domaine, les jetons
de stockage local ou les signaux de
[passkey intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)),
l'utilisateur se voit immédiatement présenter le flux de connexion/paiement le plus
fluide.

**Résumé**

En bref, l'utilisation des passkeys en un clic est la récompense ultime de la création de
passkeys. En tirant parti de la Passkey Intelligence - un mélange de détection
d'environnement, d'utilisation minimale de PII et de logique de repli - Corbado garantit
que les utilisateurs se voient proposer l'authentification par passkey uniquement
lorsqu'il est vraiment probable qu'elle réussisse. Cela réduit considérablement les
tentatives infructueuses, évite la frustration des utilisateurs et favorise une
utilisation habituelle des passkeys, aboutissant à un flux de paiement en un clic qui
rivalise avec la commodité d'Apple Pay ou d'autres expériences de paiement natives.

### 9.3 Analyses riches pour les KPI de création et de connexion de passkeys

Au-delà de la simple activation des passkeys, il est crucial de comprendre avec quelle
efficacité ils sont adoptés et utilisés sur différents appareils, navigateurs et parcours
utilisateur. Les prestataires de paiement ont besoin de données concrètes pour savoir si
les passkeys réduisent réellement les frictions, diminuent la fraude et améliorent la
conversion. S'appuyant sur les meilleures pratiques du Guide Acheter ou Construire des
Passkeys, Corbado offre une couche d'analyse riche qui vous permet de suivre, segmenter et
optimiser les performances des passkeys en temps réel.

Voici les points forts.

#### 9.3.1 Entonnoir de conversion unifié pour les passkeys : Création → Utilisation

![analyse de l'entonnoir de conversion des passkeys](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

Corbado organise tous les événements de passkeys dans un entonnoir : depuis le moment où
un utilisateur est invité à
[créer un passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey), en passant par
l'enregistrement réussi, jusqu'aux connexions/paiements ultérieurs (utilisation du
passkey).

Cette visualisation de l'entonnoir vous permet de voir où les utilisateurs abandonnent -
par exemple, combien ne commencent jamais la création, combien abandonnent en cours de
cérémonie, ou combien reviennent aux méthodes de repli lors de la connexion.

#### 9.3.2 KPI essentiels du Guide Acheter ou Construire des Passkeys

Sur la base de notre vaste expérience à aider les entreprises à implémenter les passkeys,
nous nous concentrons sur les métriques qui ont un impact direct sur le retour sur
investissement et la satisfaction des utilisateurs :

![kpi essentiels du guide passkey](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

- **Taux d'acceptation des passkeys** : Combien d'utilisateurs qui voient une invite de
  création terminent réellement l'enregistrement du passkey ?

- **Taux de réussite de la création de passkeys** : Parmi ceux qui commencent la cérémonie
  (cliquent sur « Créer un passkey »), quel pourcentage finalise sans erreur ni abandon ?

- **Taux d'utilisation des passkeys** : À quelle fréquence les utilisateurs connus
  choisissent-ils réellement les passkeys pour l'authentification ou le paiement
  quotidiens, plutôt que les mots de passe ou les OTP ?

- **Taux de réussite de la connexion par passkey** : Le pourcentage de tentatives de
  passkey qui réussissent sans repli ni frustration de l'utilisateur.

- **Utilisation du repli** : Combien d'utilisateurs initient un flux de passkey mais
  reviennent à d'anciennes méthodes ? Cela signale des barrières potentielles d'UX ou
  techniques.

#### 9.3.3 Segmentation granulaire par OS et navigateur

Corbado tague automatiquement chaque événement avec le système d'exploitation (Windows,
macOS, iOS, Android) et le navigateur (Chrome, Safari, Edge, Firefox, etc.).

Avec cette segmentation, vous pouvez voir si, par exemple, Safari sur iOS a un taux
d'abandon de passkey plus élevé, ou si Chrome sur Windows donne une meilleure adoption des
passkeys.

Ces données vous aident également à affiner les stratégies de repli - surtout si les
restrictions cross-origin d'Apple affectent votre base d'utilisateurs plus que prévu.

#### 9.3.4 Rapports dynamiques et tableaux de bord en temps réel

Nous fournissons des vues de tableau de bord pour chaque étape de l'entonnoir de passkey :
invites de création, enregistrements réussis, connexions des utilisateurs, utilisation du
repli.

Les graphiques en temps réel permettent aux chefs de produit de repérer rapidement les
tendances (par exemple, si une nouvelle mise à jour de l'OS casse les flux de passkeys).

Des alertes automatisées peuvent notifier votre équipe si les taux de réussite des
passkeys chutent de manière significative - afin que vous puissiez rapidement enquêter sur
un nouveau bogue de navigateur ou un problème de configuration.

#### 9.3.5 Débogage et journaux de processus

Chaque flux de passkey (de la création à la connexion) est enregistré avec des événements
étape par étape horodatés, permettant une analyse forensique approfondie.

Vous pouvez rapidement rechercher par hachage d'utilisateur, ID de session ou signature de
l'appareil pour voir exactement où un utilisateur a eu des difficultés ou quel code
d'erreur a été retourné.

Ceci est essentiel pour les déploiements à grande échelle, où vous ne pouvez pas vous fier
à des tickets de support anecdotiques mais avez besoin de données précises pour résoudre
les problèmes des utilisateurs.

#### 9.3.6 Optimisation de l'entonnoir avec des tests A/B

La plateforme d'analyse de Corbado prend en charge les tests A/B intégrés à l'entonnoir de
passkey : testez différents textes de CTA, invites de création, messages de repli ou
placement des boutons « Créer un passkey » dans le flux de paiement.

Des métriques comme le « Taux d'acceptation des passkeys » ou le « Taux de repli » peuvent
être mesurées côte à côte pour chaque variante.

Cette approche garantit une amélioration continue, à l'image du succès des principaux
adopteurs de passkeys qui affinent les flux au fil du temps.

#### 9.3.7 Accès flexible aux données et intégration

Bien que les tableaux de bord de Corbado fournissent une interface visuelle prête à
l'emploi, vous pouvez également exporter ou utiliser des webhooks pour les points de
données clés (par ex., succès de la création de passkeys, connexions) dans vos outils de
BI ou SIEM.

Cela permet aux prestataires de paiement d'intégrer les KPI des passkeys dans des suites
d'analyse plus larges - en suivant le retour sur investissement des passkeys aux côtés
d'autres métriques de sécurité, de marketing ou opérationnelles.

**Résumé**

En mesurant et en visualisant chaque étape du parcours du passkey - à travers les
combinaisons OS/navigateur, les flux de création et les scénarios de connexion - Corbado
vous donne les informations nécessaires pour affiner continuellement votre offre de
passkeys. Ces analyses ne confirment pas seulement que les passkeys sont activés ; elles
prouvent si les utilisateurs les adoptent réellement à grande échelle, identifient les
points de friction et vous aident à augmenter les taux d'utilisation au point où les
passkeys remplacent véritablement les mots de passe pour des paiements sécurisés et
fluides.

### 9.4 Synchronisation multi-appareils et « Intelligence » pour une adoption élevée

Pour les prestataires de paiement, la simple création d'un passkey par utilisateur ne
suffit souvent pas à offrir une expérience d'authentification véritablement transparente.
En réalité, les utilisateurs changent fréquemment d'appareil - des ordinateurs portables
au travail aux smartphones personnels, tablettes et même aux ordinateurs familiaux
partagés. S'assurer que chaque appareil dispose d'un passkey valide pour le même compte
est essentiel pour réduire les frictions et éviter le recours aux mots de passe. Apple Pay
y parvient en pouvant exploiter le compte iCloud sur tous les appareils connectés à
iCloud.

Voici comment Corbado aide à maintenir une couverture multi-appareils tout au long du
cycle de vie de l'utilisateur.

#### 9.4.1 Première création de passkey vs. appareils supplémentaires

- **Écrans de création de passkey principal** : Corbado se concentre initialement sur
  l'incitation de chaque utilisateur à enregistrer au moins un passkey - le passkey «
  principal » - là où il rencontre pour la première fois votre flux de paiement (par
  exemple, lors du paiement, sur le portail en ligne d'une banque ou dans les paramètres
  de votre compte).

- **Écrans de création de passkey secondaire** : Après qu'un utilisateur a enregistré avec
  succès son premier passkey, les connexions ultérieures sur d'autres appareils peuvent
  automatiquement déclencher un court flux « Ajouter cet appareil ». Cela garantit que
  l'utilisateur obtient rapidement un accès fluide par passkey sur tous les appareils
  pertinents sans avoir à ressaisir un mot de passe ou à basculer vers des méthodes de
  repli.

#### 9.4.2 Authentification hybride pour la « réparation » des appareils

Même si un utilisateur a un passkey sur un appareil, il peut apparaître sans passkey local
sur un deuxième appareil (en raison de nouvelles installations d'OS, de la suppression de
cookies ou simplement de n'avoir jamais créé de passkey sur cet appareil).

L'approche de Corbado utilise souvent une étape hybride : l'utilisateur peut se connecter
avec un passkey existant sur son téléphone ou une méthode de repli, puis « réparer »
instantanément la lacune en créant un passkey sur l'appareil actuel.

Ce processus d'auto-réparation aide à maintenir une couverture élevée et élimine
l'utilisation répétée du repli à l'avenir.

#### 9.4.3 Détecter et guider les utilisateurs pour ajouter les appareils manquants

Grâce à des signaux inter-appareils et à la « Passkey Intelligence » de Corbado, le
système peut détecter quand un utilisateur avec un passkey existant est passé à un
appareil non enregistré.

Si votre stratégie UX vise une couverture maximale, Corbado peut automatiquement proposer
: « Souhaitez-vous ajouter un passkey sur cet appareil pour ne pas avoir à utiliser une
solution de repli la prochaine fois ? »

![stratégie ux passkeys corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

Les utilisateurs peuvent ignorer cette étape s'ils sont sur un appareil ponctuel, mais
apprécient généralement la commodité de la connexion biométrique par passkey une fois
qu'elle est expliquée.

#### 9.4.4 Flux d'interface utilisateur adaptatifs

Le SDK de Corbado fournit des flux d'écran distincts pour la « première création de
passkey » (c'est-à-dire la toute première fois que l'utilisateur enregistre un
identifiant) et la création sur un « appareil secondaire ».

Le message peut différer : par exemple, « Sécurisez ce nouvel appareil avec un passkey »
contre « Configurez votre premier passkey ».

Cela garantit la clarté pour les utilisateurs finaux, qui comprennent la différence entre
l'inscription initiale et l'extension de la couverture à des appareils supplémentaires.

#### 9.4.5 Gestion des incohérences et des erreurs

Parfois, la création d'un passkey peut échouer en cours de cérémonie ou le système
d'exploitation de l'utilisateur est obsolète. Dans ces scénarios, Corbado enregistre la
tentative partielle et suggère gracieusement des remèdes possibles (redirection, repli
manuel ou flux QR inter-appareils).

L'utilisateur peut toujours réessayer d'ajouter un passkey sur cet appareil lors de la
prochaine tentative de connexion, ou s'appuyer sur un passkey existant d'un autre
appareil.

#### 9.4.6 Métriques de couverture continues

Les analyses de Corbado montrent non seulement combien d'utilisateurs ont créé un passkey
initialement, mais aussi combien ont étendu les passkeys à plusieurs appareils.

Vous pouvez suivre les taux de couverture des appareils (par exemple, 1 appareil contre 2
ou plus) et voir comment cela est corrélé avec une utilisation réduite du repli ou une
meilleure réussite des paiements.

Cela aide votre équipe à prioriser l'éducation des utilisateurs, les invites dans
l'application ou les flux d'inscription basés sur la banque pour augmenter la pénétration
des passkeys multi-appareils.

**Résumé : Pourquoi la couverture multi-appareils est importante**

Sans une couverture cohérente sur tous les appareils de l'utilisateur, vous risquez que
les utilisateurs soient contraints de revenir à des mesures d'authentification de repli
chaque fois qu'ils sont sur un appareil « sans passkey ». Cela brise l'expérience fluide
et maintient des [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ûts opérationnels élevés (par
exemple, frais de SMS, frais de support). En proposant des écrans de
[création de passkey](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) secondaires, une
réparation par repli hybride et des invites basées sur l'environnement, Corbado garantit
que chaque utilisateur peut éventuellement maintenir des passkeys sur tous les appareils
qu'il utilise - ce qui entraîne une adoption globale plus élevée et minimise ces moments
de repli frustrants.

### 9.5 Accélération de la mise sur le marché : pourquoi les solutions holistiques sont importantes

L'une des plus grandes idées fausses lors de la création d'un SDK de passkeys tiers est
que la partie la plus difficile est d'implémenter les appels WebAuthn (par exemple,
`navigator.credentials.create()` ou `navigator.credentials.get()`).

En réalité, c'est la partie « facile » - un ou deux appels d'API pour déclencher la
cérémonie de base. La véritable complexité, et le véritable déterminant du succès, réside
dans la garantie d'une adoption à grande échelle et la construction d'un écosystème
complet autour de ces appels d'API.

Voici les points clés - renforcés par le Guide Acheter ou Construire des Passkeys - qui
soulignent pourquoi les implémentations minimales, axées uniquement sur la cérémonie, ne
parviennent souvent pas à produire des résultats concrets.

#### 9.5.1 Les inconnues et au-delà de la cérémonie

- **Implémentation de la cérémonie** : La création ou l'authentification d'un passkey
  implique généralement quelques lignes de JavaScript pour appeler
  `navigator.credentials.create()` ou `navigator.credentials.get()`.

- **Complexité réelle** : S'assurer que le flux de passkey fonctionne sur de nombreux
  navigateurs, gère gracieusement les échecs et offre une solution de repli pour les
  systèmes plus anciens. Vous aurez également besoin d'une gestion de session robuste,
  d'une journalisation des erreurs, d'analyses, de stratégies de couverture des appareils,
  et plus encore.

- **Pièges imprévus** : Une fois que vous dépassez une « démo technique » des passkeys,
  vous découvrez des cas limites comme les blocages cross-origin, les restrictions des
  WebView intégrées et les complexités de la synchronisation multi-appareils. Ce sont les
  inconnues qui font dérailler les constructions internes naïves.

#### 9.5.2 L'adoption est le véritable objectif

- **Cérémonie vs. Adoption** : Même si vous avez une cérémonie WebAuthn parfaite, une
  faible adoption par les utilisateurs (par exemple, un taux d'utilisation des passkeys
  &lt;5 %) ne produira que des avantages minimes en matière de sécurité ou d'expérience
  utilisateur.

- **Approche holistique** : Un déploiement de passkeys réussi exige tout, des invites
  utilisateur convaincantes et une rédaction testée par A/B aux flux de couverture
  multi-appareils, à la gestion des solutions de repli et à des analyses continues - bien
  au-delà des appels de cérémonie de base.

- **Enseignements du Guide Acheter ou Construire** : Le guide souligne que stimuler
  l'adoption des passkeys - et pas seulement les activer - détermine en fin de compte le
  retour sur investissement. Si les utilisateurs ne s'inscrivent pas et n'utilisent pas
  activement les passkeys, le projet est effectivement bloqué à «
  [MFA](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) 2.0 » sans amélioration du
  taux de conversion.

#### 9.5.3 Risques d'une implémentation minimale « faite maison »

- **Gestion incomplète des solutions de repli et des erreurs** : L'absence d'une logique
  de repli avancée ou d'un débogage en temps réel peut entraîner des blocages
  d'utilisateurs et des [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ûts de support plus élevés.

- **Couverture multi-appareils fragmentée** : Sans un plan pour synchroniser des appareils
  supplémentaires ou « réparer » les lacunes de passkeys, les utilisateurs reviennent aux
  mots de passe chaque fois qu'ils changent de plateforme.

- **Analyses et tests A/B limités** : Le manque de données sur les entonnoirs de création
  de passkeys ou l'utilisation de l'environnement signifie que vous ne pouvez pas
  améliorer systématiquement l'adoption ou dépanner rapidement les nouvelles bizarreries
  des navigateurs.

#### 9.5.4 Solutions holistiques : plus qu'une simple API

- **Interface utilisateur pré-construite et meilleures pratiques** : Au lieu de simplement
  exposer les points de terminaison de la cérémonie, une solution appropriée (comme
  Corbado) regroupe des écrans en marque blanche, des flux de repli, la gestion des
  erreurs et la couverture inter-appareils.

- **Intelligence adaptative et journalisation** : Détection automatique de la présence
  probable de passkeys, guidage des utilisateurs pour créer ou corriger les passkeys
  manquants, et capture de journaux d'événements granulaires.

- **« Inconnues » axées sur l'adoption** : De nombreux détails - comme le repli par e-mail
  ou la manière de gérer les appareils d'entreprise - ne sont pas évidents jusqu'à ce que
  les utilisateurs commencent à les rencontrer dans des déploiements réels.

#### 9.5.5 Recommandation de lire le Guide Acheter ou Construire

- **Plongée plus profonde dans la stratégie d'adoption** : Le Guide Acheter ou Construire
  des Passkeys met en évidence comment équilibrer le coût, le temps de mise sur le marché
  et les complexités cachées d'une solution de passkeys robuste.

- **Benchmarks du monde réel** : Apprenez comment les déploiements à grande échelle de
  grandes banques et de fournisseurs de [commerce électronique](https://www.corbado.com/passkeys-for-e-commerce)
  ont surmonté les inconnues qui surgissent après que vous ayez codé la logique « simple »
  de la cérémonie.

- **Succès durable** : Investir dans une plateforme établie avec des modèles d'adoption
  éprouvés vous assure de ne pas être coincé à réinventer la roue - et à découvrir des
  surprises coûteuses en cours de route.

**En résumé**

Le simple fait de connecter la cérémonie WebAuthn ne suffit pas pour obtenir une adoption
significative des passkeys. Le véritable succès dépend de l'orchestration de flux de bout
en bout - comme les solutions de repli, les analyses, les extensions multi-appareils et
les parcours utilisateur testés par A/B. En abordant les complexités nuancées au-delà de «
juste la cérémonie », vous pouvez transformer votre projet de passkeys d'une curiosité
technique en une solution d'authentification véritablement fluide, largement utilisée et
économique.

### 9.6 Hébergement et déploiement flexibles (Multi-AZ, agnostique à la région)

En plus des complexités liées aux flux cross-origin, à l'adoption par les utilisateurs et
à la gestion du cycle de vie des passkeys, les considérations d'hébergement et de
déploiement sont essentielles pour toute solution de passkeys à grande échelle. Les
prestataires de paiement sont souvent confrontés à des exigences strictes en matière de
conformité, de résidence des données et de résilience qui peuvent varier considérablement
d'une région à l'autre. Voici comment Corbado (ou des solutions tout aussi robustes)
répond à ces préoccupations :

#### 9.6.1 Déploiements cloud agnostiques à la région

Pour se conformer à la souveraineté des données ou aux cadres réglementaires (par ex. le
[RGPD](https://www.corbado.com/fr/glossary/divulgation-selective) en Europe, la LPRPDE au Canada ou le
[NIST](https://www.corbado.com/fr/glossary/niveau-de-garantie-d-authentification-aal)/HIPAA aux États-Unis),
certains fournisseurs doivent conserver les données à l'intérieur de frontières
géographiques spécifiques.

Une architecture agnostique à la région garantit que le service de passkeys peut être
déployé dans n'importe quelle région [AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) souhaitée,
répondant aux mandats de conformité locaux sans sacrifier les performances ou
l'évolutivité.

Cette flexibilité est particulièrement importante si votre base d'utilisateurs s'étend sur
plusieurs pays, chacun appliquant des règles de traitement des données différentes.

#### 9.6.2 Haute disponibilité Multi-AZ (Zone de disponibilité)

Pour les flux d'authentification de paiement critiques, les temps d'arrêt ne sont pas une
option. Corbado emploie des déploiements multi-AZ, distribuant les composants clés sur
plusieurs zones de disponibilité.

Cette configuration aide à garantir que si une zone de disponibilité subit une panne ou un
problème de connectivité, votre infrastructure de passkeys dans les autres zones reste en
ligne - afin que les utilisateurs puissent continuer à s'authentifier.

Le résultat est un système plus résilient qui respecte des SLA stricts pour les
[services financiers](https://www.corbado.com/passkeys-for-banking) et les sites de
[commerce électronique](https://www.corbado.com/passkeys-for-e-commerce), où même une brève interruption peut
entraîner un impact significatif sur les revenus.

#### 9.6.3 Hébergement géré autonome ou hybride

Certains prestataires de paiement préfèrent un cluster privé dédié - que ce soit pour une
isolation plus stricte des données, des contrôles de conformité personnalisés ou un
contrôle plus approfondi des correctifs et des mises à jour.

Une solution flexible peut prendre en charge les deux extrêmes :

- **SaaS / Multi-locataire** : Rapide à mettre en œuvre, coût inférieur, bien adapté à de
  nombreux déploiements de taille moyenne.

- **Instance cloud dédiée** : Un compte et une instance de base de données distincts dans
  la région de votre choix, pour ceux qui ont besoin d'une isolation ou d'une conformité
  supplémentaires.

#### 9.6.4 Infrastructure évolutive et élastique

Les passkeys doivent gérer des charges de travail en dents de scie : d'énormes pics de
trafic (par ex., les pics d'achats des fêtes ou la vente de billets d'événements) peuvent
submerger les systèmes à capacité fixe.

Un back-end de passkeys moderne s'adapte horizontalement en temps réel, ajoutant ou
supprimant des instances de calcul en fonction des modèles d'utilisation. Cette mise à
l'échelle automatique garantit des performances constantes sans intervention manuelle.

#### 9.6.5 Outils de sécurité et de conformité

Les normes de l'industrie comme [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)-DSS,
[DSP2](https://www.corbado.com/fr/blog/biometrie-sensibilisation-payeur-lien-dynamique) SCA ou
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) s'appliquent souvent aux prestataires de
paiement. Un fournisseur de passkeys robuste s'intègre généralement aux cadres de
conformité connus dès le départ :

- **Chiffrement au repos et en transit** : Sécurisez les données avec un TLS fort et un
  chiffrement côté serveur ou côté client pour les informations d'identification stockées.

- **Journalisation et pistes d'audit** : Journaux détaillés pour chaque opération de
  passkey, adaptés aux régulateurs ou aux enquêtes sur les incidents.

- **Application régulière de correctifs de sécurité** : Application automatique de
  correctifs pour l'OS et les conteneurs afin de tenir les vulnérabilités à distance,
  particulièrement pertinent dans un environnement multi-AZ fluide.

#### 9.6.6 Reprise après sinistre et géo-redondance

La véritable résilience s'étend au-delà d'une seule région. Certains fournisseurs exigent
une réplication inter-régionale pour maintenir la continuité des activités lors de
catastrophes à grande échelle.

La géo-redondance peut répliquer les données de passkeys dans une région ou un continent
différent, garantissant que l'indisponibilité d'une région entière n'arrête pas les flux
d'authentification.

**Résumé : Multi-AZ et indépendant de la région**

Choisir une solution de passkeys qui s'adapte facilement, s'adapte géographiquement et
résiste à la fois aux pannes locales et aux catastrophes à grande échelle est essentiel
pour les prestataires de paiement modernes - en particulier ceux qui opèrent dans
plusieurs pays ou sous une conformité stricte. En prenant en charge les déploiements
multi-AZ et les configurations agnostiques à la région, Corbado (ou des solutions
comparables) garantit que les services de passkeys de paiement restent à la fois
disponibles et conformes, peu importe où se trouvent vos utilisateurs ou vos données.

## 10. Conclusion : Surmonter les barrières d'Apple et adopter les passkeys

Les passkeys représentent en effet la prochaine génération d'authentification sécurisée et
conviviale. Pourtant, les prestataires de paiement sont confrontés à des défis uniques que
la conception traditionnelle de WebAuthn n'aborde pas directement. Ces limitations sont
les plus prononcées dans :

1. Le refus de Safari d'autoriser la création de passkeys cross-origin (en particulier
   dans les iframes), forçant soit une approche basée sur la redirection, soit une
   dépendance à des passkeys créés précédemment.

2. Le manque de support d'Apple pour la Secure Payment Confirmation (SPC), empêchant un
   flux de paiement standardisé et sans friction sur les navigateurs et les plateformes.

Néanmoins, les passkeys restent essentiels pour les prestataires de paiement qui cherchent
à offrir une expérience de paiement de type Apple Pay : simplifiée, sécurisée et
délicieusement simple pour les utilisateurs finaux. Voici comment ces défis peuvent être
relevés et comment Corbado aide.

### 10.1 Questions clés résolues : limitations cross-origin et SPC

1. Quelles sont les limites actuelles de l'utilisation des passkeys dans des contextes
   tiers pour les prestataires de paiement ?

- **Restrictions cross-origin** : Safari (et certains navigateurs plus anciens) bloquent
  `navigator.credentials.create()` lorsqu'il est intégré via un iframe. Cela signifie que
  vous ne pouvez pas créer de nouveaux passkeys de manière transparente dans un flux
  intégré chez un commerçant sur ces navigateurs.

- **Absence de support SPC** : Le refus d'Apple d'adopter la SPC limite la capacité à
  standardiser les confirmations de paiement cross-origin, forçant les fournisseurs à
  maintenir des approches distinctes pour Safari par rapport à Chrome/Edge.

- **Contraintes des WebView et des applications natives** : Les WebViews intégrées cassent
  souvent les flux de passkeys, nécessitant des sessions de navigateur système ou d'autres
  approches spécialisées pour gérer l'alignement de l'origine du domaine.

- **Couverture fragmentée des appareils** : Même si l'utilisateur crée un passkey sur un
  appareil ou un navigateur, il peut manquer de couverture sur d'autres, ce qui entraîne
  une utilisation de repli.

2. Comment les prestataires de paiement peuvent-ils surmonter ces limitations pour réussir
   l'implémentation d'intégrations de passkeys tiers ?

- Utiliser une stratégie hybride (Iframe + Redirection) :
    - Iframe pour les navigateurs qui prennent entièrement en charge les passkeys
      cross-origin, offrant une interface utilisateur intégrée transparente.

    - Redirection comme solution de repli pour Safari ou les configurations incompatibles,
      garantissant qu'une création de passkey robuste est toujours possible.

- WebView système ou redirection de navigateur dans les applications natives :
    - Plutôt que d'intégrer des iframes dans les applications des commerçants, passez à
      ASWebAuthenticationSession (iOS) ou aux onglets personnalisés Chrome (Android) pour
      préserver la continuité du domaine.

    - Boîte à outils axée sur l'adoption : Fournissez des invites de création de passkeys
      convaincantes, des flux de couverture multi-appareils et des étapes de « réparation
      » de repli pour maintenir une utilisation élevée.

    - Analyses avancées et tests A/B :
        - Mesurez en continu les taux de réussite/repli des passkeys, la couverture de
          l'environnement et les commentaires des utilisateurs pour affiner vos flux.

        - Utilisez l'intelligence des passkeys pour présenter automatiquement les passkeys
          uniquement lorsque le succès est probable.

### 10.2 Comment Corbado comble le fossé pour les prestataires de paiement

Tout au long de ce guide, nous avons souligné que le simple fait de connecter
`navigator.credentials.create()` ne suffit pas. Le véritable succès repose sur une
adoption élevée des passkeys, une expérience utilisateur cohérente et une couverture
multi-appareils résiliente. C'est là que Corbado excelle :

- **Support unifié pour Iframe et Redirection** : Le SDK de Corbado détecte
  automatiquement si un flux de passkey intégré est réalisable (par exemple, sur Chrome ou
  Edge) ou si une redirection est nécessaire (par exemple, Safari). Cela maximise la
  compatibilité sans obliger les commerçants à maintenir plusieurs chemins de code.
    - **Expérience de paiement en un clic** : Avec la Passkey Intelligence, Corbado
      détecte instantanément si l'environnement d'un utilisateur a probablement un passkey
      valide - déclenchant un flux « payer avec passkey » sans friction. Cette approche
      s'inspire du paiement en un clic d'Apple Pay, stimulant l'utilisation quotidienne
      des passkeys plutôt que de la reléguer à une étape
      [MFA](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) rarement utilisée.

    - **Couverture multi-appareils robuste** : Corbado fournit des flux spéciaux pour la
      création initiale de passkeys par rapport aux extensions de passkeys secondaires,
      afin que chaque utilisateur puisse rapidement ajouter une couverture pour de
      nouveaux appareils après s'être connecté via un repli ou un QR inter-appareils.

    - **Approche d'adoption complète** : Grâce à des analyses intégrées, des tests A/B et
      une gestion des erreurs, Corbado aide les fournisseurs à identifier les points de
      friction et à optimiser systématiquement l'acceptation des passkeys. Cela s'étend
      des premières invites de passkey des banques aux expériences de paiement des
      commerçants.

    - **Hébergement flexible et conforme** : Les déploiements multi-AZ et agnostiques à la
      région de Corbado s'alignent sur la conformité stricte de l'industrie des paiements
      (PCI DSS, DSP2 SCA, etc.), garantissant la disponibilité et le respect des règles de
      résidence des données dans le monde entier.

### 10.3 Le mot de la fin : construire une expérience de passkey fluide et évolutive

Bien que les politiques restrictives d'Apple créent des frictions inévitables, les
prestataires de paiement peuvent toujours implémenter avec succès des passkeys tiers en :

1. Combinant une approche intégrée (iframe) avec une solution de repli par redirection.

2. Adoptant des webviews système spécialisées ou des flux de navigateur externes pour les
   applications natives.

3. Se concentrant sur des stratégies d'adoption robustes : couverture multi-appareils, «
   réparation » par repli, analyses avancées et tests A/B.

Corbado rassemble tous ces éléments, offrant une plateforme de passkeys d'entreprise qui
couvre l'inscription aux passkeys, l'utilisation en un clic, l'optimisation basée sur les
analyses et l'hébergement à l'échelle mondiale. Le résultat : une expérience véritablement
fluide comme Apple Pay pour votre propre service de paiement, offrant à la fois une
sécurité accrue et un parcours utilisateur supérieur.