Blockchain privée ou publique : comment choisir et quand s’en passer (2026)

Voici une vérité regrettable sur le débat entre blockchain privée et publique. Lorsque la plupart des équipes l’abordent, elles ont déjà fait le mauvais choix.

Le scénario est souvent le même. Un dirigeant lit un article sur la blockchain. Un prestataire présente son argumentaire commercial. Quelqu’un affirme « il faut une blockchain privée, car le public semble risqué », ou au contraire « nous devons être décentralisés, donc il faut une blockchain publique ». Un budget est accordé à une preuve de concept. Trois mois plus tard, l’équipe découvre que sa solution n’a pas besoin de blockchain, ou qu’elle exige un modèle totalement différent de celui en cours de développement.

Ce cycle peut être évité. La question du privé ou du public n’est pas la première à poser, ni même la deuxième. C’est la troisième, et la pertinence de toutes les décisions suivantes dépend des réponses aux précédentes.

Cet article adopte donc une autre approche. Il suit le véritable arbre de décision, dans l’ordre qu’une équipe technique compétente devrait respecter : faut-il une blockchain, avec ou sans autorisation, quelle plateforme choisir et quand renoncer ? Y compris les réponses que les vendeurs de conseil en blockchain préfèrent généralement taire.

 Les recommandations qui suivent reposent sur l’observation des solutions qui fonctionnent en production et de celles qui sont discrètement abandonnées douze mois après leur lancement.

Avez-vous vraiment besoin d’une blockchain ? (La question qui élimine 60 % des projets)

La plupart des cas d’usage développés sur blockchain auraient été mieux servis par une base de données distribuée bien conçue, avec des contrôles d’accès robustes, un journal d’audit signé et des sauvegardes fiables. La blockchain apporte deux éléments supplémentaires : la confiance décentralisée et la possibilité de détecter toute altération entre des parties qui ne se font pas entièrement confiance.

Si vous n’avez besoin d’aucun des deux, vous supportez inutilement les coûts de la blockchain. Car elle a un prix : elle est plus lente, plus coûteuse à exploiter, nécessite des compétences plus difficiles à recruter et devient nettement plus complexe à modifier après déploiement.

Voici un test simple en quatre points. La blockchain est adaptée lorsque :

• Plusieurs parties doivent partager un même état des données
• Ces parties ne se font pas entièrement confiance, ni à un intermédiaire unique
• Une source unique de vérité est réellement indispensable
• Le coût des litiges, des rapprochements ou des audits est suffisamment élevé pour justifier l’infrastructure

Si un seul de ces quatre critères manque, la réponse la plus raisonnable est probablement « utilisez une base de données ». S’il en manque au moins deux, c’est assurément la bonne réponse.

Quelques exemples concrets où la blockchain réussit ce test :

• Règlement interbancaire entre établissements concurrents qui ne passent pas les uns par les autres comme intermédiaires
• Traçabilité de la provenance dans une chaîne d’approvisionnement à plusieurs niveaux, dont aucune entreprise ne possède une vue complète
• Tokenisation d’actifs immobiliers fractionnés ou de titres non cotés, lorsque la conformité exige un historique de propriété vérifiable
• Protocoles de finance décentralisée dont l’objectif même est de permettre une participation ouverte sans intermédiaire de contrôle
• Attestations d’identité numérique entre administrations distinctes (une université délivre un diplôme, un employeur étranger le vérifie sans qu’aucun des deux ne dépende d’un registre central)

Voici où le test échoue, mais où des projets sont tout de même lancés :

• Gestion documentaire interne à une seule entreprise : une base de données avec stockage signé remplit cette fonction pour 2 % du coût
• Points de fidélité d’une seule enseigne : une base de données suffit, et la blockchain n’apporte aucune véritable décentralisation puisque l’enseigne contrôle déjà tout le système
• Pistes d’audit d’une entité réglementée : une base de données avec chaînage cryptographique suffit, et l’auditeur ne se préoccupe pas de savoir si les données sont sur une blockchain
• État « tokenisé » d’un processus interne : votre outil BPM sait déjà le gérer, utilisez-le

Tous ces cas sont réels. J’ai vu des équipes lancer ces projets, obtenir l’appui de leur direction, y consacrer six à dix mois, puis tout reconstruire discrètement sur Postgres un an plus tard, après le départ des consultants. Ces projets ne figurent jamais dans les études de cas. Ce n’est pas un hasard.

Si, après avoir répondu honnêtement à ces quatre questions, votre cas d’usage nécessite toujours une blockchain, vous avez franchi le premier filtre. La plupart des idées nées d’un « nous devrions explorer la blockchain » ne le passent pas. Celles qui y parviennent deviennent intéressantes. C’est alors que le choix entre privé et public prend tout son sens.

La vraie distinction n’est pas privé ou public, mais avec ou sans autorisation

