Tokenisation RWA : quand faut-il sa propre blockchain ?

Le problème : choisir la chaîne avant de connaître le besoin

EN BREF Choisir une blockchain pour des actifs réels, c’est surtout choisir les tâches que votre équipe prendra en charge.

Chez Integra, la chaîne n’était qu’une part de mon travail. J’ai monté l’équipe technique, travaillé sur le protocole et tenu l’infrastructure qui la faisait tourner.

J’ai été CTO de mars 2025 à juin 2026. Nous avons bâti sur la pile Cosmos EVM et amené la chaîne jusqu’à un mainnet prêt au lancement. Cet article revient sur les choix de conception. Il n’affirme pas que le mainnet a été déployé.

Ce travail a changé ma façon de faire. Aujourd’hui, je partirais de la vie de l’actif : on l’émet, des investisseurs arrivent, il change de mains, on le gèle, on le récupère, on le rachète. Chaque étape a besoin d’un responsable et d’un plan si elle échoue. Ensuite seulement, je choisirais où tourne le logiciel.

Les mots à connaître

EN BREF Tokeniser, c’est représenter des droits sur un actif réel sous forme de tokens. La chaîne est l’endroit où les règles du token s’exécutent.

Créer le tokenToken Une unité numérique sur une blockchain. Elle enregistre qui détient quoi, et du code décide comment elle peut circuler. Voir le glossaire, c’est la partie facile. Pour un actif réelActif réel Un bien hors de la blockchain, comme un immeuble, un prêt ou une part de fonds, dont des droits sont représentés par des tokens. En anglais : real-world asset (RWA). Voir le glossaire, le travail est autour du token : qui peut le détenir, combien coûte chaque mouvement et qui fait tourner le réseau.

Ce token peut vivre sur un réseau existant, comme Ethereum ou un layer 2Layer 2 (L2) Un réseau distinct qui prolonge Ethereum : il exécute les transactions, publie ses résultats sur Ethereum et s’appuie sur lui pour la sécurité, en général pour des frais plus bas. Voir le glossaire, ou sur une chaîne applicative à vous.

Comment je trancherais, étape par étape

EN BREF Je répondrais à six questions dans l’ordre, en partant de l’actif, pas du réseau.

L’ordre compte, car chaque réponse resserre la question suivante.

Partir du travail que la chaîne devra faire

EN BREF Une estimation de coût compte les transactions que votre processus crée vraiment, pas ses étapes métier.

Je suis l’un des cinq auteurs nommés d’ERC-3643. Un token permissionné comme celui-là peut tourner sur un réseau EVMEVM La machine virtuelle d’Ethereum : le moteur qui exécute les smart contracts sur Ethereum et sur les réseaux conçus pour être compatibles avec lui. Voir le glossaire existant. Une chaîne à part demande donc d’autres preuves que « l’immobilier est réglementé ».

Une transaction peut contenir plusieurs contrôles : un processus en cinq étapes ne fait donc pas forcément cinq transactions payées. Je compterais les actions qui modifient l’état, je mesurerais leur gasGas L’unité qui mesure le travail de calcul d’une transaction. Les frais valent le gas consommé multiplié par le prix du gas. Voir le glossaire sur la version prévue, et je testerais la charge attendue.

Execution fee estimate = transactions × measured gas × effective gas price
Fiat estimate          = native-token fee × assumed token price
Separate costs         = RPC + indexing + storage + providers + operations
For an L2              = include its applicable data/settlement charges

Ce sont des données pour un budget, pas un banc d’essai publié. La documentation d’Ethereum sépare bien le gas consommé et le prix du gas.

Une lecture par eth_call n’envoie pas de transaction payée. Les fournisseurs RPC, qui répondent aux lectures des applications, peuvent quand même faire payer l’usage. Le même code lancé dans une transaction, lui, consomme du gas.

Ce qu’ERC-3643 fait déjà pour vous

EN BREF ERC-3643 sépare déjà deux contrôles : le destinataire est-il vérifié, et ce transfert respecte-t-il les règles du token ?

Dans ERC-3643ERC-3643 Un standard de token Ethereum : seuls des détenteurs vérifiés peuvent recevoir les tokens, et chaque transfert ordinaire doit respecter les règles du token. Voir le glossaire, ces deux contrôles s’appellent isVerified et canTransfer. Un transfert normal vérifie aussi que le token n’est pas en pause et qu’aucun des deux wallets n’est gelé. Voir les règles de transfert de la spécification.

L’émetteur, lui, suit d’autres règles. Dans la spécification, créer des tokens ou forcer un transfert exige un destinataire vérifié, mais passe outre les règles de conformité. Détruire des tokens passe outre le contrôle de qui peut les détenir. Relisez donc ces pouvoirs à part.

Le standard fournit des contrôles techniques. Leur but juridique, c’est toujours l’équipe de l’émetteur qui le fixe.

Un refus du contrat fait partie de l’exécution. Si un transfert est annulé (revert), le solde revient à son état d’avant. Les validateurs, les machines qui vérifient et ajoutent les transactions, n’ignorent pas ce résultat.

Une transaction échouée peut quand même entrer dans un bloc et coûter du gas. EIP-140 définit l’instruction REVERT. Trois autres points sont à relire pour votre réseau : faire entrer les transactions, résister à la censure, et repartir quand une source de données tombe en panne.

Un exemple concret : un transfert passe, l’autre est annulé

EN BREF Même token, même expéditeur, deux destinataires : l’un est vérifié et le transfert passe, l’autre non et il est annulé.

