La vérification de l’âge dans l’UE suscite des critiques sur Hacker News autour de la confiance matérielle

Le projet européen de vérification de l’âge a suscité l’attention de Hacker News après que sa spécification a intégré le matériel cryptographique natif au parcours de conformité. Cette exigence protège les justificatifs d’âge contre l’extraction ou la duplication. Mais elle soulève aussi une question plus difficile : qui contrôle l’accès lorsqu’un portefeuille open source dépend d’applications approuvées, de matériel de confiance et de systèmes d’exploitation reconnus ?

La controverse est plus précise que les affirmations selon lesquelles l’Union européenne aurait interdit Linux ou imposé Google Play Integrity partout. Aucune de ces conclusions ne découle directement de la spécification publiée. Les utilisateurs d’ordinateurs de bureau peuvent suivre un parcours inter-appareils avec un portefeuille mobile, tandis que les responsables nationaux de la mise en œuvre conservent le choix d’ajouter ou non des contrôles d’intégrité.

Pour autant, l’inquiétude n’est pas imaginaire. L’architecture actuelle est centrée sur les appareils mobiles, et les fournisseurs de justificatifs doivent rejeter les applications absentes d’une liste de conformité tenue par la Commission. Cette combinaison fait de la disponibilité du code source une seule composante de l’ouverture réelle.

Il en résulte un véritable compromis de politique publique. L’association au matériel peut empêcher que des justificatifs copiés et des clients modifiés n’affaiblissent un contrôle d’âge. Le même modèle de confiance peut exclure les versions communautaires, les systèmes Android alternatifs, les appareils anciens et les personnes ne disposant pas de smartphones compatibles.

Ce qu’exige réellement la spécification européenne de vérification de l’âge

La règle contraignante porte sur le matériel cryptographique, mais l’accès en production dépend aussi de l’approbation des applications et de la politique des fournisseurs de justificatifs.

La Commission européenne a publié la première version de son plan de vérification de l’âge en marque blanche le 14 juillet 2025. Il a été conçu comme une base réutilisable que les États membres pourraient adapter en applications nationales.

Le projet soutient l’article 28 du Digital Services Act, qui impose aux plateformes concernées de protéger les mineurs au moyen de mesures appropriées et proportionnées. La Commission présente le système comme une solution transitoire vers les portefeuilles européens d’identité numérique attendus d’ici fin 2026.

Son fonctionnement de base sépare la preuve d’âge de la divulgation d’identité. Un fournisseur autorisé vérifie l’âge d’une personne et émet une attestation numérique. Un site web demande ensuite une condition liée à l’âge, par exemple si le visiteur a plus de 18 ans.

Le site web qui s’appuie sur cette preuve reçoit le résultat d’âge demandé plutôt qu’un dossier d’identité complet. Cette conception vise à éviter d’envoyer à répétition des passeports, des informations de paiement, des images faciales ou des dates de naissance à chaque service.

Selon la spécification technique publiée, une application de vérification de l’âge « SHALL » utiliser du matériel cryptographique natif lorsque cette capacité est disponible. Parmi les exemples figurent Secure Enclave d’Apple ainsi que Trusted Execution Environment ou StrongBox d’Android.

Ces composants isolent les opérations cryptographiques du système d’exploitation principal. Une clé privée liée à un justificatif peut rester inaccessible même lorsque le stockage ordinaire de l’application est copié ou inspecté.

L’exigence n’indique pas explicitement que chaque déploiement doit utiliser Google Play Integrity ou Apple App Attest. Le stockage de clés soutenu par le matériel et l’attestation distante de plateforme sont des contrôles liés, mais ils répondent à des questions différentes.

Le stockage sécurisé demande si une clé est protégée par l’appareil. L’attestation distante peut déterminer si un serveur reconnaît l’application, le système d’exploitation, l’état de démarrage, le matériel ou le canal de distribution.

Cette distinction est devenue centrale après qu’un rapport initial a décrit les implications pour Linux et les systèmes mobiles alternatifs. Le rapport notait que des services plus stricts n’étaient pas imposés universellement par l’implémentation de référence.

La spécification établit néanmoins d’autres contrôles obligatoires. Chaque preuve d’âge est à usage unique et retirée de son lot émis après présentation. Les fournisseurs d’attestations doivent vérifier l’âge à un niveau d’assurance « substantiel » ou « élevé » avant d’émettre des justificatifs.