Commençons par clarifier les termes, car une grande partie de la confusion vient de là. « Public » et « privé » sont des raccourcis, et des raccourcis imprécis. Les propriétés qui déterminent réellement les choix d’architecture sont l’accès avec ou sans autorisation.

Sans autorisation : tout le monde peut rejoindre le réseau, exploiter un nœud, valider et effectuer des transactions. Aucun contrôle d’accès central. La blockchain s’appuie sur la cryptographie et des incitations économiques pour garantir le bon comportement des participants. Ethereum, Bitcoin, Solana, Polygon PoS et Avalanche C-Chain sont les exemples classiques de réseaux sans autorisation.

Avec autorisation : les participants sont identifiés et autorisés à rejoindre le réseau. Une instance de gouvernance — consortium d’organisations, entreprise unique ou parfois régulateur — décide des admissions. La blockchain repose sur la cryptographie et l’identité institutionnelle. Hyperledger Fabric, R3 Corda et Quorum sont les exemples classiques de réseaux avec autorisation.

Il existe ensuite des variantes que les articles présentent volontiers comme des catégories distinctes, alors qu’elles ne le sont pas vraiment :

• Consortium : variante de réseau avec autorisation, gouvernée conjointement par plusieurs organisations. La plupart des blockchains d’entreprise sont des réseaux de consortium, même lorsque le marketing les qualifie de « privées ».
• Hybride : cœur de réseau avec autorisation, associé à un ancrage sur une blockchain publique pour permettre l’audit. Ce n’est pas vraiment une architecture à part, plutôt un modèle de déploiement de plus en plus répandu.

En pratique, la frontière public/privé est également poreuse. Polygon fonctionne sans autorisation sur sa couche de base, mais accepte des configurations avec autorisation. Ethereum peut être exploité sous forme de fork privé pour un consortium unique ; plusieurs grands déploiements d’entreprise le font déjà. L’important n’est pas la blockchain choisie, mais la manière dont vous configurez la participation, la validation et la visibilité des données.

Dans la suite, nous conserverons « privé » et « public », car ce sont les termes recherchés par les acheteurs. Comprenez toutefois « avec autorisation » et « sans autorisation ». Cette nuance est essentielle lors de la rédaction des exigences.

Définition des blockchains publiques et privées

Voici un rappel rapide pour les lecteurs qui arrivent directement à cette partie, avant les explications sur les réseaux avec ou sans autorisation. Passez cette section si vous maîtrisez déjà les bases.

Qu’est-ce qu’une blockchain publique ?

Une blockchain publique est un réseau ouvert, sans autorisation, où toute personne disposant d’une connexion Internet peut exploiter un nœud, valider des transactions et en effectuer. Il n’existe ni autorité centrale, ni gardien d’accès, ni liste de membres. Le registre est visible mondialement : chaque transaction, chaque adresse et chaque appel de smart contract est public. Bitcoin en est l’exemple classique. Ethereum est la référence des blockchains publiques compatibles avec les smart contracts. Solana, Polygon PoS et Avalanche appartiennent à la même catégorie malgré leurs architectures techniques différentes.

Le modèle de sécurité est économique. Les validateurs sont ceux qui acceptent d’immobiliser du capital (preuve d’enjeu) ou de consommer de l’électricité (preuve de travail). Le protocole est conçu pour rendre une attaque plus coûteuse qu’un comportement honnête. La confiance repose sur les mathématiques et les mécanismes de marché, plutôt que sur l’identité ou des accords juridiques.

Avantages d’une blockchain publique

Voici pourquoi une blockchain publique peut être pertinente lorsqu’elle correspond au besoin :

• Participation réellement ouverte : aucune procédure d’inscription, aucune obligation KYC au niveau du protocole, aucun responsable pouvant révoquer l’accès
• Transparence et auditabilité natives : l’état de la blockchain est visible de tous, ce qui peut parfois être un défaut, mais constitue souvent un avantage
• Résistance à la censure : aucune entité ne peut, seule, empêcher l’inclusion d’une transaction
• Effets de réseau et liquidité : les blockchains publiques, surtout Ethereum et ses L2, disposent d’écosystèmes riches en développeurs, outils et capitaux accessibles
• Interopérabilité avec l’écosystème crypto : stablecoins, ponts, composants DeFi et infrastructures NFT fonctionnent sur des blockchains publiques
• Immutabilité des transactions réglées : après confirmation, aucun opérateur ni administrateur ne peut annuler une transaction

Inconvénients d’une blockchain publique

Voici les coûts, sans les minimiser :

• Débit inférieur à celui d’une base de données ou d’une blockchain avec autorisation : même Solana et les L2 modernes restent en deçà des performances courantes des infrastructures d’entreprise
• Frais de transaction libellés dans le token natif de la blockchain, donc exposés au marché : les pics de frais de gas sont bien réels
• Confidentialité à ajouter plutôt qu’à configurer : les preuves ZK et le calcul hors chaîne sont possibles, mais exigent un effort d’ingénierie coûteux
• Cadre réglementaire des blockchains publiques évolutif et différent selon les juridictions : cette incertitude est réelle, pas un argument commercial
• Finalité probabiliste plutôt qu’immédiate sur de nombreuses blockchains publiques, ce qui compte pour les processus de règlement soumis à des SLA stricts
• Conformité aux régimes de protection des données, notamment au droit à l’effacement du RGPD, difficile à intégrer dans l’architecture d’un registre immuable

