// analyse
Votre identité dans un téléphone, 8/8 : votre identité doit vous laisser un reçu
Garanties de lectureDatée, sourcée, sans tracker
Niveaux de preuveProfondeur 2 : référence · 3 niveaux détectés
Sommaire et notions16 étapes · 0 notion
Analyse complète
Une entreprise vous demande de prouver votre identité. Aujourd’hui, vous voyez rarement la liste exacte des données qu’elle s’est engagée à demander, le motif enregistré de la collecte ou le certificat qui prouve qu’elle est bien le service annoncé. Si la transaction échoue, vous repartez souvent avec un message générique et presque aucune pièce pour comprendre le refus.
Le futur portefeuille européen est conçu pour modifier ce rapport de force. Le demandeur devra s’enregistrer. Le registre devra être public et exploitable par une machine. Le portefeuille devra comparer les données réclamées avec celles déclarées. Chaque transaction, y compris celle qui échoue, devra laisser une trace contenant l’identité du service, les catégories de données demandées et la raison de l’échec.
Ces règles ne prouvent pas que le système français les exécutera parfaitement. Elles fournissent quelque chose de plus utile qu’une promesse : une liste de propriétés testables.
Dernier volet de l’enquête Votre identité dans un téléphone. Le premier suivait les données et les traces de France Identité. Le deuxième mesurait le prix pratique des alternatives. Le troisième examinait l’identité souveraine sous contrat. Le quatrième suivait la transformation de l’âge en autorisation. Le cinquième testait le jour où l’identité ne répond plus. Le sixième suivait la facture cachée derrière une preuve gratuite. Le septième mesurait la dépendance aux plateformes mobiles.
English version: Your identity should leave you a receipt.
À retenir
- À partir du 24 décembre 2026, chaque État membre doit disposer d’au moins un registre national des services utilisant le portefeuille. Les informations doivent être disponibles sur un site, en lecture humaine et via une API commune exploitable sans authentification. (Règlement d’exécution 2025/848)
- Le registre doit notamment publier l’identité du service, ses coordonnées, la nature de son activité, les données qu’il prévoit de demander et l’usage déclaré pour chacune d’elles. (Annexe I du règlement 2025/848)
- Cette inscription n’est pas une approbation administrative de la nécessité juridique de chaque donnée. Depuis la modification de juillet 2026, une partie des informations d’usage est collectée automatiquement à des fins de transparence, sans procédure d’autorisation préalable. (Règlement d’exécution 2026/1730)
- Le portefeuille doit comparer la demande reçue avec les attributs enregistrés dans le certificat du service. En cas de demande excédentaire, il doit avertir clairement l’utilisateur avant toute divulgation. (Règlement d’exécution 2026/1731)
- L’utilisateur doit approuver explicitement cette demande excédentaire. Le silence ou une case précochée ne suffisent pas. La politique du portefeuille déterminera ensuite si la demande peut continuer, être limitée ou être rejetée. (Règlement 2026/1731)
- Le portefeuille doit journaliser toutes les transactions avec les services, qu’elles réussissent ou non. (Règlement d’exécution 2024/2979)
- Le journal doit au minimum contenir la date et l’heure, le nom et l’identifiant du service, son État membre, les catégories de données demandées et présentées, ainsi que le motif d’un échec. (Article 9 du règlement 2024/2979)
- Le fournisseur du portefeuille ne peut accéder à ces journaux, lorsque cet accès est nécessaire au service, qu’avec le consentement explicite préalable de l’utilisateur. Leur intégrité, leur authenticité et leur confidentialité doivent être protégées. (Règlement 2024/2979)
- Le tableau de bord EUDI doit permettre de consulter les services contactés et, le cas échéant, les données échangées, de demander leur effacement et de signaler une demande suspecte à l’autorité de protection des données. (Règlement 2024/1183)
- Les États devront publier en format ouvert et lisible par machine des statistiques sur les wallets valides, les services qui les acceptent, les plaintes, les incidents empêchant leur usage, les violations de données et les utilisateurs affectés. (Article 48 bis du règlement 2024/1183)
- Ces obligations créent une surface d’audit remarquable. Elles ne créent pas, à elles seules, un droit automatique à indemnisation après une aide perdue, une signature refusée ou une échéance manquée.
- France Identité prépare déjà trois voies de raccordement : OIDC direct, OID4VP pour le portefeuille EUDI et un Playground d’expérimentation. (France Titres)
- France Titres revendique plus de 4,5 millions d’utilisateurs et plus de 80 signataires de son mémorandum public-privé. Ces chiffres décrivent l’écosystème actuel, pas un wallet EUDI de production déjà achevé. (France Identité, mémorandum)
- Le code mobile est toujours annoncé comme prochainement publié en open source. Le dernier audit d’accessibilité chiffré retrouvé sur le site officiel porte sur une préproduction de mai 2025 et classe les applications iOS et Android non conformes. (Sécurité, accessibilité)
Le portefeuille doit vérifier celui qui vous vérifie
Le premier renversement se produit avant même le partage d’une donnée.
Le règlement d’exécution 2025/848 impose à chaque État membre d’établir au moins un registre national des parties utilisatrices du portefeuille. Une banque, une administration, un assureur, un opérateur ou toute autre organisation voulant recevoir des preuves EUDI devra s’inscrire dans le registre de son État d’établissement.
Le registre ne doit pas être un simple fichier administratif inaccessible au public. Son contenu doit être disponible en ligne :
sur un site national lisible par une personne
et
par une API commune lisible par une machineL’API devra utiliser REST et JSON, être documentée en OpenAPI 3, permettre une recherche sans authentification et fournir des réponses signées ou scellées électroniquement. Elle devra pouvoir restituer les informations courantes ainsi que l’historique des certificats d’accès et d’enregistrement. (Annexe II du règlement 2025/848)
L’annexe I prévoit notamment la publication de :
- la dénomination officielle et le nom compréhensible du service ;
- ses identifiants légaux et son État d’établissement ;
- ses coordonnées de support ;
- le type de service fourni ;
- pour chaque usage, la liste des données, attestations ou attributs demandés ;
- une description de l’usage prévu de ces données ;
- son statut public ou privé et ses éventuelles habilitations ;
- l’intervention éventuelle d’un intermédiaire. (Règlement 2025/848)
Cette publication ne doit pas être confondue avec un blanc-seing de l’État. Le règlement 2026/1730 précise que certaines informations relatives aux contacts, au service, aux données demandées et à leur usage sont collectées automatiquement à des fins de transparence, sans autorisation préalable de leur contenu. Le registre rend la déclaration visible et opposable au fonctionnement du portefeuille. Il ne transforme pas chaque collecte déclarée en collecte nécessaire ou licite.
Le contrôle de nécessité continue de relever du droit applicable, de l’autorité compétente et, en dernier ressort, du juge.
La donnée de trop doit déclencher une alerte
Le cadre européen ne se contente pas d’authentifier le service.
Depuis le règlement d’exécution 2026/1731, le portefeuille doit comparer les attestations, attributs et champs réclamés avec ceux inscrits dans le certificat d’enregistrement du demandeur.
Si le certificat n’est pas valide, a expiré, a été révoqué, est mal formé ou ne peut pas être vérifié cryptographiquement, le portefeuille doit avertir que le service n’a pas pu être validé. La requête ne peut pas être présentée comme correctement authentifiée. L’utilisateur doit alors l’approuver explicitement ; le silence ou une case précochée ne suffisent pas. (Règlement 2026/1731, règle WRP-VALIDATION-02)
Si le service demande une donnée qui ne figure pas dans son certificat, la règle WRP-OVERASKING-02 exige un avertissement clair avant tout partage. Le message doit indiquer que le demandeur réclame davantage d’informations qu’il n’en a enregistré. L’accord doit, là encore, être explicite. (Règlement 2026/1731)
Le texte ne fixe pas une réponse unique à tous les excès. Le fournisseur du portefeuille doit décider, selon son analyse de risque, sa politique de sécurité et le droit applicable, si l’utilisateur peut continuer malgré l’alerte, si seule la partie couverte peut être transmise ou si la demande doit être rejetée. (Règle WRP-OVERASKING-03)
Cette souplesse possède une raison : toutes les différences ne sont pas nécessairement frauduleuses. Une déclaration peut être obsolète, un nouveau service peut avoir été mal enregistré ou un besoin exceptionnel peut reposer sur une autre base juridique.
Elle crée aussi une question de design décisive :
L’alerte permettra-t-elle réellement de comprendre le risque, ou deviendra-t-elle une nouvelle fenêtre que chacun valide pour continuer ?
L’enquête ne peut pas répondre avant d’avoir vu l’interface française, ses textes, le nombre de demandes excédentaires et le taux de poursuite après avertissement.
Exemple pédagogique, pas cas observé
Usage enregistré : ouverture de compte
Données enregistrées : identité, majorité, adresse
Demande réellement reçue :
identité, majorité, adresse, diplôme
Résultat attendu :
alerte avant la transmission du diplômeCet exemple illustre uniquement la comparaison prévue par les textes. Il ne prétend pas qu’une banque réelle demande un diplôme pour ouvrir un compte.
Chaque transaction doit laisser une trace
La seconde protection est moins visible, mais probablement plus importante en cas de litige.
L’article 9 du règlement d’exécution 2024/2979 impose au portefeuille de journaliser toutes les transactions avec les services et les autres wallets, qu’elles réussissent ou non. La signature et le cachet électroniques entrent également dans ce périmètre.
Le journal doit au minimum indiquer :
Date et heure
Nom et coordonnées du service
Identifiant unique du service
État membre d’établissement
Types de données demandées
Types de données présentées
Motif d’échec si la transaction n’aboutit pasLe fournisseur doit garantir l’intégrité, l’authenticité et la confidentialité de ces informations. Les signalements envoyés à une autorité de protection des données depuis le wallet doivent eux aussi être journalisés. Le fournisseur du portefeuille ne peut accéder aux journaux, lorsque cet accès est nécessaire à la fourniture du service, qu’après consentement explicite préalable de l’utilisateur. (Règlement 2024/2979)
Le règlement eIDAS modifié impose en parallèle un tableau de bord commun permettant de consulter la liste actualisée des services contactés et, lorsqu’elles existent, les données échangées. Le même tableau de bord doit offrir un moyen simple de demander l’effacement des données et de signaler une demande présumée illicite ou suspecte à l’autorité nationale de protection des données.
Le mot « reçu » utilisé dans cet article est donc une description fonctionnelle. Les textes imposent un journal et un tableau de bord. Ils ne promettent pas nécessairement un PDF signé possédant, à lui seul, une valeur probatoire prédéfinie dans chaque contentieux.
Le journal qui vous protège peut aussi vous exposer
Une liste regroupant une banque, un hôpital, une université, un employeur, une plateforme et une administration peut révéler une partie importante de la vie de son titulaire, même sans contenir le détail intégral de chaque dossier.
Ce risque découle directement des champs imposés au journal : service, date, heure, données demandées et données présentées. Il s’agit ici d’une analyse de risque l0g, pas de la preuve qu’un tel historique serait centralisé ou déjà exploité. Le règlement impose au contraire la confidentialité des journaux et limite l’accès du fournisseur au consentement explicite préalable lorsqu’il est nécessaire au service. (Règlement 2024/2979)
La mise en œuvre française devra répondre publiquement à quatre questions :
Où le journal est-il stocké ?
Qui peut le déchiffrer ?
Combien de temps est-il conservé ?
Que devient-il après perte ou remplacement du téléphone ?Le droit européen fixe un socle, mais la durée de disponibilité reste liée au droit de l’Union et au droit national. Il faudra donc connaître la politique française exacte, la méthode de chiffrement, la sauvegarde éventuelle, la migration et la procédure après compromission du terminal. (Article 9, paragraphes 3 à 6 du règlement 2024/2979)
Le meilleur système n’est pas celui qui ne garde aucune trace. Sans trace, le titulaire peut se retrouver incapable de prouver un refus ou une demande excessive. Le bon objectif est plus exigeant : une trace utile au citoyen, illisible pour les acteurs qui n’en ont pas besoin et supprimable selon une règle publique.
L’Europe crée une API publique de contrôle
Le registre prévu pour le 24 décembre 2026 pourrait devenir l’une des surfaces de transparence les plus utiles du projet.
L’API commune devra permettre à n’importe quel demandeur, sans authentification préalable, de rechercher une organisation, d’obtenir une liste complète et de consulter les informations publiques de ses certificats. Les résultats devront être signés ou scellés électroniquement et le schéma devra être publié en OpenAPI 3. (Annexe II du règlement 2025/848)
Cela permet de construire un observatoire indépendant sans collecter l’identité des utilisateurs.
Au 28 août 2026, l0g n’a pas identifié, dans les pages officielles françaises consultées, de registre national de production répondant à ce cahier des charges. Cette absence de résultat n’est pas un constat de retard : le règlement 2025/848 s’applique à partir du 24 décembre 2026. Elle définit simplement l’information qui devra être retrouvée à cette échéance.
Outil l0g : Qui demande quoi ?
L’outil ci-dessous ne consulte ni le registre français, qui n’est pas encore publié, ni aucune donnée personnelle. Il compare localement les catégories déclarées dans un certificat avec celles demandées par une transaction, vérifie les éléments d’identité du service et contrôle les champs minimaux du reçu. Ne saisissez que des noms de catégories, jamais de valeurs personnelles.
// AUDIT LOCAL DE LA DEMANDE
Qui demande quoi à votre identité ?
Comparez les catégories annoncées dans le certificat avec celles réclamées par la transaction, puis vérifiez le reçu laissé par le wallet.
Exemples pédagogiques
Les exemples ne décrivent aucun service réel. Ils montrent seulement la logique de comparaison.
Méthode, sources et limites
La comparaison est littérale après normalisation typographique. Deux synonymes peuvent être signalés à tort comme différents. Le statut « arrêt » est une règle de prudence propre à cet outil, pas une décision imposée à tous les wallets. L’outil ne valide ni la base juridique, ni la nécessité, ni l’identité réelle d’un service. Il ne faut saisir que des noms de catégories, jamais de valeurs personnelles.
- Registre public des parties utilisatrices du portefeuille source primaire
- Comparaison entre demande et certificat, alerte en cas de dépassement source primaire
- Champs minimaux du journal de transaction source primaire
- Tableau de bord, effacement et signalement source primaire
Référentiel vérifié au 2026-08-29 · modèle v1.0.0
Les incidents devront eux aussi devenir des données publiques
Le nouvel article 48 bis d’eIDAS impose aux États de collecter des statistiques sur le fonctionnement des wallets et des services de confiance qualifiés.
Le jeu minimal comprend :
- le nombre de personnes physiques et morales disposant d’un wallet valide ;
- le type et le nombre de services qui acceptent le wallet ;
- le nombre de plaintes et d’incidents de protection des consommateurs ou des données ;
- un rapport synthétique sur les incidents empêchant l’utilisation du wallet ;
- un résumé des incidents de sécurité significatifs, des violations de données et des utilisateurs affectés.
Ces statistiques devront être rendues publiques dans un format ouvert, courant et lisible par machine. Chaque État devra les transmettre à la Commission avant le 31 mars de chaque année. (Règlement 2024/1183)
Cela ne garantit ni la finesse des catégories, ni la publication rapide de chaque incident individuel, ni l’existence d’une série historique homogène dès la première année. Le format, les définitions et les dénominateurs seront décisifs.
L0g cherchera notamment à séparer :
incident de wallet
incident d’un émetteur d’attribut
incident du service demandeur
refus de terminal
refus d’identité
refus réglementaire légitime
faux refus technique
indisponibilité sans perte de droit
indisponibilité avec conséquence financièreUn nombre brut de plaintes n’a de sens qu’avec le nombre d’utilisateurs, de transactions, de services et d’échecs.
Ce que la France prépare déjà
France Titres ne part pas d’une feuille blanche.
La page destinée aux services publics et privés présente déjà trois voies : un raccordement OIDC direct à France Identité, un raccordement OID4VP permettant d’anticiper le portefeuille EUDI, et un Playground destiné aux expérimentations. (France Identité)
Le Playground public recense des wallets, des vérificateurs en ligne, des émetteurs et des outils de conformité. Il se présente explicitement comme un répertoire de tests. Sa présence démontre une activité d’interopérabilité ; elle ne prouve pas qu’un service y figurant est agréé, certifié ou utilisé en production.
France Titres revendiquait plus de 4,5 millions d’utilisateurs en juillet 2026. Son mémorandum d’entente annonçait plus de 80 signataires en mai, avec l’objectif d’aligner acteurs publics et privés sur les règles et standards européens. (France Identité, mémorandum)
Ces éléments montrent que l’écosystème se prépare. Ils ne permettent pas encore d’établir que la version actuelle de l’application remplit les exigences finales de journal, de registre, d’alerte et de tableau de bord EUDI.
Une liste européenne des wallets certifiés
Le règlement eIDAS impose également à la Commission de publier et maintenir, sous une forme lisible par machine, la liste des portefeuilles certifiés. Les États doivent transmettre notamment le certificat, le rapport d’évaluation, la description du schéma d’identité, le régime de supervision, des informations sur la responsabilité et les modalités de suspension ou de révocation. (Article 5 quinquies du règlement 2024/1183, règlement d’exécution 2025/849)
Cette liste permettra de vérifier qu’un produit portant le mot « wallet » possède bien le statut européen annoncé. Elle ne remplacera ni le rapport de certification, ni l’examen du périmètre exact, ni le suivi des versions distribuées.
Là où la preuve publique manque encore
Le registre français de production
La France devra publier le site, l’API, la politique d’enregistrement, le registrar et les autorités de certification permettant d’émettre les certificats d’accès et d’enregistrement. Le règlement 2025/848, modifié par le règlement 2026/1730, fixe ce cadre à partir du 24 décembre 2026.
L0g n’a pas identifié ces éléments de production dans le corpus officiel français examiné au 28 août. Cette formulation est bornée dans le temps et aux documents publics retrouvés.
L’interface de sur-demande
Le texte européen détaille le résultat attendu : comparaison, avertissement et consentement explicite. La mise en page française, la formulation de l’alerte, les choix autorisés et les règles de rejet restent à voir et à tester. (Règlement 2026/1731)
Le code source
Le règlement EUDI impose une licence open source aux composants applicatifs du portefeuille. La page française consacrée à la sécurité indique encore que le code source mobile sera « prochainement » publié. (Règlement 2024/1183, France Identité)
Pour rendre cette ouverture vérifiable, il faudra publier au minimum :
le dépôt et son historique
la licence
les dépendances
les instructions de compilation
la nomenclature des composants logiciels
la méthode de build reproductible
la correspondance entre code et binaires des stores
les exceptions et leur justificationL’ouverture du code ne certifie pas seule la sécurité. Elle rend possible un contrôle qui reste autrement réservé à l’administration, aux prestataires et aux évaluateurs mandatés.
L’accessibilité
Le dernier audit chiffré publié sur la page officielle a été établi le 23 mai 2025 sur des versions de préproduction. Il conclut à 35,14 % des critères RAAM applicables respectés sur iOS et 36,11 % sur Android, avec un état non conforme pour les deux applications. France Titres précise que les conditions de test pouvaient produire des écarts avec la version publique. (Déclaration d’accessibilité)
Ces chiffres ne décrivent donc pas nécessairement l’application distribuée en août 2026. Dans les pages officielles consultées pour cet article, l0g n’a pas retrouvé de nouvel audit mobile chiffré. La conclusion rigoureuse n’est pas que l’application actuelle respecte encore seulement un tiers des critères. Elle est qu’un nouveau résultat public est nécessaire pour mesurer les progrès.
Le droit est plus protecteur que le récit simpliste
Au terme de huit volets, plusieurs garanties écrites doivent être reconnues sans ambiguïté.
Le cadre EUDI impose ou prévoit :
- un usage volontaire et le maintien de moyens alternatifs ;
- la divulgation sélective ;
- la possibilité de créer des pseudonymes lorsque l’identification complète n’est pas requise ;
- l’interdiction d’informer les émetteurs de la manière dont leurs attestations sont utilisées ;
- l’authentification des services demandeurs ;
- un registre public de leurs déclarations ;
- la détection des demandes excédentaires ;
- un journal contrôlable par l’utilisateur ;
- l’effacement et le signalement depuis un tableau de bord ;
- l’ouverture du code applicatif ;
- la certification des wallets ;
- la publication de statistiques sur les plaintes et incidents. (Règlement 2024/1183, règlements 2024/2979, 2024/2981, 2025/848 et 2026/1731)
Ces propriétés sont difficiles à concilier avec l’image d’un projet juridique conçu uniquement pour centraliser et suivre les citoyens.
Elles ne suffisent pas non plus à donner un blanc-seing.
Une garantie peut échouer dans :
le code
l’interface
le certificat
le registre
le journal
le contrat
le téléphone
la procédure de récupération
le parcours alternatif
la gestion du recoursLe bon niveau de critique consiste donc à comparer chaque implémentation à la règle qui la contraint.
Le reçu ne rembourse personne
Le prisme financier réapparaît au moment du refus.
Le portefeuille pourra servir à ouvrir un compte, accéder à un service financier, signer un document, demander une aide, acheter une formation, modifier une entreprise ou autoriser une opération. Ces usages ne sont pas tous disponibles aujourd’hui dans France Identité ; ils appartiennent au périmètre déjà déployé, testé ou prévu selon les cas étudiés dans les volets précédents.
Imaginons, uniquement pour analyser la mécanique du risque, qu’une transaction de signature échoue avant une échéance contractuelle.
Le journal pourrait établir :
le service contacté
l’heure exacte
les données demandées
les données présentées
la raison technique de l’échecCette trace peut aider à démontrer que l’utilisateur a tenté d’agir et que la transaction n’a pas abouti. Elle ne décide pas automatiquement :
- si le service, le fournisseur de wallet, l’émetteur ou l’utilisateur est fautif ;
- si l’échéance doit être prorogée ;
- si la perte est directe, certaine et indemnisable ;
- quelle juridiction est compétente ;
- quel montant doit être réparé.
Le dernier risque de la chaîne n’est donc plus invisible. Il reste juridiquement fragmenté.
IDENTITÉ
↓
AUTORISATION
↓
TRANSACTION
↓
INCIDENT
↓
JOURNAL
↓
RESPONSABILITÉ
↓
RÉPARATIONL’Europe a beaucoup documenté les cinq premières cases. La France et les services utilisateurs devront rendre les deux dernières compréhensibles.
Le crash-test final l0g
La série se conclut par huit engagements de suivi.
| Principe | Test l0g | Preuve attendue |
|---|---|---|
| Volontariat | Réaliser la même démarche sans wallet | Droit réellement accessible, délai et coût publiés |
| Minimisation | Demander uniquement un seuil ou un attribut | Aucune donnée supplémentaire transmise |
| Registre | Rechercher le service avant la transaction | Déclaration publique, certifiée et historisée |
| Sur-demande | Envoyer un attribut hors certificat dans un environnement autorisé | Alerte claire avant toute divulgation |
| Traçabilité | Faire échouer une transaction de test | Journal complet avec motif d’échec |
| Effacement | Utiliser le tableau de bord | Demande traçable et réponse mesurable |
| Résilience | Révoquer ou remplacer un terminal de test | Ancienne instance bloquée, retour documenté |
| Risque financier | Simuler une échéance proche | Droit préservé, interlocuteur et recours identifiés |
Les tests destructifs devront être réalisés sur des comptes, appareils et environnements préparés à cet effet. Aucun droit réel, aucune identité d’un tiers et aucune échéance personnelle ne devront être mis en danger pour produire un article.
Méthode et limites
Cet article repose principalement sur les règlements européens 2024/1183, 2024/2979, 2024/2981, 2025/848, 2025/849, 2026/1730 et 2026/1731, ainsi que sur les pages officielles de France Identité consacrées aux raccordements, au Playground, à la sécurité, au mémorandum et à l’accessibilité. Le corpus a été consulté jusqu’au 28 août 2026.
Les obligations européennes ne sont pas toutes encore observables dans une application française de production. Le régime du registre des parties utilisatrices s’applique à partir du 24 décembre 2026. Les démonstrations du Playground sont des outils de test et ne sont jamais présentées comme des services certifiés ou des preuves de production.
L0g n’a pas accédé à une architecture interne, à un registre français non public, aux contrats de certification, à une AIPD EUDI finale, aux journaux réels d’utilisateurs ni aux réponses contradictoires des institutions. Les absences documentaires sont toujours formulées comme des éléments non retrouvés dans le corpus public, jamais comme la preuve que l’information ou la fonction n’existe pas.
Les exemples de sur-demande et d’échec financier sont explicitement pédagogiques. Ils illustrent le fonctionnement du droit et la propagation d’un risque ; ils ne décrivent aucun incident réel attribué à une entreprise déterminée.
Huit articles plus tard
France Identité et le portefeuille européen ne peuvent plus être réduits à une carte d’identité rangée dans un téléphone.
Ils forment une infrastructure reliant :
l’État qui certifie
le téléphone qui protège les clés
le prestataire qui construit
le service qui demande
le registre qui publie
le wallet qui compare
le citoyen qui autorise
le journal qui conserve la traceL’enquête a identifié de vrais risques : une documentation parfois contradictoire, des alternatives inégales, une forte chaîne de sous-traitance, une responsabilité fragmentée, des délais de récupération encore mal mesurés, des coûts économiques cachés et une dépendance aux plateformes mobiles.
Elle a aussi identifié de vrais progrès possibles : transmettre moins qu’une photocopie, prouver un âge sans donner son nom, connaître celui qui demande, détecter une collecte excédentaire, conserver la trace d’un refus et produire des statistiques publiques.
La conclusion raisonnable n’est ni la confiance automatique, ni le rejet automatique.
Le droit européen a rendu une grande partie de la promesse vérifiable. La responsabilité de la France est maintenant de publier les preuves.
Le registre devra être public. L’API devra être lisible par une machine. Les demandes devront être déclarées. Les échecs devront être journalisés. Les incidents devront être comptés.
Alors l0g les comptera.
Cet article ne constitue en aucun cas un conseil en investissement.
// historique des révisions
- publication
- révision
Les corrections substantielles suivent la politique de correction et sont consignées dans le changelog éditorial.
$ cd ..