// analyse

Euro numérique, 6/6 : qui contrôle la machine ?

Version anglaiseRead this analysis in English
Garanties de lectureDatée, sourcée, sans tracker
lecture datéesources citéesaucun trackerpartage sans script tiers
Niveaux de preuveProfondeur 3 : source liée · 4 niveaux détectés
source liéesource primairesource secondairehypothèse / scénariocontexte l0g
Sommaire et notions16 étapes · 2 notions

Analyse complète

Ce texte clôt notre enquête en six volets sur l’euro numérique. Le cinquième article suivait la facture. Ce dernier volet entre dans la machine : banques centrales, marchés publics, fournisseurs, code, clés, téléphones et réseaux. La question finale porte sur la reprise du contrôle lorsqu’un élément casse.

L’euro qui s’affichera dans un portefeuille numérique serait une dette publique.

L’application qui l’affiche ne le serait pas nécessairement.

Le logiciel qui produit un score de fraude, la table qui résout un numéro de téléphone, la puce qui conserve des fonds hors ligne et une partie du réseau qui transporte les messages pourraient dépendre d’entreprises privées engagées pour dix ou quinze ans.

Cette architecture n’est pas une anomalie. Une banque centrale n’a pas vocation à fabriquer chaque téléphone, coder chaque application et poser chaque fibre. La souveraineté ne demande pas que l’État écrive toutes les lignes de code.

Elle demande autre chose : pouvoir voir, modifier, remplacer et reconstruire le système lorsque le fournisseur, le réseau ou le gatekeeper n’est plus disponible.

État du dossier au 15 août 2026. Le règlement final n’est pas adopté et la décision d’émettre n’est pas prise. Cinq composants externes ont toutefois déjà donné lieu à des accords-cadres. Le cœur a été confié à six banques centrales nationales. Un marché séparé de connectivité est engagé. Les plafonds publiés ne sont pas des dépenses et les accords-cadres ne garantissent pas qu’un développement complet soit commandé.

Sept éléments à retenir

  • L’émission, les avoirs et le règlement central resteraient dans l’Eurosystème.
  • Six banques centrales nationales ont été retenues pour les composants de cœur.
  • Cinq services spécialisés ont deux fournisseurs classés chacun, soit dix accords-cadres.
  • Leur valeur estimée cumulée atteint 432,1 millions d’euros ; leurs plafonds totalisent 1,164 milliard.
  • Les contrats peuvent aller jusqu’à dix ans pour alias, application et SEPI, quinze ans pour fraude et offline.
  • Le marché offline publie des droits d’utilisation, de modification et de redistribution particulièrement forts ; le même niveau n’est pas vérifiable publiquement pour les quatre autres composants.
  • La dépendance la plus difficile se situe peut-être hors des contrats BCE : stores, systèmes d’exploitation, secure elements, HSM et réseaux.

Une monnaie publique dans une machine hybride

Le design actuel peut se lire en quatre couches.

La première est monétaire. L’Eurosystème émettrait l’euro numérique, enregistrerait les avoirs et réaliserait le règlement final. La dette ne serait portée ni par une banque commerciale, ni par un fournisseur informatique.

La deuxième est la Digital Euro Service Platform, ou DESP. Son cœur doit être fourni par des banques centrales, tandis que cinq composants spécialisés sont confiés à des entreprises privées sous gouvernance de la BCE.

La troisième est la distribution. Les banques et autres PSP conserveraient la relation client : identité, compte, assistance, fraude locale, litiges, funding et defunding.

La quatrième se trouve dans la poche du citoyen et entre les datacentres : smartphone, système d’exploitation, app store, secure element, HSM, télécoms et fournisseurs réseau.

La machine de l’euro numérique en quatre couchesLe cœur monétaire est public, les services spécialisés sont publics et privés, la distribution revient aux PSP, tandis que les appareils et réseaux créent des dépendances extérieures.LA MACHINE EN QUATRE COUCHESLa souveraineté varie selon la couche observée1. MONNAIE ET REGISTRESix banques centrales nationalesÉmission, avoirs, règlement final, limites.La dette monétaire reste dans l’Eurosystème.CONTRÔLE PUBLIC2. SERVICES DESPCœur public + cinq composants privésAlias, fraude, application, offline et SEPI.Gouvernance BCE, développement et opération contractuels.PUBLIC + PRIVÉ EUROPÉEN3. DISTRIBUTIONBanques et autres PSPKYC, compte, interface, support, litiges, funding.La relation client reste privée et réglementée.PRIVÉ RÉGLEMENTÉ4. APPAREILS ET RÉSEAUXOS, stores, secure elements, NSPApple, Google, OEM, HSM, TSM, télécoms et datacentres.Le droit européen encadre, sans supprimer la dépendance.DÉPENDANCES MIXTESTest final : qui peut reprendre chaque couche sans permission extérieure ?Sources : BCE, marchés publics, mandat du Conseil. Synthèse l0g.
La monnaie reste publique. L’expérience, la distribution et plusieurs dépendances matérielles reposent sur des couches contractuelles distinctes.

