---
url: 'https://www.corbado.com/fr/blog/identifiants-numeriques-paiements'
title: 'Identifiants numériques et paiements : la stratégie des Wallets Apple et Google'
description: 'Découvrez l''impact des identifiants numériques sur les paiements et les stratégies que les émetteurs peuvent adopter pour concurrencer efficacement Apple Pay et Google Wallet.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2025-07-25T07:00:33.752Z'
lastModified: '2026-03-27T07:05:44.146Z'
keywords: 'identifiants numériques paiement'
category: 'Passkeys Strategy'
---

# Identifiants numériques et paiements : la stratégie des Wallets Apple et Google

### Résumé : Le guide stratégique d'un émetteur

| Phase                | Stratégie principale                                            | Actions clés                                                                                                                                                                                                                                                            |
| :------------------- | :-------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Maintenant**    | 📱 **Promouvoir l'application, maîtriser les Passkeys**         | Encouragez sans relâche l'adoption de l'application native. Utilisez les Passkeys pour une expérience de paiement en un clic qui rivalise avec Apple Pay et PayPal.                                                                                                     |
| **2. À court terme** | 🆔 **Utiliser les VCs pour l'identité, pas pour les paiements** | Intégrez les identifiants numériques pour les tâches à haute assurance comme le KYC et la récupération de compte. Surveillez, mais ne vous précipitez pas sur les identifiants de paiement vérifiables.                                                                 |
| **3. À l'avenir**    | ⚖️ **Évaluer les VCs face à l'évolution des Passkeys**          | Comparez tout flux de paiement par VC aux meilleures solutions existantes. Adoptez-les pour les paiements uniquement si c'est obligatoire ou s'ils apportent une valeur ajoutée nette. Surveillez les améliorations des Passkeys, comme les signaux d'appareil in-band. |

## 1. Introduction

