Square

Innovation

Les stratégies blockchain des acteurs financiers confrontées à la réalité

Créé le

18.07.2017

-

Mis à jour le

08.04.2019

Le secteur financier s’est intéressé tôt à la technologie des registres distribués, via des expérimentations en solo ou au sein de consortiums. Rares sont celles qui entrent en phase industrielle. Ce qui n’empêche pas la start-up Blockchain Partner, qui accompagne ces projets, de tirer quelques leçons.

Les technologies blockchain font l’objet d’un intérêt grandissant dans de multiples domaines (énergie, agroalimentaire, transports…) mais le secteur financier est celui qui s’y est intéressé, et de loin, en premier. De ce fait, il a pris une certaine avance en la matière : après la phase de découverte et d’acculturation, les grands acteurs financiers ont démarré au cours des derniers mois et années – du moins pour une partie d’entre eux – plusieurs expérimentations destinées à tester l’utilité et la solidité de ces technologies pour leurs activités. De cette façon, les acteurs financiers ont pu commencer à vérifier concrètement les gains et les limites actuelles de la blockchain, au-delà de la frénésie médiatique.

Une confidentialité ciblée difficile à garantir

En France, l'expérimentation bancaire la plus aboutie semble être le projet de la Banque de France, dont l’application devrait être déployée avant la fin de l’année, ou à défaut début 2018 [1] . Les autres projets français sur lesquels Blockchain Partner est intervenu évoluent de différentes manières : certains relevaient plutôt d’une logique d’expérimentation pure, et n’avaient pas pour ambition d’aller nécessairement au-delà de la phase de prototypage ; d’autres ont mis en avant des problématiques autour de la confidentialité et des volumes qui ne semblent pas surmontables à court terme et restent donc en pause.

Une des principales problématiques de la blockchain réside ainsi dans la difficulté à cacher de l’information aux autres participants. C’est un enjeu par exemple pour la gestion du collatéral dans le cadre de la supplychain : une banque détenant un collatéral n’a pas intérêt à inscrire toutes les informations liées à ce collatéral sur la blockchain, car certaines peuvent être confidentielles. Il est certes possible en théorie d’inscrire uniquement ce que l’on souhaite sur une blockchain, néanmoins il est difficile ensuite d’obliger chaque partie prenante à respecter des engagements si les termes initiaux sont restés secrets auprès de tous.

En effet, dans le cas d’une blockchain où les participants ne se cachent aucune information entre eux, la possibilité de tricher pour un acteur donné est très limitée, puisque tout est transparent. En revanche, si certains acteurs gardent pour eux certaines informations, il ne peut plus exister de consensus général : le protocole ne suffit plus à être garant que personne ne triche. Dès lors, il est nécessaire d’utiliser des moyens extérieurs à la blockchain pour forcer un acteur à respecter un engagement pris auparavant.

Une certaine opacité sur le résultat des expérimentations

In fine, un nombre très limité de projets avancent au-delà de la phase de Proof of Concept et se dirigent vers un développement plus industriel. Trois domaines semblent avancer plus vite que les autres :

  • la supply chain, qui comporte un grand nombre d’intermédiaires parmi lesquels des acteurs bancaires pour les questions de financement par prêt, d’assurance, etc. ;
  • la gestion des titres sur blockchain, qui va permettre de faciliter plusieurs processus (règlement-livraison, suivi des titres, utilisation des titres, etc.) ;
  • l’émission monétaire sur blockchain, pour laquelle plusieurs expériences ont eu lieu, notamment de la part de la Bank of England.
Hors de France, de nombreuses initiatives ont été lancées, notamment aux États-Unis – le Nasdaq a par exemple développé un produit centré sur l’échange de titres de sociétés non cotées –, en Asie ou encore en Russie avec des expérimentations sur Nxt. Ces initiatives sont souvent menées dans le cadre de consortiums, dont le plus connu est R3CEV, même s’il en existe d’autres : pensons ainsi au consortium japonais créé fin 2016 entre une quarantaine de banques asiatiques, dont l’expérimentation de transfert d’argent en temps réel via le protocole Ripple s’est avérée concluante et va être commercialisée.

Il est néanmoins très difficile de connaître, au-delà des effets d’annonce, les résultats concrets des expérimentations menées par les institutions et grandes entreprises financières, ainsi que par les géants de l’informatique – IBM, en particulier, est à l’initiative de plusieurs expérimentations en supply chain. Les organisations communiquent au début des phases de test, mais en font rarement publiquement le bilan. Or ces tests s’effectuent systématiquement en circuits fermés, dans des cercles restreints, ce qui empêche les acteurs extérieurs de se connecter à un produit pour le tester par eux-mêmes.

Les obstacles aux projets développés au sein des grandes banques

De manière générale, il faudra un certain temps avant que des produits fonctionnels et innovants soient mis en place par des grandes entreprises. L’innovation arrivera plus probablement des start-up, et ce d’autant plus que le développement de projets blockchain au sein du système informatique des grandes banques affronte plusieurs obstacles, qui impliquent des efforts dont le retour sur investissement est aujourd’hui très difficile à évaluer.