Cette décomposition évite deux caricatures.

La première affirme que des sociétés privées émettront l’euro. Elles ne porteront pas la dette monétaire et ne pourront pas créer un solde à leur convenance.

La seconde affirme que tout restera sous contrôle direct de Francfort. Une infrastructure peut garder un cœur public tout en dépendant, pour fonctionner chaque jour, de logiciels, de clés et d’appareils administrés ailleurs.

La souveraineté se joue précisément dans les interfaces entre ces couches.

Six banques centrales pour le cœur

Le Conseil des gouverneurs a retenu en juillet 2025 six banques centrales nationales :

  • Banca d’Italia ;
  • Banco de España ;
  • Banque de France ;
  • Deutsche Bundesbank ;
  • Lietuvos bankas ;
  • Oesterreichische Nationalbank.

La BCE décrit un règlement centralisé dans lequel l’Eurosystème enregistre et vérifie les avoirs et les règlements.

Ce choix protège l’élément le plus important : le grand livre monétaire et la capacité d’émission restent publics.

Il ne rend pas encore l’architecture publique totalement lisible.

Le corpus ouvert ne répartit pas précisément les fonctions entre les six banques centrales. Il ne permet pas de savoir publiquement :

  • laquelle développe l’émission ;
  • laquelle opère le registre ;
  • où se trouvent les sites actifs ;
  • comment le quorum est construit ;
  • qui détient les clés racines ;
  • combien de sites peuvent continuer isolément ;
  • comment une autre banque centrale reprendrait un composant.

Cette discrétion peut protéger la sécurité opérationnelle. Elle limite aussi l’audit public de la résilience.

Le point doit rester mesuré : l’absence de détail public ne prouve ni centralisation fragile ni mauvaise séparation des rôles. Elle empêche simplement de vérifier la topologie de reprise.

Cinq composants privés, dix accords-cadres

En octobre 2025, la BCE a publié les fournisseurs classés pour cinq composants.

Alias lookup

Le service doit relier le DEAN, le PSP et un alias comme le numéro de téléphone afin de router le paiement.

Premier : Sapient GmbH et Tremend Software Consulting.

Second : equensWorldline SE Germany.

Valeur estimée : 27,9 millions d’euros. Plafond : 55,8 millions. Durée maximale : dix ans.

Risk and Fraud Management

Le composant doit produire un score de risque en temps réel, analyser les transactions après règlement et fournir une vision transversale aux PSP.

Premier : Feedzai.

Second : Capgemini Deutschland.

Valeur estimée : 79,1 millions d’euros. Plafond : 237,3 millions. Durée maximale : quinze ans.

Application et SDK

La BCE prévoit une application commune et un SDK permettant aux PSP d’intégrer l’euro numérique à leurs propres interfaces.

Premier : Almaviva et Fabrick.

Second : Sapient et Tremend.

Valeur estimée : 76,8 millions d’euros. Plafond : 153,6 millions. Durée maximale : dix ans.

Solution hors ligne

La brique doit permettre des paiements successifs sans tiers dans la transaction, en P2P et au point de vente, avec funding, defunding, maintenance, hébergement et service desk.

Premier : G+D advance52 et G+D Currency Technology.

Second : equensWorldline.

Valeur estimée : 220,7 millions d’euros. Plafond : 662,1 millions. Durée maximale : quinze ans.

SEPI

Le Secure Exchange of Payment Information doit tokeniser et détokeniser des informations de paiement, générer des valeurs utilisables dans un QR code, un lien ou le NFC, puis gérer leur cycle de vie.

Premier : Senacor FCS.

Second : equensWorldline.

Valeur estimée : 27,6 millions d’euros. Plafond : 55,2 millions. Durée maximale : dix ans.

Cinq composants et dix accords-cadresPour chaque composant, la BCE a classé un fournisseur premier et un second. Les valeurs estimées et plafonds ne sont pas des dépenses.5 COMPOSANTS, 10 ACCORDSPremier classé, second si nécessaireALIAS LOOKUP · 10 ANS MAX.1. Sapient + Tremend2. equensWorldline27,9 M€ estimés55,8 M€ plafond9 offres · qualité 60 % · prix 40 %RISQUE ET FRAUDE · 15 ANS MAX.1. Feedzai2. Capgemini Deutschland79,1 M€ estimés237,3 M€ plafond8 offres · qualité 70 % · prix 30 %APPLICATION ET SDK · 10 ANS MAX.1. Almaviva + Fabrick2. Sapient + Tremend76,8 M€ estimés153,6 M€ plafond10 offres · qualité 60 % · prix 40 %SOLUTION OFFLINE · 15 ANS MAX.1. G+D advance52 + Currency Technology2. equensWorldline220,7 M€ estimés662,1 M€ plafond4 offres · qualité 70 % · prix 30 %SEPI · 10 ANS MAX.1. Senacor FCS2. equensWorldline27,6 M€ estimés55,2 M€ plafond4 offres · qualité 60 % · prix 40 %DISTINCTION CLÉLe second fournisseur ouvre une option contractuelle.La bascule opérationnelle exige un test séparé.Sources : avis d’attribution BCE, octobre 2025. Synthèse l0g.
La BCE a classé deux équipes par composant. Le second titulaire ouvre une voie contractuelle de secours dont l’état de préparation technique reste à vérifier.

