XRP Ledger Testé Pour Authentifier Les Statistiques Officielles

Et si la confiance dans un tableau de chômage, un indice de prix ou une série de réserves monétaires ne reposait plus seulement sur le site qui l’héberge, mais sur une empreinte impossible à falsifier sans laisser de trace ? C’est précisément l’hypothèse qu’un groupe de chercheurs affiliés à la Banque des règlements internationaux a voulu mettre à l’épreuve. Le 2 septembre 2026, un document de travail a décrit un prototype capable d’ancrer l’origine et l’intégrité de fichiers statistiques officiels sur le XRP Ledger, plus précisément sur son réseau d’essai. L’expérience ne dit pas que la BRI a « adopté » cette infrastructure. Elle dit autre chose, plus discret et plus intéressant : on peut désormais imaginer un cachet public, lisible par une machine, qui confirme qu’un fichier n’a pas bougé depuis sa publication.

Une expérience de confiance, pas une adoption institutionnelle

Le premier réflexe, dans l’univers des actifs numériques, consiste à transformer toute mention d’un grand nom en signal d’achat. Ici, ce réflexe serait un piège. Les auteurs précisent que leurs conclusions leur appartiennent et qu’elles ne reflètent pas nécessairement la position institutionnelle de la BRI. Le logiciel n’est pas un service de production. Il n’est pas maintenu. Il n’établit aucun partenariat avec l’éditeur du protocole. Il n’invite personne à détenir l’actif natif du réseau. Ce que le papier documente, c’est un banc d’essai méthodique : prendre un standard déjà utilisé par les institutions statistiques, calculer une empreinte, l’écrire dans une transaction, puis vérifier qu’un destinataire peut reconstruire la même empreinte en quelques secondes.

Cette nuance change tout. Elle replace le sujet là où il doit vivre : du côté de l’infrastructure de confiance, pas du côté de la spéculation. Les statistiques officielles circulent aujourd’hui par sites web, bases de données et flux automatisés. Le destinataire doit croire que le fichier téléchargé est bien celui que l’éditeur a voulu diffuser, et qu’aucun octet n’a été altéré en chemin. Le prototype ne prétend pas juger si le chiffre de l’inflation est « juste ». Il se contente d’une promesse plus modeste et plus vérifiable : ce fichier-là correspond à la version reliée à l’enregistrement initial.

Pourquoi les statistiques officielles ont un problème d’authenticité

Les instituts nationaux, les banques centrales et les organisations internationales produisent des séries que des milliers d’acteurs réutilisent : ministères, journalistes, chercheurs, modèles de prévision, agents logiciels. La chaîne de distribution est longue. Un fichier quitte un serveur, passe par un miroir, un tableau de bord, une API, parfois un tableur recopié à la main. À chaque étape, une erreur de version, une coupure de mise à jour ou une substitution malveillante peut s’introduire. Le destinataire final voit un tableau propre. Il n’a souvent aucun moyen simple de savoir s’il s’agit encore de la version authentique.

Les signatures numériques classiques existent déjà. Les horodatages aussi. Les portails institutionnels publient des sommes de contrôle. Rien de tout cela n’est nouveau. Ce qui change dans le prototype, c’est l’idée d’un registre public, indépendant de l’éditeur, où l’empreinte devient consultable par n’importe quel vérificateur sans demander une autorisation supplémentaire au producteur des données. Le destinataire n’a plus seulement à « faire confiance au site ». Il peut comparer deux objets : le fichier qu’il a sous les yeux et l’enregistrement ancré dans le registre.

Cette architecture répond à une anxiété contemporaine. Les flux automatiques se multiplient. Les agents d’intelligence artificielle piochent des séries sans qu’un humain ouvre le fichier. Une statistique altérée peut alors se propager dans des modèles, des articles générés, des tableaux de bord. Un cachet machine-lisible n’élimine pas le mensonge statistique à la source. Il réduit le risque plus banal, et déjà grave, d’une copie corrompue qui circule sous le nom d’une institution.

