Blockchain : guide pour concevoir son premier produit (MVP)

Cet article a été publié originellement sur mydatacompany.fr

La phase d’exploration d’un projet blockchain et la constitution d’un écosystème minimum viable (MVE) doivent se poursuivre par la conception d’un premier produit. Ce MVP permettra de confirmer la pertinence du projet. Mais attention à ne pas bâtir de cathédrale.

Les méthodologies sont multiples en matière de projet blockchain, néanmoins elles reposent globalement sur quatre grandes étapes, résumées ainsi par Octo Technology : former, explorer, construire (MVP) et scaler.

Le MVP sera donc la conception d’un premier produit, un Minimum Viable Product. Celui-ci mettra en musique un ou des cas d’usage en concertation avec les acteurs de l’écosystème impliqués dans sa production (le MVE ou Minimum Viable Ecosystem).

 

Le premier écueil ? Construire une cathédrale

Mais attention lors de ces étapes de ne pas se lancer dans la « construction de cathédrale ». Car les technologies blockchain sont encore nouvelles et les cas d’usage à confirmer. Quant à l’apport de valeur, il reste à mesurer et développer – tout en étant dépendant de l’implication d’un écosystème minimum.

Il est donc préférable de démarrer petit. Ou du moins de définir un périmètre maîtrisable, qui pourra ensuite être étendu. Pour ce MVP, « on va dérouler une démarche d’architecture en quatre étapes (voir schéma ci-dessous) dans laquelle on s’efforcera de limiter la complexité et les coûts initiaux d’implémentation du premier MVP » résume Ludovic Chauvaux, consultant senior pour Octo.

Ces étapes comprennent le choix du pattern de consortium permettant de définir l’architecture logique (centralisée ou décentralisée), la sélection de la stack technologique (en fonction du MVE) et du modèle de déploiement opérationnel (responsabilité du run, du hosting, du monitoring entre les membres de la blockchain, etc.).

Enfin, une fois les idées plus claires sur les questions d’interopérabilité technologique, il est possible de s’atteler à l’intégration dans les systèmes d’information de chacune des parties. Et « tout cela en anticipant la phase de scaling ».

Bref, démarrer petit, mais évolutif, même si peu d’acteurs atteignent cette étape du fait de la complexité inhérente à ces projets. « La mise en place d’un système décentralisé va engendrer beaucoup de complexité et cette complexité se percevra uniquement lors de la mise en place du premier MVP. »

La blockchain revient en effet à concevoir un nouveau système d’information commun à plusieurs entités distinctes, qui bien souvent ne partagent pas les mêmes référentiels, technologies, démarches, ou cycles de décision. Pour ne citer que ces différences.

Le MVP pour limiter la complexité et extraire la valeur

Cette complexité ne fera que s’accroître lors de la phase de scaling faisant intervenir plus d’acteurs. « Cette phase de MVP est donc essentielle pour limiter la complexité et extraire la valeur » insiste le consultant. D’ailleurs, peu de consortiums peuvent prétendre à cette dernière étape, une dizaine environ.

La construction du MVP, c’est donc beaucoup de technique, mais aussi définir des règles de gouvernance avec pour objectif de mettre en place une véritable architecture décentralisée. Au niveau infrastructure, il faut ainsi déterminer la typologie de réseau, la solution de déploiement (plus ou moins décentralisée, et assuré par qui), la gestion des clés et le monitoring (comment ? Par qui ?).

La liste n’est pas exhaustive. Pourraient s’y ajouter les questions de performance et de confidentialité des référentiels de données. Complexité, complexité… D’autant que dans une infrastructure décentralisée, chaque nœud de la blockchain (en on-premise ou sur le cloud de chaque membre) assurera run, monitoring, sécurité et intégration.

Mais il est toutefois possible de prendre quelques libertés avec cette décentralisation. Loup Théron, consultant lead developer blockchain suggère ainsi une approche plus simple pour débuter : un architecture certes décentralisée, mais au sein du cloud d’un même fournisseur.

« On conserve ainsi une segmentation inter-entreprise tout en offrant la possibilité à chaque acteur d’extraire son nœud par la suite. Il faudra par conséquent être vigilant à l’égard du vendor locking » prévient l’expert.

Un cloud pour tous, mais gare au lock-in

L’implication du fournisseur cloud permettra de simplifier le démarrage du MVP. En matière de déploiement décentralisée, qui engendre là aussi de la complexité, Octo préconise de faire de l’infra as code et d’utiliser au maximum la conteneurisation des paquets.

Au niveau de la sécurité, il est préférable de mettre en place des règles de sécurité minimums, mais communes. Le cloud provider assumera dans l’idéal ce volet sécurité. Pour l’intégration SI, une des principales sources de coûts, la tentation peut être grande de multiplier les services (paiement, CRM, gestion d’identités…).