Les fournisseurs doivent également refuser d’émettre des attestations aux applications absentes de la liste d’applications conformes de la Commission. Un fournisseur d’application doit notifier la Commission avant de publier un portefeuille conforme, et la Commission tient la liste correspondante.

Cette couche de gouvernance compte autant que la clause matérielle. Chacun peut être en mesure d’inspecter ou de bifurquer le code, mais une bifurcation ne peut pas nécessairement obtenir des justificatifs authentiques auprès des émetteurs de production.

Le projet reste une implémentation de référence plutôt qu’un service universel achevé. Son dépôt Android indique que la démonstration est en cours de développement actif et exige un travail supplémentaire avant un déploiement en production.

Les États membres ou les autres responsables de la mise en œuvre doivent gérer le renforcement des applications, la configuration des émetteurs, le stockage sécurisé, la gestion des clés, la sécurité de l’enrôlement, la localisation et la conformité juridique. Leurs choix détermineront si les systèmes finaux utilisent une association matérielle de base ou des verdicts d’appareil bien plus stricts.

Pourquoi Hacker News s’est concentré sur l’open source sans accès ouvert

Le débat sur Hacker News porte en définitive sur la question de savoir si un code auditable suffit lorsque les institutions contrôlent toujours les justificatifs et la liste de confiance.

Le projet publie son code source sous la European Union Public Licence. Les développeurs peuvent examiner les applications de référence, les compiler localement, signaler des problèmes et proposer des changements.

Cela apporte une transparence significative. Les chercheurs peuvent examiner les parcours d’enrôlement, le stockage des justificatifs, les protocoles de présentation et les dépendances avant que les déploiements nationaux n’atteignent des millions d’utilisateurs.

Cependant, une licence open source n’impose pas à un émetteur de faire confiance à chaque binaire modifié. Cela entrerait en conflit avec l’objectif de sécurité du système, car un client modifié pourrait supprimer les contrôles d’authentification ou automatiser la présentation de justificatifs.

La Commission doit donc disposer d’un moyen de distinguer les applications acceptées des logiciels arbitraires. Sa spécification le fait au moyen de la liste des applications conformes et des règles imposées aux fournisseurs d’attestations.

Cela produit deux définitions différentes de l’ouverture.

La première est l’ouverture du code. Un développeur peut étudier, compiler et modifier l’application sans obtenir l’autorisation d’un fournisseur propriétaire.

La seconde est l’ouverture opérationnelle. Une application modifiée peut participer au véritable réseau de justificatifs sans l’approbation d’une autorité centrale ou d’un gardien de plateforme.

Le projet européen soutient clairement la première définition. Son soutien à la seconde est limité par conception, car les émetteurs reçoivent pour instruction de ne reconnaître que les applications figurant sur la liste.

Les participants au fil de discussion associé ont insisté sur cet écart. Certains considéraient les exigences matérielles comme une défense nécessaire contre la copie de justificatifs. D’autres voyaient dans cette architecture un moyen d’exclure les logiciels contrôlés par les utilisateurs.

Les deux arguments identifient des propriétés réelles de cette conception. Un émetteur ne peut pas considérer chaque client comme digne de confiance, mais un processus d’approbation peut devenir une barrière si ses règles sont opaques ou difficiles à respecter pour les développeurs indépendants.

L’architecture distingue aussi l’accès sur ordinateur de bureau de l’exécution du portefeuille. Sa documentation décrit des parcours de présentation sur un même appareil et entre appareils.

Dans un parcours sur un même appareil, le portefeuille et le site web fonctionnent sur un seul appareil. Dans un parcours entre appareils, un site web sur un ordinateur de bureau affiche une demande qu’un portefeuille mobile proche complète, généralement au moyen d’un code QR.

Cela signifie que Linux n’est pas expressément interdit. Un utilisateur de Linux peut visiter un site web restreint et présenter une preuve au moyen d’un téléphone pris en charge.

Cela n’équivaut toutefois pas à une prise en charge native du portefeuille sous Linux. Les implémentations de référence actuelles se concentrent sur Android et iOS, tandis que la spécification qualifie l’application mobile en marque blanche de principal canal de diffusion.

Une personne possédant un ordinateur portable Linux mais aucun smartphone compatible rencontre toujours un problème d’accès. Il en va de même pour un utilisateur dont le téléphone ne dispose pas du matériel sécurisé requis ou ne peut satisfaire la politique d’intégrité d’un déploiement national.