Qu’est-ce qu’une blockchain privée ?

Une blockchain privée — plus précisément, avec autorisation — est un réseau dont l’accès est contrôlé. Une instance de gouvernance, qu’il s’agisse d’une organisation, d’un consortium ou d’une autorité réglementaire, décide qui peut exploiter un nœud, valider les transactions et consulter les données. L’identité est intégrée au protocole et l’appartenance au réseau est explicite.

Hyperledger Fabric, R3 Corda et Quorum en sont les exemples classiques. Leur point commun tient moins à une technologie précise qu’à un modèle de gouvernance : la confiance repose sur l’identité institutionnelle et les accords juridiques entre participants identifiés, plutôt que sur des incitations économiques entre acteurs anonymes. Dans la plupart des déploiements réels, une blockchain « privée » est en fait un consortium : plusieurs organisations partagent la gouvernance, au lieu d’une entreprise exploitant seule son réseau.

Avantages d’une blockchain privée

Pourquoi les entreprises choisissent des blockchains privées :

• Débit élevé et faible latence : un consensus avec autorisation et peu de validateurs peut offrir une finalité en moins d’une seconde et des milliers de TPS
• Visibilité des données configurable : canaux, transactions privées et échanges point à point permettent à chaque participant de consulter différents sous-ensembles de données sans artifices cryptographiques
• Coûts prévisibles : dépenses d’exploitation plutôt que frais par transaction, sans exposition à la volatilité des tokens
• Conformité réglementaire pour les participants identifiés : les contrôles KYC et AML peuvent être intégrés au réseau, facilitant les échanges avec les entités réglementées
• Souplesse de gouvernance : le consortium peut mettre à jour le protocole, modifier les règles et régler les différends sans consensus mondial
• Protection des données facilitée : la correction ou la suppression partielle des données est techniquement possible si la gouvernance l’autorise

Inconvénients d’une blockchain privée

Voici les compromis, souvent minimisés dans le discours commercial sur les blockchains d’entreprise :

• Sécurité limitée par la fiabilité des validateurs : si 51 % des membres du consortium s’entendent ou sont compromis, l’historique peut être réécrit
• Effets de réseau limités au consortium : impossible de profiter directement de tout l’écosystème d’outils, de liquidité et de composabilité des blockchains publiques
• Charge opérationnelle réelle : exploiter l’infrastructure, gérer les membres, coordonner les mises à jour et résoudre les différends demande un effort continu
• Dépendance aux fournisseurs et au consortium : quitter un consortium Fabric ou migrer depuis Corda n’a rien de simple après engagement
• Gouvernance souvent plus difficile que la technologie : déterminer qui peut modifier quelle règle et à quel moment fait échouer davantage de consortiums que les problèmes techniques
• La question fondamentale de l’utilité même d’une blockchain (voir l’introduction) est encore plus importante pour les réseaux privés : on risque facilement de construire une base de données distribuée extrêmement coûteuse

Quatre critères de décision plus importants qu’un tableau de fonctionnalités

Les tableaux comparatifs habituels des articles sur la blockchain sont presque inutiles pour décider. « Le public offre la transparence, le privé la confidentialité » ne permet de concevoir aucune architecture. Quatre questions orientent réellement les choix techniques.

Qui peut participer ?

Le degré d’ouverture de l’accès. Les réseaux sans autorisation permettent à toute personne disposant d’Internet et d’un portefeuille de rejoindre le réseau et d’effectuer des transactions, sans vérification d’identité, contrôle d’accès ni procédure d’inscription. Les réseaux avec autorisation conditionnent la participation à des contrôles KYC, des accords d’adhésion ou des votes de gouvernance.

Lorsque les participants sont des entités réglementées — banques, courtiers agréés, établissements de santé ou administrations — un réseau avec autorisation est souvent imposé par la conformité. Votre régulateur veut savoir qui participe ; « n’importe qui sur Internet » n’est pas une réponse acceptable quand des données médicales ou des instructions de règlement circulent.

Lorsque la participation ouverte constitue l’objectif même du produit — DeFi grand public, marchés NFT ouverts, applications résistantes à la censure, transferts internationaux — l’absence d’autorisation est essentielle. Un contrôle d’accès irait à l’encontre du produit.

Cette seule question règle peut-être 60 % des débats entre privé et public. Si vous connaissez vos futurs utilisateurs et devez vérifier leur identité avant tout accès, vous construisez un réseau avec autorisation. Si vous ne les connaissez pas et ne souhaitez pas les identifier, vous construisez un réseau sans autorisation.

