EUDI Wallet fin 2026 : construire une preuve de vérification sans surcollecter

L’arrivée des portefeuilles européens d’identité numérique change la façon de demander une identité, un âge, un diplôme ou un droit. Elle ne supprime pas la question probatoire. Une organisation qui accepte une présentation EUDI Wallet doit encore pouvoir expliquer ce qu’elle a demandé, ce qu’elle a validé, selon quelle règle et pendant combien de temps elle conserve le résultat.

La mauvaise réponse consiste à archiver l’attestation complète, son jeton brut et toutes les données reçues « au cas où ». Cette copie peut augmenter le risque sans démontrer correctement la validation effectuée. La bonne unité de preuve est plus étroite : un reçu de vérification intègre, relié à une finalité déclarée et limité aux éléments nécessaires pour rejouer la décision.

Conclusion courte : la preuve utile n’est pas une copie du portefeuille. C’est la trace intègre d’une vérification déterminée, effectuée à un instant donné, avec une politique et des sources de confiance identifiables.

Fin 2026 est une échéance de disponibilité, pas un droit de tout demander

La Commission européenne indique que chaque État membre doit fournir au moins un EUDI Wallet d’ici la fin de 2026. La règle juridique précise figure à l’article 5 bis du règlement eIDAS consolidé : le délai est de vingt-quatre mois à compter de l’entrée en vigueur des actes d’exécution visés par le texte.

Cette échéance concerne la mise à disposition des wallets. Elle ne signifie ni que tous les services seront intégrés au même rythme, ni que toutes les interfaces auront atteint leur état technique définitif. Le règlement d’exécution 2026/1731, publié le 22 juillet 2026, illustre cette transition : il met à jour plusieurs normes et spécifications, mais reporte au 11 août 2028 l’application de l’obligation technique imposant aux wallets d’authentifier et de valider le certificat d’enregistrement d’une partie utilisatrice.

Pour une organisation qui prépare un service fin 2026, trois états doivent donc rester distincts :

État	Question à trancher	Preuve attendue
Disponibilité	Un wallet certifié et utilisable est-il proposé dans l’État concerné ?	Référence de la solution et statut de confiance
Interopérabilité	Le flux choisi fonctionne-t-il avec les wallets et formats ciblés ?	Tests de conformité, versions et résultats
Exploitabilité probatoire	La décision peut-elle être expliquée sans conserver l’attestation entière ?	Reçu de vérification et règle de conservation

L’Architecture and Reference Framework, dont la version 2.9.0 a été publiée le 21 mai 2026, constitue le cadre technique de référence maintenu par l’écosystème européen. Son évolution confirme l’intérêt de conserver la version des profils et du vérificateur mobilisés, plutôt que d’écrire une procédure comme si les dépendances étaient figées.

La demande d’attributs est liée à une utilisation enregistrée

L’article 5 ter du règlement eIDAS consolidé impose aux parties qui veulent utiliser le wallet pour un service public ou privé de s’enregistrer dans leur État d’établissement. L’enregistrement comprend l’utilisation prévue et les données que la partie utilisatrice doit demander. Celle-ci ne peut pas demander d’autres données que celles déclarées pour cette utilisation.

Le règlement d’exécution 2025/848 détaille ces informations. Pour chaque utilisation prévue, le registre comprend notamment la liste des données, attestations et attributs demandés, avec leur dénomination technique et leur format lisible par machine.

Le règlement d’exécution 2026/1730, publié cinq jours avant cette analyse et entrant en vigueur le 11 août 2026, renforce le mécanisme :

• au moins une autorité de certification doit être autorisée par chaque État membre à délivrer les certificats d’enregistrement ;
• ces certificats doivent être délivrés automatiquement et sans retard injustifié après l’enregistrement ;
• chaque utilisation prévue doit être exprimée dans le certificat ;
• une politique d’accès générale doit indiquer que seules les données enregistrées pour cette utilisation peuvent être demandées ;
• le wallet doit informer l’utilisateur lorsqu’une partie demande une donnée absente du certificat ;
• la partie utilisatrice doit fournir l’URL de la politique de confidentialité correspondant à l’utilisation prévue.

