← Tous les articles

Une identité numérique bien faite : des attestations vérifiables sans surveillance

Sur cette page

Mise à jour du 11 février 2026 : Ça n’a pas traîné. La vérification d’âge de Discord, propulsée par k-id et son partenaire faceassure, a été contournée complètement. L’outil, écrit par xyzeva et Dziurwa (avec un crédit à amplitudes pour un travail antérieur), vérifie automatiquement ton compte comme adulte sur Discord, Twitch, Kick, Snapchat et toutes les autres plateformes qui passent par k-id. Comment ? Parce que l’« estimation faciale » de k-id traite ton visage entièrement sur l’appareil et n’envoie que des métadonnées au serveur. Du coup, tu peux simplement envoyer de fausses métadonnées. Le serveur n’a aucun moyen de faire la différence. Ce n’est pas un bug. C’est la conséquence inévitable d’un théâtre de la sécurité à la place d’une vraie sécurité. Si tu vérifies l’âge sans chaîne de confiance cryptographique ancrée dans un vrai fournisseur d’identité, tu ne vérifies rien. Tu ajoutes juste une friction que les vrais utilisateurs détestent et que les contourneurs motivés balaient en un week-end. Tout ce qui suit reste valable. Lis la suite.

Je suis australien. Je vis au Royaume-Uni. Mes deux gouvernements sont aussi responsables l’un que l’autre du bazar en cours.

Le coup d’envoi, c’est l’Online Safety Act britannique, en juillet 2025. Il impose une vérification d’âge « hautement efficace » à tout site qui héberge du contenu pour adultes (un certain hub qui commence par P, un site spécialisé dans les fans, Reddit, tout le monde) avec des amendes allant jusqu’à 18 millions de £ ou 10 % du chiffre d’affaires mondial en cas de non-conformité.1 Imgur a jeté un œil aux exigences et a quitté complètement le Royaume-Uni.2 L’Online Safety Amendment Act australien a suivi en décembre 2025 : interdiction des réseaux sociaux aux moins de 16 ans, et obligation pour les plateformes de prouver qu’elles l’appliquent.3 Et ça se propage. La France a approuvé en janvier 2026 une interdiction des réseaux sociaux aux moins de 15 ans.4 L’Espagne a annoncé la sienne aujourd’hui : moins de 16 ans, avec « de vraies barrières qui fonctionnent, pas juste des cases à cocher ».5 Le Danemark devrait voter la sienne d’ici mi-2026. La Grèce rédige la sienne en ce moment. Le Digital Services Act de l’UE impose déjà des protections adaptées à l’âge dans tout le bloc.6

Toutes les grandes démocraties (sauf celle qui se prend pour la liberté) convergent vers la même conclusion : les plateformes doivent savoir quel âge ont leurs utilisateurs. Et l’instinct est bon. Il faut protéger les esprits en développement des contenus nocifs. Les données sur la santé mentale des adolescents et l’exposition sans limites aux réseaux sociaux sont accablantes, et laisser des gamins de 12 ans se déclarer majeurs en cochant une case, c’est une farce depuis vingt ans.

Mais voilà. Toutes les implémentations à ce jour reposent sur la mauvaise question. Les gouvernements demandent « comment identifier les gens ? » alors qu’ils devraient demander « comment vérifier des attestations sans identifier personne ? »

Résultat : la vérification d’âge, ça veut dire envoyer la photo de ton passeport à un service tiers en espérant qu’il ne se fasse pas pirater. Ou faire passer ton visage dans un modèle d’IA qui devine ton âge d’après ta structure osseuse, de la surveillance biométrique sous un autre nom. Avec l’approche britannique de l’Online Safety Act, l’usage des VPN a bondi de plus de 1 400 % le premier jour d’application, parce que des adultes ont jugé, très raisonnablement, qu’ils préféraient faire transiter leur trafic par l’Irlande plutôt que de confier leur permis de conduire à un site spécialisé dans les fans.

