Introduction

Dans notre premier article, nous avons posé le cadre réglementaire (eIDAS 2.0, directive permis de conduire 2025/2205, calendrier de déploiement). Cet article complémentaire répond à une question plus opérationnelle pour les professionnels qui devront s'intégrer au système :

Comment fonctionne réellement le EUDI Wallet sur le plan technique et opérationnel ?

Concrètement : qui sont les acteurs en jeu, sur quels standards techniques le wallet repose, comment se déroule une vérification de bout en bout, et qu'est-ce qu'un loueur de véhicules doit faire pour pouvoir lire un wallet le moment venu.

Le modèle à 4 acteurs (et pourquoi c'est important pour les loueurs)

Trop souvent on présente le wallet comme un échange entre deux parties (citoyen et service). En réalité, l'écosystème EUDI Wallet est généralement décrit, dans l'Architecture Reference Framework (ARF), autour de quatre rôles opérationnels distincts, chacun avec ses obligations propres.

1. Le Wallet Provider (fournisseur de wallet)

Une entité certifiée par un État membre qui édite l'application wallet. En France, France Identité est une identité numérique régalienne portée par l'État, adossée à la carte nationale d'identité électronique (CNIe) et opérée par France Titres (ex-ANTS). Elle est décrite officiellement comme une application souveraine conçue et garantie par l'État, adossée à la carte d'identité.

Conséquence : seul un wallet édité par un Wallet Provider certifié vaut juridiquement comme EUDI Wallet. Une simple app tierce qui prétendrait faire la même chose n'a pas la même valeur.

2. L'Attestation Provider (émetteur d'attestation)

L'autorité qui émet une donnée vérifiable, en signant cryptographiquement l'attestation avec sa clé. Selon le type d'attestation :

Attestation	Émetteur typique
Person Identification Data (PID)	État membre (autorité nationale)
Permis de conduire mobile (mDL)	Autorité nationale en charge des permis
Diplômes	Établissement d'enseignement
Attestation de droits sociaux	Organisme de sécurité sociale

C'est cette signature qui rend la donnée « vérifiable » : un Relying Party peut valider l'origine sans rappeler l'émetteur.

3. Le Holder (utilisateur)

Le citoyen, qui détient le wallet sur son smartphone, conserve les attestations et contrôle leur partage par consentement explicite à chaque demande.

4. Le Relying Party / Verifier (le loueur, dans votre cas)

Toute entité qui demande la présentation d'attestations. Point crucial pour les loueurs : pour pouvoir interroger un wallet, vous devrez être enregistré comme Relying Party authentifié, soit directement auprès d'une autorité, soit via un courtier d'accès qualifié. On y revient en fin d'article.

Source : Règlement (UE) 2024/1183, dispositions sur le cadre de confiance des wallets : https://eur-lex.europa.eu/eli/reg/2024/1183/oj

Les standards techniques sur lesquels le wallet repose

Le règlement eIDAS 2.0 ne réinvente pas les protocoles : il s'appuie sur des standards ouverts déjà établis. C'est important pour les loueurs car cela rend l'intégration possible avec des bibliothèques existantes.

Pour la communication wallet ↔ services

La famille OpenID for Verifiable Credentials (OpenID4VC), maintenue par la OpenID Foundation, comprend trois protocoles :

OpenID4VCI (Issuance) : comment un émetteur transmet une attestation au wallet
OpenID4VP (Presentation) : comment un Relying Party demande et reçoit des attestations
SIOPv2 (Self-Issued OpenID Provider v2) : authentification décentralisée du Holder

Pour les formats d'attestations

L'Architecture Reference Framework (ARF) retient deux formats :

mdoc (mobile document, ISO/IEC 18013-5) : format binaire CBOR, optimisé pour la présentation en proximité (NFC, Bluetooth)
SD-JWT VC (Selective Disclosure JWT Verifiable Credentials) : format texte JSON, optimisé pour la présentation en ligne

