// analyse
Euro numérique, 3/6 : privé comme du cash ?
Garanties de lectureDatée, sourcée, sans tracker
Niveaux de preuveProfondeur 3 : source liée · 4 niveaux détectés
Sommaire et notions16 étapes · 2 notions
Analyse complète
Ce texte constitue le troisième volet de notre enquête en six parties sur l’euro numérique. Le premier article suivait la monnaie d’un bilan à l’autre. Le deuxième reconstruisait les 699 milliards d’euros de sorties de dépôts du stress test de la BCE. Ce troisième volet quitte les bilans pour suivre une autre matière : les données.
État du dossier au 14 août 2026. Le règlement final n’est pas adopté. Le projet de rulebook v0.91 publié le 2 juillet 2026 est préliminaire, non contraignant et incomplet, notamment pour le hors ligne. La documentation du pilote 2027 est distincte. Les propriétés décrites ci-dessous correspondent donc à l’architecture actuellement proposée et ne décrivent pas un produit définitif.
Vous payez un café en euros numériques.
Votre banque sait qui vous êtes. Elle a ouvert le compte, vérifié votre identité et authentifié le paiement.
Le commerçant connaît le produit vendu. Son prestataire connaît le montant, le terminal et le compte à créditer.
La plateforme centrale doit vérifier le solde, enregistrer le transfert et renvoyer un statut. Un service d’alias peut avoir résolu un numéro de téléphone. Un autre composant peut calculer un score de fraude à partir de références techniques, du contexte de transaction et, dans le projet actuel, d’une plage d’adresse IP.
La BCE affirme pourtant qu’elle ne pourra pas relier directement le paiement à votre identité.
Ces phrases peuvent être vraies en même temps.
Le système n’est pas conçu pour supprimer toutes les données. Il est conçu pour les séparer : l’identité chez le prestataire de paiement, le compte et le règlement dans l’infrastructure centrale, les valeurs substitutives chez SEPI, les signaux transversaux dans le mécanisme antifraude.
La vraie question n’est donc pas de savoir si une donnée existe.
Elle est de savoir qui peut la rapprocher des autres.
À retenir en huit lignes
- Le mode en ligne reposerait sur un compte individuel et n’offrirait pas l’anonymat d’un billet numérique.
- Le PSP connaîtrait l’identité de son propre client et conserverait les informations nécessaires au paiement, à l’AML, à la fraude et aux litiges.
- L’Eurosystème traiterait des identifiants et transactions pseudonymisés, sans recevoir normalement le nom civil.
- Pseudonymisé ne signifie pas anonyme : une information supplémentaire permet de retrouver la personne.
- Le service d’alias relierait actuellement un numéro de téléphone à un compte numérique et au PSP compétent.
- Le mécanisme central antifraude chercherait des anomalies entre plusieurs PSP et traiterait des métadonnées techniques.
- Le corpus public documente le commerçant, sa catégorie et le montant. Il n’établit aucune collecte générale du détail de chaque article acheté.
- Le mode hors ligne pourrait offrir une confidentialité réellement proche du cash pour le détail du paiement, mais son implémentation finale reste à construire et à auditer.
Privé vis-à-vis de qui ?
Le mot « privé » devient presque inutile lorsqu’on ne précise pas l’acteur concerné.
Une transaction peut être :
- privée vis-à-vis de la BCE ;
- identifiable par la banque du payeur ;
- visible par le commerçant ;
- analysée sous pseudonyme par un moteur antifraude ;
- accessible à une autorité dans une enquête ciblée ;
- inconnue des annonceurs ;
- enregistrée localement sur le téléphone.
Ces situations ne se contredisent pas.
La page consacrée à la confidentialité emploie une formulation précise : l’Eurosystème ne pourrait pas relier directement l’utilisateur à ses paiements en ligne. Les données reçues par la BCE seraient pseudonymisées. Le PSP, lui, accéderait aux informations nécessaires pour appliquer le droit européen, notamment les règles de lutte contre le blanchiment et le financement du terrorisme.
Le mot « directement » porte une grande partie de la promesse.
Il signifie que le système central ne devrait pas lire une ligne telle que :
Olivier Laurelli, 4,20 euros, café X, 8 h 42.
Il ne signifie pas que le système ne reçoitrait ni montant, ni horaire, ni référence, ni identifiant de compte, ni identifiant de PSP.
Le mandat du Conseil autorise même explicitement les banques centrales et certains services de soutien à traiter, selon leurs fonctions, un identifiant de compte numérique, le montant d’une transaction en ligne et une plage d’adresse IP de la session. Il leur impose simultanément de ne pas pouvoir attribuer ces données à une personne, y compris en les croisant avec les autres informations qu’ils détiennent.
L’architecture ne repose donc pas sur une cécité générale.
Elle repose sur une interdiction et une impossibilité technique de franchir la dernière étape vers l’identité.
Quatre mots que le débat mélange constamment
Avant de suivre un paiement, il faut distinguer quatre protections très différentes.
Pour replacer ces protections dans l’architecture monétaire, notre guide de lecture d’une CBDC passe en revue l’émetteur, le registre, l’accès, les plafonds et la confidentialité.
Anonymiser
L’anonymisation rompt raisonnablement le lien avec une personne.
Une statistique correctement agrégée peut être anonyme. Un numéro de compte stable dont une banque conserve la table de correspondance ne l’est pas.
Pseudonymiser
La pseudonymisation remplace ou sépare l’identité. Une information supplémentaire permet de réattribuer la donnée.
Le RGPD continue donc de s’appliquer.
Le projet de rulebook décrit précisément l’alias comme un identifiant pseudonyme qui ne peut être attribué à une personne que par le PSP distributeur ou par l’utilisateur. Le principe vaut plus largement pour les comptes et identifiants techniques envoyés vers l’infrastructure centrale.
Tokeniser
La tokenisation remplace une information par une valeur substitutive pour un usage déterminé.
Le service SEPI peut générer un token de QR code, de lien de paiement ou de NFC. Un PSP autorisé doit toutefois pouvoir demander la donnée sous-jacente afin de poursuivre le paiement.
Le token masque la donnée tout en conservant une correspondance réversible.
Chiffrer
Le chiffrement rend un contenu illisible sans la clé.
Le service de règlement peut transporter entre PSP des objets chiffrés qu’il n’a pas besoin de lire entièrement. L’existence d’un contenu chiffré n’efface pas les métadonnées nécessaires au routage, à l’horodatage ou au statut.
La transaction après séparation de l’identité
Le projet de rulebook v0.91 présente plusieurs domaines.
Le PSP gère la relation client. La Digital Euro Service Platform, ou DESP, regroupe notamment :
- la gestion des accès et des comptes ;
- l’annuaire d’alias ;
- le règlement ;
- SEPI ;
- le risque et la fraude ;
- les litiges ;
- l’échange de données ;
- le service hors ligne.
Le document de gestion des données décrit un modèle simplifié. Il précise qu’il ne représente ni la totalité du système, ni la manière dont chaque information sera stockée.
Cette limite est importante.
Une donnée présente dans le modèle n’est pas nécessairement visible par tous les acteurs. Une donnée absente du diagramme peut déjà exister dans les systèmes du PSP.
La carte suivante décrit un paiement en ligne typique, sans prétendre que chaque champ suit le même parcours dans tous les cas.
Le périmètre de données du PSP
Le PSP est la partie la moins mystérieuse du dispositif.
Il ouvre le compte, vérifie l’identité et attribue ou demande les identifiants nécessaires. Il peut gérer :
- le DEAN, le numéro de compte propre à l’euro numérique ;
- l’alias éventuel ;
- le compte bancaire lié ;
- les paramètres de waterfall ;
- les instruments et appareils ;
- l’historique ;
- les remboursements ;
- les litiges ;
- les alertes de fraude.
La FAQ de la BCE le dit clairement : pour les transactions en ligne, les PSP pourraient identifier les utilisateurs afin d’appliquer les règles AML.
La confidentialité vis-à-vis de l’Eurosystème ne rend donc pas le paiement invisible à la banque.
Elle tente d’empêcher que l’infrastructure publique reçoive la dernière table de correspondance entre compte technique et identité civile.
Les données nécessaires au règlement central
Le service de règlement ne peut pas fonctionner sans données transactionnelles.
Il doit :
- vérifier qu’un montant peut être transféré ;
- débiter et créditer les inscriptions techniques ;
- gérer le funding ou le defunding lorsque le plafond intervient ;
- garantir que tout se produit atomiquement ;
- renvoyer un statut ;
- permettre de retrouver une transaction en cas d’erreur ou de litige.
Le projet utilise notamment une UETR, une référence unique de bout en bout, ainsi qu’un horodatage d’acceptation.
Le projet de spécification de règlement indique que le DESP assemble les éléments envoyés par les PSP et ne transmet à chaque partie que les informations nécessaires.
Certains objets peuvent être chiffrés lorsqu’ils doivent seulement traverser le DESP pour atteindre l’autre PSP.
D’autres éléments restent nécessaires à la plateforme :
- UETR ;
- heure ;
- identifiants de PSP ;
- comptes ou inscriptions techniques ;
- montant ;
- statut ;
- présence éventuelle d’un funding, d’un defunding, d’un remboursement ou d’une réservation.
Une référence capable de retrouver une opération n’est pas une identité.
Elle devient un quasi-identifiant lorsqu’elle peut être rapprochée d’une autre source.
Le numéro de téléphone devient une adresse monétaire
Le projet autorise un paiement à partir d’un DEAN ou d’un alias plus simple.
Dans le draft actuel du service d’alias, le seul type supplémentaire prévu est le numéro de téléphone mobile.
Le service doit pouvoir répondre à deux questions :
- quel DEAN correspond à ce numéro ?
- quel PSP peut recevoir la demande ?
Le numéro ne doit pas nécessairement être révélé à l’Eurosystème comme identité civile. Il reste pourtant une donnée très proche de la personne dans la vie courante.
L’annuaire crée donc une infrastructure sensible :
téléphone → DEAN → PSP.
Cette commodité ouvre des questions classiques :
- une requête permet-elle de savoir qu’un numéro utilise l’euro numérique ?
- un attaquant peut-il tester des millions de numéros ?
- les recherches infructueuses sont-elles journalisées ?
- que se passe-t-il après un changement de numéro ?
- comment résister au SIM swap ?
- combien de temps l’ancien alias reste-t-il conservé ?
- qui peut administrer la table ?
Le rulebook décrit les appels API.
Il ne publie pas encore toutes les réponses opérationnelles à ces questions.
Le périmètre de protection de SEPI
Le service Secure Exchange of Payment Information, ou SEPI, intervient notamment dans les QR codes, les liens de paiement et le NFC.
Son rôle consiste à générer des valeurs substitutives et à valider des cryptogrammes.
Pour le NFC, SEPI produit lors de l’enrôlement une valeur substitutive et des clés de session. À chaque transaction, le terminal génère un cryptogramme à partir de métadonnées et d’une clé. Le PSP envoie ensuite le cryptogramme, le token et les données nécessaires au service, qui recalcule le résultat pour vérifier l’authenticité.
Pour le QR ou le lien de paiement, le token réduit la quantité d’information directement exposée et peut être spécifique à la transaction.
Le marché public SEPI prévoit aussi la détokenisation : un PSP autorisé peut obtenir les données associées à la valeur substitutive.
Les questions déterminantes deviennent :
- qui possède les clés ?
- le prestataire qui exploite SEPI voit-il les données sous-jacentes ?
- les tokens sont-ils toujours uniques ?
- combien de temps vivent-ils ?
- les journaux de tokenisation peuvent-ils relier plusieurs paiements ?
- qui peut demander la détokenisation ?
SEPI améliore la confidentialité du transport.
Sa sécurité dépend de la séparation entre la valeur visible et la table qui permet de l’ouvrir.
Le profil technique produit par le moteur antifraude
Le mécanisme central de risque et fraude constitue le point le plus sensible du mode en ligne.
Le marché publié par la BCE lui assigne deux fonctions.
Avant le règlement, il doit calculer un score en temps réel à partir des détails fournis par le PSP.
Après le règlement, il doit rechercher des schémas de fraude à partir d’une vue transversale des transactions entre PSP, recevoir des statistiques, conserver certaines informations liées aux scores et produire des rapports de situation.
La logique est compréhensible.
Un fraudeur peut déplacer des fonds entre plusieurs banques. Chaque PSP ne voit qu’un fragment. Un système transversal détecte des motifs qu’aucun intermédiaire isolé ne peut observer.
La même propriété crée le risque de concentration.
Le draft Risk and Fraud Management montre que le score central se trouve sur le chemin critique des paiements P2P et e-commerce. Le PSP doit recevoir le résultat avant de finaliser sa décision. Pour certains paiements en magasin, il peut continuer sans attendre afin de ne pas dépasser la latence permise.
La version publique mentionne notamment :
- Payment ID ;
- UETR ;
- identifiant du PSP payeur ;
- plage d’adresse IP de la session ;
- statut et type de fraude dans les remontées quotidiennes.
Plusieurs champs restent des placeholders.
Le corpus ne permet donc pas de connaître le jeu final utilisé par le modèle.
Le Conseil autorise les services de soutien à traiter un identifiant unique de compte, le montant et une plage IP afin de fournir la fraude et les litiges. Il exige parallèlement que ces données ne permettent pas d’identifier directement l’utilisateur.
Le débat sérieux se trouve ici.
Un moteur n’a pas besoin de connaître un nom pour reconnaître :
- une répétition ;
- un rythme ;
- un réseau de comptes ;
- une géographie approximative ;
- une succession d’appareils ;
- un comportement inhabituel.
Cette capacité est utile contre la fraude.
Elle peut aussi créer un profil technique durable.
Les questions sans réponse publique complète sont nombreuses :
- durée de conservation des scores ;
- profondeur de l’historique ;
- variables finales ;
- utilisation de machine learning ;
- entraînement sur données réelles ;
- accès des opérateurs techniques ;
- explication d’un faux positif ;
- possibilité de contester ;
- granularité des rapports transmis aux régulateurs ;
- rapprochement possible avec les autres services du DESP.
L’annexe détaillée des scénarios de risque demeure confidentielle.
Le niveau de détail commercial
La formule « la BCE connaîtra vos achats » mélange trois niveaux.
Le commerçant
Il connaît évidemment le panier vendu.
Son système de caisse peut conserver la liste des produits, le prix unitaire, les remises et la facture.
Le PSP acquéreur
Il connaît le commerçant, le montant, le terminal et les informations nécessaires au paiement.
L’infrastructure centrale
Le modèle de données documente notamment :
- le montant ;
- le commerçant ou son compte ;
- un Merchant Category Code, ou MCC ;
- le contexte du paiement ;
- une référence ou une information de remise facultative ;
- un éventuel pourboire ou montant additionnel.
Le MCC décrit une catégorie d’activité : restauration, transport, hébergement, services médicaux.
Il ne décrit pas nécessairement le contenu du panier.
Le corpus public actuel ne démontre pas que le DESP recevrait systématiquement :
café, croissant, marque, composition et quantité.
Une référence libre ou structurée peut néanmoins contenir une information sensible si le PSP ou le commerçant la renseigne.
La bonne conclusion est donc :
l’infrastructure centrale transporte le montant et peut acheminer un MCC chiffré entre acteurs autorisés. Le corpus public ne démontre ni que le DESP lit ce code en clair, ni une collecte généralisée du détail de chaque produit.
Les pseudonymes statiques vieillissent mal
Un pseudonyme peut être sûr le jour de sa création et devenir révélateur plus tard.
La CNIL et la BfDI ont insisté en mai 2026 sur le risque des identifiants statiques.
Supposons que l’infrastructure centrale voie pendant des mois le même identifiant technique.
Elle ignore le nom.
Une seule opération peut pourtant être connue de l’extérieur :
- un montant rare ;
- une heure précise ;
- un reçu ;
- un contrôle ;
- un incident ;
- un funding bancaire observé au même moment.
Si ce rapprochement révèle l’utilisateur derrière le pseudonyme, toutes les autres opérations liées au même identifiant deviennent corrélables.
Les autorités recommandent donc d’étudier des identifiants dynamiques, renouvelés régulièrement ou propres à chaque contexte.
Le projet actuel utilise plusieurs références :
- user ID ;
- preuve technique hachée ;
- DEAN ;
- UETR ;
- token ;
- identifiant d’appareil ;
- identifiant de score.
Toutes ne jouent pas le même rôle et toutes ne sont pas forcément visibles par le même service.
L’enquête doit obtenir une réponse claire à trois questions :
- quels identifiants restent stables ?
- quels services peuvent les voir ensemble ?
- quelle information supplémentaire permet de revenir à la personne ?
Le seuil de confidentialité que les autorités demandaient
Dès 2022, l’EDPB proposait un seuil en dessous duquel les petits paiements en ligne ne seraient ni tracés ni enregistrés par l’intermédiaire aux fins ordinaires de contrôle.
L’idée consiste à reproduire une propriété du cash : un café ne déclenche pas automatiquement la même traçabilité qu’un virement important.
L’avis conjoint EDPB-EDPS de 2023 demande également :
- de définir précisément les données de transaction ;
- de rendre la pseudonymisation obligatoire dans le texte juridique ;
- de justifier la nécessité du mécanisme antifraude central ;
- d’étudier des solutions moins centralisées ;
- de préciser les responsabilités des différents contrôleurs.
Le mode en ligne documenté en 2026 reste un système de compte à règlement central.
Nous n’avons pas trouvé dans le rulebook v0.91 un seuil général rendant les petits paiements en ligne non suivis par le PSP.
Le Parlement soutient les technologies de type zero-knowledge proof dans sa position de négociation. Cette orientation politique n’est pas encore une propriété démontrée de tous les flux techniques.
Le mode hors ligne change réellement la réponse
Le paiement hors ligne ne constitue pas seulement un mode dégradé du système en ligne.
Il vise une architecture différente.
La valeur serait chargée sur un dispositif sécurisé. Le transfert se produirait directement entre deux appareils proches, sans intervention d’un PSP ou du DESP au moment du paiement. La BCE affirme que les détails personnels de l’opération ne seraient connus que du payeur et du bénéficiaire.
Le mandat du Conseil va plus loin : les PSP ne devraient traiter pour le hors ligne que les informations nécessaires au chargement, au retrait et à l’authenticité du dispositif. Les données de transaction hors ligne ne devraient pas être surveillées ni conservées par l’intermédiaire.
Cette différence est substantielle.
Elle ne signifie pas qu’aucune donnée n’existe.
L’historique local du mode hors ligne
Le draft des flux de bout en bout contient un parcours de consultation de l’historique hors ligne.
L’application interroge le stockage sécurisé du dispositif, puis affiche les opérations à l’utilisateur.
Cette précision évite un raccourci.
« Les détails ne remontent pas à la BCE » ne signifie pas « aucune trace n’existe sur le téléphone ».
Une trace locale est nécessaire pour l’usage, la mise à jour du solde, la sécurité ou la présentation à l’utilisateur.
La question est de savoir si elle peut sortir du domaine sécurisé :
- sauvegarde cloud ;
- télémétrie ;
- analyse d’incident ;
- extraction par un attaquant ;
- mise à jour du logiciel ;
- procédure judiciaire ;
- compromission du secure element.
La documentation publique ne permet pas encore de trancher ces points.
La double dépense : l’endroit où la cryptographie rencontre la politique
Un billet remis à une personne ne reste pas simultanément dans la main du payeur.
Un fichier peut être copié.
Le mode hors ligne doit donc empêcher qu’une même valeur soit dépensée plusieurs fois sans demander l’autorisation d’un serveur au moment de chaque transaction.
L’expertise publiée par l’EDPB en 2025 conclut qu’une solution à la fois privée et résistante à la double dépense est techniquement envisageable.
Elle étudie plusieurs outils :
- signatures aveugles ;
- matériel sécurisé ;
- limites de montant ;
- réconciliation différée ;
- détection après coup ;
- révélation de l’identité uniquement lorsqu’un utilisateur dépense deux fois la même valeur.
Cette étude ne valide pas le futur système de la BCE.
Elle montre que le problème possède des solutions, avec des compromis.
Un matériel sécurisé peut être attaqué. Une réconciliation fréquente réduit l’autonomie hors ligne. Une révélation conditionnelle exige une architecture capable de conserver une preuve cachée. Une limite basse réduit le risque au prix de l’utilité.
Le Parlement veut que la double dépense soit traitée avant le lancement.
Le protocole final n’est pas public.
Perdre le téléphone ou récupérer l’argent
Le mandat de négociation du Parlement envisage que la perte du dispositif entraîne la perte des euros hors ligne sans remboursement.
Cette règle peut sembler brutale.
Elle possède une logique de confidentialité.
Pour restaurer exactement un solde après la destruction d’un appareil, un système doit généralement disposer quelque part :
- d’une copie ;
- d’un état récent ;
- d’une preuve ;
- ou d’une capacité à reconstituer les transactions.
Plus la récupération est complète, plus le système central doit connaître l’état de la valeur hors ligne.
Plus le dispositif ressemble à un billet, plus la perte risque d’être définitive.
Ce choix ne relève pas seulement de l’expérience utilisateur.
Il détermine la quantité de données nécessaire au fonctionnement.
Les autorités pourront-elles retrouver une opération ?
Le projet ne crée pas une zone située hors du droit.
Les paiements en ligne restent soumis aux règles de :
- lutte contre le blanchiment ;
- lutte contre le financement du terrorisme ;
- sanctions ;
- fraude ;
- enquête judiciaire ;
- droits du payeur ;
- remboursement ;
- conservation réglementaire.
Le PSP possède la relation avec l’identité.
Une autorité compétente peut demander des données selon la base légale applicable.
La confidentialité promise vis-à-vis de l’Eurosystème ne signifie donc pas l’impossibilité d’une identification ciblée.
Elle cherche à empêcher une identification générale et quotidienne par la banque centrale.
La distinction entre ces deux pouvoirs doit rester nette :
- surveillance systématique : constitution permanente d’un historique nominatif central ;
- réidentification ciblée : accès à une information chez un PSP dans le cadre d’une procédure légale.
Le corpus public décrit l’interdiction du premier.
Le droit commun maintient le second.
Le grand angle mort : combien de temps ?
Le projet justifie de nombreuses conservations :
- suivi du statut ;
- remboursement ;
- transaction non autorisée ;
- litige ;
- fraude ;
- AML ;
- sanctions ;
- sécurité ;
- audit ;
- changement de PSP.
Les documents publics ne fournissent pas encore une matrice complète des durées.
Nous ne savons pas précisément combien de temps seraient conservés :
- UETR ;
- historiques dans le DESP ;
- scores de fraude ;
- adresses IP ;
- recherches d’alias ;
- tokens et tables de détokenisation ;
- identifiants d’appareil ;
- logs d’administration ;
- sauvegardes ;
- faux positifs corrigés.
Une architecture de protection des données ne se juge pas seulement sur les champs collectés.
Elle se juge sur la durée pendant laquelle ils peuvent être rapprochés.
Six mythes, six verdicts
| Affirmation | Verdict au 14 août 2026 |
|---|---|
| « La BCE verra nominativement chaque achat » | Non étayé par le design actuel. Le nom resterait chez le PSP et les données centrales seraient pseudonymisées. |
| « Personne ne pourra retrouver un paiement en ligne » | Faux. Le PSP connaît son client et conserve les informations nécessaires au droit applicable. |
| « Le système saura exactement quels produits ont été achetés » | Non établi. Montant, commerçant, MCC et références peuvent circuler, pas nécessairement le panier détaillé. |
| « Le moteur antifraude central équivaut déjà à une base de surveillance nominative » | Non démontré. Il peut toutefois construire un profil technique transversal sans connaître directement le nom. |
| « Un paiement hors ligne ne produit aucune donnée » | Faux. Chargement, dispositif, solde local, historique local et retrait produisent des données. Le détail ne devrait pas remonter au centre. |
| « Le mode hors ligne est déjà aussi anonyme qu’un billet » | Trop affirmatif. C’est l’objectif politique et technique, mais le protocole final reste à construire et auditer. |
État des preuves et questions ouvertes
| Proposition | État de la preuve |
|---|---|
| Le PSP connaîtrait l’identité de son client | établi par le modèle de distribution et les obligations KYC/AML |
| L’Eurosystème ne devrait pas recevoir le nom civil dans le règlement ordinaire | objectif juridique et technique convergent |
| Les comptes et transactions en ligne seraient pseudonymisés | prévu par le Conseil et soutenu par les autorités de protection |
| Le DESP traiterait montant, comptes techniques, références et statuts | documenté dans les spécifications provisoires |
| Le numéro de téléphone pourrait servir d’alias | documenté, actuellement seul type supplémentaire prévu |
| Le RFM analyserait des motifs entre plusieurs PSP | documenté par le marché public et le draft |
| Le jeu final de données du RFM est connu | non, plusieurs champs et l’annexe de risque restent incomplets ou confidentiels |
| La BCE recevrait systématiquement le panier détaillé | non établi |
| Les identifiants seraient tous dynamiques | non démontré |
| Un seuil de confidentialité existe pour les petits paiements en ligne | recommandé par l’EDPB ; absent du rulebook actuel |
| Le détail des paiements hors ligne ne remonterait pas | objectif explicite du Conseil et de la BCE |
| Le protocole hors ligne garantit déjà l’anonymat et l’absence de double dépense | non, implémentation non finalisée |
| La perte du dispositif entraînerait toujours la perte des fonds | position du Parlement ; statut législatif non définitif |
La conclusion dépend d’un verbe : relier
La BCE peut concevoir une infrastructure qui ne reçoit pas directement les noms.
Le PSP peut conserver l’identité.
SEPI peut remplacer certaines données par des tokens.
Le service de règlement peut chiffrer les objets destinés aux autres PSP.
Le moteur antifraude peut travailler sur des identifiants techniques.
La confidentialité de l’ensemble dépend pourtant d’un seul test :
un acteur peut-il relier les fragments ?
La pseudonymisation fonctionne si la clé reste séparée.
La tokenisation fonctionne si la table de correspondance est protégée.
Le chiffrement fonctionne si les clés et métadonnées sont maîtrisées.
Le hors ligne fonctionne si les appareils honnêtes peuvent échanger sans créer un historique central et sans permettre la double dépense.
Le projet européen possède une architecture crédible pour éviter qu’une base centrale affiche immédiatement le nom de chaque payeur.
Il ne possède pas encore, dans le corpus public, toutes les preuves permettant d’affirmer que les corrélations seront durablement impossibles.
C’est cette frontière qu’il faudra surveiller à chaque nouvelle version du rulebook, du règlement et des contrats techniques.
Suite : la frontière juridique de l’argent programmable
Le quatrième volet examine un autre mélange fréquent.
Une monnaie programmable porte des restrictions dans l’unité elle-même : date d’expiration, catégories d’achat ou conditions intrinsèques.
Un compte ordinaire peut déjà être gelé, saisi ou bloqué sur une base légale sans que l’euro qu’il contient soit programmable.
Le prochain article séparera donc :
- monnaie programmable ;
- paiements conditionnels ;
- réservations de fonds ;
- sanctions ;
- fraude ;
- gel judiciaire ;
- modification future de la loi.
Sources et méthode
Ce volet repose principalement sur :
- la proposition de règlement de la Commission ;
- le mandat de négociation du Conseil, notamment ses articles 34 à 37 et annexes III à V ;
- la position ECON du Parlement et l’autorisation de négocier ;
- la page de confidentialité de la BCE et sa FAQ ;
- le rulebook v0.91, particulièrement les annexes consacrées à la gestion des données, à l’accès et aux alias, à SEPI, au risque et à la fraude, au règlement et aux flux de bout en bout ;
- le Statement 04/2022 de l’EDPB, l’avis conjoint EDPB-EDPS 02/2023 et l’expertise sur le mode hors ligne ;
- l’analyse conjointe de la CNIL et de la BfDI ;
- les marchés publics de la BCE relatifs au risque et à la fraude, à l’alias lookup, à SEPI et au mode hors ligne.
Le corpus distingue systématiquement une donnée présente dans un modèle, une donnée effectivement envoyée par une API, une donnée visible en clair, une donnée simplement routée et une donnée dont la conservation est démontrée. Lorsque la documentation contient un placeholder ou réserve une partie des exigences à une annexe confidentielle, l’article le signale au lieu de compléter le vide par une hypothèse.
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 ..