Une banque construit son infrastructure blockchain. Une autre lance son propre réseau. Une troisième prépare ses dépôts tokenisés.
Les ports se modernisent. Mais les bateaux peuvent-ils passer de l’un à l’autre ?
Les dépôts tokenisés peuvent rendre la monnaie bancaire plus programmable. Leur intérêt dépend aussi de leur capacité à fonctionner entre des systèmes différents. Sans cette connexion, la finance on-chain risque de reproduire des silos familiers, simplement équipés de registres plus récents.
Un dollar enregistré par la banque A ne devient pas automatiquement un dollar utilisable chez la banque B. Entre les deux, il faut transmettre des informations, vérifier les autorisations, coordonner les écritures et régler les obligations financières.
C’est dans cette discussion que Cosmos et IBC deviennent intéressants : construire des réseaux personnalisés, capables de communiquer sans devoir tous adopter exactement la même infrastructure.
Encore faut-il comprendre ce que cette interopérabilité permet — et ce qu’elle ne résout pas à elle seule.
Qu’est-ce qu’un dépôt tokenisé ?
Un dépôt tokenisé est un dépôt bancaire représenté ou enregistré sur un registre distribué, selon l’architecture retenue.
Le point central est sa nature financière : il constitue une créance sur la banque émettrice, inscrite à son passif. La technologie utilisée pour tenir le registre ne transforme pas cette créance en un actif sans émetteur ni risque.
La supervision bancaire européenne décrit ainsi les dépôts tokenisés comme des dépôts enregistrés sur un registre distribué plutôt que sur un registre centralisé traditionnel. Elle souligne leur potentiel pour les paiements programmables et certaines opérations sur titres.
L’image la plus simple : le dépôt reste dans la maison bancaire, mais une partie de ses opérations emprunte de nouveaux rails.
Que peut apporter la tokenisation d’un dépôt ?
Selon le système déployé, elle peut permettre :
- d’automatiser certaines conditions de paiement ;
- de rapprocher paiement et transfert d’un actif ;
- de réduire les rapprochements entre systèmes ;
- d’améliorer la visibilité sur une opération ;
- de gérer plus finement certains mouvements de liquidité ;
- d’étendre les plages de fonctionnement de certains services.
Ces bénéfices demandent une intégration réelle avec la banque, ses contrôles et ses infrastructures de règlement.
Une blockchain disponible en permanence ne rend pas automatiquement tous les services bancaires disponibles en permanence.
Dépôt tokenisé, stablecoin et monnaie de banque centrale : quelles différences ?
Ces instruments peuvent utiliser des technologies proches, tout en représentant des engagements différents.
| Instrument | Ce qu’il représente | Point à examiner |
|---|---|---|
| Dépôt bancaire tokenisé | Une créance sur une banque commerciale | Conditions du dépôt, transfert, remboursement et protections applicables |
| Stablecoin | Un token visant à maintenir une valeur de référence | Émetteur ou mécanisme, réserves éventuelles, droits de rachat et risques |
| Monnaie de banque centrale tokenisée | Une créance sur une banque centrale, dans le dispositif concerné | Participants autorisés et rôle dans le règlement |
Pour les stablecoins adossés à une monnaie, les conditions de réserve et de remboursement comptent particulièrement. Tous les stablecoins ne reposent toutefois pas sur le même modèle.
La différence ne se résume donc pas à “banque contre entreprise crypto”. Il faut regarder la nature de la créance, les droits du détenteur et la manière dont le paiement est réglé.
Un bulletin de la Banque des règlements internationaux distingue notamment les instruments qui circulent comme des titres au porteur des dépôts tokenisés dont le paiement s’appuie sur un règlement en monnaie de banque centrale.
La tokenisation ne crée pas automatiquement une garantie
Le mot « bancaire » ne suffit pas à déterminer les protections d’un produit.
Leur application dépend notamment du statut juridique de l’instrument, de la juridiction, du détenteur et des conditions du dispositif.
Changer le registre ne supprime ni le risque de crédit de la banque ni les questions de liquidité et de remboursement.
Le problème des « cash islands » : des îles de liquidité
Imaginons trois établissements.
La banque A dispose de son registre, de ses clients autorisés et de ses contrôles. La banque B fonctionne sur une autre infrastructure. La banque C participe à un consortium doté de ses propres règles.
Chacun peut avoir modernisé ses opérations internes.
Mais que se passe-t-il lorsqu’un client de A veut payer un client de B ?
Si les réseaux ne savent pas communiquer, il faut ajouter des connexions spécifiques, des conversions, des procédures de rapprochement ou des étapes manuelles.
Les nouvelles infrastructures reproduisent alors une ancienne difficulté : la valeur fonctionne dans un périmètre, mais circule difficilement au-delà.
Cosmos utilise cette idée de fragmentation dans son analyse consacrée à l’interopérabilité des dépôts tokenisés.
Les registres peuvent être connectés sans que les systèmes se comprennent
Une connexion technique ne suffit pas toujours.
Deux banques doivent aussi s’accorder sur le sens des informations échangées :
- qui est le bénéficiaire ;
- quelle devise est utilisée ;
- quel instrument est transféré ;
- quelles autorisations sont nécessaires ;
- quand l’opération est considérée comme terminée ;
- comment traiter une erreur.
C’est la différence entre relier deux téléphones et parler une langue commune.
Un message reçu correctement peut encore être inutilisable si les deux systèmes ne lui donnent pas le même sens.
Un paiement entre deux banques : que faut-il réellement coordonner ?
Prenons un exemple simplifié.
Alice est cliente de la banque A. Elle veut payer 1 000 euros à Benoît, client de la banque B.
Dans le système bancaire, Benoît n’acquiert pas nécessairement une créance sur la banque d’Alice. Sa propre banque crédite son compte, tandis que les établissements règlent leurs obligations par les mécanismes applicables.
La BRI rappelle que les paiements interbancaires reposent sur des mises à jour coordonnées de comptes et, dans le cadre décrit, sur un règlement final en réserves de banque centrale.
Avec des dépôts tokenisés, plusieurs modèles restent possibles
L’opération peut notamment nécessiter :
- La vérification des participants et des droits de transfert.
- La réservation ou le débit du montant chez A.
- La transmission d’une instruction vérifiable.
- Le règlement entre les établissements.
- Le crédit correspondant chez B.
- Le rapprochement et la confirmation de l’ensemble.
Le détail dépend de l’architecture choisie.
Certains dispositifs peuvent aussi organiser la circulation d’une créance sur une banque entre détenteurs autorisés. Il ne faut donc pas présenter tous les dépôts tokenisés comme un seul modèle universel.
Déplacer un token, transmettre une instruction et régler une obligation bancaire sont trois opérations liées, mais différentes.
C’est précisément pour cela que l’interopérabilité financière dépasse la construction d’un pont entre deux blockchains.
Pourquoi Cosmos est pertinent pour les dépôts tokenisés
L’approche Cosmos repose sur des réseaux personnalisables plutôt que sur l’obligation de réunir toutes les applications sur une seule chaîne.
Une organisation peut adapter son registre à ses contraintes, puis mettre en place les connexions nécessaires avec d’autres environnements.
Dans un contexte bancaire, cela peut concerner :
- les acteurs autorisés à participer ;
- les règles de validation ;
- les permissions ;
- la gouvernance ;
- les interfaces avec les systèmes existants ;
- les mécanismes de contrôle et de supervision.
Le Cosmos Stack fournit des composants pour construire ces infrastructures. Leur sélection et leur configuration dépendent du projet.
La souveraineté ne signifie pas forcément une banque seule sur sa chaîne
Une institution peut utiliser une infrastructure propre, un consortium, un service opéré par un prestataire ou certaines infrastructures publiques.
Il serait trop catégorique d’affirmer qu’une banque ne peut jamais utiliser un réseau qu’elle n’opère pas directement.
La question est plus concrète : quel contrôle conserve-t-elle, quelles dépendances accepte-t-elle et comment assume-t-elle ses obligations ?
Un consortium peut mutualiser une infrastructure. Un registre dédié peut faciliter certaines personnalisations. Une connexion à un réseau externe peut ouvrir d’autres usages.
Chaque option possède ses compromis.
L’intérêt du modèle Cosmos est de proposer une architecture dans laquelle personnalisation et connexion peuvent être pensées ensemble.
IBC : comment des registres indépendants communiquent
IBC signifie Inter-Blockchain Communication. Il s’agit d’un ensemble de standards permettant à des systèmes compatibles d’échanger des messages vérifiables.
Les transferts de tokens sont un usage connu. Mais les messages peuvent aussi servir à d’autres interactions applicatives.
Pour comprendre le fonctionnement, distinguons trois rôles.
Les clients vérifient les informations reçues
Dans les architectures utilisant des clients légers, un réseau vérifie des éléments de l’état du réseau distant à partir de preuves.
Il ne se contente donc pas de croire un message parce qu’un opérateur l’a livré.
Les méthodes de vérification et les hypothèses de confiance dépendent néanmoins du client déployé.
Les relayeurs transportent les messages et les preuves
Les relayeurs observent les événements et transmettent les éléments nécessaires entre les réseaux.
Dans le modèle à clients légers décrit ici, leur rôle de transport ne leur donne pas, à lui seul, le pouvoir de fabriquer une preuve valide.
Leur disponibilité compte toutefois pour que les opérations progressent.
Les applications décident quoi faire du message
Une fois le message vérifié, la logique applicative détermine son effet : transfert, mise à jour d’un état ou autre action prévue.
La présentation officielle du fonctionnement d’IBC distingue ainsi le transport et la vérification des paquets de la logique métier des applications. Elle décrit aussi les étapes d’envoi, de réception, d’accusé de réception et d’expiration.
IBC apporte une grammaire commune. L’application doit encore définir ce que les phrases déclenchent.
IBC connecte-t-il automatiquement toutes les blockchains ?
Non.
Une connexion exige des composants adaptés aux réseaux concernés, une configuration et des applications compatibles.
Cosmos présente des solutions d’interopérabilité destinées à différents environnements dans son offre IBC pour les registres institutionnels. Cela ne signifie pas que chaque réseau possède déjà une connexion prête à l’emploi avec tous les autres.
Il faut distinguer :
- une capacité annoncée ;
- une intégration en développement ;
- un pilote ;
- un service disponible ;
- une connexion utilisée en production dans un périmètre donné.
Toutes les connexions n’ont pas les mêmes hypothèses de confiance
Selon l’intégration, la vérification peut notamment s’appuyer sur des clients légers, des preuves ou des attestations d’acteurs autorisés.
La feuille de route Cosmos Stack décrit elle-même plusieurs approches pour étendre les connexions à d’autres environnements.
Avant de parler de sécurité, il faut donc examiner le montage concret : qui atteste, qui vérifie, qui peut mettre à jour les composants et que se passe-t-il en cas d’incident ?
Un standard commun facilite l’analyse. Il ne dispense pas d’analyser chaque déploiement.
Ce que Cosmos propose aux institutions financières
La Cosmos Tokenization Suite est présentée comme une offre pour émettre et transférer des dépôts tokenisés tout en les intégrant aux systèmes bancaires existants.
Cosmos met notamment en avant :
- des connexions aux systèmes de cœur bancaire ;
- des mécanismes de rapprochement comptable ;
- des contrôles de conformité ;
- des connexions avec des réseaux externes.
Il s’agit du périmètre décrit par le fournisseur. Les bénéfices doivent être évalués sur une implémentation, un cas d’usage et des contraintes mesurables.
| Besoin institutionnel | Contribution possible de l’architecture | Ce qu’il reste à vérifier |
|---|---|---|
| Contrôler le registre | Infrastructure personnalisable | Gouvernance et dépendances opérationnelles |
| Encadrer les participants | Permissions et contrôles applicatifs | Couverture juridique et qualité des données |
| Communiquer avec d’autres réseaux | Intégration IBC | Compatibilité et modèle de sécurité |
| Synchroniser la comptabilité | Interfaces et rapprochements | Gestion des écarts et source de référence |
| Automatiser un paiement | Logique programmable | Conditions de déclenchement et recours |
| Protéger les informations | Dispositifs de confidentialité adaptés | Visibilité réelle des données et métadonnées |
L’enjeu n’est pas seulement d’ajouter un registre. Il faut l’intégrer à une institution qui fonctionne déjà, avec ses clients, ses procédures et ses responsabilités.
Pourquoi un registre permissionné n’est pas automatiquement privé
Un réseau permissionné limite certains accès ou certains rôles.
Cela ne signifie pas que toutes les données sont invisibles pour les participants autorisés, les opérateurs ou les outils d’exploitation.
Il faut notamment examiner :
- ce que voient les validateurs ;
- les informations accessibles via les interfaces ;
- les journaux techniques ;
- les métadonnées des transactions ;
- les droits des administrateurs ;
- les informations partagées avec les contreparties.
Dans son analyse des dépôts tokenisés, Cosmos souligne lui-même que la confidentialité doit être traitée à plusieurs niveaux, au-delà du seul caractère permissionné du réseau.
Une porte avec un badge contrôle l’entrée. Elle ne rend pas les murs opaques.
IBC ne remplace ni le règlement juridique ni la réglementation
Un protocole peut vérifier qu’un message provient d’un système reconnu et qu’il respecte certaines conditions techniques.
Il ne décide pas seul :
- si une obligation est juridiquement éteinte ;
- quel droit s’applique ;
- qui assume une erreur ;
- comment traiter une sanction ;
- quelles données peuvent traverser une frontière ;
- comment exercer un recours.
Finalité technique et finalité juridique
La finalité technique concerne la confirmation et l’irréversibilité attendue d’une opération dans le système.
La finalité juridique concerne les effets reconnus de cette opération sur les droits et obligations des parties.
Les deux doivent être cohérentes. Elles ne deviennent pas identiques simplement parce qu’un bloc a été confirmé.
Un message expiré ne défait pas forcément toute une opération financière
IBC prévoit des mécanismes de suivi et d’expiration des messages. Leur traitement dépend de la version et des applications utilisées.
Mais une opération bancaire peut aussi mobiliser un système comptable, une conversion de devise ou un règlement externe.
Le protocole de messagerie ne garantit pas, à lui seul, l’annulation de toutes ces étapes. Il faut prévoir les états intermédiaires, les reprises et les responsabilités.
Les routes sont nécessaires. Le code de la route, les assurances et les procédures de secours le sont aussi.
Une seule plateforme ou plusieurs registres compatibles ?
L’architecture Cosmos n’est pas la seule manière d’aborder la tokenisation.
Une plateforme commune peut rapprocher monnaie et actifs dans un même environnement. Plusieurs registres compatibles peuvent préserver davantage d’autonomie, avec un effort supplémentaire de coordination.
Ces modèles peuvent aussi coexister.
Dans une note publiée en juillet 2026, des auteurs du FMI examinent notamment les architectures de registres compatibles et leurs compromis de gouvernance. Ils les présentent comme une option potentiellement plus pratique à court terme dans certains contextes.
Cela ne constitue pas une validation de Cosmos ou d’IBC par le FMI.
C’est un éclairage sur le problème auquel cette approche cherche à répondre : connecter des infrastructures qui ne veulent pas nécessairement fusionner.
Au-delà des dépôts : fonds, obligations et actifs tokenisés
La connexion entre registres concerne aussi les fonds, les obligations, le collatéral et d’autres actifs tokenisés.
Un cas d’usage important est la livraison contre paiement, ou DvP : organiser la remise d’un actif contre son paiement, en limitant le risque qu’une partie livre sans recevoir la contrepartie attendue.
Sur une infrastructure partagée, certaines étapes peuvent être coordonnées dans une même transaction. Entre plusieurs systèmes, il faut concevoir les mécanismes de synchronisation et de gestion des échecs.
Autre exemple : mobiliser un actif comme garantie. Il faut savoir où il se trouve, s’il est disponible, qui le contrôle et comment sa valeur est reconnue.
La tokenisation facilite certaines automatisations. Elle ne fait pas disparaître les droits attachés aux actifs ni les responsabilités de leurs détenteurs.
Cosmos, Cosmos Hub et ATOM : éviter la confusion
Dans cette discussion, Cosmos désigne une approche technologique, des logiciels et un écosystème.
Le Cosmos Hub est une blockchain particulière. ATOM est son token.
Construire un registre avec des composants Cosmos ou utiliser IBC n’implique pas automatiquement que tous les flux passent par le Hub, ni que toutes les opérations utilisent ATOM.
Il faut regarder l’architecture retenue et le rôle réel de chaque composant.
Cette distinction évite de transformer une analyse d’infrastructure en conclusion automatique sur un token.
Comment évaluer un projet de dépôts tokenisés ?
Au-delà des annonces, quelques questions permettent de comprendre ce qui existe réellement.
L’instrument est-il clairement défini ?
Qui doit l’argent au détenteur ? Qui peut le détenir ? Comment se fait le remboursement ?
Quel problème le projet résout-il ?
Un paiement interne, un transfert interbancaire et un règlement transfrontalier ne possèdent pas les mêmes contraintes.
Comment fonctionne la connexion ?
Quels réseaux sont effectivement intégrés ? Avec quels clients, quelles preuves et quels opérateurs ?
Comment l’argent et la comptabilité restent-ils cohérents ?
Quel système fait référence ? Comment un écart est-il détecté puis corrigé ?
Quel est le niveau de déploiement ?
Démonstration, pilote et production doivent être distingués. Le nombre de partenaires annoncés ne mesure pas, à lui seul, l’usage effectif.
Ces questions rendent les progrès plus lisibles. Elles permettent aussi de repérer les endroits où une belle démonstration rencontre encore les contraintes du quotidien bancaire.
FAQ sur les dépôts tokenisés, Cosmos et IBC
Qu’est-ce qu’un dépôt bancaire tokenisé ?
Un dépôt bancaire représenté ou enregistré sur un registre distribué. Sa nature de créance sur la banque et les droits associés dépendent du dispositif applicable.
Quelle différence avec un stablecoin ?
Il faut examiner l’émetteur, la nature de la créance, les réserves éventuelles, le remboursement et le mode de circulation. Un dépôt tokenisé reste une dette bancaire ; les stablecoins recouvrent plusieurs constructions.
Pourquoi l’interopérabilité est-elle importante ?
Elle permet de coordonner des opérations entre systèmes distincts. Sans elle, les bénéfices peuvent rester limités à un réseau ou à un consortium.
À quoi sert IBC ?
IBC standardise des échanges de messages vérifiables entre systèmes compatibles. Les applications définissent les opérations financières ou techniques exécutées à partir de ces messages.
Cosmos impose-t-il une seule blockchain ?
Non. Son approche permet de construire des réseaux personnalisés et de développer leurs connexions, sous réserve des intégrations nécessaires.
Une connexion IBC garantit-elle un paiement sans risque ?
Non. La sécurité dépend notamment des réseaux, des clients, des applications et de leur exploitation. Le règlement financier et juridique demande aussi des mécanismes adaptés.
L’adoption de ces technologies implique-t-elle l’utilisation d’ATOM ?
Pas automatiquement. Il faut distinguer les logiciels Cosmos, le protocole IBC et la blockchain Cosmos Hub.
Relier les îles sans effacer leurs frontières
Les dépôts tokenisés peuvent rendre certaines opérations bancaires plus programmables et mieux intégrées aux actifs numériques.
Mais un registre performant reste limité si les institutions ne peuvent pas coordonner leurs paiements, partager les informations nécessaires et reconnaître les effets de leurs opérations.
Cosmos et IBC proposent une réponse architecturale à une partie de ce problème : permettre à des systèmes distincts de communiquer tout en conservant leurs règles.
La valeur de cette approche se mesurera dans les intégrations opérationnelles, la gestion des incidents et les usages réels.
Construire de nouveaux ports est une étape. Rendre la navigation fiable entre eux en est une autre.
