Registre partagé : les 3 questions à poser avant d’envisager une DLT
La présence de plusieurs entreprises dans un même processus ne suffit pas à justifier une Blockchain.
Le besoin de traçabilité non plus.
Et le fait qu’un processus comporte de nombreux échanges de données ne constitue pas, à lui seul, un cas d’usage DLT.
Avant de parler de technologie, une direction peut soumettre l’opportunité à trois questions simples :
1. Plusieurs acteurs autonomes doivent-ils écrire ou vérifier les mêmes événements ?
2. Les réconciliations, litiges ou contrôles entre eux ont-ils un coût mesurable ?
3. Existe-t-il une bonne raison pour qu’aucun acteur ne puisse administrer seul la vérité commune ?
Si ces trois conditions sont réellement présentes, un registre partagé mérite d’être étudié.
Sinon, une architecture conventionnelle sera souvent plus simple.
Un registre partagé n’est pas nécessairement une Blockchain
Il faut d’abord distinguer le besoin de la technologie.
Une organisation peut avoir besoin d’un référentiel commun, d’une meilleure traçabilité ou d’un historique vérifiable sans avoir besoin d’une DLT.
Une base de données partagée, une API, une plateforme centrale, un workflow, une signature électronique ou un système de journalisation peuvent répondre efficacement à de nombreux besoins.
La bonne question n’est donc pas :
« Peut-on utiliser une Blockchain ici ? »
Techniquement, la réponse sera souvent oui.
La question pertinente est :
« Pourquoi faudrait-il distribuer la tenue du registre entre plusieurs participants plutôt que confier sa gouvernance à un acteur clairement identifié ? »
C’est cette distinction qui évite de transformer un problème d’intégration en projet Blockchain.
Question 1 — Plusieurs acteurs autonomes doivent-ils partager les mêmes événements ?
Une DLT commence à devenir intéressante lorsqu’un processus ne se déroule pas uniquement à l’intérieur d’une organisation.
Il peut impliquer par exemple :
- fournisseur ;
- industriel ;
- transporteur ;
- distributeur ;
- banque ;
- assureur ;
- prestataire technique ;
- autorité ou fonction de contrôle ;
- client professionnel.
Ces participants disposent souvent de leurs propres systèmes d’information, règles internes et responsabilités.
Ils ne partagent donc pas nécessairement une même base de données.
Prenons un événement simple :
« La marchandise a été livrée. »
Pour le fournisseur, cet événement peut déclencher une facture.
Pour le client, il peut nécessiter une réception et un contrôle.
Pour le logisticien, il clôt une prestation.
Pour la finance, il peut autoriser un paiement.
Pour l’assureur, il peut modifier l’état du risque.
Le même fait opérationnel est donc utilisé par plusieurs acteurs.
La première question consiste alors à déterminer si ces acteurs doivent seulement recevoir une information, ou s’ils doivent réellement partager et vérifier un événement commun.
Cette nuance est importante.
Si une entreprise produit l’information et que toutes les autres peuvent légitimement lui faire confiance, une API peut suffire.
Si, en revanche, plusieurs parties produisent, vérifient ou contestent les événements au cours du processus, la question du registre partagé devient plus sérieuse.
Question 2 — La réconciliation a-t-elle un coût mesurable ?
Le simple fait que plusieurs systèmes existent n’est pas un problème.
Le problème apparaît lorsque leurs différences créent du travail, du délai ou du risque.
Les organisations peuvent maintenir leurs propres versions d’un même événement :
- commande validée ;
- marchandise expédiée ;
- prestation réalisée ;
- document reçu ;
- contrôle effectué ;
- paiement déclenché ;
- actif transféré ;
- intervention terminée.
Lorsque les versions divergent, il faut les rapprocher.
Cela peut produire :
- recherches manuelles ;
- échanges de courriels ;
- contrôles de justificatifs ;
- appels entre équipes ;
- suspensions de paiement ;
- litiges ;
- retraitements comptables ;
- contrôles supplémentaires ;
- temps d’audit.
Le deuxième test consiste donc à mesurer ce coût.
Combien de rapprochements sont réalisés ?
Combien d’exceptions apparaissent ?
Combien de temps faut-il pour résoudre une divergence ?
Quel montant reste bloqué lorsqu’une information n’est pas reconnue par toutes les parties ?
Combien coûte la reconstitution de l’historique en cas de contrôle ou de litige ?
Sans réponse à ces questions, le bénéfice potentiel d’un registre partagé reste théorique.
Une DLT peut éliminer certaines réconciliations uniquement si celles-ci constituent réellement une source significative de friction.
Question 3 — Qui doit administrer la vérité commune ?
C’est probablement la question la plus discriminante.
Imaginons qu’une entreprise dispose d’une autorité légitime sur le processus.
Elle peut :
- gérer le référentiel ;
- attribuer les droits d’accès ;
- corriger les erreurs ;
- garantir la disponibilité ;
- produire l’historique ;
- arbitrer les contestations.
Dans ce cas, pourquoi distribuer cette responsabilité ?
Une architecture centralisée peut être plus simple, moins coûteuse et plus facile à exploiter.
La logique change lorsque plusieurs organisations autonomes doivent partager une information sans souhaiter dépendre entièrement de l’une d’entre elles.
Cela peut arriver lorsque :
- aucun participant ne possède naturellement l’ensemble du processus ;
- plusieurs entreprises ont des intérêts différents ;
- chacun doit pouvoir vérifier l’historique ;
- les responsabilités sont réparties ;
- l’intégrité du registre commun constitue elle-même une exigence de gouvernance.
Dans cette situation, la distribution du contrôle peut avoir une valeur.
La DLT ne sert alors pas simplement à stocker des données.
Elle sert à organiser qui peut écrire, qui peut vérifier et selon quelles règles la vérité commune évolue.
Un quatrième signal : la chronologie ou l’origine ont-elles une valeur ?
Une fois les trois critères fondamentaux établis, un autre élément peut renforcer le cas d’usage :
la valeur de la preuve.
Certaines opérations exigent de pouvoir démontrer :
- qui a produit une information ;
- quand elle a été produite ;
- dans quel ordre plusieurs événements se sont produits ;
- si un justificatif a été modifié ;
- quel acteur a validé une étape ;
- quelle version existait à un instant donné.
Cette exigence d’intégrité, d’origine ou de chronologie peut rendre un registre partagé particulièrement intéressant.
Mais elle ne suffit pas seule.
Une organisation unique peut également obtenir une excellente journalisation avec des technologies conventionnelles.
La question reste donc toujours liée à la gouvernance multi-acteurs.
Le test peut conduire à trois résultats
Après analyse, une organisation devrait pouvoir aboutir à l’une de trois conclusions.
1. Solution conventionnelle
Le processus possède un propriétaire clair.
Les acteurs font confiance à ce référentiel.
Le principal problème concerne l’intégration ou l’automatisation.
Une API, un workflow ou une base de données peut donc être préférable.
2. Registre partagé à approfondir
Plusieurs acteurs doivent partager des événements.
La réconciliation produit un coût significatif.
La gouvernance ne peut pas raisonnablement être concentrée chez un seul participant.
Une DLT ou une autre architecture de registre partagé mérite alors une étude détaillée.
3. No-Go
Le problème est insuffisamment important, mal mesuré ou trop peu structuré.
Dans ce cas, il est préférable de ne pas poursuivre.
Ce troisième résultat est aussi important que les deux autres.
Le but d’un diagnostic n’est pas de fabriquer un cas Blockchain. Il est de prendre une décision rationnelle.
Une DLT doit ensuite être comparée aux alternatives
Franchir les trois premières questions n’autorise pas automatiquement un projet Blockchain.
Cela signifie seulement que l’hypothèse mérite d’être étudiée.
Il reste à comparer :
- amélioration du processus ;
- intégration par API ;
- base de données partagée ;
- automatisation centralisée ;
- plateforme opérée par un tiers ;
- DLT permissionnée ;
- architecture hybride ;
- éventuellement infrastructure publique selon la nature du besoin.
Cette comparaison doit prendre en compte :
Valeur.
Quels coûts, délais ou risques sont réellement réduits ?
TCO.
Quel est le coût complet de conception, intégration, sécurité, exploitation et évolution ?
Gouvernance.
Qui opère le réseau, attribue les permissions et arbitre les incidents ?
Données.
Quelles informations doivent être partagées et lesquelles doivent rester hors registre ?
Sécurité.
Comment sont gérées identités, clés, accès et continuité ?
Conformité.
Quelles validations sont nécessaires selon le service, les acteurs et les données concernés ?
Adoption.
Pourquoi chaque participant accepterait-il de rejoindre le dispositif ?
Une architecture distribuée n’est supérieure que si son avantage reste défendable après cette comparaison.
Le piège du « besoin de confiance »
L’expression est souvent utilisée pour justifier une Blockchain :
« Nous avons besoin de confiance entre les participants. »
Mais toutes les relations économiques reposent sur une forme de confiance.
Ce critère est donc trop large.
La formulation correcte est plutôt :
« Plusieurs acteurs autonomes doivent-ils partager une preuve ou un état commun sans vouloir déléguer entièrement son administration à l’un d’entre eux ? »
Cette question est beaucoup plus exigeante.
Et beaucoup plus utile.
Elle permet de distinguer un problème de confiance distribuée d’un simple problème d’organisation, de qualité de données ou d’intégration.
La règle de décision
Avant d’engager une étude DLT, un CODIR peut donc demander :
Plusieurs acteurs doivent-ils réellement partager ou vérifier les mêmes événements ?
Les divergences entre leurs systèmes produisent-elles un coût significatif ?
Existe-t-il une raison solide pour qu’aucun acteur ne puisse gérer seul le référentiel commun ?
Si la réponse est non à ces questions fondamentales, la Blockchain ne devrait probablement pas être le point de départ de la conception.
Si la réponse est oui, l’organisation dispose alors d’une hypothèse sérieuse à comparer aux solutions conventionnelles.
C’est exactement la discipline recherchée par la Méthode F5 : ne jamais transformer l’éligibilité technologique en présomption.
La technologie doit gagner sa place dans le business case.
Vous envisagez un registre partagé entre plusieurs organisations ?
Maymana Consulting aide les entreprises et institutions à qualifier les acteurs, les événements partagés, les coûts de réconciliation et les modèles de gouvernance avant toute décision d’architecture.