Un vérificateur qui accepte une attestation de preuve d'âge parce que sa signature est bien formée n'a fait que la moitié du travail et a sauté la moitié importante. Une signature valide prouve seulement que le justificatif a été signé par une clé. Elle ne dit rien quant à savoir si cette clé appartient à un émetteur en qui l'UE accorde réellement sa confiance pour attester l'âge. Combler cet écart est le rôle de l'Age Verification Trusted List, et les recommandations relatives au vérificateur sont explicites : vous devez valider chaque attestation d'âge par rapport à elle avant d'accorder l'accès.
C'est l'étape que les équipes sautent le plus souvent — et celle sur laquelle un auditeur vous interrogera le plus sûrement.
La confiance est une liste, pas une signature
Dans l'écosystème EUDI, la confiance est ancrée dans des listes de confiance publiées : des registres lisibles par machine des entités autorisées à jouer un rôle donné. Pour la vérification d'âge, le registre pertinent est l'Age Verification Trusted List — l'ensemble des émetteurs dont un vérificateur conforme est autorisé à accepter les attestations de preuve d'âge.
La chaîne de validation que votre vérificateur doit mener à son terme :
- Analysez le
mso_mdocProof of Age présenté (l'attestationeu.europa.ec.av.1— voyez notre guide du développeur sur l'espace de noms). - Vérifiez la signature par rapport au certificat de l'émetteur.
- Ancrez ce certificat à l'Age Verification Trusted List — confirmez que l'émetteur y figure réellement.
- Seulement alors, accordez l'accès.
Sautez l'étape 3 et vous accepterez allègrement une attestation parfaitement signée d'un émetteur que personne n'a autorisé. C'est la différence entre validité cryptographique et confiance, et c'est toute la raison d'être des listes de confiance. Nous parcourons la version générale de cette chaîne dans Comment fonctionne la vérification eIDAS ; cet article en est l'instance spécifique à la vérification d'âge.
Il existe déjà une liste de test — dans l'environnement ACC
Vous n'avez pas à attendre la production pour construire cela. La Commission héberge déjà une Age Verification Trusted List de test dans l'environnement ACC (acceptation) du tableau de bord eIDAS. Un détail notable pour quiconque l'explore : l'émetteur de test de référence apparaît sous l'Islande dans cet environnement — un placement de test, et non une déclaration relative à un déploiement islandais. Utilisez la liste ACC pour développer et exercer dès maintenant votre logique d'ancrage de confiance face à une structure de liste réelle, en amont de la mise en service de la liste de production.
Le tableau de bord eIDAS est la même infrastructure qui hébergera les points d'accès des listes de confiance de production. Construire votre validation face à la liste ACC signifie que, lorsque la liste de production sera publiée, vous changerez un point d'accès et une ancre de confiance — et non l'architecture d'une capacité partant de zéro.
La distinction qui fait trébucher : liste AV ≠ liste WRPAC
C'est la clarification la plus importante de cet article. Le tableau de bord eIDAS hébergera plusieurs listes de confiance pour différents rôles, et les confondre conduit à des intégrations réellement erronées :
| Liste | Répond à la question | Utilisée par |
|---|---|---|
| Age Verification Trusted List | « Cet émetteur est-il autorisé à attester l'âge ? » | Le vérificateur, pour faire confiance à une preuve entrante |
| Liste des fournisseurs WRPAC | « Cette partie utilisatrice est-elle autorisée à demander des attributs ? » | Le portefeuille, pour faire confiance à une requête sortante |
Elles fonctionnent en sens opposés. L'Age Verification Trusted List vous protège, vous, le vérificateur, contre l'acceptation de preuves émanant d'émetteurs malveillants. La liste des fournisseurs WRPAC protège le portefeuille de l'utilisateur contre la divulgation d'attributs à des parties utilisatrices non enregistrées. Comme nous l'avons documenté, la liste des fournisseurs WRPAC n'est pas encore publiée — ses obligations s'appliquent à partir du 24 décembre 2026. La liste de test AV, en revanche, est déjà disponible en ACC. Même tableau de bord, listes différentes, calendriers différents, sens de confiance différents. Traitez-les comme une seule et même chose et vous câblerez votre vérificateur pour qu'il consulte le mauvais registre.
Réalités opérationnelles de la validation par liste de confiance
Quelques points d'ingénierie qui séparent une implémentation robuste d'une implémentation fragile :
- Mettez en cache, mais rafraîchissez. Les listes de confiance changent — des émetteurs sont ajoutés, des certificats sont renouvelés. Récupérez la liste, mettez-la en cache pour la performance, mais rafraîchissez-la selon un calendrier et gérez le cas où une ancre auparavant approuvée disparaît.
- Échouez de façon fermée. Si vous ne pouvez pas atteindre ou valider la liste de confiance, le comportement par défaut correct pour une barrière d'âge est de refuser, et non de laisser passer l'utilisateur. Un contrôle de confiance qui échoue de façon ouverte n'est pas un contrôle de confiance.
- Distinguez « pas encore publiée » de « vide ». Pendant cette période de transition, un point d'accès peut légitimement indiquer qu'une liste n'est pas publiée. C'est un état défini, et non une erreur à étouffer — exactement comme nous l'avons constaté avec le statut WRPAC dans l'UE-27 fin mai 2026, où le point d'accès WRPAC signale délibérément l'absence de publication. Votre code doit reconnaître la différence entre « la liste indique aucun émetteur » et « il n'y a pas encore de liste ».
- Séparez proprement les ancres de test et de production. La liste ACC (avec son émetteur de test islandais) ne doit jamais être une ancre de confiance dans votre vérificateur de production. Gardez une configuration d'environnement explicite afin qu'une ancre de test ne puisse jamais s'infiltrer dans la confiance de production.
Pourquoi c'est un avantage concurrentiel, et pas seulement une case à cocher
La plupart des fournisseurs de vérification d'âge aujourd'hui valident une signature et considèrent l'affaire close. Un vérificateur qui s'ancre correctement à l'Age Verification Trusted List de l'UE fait quelque chose de matériellement plus fort : il fait respecter la gouvernance de l'UE quant à qui peut attester l'âge, et pas seulement la cryptographie d'une signature isolée. Lorsqu'une partie utilisatrice régulée — un opérateur de jeu, une place de marché à accès restreint par l'âge, une plateforme relevant de l'article 28 du DSA — doit démontrer comment elle sait qu'une preuve d'âge est authentique, « nous nous ancrons à l'Age Verification Trusted List de l'UE » est une réponse bien plus forte que « la signature était correcte ». La même logique sous-tend nos intégrations WooCommerce et jeu en ligne.
En résumé
Valider par rapport à l'Age Verification Trusted List est l'étape qui convertit un justificatif signé en un justificatif de confiance. La liste de test existe dès aujourd'hui dans l'environnement ACC du tableau de bord eIDAS, il n'y a donc aucune raison de différer sa construction. Ancrez chaque preuve à la liste, échouez de façon fermée lorsque vous ne le pouvez pas, rafraîchissez votre cache, gardez les ancres de test et de production strictement séparées — et ne confondez jamais la liste des émetteurs AV avec la liste des fournisseurs WRPAC. Réussissez cela et votre vérificateur fait respecter la gouvernance de confiance de l'UE, et pas seulement des calculs.
Cet article reflète l'infrastructure de confiance de la vérification d'âge de l'UE en date de juin 2026. L'Age Verification Trusted List de production n'était pas encore en service au moment de la rédaction ; la liste de test ACC et ses placements sont réservés au développement. Vérifiez par rapport au tableau de bord eIDAS et aux recommandations en vigueur relatives au vérificateur avant de vous fier à des éléments spécifiques.
Partager cet article
Aidez les autres à en savoir plus sur la vérification eIDAS