L’application de référence Android requiert le niveau d’API 29, qui correspond à Android 10. Ce seuil exclut déjà les appareils plus anciens avant tout renforcement supplémentaire nécessaire à la production.

L’accessibilité implique aussi davantage que les systèmes d’exploitation. L’enrôlement peut reposer sur une identification électronique nationale, des documents d’identité pris en charge, des fournisseurs de confiance ou d’autres sources propres à chaque pays.

Les personnes sans documents pris en charge peuvent rencontrer un obstacle avant même que la confiance matérielle ne devienne pertinente. Les réfugiés, les migrants, les visiteurs et les résidents dont les dossiers ne se rattachent pas clairement à un émetteur ont besoin d’alternatives fonctionnelles.

Ces problèmes ne prouvent pas que le système soit conçu comme un mécanisme de surveillance. Ils montrent en revanche pourquoi l’« open source » ne peut à lui seul trancher le débat sur l’accès.

Un dépôt ouvert rend l’examen possible. Il ne garantit pas une participation égale selon les appareils, les systèmes d’exploitation, le statut documentaire ou les implémentations nationales.

L’association matérielle protège les justificatifs mais déplace le contrôle

Le compromis central est une résistance accrue au vol de justificatifs en échange d’une dépendance plus forte aux fournisseurs de matériel, aux distributeurs d’applications et aux décisions institutionnelles de confiance.

Une preuve d’âge réutilisable devient précieuse dès lors que des sites web l’acceptent. Les attaquants sont alors incités à copier des justificatifs, générer de fausses attestations, automatiser les présentations ou modifier un portefeuille pour contourner l’authentification locale.

Les clés soutenues par le matériel réduisent ces risques. Le portefeuille peut demander des signatures sans exposer la clé privée à la mémoire ou au stockage ordinaires de l’application.

Cela protège contre une extraction simple. Copier les fichiers du portefeuille vers un autre appareil ne devrait pas copier l’autorité cryptographique nécessaire pour présenter le justificatif.

La spécification ajoute des attestations à usage unique afin de limiter la relecture et le suivi entre services. Les fournisseurs émettent les justificatifs par lots, et le portefeuille retire chaque attestation après l’avoir présentée.

Une durée de validité maximale recommandée de trois mois limite la période pendant laquelle un lot émis reste utilisable. Le document évite d’imposer une révocation obligatoire, car un service de révocation ajouterait de la complexité et pourrait accroître la possibilité de liaison entre les usages.

Ces choix illustrent l’ingénierie de confidentialité du projet. Un service central n’a pas besoin d’approuver chaque visite de site web, tandis que les parties qui s’appuient sur la preuve reçoivent un attribut d’âge strictement limité.

Le Comité européen de la protection des données a également publié dix principes de confidentialité pour l’assurance de l’âge. Ils mettent l’accent sur la nécessité, la proportionnalité, la minimisation des données, l’équité, l’exactitude, la sécurité et des alternatives efficaces.

La protection matérielle favorise la sécurité, mais elle ne satisfait pas automatiquement les autres principes. Un système techniquement sécurisé peut tout de même exclure des utilisateurs ou révéler davantage d’informations que ne le requiert un service donné.

La controverse s’amplifie lorsque les responsables de la mise en œuvre ajoutent des services d’intégrité à distance. Google présente Play Integrity comme un moyen d’évaluer si les requêtes proviennent d’une application reconnue exécutée dans un environnement Android authentique et certifié.

Ses niveaux d’intégrité peuvent inclure des signaux soutenus par le matériel, l’état du bootloader, la certification du système d’exploitation, les récentes mises à jour de sécurité, la reconnaissance de l’application et la source d’installation.

Ces capacités permettent de détecter les clients altérés et les appareils rootés. Elles peuvent aussi rejeter des systèmes d’exploitation alternatifs qui offrent une forte sécurité mais ne sont pas acceptés par le modèle de certification de Google.

Google recommande lui-même une application graduée des contrôles, car moins d’appareils satisfont au verdict le plus strict. Ce conseil reconnaît le problème de couverture : la réponse de sécurité la plus stricte n’est pas accessible à tous les utilisateurs légitimes.

App Attest d’Apple suit un modèle similaire, vérifié côté serveur. Il crée une clé matérielle et permet à Apple de certifier que cette clé appartient à une instance d’application valide.