Qui valide les transactions ?

La couche de consensus. C’est ici que les conséquences architecturales deviennent concrètes.

Les blockchains sans autorisation utilisent un consensus fondé sur la sécurité économique. Preuve de travail (Bitcoin), preuve d’enjeu (Ethereum après The Merge, Solana, Polygon) et variantes de preuve d’enjeu déléguée. Les validateurs acceptent de mettre leur capital en jeu, et le protocole rend les attaques plus coûteuses que le respect des règles.

Les blockchains avec autorisation utilisent un consensus institutionnel : variantes de Practical Byzantine Fault Tolerance (PBFT), Raft ou Istanbul BFT. Les validateurs sont des organisations précises et identifiées qui ont accepté de participer. Le protocole doit simplement les maintenir synchronisées, même si une minorité agit mal ou se déconnecte.

Conséquences pratiques :

• Le consensus avec autorisation est beaucoup plus rapide : finalité en quelques millisecondes à quelques secondes, contre des blocs Ethereum d’environ 12 secondes ou quelque 60 minutes de finalité économique sur Bitcoin.
• Le consensus avec autorisation coûte nettement moins cher par transaction. Vous payez l’infrastructure, pas les frais de gas.
• La fiabilité du consensus avec autorisation dépend entièrement des institutions validatrices. Si 51 % de votre consortium décident de réécrire l’historique, elles le peuvent. La sécurité économique est remplacée par la réputation institutionnelle et les accords juridiques.

C’est pourquoi ce consensus convient à un réseau de règlement entre banques réglementées (leurs obligations juridiques et leur réputation rendent une collusion peu probable), mais pas à un système d’oracles décentralisé (dont l’objectif est précisément d’éviter ce risque de collusion).

Qui peut consulter les données ?

La couche de visibilité. Sur une blockchain publique sans autorisation, l’historique des transactions est visible mondialement par défaut. Chaque adresse, chaque montant, chaque appel de smart contract est public. Il faut ajouter la confidentialité au moyen de preuves à divulgation nulle de connaissance, de mécanismes d’engagement-révélation ou de calcul hors chaîne. C’est faisable, mais complexe et coûteux en calcul comme en temps d’ingénierie.

Sur une blockchain à accès autorisé, la visibilité des données est configurable dès la conception. Hyperledger Fabric propose des « canaux », autrement dit des sous-réseaux où certaines organisations accèdent à certaines données. Corda va plus loin : les données sont échangées directement entre participants, sans être répliquées partout. Quorum propose des transactions privées. Chacune de ces solutions permet de limiter l’accès à différents ensembles de données sans montages cryptographiques complexes.

Pour les entreprises soumises à de réelles exigences de confidentialité — stratégies de trading, dossiers médicaux, tarifs fournisseurs — les blockchains à accès autorisé sont nettement plus simples à déployer. Non que la confidentialité soit impossible sur les réseaux publics, mais le budget consacré aux circuits ZK et aux couches de confidentialité serait mieux employé dans une blockchain offrant nativement une visibilité sélective.

Qui finance son fonctionnement ?

La dimension économique, à laquelle presque personne ne pense avant la deuxième année d’exploitation.

Les blockchains publiques facturent les transactions dans leur token natif : ETH sur Ethereum, MATIC sur Polygon, SOL sur Solana. L’exploitant d’une DApp paie chaque transaction, avec des coûts susceptibles de grimper sans prévenir : certaines émissions de NFT ont brièvement porté les frais de gas sur Ethereum à 200 $ par transaction. Vos coûts d’exploitation dépendent donc de l’usage et des marchés.

Les blockchains à accès autorisé sont financées directement par les membres du consortium. Il s’agit de coûts d’infrastructure — serveurs, exploitation, supervision — plutôt que de frais de transaction. Ils sont plus prévisibles et moins exposés aux fluctuations du token natif.

Sur la durée et avec de gros volumes de transactions, les réseaux à accès autorisé sont généralement moins coûteux. À faible volume, leurs coûts fixes d’infrastructure peuvent rendre les réseaux publics plus économiques, surtout depuis que les L2 comme Arbitrum et Base ont abaissé les frais de transaction à des fractions de centime.

Les plateformes qui comptent vraiment en 2026

Cette section présente les plateformes qui figurent réellement dans les sélections des entreprises. Il existe désormais des centaines de L1 et de L2. La plupart ne changent rien à votre décision. Celles-ci, si.

Ethereum (sans autorisation)

Le choix de référence pour les smart contracts ouverts et programmables. Après The Merge et le déploiement de multiples rollups L2 (Optimism, Arbitrum, Base, zkSync, Scroll), Ethereum est en 2026 davantage un écosystème qu’une blockchain unique.

