Si vous suivez l'obligation WRPAC sous le seul angle du texte juridique, vous n'avez lu que la moitié de la spécification. Le règlement d'exécution vous dit que vous devez vous enregistrer. Il ne vous dit pas comment un portefeuille reconnaîtra votre enregistrement au moment d'une transaction. Cette seconde moitié se trouve dans le cadre d'architecture et de référence (ARF), et le 21 mai 2026 elle a franchi une étape importante vers sa stabilisation : la version 2.9.0 de l'ARF a marqué le Topic X — Enregistrement des parties utilisatrices comme Final.
Pour une partie utilisatrice qui planifie une intégration au portefeuille EUDI, il s'agit de la version de l'ARF la plus déterminante depuis des mois. Voici ce qui a réellement changé et pourquoi cela compte pour votre stratégie WRPAC.
Ce qu'est l'ARF, et pourquoi « Final » est un mot qui pèse
L'ARF est le compagnon technique vivant que la Commission européenne associe au règlement eIDAS 2.0. Là où les actes juridiques énoncent des obligations, l'ARF les exprime sous forme d'exigences de haut niveau (High-Level Requirements, HLR) — des énoncés numérotés et testables sur lesquels les développeurs (fournisseurs de portefeuilles, émetteurs et vérificateurs) construisent leurs implémentations. Chaque domaine fonctionnel est organisé en « Topic », et les Topics traversent des états de projet et de discussion avant d'être déclarés Final.
Le passage d'un Topic au statut Final ne le fige pas pour autant définitivement — l'ARF continue d'être révisé — mais cela signale que le groupe de travail considère le domaine comme suffisamment stable pour qu'on puisse l'implémenter sans craindre que le terrain ne se dérobe sous vos pieds. Le fait que le Topic X couvrant l'enregistrement des parties utilisatrices atteigne ce stade signifie que le modèle de données d'enregistrement et les mécaniques d'authentification constituent désormais une cible délibérée, et non mouvante.
C'est exactement l'assurance dont une partie utilisatrice a besoin avant d'engager du temps d'ingénierie. C'est la distinction que nous avons tracée dans WRPAC de production vs certificat de sandbox : construire sur une spécification stable plutôt que sur un projet que vous devrez reconstruire.
Le Topic X en termes simples : trois choses que vous devez déclarer
L'enregistrement des parties utilisatrices, tel que finalisé dans la 2.9.0, formalise la chaîne qui va de qui vous êtes à ce qu'un portefeuille vous autorisera à demander. Trois catégories d'exigences de haut niveau l'ancrent :
-
Authentification de la partie utilisatrice. Le portefeuille — et l'utilisateur derrière lui — doit pouvoir vérifier cryptographiquement que la partie qui demande des attributs est bien celle qui s'est enregistrée. C'est le rôle que joue concrètement un Wallet-Relying Party Access Certificate (WRPAC) : il lie votre identité enregistrée aux clés qui signent vos requêtes de présentation.
-
Coordonnées et données d'identification. L'enregistrement doit comporter des informations vérifiables sur l'entité juridique derrière la partie utilisatrice — les données qu'un registre national détient et qu'un portefeuille peut présenter à l'utilisateur afin qu'il sache qui formule la demande.
-
Usage prévu (les attributs demandés). Une partie utilisatrice déclare, au moment de l'enregistrement, quels attributs elle entend demander et dans quel but. Un portefeuille peut alors confronter une requête en direct à ce périmètre déclaré. Demandez plus que ce pour quoi vous vous êtes enregistré, et un portefeuille conforme pourra refuser.
Ce troisième point est celui que la plupart des équipes sous-estiment. L'enregistrement n'est pas une simple formalité administrative ponctuelle — il définit une enveloppe de périmètre qui contraint chaque transaction que vous mènerez. Pour un cas d'usage de vérification d'âge, c'est libérateur : une partie utilisatrice qui s'enregistre uniquement pour un attribut de preuve d'âge est, de manière visible et démontrable, incapable de demander une date de naissance ou une identité complète, ce qui correspond précisément au discours de minimisation des données que les régulateurs souhaitent entendre. Nous avons exploré ce même principe sous l'angle de la protection des données dans Conformité RGPD : comment eIDAS minimise la collecte de données.
Comment le Topic X se rattache au WRPAC et au WRPRC
L'ARF distingue deux types de certificats qui reposent sur l'enregistrement, et le Topic X de la 2.9.0 est le tissu conjonctif entre les deux :
- WRPAC — Wallet-Relying Party Access Certificate. Authentifie la partie utilisatrice auprès du portefeuille lorsqu'elle formule une requête d'accès (de présentation). C'est le certificat qui intéresse la plupart des marchands et des vérificateurs.
- WRPRC — Wallet-Relying Party Registration Certificate. Atteste de l'enregistrement lui-même — les droits et le périmètre d'usage prévu consignés dans le registre national.
Le Topic X est ce qui rend ces deux éléments cohérents : il définit les données saisies lors de l'enregistrement (le contenu du WRPRC) et les exigences d'authentification que le certificat d'accès (WRPAC) doit satisfaire. Si vous avez lu notre guide complet de l'enregistrement des parties utilisatrices, le Topic X en est l'expression au niveau des HLR.
La moitié juridique : le règlement d'exécution 2025/848
L'ARF ne se suffit pas à lui-même. La base juridique de l'enregistrement des parties utilisatrices est le règlement d'exécution (UE) 2025/848 de la Commission, adopté en vertu de l'article 5 ter, paragraphe 11 du règlement eIDAS. Deux dates importent :
- Il est entré en vigueur à la mi-2025 (peu après son adoption le 6 mai 2025).
- Ses obligations de fond s'appliquent à partir du 24 décembre 2026.
C'est cette seconde date qu'il faut entourer. Comme nous l'avons documenté dans l'instantané du statut WRPAC dans l'UE-27, aucun État membre n'exploite actuellement de voie WRPAC de production vérifiable publiquement, et le point d'accès à la liste de confiance à l'échelle de l'UE sur le tableau de bord eIDAS n'est pas encore publié. Ce n'est pas un échec — la date d'application n'est tout simplement pas encore arrivée. Que l'ARF 2.9.0 finalise le Topic X avant que l'obligation juridique ne s'applique, c'est le système qui fonctionne dans le bon ordre : stabiliser la spécification, puis ouvrir les registres.
Une remarque sur ce que nous ne pouvons pas encore confirmer. L'ensemble exact des informations qu'une partie utilisatrice doit soumettre au titre de l'annexe I du 2025/848 — et la question de savoir si la discussion de mars 2026 autour de l'acte d'enregistrement (soulevée par des organisations sectorielles telles que Bitkom, qui soutiennent que le détail technique relève des normes plutôt que de la loi) en remaniera la composition — reste en mouvement. Considérez la liste des champs de l'annexe I comme stable dans sa structure, mais vérifiez les spécificités par rapport au texte officiel avant de construire un formulaire d'enregistrement.
Ce que cela signifie pour votre feuille de route
L'enseignement pratique est une question de séquençage. Le Topic X étant Final, vous pouvez accomplir un vrai travail dès maintenant, en amont de la date d'application du 24 décembre 2026 :
| Ce que vous pouvez faire dès maintenant | Ce sur quoi vous devriez attendre |
|---|---|
| Concevoir votre vérificateur selon le modèle d'authentification du Topic X | Soumettre une demande de WRPAC de production (registres non ouverts) |
| Décider et documenter votre périmètre d'usage prévu (quels attributs, dans quel but) | Vous ancrer à une chaîne d'autorité de certification nationale spécifique (pas encore publiée) |
| Construire et tester les flux de signature des requêtes de présentation en sandbox | Considérer tout certificat actuel comme un WRPAC de production |
| Mapper votre cas d'usage à l'ensemble minimal d'attributs | Coder en dur des hypothèses sur les champs de l'annexe I avant que le texte ne soit finalisé |
Pour une partie utilisatrice dont le cas d'usage est spécifiquement la vérification d'âge, le séquençage est encore plus net, car l'implémentation de référence de la vérification d'âge de l'UE exerce déjà le côté vérificateur de ces exigences dans un environnement de test — voyez notre prochain article compagnon sur la validation de la preuve d'âge par rapport à la liste de confiance de l'UE, ainsi que sur le flux de requête DC API / OpenID4VP qu'une partie utilisatrice enregistrée utilise pour formuler ces requêtes.
En résumé
L'ARF 2.9.0 n'a pas modifié l'échéance WRPAC — elle reste fixée au 24 décembre 2026 au titre du règlement d'exécution 2025/848. Ce qu'elle a modifié, c'est votre niveau de confiance : le modèle de données d'enregistrement et les mécaniques d'authentification sous-jacentes au WRPAC constituent désormais un Topic Final. Vous pouvez bâtir votre architecture sur ces bases sans craindre qu'elles ne bougent.
Les parties utilisatrices qui seront prêtes dès le premier jour ne sont pas celles qui attendent l'ouverture des registres. Ce sont celles qui, aujourd'hui, ont déjà arrêté leur périmètre d'usage prévu, construit leur flux de signature des requêtes selon le modèle stable du Topic X, et l'ont testé de bout en bout. L'ARF 2.9.0 est le feu vert pour en faire partie.
Cet article reflète l'ARF dans sa version 2.9.0 (21 mai 2026) et la position réglementaire en date de juin 2026. Les deux suivent une cadence active en 2026 — vérifiez les dates et les spécificités des annexes par rapport au dépôt officiel de l'ARF et à EUR-Lex avant de vous y fier.
Partager cet article
Aidez les autres à en savoir plus sur la vérification eIDAS