Le standard SDMX comme point d’entrée naturel

Les chercheurs n’ont pas inventé un format maison. Ils se sont branchés sur le Statistical Data and Metadata eXchange, plus connu sous le sigle SDMX. Ce standard international sert déjà à échanger des informations statistiques entre organisations, dont la BRI. Choisir SDMX n’est pas un détail cosmétique. C’est une décision de conception : le prototype s’insère dans une tuyauterie existante plutôt que d’exiger que les instituts réécrivent leurs pipelines.

Concrètement, avant publication, le logiciel convertit un fichier SDMX vers un format normalisé, puis calcule une empreinte. Cette empreinte n’est pas le tableau. C’est une représentation cryptographique compacte du tableau. Le destinataire qui reçoit le fichier peut refaire le calcul et comparer le résultat avec ce qui a été inscrit dans la transaction. Si les deux coïncident, le contenu n’a pas changé. S’ils divergent, quelque chose a bougé, même d’un seul caractère.

Le message SDMX ne se contente pas de transporter les données. Dans le prototype, il emporte aussi la référence de transaction, l’ordre des feuilles d’un arbre de hachage et l’identifiant nécessaire pour relier le fichier à l’adresse de l’éditeur. Le vérificateur n’a pas à bricoler dix outils. Il dispose, dans le même objet, de ce qu’il faut pour localiser l’enregistrement et clore la comparaison.

Le registre ne dit pas si le chiffre est vrai. Il dit seulement que le fichier vérifié correspond à la version reliée à l’enregistrement d’origine.

Une empreinte, pas un entrepôt de chiffres

Le choix de ne pas publier les statistiques elles-mêmes sur la chaîne n’est pas un compromis faible. C’est le cœur du dispositif. Les séries officielles peuvent être volumineuses, révisables, parfois sensibles dans leur combinaison. Les placer en clair sur un registre public poserait des questions de coût, de confidentialité, de gouvernance et de lisibilité. L’empreinte contourne ces obstacles. Elle est courte. Elle ne révèle pas le contenu. Elle change radicalement dès qu’on touche au fichier source.

L’algorithme retenu est un hachage SHA3-512. On peut le décrire comme une empreinte digitale : deux fichiers identiques donnent le même résultat ; deux fichiers presque identiques donnent des résultats sans rapport visible. Cette propriété, banale en cryptographie, devient précieuse dès qu’on veut détecter une altération minuscule dans un tableau que personne n’a le temps de relire cellule par cellule.

Le prototype va plus loin qu’un hachage unique de fichier. Il permet de vérifier l’ensemble du document ou seulement certaines séries. Lorsque plusieurs séries sont concernées, leurs empreintes sont combinées dans une racine de Merkle. Une seule transaction peut alors servir de point d’ancrage à plusieurs composantes, chacune restant vérifiable séparément. C’est une économie d’écriture autant qu’une élégance technique. On n’encombre pas le registre d’une transaction par ligne de tableau.

Comment la vérification se déroule concrètement

Le scénario imaginé par les chercheurs est linéaire. Un éditeur prépare son fichier SDMX. Le logiciel normalise le contenu, calcule les empreintes, construit au besoin la racine de Merkle, puis ancre cette racine via une transaction sur le Devnet du XRP Ledger. Une référence vers cette transaction est ensuite insérée dans le fichier lui-même. Le destinataire télécharge le fichier comme d’habitude. Il recalcule l’empreinte. Il interroge le registre. Il compare.

Deux durées ont été mesurées dans des conditions contrôlées. La publication, c’est-à-dire la création et la confirmation de l’enregistrement, affichait une latence médiane d’environ trois à cinq secondes. La vérification, recalcul plus comparaison, prenait environ une à deux secondes. Ces chiffres sont utiles. Ils ne sont pas des garanties de production. Ils décrivent un banc d’essai sur un réseau d’expérimentation, pas le réseau public utilisé pour des transactions réelles.