L’État devrait rester très loin de tes affaires. Mais les entreprises devraient pouvoir être sûres qu’on ne les tiendra pas pour responsables quand le contrôle d’âge est contourné. Un ado de 14 ans avec une barbe fournie pourrait bien battre l’estimation faciale d’aujourd’hui. Une carte bancaire empruntée bat le contrôle par paiement. Un VPN bat entièrement le géoblocage.

Alors voyons ça : peut-on réparer ce foutoir ?

Oui.

Tu utilises déjà l’essentiel de cette technologie

C’est ce qui rend toute cette histoire si exaspérante : les briques d’une vérification d’identité qui respecte la vie privée ne sont pas un projet de recherche lointain. Elles tournent sur ton téléphone en ce moment même… pendant que tu lis ça.

Chaque fois que tu te connectes à un site et qu’il se souvient de toi sans te redemander ton mot de passe, il y a de bonnes chances qu’un JSON Web Token (JWT) fasse le gros du travail.7 Un JWT, c’est juste un bloc d’informations signé. Il a trois parties : un en-tête qui dit comment il a été fabriqué (signé), une charge utile pleine d’« attestations » (qui tu es et quel genre de sac à viande tu es), et une signature qui prouve que le tout n’a pas été modifié.

Voici à quoi ressemble la charge utile d’un JWT typique quand tu te connectes, disons, à ta banque :

{
  "sub": "user_38291",
  "name": "Will Hackett",
  "email": "will@example.com",
  "iat": 1706918400
}

Tu vois ce champ sub ? C’est un identifiant unique. C’est comme ça que la banque sait que c’est toi. Et c’est normal pour une banque, elle a l’obligation légale de savoir qui tu es. Mais regarde ce que fait chaque système de vérification d’âge : il reprend ce même modèle et y fourre toute ton identité juste pour répondre à la question « cette personne est-elle assez âgée ? »

C’est comme demander son passeport à quelqu’un parce que tu veux savoir s’il préfère le thé ou le café.

Et si le jeton ressemblait plutôt à ça ?

{
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "iat": 1706918400
}

Pas de sub. Pas de nom. Pas d’e-mail. Pas de date de naissance. Juste les réponses aux questions qui comptent vraiment, signées par quelqu’un en qui tu as confiance. Le service demande « as-tu plus de 18 ans ? » et reçoit un true cryptographique. Il n’apprend jamais ton nom, ton anniversaire, ton adresse, ni le fait que tu es un Australien de 30 et quelques années installé à Londres qui continue à manger du fromage malgré ce que ça lui fait.

Voilà tout le concept. Le reste de cet article, c’est comment le rendre réel.

Comment les signatures fonctionnent vraiment (sans diplôme de maths)

Un jeton signé ne sert à rien si tu ne peux pas vérifier qui l’a signé. C’est là qu’interviennent les JSON Web Key Sets (JWKS).8 Un nom pompeux pour une idée simple : le signataire publie sa clé publique à une URL, et quiconque reçoit un jeton signé peut le vérifier avec cette clé.

{
  "keys": [{
    "kty": "EC",
    "kid": "uk-gov-age-verification-2026",
    "use": "sig",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
  }]
}

Imagine que le gouvernement britannique publie ça à gov.uk/.well-known/jwks.json. Maintenant, quand un site spécialisé dans les fans reçoit un jeton de vérification d’âge qui affirme que tu as plus de 18 ans, il n’a pas à te croire sur parole. Il n’a pas à appeler le gouvernement. Il récupère la clé publique, vérifie la signature, et soit les maths marchent, soit elles ne marchent pas. Pas d’appel à la maison. Pas d’appel d’API. Pas de « je vérifie juste auprès de HMRC (le fisc) ». La clé publique est publique. La signature, c’est des maths. Terminé.

C’est déjà comme ça que fonctionne chaque connexion OAuth. Quand tu cliques sur « Se connecter avec Google », le site ne demande pas à Google si ton jeton est légitime : il récupère le JWKS publié par Google et vérifie la signature en local.

On fait ça depuis plus de dix ans. L’infrastructure est là, littéralement, et elle s’ennuie.