La qualité pèse 60 % de la sélection pour alias, application et SEPI, 70 % pour fraude et offline. Les prix représentent le reste.

Au total, les cinq procédures ont reçu 35 offres.

L’existence d’une compétition réelle au moment de l’attribution ne garantit pas qu’elle subsistera après dix ans d’intégration, de données et de connaissances accumulées.

Valeurs estimées, plafonds et commandes

La somme des valeurs estimées atteint 432,1 millions d’euros.

La somme des plafonds atteint 1,164 milliard d’euros.

Ces deux chiffres demandent une discipline de lecture.

La valeur estimée indique l’ordre de grandeur anticipé de la procédure.

Le plafond définit le maximum susceptible d’être commandé pendant la durée de l’accord.

L’accord-cadre lui-même n’entraîne pas automatiquement une dépense. La BCE l’a précisé au moment de la sélection : aucune somme n’est due du seul fait de la signature. Les travaux sont déclenchés progressivement par des commandes ou accords spécifiques.

Le plafond peut couvrir :

  • deux années de développement ;
  • déploiement progressif ;
  • maintenance ;
  • exploitation ;
  • hébergement ;
  • service desk ;
  • extensions jusqu’à dix ou quinze ans.

L’addition de 1,164 milliard ne signifie donc pas que la BCE a versé un milliard aux fournisseurs.

Elle ne doit pas non plus être ajoutée mécaniquement aux 1,3 milliard de développement public présentés dans le cinquième volet. Les périmètres et les horizons se chevauchent probablement en partie.

Valeurs estimées et plafonds des marchés externesLes barres comparent la valeur estimée et le maximum contractuel pour cinq composants et le marché réseau.VALEURS DES MARCHÉSValeurs estimées et maxima contractuelsAlias27,9 M€55,8 M€Fraude79,1 M€237,3 M€App + SDK76,8 M€153,6 M€Offline220,7 M€662,1 M€SEPI27,6 M€55,2 M€Connectivité, 2 lots162,84 M€355,32 M€CINQ COMPOSANTS ATTRIBUÉS432,1 M€ estimés1,164 Md€ plafondDéveloppement, maintenance, exploitation et options peuvent se chevaucher.AVEC LA CONNECTIVITÉ594,94 M€ estimés · 1,51932 Md€ de plafondsLe marché réseau n’était pas attribué dans le corpus au 15 août 2026.PLAFOND = COMMANDE MAXIMALESources : avis de marchés BCE. Calculs l0g.
La solution offline domine les enveloppes publiées. Les plafonds indiquent la commande maximale possible sur toute la durée du contrat.

Le cas offline illustre la différence.

Sa valeur estimée représente environ 51 % du total des cinq procédures. Son plafond représente près de 57 %.

Cette concentration peut refléter :

  • la complexité cryptographique ;
  • le matériel sécurisé ;
  • la lutte contre la double dépense ;
  • la maintenance ;
  • l’hébergement ;
  • la très longue période d’exploitation ;
  • le besoin de plusieurs formes d’appareil.

Elle ne permet pas de conclure que 662,1 millions seront dépensés.

La portée réelle du second fournisseur

La BCE adresse d’abord ses demandes au fournisseur classé premier. Le second est contacté si nécessaire.

Cette construction procure une option contractuelle. Elle peut protéger contre :

  • un refus ;
  • une incapacité ;
  • une rupture ;
  • un besoin supplémentaire ;
  • une volonté de remplacement.

Elle ne démontre pas une bascule technique.

Pour parler de redondance active, il faudrait répondre à des questions plus exigeantes.

Le second fournisseur reçoit-il le code du premier ?

Dispose-t-il des mêmes données, clés et environnements ?

Maintient-il une équipe prête ?

Une implémentation commune ou compatible existe-t-elle ?

Combien de jours séparent l’incident de la reprise ?

Le service peut-il continuer pendant la transition ?

La BCE peut-elle opérer elle-même entre les deux ?

Les avis publics ne répondent pas.

Le résultat le plus rigoureux est donc :

La BCE a acheté une redondance contractuelle. La redondance opérationnelle reste à démontrer.

La distinction est particulièrement importante pour le moteur antifraude.

