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

Blockchain créée par une seule entreprise, blockchain dans le Cloud, blockchain au code propriétaire, blockchain non auditable, ou encore s'appuyer sur une équipe à la fibre pas assez R&D. Voici cinq travers que tout PoC devra éviter sous peine d'aller dans le mur.

Déployer une blockchain à l’heure où les solutions centralisées sont très efficaces, c’est soit avoir compris l’intérêt de la technologie (et donc être sur le point de proposer un service réellement nouveau et disruptif), soit jeter de l’argent par les fenêtre en proposant un service déjà existant mais plus cher à mettre en place.

Pour être sur d'être dans le premier cas, l’étude de la fameuse Proof Of Concept (POC) est un passage obligé tant la Blockchain est une technologie en mutation constante, pour lesquelles les mises en œuvre pratiques se font attendre. La mise en place d’un PoC permet normalement de bien comprendre l'esprit décentralisé du concept, de le respecter, et de réaliser quelles contraintes nouvelles impliquent les blockchains.

En tout état de cause, et avant toute chose, pour réussir, il vous faudra d'abord réunir des profils variés, et surtout pertinents (chercheurs, ingénieurs, développeurs, business analyste, data scientist, etc.) avec un chef de projet ayant la fibre R&D. Vous n’irez nulle par avec un expert du Back Office.

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 Blokchain 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 fournisseurs sont éparpillées physiquement sur le 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'abolie 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é ») 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 limpides.

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.

Dernière mise à jour de cet article : février 2018

Approfondir

Participer à la conversation

1 commentaire

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

Partir du principe qu'au sein d'une entreprise, souvent constituée de sociétés diverses agrégées au cours du temps, n'existe aucun "manque de confiance a priori entre les acteurs" relève, à mon humble avis, d'une vision irénique de l'entreprise. Comme théâtre d'initiation aux autres problématiques, par ailleurs fort bien exposées ici, je défends que cette approche à toute sa place. Elle minimise les risques lié à cet apprentissage et permet de s'appuyer sur des mécanismes incitatifs classiques. Et puis, une fois que vous savez nager, votre désir sera toujours d'aller dans le grand bain, mais sans vous noyer... Pierre Gradit - MEZZONOMY
Annuler

- ANNONCES GOOGLE

Close