Doucement, petit impatient… on va y venir, à la vie privée, dans une minute.

Et si on ne montrait qu’une partie du jeton ?

Les JWT classiques ont un défaut : la signature couvre toute la charge utile. Tu ne peux pas retirer les champs que tu ne veux pas partager sans casser la signature. Si le gouvernement signe un jeton qui contient tes tranches d’âge, le hash de ton nom et ton gabarit biométrique, tu dois présenter le tout ou rien.

Voici les Selective Disclosure JWT (SD-JWT).9 Le principe est d’une simplicité grandiose. L’émetteur signe l’attestation complète, mais chaque champ reçoit sa propre divulgation. Le titulaire, c’est-à-dire toi, sur ton téléphone, choisit quels champs révéler. Les autres restent cachés, et la signature se vérifie quand même.

Le gouvernement t’émet donc ceci :

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_13": true,
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "name_hash": "sha256:a1b2c3d4...",
  "biometric_template": "...",
  "nationality": "AU"
}

Mais quand le site spécialisé dans les fans demande une vérification d’âge, ton appareil ne présente que ça :

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_18": true
}

La signature est toujours valide. Le site obtient sa réponse. Et il n’apprend jamais ton nom, ta nationalité, ni le fait franchement gênant que tu n’as pas encore 21 ans dans une juridiction qui s’en soucie encore.

Les Verifiable Credentials du W3C vont encore plus loin avec des preuves à divulgation nulle de connaissance, des méthodes cryptographiques qui te permettent de prouver qu’une affirmation est vraie sans révéler la moindre donnée sous-jacente.10 « Cette personne a-t-elle plus de 18 ans ? » cesse d’être une divulgation de données et devient une preuve mathématique. Le site ne reçoit pas "over_18": true. Il reçoit une preuve que l’affirmation est vraie, sans aucune donnée attachée.

C’est comme un videur qui arriverait à vérifier ton âge en regardant une enveloppe scellée sans l’ouvrir. Les cryptographes sont des gens bizarres et merveilleux.

Comment ça devrait marcher sur ton téléphone

Bon, assemblons le tout. Je te promets que c’est moins compliqué que le processus actuel, où tu envoies un selfie avec ton passeport à un service de vérification tiers qui sera peut-être racheté l’an prochain par une société dont tu n’as jamais entendu parler.

Étape 1 : obtiens ton attestation (une seule fois). Ton appareil fournit un cadre pour gérer les attestations vérifiables. Tu t’authentifies une fois auprès du fournisseur d’identité de ton gouvernement, sur l’appareil. En Estonie, c’est ton eID. Dans l’UE, d’ici fin 2026, ce sera ton portefeuille EUDI.11 Au Royaume-Uni, ça pourrait être GOV.UK One Login ou ce qui finira par le remplacer. Le fournisseur d’identité du gouvernement émet une attestation vérifiable vers ton appareil (tranches d’âge, hash du nom, gabarit biométrique), signée par la clé du gouvernement et vérifiable avec son point d’accès JWKS publié.

Elle vit dans l’enclave sécurisée de ton appareil. Tu fais ça une fois. Ensuite, tu oublies.

Étape 2 : la plateforme l’enveloppe. Ton fournisseur de plateforme (Apple, Google) joue le rôle d’émetteur intermédiaire. Il prend l’attestation signée par le gouvernement et la réémet avec une double signature : celle d’origine du gouvernement, plus celle de la plateforme. Un service vérificateur peut alors confirmer deux choses : l’attestation vient bien d’un vrai fournisseur d’identité gouvernemental, et elle est présentée via une plateforme légitime. Point crucial, ni le gouvernement ni la plateforme n’apprennent à quel service tu la présentes. Le gouvernement voit « Apple a demandé une attestation ». Apple voit « une attestation a été stockée ».

Aucun des deux ne voit « Will essaie d’accéder à un site spécialisé dans les fans à 2 h du matin un mardi ». Ce qui est important. Pas pour moi, personnellement… mais en général.

Étape 3 : réponds à des questions, pas à des demandes de données. Quand un service doit vérifier une attestation, l’échange ressemble à ça :