« Très tôt dans les phases de projet MVP, il faudra s’aligner sur des protocoles, les cycles de décision, de gouvernance »

Loup Théron, octo

Sur ce point aussi, Loup Théron préconise une « intégration minimale », c’est-à-dire de se cantonner aux éléments indispensables à la démonstration de la valeur du cas d’usage. La priorité, c’est l’expérience utilisateur. Et pour l’optimiser, il convient généralement de connecter le moins de services possible.    

Le monitoring et le run enfin. Le consultant encourage l’adoption dès le début du MVP d’un monitoring centralisé afin de suivre l’état des différents nœuds. « L’objectif ici est de réagir au plus vite si un nœud tombe. Cela permettra en outre par la suite de basculer avec le moins de heurts possibles dans un système plus décentralisé. »

Ludovic Chauvaux insiste plus largement sur l’importance de la standardisation. De multiples acteurs devront en effet être synchronisés. « Très tôt dans les phases de projet MVP, il faudra s’aligner sur des protocoles, les cycles de décision, de gouvernance qui faciliteront la constitution de l’architecture et sa croissance. » 

C’est en tenant compte de ces différents enjeux que l’équipementier automobile Faurecia s’est lancé dans la mise en place de son premier MVP. Lors de la phase d’exploration, il a convaincu un constructeur auto et un fournisseur de participer à son projet blockchain tourné vers l’amélioration de l’efficacité opérationnelle, une préoccupation centrale dans cette industrie.

Mais avant d’entamer la phase de MVP, et dans le cadre d’une démarche lean startup, Faurecia a mis au point un PoC, qui a ainsi fait office de démonstrateur et d’outil marketing pour convaincre ses partenaires potentiels. Et Adrien Winter, consultant product et delivery pour Octo insiste bien sur la nécessité dans un premier temps, « pour aller vite en production », de « prioriser, et de réduire le premier scope » à livrer.

La complexité ? Réunir autour d’un même but

« Quelle est la tranche de valeur que je veux pouvoir tester en premier afin d’apporter de la valeur à mes utilisateurs et présentant un potentiel un retour pour mon entreprise, mais me permettant aussi d’apprendre afin de passer à l’étape suivante ? » résume-t-il sous forme de question.

« Quelles sont les trois fonctionnalités que j’emporterais sur une île déserte ? » Un cadrage s’impose, mais attention agile, n’excédant pas un mois et conçu par exemple par le biais d’ateliers (produit, technique, organisationnel, …). L’objectif étant d’en extraire un « périmètre priorisé. »

Faurecia a justement été confronté à cet obstacle, aboutissant à un périmètre trop conséquent par rapport à son objectif de livrer un produit en sept sprints (plus un sprint zéro) de deux semaines. L’équipementier et ses partenaires se sont donc réunis et ont âprement négocié pour réduire le scope.

« Quelles sont les trois fonctionnalités que j’emporterais sur une île déserte ? » 

Adrien Winter, octo

Ce livrable de blockchain devait ainsi être axé en priorité sur les interactions entre les entreprises, et non intra-entreprise. Le résultat ? Un candidat de MVP. Le M et P sont là, la viabilité restait elle à confirmer grâce à une mise en production et des tests en réel (sur la base de KPI définis lors du cadrage). C’est donc le début d’une phase pilote du MVP candidat.    

Soulignons que fournisseur et constructeur ont contribué directement à ces étapes, aux côtés de Faurecia, l’instigateur du projet. Les trois partenaires se sont accordés sur sa finalité, à savoir de fluidifier les interactions au sein de la chaîne logistique sur la gestion des modifications sur des pièces.

Et mettre tout le monde d’accord n’est pas chose facile, souligne le directeur du numérique de Faurecia, Grégoire Ferré. « Tout le monde vient avec son propre a priori de là où il faut aller ou au contraire de ce qui est exclu. La question de la valeur est complexe. Elle doit porter sur un point faisant l’unanimité. C’est la condition incontournable pour rapprocher tous les acteurs. »

« Quand on dit blockchain, on pense souvent d’abord technologie. Mais la complexité provient avant tout du fait de réunir les acteurs souhaités autour de la même table et ensuite de les mettre d’accord. C’est le plus long à réaliser » confirme Maxence Finot, consultant stratégie pour Accenture.

Du côté de la solution technique, celle-ci devait prendre en compte trois besoins principaux par rapport aux règles métiers de cette industrie, des différents cas d’usage prévus et des échanges transactionnels qui en découlent : interopérabilité, confidentialité et relations dynamiques.

A ainsi été retenue la plateforme Corda, « véritablement centrée sur les relations dynamiques. » En mars, la construction du MVP était en cours de finalisation. Cependant, du fait « de vents contraires » au sein de l’automobile, l’exécution a été mise en pause. « Mais on le lancera, c’est absolument certain » assure le CDO de Faurecia.