Les recommandations d’Apple en matière d’attestation demandent également aux développeurs de vérifier la disponibilité du service et de gérer avec souplesse les appareils non pris en charge. Elles ne supposent pas que chaque appareil ou type d’application puisse fournir le service.

La spécification de l’UE ne regroupe actuellement pas toutes les protections matérielles dans ces deux services commerciaux. Elle cite des environnements cryptographiques natifs et laisse les décisions de renforcement supplémentaires aux responsables de la mise en œuvre.

Cette flexibilité est importante, mais elle reporte aussi la question politique décisive. Les déploiements nationaux peuvent choisir des contrôles aux conséquences différentes pour les magasins d’applications alternatifs, les systèmes d’exploitation modifiés après-vente et les portefeuilles compilés indépendamment.

Une mise en œuvre limitée pourrait lier les identifiants à une clé sécurisée sans demander à un opérateur de plateforme d’approuver l’ensemble de l’environnement logiciel. Une mise en œuvre plus stricte pourrait exiger une signature d’application reconnue, un bootloader verrouillé, un système d’exploitation certifié et un canal de distribution officiel.

Les deux mises en œuvre pourraient se présenter comme reposant sur du matériel. Leurs effets sur la concurrence et la liberté des utilisateurs différeraient toutefois fortement.

Les développeurs devraient donc éviter de considérer « l’attestation matérielle » comme une technologie indivisible. La politique de confiance réelle dépend des affirmations exigées par un vérificateur et des autorités qu’il accepte.

Un appareil peut prouver qu’une clé réside dans du matériel sécurisé sans prouver que Google a approuvé son système d’exploitation. À l’inverse, Play Integrity peut combiner des preuves matérielles avec les classifications de Google concernant l’application et l’appareil.

La question pertinente n’est pas de savoir si du matériel est impliqué. Elle est de savoir qui définit un appareil acceptable, quelles preuves sont requises et si les utilisateurs rejetés disposent d’une autre voie sécurisée.

La promesse de confidentialité se heurte encore à des faiblesses pratiques

L’architecture peut limiter la divulgation aux sites web, mais elle ne peut pas prouver que la personne détenant un identifiant adulte est celle qui consulte le contenu.

La conception de l’UE répond à une défaillance majeure des contrôles d’âge traditionnels. Un site web restreint n’a pas besoin de collecter une pièce d’identité ni de maintenir une base de données reliant les identités légales à l’activité de navigation.

Le plan en marque blanche de la Commission décrit une méthode respectueuse de la vie privée que les États membres peuvent adapter. L’identifiant doit révéler une condition d’âge plutôt que des informations personnelles sans rapport.

Cette séparation a de la valeur. De vastes collections de passeports, selfies, dates de naissance et données de paiement constituent des cibles attrayantes pour les attaquants et aggravent les conséquences d’une fuite.

Toutefois, la préservation de la vie privée ne résout pas le problème du prêt d’identifiants. Un enfant peut utiliser le téléphone d’un adulte, tandis qu’un adulte peut approuver une demande pour quelqu’un d’autre.

La spécification reconnaît que des appareils peuvent être partagés entre utilisateurs. Elle exige une authentification locale fiable, telle qu’un code PIN, un mot de passe, un schéma ou une vérification biométrique, avant de présenter une attestation.

Cela vérifie l’accès au portefeuille. Cela n’établit pas qui regarde l’écran de destination après acceptation de la preuve.

Des contrôles locaux plus stricts peuvent rendre le partage occasionnel moins pratique, mais le système ne peut pas associer en continu la consommation de contenu à la personne dont l’âge a été vérifié. Cela nécessiterait une surveillance plus intrusive.

C’est la limite fondamentale de nombreux systèmes de vérification de l’âge. Accroître le niveau d’assurance exige souvent des preuves d’identité supplémentaires, des contrôles biométriques, une analyse comportementale ou des authentifications répétées.

Chaque mesure ajoutée peut réduire les possibilités de contournement. Chacune peut aussi créer de nouveaux risques en matière de collecte de données, d’exclusion, d’accessibilité et de sécurité.

La liaison au matériel protège l’identifiant contre l’extraction, mais elle ne peut pas empêcher la remise volontaire d’un appareil déverrouillé. L’attestation d’application peut détecter un logiciel modifié, mais elle ne peut pas déterminer qui se trouve derrière l’écran.

Le mécanisme de preuve à divulgation nulle de connaissance du projet mérite également un traitement précis. Le texte normatif indique que les applications devraient mettre en œuvre le mécanisme de preuve à divulgation nulle de connaissance spécifié, tandis que les parties utilisatrices devraient en mettre en œuvre la vérification.