Ces limites tiennent en particulier au fait que les pratiques et processus habituels de sécurité (logiciels audités et autorisés en interne…) sortent des sentiers battus avec les projets blockchain. Par exemple, le fait que les projets blockchain soient basés sur des réseaux pair à pair renverse la logique des environnements traditionnels qui reposent sur une architecture client-serveur [2] . Ces logiques non traditionnelles peuvent s’avérer très compliquées à concilier avec les systèmes bancaires actuels. Il est par exemple difficile de faire tourner un nœud en interne qui communique à la fois avec des nœuds externes et avec des applications internes.

En outre, les versions des logiciels proposés (qui ont été audités par la sécurité informatique de l’institution financière) et autorisés pour les projets sont souvent peu à jour, ce qui constitue un autre obstacle pour développer des projets blockchain : les technologies blockchain avancent en effet très rapidement, et les versions des logiciels s’enchaînent vite, alors que les temps de validation en interne sont longs.

Les freins au succès des consortiums

Les projets développés au sein de consortiums connaissent eux aussi des freins importants. L’idée initiale de ces consortiums est de mutualiser les coûts d’expérimentations, mais le nombre, souvent très (voire trop) important, d’acteurs réunis complique fortement les avancées de ces initiatives. Le consortium R3CEV, composé de plusieurs dizaines d’acteurs financiers, a certes tenté de répondre à ce problème en répartissant les organisations membres en différents groupes de travail, soit autour d’une zone géographique, soit autour d’un métier spécifique. Néanmoins, cette méthode n’a pas permis de surmonter l’obstacle de fond : si les acteurs réunis autour de la table se déclarent d’abord volontaires pour expérimenter, il s’avère en pratique que chacun se montre réticent à expérimenter les cas d’usage les plus disruptifs pour leurs cœurs de métier respectifs. Dès lors, chacun pose des conditions restrictives qui limitent fortement le champ des possibles.

Pour ces raisons, il est permis d’être réservé sur les résultats à venir des différents consortiums. À ce jour, très peu d’applications fonctionnelles ont été développées par ces consortiums, même si cela reste logique au vu de leur taille, qui ralentit le rythme d’avancement. La question est de savoir si dans 2 ans, ou même 5 ans, des résultats concrets et intéressants auront été produits. Déjà, plusieurs membres commencent à s’impatienter ; le consortium R3CEV a du reste connu des défections de la part de membres importants au cours des derniers mois (JP Morgan, Goldman Sachs, Morgan Stanley, Santander…), d’autant plus symboliques que certains faisaient partie des membres fondateurs.

Si les raisons de ces départs divergent – et ne sont parfois pas communiquées – il apparaît tout de même que la logique du consortium profite avant tout aux participants les moins avancés dans le domaine. Certaines entreprises voient le consortium auquel elles appartiennent travailler sur des projets qu’elles ont déjà expérimentés en interne précédemment. Elles sont alors tentées de revenir à une logique plus classique, avec l’idée de développer seules une solution puis de convaincre les autres acteurs de l’adopter. En partageant la gouvernance, il est en effet plus compliqué d'arriver à un consensus et donc d’avancer aussi vite.

D’où viendra l’innovation ?

In fine, trois scénarios se dégagent pour les mois et années à venir :

  • l’émergence de solutions et standards développés au sein des consortiums : ce scénario est le moins probable, du moins à court terme, en particulier en raison des problématiques de gouvernance ;
  • le développement, par un grand acteur du secteur (une grande banque ou une banque centrale) de solutions répondant à des problèmes spécifiques : l’idée est alors d’agglomérer un écosystème autour de cette solution ;
  • le développement de solutions par des start-up de l’écosystème blockchain, qui pourraient ensuite se faire racheter (ou non) par une ou plusieurs banques. Pensons par exemple aux produits développés par des start-up comme Wave (qui travaille sur une solution de supply chain clef en main qui pourrait intéresser des banques), Setl [3] , Kalypton, QED-it, et bien d’autres.
Affaire(s) à suivre…

 

1 Lire à ce sujet, dans ce même numéro, l’interview de Thierry Bedoin, CDO de la Banque de France.
2 Une architecture client-serveur se caractérise par un ou plusieurs serveurs où les clients se connectent, et qui sont gérés par une seule entité. Dans un réseau pair à pair, les serveurs sont répartis sur différents nœuds.
3 Lire aussi l'interview de Setl dans Revue Banque n°808, mai 2017, p.40-41.

À retrouver dans la revue
Revue Banque Nº811
Notes :
1 Lire à ce sujet, dans ce même numéro, l’interview de Thierry Bedoin, CDO de la Banque de France.
2 Une architecture client-serveur se caractérise par un ou plusieurs serveurs où les clients se connectent, et qui sont gérés par une seule entité. Dans un réseau pair à pair, les serveurs sont répartis sur différents nœuds.
3 Lire aussi l'interview de Setl dans Revue Banque n°808, mai 2017, p.40-41.