Les paiements numériques sont en constante évolution. Nous voulons qu'ils soient plus
rapides, plus sûrs et plus simples à utiliser. Parallèlement, les outils d'identité
numérique, comme les Identifiants Vérifiables (VCs) et les documents d'identité mobiles
(mdocs), s'améliorent. Ils offrent de nouvelles manières de prouver son identité. La
grande question est donc la suivante : ces nouveaux
[identifiants numériques](https://www.corbado.com/fr/blog/digital-credentials-api) peuvent-ils aussi rendre les
paiements numériques bien meilleurs ou plus simples ?

Cet article examine comment les
[identifiants numériques](https://www.corbado.com/fr/blog/digital-credentials-api) (y compris les mdocs ISO et
les VCs envoyés via [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)) interagissent avec le monde des
paiements. Nous aborderons les points suivants :

- Comment les Wallets mobiles actuels (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance),
  [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) gèrent les informations d'identité par
  rapport aux cartes de paiement.
- Pourquoi les normes d'[identité numérique](https://www.corbado.com/fr/glossary/openid-4-vp) actuelles comme les
  mdocs [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 ne sont pas vraiment adaptées comme outils
  de paiement directs.
- Quel rôle des protocoles comme [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) pourraient jouer dans
  les futures méthodes de paiement.
- Comment d'autres applications de [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) (tierces)
  pourraient gérer les fonctionnalités de paiement.
- Les principaux problèmes et les perspectives d'avenir lors de la tentative d'utilisation
  des identifiants vérifiables dans les systèmes de paiement.

Ce texte complète notre autre article sur les
[identifiants numériques](https://www.corbado.com/fr/blog/digital-credentials-api) et les Passkeys en se
concentrant uniquement sur les paiements.

## 2. Comprendre le paysage actuel : les écosystèmes d'identité et de paiement

Pour voir comment les identifiants numériques pourraient être utilisés dans les paiements,
nous devons d'abord comprendre comment les principales plateformes mobiles actuelles et
leurs Wallets intégrés (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance),
[Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) séparent les informations d'identité du
traitement des paiements.

### 2.1 Wallets natifs des plateformes : des silos distincts pour l'identité et les paiements

Les Wallets natifs des plateformes sont devenus des centres sophistiqués pour les
utilisateurs, mais ils maintiennent généralement une distinction claire entre les
identifiants et les instruments de paiement :

- **Identifiants (ex. : mDLs) :**
    - **Apple Wallet :** Prend principalement en charge les permis de conduire mobiles
      (mDLs) et les cartes d'identité d'État conformes à la norme ISO/IEC 18013-5. Depuis
      la [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), Apple a confirmé que Safari 26 (dans
      [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)) prendra en charge
      l'[API Digital Credentials](https://www.corbado.com/fr/blog/digital-credentials-api) du W3C pour la
      présentation en ligne, en se concentrant exclusivement sur le protocole
      `org.iso.mdoc`. Ceci est destiné à la vérification des attributs d'identité (par
      exemple, nom, âge, adresse), et non aux paiements.
    - **Google Wallet et Android Credential Manager :**
      [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) prend également en charge les mDLs
      basés sur la norme [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5). Le Credential Manager
      sous-jacent d'[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) offre un cadre plus
      flexible. Bien que son implémentation de l'API Digital Credentials soit agnostique
      au protocole, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) fournit une
      implémentation par défaut qui utilise [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) comme
      mécanisme de transport.
- **Instruments de paiement (ex. : cartes de crédit/débit) :**
    - [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) (dans Apple Wallet) et
      [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) (dans Google Wallet) utilisent tous deux
      des technologies de paiement établies et hautement réglementées. Celles-ci sont
      principalement basées sur les normes EMV (Europay,
      [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Visa](https://www.corbado.com/blog/visa-passkeys)), impliquant la
      tokenisation (les PANs d'appareil ou DPANs remplaçant les vrais numéros de carte
      pour les transactions), des éléments sécurisés ou une
      [sécurité matérielle](https://www.corbado.com/fr/blog/meilleures-cles-securite-materielles-fido2-2025) pour
      stocker les jetons de paiement, et des cryptogrammes dynamiques pour la sécurité des
      transactions.
    - Ces systèmes de paiement interagissent directement avec les réseaux de paiement
      existants (Visa, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), Amex, etc.) et les banques
      acquéreuses.

**Point clé à retenir :** Les Wallets natifs des plateformes fonctionnent actuellement
avec des « écosystèmes » ou des technologies distinctes pour les identifiants et les
cartes de paiement. Un [mdoc](https://www.corbado.com/glossary/mdoc) est présenté pour prouver un attribut
d'identité ; une carte tokenisée est présentée pour effectuer un paiement. Il n'y a pas
d'utilisation directe d'un [mdoc](https://www.corbado.com/glossary/mdoc) \_en tant qu'\_instrument de paiement au
sein de ces écosystèmes natifs.

### 2.2 Pourquoi les mdocs ISO 18013-5 ne sont pas des instruments de paiement

La norme ISO/IEC 18013-5 définit la structure des données pour les mDLs et autres
identifiants mobiles (mdocs). Bien qu'excellente pour la vérification d'identité, sa
conception n'est pas adaptée à une utilisation directe comme instrument de paiement :

| Caractéristique                   | Ce que spécifie l'ISO 18013-5 (pour les mdocs d'identité)                                                                                                                                                                                                                                                                                                                                                    | Pourquoi c'est un problème pour les paiements                                                                                                                                                                                                                                                                                                                 |
| :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Champ d'application principal** | Permis de conduire mobiles et autres documents d'identité.                                                                                                                                                                                                                                                                                                                                                   | Les réseaux de cartes nécessitent des éléments de données et des cryptogrammes spécifiques aux paiements.                                                                                                                                                                                                                                                     |
| **Modèle de données**             | Éléments de données fixes liés à l'identité (ex. : portrait, nom, date de naissance). Extensible, mais toujours lié à un espace de noms « identité ».                                                                                                                                                                                                                                                        | Les PANs de carte, les DPANs tokenisés, les CVMs, les cryptogrammes dynamiques ne correspondent pas clairement à ces éléments d'identité.                                                                                                                                                                                                                     |
| **Modèle de menace et sécurité**  | Vérification en présence du titulaire (« assistée ») ; « tap-to-verify » hors ligne avec divulgation sélective des attributs d'identité. Récupération sécurisée des données du mdoc.                                                                                                                                                                                                                         | Les paiements exigent des mécanismes robustes pour l'autorisation en ligne, la génération de cryptogrammes dynamiques (style EMV), la prévention de la fraude spécifique aux transactions financières et des liens vers les sources de financement. La sécurité des mdocs concerne l'intégrité de l'identité, pas le traitement des transactions financières. |
| **Reconnaissance par la norme**   | La norme ISO 18013-5 se limite explicitement à l'identification en personne. Les normes ISO/IEC 18013-7 et ISO/IEC 23220 spécifient des mécanismes de présentation en ligne pour les mdocs (par exemple, pour la vérification d'identité sur le web via l'API Digital Credentials), mais celles-ci se concentrent toujours sur la _vérification d'identité à distance_, et non sur les circuits de paiement. | Les paiements, surtout en ligne, restent hors du champ d'application des normes mdoc elles-mêmes.                                                                                                                                                                                                                                                             |

Même si un [mdoc](https://www.corbado.com/glossary/mdoc) _pouvait_ théoriquement contenir des champs de données
personnalisés pour un [PAN](https://www.corbado.com/glossary/pan) ou un jeton de paiement (comme le permet
l'[ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) pour les espaces de noms personnalisés), la norme
mdoc elle-même ne définit pas :

- Comment générer ou traiter des cryptogrammes de paiement dynamiques.
- Comment effectuer une autorisation en ligne avec un réseau de paiement.
- Les mécanismes de sécurité nécessaires spécifiques aux transactions de paiement (au-delà
  de l'intégrité des données d'identité).

Il n'existe donc actuellement aucun moyen d'utiliser un mdoc ISO 18013-5 comme instrument
de paiement direct.

### 2.3 Authentification renforcée (Step-Up) : utiliser les mdocs pour la preuve d'identité, pas pour le paiement

Bien qu'un mdoc ne soit pas un outil de paiement, il peut jouer un rôle dans un flux d'«
[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) renforcée », où
l'identité d'un utilisateur doit être explicitement vérifiée pour une action à haut
risque. C'est différent de l'utiliser pour exécuter le paiement lui-même. Le flux se
déroulerait généralement comme suit :

1. **Authentification principale :** L'utilisateur se connecte à un service, souvent avec
   une méthode à faible friction comme un passkey.
2. **Déclenchement de l'authentification renforcée :** Pour une action à haute assurance
   (par exemple, un virement bancaire important, la mise à jour de données personnelles),
   le service exige une vérification d'identité explicite.
3. **Présentation du mdoc :** Le service demande une présentation du mdoc de l'utilisateur
   (par exemple, son permis de conduire). L'utilisateur présente les attributs requis
   depuis son Wallet.
4. **Vérification :** Le service vérifie cryptographiquement les données du mdoc par
   rapport à une source de confiance ou à une identité préalablement enregistrée.

Dans ce modèle, le mdoc fournit une preuve d'identité forte et résistante au
[phishing](https://www.corbado.com/glossary/phishing) pour un moment spécifique à haut risque. Cependant, la
transaction financière qui suit utilise toujours les circuits de paiement établis. Le mdoc
vérifie la _personne_, pas le _moyen de paiement_.

## 3. Le rôle d'OpenID4VC dans les scénarios de paiement potentiels

Bien que les mdocs eux-mêmes ne soient pas des instruments de paiement, des protocoles
comme OpenID for [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (OpenID4VC – qui
englobe [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) pour la présentation et
[OpenID4VCI](https://www.corbado.com/glossary/openid4vci) pour l'émission) offrent une couche de transport plus
flexible.

**Caractéristiques clés d'OpenID4VC :**

- **Protocole, pas contenu :** OID4VC définit comment demander et présenter des VCs, mais
  il est largement agnostique quant au format du contenu (payload) du VC lui-même. Il peut
  transporter des mdocs, des VCs standard du W3C (par exemple, au format
  [JWT](https://www.corbado.com/fr/glossary/jwks) ou SD-[JWT](https://www.corbado.com/fr/glossary/jwks)), ou d'autres types
  d'identifiants personnalisés.
- **Largeur des cas d'usage :** Cette flexibilité permet à des plateformes comme
  [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) (via son Credential Manager) de prendre
  en charge des demandes pour divers types d'identifiants via un mécanisme commun.
- **Compatibilité future pour les VCs de paiement :** Si l'industrie des paiements venait
  à standardiser un format d'identifiant de « jeton de paiement » ou d'« autorisation de
  paiement » vérifiable, OID4VC pourrait théoriquement transporter un tel identifiant
  entre le Wallet d'un utilisateur et un
  commerçant/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk).

**Cependant, OID4VC n'est pas une solution de paiement en soi :**

- Le rôle d'OID4VC est de faciliter l'échange d'un identifiant. Il ne définit pas le
  contenu de l'identifiant de paiement, ses caractéristiques de sécurité, ni la manière
  dont il interagit avec les systèmes de traitement des paiements.
- Pour qu'OID4VC soit utile pour les paiements, un _format d'identifiant de paiement
  vérifiable_ largement adopté, sécurisé et standardisé devrait d'abord être développé et
  pris en charge par l'écosystème des paiements (émetteurs, acquéreurs, réseaux). Cela
  n'existe pas actuellement.

## 4. Wallets tiers et paiements

Au-delà des Wallets natifs des plateformes, un écosystème croissant de Wallets tiers (par
exemple, EUDI Wallet, Wallets fournis par les banques, Wallets sectoriels spécialisés) est
en train d'émerger. Ces Wallets doivent naviguer entre la différence fondamentale entre
une [authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) rapide et à
faible friction et une vérification d'attributs à haute assurance, en particulier dans les
contextes de paiement.

[Le consensus émergent est que les Passkeys sont idéaux pour l'_authentification_ de base à un service de paiement](https://www.corbado.com/blog/digital-credentials-passkeys#34-payment-scenarios-low-friction),
car ils sont résistants au [phishing](https://www.corbado.com/glossary/phishing) et conçus pour une expérience
utilisateur fluide. Injecter une présentation d'identifiant numérique dans l'étape
critique de confirmation du paiement ajouterait une friction importante et nuirait
probablement aux taux de conversion. Par conséquent, le rôle principal des identifiants
numériques se situe dans la phase ponctuelle d'intégration à haute assurance et de
[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) qui permet les capacités de paiement,
plutôt que dans la transaction elle-même. Comment ces Wallets pourraient-ils aborder les
paiements, notamment en conjonction avec les fonctionnalités d'identité numérique ?

### 4.1 Modèles d'interaction actuels pour les paiements

Pour qu'un Wallet tiers autorise un paiement, il a besoin d'un moyen d'être appelé par
l'application ou le site web du commerçant. Il existe plusieurs modèles d'interaction
établis pour cela, chacun avec des niveaux différents d'intégration à la plateforme et
d'expérience utilisateur :

- **Deep Linking d'application à application :** C'est une méthode universelle où
  l'application du commerçant (native ou web) redirige l'utilisateur vers l'application du
  Wallet tiers en utilisant un schéma d'URL personnalisé (par exemple,
  `eudi-wallet://...`). Les détails de la transaction sont passés en paramètres dans
  l'URL. Après que l'utilisateur a confirmé le paiement dans l'application du Wallet,
  celle-ci le redirige vers l'application du commerçant via un autre deep link. Cela
  fonctionne sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) et Android mais implique un
  changement de contexte visible entre les applications.
- **Sélecteur de Wallet natif :** Avec le sélecteur de Wallet natif, une application peut
  appeler un service système générique qui affiche tous les gestionnaires de paiement ou
  Wallets enregistrés. L'utilisateur peut alors choisir son Wallet préféré dans une
  interface fournie par le système. Cela offre une sensation plus intégrée qu'un simple
  deep linking (API Digital Credentials).
- **Paiements simples par code QR :** Ce modèle est idéal pour les flux de l'ordinateur de
  bureau au mobile. Le site web du commerçant affiche un code QR contenant les détails de
  la transaction ou une URL. L'utilisateur scanne ce code avec son application de Wallet
  mobile, qui gère ensuite indépendamment la confirmation sur le téléphone. Le backend du
  Wallet communique ensuite l'approbation au système du commerçant.
- **Flux inter-appareils standardisés (FIDO CTAP) :** Une évolution de la méthode par code
  QR, qui utilise des protocoles comme le Client to
  [Authenticator](https://www.corbado.com/glossary/authenticator) Protocol (CTAP) de FIDO pour créer un canal
  direct, sécurisé et chiffré entre le navigateur de bureau (client) et le Wallet mobile
  (agissant comme un authentificateur). C'est plus sécurisé que les simples codes QR car
  le navigateur et le téléphone communiquent directement, un modèle fortement soutenu par
  Google pour les Passkeys et les identifiants numériques.
- **Intégration directe avec le backend :** Dans certains systèmes en circuit fermé,
  l'application du Wallet tiers peut interagir directement avec un fournisseur de services
  de paiement (PSP) ou le backend d'une institution financière pour traiter les paiements,
  souvent en utilisant des API propriétaires.

Ces modèles fournissent la « couche de transport » pour initier une confirmation de
paiement, au sein de laquelle un flux cryptographique (comme celui détaillé pour l'EUDI
Wallet) peut ensuite avoir lieu.

### 4.2 Intégration au navigateur : l'identité d'abord, les paiements séparément

Avec les annonces de la [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), le paysage de la gestion des
identifiants numériques par les navigateurs s'est beaucoup clarifié, consolidant la
séparation entre la vérification d'identité et le traitement des paiements. Les
plateformes permettent aux Wallets tiers d'interagir avec les navigateurs pour la
_vérification d'identité_ via l'API Digital Credentials du W3C, mais les approches
divergent :

- **La position d'Apple (confirmée à la WWDC25) :** Apple a officiellement annoncé le
  support de l'[API Digital Credentials](https://www.corbado.com/fr/blog/digital-credentials-api) dans Safari 26
  (livré avec [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)). Comme détaillé dans leur session
  [« Verify identity documents on the web »](https://developer.apple.com/videos/play/wwdc2025/232/),
  l'implémentation **prend exclusivement en charge le protocole `org.iso.mdoc`**. Cela
  permet aux sites web de demander des informations vérifiables à partir des mdocs dans
  Apple Wallet ou d'autres applications tierces de fournisseurs de documents enregistrées,
  mais ne prend pas en charge le protocole plus généraliste
  [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp). Avec le support croissant des identifiants
  numériques et des intégrations web améliorées, maintenir les performances et la sécurité
  du système devient encore plus crucial - des outils comme
  [CleanMyMac](https://cleanmymac.com/) aident à garantir que votre Mac fonctionne de
  manière optimale à mesure que ces technologies évoluent.
- **La position de Google :** Le Credential Manager d'Android permet aux Wallets tiers de
  s'enregistrer comme gestionnaires pour les demandes d'identifiants. Son implémentation
  de l'[API Digital Credentials](https://www.corbado.com/fr/blog/digital-credentials-api) dans Chrome se
  concentre sur l'utilisation d'**OpenID4VP** comme protocole de transport principal. Bien
  qu'OpenID4VP puisse transporter un mdoc comme contenu, le protocole lui-même est
  différent de l'approche directe `org.iso.mdoc` d'Apple.

**Point crucial, ces intégrations de navigateur sont destinées aux attributs d'identité,
et non à traiter le mDoc ou le VC présenté comme un instrument de paiement.**

Si un utilisateur présente un [mDL](https://www.corbado.com/blog/mobile-drivers-license) de son Wallet à un site
web via l'API Digital Credentials du navigateur, ce site pourrait utiliser l'information
pour pré-remplir une adresse ou vérifier l'âge lors du paiement. Cependant, l'étape de
paiement réelle nécessiterait toujours une interaction distincte avec une méthode de
paiement (par exemple, [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay),
[Google Pay](https://www.corbado.com/blog/how-to-use-google-pay), ou la saisie des détails de la carte). L'API du
navigateur elle-même n'est pas conçue pour initier ou traiter une transaction financière
en utilisant un identifiant.

## 5. Le portefeuille d'identité numérique de l'UE en pratique

Le [portefeuille](https://www.corbado.com/fr/blog/garantie-portefeuille-numerique)
d'[identité numérique](https://www.corbado.com/fr/glossary/openid-4-vp) de l'UE (EUDI Wallet) constitue une
excellente étude de cas sur la manière dont un Wallet tiers doit naviguer dans le paysage
complexe et réel des systèmes d'exploitation et de la disponibilité des API. Parmi ses
nombreuses fonctions, deux des cas d'usage les plus importants sont la vérification
d'identité et la confirmation de paiement, et les voies techniques pour accomplir ces deux
tâches sont différentes, surtout si l'on compare le cadre flexible d'Android à
l'implémentation plus rigide d'Apple.

### 5.1 Comparaison des modèles d'interaction : identité vs paiement

Le tableau suivant détaille comment l'EUDI Wallet peut être appelé pour la vérification
d'identité ou l'autorisation de paiement, en soulignant les différences de support entre
les plateformes.

| Modèle d'intégration                         | Identité (Android) | Identité (iOS) | Paiement (Android) | Paiement (iOS) |
| :------------------------------------------- | :----------------: | :------------: | :----------------: | :------------: |
| **API Digital Credentials**                  |         ✅         |       ✅       |        ✅\*        |       ❌       |
| **Sélecteur de Wallet natif**                |         ✅         |       ✅       |         ✅         |       ❌       |
| **Deep Linking d'application à application** |         ✅         |       ✅       |         ✅         |       ✅       |
| **Inter-appareils standardisé**              |         ✅         |       ❌       |         ✅         |       ❌       |

**Points clés de la comparaison :**

- **API Digital Credentials :** Cette norme émergente du W3C est agnostique au protocole
  et bien prise en charge pour l'**identité** sur les deux plateformes. Pour son
  implémentation, Android fournit un flux par défaut utilisant le protocole flexible
  OpenID4VP, qui peut transporter divers formats d'identifiants. L'implémentation d'Apple,
  en revanche, est strictement réservée au format `org.iso.mdoc`. Fait crucial, les
  navigateurs destinent cette API à des cas d'usage d'identité, et non à l'initiation de
  paiements.
- **Sélecteur de Wallet natif :** Les deux systèmes d'exploitation fournissent une
  interface utilisateur native pour sélectionner un Wallet, mais avec des limitations
  différentes. Android propose un sélecteur pour les applications d'identité et de
  paiement. [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) fournit un sélecteur pour les
  applications « Fournisseur de documents » d'identité enregistrées, mais n'en propose pas
  pour les applications de paiement tierces.
- **Deep Linking d'application à application :** C'est la solution universelle,
  fonctionnant de manière fiable pour les cas d'usage d'identité et de paiement sur les
  deux plateformes. Elle reste la principale méthode pour appeler un Wallet tiers pour les
  paiements sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios).
- **Inter-appareils standardisé :** Ce flux basé sur FIDO [CTAP](https://www.corbado.com/fr/glossary/ctap) est
  actuellement une fonctionnalité de l'écosystème Google/Android et n'est pas pris en
  charge sur iOS.

**(\*) Remarque sur les paiements via l'API DC :** Bien que l'utilisation d'OpenID4VP par
Android rende un flux de paiement _techniquement_ réalisable via l'API Digital
Credentials, ce n'est pas son objectif principal. Une intégration transparente pour les
paiements via cette API spécifique, par opposition à d'autres méthodes natives, reste à
voir et nécessiterait un support explicite des fournisseurs de navigateurs.

Cette comparaison montre clairement que si la vérification d'identité est de plus en plus
standardisée via l'API Digital Credentials, l'autorisation de paiement pour les Wallets
tiers comme l'EUDI Wallet repose encore fortement sur des modèles d'intégration natifs
plus traditionnels comme le deep linking d'application à application, en particulier sur
iOS.

### 5.2 Sous le capot : le flux de confirmation de paiement EWC

Quel que soit le modèle d'intégration de paiement utilisé pour appeler le Wallet, le cœur
de la confirmation de paiement de l'EUDI Wallet repose sur un flux cryptographique
standardisé détaillé dans
[`EWC RFC008`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc008-payment-data-confirmation.md).

Voici un aperçu de haut niveau de ce processus :

| Étape | Action                                      | Artefacts clés                                                                                                                                                                                                                                                                        |
| ----- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1     | **Demande d'autorisation**                  | Le commerçant ou le PSP envoie une requête OpenID4VP au Wallet contenant une `presentation_definition` qui référence une _Attestation de Wallet de paiement_ **et** un objet `transaction_data` encodé en base64url (montant, devise, bénéficiaire).                                  |
| 2     | **Examen et consentement de l'utilisateur** | Le Wallet affiche les détails du paiement lisibles par l'homme (par exemple, 23,58 € à _Commerçant XYZ_) et demande à l'utilisateur d'approuver avec un geste biométrique ou un code PIN.                                                                                             |
| 3     | **Présentation vérifiable**                 | Le Wallet renvoie une Présentation Vérifiable qui inclut (a) l'Attestation de Wallet de paiement sélectionnée (en tant que VC SD-JWT) et (b) un JWT de liaison de clé dont la revendication `transaction_data_hashes` prouve que l'utilisateur a signé le contenu exact de l'étape 1. |
| 4     | **Vérification**                            | Le PSP valide la présentation, vérifie que le hachage du `transaction_data` original correspond à celui dans le JWT, et s'assure que l'horodatage est récent.                                                                                                                         |
| 5     | **Mouvement des fonds**                     | Ayant satisfait à la SCA, le PSP procède au paiement normal par carte ou par compte, confiant que l'utilisateur a explicitement confirmé les détails de la transaction.                                                                                                               |

#### Exemple : Contenu des données de transaction

Ceci est un exemple non normatif de l'objet `payment_data` qui est envoyé au Wallet,
détaillant la transaction que l'utilisateur doit confirmer.

```json
{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}
```

#### Exemple : Revendications du JWT de liaison de clé

Après l'approbation de l'utilisateur, le Wallet crée un [JWT](https://www.corbado.com/fr/glossary/jwks) de
liaison de clé. Ses revendications prouvent que l'utilisateur a confirmé les données
spécifiques de la transaction.

```json
{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}
```

## 6. La réponse de l'industrie : convergence des paiements et de l'identité

Alors que les normes techniques évoluent, l'industrie du paiement ne reste pas inactive.
Les acteurs clés explorent activement comment fusionner la sécurité des identifiants
numériques avec la fonctionnalité des paiements.

### 6.1 Parallèles avec la tokenisation des paiements

Une excellente façon de comprendre le potentiel des Identifiants Vérifiables (VCs) est de
les comparer aux systèmes de tokenisation des paiements de réseau qui ont fait leurs
preuves (comme le [Visa](https://www.corbado.com/blog/visa-passkeys) Token Service ou le MDES de
[Mastercard](https://www.corbado.com/blog/mastercard-passkeys)).

- La **tokenisation des paiements** a remplacé le numéro de compte principal (PAN)
  sensible par un jeton sécurisé et un cryptogramme à usage unique. Cela protège l'actif
  principal — le numéro de carte — pendant les transactions.
- Les **Identifiants Vérifiables** visent à faire pour les données personnelles ce que la
  tokenisation a fait pour les PANs. Au lieu de partager des données brutes (nom, date de
  naissance, adresse), l'utilisateur présente un identifiant signé cryptographiquement par
  un émetteur de confiance.

En substance, **un VC est aux données personnelles ce qu'un jeton de paiement et un
cryptogramme sont aux données de carte** : un substitut sécurisé et vérifiable qui réduit
les risques et améliore la confidentialité.

### 6.2 L'essor des identifiants de paiement vérifiables

S'appuyant sur ce parallèle, les organismes de normalisation travaillent sur le concept
d'un « identifiant de paiement vérifiable ». Il s'agirait d'un identifiant, émis par une
banque, qui regroupe un instrument de paiement (comme une carte tokenisée) et peut être
utilisé pour autoriser des transactions.

- [**EMVCo**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc), l'organisme
  de normalisation pour les paiements sécurisés, intègre activement les normes FIDO dans
  le protocole EMV [3-D Secure](https://www.corbado.com/glossary/3d-secure). Cela permet d'utiliser les
  authentifications préalables par passkey comme un signal fort pour des approbations sans
  friction, tout en préparant le terrain pour que la
  [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) serve
  d'alternative moderne et résistante au [phishing](https://www.corbado.com/glossary/phishing) aux défis OTP
  traditionnels. Des discussions sont également en cours sur la manière dont les
  identifiants vérifiables pourraient être intégrés à ces flux à l'avenir.
- **Visa** a annoncé le
  [**Visa Payment Passkey Service**](https://www.corbado.com/blog/visa-passkeys), qui lie
  de manière sécurisée un authentificateur FIDO à des identifiants de paiement. Ce service
  est conçu pour confirmer l'identité et autoriser les paiements en une seule étape
  fluide, sans interrompre l'expérience de paiement.
- **Mastercard** suit une stratégie parallèle avec son
  [**Mastercard Payment Passkey Service**](https://www.corbado.com/blog/mastercard-passkeys),
  qui s'appuie sur son Token Authentication Service (TAS) pour remplacer les mots de passe
  et les OTP par une
  [authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) biométrique
  basée sur les Passkeys, étroitement intégrée à ses services de tokenisation (MDES).

Cela montre une tendance claire : l'industrie s'oriente vers un avenir où un Wallet pourra
présenter une preuve cryptographiquement vérifiable de l'identité et de l'autorisation de
paiement en un seul flux standardisé.

## 7. Le paysage réglementaire : l'Europe comme catalyseur

Une grande partie de cette innovation est accélérée par des vents réglementaires
favorables, en particulier de la part de l'Union européenne.

### 7.1 Le rôle de l'EUDI Wallet dans l'Authentification Forte du Client (SCA)

Le règlement
[eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) de l'UE ne
vise pas seulement à fournir aux citoyens une
[identité numérique](https://www.corbado.com/fr/glossary/openid-4-vp) ; il envisage explicitement
l'[EUDI Wallet](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en)
comme une méthode pour effectuer la SCA pour les paiements en ligne. Cela signifie qu'à
l'avenir, les banques et les fournisseurs de paiement de l'UE pourraient être tenus
d'accepter l'EUDI Wallet comme moyen pour les utilisateurs de confirmer les transactions
en ligne, offrant une alternative basée sur des normes aux applications bancaires
propriétaires ou aux codes SMS.

### 7.2 Le jardin clos NFC d'Apple est désormais ouvert (en Europe)

Un
[accord antitrust historique dans l'UE](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706)
a déjà forcé Apple à ouvrir son interface NFC jusqu'alors fermée sur les iPhones. Depuis
[iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).4 (sorti le 5 mars 2024), Apple a mis en œuvre
les API nécessaires et permis aux utilisateurs de choisir une application de paiement sans
contact par défaut, respectant ainsi la date limite contraignante de la Commission
européenne du 25 juillet 2024. Ce n'est plus une perspective d'avenir ; c'est la réalité
actuelle dans l'Espace économique européen (EEE).

Ce changement signifie que les applications de Wallet tierces peuvent désormais proposer
leurs propres solutions de paiement sans contact sur iOS, mettant fin au monopole de
longue date d'[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay). Les capacités clés désormais
disponibles pour les développeurs incluent :

- **Choix du Wallet par défaut :** Les utilisateurs de l'EEE peuvent définir une
  application tierce éligible comme leur application de paiement sans contact par défaut,
  qui peut être appelée par un double-clic sur le bouton latéral.
- **Intégration complète :** Ces Wallets peuvent utiliser les fonctionnalités de sécurité
  natives de l'iPhone, y compris [Face ID](https://www.corbado.com/faq/is-face-id-passkey) et Touch ID, pour
  l'autorisation de paiement.
- **Adoption concrète :** Plusieurs acteurs majeurs ont déjà lancé leurs solutions,
  notamment **Vipps MobilePay** en Norvège et **PayPal** en Allemagne.

Les implications de cette ouverture sont importantes et déjà en cours :

- **Concurrence accrue :** Les banques et les fintechs peuvent désormais concurrencer
  directement Apple Pay sur sa propre plateforme, ce qui devrait faire baisser les frais
  pour les émetteurs et stimuler l'innovation.
- **Utilisation plus large des identifiants :** Les mêmes API peuvent être utilisées pour
  plus que de simples paiements, y compris les badges d'entreprise, les titres de
  transport et les clés d'hôtel, sans avoir besoin d'être dans Apple Wallet.
- **Un chemin vers des identifiants standardisés :** Cela crée un précédent crucial. La
  même logique réglementaire qui a ouvert l'interface NFC pour les applications de
  paiement pourrait éventuellement être utilisée pour imposer le support d'« Identifiants
  de Paiement Vérifiables » standardisés et neutres (comme ceux pilotés pour l'EUDI
  Wallet), leur permettant de fonctionner aux côtés des solutions propriétaires.
- **Précédent mondial :** Bien que le changement soit actuellement limité à l'EEE, il
  établit un précédent mondial puissant. Les régulateurs d'autres régions, y compris les
  États-Unis, observent attentivement, et cela pourrait accélérer des ouvertures
  similaires dans le monde entier.

## 8. Le guide d'un émetteur : une stratégie pratique pour les paiements vérifiables

Pour les émetteurs de paiements (banques, réseaux, fintechs), naviguer dans la transition
vers les identifiants numériques nécessite une stratégie pragmatique et progressive.
L'objectif est de s'appuyer sur les atouts que vous contrôlez aujourd'hui pour vous
préparer à l'écosystème de demain. Ce guide décrit cette stratégie, passant d'actions
immédiates à faible regret à des évaluations stratégiques à plus long terme.

### Phase 1 : Étendre la couverture et sécuriser les paiements avec les Passkeys (Aujourd'hui)

Le fondement de toute future stratégie de Wallet est une
[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) sécurisée et largement
adoptée. La priorité immédiate est de maximiser la portée de votre application et de
renforcer son authentification pour la connexion et les paiements.

1. **Encourager l'adoption de l'application native :** Votre application mobile est votre
   futur Wallet. L'objectif principal est d'en faire un outil indispensable pour vos
   clients. Cette distribution et cet engagement constituent le fondement essentiel de
   toute future émission d'identifiants ou fonctionnalité de Wallet.

2. **Utiliser les Passkeys pour les paiements, en suivant le modèle de PayPal :** Déployez
   les Passkeys immédiatement, non seulement pour la connexion, mais aussi pour
   l'autorisation de paiement. Visez une expérience quasi équivalente aux solutions
   natives des plateformes comme Apple Pay. Pour les environnements réglementaires
   exigeant une [Authentification Forte](https://www.corbado.com/fr/blog/passkeys-dsp2) du Client (SCA), adoptez
   l'approche pragmatique de [PayPal](https://www.corbado.com/blog/paypal-passkeys) :
    - Tirez parti des Passkeys comme facteur d'authentification principal.
    - Combinez-les avec des signaux d'appareils de confiance (par exemple, les « appareils
      mémorisés » gérés via votre application ou des cookies sécurisés) pour satisfaire au
      facteur de « possession » de la SCA.
    - Cette combinaison vous permet de fournir une expérience de confirmation de paiement
      fluide et à faible friction, à la fois très sécurisée et conforme, sans attendre un
      support universel des VCs.

### Phase 2 : Faire évoluer les capacités avec les technologies émergentes (Prochains 24-36 mois)

Avec une application sécurisée et protégée par des Passkeys comme base, vous pouvez
commencer à intégrer sélectivement de nouvelles technologies d'identifiants là où elles
offrent une valeur claire.

3. **Surveiller l'essor des identifiants de paiement vérifiables :** Le concept d'un VC
   transportant un jeton de paiement est puissant mais pas encore standardisé. Votre rôle
   ici est d'être un observateur et un participant actif.
    - **Action :** Suivez de près les progrès au sein des organismes de normalisation
      comme EMVCo et le W3C. Soyez prêt à tirer parti des Identifiants de Paiement
      Vérifiables standardisés si et quand ils offrent un avantage clair par rapport aux
      flux existants basés sur les Passkeys.

4. **Intégrer les identifiants numériques pour les cas d'usage liés à l'identité :** À
   mesure que les Wallets d'identité numérique (comme l'EUDI Wallet) gagnent du terrain,
   intégrez l'API Digital Credentials pour les tâches _liées à l'identité_, et non pour
   les paiements.
    - **Action :** Utilisez les présentations de VC pour les processus à haute assurance
      où ils excellent :
        - **Intégration et KYC :** Simplifiez la création de nouveaux comptes.
        - **Authentification renforcée (Step-Up) :** Vérifiez l'identité pour les actions
          à haut risque.
        - **Récupération de compte :** Fournissez un chemin sécurisé pour les utilisateurs
          qui ont perdu leurs appareils.

### Phase 3 : Maintenir une référence sans friction et surveiller l'évolution des Passkeys

L'obstacle ultime à l'adoption de toute nouvelle technologie de paiement est la friction
pour l'utilisateur. Avant de remplacer un simple flux de passkey, une alternative basée
sur les VCs doit prouver qu'elle est non seulement plus sécurisée, mais aussi tout aussi
fluide.

5. **Comparer sans relâche à l'expérience en un clic :** La norme pour une expérience de
   paiement moderne est fixée par des leaders comme Apple Pay et son proche suiveur sur le
   Web, [PayPal](https://www.corbado.com/blog/paypal-passkeys). Tout nouveau flux que vous introduisez doit
   rivaliser avec leur confirmation quasi instantanée en un clic. Tous les signaux actuels
   indiquent que pour la grande majorité des transactions, la résistance au phishing des
   Passkeys offre un niveau de protection suffisant et une expérience utilisateur
   supérieure. N'ajoutez pas d'étape de présentation de VC à un flux de paiement si cela
   introduit une friction perceptible.

6. **Surveiller les signaux d'appareil in-band dans WebAuthn :** L'évolution des Passkeys
   n'est pas statique. Bien que les premières tentatives de fournir des signaux
   spécifiques à l'appareil aient été abandonnées, les organismes de normalisation
   travaillent activement à l'intégration de signaux de confiance de liaison d'appareil
   plus forts directement dans le protocole WebAuthn. Cela permettrait à une
   [partie de confiance](https://www.corbado.com/fr/glossary/relying-party) (RP) d'identifier un appareil de
   confiance lors d'une authentification par passkey, renforçant davantage le signal pour
   les moteurs de risque sans nécessiter une présentation de VC distincte et hors bande.
   Surveillez cet espace de près, car c'est la voie la plus probable vers une sécurité
   renforcée sans sacrifier l'expérience sans friction du passkey.

En suivant ce guide progressif, un émetteur peut construire une stratégie robuste et
pratique qui maximise la sécurité et améliore l'expérience utilisateur aujourd'hui, tout
en se préparant à adopter judicieusement les technologies de paiement vérifiables de
demain.

## 9. Défis et perspectives d'avenir pour les VCs dans les paiements

Pour que les identifiants numériques fassent partie intégrante des processus de paiement
au-delà du simple support du [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) ou de
l'authentification des utilisateurs aux comptes de paiement, plusieurs défis importants
doivent être relevés :

1. **Standardisation des VCs spécifiques aux paiements :** Un format d'identifiant
   vérifiable dédié, sécurisé et largement accepté pour les paiements doit être développé.
   Il devrait encapsuler des jetons de paiement, des données spécifiques à la transaction
   et potentiellement des éléments de sécurité dynamiques, dépassant de loin le champ des
   mdocs actuels axés sur l'identité ou des VCs génériques.
2. **Intégration avec les réseaux de paiement :** Toute solution de paiement basée sur les
   VCs doit s'intégrer de manière transparente aux réseaux de paiement mondiaux existants
   (Visa, Mastercard, etc.) ou proposer de nouveaux circuits viables. Cela implique des
   alignements techniques, de sécurité et de modèles économiques complexes.
3. **Conformité réglementaire :** Les paiements sont fortement réglementés (par exemple,
   [PSD2](https://www.corbado.com/blog/psd2-passkeys)/SCA en Europe,
   [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) au niveau mondial). Un système de
   paiement basé sur les VCs devrait respecter toutes les réglementations financières
   pertinentes, y compris celles relatives à la sécurité, à la protection des
   consommateurs et à la lutte contre la fraude.
4. **Adoption par les émetteurs et les acquéreurs :** Les banques, les institutions
   financières (en tant qu'émetteurs de VCs de paiement) et les acquéreurs de commerçants
   devraient investir dans l'infrastructure pour soutenir un tel système.
5. **Modèle de sécurité :** Un modèle de sécurité robuste spécifiquement pour les VCs de
   paiement serait essentiel, couvrant l'émission, le stockage (idéalement dans des
   éléments sécurisés matériels), la présentation et la révocation dans un contexte
   financier.
6. **Expérience utilisateur :** Bien que les VCs puissent offrir un contrôle à
   l'utilisateur, l'expérience de paiement doit rester rapide, intuitive et fiable pour
   être largement adoptée.

**Possibilités futures :**

- **VCs comme bons d'autorisation de paiement :** Les VCs pourraient représenter une «
  autorisation » de payer signée cryptographiquement à partir d'un compte lié, présentée
  via OpenID4VP, le transfert de fonds réel se produisant toujours via les circuits
  traditionnels.
- **VCs contenant des jetons de paiement :** Un VC standardisé pourrait être défini pour
  contenir de manière sécurisée un jeton de paiement (similaire à un DPAN EMV), qui est
  ensuite traité par les infrastructures de paiement existantes.
- **VCs de paiement en circuit fermé :** Des émetteurs ou des communautés spécifiques
  pourraient créer des VCs pour les paiements au sein de leurs propres systèmes en circuit
  fermé.

Cependant, ces possibilités sont largement conceptuelles à l'heure actuelle. La principale
motivation derrière le développement actuel des VCs et des mdocs, maintenant consolidée
par les implémentations concrètes des API de navigateur, reste axée sur la vérification
d'identité et l'[attestation](https://www.corbado.com/glossary/attestation) d'attributs, et non sur l'exécution
des paiements.

## 10. Conclusion : Une voie pragmatique pour les émetteurs

La convergence de l'identité numérique et des paiements présente un paysage complexe mais
navigable. Bien que la promesse d'un « identifiant de paiement vérifiable » unique et
universel soit séduisante, cet article conclut que la stratégie la plus efficace et la
plus pratique pour les émetteurs de paiements aujourd'hui est ancrée dans une réalité
différente : **la bataille pour la meilleure expérience utilisateur est primordiale, et
les Passkeys sont l'arme la plus puissante.**

Le guide stratégique est clair. La mesure immédiate et à faible regret consiste à se
concentrer sur la mise en place d'une
[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) imbattable, en l'utilisant
comme véhicule pour déployer des paiements basés sur les Passkeys capables de rivaliser
avec la norme « en un clic » sans friction établie par Apple Pay et
[PayPal](https://www.corbado.com/blog/paypal-passkeys). Cette approche répond aux besoins fondamentaux de
sécurité (grâce à la résistance au phishing) et d'expérience utilisateur aujourd'hui, en
utilisant une technologie mature et largement adoptée.

Dans ce modèle, les Identifiants Vérifiables trouvent leur rôle crucial, mais distinct.
Ils ne sont pas encore l'outil pour l'acte de paiement lui-même, mais sont indispensables
pour les tâches d'identité à haute assurance qui l'entourent : intégration sécurisée,
[récupération de compte](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) robuste et
[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) réglementaire.

L'avenir des paiements ne sera pas déterminé par une seule technologie, mais par une
attention constante portée à l'utilisateur. Le succès sourira aux émetteurs qui
maîtriseront d'abord l'expérience basée sur les Passkeys dans leurs propres applications,
tout en surveillant attentivement l'évolution des identifiants vérifiables et des signaux
de confiance in-band des Passkeys. Ils doivent être prêts à intégrer ces nouvelles
technologies non pas lorsqu'elles sont simplement disponibles, mais seulement lorsqu'elles
peuvent atteindre le formidable critère d'une expérience de paiement véritablement fluide,
sécurisée et supérieure.