Swift transporte des messages ; la blockchain transporte la valeur. Cette distinction technique est fondamentale. Swift reste le langage universel des banques : un réseau mondial de messagerie financière standardisée, conçu pour acheminer des instructions de paiement de manière fiable et sécurisée. Mais Swift n’a jamais déplacé un seul euro : il transporte l’instruction, tandis que le règlement final se fait ailleurs, sur des systèmes à règlement brut en temps réel (RTGS), des infrastructures de compensation ou via des banques correspondantes.
La technologie blockchain inverse cette logique. Un transfert de stablecoin ou de dépôt tokenisé ne se limite pas à transmettre une instruction : il inscrit et exécute le mouvement de valeur dans un registre partagé. Ici, « tokenisation » désigne la représentation du cash ou d’un actif sous forme de jeton sur un registre blockchain/Distributed ledger technology (DLT), à distinguer de la tokenisation de données (par exemple, le remplacement d’un numéro de carte par un token). Dans ce cadre, deux formes de « cash on-chain » coexistent : le stablecoin (un jeton indexé sur l’euro, adossé à des réserves) et le deposit token (un dépôt bancaire tokenisé, passif de la banque). Autrement dit, on passe d’un modèle où l’on « raconte » le paiement (messagerie) à un modèle où l’on réalise le paiement dans le registre. Le bénéfice ne vient donc pas d’un « nouveau produit », mais d’un changement de rail et de logique d’exécution.
Une nouvelle architecture
Ce cadrage évite un contresens : la tokenisation n’est pas un slogan, c’est une architecture. Elle rapproche l’écriture (qui détient quoi) et le règlement (quand et comment la valeur change de main). Sur un rail on-chain, une transaction validée met à jour l’état du registre ; des règles peuvent être exécutées par des smart contracts (contrats) qui s’exécutent automatiquement ; et l’infrastructure, plutôt que d’être rythmée par des fenêtres de traitement, peut fonctionner en continu.
Dans les rails traditionnels, l’état de la transaction est dispersé : un message part, un correspondant débite, un autre crédite, un système de règlement finalise, et l’industrie passe ensuite du temps à expliquer, rapprocher, corriger. Les progrès récents améliorent la visibilité, mais ne changent pas la nature du règlement : la finalité et la liquidité restent contraintes par des chaînes d’intermédiaires et des arrêtés de comptes ou cut-offs.
Un rail se juge à ses frictions. À ce stade, la question n’est plus « faut-il y aller ? », mais « sur quels flux, avec quelles garanties opérationnelles, et avec quel niveau d’interopérabilité ? ». Les rails off-chain ont déjà progressé (données mieux structurées, traçabilité, instantanéité domestique), mais des frictions demeurent : coordination multi-acteurs, exceptions et réconciliations, et surtout liquidité au mauvais endroit au mauvais moment. C’est sur ces points que le rail on-chain peut apporter une couche complémentaire, sans effacer l’existant, lorsque la programmabilité et le 24/7 créent un gain net.
Vers un registre programmable
À horizon dix ans, la tokenisation pourrait représenter des milliers de milliards d’actifs gérés sous forme de « registre programmable ». Le point clé n’est pas « tout sur blockchain », mais la bascule de segments précis : ceux où les frictions coûtent le plus, et où l’automatisation du règlement et de certains contrôles réduit le coût total d’exécution.
Cette bascule n’a de sens que si elle devient industrialisable. MiCA contribue à rendre le sujet opérable : un stablecoin euro régulé de type EMT peut servir de brique de règlement on-chain, et des prestataires agréés (Crypto Asset Service Provider, CASP) opèrent les services (conservation, transferts, échange, exécution) autour de ces actifs. L’enjeu n’est pas d’« adopter la blockchain », mais de construire un rail gouverné, conforme, résilient et raccordé au système d’information (SI).
En France, SG-Forge illustre l’approche « infrastructure » avec EUR CoinVertible (EURCV), conçu comme une brique de règlement en euro tokenisé pour des usages institutionnels.
À l’échelle européenne, la joint-venture Qivalis marque un changement de phase : BNP Paribas a rejoint un consortium de douze banques européennes pour porter un stablecoin euro, avec un objectif de lancement au second semestre 2026.
Même l’infrastructure historique évolue. Après un essai d’interopérabilité sur obligations tokenisées (DvP et événements de vie du titre) avec SG-Forge et BNP Paribas Securities Services, Swift indique vouloir ajouter un registre partagé (shared ledger) basé sur blockchain, pour des paiements transfrontaliers en temps réel, 24/7, en complément de la messagerie, des API et d’ISO 20022. Le scénario le plus probable combine off-chain et on-chain, à condition d’éviter le « silo on-chain » et de penser l’interconnexion de bout en bout.
Liquidité, orchestration et données :
trois sujets clefs
L’hybridation des rails ne se résume pas à « connecter une blockchain ». Elle impose de traiter trois sujets d’infrastructure, souvent invisibles dans les démonstrations.
Premier sujet : la liquidité. Un rail on-chain n’apporte de valeur que si la liquidité y est disponible au bon moment, au bon endroit, avec des règles de gestion claires : alimentation et retraits, limites, gestion du 24/7, mécanismes de contrôle en cas d’incident. C’est la différence entre un transfert « technique » et un rail « opérable ».
Deuxième sujet : l’orchestration. Les transactions financières ne sont pas uniquement des mouvements de fonds : ce sont des chaînes d’événements (contrôles, statuts, rejets, retours, sanctions, exceptions) qui doivent être pilotées de bout en bout. Le registre on-chain peut automatiser certaines règles, mais l’industrie doit encore définir ce qui relève du code, ce qui relève de l’opérationnel, et comment les exceptions sont gérées sans casser le Straight Through Processing (STP).
Troisième sujet : les données et l’intégration SI. ISO 20022 reste une couche de données et de messagerie : dans un modèle hybride, on associe les champs utiles à des transactions et événements on-chain, cependant que l’identité/les contrôles (KYC/AML, sanctions) restent portés par des acteurs régulés. Sur les réseaux publics, les transactions sont signées et vérifiables (preuve), pas chiffrées par défaut. Un rail on-chain gagne quand il s’insère proprement dans cette chaîne de valeur, pas lorsqu’il la contourne.
Deux cas d’usage rendent ce futur concret. D’abord la trésorerie 24/7 : exécuter certains transferts intra-groupe et paiements conditionnels en continu, avec des données structurées intégrées au flux, réduit les frictions et les interventions manuelles. Ensuite le règlement‑livraison atomique (DvP) sur actifs tokenisés : une logique « tout ou rien » exécute livraison et paiement dans une seule opération indivisible ; si l’un échoue, l’autre ne s’exécute pas.
La frontière entre une démonstration et une infrastructure reste exigeante : résilience 24/7, gouvernance des accès et des clés, gestion d’incidents, intégration SI (référentiels, comptabilité, reporting) et interopérabilité entre rails. ISO 20022 n’est pas un détail : c’est le carburant de l’automatisation ; les rails on-chain réussiront en s’y raccordant proprement.
Au fond, la question n’est pas « blockchain ou pas », mais où placer le registre de référence. Quand la valeur circule sur un registre partagé, on réduit certaines ambiguïtés d’état : payé/non payé, livré/non livré, en attente/en échec. Cette clarté permet d’industrialiser des contrôles et des statuts, et de rapprocher plus vite ce qui, aujourd’hui, se reconstruit a posteriori, par des échanges entre back-offices. Le rail on-chain n’est donc pas un raccourci : c’est une manière différente d’aligner exécution et preuve.
La conclusion est simple : la tokenisation est une couche de rail qui complète l’infrastructure off-chain lorsque le gain est tangible (24/7, automatisation, réduction des frictions de règlement). L’innovation sera souvent invisible pour l’utilisateur final, mais décisive pour la performance opérationnelle à l’échelle.