Le Devnet n’est pas un théâtre mineur. Il sert précisément à cela : tester sans mobiliser un actif qui a une valeur de marché. On y obtient des jetons d’essai via un robinet. L’activité, les exigences de fiabilité et l’environnement d’exploitation diffèrent du réseau principal. Présenter les trois à cinq secondes comme une performance institutionnelle serait donc prématuré. Présenter ces durées comme la preuve qu’un ancrage n’est pas nécessairement lent, en revanche, est légitime.

Pourquoi ce registre plutôt qu’un autre

Les auteurs indiquent avoir retenu le XRP Ledger en partie pour la confirmation relativement rapide des transactions et pour le faible coût d’écriture. Ces deux arguments sont cohérents avec l’usage visé. Un institut qui publie souvent n’a pas besoin d’attendre une finalité longue, ni de payer un ancrage prohibitif à chaque livraison. Cela ne signifie pas que le protocole soit le seul candidat possible. Le papier ne compare pas directement cette infrastructure à Ethereum, à Solana, à une base permissionnée ou à un service classique d’horodatage numérique.

L’absence de comparaison est un aveu de modestie méthodologique, pas un défaut caché. Une preuve de concept cherche d’abord à montrer qu’un enchaînement fonctionne de bout en bout. Elle ne prétend pas classer les réseaux. Quiconque voudrait en faire un argument concurrentiel devrait donc ajouter ce que le document ne fournit pas : des mesures homologues, sur des charges comparables, avec les mêmes fichiers, les mêmes tailles d’empreinte et les mêmes exigences d’identité.

Le code a été déposé dans un dépôt public lié à la BRI. La documentation le décrit comme un prototype expérimental, ni destiné à la production, ni activement maintenu. Cette phrase devrait figurer en tête de toute reprise du sujet. Un dépôt ouvert invite à la lecture, à la critique, éventuellement à la reprise. Il n’ouvre pas un guichet de certification pour les instituts nationaux.

L’intégrité ne suffit pas : il faut aussi l’identité

Un hash valide ne dit rien sur l’auteur. Un acteur malveillant pourrait fabriquer un fichier frauduleux, calculer une empreinte parfaitement cohérente, puis l’écrire depuis une adresse sans rapport avec l’institut. Le destinataire verrait alors une correspondance technique et croirait, à tort, tenir un document officiel. Les chercheurs ont donc ajouté une couche d’identité.

Le prototype s’appuie sur une Verifiable Credential au sens du W3C, signée par une clé d’identité associée à l’adresse de l’éditeur sur le registre. Le destinataire peut vérifier que la partie qui publie le fichier contrôle bien l’adresse reconnue. La vérification porte dès lors sur deux questions distinctes : le contenu a-t-il changé, et l’émetteur est-il bien celui qu’on croit ? Sans la seconde, la première devient un cachet orphelin.

Cette combinaison n’élimine pas tous les risques. Une clé compromise resterait un cauchemar opérationnel. Une révocation mal gérée laisserait des enregistrements anciens difficiles à interpréter. Un institut devrait définir qui détient la clé, comment on la stocke, comment on la remplace, comment on signale une publication illégitime. Le prototype montre le principe. Il ne livre pas la politique de sécurité.

Ce que le système ne promet pas

Il faut insister, parce que le sujet s’y prête. Le XRP Ledger, dans cette expérience, n’établit pas l’exactitude économique d’une série. Il n’arbitre pas un débat de méthode. Il n’empêche pas un institut de publier une estimation ensuite révisée. Il n’apporte pas non plus une preuve que le fichier a été « vu » par la BRI en tant qu’institution. Il apporte une preuve d’intégrité et, grâce à la credentielle, une preuve d’attribution à une adresse reconnue.