Un autre fournisseur peut reproduire une API. Reprendre un système ayant accumulé règles, statistiques, modèles et procédures pendant plusieurs années exige davantage qu’un contrat de secours.

La même difficulté apparaît pour l’alias. Le second doit pouvoir reprendre une table de mapping complète, prouver son intégrité, continuer les requêtes et conserver les protections contre l’énumération.

Pour SEPI, il faut migrer les tokens, les clés et les HSM sans casser les paiements en cours.

Pour l’app, il faut reconstruire, signer et republier une version compatible dans les stores.

Pour l’offline, il faut reprendre le code, les applets, les clés, le provisioning et le support matériel.

Une option de marché ne réalise aucune de ces opérations à elle seule.

La concentration économique derrière les dix accords

Les dix accords ne correspondent pas à dix groupes économiques distincts.

Sapient et Tremend apparaissent ensemble sur l’alias et l’application. Publicis Groupe a acquis Tremend en 2022 afin de renforcer les capacités de livraison de Publicis Sapient.

Les deux sociétés restent des entités identifiables dans le groupement, mais ne constituent pas deux pôles de contrôle totalement indépendants.

equensWorldline est classé second sur trois composants : alias, offline et SEPI.

Cette présence n’implique pas que Worldline opère trois briques. Elle signifie qu’une partie importante de la solution de repli se concentre dans le même groupe.

L’effet peut être positif : expertise paneuropéenne, connaissance des interfaces et capacité industrielle.

Il peut aussi créer une corrélation : un problème juridique, financier, technique ou de gouvernance chez le groupe affecterait plusieurs options de secours.

Fabrick appartient à l’écosystème Sella. Sa propre communication cite aussi Mastercard et Reale Mutua parmi ses soutiens au capital.

La présence d’un investisseur minoritaire non européen n’établit aucun contrôle non européen. Elle montre que « fournisseur européen » ne signifie pas entreprise isolée de tout capital ou partenariat mondial.

L’analyse sérieuse doit donc regarder :

  • contrôle ;
  • droits de vote ;
  • sous-traitance ;
  • dépendances logicielles ;
  • accès aux données ;
  • capacité de remplacement.

Le drapeau du siège ne suffit pas.

La clause européenne est une vraie barrière

Les cinq procédures externes imposent aux candidats, membres de groupements et sous-traitants d’être établis dans l’Union et contrôlés par des ressortissants ou entités de l’Union.

Le contrôle peut être évalué à travers :

  • le capital ;
  • les droits de vote ;
  • le pouvoir de décision direct ou indirect.

Les titulaires doivent aussi éviter que leurs coopérations avec des acteurs de pays tiers ne compromettent les intérêts de sécurité ou l’approvisionnement critique.

Cette clause est plus forte qu’une obligation de localisation.

Elle protège contre une entreprise directement pilotée depuis une juridiction extérieure pour les composants sélectionnés.

Elle donne également à la BCE un moyen de surveiller les changements de contrôle et les sous-traitants critiques.

Sa portée reste limitée à l’objet qu’elle contrôle.

Elle ne garantit pas que :

  • le cloud est européen ;
  • chaque bibliothèque est maintenue en Europe ;
  • le HSM est européen ;
  • le système d’exploitation est européen ;
  • le secure element est européen ;
  • la chaîne de compilation est indépendante ;
  • aucun brevet étranger n’est nécessaire ;
  • le support ne passe jamais par une filiale hors EEE.

La souveraineté juridique du titulaire constitue une fondation.

Elle ne cartographie pas toute la supply chain.

Une sous-traitance largement opaque

Les avis d’attribution indiquent un recours à la sous-traitance pour huit des dix accords. Deux déclarent l’absence de sous-traitance.

Les mêmes avis ne donnent généralement pas :

  • les noms ;
  • les fonctions ;
  • les montants ;
  • les pourcentages ;
  • l’accès aux données ;
  • l’accès à la production ;
  • les pays d’opération.

Le titulaire peut sous-traiter des fonctions aussi différentes que :

  • cloud ;
  • SOC ;
  • développement ;
  • support ;
  • HSM ;
  • TSM ;
  • tests ;
  • modèle d’apprentissage ;
  • connectivité.

La clause de contrôle européen s’applique en principe aux acteurs concernés par les procédures.

Le public ne peut pas vérifier la chaîne réelle.

Cette opacité ne suffit pas à conclure à une dépendance problématique. Elle empêche de mesurer la concentration et les droits d’accès.

Une infrastructure de paiement souveraine devrait pouvoir publier au minimum :

  • la liste des sous-traitants critiques ;
  • leur fonction ;
  • leur pays ;
  • leur accès potentiel ;
  • le mécanisme d’approbation d’un remplacement.

La confidentialité commerciale n’exige pas de cacher l’existence d’une dépendance critique.