Le terme « devrait » est important, mais moins contraignant que « doit » dans le langage des normes. Les mises en œuvre peuvent donc différer dans leur manière d’assurer la non-corrélation et la divulgation sélective.

Une preuve à divulgation nulle de connaissance permet à une partie d’établir un fait sans révéler le secret sous-jacent. Dans ce contexte, l’objectif est de prouver une condition d’âge sans divulguer une identité ni une date de naissance exacte.

Même un système de preuve bien conçu fonctionne au sein d’un réseau plus large. Les émetteurs, applications, listes de confiance, sites web, appareils et services de plateforme produisent encore des données opérationnelles.

La confidentialité dépend de la capacité de ces composants à corréler les événements d’émission et de présentation. Elle dépend aussi des politiques de journalisation, de la précision des horodatages, des identifiants réseau, des outils d’analyse et des choix nationaux de mise en œuvre.

La spécification tente de réduire les corrélations en utilisant des attestations à usage unique et en limitant la précision des horodatages. Ces mesures méritent d’être reconnues, mais des tests indépendants doivent confirmer le comportement des déploiements complets.

L’application Android existante est explicitement une démonstration en cours de développement actif. Son dépôt avertit que les déploiements de production exigent un stockage sécurisé, une gestion des clés, un renforcement de l’application, une validation de l’inscription et un travail de gouvernance.

Une faille dans une version de démonstration n’invaliderait pas nécessairement le protocole. De même, un protocole solide ne garantirait pas que chaque application nationale le mette en œuvre de manière sûre.

Cette distinction devrait guider la couverture des futurs rapports de sécurité. Les chercheurs doivent déterminer si une faiblesse affecte la démonstration, un choix de déploiement, le protocole d’identifiants ou l’ensemble du modèle d’assurance.

La réaction de Hacker News reflète la méfiance envers les systèmes qui commencent avec un objectif limité et acquièrent ensuite des usages plus larges. La spécification actuelle se concentre sur l’accès aux services en ligne et considère plusieurs scénarios du monde physique comme hors de son champ prioritaire.

Ce champ peut évoluer par de futures décisions politiques. Les composants techniques conçus pour la preuve d’âge pourraient à terme prendre en charge d’autres attributs dans le cadre plus large de l’identité numérique européenne.

Une telle extension n’est pas établie par le présent document de vérification de l’âge. Néanmoins, la gouvernance devrait traiter la limitation des finalités avant le déploiement, car la compatibilité technique facilite la réutilisation ultérieure.

La promesse de confidentialité est donc conditionnelle plutôt que vide. La conception peut divulguer moins d’informations que les contrôles directs de documents, mais son succès dépend de la mise en œuvre, de la supervision, des alternatives et de la résistance à l’extension du champ d’application.

Ce que les développeurs et les utilisateurs devraient surveiller ensuite

Les éléments décisifs viendront des politiques nationales de confiance, des tests de sécurité indépendants et du traitement des appareils légitimes qui échouent aux contrôles d’intégrité privilégiés.

Le premier signal est la politique de conformité en production des applications. La liste de la Commission des portefeuilles acceptés déterminera si les fournisseurs indépendants disposent d’une voie réaliste pour intégrer l’écosystème.

Les développeurs ont besoin de critères publiés, de délais d’examen, de procédures de recours et de règles pour les builds reproductibles open source. Sans cela, la liste peut fonctionner comme un filtre opaque, même lorsque le code source reste public.

Un processus crédible devrait expliquer si des applications maintenues par la communauté peuvent être admissibles. Il devrait également indiquer qui assume la responsabilité des mises à jour de sécurité, de la réponse aux incidents et de la révocation des identifiants après l’acceptation d’un portefeuille.

Le deuxième signal est la manière dont les États membres mettent en œuvre la confiance dans les appareils. Le stockage de clés reposant uniquement sur le matériel entraîne des conséquences d’accès différentes de verdicts Play Integrity ou App Attest obligatoires.

Les applications nationales devraient documenter les signaux qu’elles demandent et leur réaction en cas d’échec. Un résultat d’intégrité vide ne devrait pas être automatiquement considéré comme une preuve de fraude lorsqu’un matériel non pris en charge ou un système d’exploitation alternatif peut produire le même résultat.