Fans specialist → Your device: "Is this user over 18?"
Your device → Secure Enclave: [biometric check, signature generation]
Your device → Fans specialist: { "over_18": true, "sig": "..." }

Ici, « Fans specialist » désigne… le service auquel tu essaies d’accéder…

Le service pose une question. Ton appareil y répond. Le service reçoit un oui ou non cryptographique. Rien de plus. Pas « quelle est ta date de naissance ? » mais « as-tu plus de 18 ans ? ». Pas « quel est ton nom ? » mais « ce hash SHA-256 correspond-il ? ». Pas « montre-moi ton visage » mais « le contrôle biométrique sur l’appareil est-il réussi ? »

Pour vérifier un nom, un service soumet un hash (SHA-256 du prénom, du deuxième prénom et du nom) et l’attestation indique s’il correspond. Le service ne voit jamais ton vrai nom. Pour vérifier une photo, l’attestation contient un gabarit biométrique (une représentation mathématique, pas une photo). Le contrôle s’exécute en local sur ton appareil. Le résultat, correspondance ou non, est signé et renvoyé. Les données biométriques ne quittent jamais ton appareil. Jamais.

L’Estonie a réussi l’architecture. Dommage pour le périmètre.

J’ai déjà écrit sur le système d’identité numérique estonien.12 Ils font tourner des eID nationaux depuis 2002, avec X-Road comme colonne vertébrale d’interopérabilité reliant plus de 450 organisations.13 Chaque citoyen de plus de 15 ans a une identité numérique. 99 % des services publics sont en ligne. Le système économiserait environ 2 % du PIB chaque année.14 C’est franchement impressionnant. Si tu veux te sentir mal pour GOV.UK, passe un après-midi à lire comment les Estoniens déclarent leurs impôts.

Mais le système estonien est un écosystème fermé. Il marche à merveille pour les services estoniens (administration, banque, santé, impôts) parce que toute la pile est estonienne. Tu ne peux pas utiliser ton eID estonien pour vérifier ton âge sur Instagram, et Instagram n’a absolument aucune raison d’intégrer X-Road pour un pays de 1,3 million d’habitants. Normal.

Le portefeuille d’identité numérique de l’UE, imposé par eIDAS 2.0 pour un déploiement d’ici fin 2026, est conçu pour combler ce fossé.15 Chaque État membre doit fournir au moins un portefeuille EUDI. Les très grandes plateformes en ligne doivent l’accepter pour l’authentification forte. Le portefeuille utilise des attestations vérifiables du W3C, avec divulgation sélective intégrée.16 C’est plus proche du bon modèle. Mais il le présente encore comme un outil d’identité plutôt que comme un outil d’attestations. Le basculement à opérer, c’est de « prouve qui tu es » vers « réponds à cette question précise ». La nuance est mince, mais c’est tout l’enjeu.

Apple et Google sont à 90 % du chemin

Ce n’est pas qu’un problème de gouvernements. Les fournisseurs de plateformes doivent construire la couche d’intégration, et la bonne nouvelle, c’est qu’ils en ont déjà presque accidentellement construit l’essentiel.

Apple gère la Secure Enclave, un processeur isolé au niveau matériel, conçu spécifiquement pour les opérations cryptographiques et les données biométriques.17 Les passkeys, bâties sur le standard FIDO2/WebAuthn, utilisent déjà exactement cette infrastructure pour l’authentification sans mot de passe.18 La clé privée ne quitte jamais l’appareil. La vérification biométrique se fait en local. Le serveur ne voit qu’une preuve cryptographique. Ça te rappelle quelque chose ? C’est le même schéma.

Étendre ça aux attestations vérifiables est simple sur le plan architectural. Apple fournit un cadre. Tu t’authentifies auprès du fournisseur d’identité de ton gouvernement via ce cadre. L’attestation est stockée dans la Secure Enclave, à côté de tes passkeys. Quand un service demande une attestation, le déroulé est identique à une authentification par passkey : contrôle biométrique sur l’appareil, preuve cryptographique envoyée au serveur. Le service sait que l’attestation est valide. Il ne sait pas qui tu es. Android a des capacités équivalentes avec StrongBox et le Trusted Execution Environment.

