Quand les oracles de la blockchain deviennent une infrastructure financière

La finance tokenisée ne peut pas se développer à grande échelle sur infrastructure blockchain à elles seules. Les banques, les gestionnaires d'actifs et les réseaux de paiement ont également besoin d'un moyen fiable pour transférer les cours, les taux d'intérêt, les opérations sur titres, les données relatives aux réserves et les instructions de règlement entre les blockchains et les systèmes d'où proviennent ces informations. Les réseaux Oracle commencent à remplir ce rôle, faisant ainsi de ce qui était autrefois un élément spécialisé de la finance décentralisée une composante à part entière de l'infrastructure plus large des marchés financiers.

Chainlink illustre parfaitement cette évolution. Son réseau a été conçu pour relier les contrats intelligents à des données externes, mais son utilisation s’est étendue bien au-delà des flux de cours des cryptomonnaies. L’infrastructure prend désormais en charge les titres tokenisés, les transactions inter-chaînes et les liaisons entre les réseaux blockchain et les institutions financières établies. Cela modifie la portée des oracles. Ceux-ci ne sont plus simplement des outils utilisés par les applications DeFi. Ils s’intègrent désormais au mécanisme permettant l’émission, le transfert et la gestion des actifs traditionnels sur la chaîne.

Les opportunités sont considérables, mais les défis le sont tout autant. Les institutions financières ne peuvent pas se fier à des données simplement parce qu’elles ont été enregistrées sur une blockchain. Elles doivent savoir d’où elles proviennent, comment elles ont été vérifiées, ce qui se passe en cas de divergence entre les sources et qui est responsable lorsque des informations erronées déclenchent une transaction. L’adoption par les institutions dépendra donc de la capacité de l’infrastructure des oracles à combiner une vérification décentralisée avec les normes de contrôle, d’auditabilité et de responsabilité attendues dans la finance traditionnelle.

Le problème : les blockchains ne peuvent pas vérifier le monde extérieur

Une blockchain permet de vérifier ce qui se passe au sein de son propre réseau. Elle permet de confirmer qu'une adresse détient un actif, qu'une transaction a été signée ou qu'un contrat intelligent a respecté les règles qui lui ont été programmées. Elle ne peut toutefois pas déterminer de manière indépendante le cours actuel d'une action, ni vérifier si un paiement d'intérêts a été effectué, si une société a annoncé un fractionnement d'actions ou si un actif détenu par un dépositaire existe toujours.

Cette limitation est au cœur de la finance tokenisée. Une obligation tokenisée peut être émise et transférée sur la chaîne, mais sa valeur et sa gestion dépendent toujours d’événements externes. Le calcul des coupons peut s’appuyer sur un taux de référence hors chaîne. Le remboursement peut dépendre des instructions d’un émetteur ou d’un agent payeur. Les exigences en matière de garantie peuvent varier en fonction des prix du marché fournis par des sources externes. Un fonds tokenisé peut avoir besoin de valeurs d’actifs nets, de données de souscription et d’informations sur les opérations sur titres avant que ses contrats intelligents puissent fonctionner correctement.

Sans une connexion fiable à ces sources d'informations, la tokenisation reste incomplète. L'actif peut bien exister sur une blockchain, mais une grande partie des informations nécessaires à sa gestion se trouve toujours ailleurs.

La solution la plus simple consisterait à désigner un seul fournisseur de données et à lui permettre d'envoyer directement les informations au contrat intelligent. Cela recréerait l'une des faiblesses que les systèmes de blockchain sont censés réduire : la dépendance vis-à-vis d'un seul acteur. Une source d'informations inexacte, une défaillance technique ou une manipulation délibérée pourrait affecter toutes les transactions reposant sur ces informations.

Les réseaux Oracle résolvent ce problème en collectant des informations provenant de plusieurs sources et en faisant appel à plusieurs opérateurs de nœuds indépendants pour les vérifier et les transmettre. Au lieu de se fier à un seul fournisseur, le contrat intelligent reçoit un résultat issu d'un processus de validation plus large.

