Pourquoi un projet Blockchain ne devrait jamais commencer par la Blockchain
La première question d’un projet Blockchain ne devrait pas être : « Quelle Blockchain utiliser ? »
Elle devrait être beaucoup plus simple :
« Quel problème voulons-nous réellement résoudre ? »
Dans une grande organisation, commencer par la technologie crée un biais immédiat. Une plateforme est envisagée avant que le problème soit précisément défini. Des cas d’usage sont ensuite recherchés pour justifier ce choix. Le pilote finit par démontrer que la technologie fonctionne, sans nécessairement démontrer qu’elle apporte une valeur supérieure à une solution conventionnelle.
Une démarche rigoureuse procède dans l’ordre inverse.
Elle part d’une friction opérationnelle, établit une baseline, mesure l’impact de cette friction, compare les différentes options disponibles et ne retient une Blockchain ou une DLT que lorsque leur avantage peut être défendu.
Partir du problème, pas de la solution
Les organisations accumulent des frictions parfois peu visibles dans leurs systèmes de reporting :
- réconciliations entre plusieurs acteurs ou systèmes ;
- doubles saisies et validations successives ;
- délais de règlement ou de traitement ;
- litiges liés à l’origine ou à l’état d’une information ;
- difficulté à reconstituer une chronologie fiable ;
- multiplication des contrôles documentaires ;
- manque de visibilité entre plusieurs organisations ;
- dépendance à un intermédiaire chargé d’administrer la vérité commune.
Certaines de ces situations peuvent justifier l’utilisation d’un registre partagé.
Beaucoup d’autres non.
Une mauvaise qualité de données ne devient pas meilleure parce qu’elle est enregistrée sur une Blockchain. Un processus mal conçu ne devient pas performant parce qu’un smart contract en automatise certaines étapes. Et lorsqu’une seule organisation possède légitimement le référentiel et peut en assurer la gouvernance, une base de données classique peut être plus simple, plus économique et plus appropriée.
Le diagnostic doit donc précéder l’architecture.
Une friction doit d’abord être observable
Dire qu’un processus est « lent », « complexe » ou « coûteux » ne suffit pas.
Avant d’envisager sa transformation, il faut pouvoir décrire la situation existante avec des éléments factuels.
Combien de temps prend réellement le processus ?
Combien d’interventions manuelles nécessite-t-il ?
Combien de rapprochements ou de contrôles sont réalisés ?
Quel est le coût des erreurs, litiges ou exceptions ?
Quelles ressources restent immobilisées pendant le traitement ?
Quels acteurs produisent, modifient, valident ou contestent l’information ?
Cette photographie constitue la baseline.
Sans elle, il devient extrêmement difficile de distinguer une amélioration réelle d’une simple démonstration technologique.
Et sans baseline, parler de ROI est prématuré.
Traduire la friction en valeur
Une friction opérationnelle devient stratégique lorsqu’il est possible de relier sa résolution à un résultat métier.
Selon le processus étudié, la valeur peut provenir de plusieurs sources :
Réduction des coûts.
Moins de rapprochements, de saisies manuelles, de contrôles redondants ou de traitements d’exception.
Accélération des flux.
Réduction des délais de traitement, de validation, de règlement ou de circulation documentaire.
Réduction du risque.
Meilleure traçabilité, meilleure qualité des preuves, diminution des erreurs ou simplification de certains contrôles.
Amélioration du besoin en fonds de roulement.
Lorsque la friction provoque des délais de règlement, des immobilisations ou une mauvaise synchronisation des opérations.
Création de nouveaux services.
Lorsqu’une infrastructure de confiance permet de fournir à des clients ou partenaires une preuve, une traçabilité, une identité ou un mécanisme de coordination qu’ils sont prêts à valoriser.
Ce n’est qu’à ce stade que le projet peut commencer à être évalué économiquement.
Blockchain ou solution conventionnelle ?
La question n’est pas de savoir si la Blockchain peut techniquement réaliser une fonction.
Dans de nombreux cas, elle le peut.
La question utile est :
Apporte-t-elle un avantage suffisamment important par rapport aux alternatives pour justifier sa complexité supplémentaire ?
Une décision sérieuse devrait donc comparer plusieurs scénarios :
- amélioration du processus existant ;
- workflow ou automatisation conventionnelle ;
- API entre les systèmes concernés ;
- base de données ou référentiel partagé ;
- signature électronique ou mécanisme de preuve existant ;
- architecture DLT permissionnée ;
- architecture hybride ;
- éventuellement infrastructure publique lorsqu’elle est réellement pertinente.
La Blockchain n’est ainsi plus le point de départ du raisonnement. Elle devient une hypothèse parmi plusieurs
Quand un registre partagé devient-il réellement intéressant ?
Une architecture distribuée devient plus pertinente lorsque plusieurs conditions apparaissent simultanément.
Il existe plusieurs organisations ou entités qui doivent écrire, vérifier ou utiliser les mêmes événements.
Les rapprochements entre leurs systèmes ont un coût ou créent des litiges.
Aucun acteur ne devrait pouvoir modifier seul l’historique commun sans contrôle des autres participants.
L’origine, l’intégrité ou la chronologie d’un événement possède une valeur opérationnelle.
Les participants ont intérêt à utiliser un référentiel commun tout en conservant leur autonomie.
Plus ces caractéristiques sont absentes, plus il devient nécessaire de se demander si une architecture conventionnelle ne constitue pas une meilleure réponse.
Cette capacité à recommander une solution sans Blockchain fait partie d’un diagnostic professionnel.
Le No-Go est aussi une décision de valeur
Un projet de transformation n’est pas réussi uniquement lorsqu’il débouche sur un déploiement.
Il peut également être réussi lorsqu’il permet de conclure suffisamment tôt que l’investissement ne se justifie pas.
Un No-Go documenté peut éviter :
- un pilote sans véritable problème métier ;
- une architecture inutilement complexe ;
- des coûts d’intégration disproportionnés ;
- une dépendance fournisseur supplémentaire ;
- des risques juridiques ou cyber injustifiés ;
- plusieurs mois de mobilisation d’équipes rares.
La capacité à arrêter fait donc partie de la gouvernance du projet.
Une transformation maîtrisée doit comporter des portes de décision explicites permettant de poursuivre, corriger, différer ou arrêter.
Un pilote ne doit pas simplement prouver que la technologie fonctionne
Une démonstration technique peut montrer qu’un registre enregistre des transactions, qu’un smart contract s’exécute ou qu’une application interagit avec une infrastructure DLT.
Cela ne répond cependant qu’à une partie de la question.
Pour une direction, le véritable enjeu est de savoir si la solution :
- améliore les indicateurs par rapport à la baseline ;
- s’intègre correctement au système d’information ;
- respecte les exigences de sécurité et de données ;
- peut être utilisée par les acteurs concernés ;
- reste exploitable à un coût acceptable ;
- possède un modèle de gouvernance viable ;
- conserve son intérêt lorsqu’elle passe à l’échelle.
C’est pourquoi Maymana privilégie la logique de Proof of Business : prouver simultanément la faisabilité, la valeur, l’adoption et l’exploitabilité.
La technologie devient alors une composante de la preuve — et non la preuve elle-même.
La conformité doit commencer avant l’architecture
Le même raisonnement vaut pour la conformité, la cybersécurité et les données.
Elles ne peuvent pas être ajoutées à la fin d’un pilote déjà construit.
La nature des acteurs, des flux, des informations manipulées, des droits représentés et du service proposé peut modifier profondément les architectures envisageables.
Le cadrage initial doit donc identifier suffisamment tôt :
- les catégories de données concernées ;
- les responsabilités des différents acteurs ;
- les exigences de confidentialité ;
- les risques cyber ;
- les dépendances à des tiers ;
- les contraintes réglementaires potentielles ;
- les validations nécessaires avant expérimentation.
La profondeur de l’analyse augmente ensuite avec le projet.
Le principe reste constant : concevoir avec les contraintes réelles plutôt que tenter de les ajouter après coup.
Une transformation Blockchain est d’abord une suite de décisions
Vue de cette manière, une transformation ne consiste plus à « déployer une Blockchain ».
Elle consiste à répondre successivement à plusieurs questions :
Pourquoi agir ?
Quel problème ou quelle opportunité justifie l’exploration ?
Où se situe la friction ?
Que montrent réellement les processus, les données et la baseline ?
Quelle valeur peut être créée ?
Quel impact économique ou opérationnel peut être défendu ?
Quelle solution est la plus pertinente ?
Une DLT apporte-t-elle réellement plus de valeur qu’une alternative conventionnelle ?
La solution fonctionne-t-elle dans les conditions réelles ?
La valeur, l’adoption, la sécurité, l’intégration et l’exploitabilité sont-elles démontrées ?
Faut-il industrialiser ?
Les résultats justifient-ils un passage à l’échelle et sous quelles conditions ?
C’est précisément cette logique que structure la Méthode F5 de Maymana Consulting : cadrer, observer, quantifier, concevoir, prouver puis industrialiser uniquement lorsque les preuves justifient la décision.
La bonne question pour un CODIR
Lorsqu’une opportunité Blockchain est présentée à une direction, la question la plus utile n’est donc pas :
« Quelle technologie allons-nous déployer ? »
Mais :
« Quelle friction voulons-nous éliminer, combien nous coûte-t-elle aujourd’hui, et pourquoi une architecture distribuée serait-elle meilleure que les autres options ? »
Si ces trois éléments ne peuvent pas être établis, il est probablement trop tôt pour parler de Blockchain.
Si, au contraire, ils peuvent être démontrés, alors la technologie peut être étudiée rationnellement — avec un business case, des critères d’acceptation et une possibilité explicite d’arrêter.
Vous avez identifié une friction à fort impact ?
Maymana Consulting accompagne les entreprises et institutions dans la qualification des frictions, la construction du business case et la comparaison entre solutions conventionnelles, DLT et Blockchain avant tout engagement d’investissement.