Blockchain, API ou base de données : comment choisir la bonne architecture ?
Blockchain, API ou base de données ?
La question paraît technologique.
Elle ne l’est pas vraiment.
Une organisation qui arrive à ce stade devrait déjà avoir répondu à deux questions plus importantes :
Quelle friction voulons-nous transformer ?
et
Quelle est notre situation de départ ?
Ce n’est qu’une fois la friction observée et la baseline établie qu’il devient pertinent de comparer les architectures.
À ce moment-là, la Blockchain ne bénéficie d’aucun traitement de faveur.
Elle doit démontrer qu’elle offre un meilleur rapport :
valeur / coût / risque
que les alternatives disponibles.
La première option est parfois de ne rien reconstruire
Lorsqu’une friction est identifiée, l’organisation a souvent tendance à chercher immédiatement une nouvelle solution technique.
Mais la première question devrait être :
peut-on simplement améliorer le processus existant ?
Certaines inefficacités proviennent de :
- responsabilités mal définies ;
- validations inutiles ;
- doublons ;
- procédures historiques ;
- règles devenues obsolètes ;
- données mal structurées ;
- absence de gouvernance.
Dans ces situations, ajouter une nouvelle technologie peut simplement automatiser une mauvaise organisation.
Une simplification du processus peut alors produire davantage de valeur qu’une nouvelle architecture.
C’est pourquoi F2 commence par comparer les options — et non par sélectionner une technologie.
Option 1 — Améliorer le processus
Cette option est particulièrement pertinente lorsque :
- un acteur possède clairement le processus ;
- les problèmes sont principalement organisationnels ;
- les systèmes existants peuvent déjà supporter le besoin ;
- les contrôles sont trop nombreux ou mal séquencés ;
- les rôles sont ambigus ;
- le principal gain peut être obtenu sans investissement technologique significatif.
L’avantage est évident :
faible complexité, faible coût, réversibilité élevée.
Elle doit donc toujours faire partie de la comparaison.
Option 2 — Renforcer l’ERP ou utiliser des API
Beaucoup de frictions sont en réalité des problèmes d’intégration.
Deux applications disposent de la bonne information, mais ne communiquent pas correctement.
Des équipes ressaisissent alors des données.
Des fichiers intermédiaires circulent.
Des contrôles manuels compensent l’absence d’interface.
Dans ce contexte, une API peut être la bonne réponse.
Elle permet notamment :
- d’échanger automatiquement des données ;
- de synchroniser plusieurs applications ;
- d’éviter certaines ressaisies ;
- de déclencher des opérations ;
- de réduire les délais ;
- de maintenir les responsabilités existantes.
Si une organisation ou une plateforme peut légitimement orchestrer les échanges, une architecture API peut être beaucoup plus simple qu’un registre distribué.
Option 3 — Utiliser une base de données ou un référentiel partagé
Lorsqu’un ensemble d’acteurs doit accéder à la même information, une base de données partagée peut suffire.
Elle est particulièrement adaptée lorsque :
- un administrateur central est accepté ;
- les droits peuvent être gérés par une organisation identifiée ;
- les participants font confiance au propriétaire du référentiel ;
- les exigences de traçabilité peuvent être satisfaites par une journalisation conventionnelle ;
- les volumes ou performances nécessitent une architecture centralisée simple.
Une base de données n’est donc pas une version « moins avancée » d’une Blockchain.
Elle répond simplement à un modèle de gouvernance différent.
Dans beaucoup de situations, c’est l’architecture la plus rationnelle.
Option 4 — Automatiser par workflow ou règles centralisées
Certaines frictions proviennent moins du stockage des données que de l’exécution des règles.
Par exemple :
- valider automatiquement un dossier complet ;
- déclencher un paiement après confirmation ;
- envoyer une alerte ;
- appliquer une règle de contrôle ;
- router une exception vers la bonne équipe.
Ces usages peuvent être traités avec :
- moteurs de workflow ;
- règles métiers ;
- BPM ;
- automatisation ;
- orchestration applicative.
Il n’est pas nécessaire d’utiliser un smart contract simplement parce qu’une règle peut être programmée.
La question est de savoir où la règle doit être exécutée et qui doit en contrôler l’évolution.
Option 5 — Étudier une DLT ou une Blockchain
Une architecture distribuée devient plus intéressante lorsque plusieurs conditions apparaissent ensemble :
- plusieurs acteurs autonomes participent au processus ;
- ils doivent partager ou vérifier les mêmes événements ;
- les réconciliations entre leurs systèmes produisent un coût mesurable ;
- aucun acteur ne devrait pouvoir administrer seul le référentiel ;
- l’origine, l’intégrité ou la chronologie ont une valeur ;
- les règles communes peuvent être formalisées ;
- tous les participants disposent d’un intérêt suffisant à rejoindre le dispositif.
La Méthode F5 utilise précisément ces critères pour éviter de traiter toute problématique multi-acteurs comme un cas Blockchain.
Mais même lorsque ces critères existent, cela ne signifie pas que la DLT est automatiquement gagnante.
Elle doit encore passer le business case.
Comparer selon la valeur
La première dimension est la plus importante :
quelle valeur chaque option crée-t-elle réellement ?
Selon le processus, cela peut concerner :
- réduction du délai ;
- baisse du coût de traitement ;
- diminution des litiges ;
- amélioration du BFR ;
- accélération du cash-flow ;
- réduction du risque ;
- meilleure auditabilité ;
- nouveau service ;
- nouveau revenu.
Une architecture plus sophistiquée n’a aucune valeur si elle ne produit pas un résultat supérieur.
La technologie doit donc être reliée à la baseline et aux indicateurs définis précédemment.
Comparer le coût complet, pas seulement le coût du développement
Une mauvaise comparaison consiste à regarder uniquement le prix de construction.
Il faut examiner le TCO — Total Cost of Ownership.
Il peut comprendre :
- développement ;
- intégration ;
- infrastructure ;
- licences ;
- sécurité ;
- gestion des identités ;
- exploitation ;
- support ;
- monitoring ;
- gouvernance ;
- formation ;
- évolution ;
- fournisseurs ;
- continuité ;
- réversibilité.
Une DLT qui réduit fortement une friction mais nécessite une gouvernance extrêmement coûteuse peut perdre la comparaison face à une solution conventionnelle.
Inversement, une architecture distribuée peut justifier son coût si elle supprime durablement des réconciliations importantes entre plusieurs organisations.
Comparer le risque
La meilleure option économique n’est pas toujours celle qui présente le risque le plus acceptable.
Il faut notamment examiner :
- sécurité ;
- données ;
- conformité ;
- dépendance fournisseur ;
- risque opérationnel ;
- continuité ;
- capacité d’exploitation ;
- réversibilité ;
- adoption par l’écosystème.
C’est particulièrement important lorsqu’une architecture introduit plusieurs organisations, des clés cryptographiques ou de nouvelles responsabilités.
La sophistication technique peut augmenter le risque autant qu’elle crée de la valeur.
Comparer la gouvernance
C’est l’un des éléments qui distinguent le plus fortement les architectures.
Avec une base de données classique, la question est généralement simple :
qui administre le système ?
Avec une DLT, il faut également déterminer :
- qui peut participer ;
- qui peut écrire ;
- qui valide ;
- qui modifie les règles ;
- qui gère les identités ;
- qui révoque un participant ;
- qui finance l’infrastructure ;
- qui traite un incident ;
- comment le réseau évolue ;
- comment un acteur peut sortir.
La gouvernance n’est donc pas une couche ajoutée après la technologie.
Elle fait partie de l’architecture elle-même.
Comparer l’intégration avec l’existant
Une entreprise ne travaille pas sur une feuille blanche.
Elle possède déjà :
- ERP ;
- CRM ;
- bases de données ;
- référentiels ;
- outils de conformité ;
- systèmes d’identité ;
- API ;
- infrastructure cloud ;
- politiques de sécurité.
La bonne architecture doit compléter cet environnement.
Elle ne doit pas imposer une reconstruction globale lorsque l’intégration est possible.
La Méthode F5 privilégie précisément une modernisation ciblée, progressive et réversible plutôt qu’une migration générale Web2 vers Web3.
Comparer l’adoption
Une solution multi-acteurs peut être techniquement excellente et économiquement attractive pour une entreprise tout en échouant pour une raison simple :
les autres participants n’ont aucune raison de l’utiliser.
Le business case doit donc examiner la valeur distribuée.
Pourquoi :
- le fournisseur ;
- le client ;
- le partenaire ;
- la banque ;
- le logisticien ;
- l’autorité ;
- ou le prestataire
accepterait-il de modifier ses processus ?
Un réseau ne crée de valeur que si suffisamment de participants trouvent eux-mêmes un intérêt à y contribuer.
Le résultat de F2 doit être une décision
Une bonne comparaison ne doit pas produire une liste de technologies.
Elle doit aboutir à une recommandation.
Dans la Méthode F5, trois résultats sont parfaitement légitimes.
NO-GO
La friction existe, mais la valeur potentielle ne justifie pas le coût, le risque ou l’effort.
La meilleure décision est d’arrêter.
SOLUTION CONVENTIONNELLE
La transformation est pertinente, mais :
- amélioration de processus ;
- ERP ;
- API ;
- base de données ;
- workflow ;
- automatisation
répondent mieux au besoin.
Ce résultat est pleinement conforme à la Méthode F5 : la Blockchain n’est retenue que lorsqu’elle apporte une valeur supérieure.
PASSAGE À F3
La valeur est significative.
Une DLT présente un avantage défendable.
La gouvernance est envisageable.
Les risques semblent maîtrisables.
L’organisation peut alors engager la conception détaillée.
La Blockchain doit gagner la comparaison
Cette règle peut sembler restrictive pour un cabinet spécialisé dans les transformations Blockchain, DLT et Web3.
Elle est au contraire essentielle à la crédibilité de la démarche.
Le métier d’un cabinet n’est pas de démontrer que sa technologie préférée doit être utilisée.
Il est d’aider le client à prendre une meilleure décision d’investissement.
Une architecture distribuée mérite d’être retenue lorsqu’elle crée une valeur que les solutions plus simples ne peuvent pas reproduire avec un niveau de coût et de risque inférieur.
Sinon, elle ne doit pas passer en conception.
Une matrice simple pour un CODIR
Une direction peut demander que chaque option soit comparée au minimum sur six dimensions :
| Dimension | Question |
|---|---|
| Valeur | Quel bénéfice mesurable par rapport à la baseline ? |
| Coût | Quel TCO pour construire, intégrer et exploiter ? |
| Risque | Quels risques opérationnels, cyber, données et conformité ? |
| Gouvernance | Qui administre, décide et arbitre ? |
| Intégration | Comment la solution s’insère-t-elle dans le SI existant ? |
| Adoption | Pourquoi les utilisateurs et partenaires l’adopteront-ils ? |
L’objectif n’est pas de donner artificiellement le même score à toutes les options.
Il est de rendre le raisonnement visible et défendable.
La question à poser avant d’autoriser F3
Avant de financer une architecture ou un pilote, un CODIR peut donc demander :
« Quelles alternatives avons-nous comparées, et pourquoi cette option crée-t-elle davantage de valeur pour un niveau de coût et de risque acceptable ? »
Si la réponse est simplement :
« Parce que nous voulons tester la Blockchain »
le business case n’est pas terminé.
Si, en revanche, le processus, les API, la base de données, l’automatisation et la DLT ont réellement été comparés, la décision devient beaucoup plus robuste.
La bonne architecture n’est pas la plus innovante.
C’est celle qui gagne la comparaison.
Vous devez arbitrer entre plusieurs architectures ?
Maymana Consulting accompagne les entreprises et institutions dans la quantification des frictions, la comparaison des alternatives, le business case et la décision No-Go, solution conventionnelle ou passage à une architecture DLT.