Les noms et les montants ci-dessous sont fictifs. Les contrôles, eux, sont ceux que nomme ERC-3643.

Suivre chaque forme que l’actif peut prendre

EN BREF Quand un token restreint change de forme, vérifiez quel code décide de son prochain mouvement.

Il peut devenir une monnaie native de la chaîne, une copie encapsulée (un second token adossé à l’original, qui reste bloqué) ou une copie passée par un bridge (un pont vers une autre chaîne). Les règles de cette nouvelle forme ne sont pas forcément les contrôles du token.

On le vérifie en relisant un module de conversion, une encapsulation ou un bridge précis. Je ne dis pas que chaque L2 ou chaque déploiement Cosmos EVM a une faille pour contourner les règles.

Le module bank du Cosmos SDK offre des restrictions d’envoi, entre autres contrôles. Mais leur présence dans le SDK ne prouve pas qu’une chaîne donnée a réglé tous les chemins utiles.

Je vérifierais donc la version exacte de la chaîne. Je garderais coupée toute conversion non prise en charge tant qu’elle n’est pas testée. L’article suivant détaille cette relecture.

Ce qu’apporte une chaîne applicative, et ce qu’elle coûte

EN BREF Une chaîne applicative vous donne la main sur le protocole, et fait de son exploitation votre travail.

Chez Integra, j’ai travaillé sur cinq briques : un Asset Passport, des modules de conformité, le séquestre et l’exécution par jalons, la preuve de paiement en monnaie fiduciaire et l’application native des commissions. Une chaîne applicativeChaîne applicative Une blockchain construite pour un seul produit. L’équipe fixe ses règles de protocole et doit prévoir qui fait tourner le réseau. Voir le glossaire nous laissait choisir comment elles entraient dans le protocole.

Elle nous laissait aussi la charge des mises à jour, des validateurs, de l’accès RPC et de chaque incident de la chaîne.

Avant de dire qu’une règle vaut pour toute la chaîne, j’exigerais des tests sur chaque point d’entrée ouvert. L’appeler règle de consensus, une règle que chaque validateur applique, ne suffit pas. Le code doit l’appliquer à chaque changement d’état, et les mises à jour doivent la garder.

Registres d’actifs et permissions des agents

EN BREF Un registre d’actif relie des preuves sur un actif, mais il ne rend pas ces preuves vraies.

L’Asset Passport sur lequel j’ai travaillé était un registre centré sur l’actif. Pour une revue, je séparerais quatre choses : l’identifiant de l’actif, les liens vers les preuves, qui peut publier une mise à jour, et leur historique.

Une signature montre qui a fait une déclaration. Elle ne prouve pas qu’une valeur ou une affirmation juridique est juste.

Les permissions des agents posent un problème voisin. Un agent logiciel qui agit sur la chaîne a besoin d’un opérateur qui en répond, de pouvoirs limités et d’un moyen de les retirer. Une identité enregistrée ne suffit pas à lui donner des droits larges.

Le code de l’encadré ci-dessous est une esquisse pour une relecture, purement illustrative. Il ne vérifie pas qui a le droit, ne contrôle aucune preuve et ne s’accroche pas au protocole. En Solidity, les interfaces listent les fonctions qu’on peut appeler ; c’est le code derrière qui décide de ce qu’elles imposent.

// Illustrative interface only. No implementation or security guarantee.
interface IActionPolicy {
    function isAuthorized(
        address operator,
        address target,
        bytes4 selector,
        uint256 assetId
    ) external view returns (bool);
}

Une vraie version doit tout vérifier au moment où elle tourne : les paramètres, l’appelant, l’expiration, une éventuelle révocation et le rejeu (la même demande envoyée deux fois). Même une fonction autorisée peut comporter un destinataire ou un montant interdit. C’est la même règle que celle du moindre privilège pour les agents.

Ce que le produit doit encore livrer

EN BREF Une meilleure infrastructure peut réduire le travail d’intégration répété, mais elle ne termine pas le produit.

Un token qui circule a encore besoin d’acheteurs et de vendeurs éligibles. Il faut aussi un moyen de les trouver, un prix et un règlement. Découper un actif en petites parts ne garantit pas un acheteur le jour où un investisseur veut vendre.

Une mise à jour automatique de la valeur demande une méthode écrite et un moyen de corriger la valeur. Une nouvelle juridiction demande une analyse de l’instrument et de ses obligations. Changer d’oracle, la source de données de la chaîne, ne fait pas cette analyse.

Je traiterais chacun comme un chantier à part, avec ses critères de fin et une équipe responsable.

Comment je prendrais la décision finale

EN BREF Un processus qui tient dans des contrats EVM existants oriente vers un réseau existant, des membres connus vers un réseau permissionné, et des modifications de protocole exigées vers une chaîne applicative.

Integra m’a rendu plus précis sur cette dernière branche. En plus du protocole, j’ai mené le durcissement du RPC avant le lancement et l’infrastructure des validateurs sur quatre clouds.

Il a aussi fallu une façon de travailler pour l’équipe : contrôles de configuration, étapes de déploiement et plan en cas d’incident.

Pour un nouveau projet, je partirais de l’architecture la plus simple qui satisfait les exigences vérifiées. Si cela mène à une chaîne sur mesure, je veux des raisons écrites et testables. Vous devez trancher en ce moment ? Envoyez-moi le processus de l’actif et la contrainte que vous ne savez pas respecter.

Si vous devez faire ce choix

FAQ