Cette architecture a déjà fait ses preuves dans le domaine de la DeFi, où les plateformes de prêt, les produits dérivés et les stablecoins dépendent des cours actuels du marché. La finance institutionnelle impose toutefois des exigences plus complexes. Une banque peut avoir besoin de savoir non seulement si une donnée est exacte, mais aussi si sa source est agréée, si le processus de transmission peut faire l'objet d'un audit et si l'accès à ces données respecte les restrictions contractuelles et réglementaires.

Pourquoi l'utilisation institutionnelle redéfinit la norme

Une erreur de transmission des cours dans une petite application de cryptomonnaie peut affecter un nombre limité d'utilisateurs. La même erreur, si elle survient dans l'infrastructure utilisée pour les obligations, les fonds ou les garanties tokenisés, pourrait perturber les transactions au sein de plusieurs institutions.

La norme évolue donc dès lors que les réseaux Oracle font leur entrée sur les marchés réglementés. La décentralisation technique reste pertinente, mais elle ne suffit plus à elle seule. Les banques et les opérateurs de marché ont besoin de contrôles adaptés à leurs cadres de gestion des risques.

La traçabilité des données devient essentielle. Une institution doit être en mesure d'identifier l'origine des informations, les sources ayant contribué au résultat final et la manière dont les divergences ont été résolues. Ce processus ne peut pas fonctionner comme un service technique opaque dont le résultat est accepté sans examen.

La résilience opérationnelle est également essentielle. L'infrastructure financière doit pouvoir continuer à fonctionner en période de tensions sur les marchés, lorsque la demande de données précises est la plus forte et que certaines sources peuvent devenir peu fiables. Les systèmes Oracle doivent disposer d'une redondance entre les nœuds, les fournisseurs et les réseaux, ainsi que de procédures bien définies pour gérer les informations retardées ou contradictoires.

La protection de la vie privée pose une autre difficulté. Les cours du marché public peuvent être diffusés ouvertement, mais les transactions institutionnelles peuvent impliquer des données confidentielles, des dossiers à accès restreint ou des informations réservées aux seules contreparties autorisées. L'infrastructure Oracle conçue pour les banques devra prendre en charge un accès contrôlé sans compromettre le processus de vérification.

La dernière question concerne la responsabilité. Une architecture décentralisée répartit la responsabilité entre plusieurs acteurs, alors que la réglementation financière prévoit généralement que des entités identifiables assument des obligations spécifiques. Les institutions voudront savoir qui exploite chaque partie du service, quelles sont les protections contractuelles applicables et comment les pertes seraient gérées si des données erronées entraînaient une transaction automatisée.

Ces questions ne rendent pas pour autant les réseaux Oracle inadaptés au secteur financier. Elles définissent les conditions dans lesquelles cette technologie peut s'imposer davantage dans ce secteur.

La solution : une couche de données institutionnelles vérifiable

Le modèle le plus prometteur n'est pas un réseau d'oracles entièrement sans autorisation, utilisé tel quel. Il s'agit d'une infrastructure à plusieurs niveaux qui préserve la vérification indépendante tout en intégrant les contrôles requis par les utilisateurs institutionnels.

Le premier critère est la qualité des sources. Les réseaux Oracle au service des institutions financières devront recourir à des fournisseurs de données de marché reconnus, à des dépositaires réglementés, à des agents de transfert et à d’autres sources agréées lorsque le cas d’utilisation l’exige. La décentralisation ne doit pas signifier la combinaison d’un grand nombre de flux de données peu fiables ou non vérifiés. Un ensemble plus restreint de sources de haute qualité peut s’avérer plus approprié qu’un ensemble plus vaste dont la fiabilité est incertaine.

Le deuxième niveau est celui de la validation indépendante. Plusieurs nœuds peuvent toujours récupérer et comparer les informations avant qu’elles n’atteignent un contrat intelligent. Cela réduit la dépendance vis-à-vis d’un opérateur unique et rend toute manipulation plus difficile. Des incitations économiques peuvent renforcer ce processus en exigeant des opérateurs qu’ils engagent des capitaux et en récompensant les performances précises.