Cette limite n’est pas un échec. C’est la frontière honnête d’un outil de traçabilité. Confondre authenticité du fichier et vérité du chiffre reviendrait à croire qu’un cachet notarié transforme une estimation en loi de la nature. Les statisticiens savent que les séries bougent. Les réviseurs savent que les premières publications sont souvent provisoires. Un bon système de vérification doit donc vivre avec la révision, pas faire semblant qu’elle n’existe pas.

Les auteurs évoquent aussi des extensions possibles, sans les avoir implémentées comme service. Les preuves à divulgation nulle de connaissance pourraient permettre de démontrer certains faits sur des données restreintes sans exposer le jeu complet. Des agents logiciels pourraient, de leur côté, refuser automatiquement un fichier altéré ou mal attribué. Ce sont des pistes. Le dépôt publié reste un code d’expérience, pas une offre destinée aux banques centrales, aux instituts nationaux ou aux entreprises d’intelligence artificielle.

Utiliser le registre n’implique pas d’adopter l’actif

Chaque enregistrement onchain exige une transaction. Une transaction, sur ce réseau, implique des frais. On pourrait en déduire trop vite que le cas d’usage crée une demande massive pour l’actif natif. Le prototype invite à plus de sobriété. Il n’utilise pas cet actif pour un paiement, une liquidité, un règlement ou un transfert transfrontière. Il s’en sert seulement comme carburant minuscule d’un ancrage.

Sur le réseau principal, le montant dépendrait des conditions du moment et de la méthode de publication. Surtout, un éditeur peut regrouper plusieurs séries derrière une seule racine de Merkle. Le nombre de transactions n’augmente donc pas linéairement avec le nombre de tableaux. Un institut productif pourrait ancrer beaucoup de contenu avec peu d’écritures. L’usage du registre et la demande pour l’actif ne sont pas la même histoire.

Cette distinction mérite d’être répétée dans un climat où chaque expérience technique est lue comme un catalyseur de cours. Un ancrage de métadonnées n’est pas un corridor de liquidité. Ce n’est pas non plus un argument pour conclure que les applications non financières du réseau seraient soudain devenues centrales. C’est un élargissement du champ des essais : au-delà des paiements et des actifs tokenisés, on teste aussi la notarisation de fichiers publics.

Le réseau autour, sans en faire un argument de vente

Le XRP Ledger continue par ailleurs d’évoluer sur un autre front, institutionnel et financier : marchés permissionnés, propositions de prêt natif, émission d’actifs. Ces chantiers n’ont pas de lien opérationnel avec le prototype statistique. Les mélanger dans une même phrase d’enthousiasme brouille les genres. Un outil de vérification de fichiers n’a pas besoin d’un carnet d’ordres. Un carnet d’ordres n’a pas besoin d’un hash SDMX.

Des travaux distincts ont aussi observé une activité de marché plus concentrée sur le registre, avec une hausse marquée des volumes de carnet d’ordres et une baisse du nombre de traders quotidiens sur un trimestre donné. Là encore, l’information vaut comme contexte d’écosystème, pas comme preuve que le prototype statistique ira en production. Deux dynamiques peuvent cohabiter sur la même infrastructure sans que l’une valide l’autre.

Le lecteur a donc intérêt à tenir trois plans séparés. Premier plan : une expérience de vérification documentaire. Deuxième plan : des évolutions financières du protocole. Troisième plan : la microstructure de marché. Les confondre produit des titres spectaculaires et des analyses pauvres.

Le vrai obstacle : vivre avec les révisions

Les statistiques officielles ne sont pas des tablettes gravées. Elles sont révisées quand de nouvelles informations arrivent, quand une saisonnalité est réestimée, quand une erreur est corrigée. Un registre permanent fixe un enregistrement. Il ne dit pas, à lui seul, si cet enregistrement reste la version courante. C’est le nœud le plus délicat d’un éventuel passage en production.