Pour le permis de conduire numérique spécifiquement

Deux normes ISO sont mobilisées :

ISO/IEC 18013-5:2021 — permis mobile en proximité (par exemple lors d'un contrôle routier physique)
ISO/IEC 18013-7 — extension pour la présentation en ligne (par exemple lors d'une location en ligne)

Sources :

Architecture Reference Framework (officiel Commission européenne) : https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
OpenID for Verifiable Credentials (OpenID Foundation) : https://openid.net
ISO/IEC 18013-5:2021 — Mobile driving licence : https://www.iso.org/standard/69084.html

Le niveau d'assurance « élevé » (Level of Assurance High)

Le règlement impose au EUDI Wallet le niveau d'assurance le plus élevé prévu par eIDAS, dit « high ».

Ce que cela implique

Le niveau « élevé » implique des exigences fortes d'authentification, de protection des clés et de certification, dont les modalités exactes dépendent des schémas nationaux et des actes d'exécution publiés en application du règlement. Cela recouvre généralement :

une authentification multi-facteur robuste de l'utilisateur lors d'opérations sensibles
une protection forte des clés cryptographiques du wallet
une vérification d'identité initiale rigoureuse au moment de la délivrance, conforme au niveau d'assurance « élevé » défini à l'article 8 du règlement eIDAS d'origine

Les implémentations concrètes (recours ou non à un élément sécurisé matériel, type de parcours d'enrôlement vidéo, etc.) restent à la main de chaque État membre dans le cadre de la certification.

Pourquoi c'est important pour les loueurs

Un wallet conforme à ce niveau garantit que la personne qui présente le permis est bien la personne authentifiée par l'État. Cela renforce la valeur juridique d'une vérification automatisée comparée à un simple scan de document papier.

Source : Règlement (UE) 2024/1183 imposant le niveau d'assurance « élevé » au sens de l'article 8 du règlement eIDAS originel.

La divulgation sélective : un changement de paradigme

C'est l'une des innovations majeures du EUDI Wallet par rapport aux documents physiques.

Ce que ça permet

Au lieu de présenter une attestation complète (un permis avec nom, prénom, photo, adresse, date de délivrance, numéro), le citoyen peut partager uniquement les champs strictement nécessaires à la transaction.

Exemple concret pour une location de véhicule

Demande loueur (cas typique) :

Information demandée	Pourquoi ?
Catégorie de permis valide (B)	Vérifier le droit de conduire le véhicule
Date de naissance	Vérifier l'âge minimum (souvent 21 ou 25 ans)
Nom + prénom	Établir le contrat

Informations qui n'ont pas vocation à être transmises (sauf justification spécifique) :

adresse complète
numéro de permis
photo
date exacte de délivrance

Le règlement impose explicitement le principe de minimisation des données : un Relying Party ne peut demander que les attributs strictement nécessaires à sa finalité déclarée.

Conséquence opérationnelle

Côté loueur, cela suppose trois adaptations :

Définir précisément les attributs nécessaires à votre processus, pas un de plus
Déclarer ces attributs lors de votre enregistrement Relying Party auprès de l'autorité
Adapter votre logiciel à un retour partiel — vous n'aurez plus systématiquement le numéro de permis ou l'adresse, par exemple, et vos workflows internes doivent en tenir compte

Source : Règlement (UE) 2024/1183, principe de minimisation à l'article 5 bis.

Le déroulé d'une vérification de bout en bout

Voici ce qui se passe concrètement quand un loueur demande la vérification d'un permis via le wallet, en flux en ligne (OpenID4VP) :

Phase 1 — Demande (Relying Party → Wallet)

Le système du loueur envoie une requête de présentation contenant :

l'identifiant du Relying Party, signé par son certificat d'accès
la liste des attributs demandés
la finalité déclarée (« location de véhicule »)
un nonce cryptographique pour empêcher les rejeux

Phase 2 — Consentement (Wallet → Holder)

Le wallet affiche au citoyen :

qui demande (loueur identifié de manière non répudiable, pas anonyme)
quels attributs précis sont demandés
la finalité déclarée

Le citoyen approuve par biométrie locale ou code, et la validation explicite déclenche la phase suivante.

Phase 3 — Présentation (Wallet → Relying Party)

Le wallet construit une réponse contenant :

les attributs sélectionnés (uniquement ceux explicitement consentis)
la signature du Wallet Holder, produite par la clé privée stockée dans l'élément sécurisé du téléphone
les signatures originales des Attestation Providers (l'autorité préfectorale pour le permis, par exemple)

Phase 4 — Vérification (Relying Party)

Le système du loueur valide cryptographiquement et localement :

la signature du Wallet (le téléphone n'a pas été compromis)
la signature de l'Attestation Provider (le permis vient bien de l'autorité légitime)
le statut de révocation (le permis n'a pas été suspendu — voir section dédiée plus bas)
le nonce et l'horodatage (la présentation est récente, ce n'est pas un rejeu)

L'ensemble se fait en temps machine, sans contrôle visuel manuel. Pas d'appel à l'émetteur original au moment de la vérification (sauf optionnellement pour la révocation).

Cette vérification cryptographique remplace ce qui se faisait jusqu'ici visuellement : « cette photo correspond à ce visage », « cet hologramme est authentique »…

La révocation : le piège souvent oublié

Une question critique pour les loueurs : que se passe-t-il si le permis du conducteur a été suspendu après son émission dans le wallet ? L'attestation cryptographiquement signée est toujours techniquement valide.

Deux mécanismes sont prévus dans l'ARF :

1. Status List (recommandée)

L'émetteur publie une liste de référence de l'état de toutes les attestations émises (valide / suspendue / révoquée). Le Relying Party interroge cette liste sans révéler quelle attestation précise il vérifie. C'est le standard W3C Bitstring Status List.

Avantage : préserve la vie privée (l'émetteur ne sait pas qui demande quelle vérification).

2. Vérification temps réel (online check)

Pour les usages très sensibles, le Relying Party peut interroger directement l'émetteur. Coûteux en privacy : l'émetteur sait qui vérifie quoi.

Pour la location

La Status List sera probablement suffisante : vérifier le statut quelques secondes avant la remise du véhicule. À discuter avec votre fournisseur logiciel.

Source : W3C Bitstring Status List : https://www.w3.org/TR/vc-bitstring-status-list/

Cas d'usage en proximité (sans connexion internet)

Avantage souvent oublié : le wallet fonctionne aussi sans connexion réseau active entre le téléphone et le terminal de vérification. Le protocole utilisé est ISO/IEC 18013-5 via NFC ou Bluetooth Low Energy (BLE).

Cas concret pour un loueur

Le client se présente devant un terminal d'agence ou ouvre la porte d'un véhicule équipé
Le wallet du conducteur communique en BLE/NFC avec le terminal du loueur
Le terminal vérifie cryptographiquement l'attestation en local, sans appeler Internet
Aucune donnée ne transite par les serveurs centraux

Conséquence

Le système est robuste face à :

une coupure internet de l'agence
un parking souterrain sans 4G
une zone rurale ou un événement avec réseau saturé

Source : ISO/IEC 18013-5:2021 : https://www.iso.org/standard/69084.html

Ce qu'un loueur doit préparer techniquement

Pour pouvoir lire un wallet à l'horizon 2027 (cible réaliste de déploiement opérationnel à grande échelle), un loueur doit anticiper sur deux fronts.

Côté software

Implémenter (ou intégrer un SDK) compatible OpenID4VP pour la vérification en ligne
Optionnel selon le cas d'usage : implémenter ISO 18013-5 (NFC/BLE) pour la vérification en proximité
Stocker et valider le certificat de Relying Party
Gérer la révocation (au minimum via Status List)

Côté légal et opérationnel

S'enregistrer comme Relying Party auprès de l'autorité nationale ou d'un courtier d'accès qualifié
Déclarer la liste précise des attributs demandés et la finalité associée
Mettre à jour les CGV sur le traitement des attributs reçus
Adapter les processus métier au retour partiel — on l'a dit : pas systématiquement de numéro de permis, ni d'adresse, etc.

Bonne nouvelle

La plupart des éditeurs de logiciels de gestion de location intégreront ces capacités progressivement. Posez la question à votre fournisseur dès maintenant pour comprendre sa roadmap : implémentation OpenID4VP, format mdoc/SD-JWT VC supporté, gestion de la révocation, plans pour ISO 18013-5.

Conclusion

Le EUDI Wallet n'est pas une simple application. C'est un système distribué de vérification d'identité reposant sur :

une chaîne de confiance à plusieurs acteurs (Wallet Provider, Attestation Provider, Holder, Relying Party)
des standards ouverts éprouvés (OpenID4VC, ISO 18013-5, SD-JWT VC, mdoc)
une cryptographie forte stockée dans un élément sécurisé matériel
un principe de minimisation et de divulgation sélective inscrit dans le règlement

Pour les loueurs, c'est plus qu'un changement technique : c'est un changement de modèle de confiance. On passe de la vérification visuelle (« cette photo correspond à ce visage », « ce hologramme est authentique ») à une vérification cryptographique vérifiable à la milliseconde, avec une valeur juridique au moins équivalente — et probablement supérieure.

L'enjeu en 2026-2027 n'est donc pas seulement « être prêt techniquement », mais aussi : être enregistré comme Relying Party, avoir défini ses attributs nécessaires, et avoir choisi un fournisseur logiciel capable de gérer cette transition.

Sources

Textes officiels

Règlement (UE) 2024/1183 (eIDAS 2.0) : https://eur-lex.europa.eu/eli/reg/2024/1183/oj
Architecture Reference Framework (officiel Commission européenne) : https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
Commission européenne — European Digital Identity : https://commission.europa.eu/topics/digital-economy-and-society/european-digital-identity_en

Standards techniques

OpenID for Verifiable Credentials, OpenID Foundation : https://openid.net
ISO/IEC 18013-5:2021 — Mobile driving licence : https://www.iso.org/standard/69084.html
W3C Bitstring Status List : https://www.w3.org/TR/vc-bitstring-status-list/

Article complémentaire

Permis numérique européen : la fin du contrôle au comptoir pour les loueurs de voitures ? : https://pass2rent.com/fr/blog/tech-et-automatisation-en-mobilite/permis-numerique-europeen-la-fin-du-controle-au-comptoir-pour-les-loueurs-de-voitures-guide-2026

Note méthodologique de l'auteur

Cet article décrit le fonctionnement du EUDI Wallet sur la base du règlement (UE) 2024/1183 et de l'Architecture Reference Framework publié en open source par la Commission européenne. Les protocoles cités (OpenID4VC, ISO/IEC 18013-5, SD-JWT VC, mdoc) sont ceux retenus dans les versions de référence de l'ARF.

Les modalités précises peuvent évoluer avec :

les futures versions de l'ARF (mises à jour régulières en open source)
les transpositions et profils nationaux spécifiques à chaque État membre
les profils techniques publiés par les pilotes (POTENTIAL, EWC, DC4EU, NOBID)

Aucune statistique de marché n'a été ajoutée dans cet article. Les chiffres sectoriels pertinents (40-70 millions de locations annuelles en Europe nécessitant une vérification de permis ; environ 54 M€/an d'acquisition de permis physiques dans l'UE) ont déjà été cités dans notre article précédent et restent applicables — ils ne sont pas répétés ici par souci de non-doublon.

EUDI Wallet : comment fonctionne concrètement le portefeuille d'identité numérique européen ?