Le troisième volet concerne l'interopérabilité. La finance tokenisée ne fonctionnera pas sur une seule blockchain. Les institutions auront probablement recours à une combinaison de réseaux publics, de réseaux privés et de systèmes de paiement existants. L'infrastructure Oracle doit donc permettre de transférer à la fois les données et les instructions de transaction entre différents environnements, sans imposer à chaque institution d'adopter la même pile technologique.

C'est là que les protocoles inter-chaînes prennent toute leur importance. Un actif tokenisé peut être émis sur un réseau, utilisé comme garantie sur un autre et réglé via un système bancaire établi. Les institutions concernées ont besoin d'une méthode contrôlée pour coordonner ces actions sans devoir recourir à une série de ponts mis en place manuellement.

Le quatrième niveau concerne la gouvernance. Les services d’oracle institutionnels doivent obéir à des règles claires régissant la sélection des données, l’admission des nœuds, les mises à jour logicielles, la gestion des incidents et le traitement des informations contestées. La gouvernance ne peut se limiter aux développeurs techniques. Elle doit également prendre en compte les exigences juridiques, opérationnelles et de conformité des institutions qui utilisent le service.

Enfin, l'infrastructure doit disposer de pistes d'audit exploitables. Les institutions doivent pouvoir retracer le parcours d'une valeur donnée au sein d'une transaction : quelles sources ont été utilisées, quels nœuds ont répondu, quelle méthode d'agrégation a été appliquée et si des exceptions se sont produites. Cela transforme la fourniture de données par les oracles, qui passe d'un simple événement technique à un processus pouvant être examiné par les équipes chargées de la gestion des risques, les auditeurs et les autorités de régulation.

Des flux de cours à la gestion des actifs

La prochaine étape de l'adoption des oracles ne se limitera pas à la simple fourniture des cours du marché.

Les titres tokenisés nécessitent des informations tout au long de leur cycle de vie. Les dividendes, les paiements de coupons, les rachats, les modifications d’indice et les opérations sur titres doivent tous être communiqués aux contrats intelligents concernés. Les tokens de fonds peuvent dépendre de la valeur nette d’inventaire et des registres de souscription. Les actifs réels tokenisés peuvent nécessiter des attestations de réserve, des informations sur le statut d’assurance ou la preuve que l’actif sous-jacent reste sous garde valide.

Les systèmes de preuve de réserves illustrent bien ce rôle plus large. Un oracle peut fournir la preuve que les actifs adossés à un token sont toujours détenus par un dépositaire. La valeur de ce service dépend de la qualité de la vérification sous-jacente, mais le principe est important : l'enregistrement sur la blockchain peut être relié à des informations concernant des actifs détenus en dehors du réseau.

La gestion des garanties constitue un autre cas d'utilisation. Les contrats intelligents peuvent ajuster les exigences de marge ou déclencher des virements en fonction de données vérifiées relatives aux prix et à l'exposition. Cela pourrait réduire les délais et les opérations de rapprochement manuelles, même si les institutions devront mettre en place des mesures de protection pour éviter que des informations erronées n'entraînent des conséquences immédiates et irréversibles.

Les réseaux « oracle » peuvent également prendre en charge des fonctions de conformité. Une transaction pourrait dépendre de la confirmation qu’un investisseur reste éligible, qu’une restriction juridictionnelle a été respectée ou qu’un actif particulier n’est pas désormais soumis à une restriction de négociation. Les informations sensibles n’auraient pas nécessairement besoin d’être publiées sur une blockchain publique. L’oracle pourrait fournir un résultat vérifié sans révéler l’enregistrement sous-jacent.

À mesure que ces applications se développent, l'oracle s'éloigne de son rôle de simple source de données pour devenir davantage une couche de coordination entre la propriété légale, les informations de marché et l'exécution automatisée.

Le risque qui subsiste est celui de la concentration

Les réseaux Oracle sont souvent présentés comme une solution à la centralisation, mais leur adoption par les institutions pourrait donner lieu à de nouvelles formes de concentration.