Pour les entreprises, les L2 compatibles avec Ethereum sont généralement plus pertinentes que le réseau principal. Elles sont beaucoup moins chères, offrent une finalité plus rapide et bénéficient toujours du modèle de sécurité d’Ethereum pour le règlement. Le réseau principal convient aux opérations exigeant une décentralisation maximale et pouvant supporter 1 à 5 $ par transaction. Aujourd’hui, la plupart des applications fonctionnent sur les L2.

Points forts : de loin le plus vaste écosystème de développeurs, outils les plus éprouvés, liquidité la plus profonde et bonne connaissance des régulateurs. Limites : le paysage des L2 reste fragmenté, les transferts entre L2 posent toujours des problèmes d’UX et choisir « Ethereum » implique désormais de choisir aussi une L2. Consultez notre article sur le développement Ethereum pour faire le point.

Polygon (sans autorisation, compatible Ethereum)

L’option publique de référence pour les entreprises. Compatible EVM, frais faibles et déploiements réels en entreprise : Starbucks Odyssey avant son arrêt, Nike .Swoosh avant sa fermeture, objets de collection Reddit et divers POC de chaîne d’approvisionnement. L’écosystème élargi de Polygon comprend désormais Polygon zkEVM et Polygon CDK pour créer des blockchains propres aux applications.

Points forts : déploiement économique de contrats compatibles Ethereum à grande échelle, bonne expérience développeur et démarche commerciale active auprès des entreprises. Limites : de nombreux partenariats avec de grandes marques n’ont pas duré, l’économie du token est complexe et la blockchain a connu des incidents de sécurité. Le développement Polygon est souvent le choix de nos clients de taille intermédiaire qui recherchent un réseau ouvert à coût maîtrisé.

Solana (sans autorisation)

Débit élevé — 65 000 TPS théoriques, plusieurs milliers en pratique — coûts très faibles et finalité inférieure à une seconde. Utilisée pour les applications grand public, la DeFi à haute fréquence, les marketplaces NFT et les paiements en temps réel. La stack de développement de Solana fondée sur Rust, plutôt que sur Solidity, est un véritable critère si votre équipe maîtrise déjà l’EVM.

L’adoption en entreprise progresse, mais a longtemps été freinée par les interruptions du réseau : plusieurs arrêts de plusieurs heures entre 2022 et 2023, largement résolus depuis, mais encore présents dans les mémoires. Toute entreprise évaluant Solana en 2026 a probablement déjà dû déterminer les conséquences d’une interruption sur ses SLA. La réponse conditionne la pertinence du réseau. Consultez notre page sur le développement Solana pour les aspects pratiques.

Hyperledger Fabric (à accès autorisé)

La blockchain d’entreprise la plus largement déployée. Issue d’IBM, elle relève aujourd’hui du projet Hyperledger de la Linux Foundation. Elle propose un consensus interchangeable, des canaux de données privés et du chaincode écrit en Go, JavaScript ou Java plutôt que des smart contracts au sens strict.

Chaque choix de conception répond aux besoins des entreprises. Les canaux permettent aux organisations de consulter différents sous-ensembles de données. Le Membership Service Provider gère les identités. Le consensus modulaire permet de choisir PBFT ou Raft selon le modèle de confiance. C’est le choix classique pour les consortiums, surtout lorsqu’IBM est déjà présent chez le client.

Points forts : blockchain à accès autorisé la plus mature, déploiements réels, documentation abondante et large soutien des prestataires. Limites : exploitation lourde, apprentissage difficile pour les équipes venant d’Ethereum et ralentissement de la dynamique des consortiums blockchain depuis 2022. Elle reste la référence pour les projets bancaires et logistiques en consortium. Notre expertise Hyperledger Fabric couvre les détails de mise en œuvre.

R3 Corda (à accès autorisé, spécialisée)

Conçue spécialement pour les services financiers. Précisons que Corda n’est pas strictement une blockchain au sens traditionnel : les données circulent directement entre participants au lieu d’être répliquées sur chaque nœud d’un registre global. Pour les processus financiers réglementés, c’est un avantage : les données de trading d’une contrepartie ne doivent pas être visibles par tous.

Son architecture repose sur les composants réellement utilisés dans la finance : notaires, contrats en Kotlin ou Java et flux plutôt que smart contracts. Elle excelle dans le change, les produits dérivés, les prêts syndiqués et le règlement interbancaire. Son champ d’application est plus étroit que celui de Fabric : on la rencontre rarement dans la logistique ou la santé, mais elle est très solide dans sa spécialité.

Quorum, Besu et autres blockchains à accès autorisé dérivées d’Ethereum

Quorum était une version dérivée d’Ethereum créée par JP Morgan pour les réseaux à accès autorisé. Elle relève désormais de ConsenSys et son avenir stratégique reste incertain depuis quelques années : vérifiez sa situation avant de vous engager. Hyperledger Besu demeure un client Ethereum solide pour les réseaux à accès autorisé, avec le consensus IBFT2. Les réseaux Geth privés existent toujours.