Dix ou quinze ans : continuité et verrouillage

Les durées maximales peuvent surprendre.

Alias, application et SEPI peuvent atteindre dix ans.

Fraude et offline peuvent atteindre quinze ans.

Les avis donnent une justification cohérente :

  • environ deux ans de développement ;
  • mise en service progressive ;
  • montée en charge après la phase initiale ;
  • besoin de stabilité pendant l’onboarding massif ;
  • maintenance et exploitation de long terme.

Une banque centrale ne change pas son moteur antifraude ou sa solution hors ligne comme elle change un prestataire de communication.

La durée protège la continuité.

Elle peut aussi concentrer :

  • la connaissance ;
  • les procédures ;
  • les modèles ;
  • les outils ;
  • les équipes ;
  • le pouvoir de négociation.

Un contrat long n’est pas automatiquement un lock-in.

Le lock-in apparaît lorsque la sortie n’est pas démontrable.

Les bonnes questions sont donc :

  • le code est-il repris ?
  • les formats sont-ils ouverts ?
  • les données sont-elles exportables ?
  • les clés peuvent-elles être migrées ?
  • les builds sont-ils reproductibles ?
  • les équipes publiques savent-elles opérer ?
  • les extensions sont-elles conditionnées à un test de sortie ?

Une clause de durée protège le service. Un test de reprise protège la souveraineté.

Quels droits sur le code ?

La réponse la plus claire concerne l’offline.

L’avis de marché indique que la BCE cherche une solution de bout en bout avec les droits complets pour :

  • l’utiliser ;
  • la modifier ;
  • la redistribuer aux intermédiaires participants.

Cette clause constitue une garantie de reprise sérieuse.

Elle n’épuise pas toutes les questions.

Le code peut contenir :

  • bibliothèques tierces ;
  • firmware propriétaire ;
  • brevets ;
  • outils de compilation fermés ;
  • modules matériels ;
  • composants dont la redistribution est limitée.

Il faut encore connaître le périmètre précis des droits.

Le pilote apporte un signal favorable. Sa documentation prévoit pour certaines briques :

  • spécifications ;
  • API ;
  • implémentation de référence ;
  • code source d’un SDK offline ;
  • application exemple ;
  • scripts de test.

Ces livrables facilitent l’intégration et l’audit.

Ils concernent une version bêta et ne prouvent pas que toute l’implémentation de production sera publiée.

Pour l’alias, le moteur antifraude, l’application et SEPI, les avis publics décrivent développement, maintenance et opération. Ils ne publient pas une clause de droits aussi explicite que celle de l’offline.

La formulation correcte est :

Les droits de modification et de reprise ne sont pas vérifiables publiquement pour quatre composants.

Cette phrase ne signifie pas qu’ils sont absents des contrats détaillés.

Elle signifie qu’une propriété essentielle de souveraineté demeure derrière la plateforme d’e-tendering.

Standards ouverts, code ouvert et reprise

Le rulebook et les API peuvent être publics tandis que l’implémentation reste propriétaire.

Un standard ouvert permet :

  • plusieurs PSP ;
  • conformité ;
  • interopérabilité ;
  • certification ;
  • développement alternatif.

Il ne garantit pas :

  • accès au dépôt ;
  • build reproductible ;
  • contrôle des clés ;
  • maîtrise de la production ;
  • compétences pour opérer.

Le code open source aide lui aussi sans résoudre tout le problème.

Une banque centrale peut posséder un dépôt et dépendre encore :

  • d’une chaîne CI fermée ;
  • d’un cloud spécifique ;
  • d’un app store ;
  • d’un HSM ;
  • d’un fournisseur qui seul connaît les procédures.

La hiérarchie la plus utile est donc :

  1. standard public ;
  2. spécification complète ;
  3. code accessible ;
  4. droits de modification ;
  5. build reproductible ;
  6. clés sous contrôle ;
  7. exploitation documentée ;
  8. reprise testée.

La souveraineté commence avec le droit.

Elle se confirme par une opération réussie sans le fournisseur historique.

Qui détient les droits root ?

Les contrats couvrent souvent plus que le développement.

Le moteur antifraude, l’application et l’offline incluent l’opération. L’offline couvre explicitement hébergement, fonctionnement et service desk.

Les avis publics ne détaillent pas :

  • le cloud ;
  • les datacentres ;
  • les comptes administrateurs ;
  • les bastions ;
  • les HSM ;
  • les clés racines ;
  • les sauvegardes ;
  • les RTO et RPO ;
  • les procédures de restauration ;
  • les accès d’urgence ;
  • les personnels habilités.

La question « qui possède les droits root ? » n’implique pas l’existence d’un bouton unique capable de modifier la monnaie.

Elle demande qui peut :

  • déployer une version ;
  • signer un binaire ;
  • administrer la production ;
  • restaurer après incident ;
  • extraire un journal ;
  • faire tourner le service pendant une crise.

