PoC Blockchain : cinq non-sens, erreurs et idées fausses à éviter

Une blockchain pour vous tout seul ne sert à rien

Quand vous entendez ou lisez « Telle entreprise a décidé de créer sa propre blockchain », il est difficile de savoir qui blâmer : le journaliste qui n’a pas fait relire son article par l’entreprise en question, ou cette dernière qui vend un service n’ayant absolument aucun sens et qui est probablement très coûteux.

Une bonne fois pour toutes, la blockchain n’a d’utilité que s’il existe un manque de confiance a priori entre les acteurs.

Distribuer un registre a du sens quand on cherche à garantir la fiabilité des transactions. S’il n’y a qu’un seul acteur, alors dire que l’on va utiliser une blockchain est de la pure malhonnêteté – un comble quand on veut palier un problème de confiance. Rien ne vaut dans ce cas une bonne solution centralisée telle qu’il en existe partout et qui ont fait leurs preuves.

La première vraie question à se poser est véritablement : « ai-je des concurrents avec lesquels nous ne partageons rien (car ce serait dans notre intérêt individuel de tricher), alors que s’il nous était impossible de tricher nous pourrions nous installer dans une relation de consortium gagnant-gagnant ».

Attention. Partager ne veut pas dire tout divulguer. C'est aussi une des caractéristiques des blockchains et des smart contracts - et une source de complexité technique - que de moduler quelles informations sont consultables, par qui et quand.

Une blockchain dans un cloud ? Autant faire prendre l’autoroute à un avion

La décentralisation est le cœur du cœur du concept de blockchain. Elle est garante de sécurité et de la transparence. Le registre est dupliqué et possédé par plusieurs acteurs qui, n’ayant a priori pas confiance les uns dans les autres, vérifient ce que chacun fait.

Or la Blockchain dans le cloud pose un problème de respect de l'esprit initial de la technologie. Si tous les nœuds sont dans les datacenters d'un seul et même fournisseur, la notion de décentralisation perd une partie de son sens. Pourquoi ? Parce que dans ce cas, on centralise de facto l'architecture sous-jacente de la blockchain chez un acteur, et cela même si les datacenters du fournisseur sont éparpillés physiquement sur la planète.

Ce n’est donc pas la simple distribution géographique qui compte - entendons par là le fait d’avoir des nœuds blockchain fonctionnant sur plusieurs serveurs distants - mais l'indépendance des entités qui les gèrent.

On en revient au point précédent : un PoC sur la blockchain au kick-off duquel ne se trouverait dans la salle qu’un seul acteur privé - à un niveau ou à un autre - est voué à se retrouver face à un mur.

La blockchain n'abolit pas la notion de confiance

Au sens traditionnel du terme, une transaction implique de la confiance. Elle peut trouver son origine dans un rapport social (« je fais confiance à un ami pour qu’il me rende les dix euros que je lui ai prêtés ») ou institutionnel (« je fais confiance à ma banque pour effectivement virer dix euros sur tel compte bancaire »). Autrement dit, il faut de la confiance directement entre les acteurs, ou des acteurs vis à vis d’un tiers.

On lit souvent : « la blockchain, c’est l’abolition du tiers de confiance ». C'est tout simplement faux !

Le dire, c’est pêcher par manque de rigueur. Dans un réseau blockchain, la confiance est placée dans un programme informatique – développé par un humain – qui a ceci de rassurant qu’il est dénué de tout sentiment et d’intérêt à mentir. Il y a donc simplement déplacement de la cible nécessaire de la confiance.

Une blockchain qui n'est pas open-source n'est pas une vraie blockchain

Ainsi, offrir un service basé sur une blockchain sans rendre publique les codes de fonctionnement, interface comprise, et sans donner aux utilisateurs la possibilité de vérifier leur déploiement effectif, c’est leur demander de placer leur confiance en vous, et c’est remettre là encore de la centralité dans l’architecture.

L’esprit blockchain est alors bafoué, et celle-ci ne présente plus aucun intérêt.

Certes vous allez dire « comme si nos clients allaient aller lire le code ». Comprenez bien. L’important n’est pas tant que tout un chacun aille vérifier, mais qu’il soit possible d’aller vérifier.

Alors, pas de place pour la confidentialité des données ? Si bien sûr. On ne le redira jamais assez, la transparence des informations qui circulent n’implique pas leur totale lisibilité. Certaines blockchains – Quorum par exemple – permettent de créer des canaux d’échanges cryptés.

Et même sans cela, votre équipe d’ingénieurs-chercheurs inventifs trouvera la solution à tout.

La répartition des coûts entre membres du consortium implique une blockchain auditable

Si la distribution des coûts relatifs à la validation des blocs est intrinsèque à la blockchain, celle qui concerne son usage peut se révéler être une source potentielle de blocage en cas d’utilisation de smart contracts.

Un exemple : A, B et C sont trois entreprises ayant déployé un nouveau service dans une blockchain. Celui-ci fonctionne à l’aide de smart contracts déployés par chacun des partenaires.

Après un mois d’utilisation, A et B se rendent compte que seuls les smart contract de C ont été utilisés par les clients. Auraient-elles dû exiger en amont que les coûts soient également répartis au prorata de l’utilisation des smart contracts ?

La question n’a en apparence rien à voir avec le volet technologique d’un PoC. Et pourtant : pouvoir auditer la blockchain, suivre son bon fonctionnement et l’usage qui en est fait à des implications sur son architecture, et nécessite le développement d’outils spécifiques pour pouvoir lire les transactions sur la blockchain, qui comme chacun sait n’ont rien de limpide.

Si vous ne deviez retenir qu’une seule chose : bien s’entourer

La blockchain est encore un concept nouveau, en constante et rapide évolution. Développer un PoC sur le sujet ne se résume donc pas encore à implémenter des spécifications logicielles décidées dans des réunions au sommet. Le cœur de votre équipe devra donc se composer d’un ou plusieurs experts techniques, au moins développeur très-senior, et/ou de préférence docteur en informatique.

Il vous faudra aussi des collaborateurs capables d’ouvrir le capot des technologies les plus avancées, d’en suivre l’évolution au jour le jour, qui ont cette fibre R&D qui les fait prendre des initiatives sans avoir besoin de consignes, et qui peuvent s’intégrer dans n’importe quelle problématique métier.

En bref prenez ceux qui, pour s’extraire d’un atelier d’idéation qui commence à traîner en longueur, diront « bon, on commence à coder, on verra après ».

Et maintenant ?

Arrivé ici, sans doute vous êtes-vous rendu compte que vous n’avez pas besoin d’une blockchain et vous pouvez souffler. Dans le cas contraire, un énorme travail vous attend. Sachez donc vous entourer.

Hugo Levard & Damien Lecan (SQLI) ont participé au PoC de carnet d'entretien distribué de PSA qui s'appuyait sur une Blockchain réunissant constructeur, garages, et autres acteurs de la chaîne de valeur automobile. Les enseignements décrits dans cet article viennent, entre autre, de cette expérience concrète.