Un système mature devrait distinguer une révision légitime d’une altération clandestine. Il devrait indiquer clairement quelle version est actuelle, laquelle est historique, laquelle a été retirée. Il devrait éviter qu’un lecteur croie que la première publication demeure la référence simplement parce qu’elle a été ancrée en premier. La permanence, ici, est à la fois une force et un piège. Elle conserve la trace. Elle peut aussi fossiliser un malentendu.

Les instituts devraient aussi décider s’ils s’appuient uniquement sur un registre public, s’ils conservent une infrastructure parallèle, ou s’ils combinent l’ancrage avec des signatures déjà en place. Les règles de confidentialité limiteraient les métadonnées exposées dans une transaction visible de tous. Un identifiant trop parlant, une note trop précise, une structure trop révélatrice pourraient entrer en tension avec des politiques de publication. Le prototype n’arbitre pas ces choix. Il les rend visibles.

Gouvernance des clés, pannes et corrections

Avant qu’un producteur officiel s’appuie sur un tel dispositif, il faudrait beaucoup plus qu’un dépôt expérimental. Il faudrait une politique de clés : qui les crée, qui les utilise, comment on les sauvegarde, comment on réagit à une compromission. Il faudrait une doctrine des échecs de transaction : que fait-on si l’écriture n’est pas confirmée au moment où le communiqué part ? Il faudrait une procédure de correction : comment signaler qu’un fichier déjà ancré doit être remplacé sans donner l’impression d’un déni.

Ces questions sont moins spectaculaires qu’un temps de confirmation de quelques secondes. Elles sont pourtant décisives. Une institution publique n’a pas le droit de traiter un cachet cryptographique comme un gadget. Si le cachet devient une référence, son absence, son retard ou son ambiguïté deviennent des incidents de communication. Le prototype, en l’état, n’offre pas ce mode d’emploi opérationnel.

On peut même dire que la réussite technique du banc d’essai rend ces questions plus urgentes, pas moins. Dès qu’un enchaînement « marche » en laboratoire, la tentation est de le raconter comme s’il était prêt. Or un logiciel non maintenu, documenté comme preuve de concept, n’est pas un socle de production. Le dire clairement n’enlève rien à l’intérêt de l’expérience. Cela empêche seulement une inflation narrative.

Des agents automatiques et des preuves plus sélectives

Les chercheurs soulignent un usage potentiel du côté des systèmes automatisés. De plus en plus de logiciels récupèrent des statistiques sans qu’une personne contrôle chaque source. Un enregistrement de vérification lisible par machine permettrait à un agent de rejeter un fichier modifié ou mal attribué. Dans un monde saturé de reprises automatiques, ce filtre a plus de valeur que dans un monde où chaque tableau était ouvert par un analyste patient.

La piste des preuves à divulgation nulle de connaissance va dans une autre direction : démontrer un fait ciblé sans publier l’ensemble. Une organisation pourrait, par exemple, attester qu’une série respecte une contrainte ou qu’un sous-ensemble n’a pas changé, tout en gardant le reste hors de vue. Le papier présente cela comme une évolution possible de l’architecture, non comme une fonction livrée.

Ces deux extensions éclairent l’intention générale. Il ne s’agit pas seulement de rassurer un lecteur humain. Il s’agit de préparer un environnement où des machines s’échangent des objets statistiques et ont besoin d’un critère binaire : acceptable ou non. Le registre, ici, n’est plus une vitrine. C’est un témoin que l’on interroge à grande fréquence.

Au-delà du SDMX, d’autres formats pourraient suivre

Les auteurs affirment que l’approche n’est pas prisonnière du SDMX. Elle pourrait être adaptée à d’autres formats structurés, notamment le XBRL, déjà utilisé par des entreprises et des régulateurs pour le reporting financier. L’idée reste la même : normaliser, empreindre, ancrer, vérifier. Seuls changent le schéma, les métadonnées et les habitudes de publication.