Ces règles construisent un contrôle de périmètre. Elles ne répondent pas seules à la question suivante : quelle trace la partie utilisatrice doit-elle conserver pour démontrer que son propre vérificateur a correctement contrôlé la présentation ?

Vérifier une présentation ne revient pas à lire un attribut

Une réponse comme age_over_18 = true ne devient pas fiable parce qu’elle est affichée dans une interface. Le vérificateur doit séparer les couches qui soutiennent sa décision.

Couche	Contrôle	Limite de la conclusion
Partie utilisatrice	Identité de la partie, certificat d’accès et utilisation enregistrée	Ne prouve pas la validité de l’attestation présentée
Demande	Attributs demandés conformes à l’utilisation enregistrée	Ne prouve pas que les attributs reçus suffisent à la règle métier
Wallet	Authenticité et validité de l’unité de portefeuille selon les mécanismes applicables	Ne prouve pas que toute donnée du wallet est encore valide
Attestation	Signature ou cachet, émetteur, période de validité et statut de révocation	Établit un état à l’instant du contrôle, pas une vérité permanente
Liaison	Présentation reliée au wallet, à la clé ou au mécanisme prévu par le profil	Ne prouve pas à elle seule l’identité civile de la personne devant l’écran
Décision	Règle métier appliquée au résultat validé	Reste une conclusion de la partie utilisatrice

Le règlement d’exécution 2024/2977 exige que les attestations contiennent les informations nécessaires à leur authentification et à leur validation. Il organise aussi la gestion du statut de validité et la révocation des données d’identification personnelle. Le règlement eIDAS consolidé place la responsabilité de l’authentification et de la validation des données d’identification personnelle et des attestations demandées sur la partie utilisatrice.

Le journal du wallet n’est pas le reçu de la partie utilisatrice

Le règlement d’exécution 2024/2979 impose à l’instance de wallet de journaliser toutes ses transactions avec les parties utilisatrices et les autres wallets, qu’elles aboutissent ou non. Le journal comprend au minimum :

• la date et le lieu de la transaction ;
• le nom, les coordonnées et l’identifiant unique de la partie utilisatrice ainsi que son État d’établissement ;
• les types de données demandées et présentées ;
• la raison de l’échec lorsqu’une opération n’aboutit pas.

Le même article impose l’intégrité, l’authenticité et la confidentialité de ces éléments. Il permet à l’utilisateur de les exporter. Leur accès par le fournisseur de wallet est limité aux besoins du service et subordonné au consentement préalable explicite de l’utilisateur.

Ce journal répond à un objectif de traçabilité du wallet et de contrôle par l’utilisateur. Il ne documente pas nécessairement le moteur de validation de la partie utilisatrice, la version exacte de sa politique, les sources de statut consultées, le résultat de chaque contrôle ou la règle métier appliquée.

Dans les textes examinés pour cette analyse, aucun format harmonisé de reçu de vérification destiné à la partie utilisatrice n’est imposé. Concevoir ce reçu relève donc d’une décision d’architecture et de conformité. Il ne faut ni le présenter comme un document officiel EUDI, ni lui attribuer un effet juridique automatique.

Proposition BLACKPROOF : un reçu minimal de vérification

La structure suivante est une proposition opérationnelle BLACKPROOF. Elle vise à documenter la décision sans dupliquer par défaut le PID, l’attestation électronique d’attributs ou le jeton de présentation.