Les solutions de repli comptent. Une personne qui ne dispose pas d’un téléphone compatible a besoin d’une autre manière proportionnée d’établir son âge, en particulier lorsque l’accès concerne des informations légales plutôt qu’une fonctionnalité commerciale facultative.

Ces alternatives pourraient inclure des identifiants inter-appareils provenant d’un autre portefeuille de confiance, une inscription assistée, des canaux physiques pris en charge ou du matériel sécurisé indépendant des plateformes. Chaque option exige sa propre analyse des menaces.

Le troisième signal est l’évaluation indépendante du système complet. Les dépôts de référence mentionnent des mises à jour continues, un renforcement pour la production et des tests communautaires, mais la revue publique du code ne remplace pas une évaluation structurée.

Les chercheurs devraient tester l’extraction d’identifiants, la résistance aux rejouements, le clonage de portefeuilles, les abus d’émetteurs, la collusion entre vérificateurs, les scénarios d’appareils partagés, la corrélation des métadonnées, les dénis de service et les échecs d’accessibilité.

Ils devraient également publier si une découverte vise le protocole ou une mise en œuvre. Cette clarté évite qu’un bug d’application corrigeable soit présenté comme un échec cryptographique total.

À l’inverse, une démonstration sécurisée ne devrait pas servir à affirmer que le modèle politique a résolu l’assurance d’âge. Le prêt d’identifiants, l’accès aux documents, l’exclusion numérique et l’extension des finalités ne sont pas des défauts logiciels ordinaires.

Les plateformes sont également confrontées à des décisions opérationnelles. Un site web doit valider qu’une attestation provient d’un fournisseur autorisé et contient l’attribut demandé.

Il ne devrait demander que la condition d’âge minimale requise par la loi ou la politique. La collecte d’attributs supplémentaires compromettrait l’avantage déclaré du système par rapport aux fournisseurs de vérification fortement axés sur l’identité.

Les développeurs intégrant le protocole devront suivre l’évolution des spécifications, car le projet est aligné sur l’Architecture et le cadre de référence en évolution de l’identité numérique européenne. Les affirmations d’interopérabilité dépendent de ces normes mouvantes.

Ils devraient également éviter de supposer que la mise en œuvre d’un pays prédit celle d’un autre. Le plan permet des adaptations nationales concernant l’inscription, les seuils d’âge, les contrôles de sécurité, la conservation et la configuration des fournisseurs.

Pour les utilisateurs, les questions les plus claires sont pratiques. Le portefeuille national peut-il fonctionner sur leur appareil, peuvent-ils obtenir un identifiant et peuvent-ils contester un rejet erroné ?

Les utilisateurs devraient également savoir ce que reçoit le site web utilisateur, combien de temps le portefeuille conserve les attestations et si l’émission peut être liée à des présentations ultérieures. Ces explications doivent être compréhensibles sans lire une spécification de protocole.

L’argument le plus fort en faveur de l’approche de l’UE est qu’elle peut remplacer les divulgations répétées d’identité par des preuves d’âge à usage unique et strictement limitées. Les clés liées au matériel rendent ces preuves plus difficiles à copier ou à fabriquer.

L’objection la plus forte est que la sécurité peut devenir une permission. Si les identifiants de production ne fonctionnent qu’avec des logiciels approuvés sur des appareils reconnus par les fournisseurs, les utilisateurs perdent un contrôle réel malgré l’accès au code source.

C’est pourquoi la controverse sur Hacker News ne peut pas être tranchée en qualifiant le projet soit de respectueux de la vie privée, soit d’excluant. L’architecture contient des mécanismes qui soutiennent les deux résultats.

Surveillez d’abord la liste de conformité, puis les exigences nationales d’intégrité, puis les résultats indépendants issus des flux de production complets. Ensemble, ces signaux montreront si la confiance matérielle protège un identifiant privé ou devient une barrière autour de l’accès légal à Internet.

Les développeurs, les décideurs politiques et les utilisateurs devraient exiger une réponse concrète avant d’accepter un déploiement national : quelle voie sécurisée reste-t-il lorsqu’une personne légitime ne peut pas satisfaire la vérification privilégiée de l’appareil ? La réponse révélera si ce système considère les échecs de compatibilité comme des exceptions gérables ou comme des motifs d’exclusion. Ce choix, davantage que l’existence d’une Secure Enclave ou de StrongBox, déterminera si le projet européen de vérification de l’âge parvient à inspirer confiance au-delà de l’actualité des hackers.