Si l’on pousse le raisonnement, le champ s’élargit à tout document dont l’intégrité compte davantage que la mise en ligne spectaculaire : rapports prudentiels, jeux de données ouvertes, indicateurs climatiques institutionnels, publications de méthodologie. Encore une fois, le prototype ne déploie rien de tout cela. Il montre qu’une fois le principe admis, le format d’entrée devient un détail d’ingénierie.

Aucun calendrier de mise en œuvre n’est fourni. Le dépôt indique que le logiciel n’est pas maintenu. Aucune annonce n’indique que la BRI s’apprête à doter ses publications statistiques officielles de ce cachet. Le résultat vérifié est donc plus étroit que certaines lectures enflammées : des chercheurs affiliés ont montré qu’un système expérimental pouvait, sur le Devnet, authentifier des fichiers en quelques secondes dans des conditions contrôlées.

Ce que cette démonstration change vraiment

Elle change le vocabulaire utile. On ne parle plus seulement de « mettre des données sur la blockchain », formule vague et souvent inexacte. On parle d’ancrer une preuve d’intégrité, de relier cette preuve à une identité, de laisser le contenu utile hors chaîne, de rendre la vérification assez rapide pour qu’elle entre dans un flux de publication. Ce vocabulaire est plus pauvre en rêves et plus riche en ingénierie.

Elle change aussi le critère de lecture médiatique. La question intéressante n’est pas « tel actif va-t-il exploser parce qu’une institution a été citée ». La question intéressante est : les producteurs de statistiques publiques ont-ils un problème d’authenticité assez concret pour justifier un registre indépendant, et ce registre apporte-t-il quelque chose que les signatures existantes ne donnent pas déjà ? Le prototype répond à la première moitié par l’affirmative, à la seconde par un « peut-être, à condition de traiter l’identité, la révision et la gouvernance ».

Enfin, elle rappelle qu’un réseau public peut servir à autre chose qu’à déplacer de la valeur. Servir n’est pas convaincre. Une démonstration n’est pas une politique. Mais refuser de voir cet élargissement d’usage reviendrait à lire le papier avec les lunettes d’hier, celles qui ne reconnaissent un protocole que lorsqu’il règle un paiement.

Une chronologie mentale pour ne pas se tromper d’étape

Il est tentant de placer cette expérience dans une lignée héroïque : d’abord les paiements, ensuite la tokenisation, enfin la confiance documentaire. Cette lignée est trop lisse. Les institutions testent beaucoup de choses en parallèle, abandonnent davantage encore, et publient des documents de travail précisément pour exposer une idée sans s’y lier. Le bon ordre mental est plus humble.

Première étape : un problème documenté, celui de l’authenticité des fichiers qui circulent. Deuxième étape : un assemblage technique qui relie un standard statistique, un hachage, un arbre de Merkle, une transaction et une credentielle. Troisième étape : des mesures de latence sur un réseau d’essai. Quatrième étape, encore absente : un pilote réel, avec des clés institutionnelles, des révisions, des pannes et une équipe responsable. Tant que la quatrième étape n’existe pas, le récit doit s’arrêter à la troisième.

Cette discipline de lecture protège autant les sceptiques que les enthousiastes. Les premiers évitent de déclarer l’expérience nulle parce qu’elle n’est pas un déploiement. Les seconds évitent de la déclarer historique parce qu’un sigle prestigieux apparaît dans un en-tête. Entre les deux se trouve le territoire utile : une preuve de faisabilité étroite, claire, reproductible en principe, et encore loin des contraintes d’un institut qui publie tous les mois sous le feu des marchés.

Ce que le grand public devrait retenir sans jargon