Champ proposé	Fonction probatoire	Contenu à éviter
receipt_schema	Identifier le schéma et sa version	Un libellé non versionné
verification_id	Relier les journaux internes d’un seul traitement	Un identifiant global réutilisé entre services
verified_at	Fixer l’instant du contrôle avec fuseau explicite	Une date locale ambiguë
intended_use	Référencer l’utilisation enregistrée et la politique de confidentialité	Une finalité libre réécrite après la transaction
relying_party_check	Conserver le résultat, l’empreinte et le statut du certificat contrôlé	Le certificat complet si sa copie n’est pas nécessaire
requested_types et presented_types	Montrer le périmètre demandé puis reçu	Les valeurs de tous les attributs
attestation_check	Enregistrer format, émetteur, validité, statut et résultat cryptographique	Le jeton brut par réflexe
binding_check	Identifier le contrôle de liaison prévu par le profil	Une affirmation générique « utilisateur authentifié »
decision	Conserver le résultat strictement nécessaire à la finalité	La donnée source plus précise lorsque le résultat suffit
validator	Versionner le logiciel, le profil et la politique de validation	« Validation OK » sans règle reproductible
integrity	Signer ou sceller le reçu et ses références	Une empreinte sans convention de calcul
retention	Associer fondement, durée, échéance et procédure d’effacement	Une conservation indéfinie « en cas de litige »

Pour un contrôle d’âge, la solution européenne recommandée en avril 2026 illustre le principe de minimisation : prouver le franchissement d’un seuil sans révéler l’âge exact, l’identité ou d’autres informations personnelles. Si le service a seulement besoin de savoir qu’une personne a au moins 18 ans, conserver la date de naissance et le portrait augmente le périmètre sans renforcer nécessairement la preuve de la décision.

Le reçu reste lui-même susceptible de contenir des données à caractère personnel. Un résultat d’âge, une date, un identifiant local ou une combinaison de métadonnées peuvent permettre de distinguer ou de retrouver une personne. La minimisation ne transforme pas automatiquement le reçu en donnée anonyme.

Conserver la décision, référencer le contexte, écarter le surplus

Le RGPD, article 5, exige que les données soient adéquates, pertinentes et limitées à ce qui est nécessaire pour la finalité. Il impose aussi une durée de conservation n’excédant pas celle nécessaire et la capacité du responsable du traitement à démontrer le respect de ces principes. Son article 25 étend cette exigence à la conception et aux paramètres par défaut.

L’exception doit donc être documentée avant la collecte. Une banque, une autorité publique ou un acteur soumis à une règle sectorielle peut avoir une obligation spécifique d’identification ou de conservation. La présence de cette obligation doit être reliée au champ conservé, à sa durée et à son accès. Le seul souhait de disposer d’un dossier « plus complet » ne démontre pas la nécessité.

Une empreinte ne rend pas la donnée anonyme

Remplacer un identifiant ou une attestation par une empreinte peut préserver l’intégrité d’une référence et réduire l’exposition directe. Cela ne suffit pas à faire sortir le reçu du RGPD.

Le considérant 26 du RGPD précise que des données pseudonymisées qui peuvent être attribuées à une personne à l’aide d’informations supplémentaires restent des informations concernant une personne identifiable. Une empreinte d’adresse électronique, de numéro client ou de jeton à faible variabilité peut encore permettre une comparaison, une recherche ou une réattribution.

La conception doit distinguer :

• l’empreinte d’un objet pour vérifier son intégrité ;
• un identifiant pseudonyme local pour relier un dossier ;
• une donnée véritablement anonyme, pour laquelle la personne n’est plus identifiable par des moyens raisonnablement susceptibles d’être utilisés.

Le reçu ne doit pas promettre l’anonymat si le système conserve ailleurs la table de correspondance, la transaction métier ou les journaux permettant de retrouver la personne.

L’accord de partage dans le wallet n’est pas automatiquement la base juridique

Le wallet donne à l’utilisateur un contrôle sur la présentation. Ce geste ne règle pas, à lui seul, la licéité de tout traitement ultérieur par la partie utilisatrice.

Le règlement d’exécution 2026/1731 le dit expressément pour le portrait : la confirmation explicite de sa divulgation constitue une garantie technique, pas en elle-même un fondement juridique du traitement. Le même texte interdit par défaut à la partie utilisatrice de conserver le portrait, sauf nécessité pour l’identification et l’authentification conforme au droit de la protection des données ou obligation prévue par le droit de l’Union ou le droit national.