Une infrastructure peut être gouvernée par la BCE et opérée au quotidien par un titulaire.

La souveraineté exige que la banque centrale sache reprendre cette opération dans une situation extrême, directement ou par un autre fournisseur.

Le smartphone reste une frontière extérieure

L’application euro numérique doit être distribuée au moins dans les stores officiels Android et iOS. Elle doit aussi fonctionner sur des versions anciennes encore supportées et sur différents appareils, dont des wearables.

Le développeur peut être européen.

Le canal de distribution et une partie du matériel ne le sont pas.

Le NFC a été ouvert

En juillet 2024, la Commission européenne a rendu juridiquement contraignants pendant dix ans les engagements d’Apple sur l’accès NFC dans l’EEE.

Les wallets tiers peuvent utiliser Host Card Emulation, être choisis par défaut et s’appuyer sur Face ID ou Touch ID dans les conditions prévues.

Cette ouverture réduit le pouvoir de verrouillage d’Apple sur les paiements de proximité en ligne.

Ce que HCE permet réellement

La BCE avait averti qu’un accès HCE ne suffit pas pour sa vision du paiement hors ligne mobile.

Le secure element offre un environnement matériel résistant aux manipulations. Il peut être intégré, embarqué ou lié à une eSIM.

La solution offline doit prévenir la copie et la double dépense sans serveur interrogé pendant la transaction.

Le matériel devient donc un élément monétaire fonctionnel, même s’il n’émet pas la monnaie.

Le droit cherche à ouvrir le matériel

L’article 33 du mandat du Conseil prévoit un accès équitable, raisonnable et non discriminatoire aux fonctions matérielles et logicielles nécessaires.

Les États membres doivent désigner des autorités et prévoir des sanctions.

Le texte peut transformer une négociation commerciale en obligation légale.

Il reste à démontrer :

  • le prix FRAND ;
  • le délai ;
  • la capacité de stockage ;
  • le provisioning ;
  • la parité avec le wallet natif ;
  • le support des wearables ;
  • la durée de support ;
  • l’accès sur les appareils non désignés comme gatekeepers.
Chaîne de dépendance du paiement offlineLe paiement entre deux appareils peut être local, tandis que l’installation, le financement, les clés et la maintenance dépendent d’une chaîne de fournisseurs.OFFLINE : TROIS TEMPSProvisionnement, transaction et maintenanceAVANT LE PAIEMENTProvisionner l’instrumentApp store → OS → SDK → OEM → secure elementTSM / eSIM → PSP → HSM → service offlineSTORE / OSApple, GoogleSECURE ELEMENTOEM, puce, eSIMPSP / HSMclés et compteOFFLINEG+D / secoursPENDANT LE PAIEMENTDeux appareils, transfert directAPPAREIL Asolde localP2P / POSBsolde localAucun tiers n’intervient dans la transaction honnête.APRÈS ET AUTOUR DU PAIEMENTMettre à jour, révoquer, financer• funding et defunding identifiés• rotation des clés et applets• appareil compromis et liste de révocation• fin de support d’un OS ou d’un secure element• migration vers un autre fournisseurL’usage proche du cash dépend d’une chaîne complexe.ARTICLE 33Le droit vise un accès FRAND. Le prix, le délai et la parité restent à tester.Sources : BCE, Commission européenne, mandat du Conseil. Synthèse l0g.
Le transfert offline peut être direct entre deux appareils. La création, la mise à jour et la reprise de l’instrument dépendent d’une chaîne beaucoup plus longue.

Le paradoxe est clair.

La transaction la plus proche du cash pourrait être celle dont le provisioning dépend le plus d’acteurs privés.

Une architecture robuste doit donc prévoir plusieurs chemins :

  • plusieurs fabricants ;
  • plusieurs secure elements ;
  • carte physique ;
  • appareil relais ;
  • provisioning indépendant de l’opérateur télécom ;
  • applet portable ;
  • clés sous contrôle public ;
  • test d’abandon d’un OEM.

Un sixième marché pour le réseau

Un marché séparé concerne la connectivité entre :

  • les PSP ;
  • les banques centrales nationales ;
  • la DESP ;
  • les composants répartis entre plusieurs sites et datacentres.

La procédure prévoit deux lots.

La valeur estimée totale est de 162,84 millions d’euros et le plafond de 355,32 millions sur une durée pouvant atteindre dix ans.

Un même candidat peut soumissionner aux deux lots, mais ne peut en remporter qu’un. La BCE cherche donc deux opérateurs distincts.

Le lot 1 est réservé aux entités de l’Union contrôlées dans l’Union.

Le lot 2 est ouvert aux acteurs européens et non européens.

Nous n’avons identifié aucun avis officiel d’attribution dans le corpus public examiné au 15 août 2026.

