Les preuves de concept sur la blockchain : pièges, déviances et non-sens à éviter

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 tout simplement jeter de l’argent par les fenêtres en proposant un service déjà existant mais plus cher à mettre en place. L’étude de la fameuse preuve de concept (poc) est donc un passage obligé tant il s’agit d’une technologie en mutation constante et pour lesquelles les mises en œuvre pratiques se font attendre.

La mise en place d’un poc sur la blockchain apporte des complications bien spécifiques, celle du respect du concept, de son esprit, et la prise en compte de contraintes nouvelles. Se donner les moyens de réussir, c’est donc réunir des profils variés, et surtout pertinents – chercheurs, ingénieurs, développeurs, business analyste, data scientist, etc… – et un chef de projet ayant la fibre R&D. Vous n’irez nul par avec un expert du pack Office, mais là-dessus nous reviendrons plus tard.

Implémenter de nouveaux services rendus possibles grâce à la blockchain, en partenariat et étroite collaboration avec des partenaires industriels de renom, c’est justement l’objectif du projet Blockchain for Smart Transaction de l’Institut de Recherche Technologique SystemX. (sources : page web du projet : http://www.irt-systemx.fr/project/bst/, communiqué de presse : http://www.irt-systemx.fr/v2/wp-content/uploads/2016/12/SystemX-081216-Projet-BST.pdf).

Une introspection sur le déroulement de l’étude du premier cas d’usage à être arrivé à son terme, l’implémentation de carnets d’entretien décentralisés pour les constructeurs automobiles (ref : http://www.itpro.fr/n/blockchain-en-pratique-22081/), a non seulement mis à jour des éléments indispensables au succès d’un poc sur la blockchain, mais aussi de se rappeler quelques principes de base plus généraux sur que faire et ne pas faire dans un environnement R&D. En voici la substance.

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 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. C’est la distribution du registre qui garantit 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é – avouez que c’est un comble quand on veut palier un problème de confiance. Rien ne vaut alors une bonne solution centralisée telle qu’il en existe partout et qui ont fait leurs preuves.

La question à se poser est : « 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 consortium gagnant-gagnant ».  Rassurez-vous cependant, partager ne veut pas dire tout divulguer ! A ce sujet, voir par exemple le cas des carnets d’entretien distribués de PSA et Renault évoqué plus haut (http://www.journaldunet.com/economie/automobile/1204234-blockchain-renault-psa-fraude-automobile/, http://www.itpro.fr/n/blockchain-en-pratique-22081/).

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

La décentralisation est au 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. Ce n’est pas donc la simple distribution géographique qui compte – entendons par là le fait d’avoir des nœuds blockchain fonctionnant sur plusieurs serveurs distants. On en revient donc au point précédent : un poc sur la blockchain au kickoff duquel ne se trouverait dans la salle qu’un seul acteur privé est voué à se retrouver face à un mur.

L’open source, gage de bonne foi, assurer la confiance là où elle est nécessaire

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 ». « Faux ! », dire cela 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.

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 de la centralité dans l’architecture. L’esprit blockchain est violé, et elle ne présente plus aucun intérêt.

Certes vous allez dire « comme si nos clients allaient aller lire le code … ». 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 ? La transparence des informations qui circulent n’impliquent pas leur totale lisibilité (REF http://www.itpro.fr/n/blockchain-en-pratique-22081/). 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 solution à tout.

La répartition des coûts entre membres du consortium

Si la distribution des coûts relatif à 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 (REF : http://www.itpro.fr/n/blockchain-en-pratique-22081/), 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, et par cela j’entends au moins développeur très-senior, et/ou de préférence docteur en informatique : 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

Data Scientist, SQLI

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !