L’échéance du portefeuille européen d’identité numérique se rapproche, et la question n’est plus de savoir si vos utilisateurs présenteront un jour une attestation issue d’un wallet, mais si votre plateforme saura la lire, la vérifier et n’en garder aucune trace inutile. Trois capacités conditionnent tout le reste : consommer une attestation vérifiable via un protocole standardisé, exploiter la divulgation sélective pour ne demander qu’un attribut, et prouver que vous ne conservez rien au-delà du strict nécessaire. Le reste est de l’intégration.
Le règlement (UE) 2024/1183, dit eIDAS 2, impose à chaque État membre de mettre un portefeuille d’identité numérique à disposition de ses citoyens, et oblige un large ensemble de services en ligne à l’accepter lorsqu’une authentification forte de l’utilisateur est requise. Autrement dit : vous ne choisissez pas d’adopter l’EUDI Wallet, vous choisissez seulement la qualité de votre intégration.
Le piège classique, celui que nous voyons remonter des DSI que nous accompagnons, consiste à traiter le wallet comme un fournisseur d’identité supplémentaire, un connecteur de plus dans la stack d’authentification. C’est une erreur d’architecture. Un portefeuille européen ne vous envoie pas un profil utilisateur : il vous transmet une preuve cryptographique portant sur un attribut précis, signée par un émetteur de confiance, présentée par le porteur lui-même. Le modèle mental change complètement. Vous passez d’une logique « je récupère des données » à une logique « je vérifie une assertion ».
L’écosystème européen s’est stabilisé autour d’OpenID for Verifiable Credentials : OpenID4VCI côté émission, OpenID4VP côté présentation, avec des formats d’attestation de type SD-JWT VC et mdoc (ISO/IEC 18013-5) pour les documents dérivés du permis ou de la carte d’identité. Si votre équipe raisonne encore en termes d’API REST propriétaire et de scan de document, il y a un chantier d’apprentissage avant le chantier de développement.
Accepter une attestation suppose de valider la signature de l’émetteur, de remonter à une liste de confiance publiée au niveau européen, et de vérifier le statut de révocation. Ce mécanisme doit fonctionner hors ligne autant que possible, sans rappeler l’émetteur à chaque présentation. Une architecture qui interroge l’émetteur en temps réel crée exactement le traçage que le règlement cherche à empêcher.
La divulgation sélective permet de ne révéler qu’un champ d’une attestation. Le prédicat va plus loin : au lieu de la date de naissance, vous recevez une réponse binaire à la question « cette personne a-t-elle plus de 18 ans ? ». Pour un éditeur de contenus soumis à la loi SREN, c’est la différence entre héberger une base de données d’états civils et n’héberger rien du tout. Votre modèle de données doit être conçu pour accueillir un booléen horodaté, pas une identité.
Le règlement encadre les vérificateurs : enregistrement auprès d’une autorité nationale, déclaration des attributs demandés, interdiction de solliciter davantage que ce qui a été déclaré. Concrètement, votre architecture doit rendre auditable la liste exacte des attributs demandés par chaque parcours. Un formulaire qui réclame le nom complet « au cas où » ne passera pas.
C’est le point le plus souvent sous-estimé. Le portefeuille est conçu pour que l’émetteur ne sache pas où l’attestation est présentée. Mais rien n’empêche une intégration bâclée de recréer la corrélation côté serveur : identifiants persistants dans les journaux, clés publiques réutilisées d’une session à l’autre, appels analytics enrichis. La séparation des rôles doit être une propriété de votre architecture, pas une promesse dans votre politique de confidentialité.
Une part significative de vos utilisateurs n’aura pas de portefeuille actif au moment où vous mettrez la fonctionnalité en production : téléphones incompatibles, résidents non européens, refus d’usage. Prévoir une alternative conforme n’est pas une option, c’est une condition de continuité de service. Votre parcours de vérification doit donc être multi-méthodes dès la conception, avec un socle de décision unique en aval.
En France, la loi SREN et le référentiel de l’Arcom ont posé une exigence structurante avant même l’arrivée du wallet : le double anonymat. Le vérificateur d’âge ne doit pas savoir quel site l’utilisateur consulte, et le site ne doit pas connaître l’identité de l’utilisateur. Cette architecture à tiers séparé est précisément celle que l’EUDI Wallet généralise à l’échelle européenne, avec un porteur qui devient l’intermédiaire de sa propre preuve.
C’est le principe sur lequel GreenBadg a été conçu chez IDxLAB : une preuve d’âge ou d’attribut transmise sans identité, sans base centralisée exploitable, et sans que l’émetteur puisse reconstituer l’historique de navigation. Les plateformes de contenus adultes, dont des acteurs de référence du secteur comme le groupe Dorcel, ont été les premières confrontées à cette tension entre obligation légale et protection de la vie privée. Les opérateurs d’événements et les acteurs du phygital y arrivent maintenant, avec les mêmes contraintes et une pression réglementaire montante. Notre conviction, portée depuis l’écosystème French Tech Aix-Marseille, est simple : une plateforme correctement architecturée pour le double anonymat aujourd’hui absorbera l’EUDI Wallet comme une méthode de plus, pas comme une refonte.
Les équipes qui traiteront ce sujet comme une mise en conformité de dernière minute intégreront un connecteur et conserveront leurs mauvaises habitudes de collecte. Celles qui l’abordent comme une révision de leur modèle de données sortiront avec moins de données sensibles, moins de surface d’attaque et un argument commercial. Vous pouvez échanger avec notre équipe sur idxlab.eu pour confronter votre architecture actuelle à ces exigences.
Non. Il devient une méthode supplémentaire, sans doute la plus robuste juridiquement, mais il ne couvrira pas l’ensemble de votre audience avant plusieurs années. Une plateforme sérieuse conserve plusieurs méthodes de preuve derrière un point de décision unique.
Oui. Le règlement prévoit un enregistrement des parties utilisatrices auprès d’une autorité nationale, avec déclaration des attributs demandés. Demander plus que ce qui a été déclaré vous expose à un refus du portefeuille et à un risque de sanction.
OpenID4VCI pour l’émission, OpenID4VP pour la présentation, SD-JWT VC et mdoc ISO/IEC 18013-5 pour les attestations. Ce sont les briques retenues par l’architecture de référence européenne et par la plupart des projets pilotes nationaux.
Vous devez pouvoir démontrer qu’une vérification a eu lieu, pas ce qu’elle contenait. Un identifiant technique non réversible, un horodatage et le résultat binaire suffisent dans la très grande majorité des cas. Stocker la date de naissance ou une image de document crée un risque disproportionné.
Par la séparation des rôles. Le double anonymat fait en sorte qu’aucun acteur de la chaîne ne détienne à la fois l’identité de la personne et l’usage qu’elle en fait. C’est exactement la logique du portefeuille européen, et c’est le principe de conception de GreenBadg.