La partie utilisatrice doit donc identifier séparément :

1. la finalité du traitement ;
2. la base juridique applicable au titre de l’article 6 du RGPD et, le cas échéant, les conditions de l’article 9 ;
3. les attributs strictement nécessaires ;
4. la décision conservée ;
5. la durée et les destinataires du reçu ;
6. la procédure d’exercice des droits et d’effacement.

Le test opérationnel en huit questions

Avant d’ouvrir un flux EUDI Wallet en production, le RSSI, le DPO, le responsable métier et l’équipe de preuve peuvent exiger huit réponses vérifiables :

1. L’utilisation prévue et chaque attribut demandé figurent-ils dans l’enregistrement de la partie utilisatrice ?
2. Le service peut-il demander une propriété dérivée plutôt que la donnée précise, par exemple un seuil d’âge plutôt que la date de naissance ?
3. Quels contrôles portent sur la partie utilisatrice, le wallet, l’attestation, son émetteur, son statut et sa liaison ?
4. Le résultat distingue-t-il une validation réussie, une absence de donnée, une révocation, une expiration et une erreur technique ?
5. Le reçu permet-il de retrouver la politique, le vérificateur et les sources de confiance utilisés à l’instant du contrôle ?
6. Le reçu est-il intègre, exportable et vérifiable sans dépendre exclusivement du système qui l’a produit ?
7. Chaque donnée conservée possède-t-elle une finalité, une base, une durée et un propriétaire d’effacement ?
8. Un test négatif démontre-t-il que le service refuse ou signale une demande hors périmètre et qu’il n’archive pas le jeton brut par défaut ?

Ces contrôles peuvent rejoindre le ProofPack comme pièces versionnées : enregistrement de la partie utilisatrice, politique de validation, matrice des attributs, vecteurs de test, exemple de reçu expurgé et preuve d’effacement. La méthode BLACKPROOF permet ensuite de distinguer les faits techniques, la règle métier et la conclusion soutenue.

Inconnues et limites au 27 juillet 2026

Les points suivants ne doivent pas être présentés comme résolus :

• les registres, procédures d’enregistrement et calendriers de déploiement resteront opérés par les États membres ;
• le règlement 2026/1730 vient d’être publié et n’entre en vigueur que le 11 août 2026 ;
• l’authentification et la validation du certificat d’enregistrement par le wallet ne deviennent obligatoires qu’au 11 août 2028 ;
• les profils, normes référencées et implémentations continuent d’évoluer, comme le montre la mise à jour 2026/1731 ;
• le droit sectoriel peut imposer des contrôles ou des conservations supplémentaires ;
• une validation réussie prouve l’état contrôlé à un instant donné, pas l’exactitude éternelle de l’attribut ni la présence continue de la même personne.

Une organisation ne peut donc pas acheter aujourd’hui une « conformité EUDI fin 2026 » générique. Elle peut en revanche construire un contrat de vérification testable : finalité enregistrée, demande minimale, contrôles versionnés, décision explicite, reçu intègre et effacement démontrable.

Décision

Le meilleur indicateur de maturité n’est pas le nombre d’attributs qu’un service sait extraire. C’est sa capacité à répondre, pour chaque décision, à quatre questions :

• quelle donnée était nécessaire ;
• quelle propriété a réellement été vérifiée ;
• quelle trace suffit pour le démontrer ;
• à quelle date cette trace sera effacée ou renouvelée.

Le wallet européen apporte des mécanismes de confiance, de divulgation sélective et de contrôle utilisateur. La partie utilisatrice reste responsable de la validation demandée et du traitement qu’elle choisit d’effectuer. Un reçu minimal, signé, versionné et soumis à une durée explicite transforme cette responsabilité en preuve contrôlable sans faire de chaque interaction une nouvelle base d’identité à conserver.