L’intérêt de cette catégorie : profiter des outils Ethereum (Solidity, Truffle ou Hardhat, portefeuilles compatibles MetaMask) avec un contrôle des accès. La promesse est simple : « des développeurs Ethereum sur une blockchain privée ». La réalité est plus nuancée : le consensus à accès autorisé a moins fait ses preuves et la communauté est plus restreinte que celles de Fabric et d’Ethereum.

Cosmos, Polkadot et l’approche des blockchains applicatives

Une voie intermédiaire émergente, particulièrement intéressante pour les entreprises en 2026. Les zones Cosmos et les parachains Polkadot permettent à un consortium ou à une organisation d’exploiter sa propre blockchain souveraine tout en communiquant avec un réseau plus vaste grâce à IBC (Cosmos) ou XCM (Polkadot).

C’est ici que les modèles hybrides prennent tout leur sens. Vous conservez le contrôle d’un réseau à accès autorisé — vos validateurs, votre gouvernance, vos règles de visibilité — tout en restant connecté à l’écosystème ouvert si nécessaire. Le protocole Inter-Blockchain Communication (Cosmos) et XCM (Polkadot) sont suffisamment matures en 2026 pour que l’interopérabilité entre blockchains ne soit plus le problème de recherche d’il y a cinq ans. Pour les consortiums qui veulent rester souverains sans s’isoler, cette approche mérite une étude sérieuse. Son adoption en entreprise reste moins avancée que celle de Fabric, mais progresse.

Les plateformes en bref

Un tableau de référence. Ne le prenez pas pour une décision toute faite, mais pour un aide-mémoire à consulter en examinant les quatre dimensions précédentes.

Plateforme	Accès	TPS réels	Finalité	Langage des contrats	Atouts / points de vigilance
Réseau principal Ethereum	Sans autorisation	~15	~12 s (économique)	Solidity, Vyper	Décentralisation maximale, écosystème très riche. Coûts et débit : privilégier les L2.
Ethereum L2 (Arbitrum, Base)	Sans autorisation	~2 000+	De quelques secondes à quelques minutes	Solidity	Choix pratique pour la plupart des dApps en 2026. Transferts entre réseaux encore complexes en UX.
Polygon PoS	Sans autorisation	~7 000	~2 s	Solidity	Coûts adaptés aux entreprises. Incidents de sécurité passés ; surveiller la gouvernance.
Solana	Sans autorisation	~3 000–4 000	<1 s	Rust	Rapidité et faible coût. Historique des interruptions important pour les SLA.
Hyperledger Fabric	À accès autorisé	~1 000–3 000	~1 s	Go, JS, Java	Référence pour les consortiums. Exploitation lourde.
R3 Corda	À accès autorisé	~600+	Moins d’une seconde	Kotlin, Java	Spécialiste des services financiers. Périmètre étroit, expertise approfondie.
Blockchain applicative Cosmos	Les deux	~10 000	~6 s	CosmWasm (Rust)	Blockchain souveraine interopérable. Encore en maturation pour les entreprises.

Précision sur ce tableau : les chiffres de débit correspondent à ce que les plateformes soutiennent de manière fiable en production, pas à leurs promesses marketing. Les maxima théoriques sont très différents : Solana annonce 65 000 TPS et Fabric a publié des tests dépassant 20 000 TPS en environnement contrôlé. Aucun de ces chiffres ne représente nécessairement le débit de votre futur réseau.

Associer chaque cas d’usage au bon modèle

Six cas d’usage, avec des recommandations sans détour. Pas une liste de fournisseurs, mais un regard de praticien.

Règlement interbancaire entre banques réglementées

À accès autorisé. Très probablement Corda ou Fabric. Les participants sont des entités réglementées identifiées, la confidentialité des données de trading est impérative, la finalité du règlement doit répondre aux exigences institutionnelles et le régulateur attend une gouvernance exercée par des participants nommément identifiés. C’est précisément le terrain pour lequel ces réseaux ont été conçus.

Marketplace publique d’immobilier tokenisé

Sans autorisation. Ethereum L2 ou Polygon. Le produit repose sur l’idée que « chacun peut acheter une fraction d’un actif » : l’accès ouvert est donc une fonctionnalité essentielle. Une blockchain à accès autorisé irait à l’encontre de cet objectif. L’auditabilité des smart contracts renforce la confiance des clients. La conformité (KYC des acheteurs) se gère au niveau de l’application, pas de la blockchain.

Traçabilité de la chaîne d’approvisionnement à plusieurs niveaux

Un consortium à accès autorisé (Fabric) est le choix habituel et souvent le bon pour une première version. Mais en 2026, l’approche plus élaborée est hybride : une blockchain à accès autorisé pour le détail des transactions et un ancrage périodique sur une blockchain publique (Ethereum ou Polygon) pour permettre un audit indépendant. Les organisations bénéficient ainsi de la confidentialité et du débit du réseau privé, tandis que les auditeurs externes ou clients peuvent vérifier une preuve publique de non-altération. Mieux vaut le prévoir dès le départ que l’ajouter ensuite. Consultez nos travaux sur la gestion documentaire blockchain pour des exemples connexes.