Imaginez un communiqué statistique comme une photographie. Le prototype ne met pas la photographie dans un coffre public. Il met l’empreinte de la photographie dans un carnet que tout le monde peut consulter. Si quelqu’un recadre l’image, l’empreinte ne correspond plus. Si quelqu’un prétend être le photographe sans détenir la clé reconnue, la credentielle ne passe pas. Voilà, dépouillé de sigles, le geste technique.

Ce geste ne rend pas la photographie plus belle. Il ne dit pas si le paysage était vraiment ensoleillé. Il dit seulement que la copie que vous tenez est la même que celle déposée au moment de la publication, et que le déposant contrôlait l’identité annoncée. Dans un débat public saturé de captures d’écran, de fichiers recyclés et de tableaux sortis de leur contexte, cette modestie a plus de valeur qu’une promesse de vérité universelle.

Elle a aussi une limite pédagogique. Beaucoup de lecteurs entendront « registre public » et comprendront « les chiffres sont désormais dans la chaîne ». Il faudra répéter, encore, que non. Les chiffres restent là où ils sont déjà : sur les portails, dans les bases, dans les flux. Le registre ne garde qu’un sceau. Confondre le sceau et le document, c’est précisément ce que le prototype cherche à éviter.

Les questions qui resteront ouvertes après le papier

Qui devrait opérer un tel service s’il devenait réel ? L’éditeur statistique lui-même, un opérateur mutualisé, un consortium d’instituts ? Comment traiter les publications d’urgence, quand le temps de relecture humaine est déjà trop court pour ajouter une couche d’ancrage ? Que faire des archives anciennes, produites avant le dispositif, que l’on voudrait néanmoins authentifier rétroactivement ? Comment expliquer au public qu’une série ancrée hier n’est plus la série de référence aujourd’hui ?

D’autres questions touchent au pluralisme technique. Faut-il dépendre d’un seul registre public ? Faut-il ancrer la même empreinte en plusieurs lieux pour réduire le risque de dépendance ? Faut-il conserver un horodatage classique en parallèle, au cas où l’interprétation d’une transaction deviendrait litigieuse ? Le prototype n’a pas à répondre à tout. Un décideur public, lui, n’a pas le droit d’ignorer ces points.

Reste enfin la question culturelle. Les instituts statistiques ont construit leur autorité sur la méthode, l’indépendance et la répétition d’un rituel de publication. Un cachet cryptographique peut renforcer ce rituel. Il peut aussi, mal expliqué, donner l’illusion qu’une empreinte remplace le travail de qualité. La technique doit rester un auxiliaire de la confiance, pas un substitut à la compétence statistique.

Une conclusion volontairement étroite

Le 2 septembre 2026, un document de travail a décrit un prototype qui relie le standard SDMX, un hachage SHA3-512, une racine de Merkle, une transaction sur le Devnet du XRP Ledger et une credentielle d’identité. Dans des tests contrôlés, publier prenait quelques secondes, vérifier un peu moins. Le logiciel est public, expérimental, non maintenu. Les auteurs ne parlent pas au nom d’une doctrine institutionnelle. L’expérience n’est ni un partenariat, ni un signal d’investissement, ni une mise en production.

Elle est pourtant plus qu’une anecdote. Elle montre qu’on peut concevoir un cachet public pour des fichiers officiels sans exposer les fichiers eux-mêmes, sans exiger que le destinataire fasse confiance au seul site de téléchargement, et sans transformer le registre en entrepôt statistique. Elle montre aussi que la difficulté réelle commence après la démonstration : clés, révisions, pannes, confidentialité, gouvernance, pédagogie.

Ceux qui chercheront dans cette affaire une consécration verront trop large. Ceux qui n’y verront qu’un gadget verront trop court. Entre les deux, il reste un objet rare dans le débat public sur les registres distribués : une expérience précise, bornée, lisible, qui traite la confiance comme un problème d’ingénierie plutôt que comme un slogan. C’est déjà beaucoup. Ce n’est pas encore une infrastructure. Et c’est exactement ainsi qu’il faut le raconter.