Cette ouverture hors Union ne signifie pas qu’un acteur étranger contrôlerait la monnaie.

L’opérateur réseau ne décide ni des avoirs, ni de l’émission, ni du règlement.

Il peut néanmoins devenir critique pour :

  • la disponibilité ;
  • le routage ;
  • la protection DDoS ;
  • les métadonnées ;
  • le support ;
  • la continuité entre datacentres.

Le réseau illustre parfaitement la différence entre contrôle monétaire et dépendance opérationnelle.

Une solution peut préserver la souveraineté du grand livre tout en exposant la disponibilité à une chaîne extérieure.

Une grille de souveraineté en six tests

Attribuer une note globale sur dix serait séduisant et trompeur.

Le cœur public recevrait une bonne note. Le secure element une note incertaine. Les droits offline seraient plus forts que les droits publiés sur l’antifraude. La connectivité resterait en cours.

La moyenne écraserait ces différences.

L’article retient donc six tests.

Les six tests de souverainetéLa souveraineté opérationnelle est évaluée par la gouvernance, la visibilité, la modification, le remplacement, la continuité et la reconstruction.LES SIX TESTS DE SOUVERAINETÉUne preuve distincte pour chaque capacité1GOUVERNERQui décide, certifie et impose une correction ?Atout : émission, registre et rulebook publics.Angle mort : répartition précise entre les six BCN.2VOIRQui inspecte code, logs, modèleset sous-traitants ?Atout : standards et contrôle contractuel BCE.Angle mort : droits d’audit et chaîne de sous-traitance non publics.3MODIFIERL’Eurosystème peut-il corriger sans le titulaire ?Atout : droits complets publiés pour offline.Angle mort : quatre autres composants non vérifiables publiquement.4REMPLACERLe second fournisseur peut-ilreprendre la production ?Atout : deux accords par composant.Angle mort : délai, code, données, clés et bascule non démontrés.5CONTINUERQue reste-t-il sans store, réseauou secure element ?Atout : droit européen, deux lots réseau, cartes alternatives.Angle mort : accès matériel et parité opérationnelle.6RECONSTRUIRESources, builds, clés et compétences suffisent-ils ?Atout : références et SDK prévus dans le pilote.Angle mort : couverture production et exercice par une autre équipe.Le pilote doit mesurer la reprise après une défaillance.Cadre d’analyse l0g, fondé sur les contrats et l’architecture publique.
La souveraineté opérationnelle se mesure par une série de capacités vérifiables, indépendamment du siège social du fournisseur.

Gouverner

L’Eurosystème garde l’émission, le règlement, le rulebook et la certification générale.

Le point à publier davantage concerne la répartition du cœur entre les six banques centrales.

Voir

Les contrats donnent à la BCE des pouvoirs de contrôle.

Le public ne connaît pas le périmètre exact des audits de code, des logs, des modèles et des sous-traitants.

Modifier

La garantie offline est explicite.

Le niveau de droits sur les quatre autres composants demeure non vérifiable publiquement.

Remplacer

Deux fournisseurs sont classés.

Le délai de bascule, la compatibilité et le transfert des clés ne sont pas démontrés.

Continuer

Le droit européen ouvre le NFC et cherche à ouvrir le matériel.

La continuité sans store, sans secure element ou sans un opérateur réseau reste à tester.

Reconstruire

Le pilote prévoit des spécifications et certaines références.

Une reconstruction complète par une équipe différente n’est pas documentée.

Le pilote doit casser quelque chose

Le pilote de douze mois prévu à partir du second semestre 2027 doit tester les paiements P2P, le point de vente, l’e-commerce, l’application, le SDK, le funding, le defunding et l’offline avec 36 PSP et 19 banques centrales nationales.

La réussite fonctionnelle ne suffit pas.

Un pilote souverain doit provoquer des pannes contrôlées.

Retirer le premier fournisseur

Le second doit reprendre un composant dans un délai mesuré.

Le rapport doit publier :

  • préparation ;
  • transfert ;
  • données ;
  • clés ;
  • indisponibilité ;
  • corrections.

Repartir du code

Une nouvelle équipe doit reconstruire une version depuis :

  • sources ;
  • dépendances ;
  • documentation ;
  • scripts ;
  • secrets gérés par l’Eurosystème.

Perdre un gatekeeper

Le test doit simuler :

  • retrait d’un app store ;
  • secure element inaccessible ;
  • OS non supporté ;
  • fabricant qui abandonne un modèle.

Une carte ou un dispositif relais doit permettre la continuité.

Perdre un réseau

Le trafic doit basculer d’un lot NSP à l’autre, avec mesure de la latence, des erreurs et des métadonnées exposées.

Perdre un HSM

Les clés doivent être restaurées ou tournées sans casser les soldes ni les instruments.

Publier le résultat

La transparence utile ne demande pas de révéler un plan d’attaque exploitable.