Identité numérique et justificatifs vérifiables

Tout dépend de l’émetteur et du degré d’ouverture requis. Pour une identité délivrée par une entreprise ou une administration (accréditations de salariés, licences professionnelles), un réseau à accès autorisé est cohérent : l’émetteur fait autorité, les vérifications reposent sur des identités connues et la confidentialité compte. Pour une identité autosouveraine, où chacun contrôle ses justificatifs et où tous peuvent les vérifier, un réseau sans autorisation est plus naturel. Méfiez-vous des réponses universelles.

Protocole DeFi ou DEX

Sans autorisation, pratiquement sans alternative. Un protocole DeFi à accès autorisé est contradictoire. Pour une solution devant interagir avec l’écosystème DeFi existant, une L2 Ethereum ou une blockchain compatible EVM constitue le choix pratique. Nos projets de développement DeFi suivent systématiquement cette voie.

Gestion documentaire interne avec exigences d’audit

Revenez au test en quatre questions. Vraiment. Si une seule organisation contrôle les documents et que l’auditeur est le seul intervenant externe, une base de données bien conçue avec chaînage cryptographique des enregistrements satisfera toutes les exigences réelles pour une fraction du coût. Ici, la blockchain est presque toujours une solution en quête de problème. Si un membre de l’équipe insiste, proposez d’abord une architecture Postgres solide, puis réévaluez l’intérêt du projet.

Quand la blockchain est le mauvais choix, quel que soit son type

Personne dans le secteur blockchain n’aime écrire cette section. Elle est pourtant nécessaire : les promesses excessives y sont fréquentes, alors que la crédibilité à long terme repose sur la franchise. Voici les situations où la blockchain, privée ou publique, échoue au test et ne devrait pas être retenue :

• Une seule partie contrôle toutes les données. Une base de données assortie d’un journal d’audit signé coûte moins cher et rend le même service.
• Un intermédiaire de confiance existe déjà, fonctionne bien et ne prélève pas de frais justifiant sa suppression. La promesse de la blockchain est de se passer de cet intermédiaire. Sans problème d’intermédiation, cette promesse n’a pas d’intérêt.
• Les exigences de performance sont réellement élevées : des dizaines de milliers de transactions par seconde en continu. Même les blockchains les plus rapides n’atteignent pas encore ce niveau hors de tests très ciblés. Pour un moteur de trading en temps réel ou un commutateur de paiement, choisissez une infrastructure spécialisée.
• Les exigences de confidentialité sont incompatibles avec le modèle de visibilité de la blockchain et aucune couche de protection n’a été budgétée. Les preuves ZK ont un coût. Les canaux et transactions privées présentent aussi des compromis. Réglez cette question dès le cadrage, pas au déploiement.
• La réglementation impose des garanties précises de localisation des données ou de droit à l’oubli difficiles à assurer sur une blockchain. Le droit à l’effacement prévu par le RGPD s’accorde mal avec un registre immuable. Des solutions existent, mais exigent une architecture adaptée dès le départ.
• L’objectif annoncé est « nous voulons faire quelque chose avec la blockchain ». Si le projet est conçu à rebours pour justifier l’usage de cette technologie, le résultat est généralement prévisible. Fuyez sans hésiter.

La bonne approche ne consiste pas à choisir la blockchain parce qu’elle figure dans une présentation stratégique. Elle consiste à retenir l’architecture la plus simple répondant au besoin réel. Parfois, c’est une blockchain publique. Parfois, un réseau à accès autorisé. Souvent, une base de données bien conçue. Ce sont les exigences qui doivent guider le choix, pas un catalogue de technologies.

Les données du marché confirment l’adoption des blockchains publiques pour la tokenisation

La tokenisation des actifs est un domaine où le débat entre blockchain privée et publique se tranche progressivement au grand jour. Cette catégorie englobe les bons du Trésor tokenisés, les actifs du monde réel (RWA), les stablecoins et les security tokens. Les chiffres méritent attention : ils montrent où vont réellement les investissements des entreprises, au-delà des études de cas séduisantes.

Une synthèse récente d’InvestaX, opérateur de plateforme de tokenisation agréé à Singapour, rassemble ces données. En mai 2024, environ 60 % des produits de bons du Trésor tokenisés fonctionnaient sur Ethereum (selon The Block), 87 % de la valeur verrouillée des tokens RWA se trouvait sur Ethereum (selon DefiLlama) et six des sept principaux protocoles RWA étaient déployés sur Ethereum (selon RWA.xyz). Le rapport de Grayscale « Public Blockchains and the Tokenization Revolution » défend la même idée : les banques ont surtout exploré les infrastructures privées en raison des contraintes réglementaires, tandis que les gestionnaires d’actifs ont privilégié les blockchains publiques ou les architectures hybrides.