Les éditeurs de navigateurs doivent étendre WebAuthn ou créer un standard parallèle pour la vérification d’attestations. Un site web devrait pouvoir demander une attestation vérifiée aussi facilement qu’il demande une passkey. Même modèle d’API. Même UX. Même modèle de sécurité. La plomberie existe. Il manque juste quelqu’un pour la brancher. Vu qu’Apple, Google et la FIDO Alliance ont déjà prouvé qu’ils savaient se coordonner sur les passkeys, ce qui était en soi un petit miracle de coopération entre entreprises, ce n’est pas aussi tiré par les cheveux que ça en a l’air.

Ce que personne n’a le droit de voir

Soyons précis sur les garanties de vie privée, parce que c’est là que la plupart des propositions d’identité numérique s’effondrent et que les gens se mettent, à juste titre, à marmonner sur les États de surveillance.

Ton gouvernement n’apprend jamais quels services tu utilises. Le fournisseur de plateforme relaie les requêtes vers le fournisseur d’identité du gouvernement avec ses propres clés. Le gouvernement voit « Apple a demandé une attestation ». Il ne voit pas « Will a visité un site spécialisé dans les fans ». Ça compte.

Les services ne voient jamais tes données. Ils reçoivent des réponses cryptographiques à des questions précises. Pas ton nom. Pas ta date de naissance. Pas ta photo. Un oui ou un non signé, issu d’une chaîne d’émetteurs de confiance. C’est tout.

Aucun identifiant unique par défaut. L’attestation contient des déclarations, pas des identifiants. Il n’y a pas d’ID utilisateur que les services pourraient recouper d’une plateforme à l’autre. Tu es un ensemble de faits vérifiés, pas une entité traçable. Tu peux prouver que tu as plus de 18 ans sur cinquante sites différents sans qu’aucun puisse savoir que c’est la même personne. Essaie donc avec un envoi de passeport.

Pour les services qui ont réellement besoin de t’identifier (banque, forces de l’ordre, secteurs régulés), le système prévoit une classe spéciale d’attestation avec un identifiant délivré par le gouvernement. Mais cet identifiant ne peut être déréférencé que si le fournisseur de plateforme et le gouvernement coopèrent, via un mécanisme de partage de clé qui exige les deux parties. Une seule clé ne sert à rien. La surveillance de masse devient structurellement impossible, tout en gardant une identification légitime pour les cas régulés. C’est l’équivalent cryptographique des deux clés qu’il faut pour lancer un missile nucléaire, sauf qu’au lieu de finir le monde, tu vérifies l’identité de quelqu’un pour une demande de prêt immobilier. Beaucoup moins dramatique. Les mêmes maths.

Tout se passe sur l’appareil. Les clés de vérification ne quittent jamais l’enclave sécurisée. Aucun serveur central ne traite tes données biométriques. Aucun service cloud ne voit tes attestations gouvernementales. La preuve est générée en local et transmise au service. Rien d’autre ne circule.

Ce qui doit se passer

La technologie est prête. Les standards existent. Le matériel est déployé sur des milliards d’appareils. Ce qui manque, c’est la volonté de se coordonner, ce qui, vu qu’on parle de gouvernements, de fournisseurs de plateformes et d’organismes de normalisation, devrait seulement prendre… soyons optimistes et disons cinq ans… ou cent au Royaume-Uni.

Les gouvernements doivent publier les clés de leurs fournisseurs d’identité et émettre des attestations vérifiables qui supportent la divulgation sélective. L’Estonie a déjà fait le plus dur. L’UE impose des portefeuilles d’ici 2026. Le Royaume-Uni explore l’identité numérique. L’Australie, elle… disons que l’Australie cherche comment empêcher des gamins de 14 ans de créer des comptes TikTok, ce qui gagnerait sans doute à passer par un vrai système de vérification d’âge plutôt qu’à menacer les plateformes d’amendes. Les engagements d’infrastructure sont en route. Quelqu’un doit juste les faire se parler.