Elle peut publier :

  • scénario ;
  • délai ;
  • objectif ;
  • résultat ;
  • écart ;
  • correctif.

Le pilote devrait mesurer la capacité de l’Europe à réparer et reprendre l’euro numérique après une défaillance.

Ce que les six volets ont établi

Cette enquête a commencé par une question comptable.

1. Un euro qui change de débiteur

Le premier volet a montré que la conversion ne change pas le nombre d’euros. Elle déplace la dette d’une banque commerciale vers l’Eurosystème.

2. Un plafond qui protège un modèle bancaire

Le deuxième volet a reconstruit les 699 milliards du scénario extrême. Le système tient dans le modèle parce que les banques remplacent les dépôts par des réserves, du marché ou du refinancement contre collatéral.

3. Une confidentialité fondée sur la séparation

Le troisième volet a suivi les données. La BCE ne devrait pas recevoir directement le nom dans les flux centraux, tandis que les PSP gardent l’identité et que les services communs manipulent des pseudonymes et métadonnées.

4. Une interdiction réelle, des pouvoirs distincts

Le quatrième volet a séparé monnaie programmable, paiement conditionnel, fraude, sanction et saisie. L’interdiction protège la fongibilité, pas l’absence de tout blocage juridique.

5. Une facture encore fragmentée

Le cinquième volet a montré que les chiffres publics couvrent des périmètres différents. Le modèle de rémunération déterminera qui supporte la distribution et si Wero bénéficie d’une infrastructure commune ou subit une duplication.

6. Une souveraineté à démontrer par la reprise

Ce dernier volet referme la boucle.

La monnaie peut être publique, confidentielle, non programmable et moins dépendante des schémas internationaux.

Ces propriétés n’assurent pas que la machine soit réparable sans son fournisseur.

Qui contrôle la machine ?

Le futur euro numérique prendrait la forme d’une infrastructure hybride.

Son cœur monétaire reste public.

Ses services spécialisés sont contractualisés auprès d’entreprises contrôlées dans l’Union.

Sa distribution repose sur les PSP.

Son usage mobile dépend en partie de plateformes et de matériels mondiaux.

Cette construction possède de vrais garde-fous :

  • émission publique ;
  • six banques centrales ;
  • deux accords par composant ;
  • exigences de contrôle européen ;
  • standards communs ;
  • droits forts publiés pour l’offline ;
  • intervention du droit de la concurrence et du DMA.

Elle conserve de vrais angles morts :

  • commandes effectivement passées ;
  • sous-traitants ;
  • clouds ;
  • garde des clés ;
  • droits de code pour quatre composants ;
  • délais de bascule ;
  • accès au secure element ;
  • attribution du réseau ;
  • répartition du cœur entre les six banques centrales.

La souveraineté opérationnelle repose sur une voie de sortie.

Une infrastructure est souveraine lorsque l’autorité qui en répond peut :

  • inspecter ;
  • corriger ;
  • migrer ;
  • révoquer ;
  • basculer ;
  • reconstruire.

La conclusion de cette enquête tient en une phrase :

La souveraineté opérationnelle se mesurera à la capacité de l’Eurosystème à reprendre la machine, changer ses opérateurs et continuer à servir les citoyens lorsqu’un fournisseur, un réseau ou un gatekeeper disparaît.

Sources et méthode

Ce volet repose principalement sur :

  1. BCE, sélection des fournisseurs.

  2. BCE, rapport de clôture de la phase de préparation.

  3. Marché Alias Lookup.

  4. Marché Risk and Fraud Management.

  5. Marché Application et SDK.

  6. Marché Offline.

  7. Marché SEPI.

  8. Marché NSP Connectivity.

  9. BCE, lettre sur Apple, NFC et secure element.

  10. Commission européenne, engagements NFC d’Apple.

  11. Conseil de l’Union européenne, article 33 et architecture.

  12. BCE, architecture fonctionnelle du pilote.

  13. Publicis Groupe, acquisition de Tremend.

  14. Fabrick, annonce relative à l’accord-cadre.

Les totaux de valeurs estimées et de plafonds sont des additions l0g des montants publiés dans les avis. Ils ne constituent pas des dépenses et ne sont pas additionnés au coût global de 1,3 milliard sans réconciliation de périmètre.

Limites

  • Les contrats complets et commandes spécifiques ne sont pas publics.
  • Les noms et fonctions des sous-traitants ne sont généralement pas publiés.
  • Les droits de code sont explicitement visibles dans l’avis offline, pas dans les quatre autres avis.
  • Les clouds, datacentres, clés, RTO, RPO et clauses de sortie ne sont pas publics.
  • Aucun résultat officiel du marché NSP n’a été identifié dans le corpus examiné.
  • La répartition précise des fonctions entre les six banques centrales n’est pas publique.
  • L’accès pratique et tarifaire au secure element reste à démontrer.

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 ..