Si un réseau venait à s'imposer comme la connexion par défaut entre les institutions financières et les blockchains, une grande partie du marché des jetons pourrait dépendre des mêmes normes techniques, des mêmes opérateurs de nœuds et des mêmes processus de gouvernance. Un service largement utilisé peut être décentralisé en interne tout en devenant néanmoins un point de dépendance systémique concentré.

Cela ne signifie pas pour autant que les institutions doivent éviter de recourir à des infrastructures communes. Les réseaux partagés peuvent réduire la fragmentation et faciliter l'interopérabilité. Il convient de prendre conscience de ce risque et de le gérer.

Les institutions doivent examiner la diversité des sources de données, des opérateurs de nœuds et des modalités d'hébergement. Elles doivent déterminer s'il existe des itinéraires alternatifs en cas de défaillance d'un réseau. Les applications critiques peuvent nécessiter des flux de secours, des mécanismes d'exécution différée ou la possibilité de suspendre les transactions lorsque la qualité des données passe en dessous d'un seuil défini.

Les contrats intelligents doivent également être conçus en tenant compte de la possibilité que des informations externes puissent être tardives, contestées ou indisponibles. L'automatisation ne doit pas supprimer tout jugement du processus. Dans le cadre de transactions de grande valeur, une procédure d'exception soigneusement élaborée peut s'avérer plus importante que l'exécution immédiate.

Ce que les établissements financiers devraient évaluer

Les banques et les gestionnaires d'actifs qui envisagent de mettre en place une infrastructure Oracle devraient partir de la transaction plutôt que de la technologie.

Ils doivent déterminer de quels faits externes dépend la transaction, dans quels délais ces faits doivent être fournis et quelles seraient les conséquences si les informations s'avéraient erronées. Un cours du marché public, une évaluation par un fonds privé et une confirmation de la propriété légale comportent des risques différents et peuvent nécessiter des conceptions d'oracles différentes.

Ils doivent ensuite évaluer l'ensemble de la chaîne de responsabilité. Celle-ci comprend le fournisseur initial des données, les opérateurs de nœuds, le protocole réseau, le développeur du contrat intelligent et l'institution qui utilise le résultat. Un système techniquement décentralisé ne dispense pas de la nécessité d'une clarté contractuelle.

L'intégration mérite également une attention particulière. L'infrastructure Oracle ne doit pas devenir une couche isolée supplémentaire qui génère un travail de rapprochement supplémentaire. Sa valeur réside dans la connexion des systèmes de blockchain aux processus existants en matière de paiements, de conservation, de reporting et de gestion des risques.

L'évaluation finale porte sur la gouvernance à long terme. L'adoption par les institutions ne se résume pas à une intégration ponctuelle. Les sources de données évoluent, les logiciels sont mis à jour et de nouveaux réseaux viennent s'ajouter. Les institutions doivent savoir comment ces décisions sont prises et si elles peuvent influencer les changements qui affectent les services essentiels.

L'impact : la tokenisation entre dans la phase opérationnelle

Le débat autour de la tokenisation s'est souvent concentré sur l'émission : la question de savoir si une obligation, une part de fonds ou tout autre actif peut être représenté sur une blockchain. Ce n'est qu'un début. Les actifs financiers nécessitent des informations actualisées, une gestion, un règlement et une surveillance tout au long de leur cycle de vie.

Les réseaux Oracle comblent en partie ce manque d'infrastructure. Ils permettent aux contrats intelligents de réagir à des événements qui se produisent en dehors de la blockchain et facilitent l'interaction entre les actifs tokenisés et les systèmes financiers existants.

Leur succès dépendra moins de leur capacité à fournir un cours que de la confiance que les institutions pourront accorder à l'ensemble du processus qui sous-tend ce cours. La qualité des sources, la résilience, la protection de la vie privée, la gouvernance et la responsabilité détermineront si les réseaux d'oracles resteront une infrastructure cryptographique spécialisée ou s'ils s'intégreront au cœur du système financier.

Cette technologie a déjà dépassé son rôle initial. La prochaine étape dépendra de sa capacité à répondre aux exigences des marchés auxquels elle commence à s'ouvrir.