Les fournisseurs de plateformes doivent construire la couche d’infrastructure : gestion des attestations sur l’appareil, émission par procuration, intégration de l’enclave sécurisée pour la vérification. Apple et Google sont à 90 % avec les passkeys. Les 10 % restants consistent à étendre la même architecture aux attestations vérifiables. Comme les deux entreprises adoreraient être les gardiennes de ton identité numérique (et facturer une modeste redevance pour ce privilège), je suppose que l’incitation économique existe.

Les éditeurs de navigateurs doivent étendre WebAuthn ou créer un standard parallèle pour la vérification d’attestations. Un site web devrait pouvoir demander une attestation vérifiée aussi facilement qu’il demande une authentification par passkey. Même modèle d’API. Même UX. Même modèle de sécurité.

Et les services doivent arrêter de demander des documents et commencer à poser des questions. « Cet utilisateur a-t-il plus de 16 ans ? » est une question fermée. Elle ne devrait pas exiger un passeport. Elle ne devrait pas exiger un selfie. Elle ne devrait pas exiger l’envoi d’une photo de ton permis de conduire à une société dont le siège est dans une juridiction que tu ne sais pas épeler. Il lui faut un seul booléen signé, vérifié avec une clé publique publiée.

On a passé vingt ans à construire des systèmes d’identité qui traitent la surveillance comme une fonctionnalité. Il est temps d’en construire un qui fait de la vie privée son architecture.

La prochaine fois qu’on te demandera d’envoyer ton passeport pour prouver que tu es assez grand pour regarder des mèmes, souviens-toi : la technologie pour le faire correctement existe déjà. Elle a fait ses preuves pendant dix ans. Elle tourne sur ton téléphone en ce moment. Ce qui nous bloque, c’est la même chose qui bloque la plupart des bonnes idées en tech : réussir à mettre d’accord sur un standard trois groupes de gens qui ne s’apprécient pas particulièrement.

Donc, en gros, d’un jour à l’autre…


Footnotes

  1. UK Online Safety Act 2023 ↩

  2. The Register: Imgur exits the UK as parent company faces fine, tous les utilisateurs britanniques géobloqués à partir du 30 septembre 2025 plutôt que de se plier aux exigences de vérification d’âge de l’Online Safety Act ↩

  3. Australian Government eSafety Commissioner: Social Media Age Restrictions ↩

  4. Al Jazeera: French MPs approve law seeking ban on social media for children below 15, approuvée en janvier 2026 par 116 voix contre 23 ↩

  5. Euronews: Spain to ban social media platforms for children under 16, annoncé le 3 février 2026 au World Government Summit ↩

  6. European Commission: The Digital Services Act ↩

  7. IETF RFC 7519: JSON Web Token (JWT) ↩

  8. IETF RFC 7517: JSON Web Key (JWK) ↩

  9. IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC) ↩

  10. W3C: Verifiable Credentials Data Model v2.0 ↩

  11. European Commission: European Digital Identity, impose des portefeuilles EUDI à tous les États membres d’ici fin 2026 ↩

  12. Will Hackett: Reclaiming the commons: the case for an accountable internet ↩

  13. e-Estonia: X-Road interoperability platform, relie plus de 450 organisations par un échange de données open source et décentralisé ↩

  14. University of Liverpool: As the UK plans to introduce digital IDs, what can it learn from pioneer Estonia? ↩

  15. eIDAS 2.0 Regulation (EU) 2024/1183, entré en vigueur en mai 2024, portefeuilles attendus d’ici fin 2026 ↩

  16. W3C: Verifiable Credentials Implementation Guidelines, Selective Disclosure and Zero-Knowledge Proofs ↩

  17. Apple: About the security of passkeys, les passkeys utilisent la Secure Enclave pour la génération des clés et la vérification biométrique ↩

  18. FIDO Alliance: Passkeys, standard FIDO2/WebAuthn pour l’authentification sans mot de passe ↩