Pour situer le contexte, le marché mondial de la blockchain devrait passer d’environ 44 milliards de dollars en 2025 à près de 746 milliards en 2032 (Fortune Business Insights), soit un taux de croissance annuel composé supérieur à 50 %. La tokenisation contribue largement à cette croissance.

Cette préférence pour les blockchains publiques dans ce cas précis s’explique par l’interopérabilité (les tokens RWA utilisables avec les stablecoins, les garanties DeFi et les pools de liquidité ont davantage de valeur que les tokens isolés), les effets de réseau (les meilleurs développeurs, les outils les plus complets et les capitaux les plus importants se trouvent sur les réseaux publics), ainsi que par une clarification progressive de la réglementation des titres tokenisés sur les infrastructures publiques dans les grandes juridictions.

Cela ne signifie pas que les blockchains publiques conviennent automatiquement à tous les projets de tokenisation. Une banque qui souhaite tokeniser son portefeuille de négociation interne, avec uniquement d’autres établissements réglementés comme contreparties, a de bonnes raisons de choisir Corda ou Fabric. En revanche, pour les gestionnaires d’actifs qui souhaitent émettre des tokens destinés à être négociés, détenus dans des protocoles DeFi ou utilisés comme garantie dans l’écosystème élargi des actifs numériques, les données indiquent clairement où se concentre l’activité.

Considérez ces chiffres comme un élément de votre choix de plateforme, pas comme une consigne. Le test en quatre questions présenté au début de cet article reste valable : si votre projet de tokenisation n’a pas réellement besoin de l’interopérabilité d’une blockchain publique, un réseau permissionné peut rester le meilleur choix. Ces chiffres peuvent départager deux options proches, mais ne remplacent pas l’adéquation de l’architecture aux besoins.

Comment choisir concrètement : une méthode en quatre étapes

Rassemblons les éléments. Si vous évaluez actuellement un projet concret, voici l’ordre à suivre :

1. Appliquez le test blockchain en quatre questions. Plusieurs parties doivent-elles partager un état ? La confiance est-elle partielle ? Une source unique de vérité est-elle indispensable ? Les litiges coûtent-ils cher ? Si l’un de ces critères n’est pas rempli, ne choisissez pas la blockchain. Commencez par envisager une base de données bien conçue.
2. Choisissez entre réseau permissionné et sans permission selon les participants. Qui participe ? Leur identité est-elle déjà connue ? L’accès ouvert est-il une fonctionnalité du produit ou un problème de conformité ? Cette question suffit à résoudre l’essentiel du débat entre blockchain privée et publique.
3. Affinez le choix de la plateforme selon les contraintes d’exploitation. Débit, finalité, gouvernance, coûts, stack de développement, conformité réglementaire, compétences de l’équipe. C’est sur ces points qu’Ethereum, Solana, Polygon, Fabric, Corda et Cosmos présentent des différences déterminantes.
4. Réalisez un prototype sans vous raconter d’histoires. Développez la même solution sur les deux plateformes les plus plausibles pour votre cas d’usage. Mesurez les résultats au lieu de vous fier aux présentations commerciales. Beaucoup d’équipes sautent cette étape et le regrettent, parfois à grands frais. Deux semaines d’expérimentation peuvent éviter six mois de déploiement sur la mauvaise plateforme.

L’erreur classique consiste à sauter l’étape 1 (parce que « le conseil d’administration veut de la blockchain »), puis l’étape 4 (parce que « nous avons déjà choisi la plateforme »). Ces deux raccourcis donnent naissance à des projets qui semblent fonctionner, jusqu’au moment où ils échouent.

Conclusion

La plupart des articles posent mal la question du choix entre blockchain privée et publique, ce qui contribue largement aux difficultés rencontrées par ces projets. Le véritable arbre de décision commence par « faut-il réellement utiliser une blockchain ? », se poursuit par le choix entre réseau permissionné et sans permission, puis aboutit à la sélection de la plateforme. À chaque étape, il faut aussi envisager que la blockchain soit tout simplement le mauvais outil.

Si vous répondez correctement à la première question, la suite devient beaucoup plus simple. Pour la plupart des cas d’usage qui passent le test en quatre points, le choix entre permissionné et sans permission devient assez évident dès lors que vous connaissez les participants et les validateurs. En filtrant selon le débit, la finalité et les compétences de l’équipe, la liste des plateformes se réduit souvent à deux options sérieuses. Un prototype avant tout engagement permet ensuite d’éliminer une grande partie des risques.

Si vous êtes précisément à cette étape, entre « la blockchain pourrait nous aider » et « nous sommes prêts à définir le périmètre du projet », un regard extérieur peut réellement rentabiliser son coût. Nous accompagnons depuis sept ans des projets de blockchain privée et publique. Nous vous dirons clairement quel modèle correspond à votre problème, et si une blockchain est même nécessaire. Contactez-nous pour discuter de ce que vous souhaitez réellement développer.